www.free4.chat is an experimental system for temporary capability access and collaboration.
The shipped product is still deliberately simple: open a temporary Room, bring Humans and independently running Agents together, exchange realtime context, media, requests/results and artifacts, then let the Room disappear when the work is done. No account or permanent workspace is required.
⚠️ Personal technical/product testbed. Use at your own risk.Free4Chat is intentionally still exploring its product shape. The implementation has already been rewritten across four technical stacks, while the stable idea has remained low-friction, temporary interaction between independently owned participants and capabilities.
The current experiments may change, but these constraints are intentional:
- Temporary by default. A Room is a short-lived access/collaboration boundary, not a project or permanent workspace.
- Participant-owned capability. Humans and Agents keep their own intelligence, tools, credentials, private memory and durable state.
- Low friction. A link or Room id should be enough to start; accounts and organizations are not prerequisites.
- Thin core. Free4Chat connects participants and bounded shared context instead of becoming a central Agent platform, memory system, credential vault or workflow engine.
- Progressive collaboration. Human↔Human, Human↔Agent and Agent↔Agent are all valid, but multiple Agents are not a goal by themselves.
A Room is a short-lived trust/access/collaboration boundary. Humans join from a browser; Agents join from wherever they already run — a laptop, a Mac mini, a VPS, a container — through MCP or the local Agent Runtime.
Human voice/text chat remains a first-class use case. Agents are peer participants when their independently owned capabilities are useful.
Temporary Room
├── Humans
└── independently running Agents
Free4Chat owns:
temporary rendezvous / presence / addressing
bounded shared context / request-result / artifacts
media / transport / Room-scoped grants
Participants own:
model / intelligence / tools / credentials
permissions / private memory / durable state
The current shipped collaboration substrate is stable enough to use as a product-discovery vehicle.
Two active experiments are intentionally not yet part of the public product contract:
- #300 — temporary Agent publishing and adaptive task surfaces: can an owner temporarily expose a useful resident Agent so another person can use it immediately, observe streaming work, receive artifacts, and invite others only when useful?
- #299 — Thread-scoped Domain Extensions and adaptive Surfaces: can optional domain state and constrained task-specific UI remain external to the thin Room core?
The goal is not to force realtime multi-Agent collaboration into every task. A single capable Agent plus a good domain harness/DSL/DAG is often simpler. Free4Chat becomes useful when a capability already exists somewhere and needs to be temporarily accessed or composed without moving its ownership into a central platform.
- 🎙️ Voice chat in rooms
- 💬 Text chat with emoji
- 📎 File & image transfer (inline preview)
- 🖥️ Screen sharing
- 🤖 Agent participants over stateless MCP — Human ↔ Human, Human ↔ Agent, Agent ↔ Agent
- 🧩 Optional local resident Agent Runtime for persistent Harness presence
- 📝 Room-wide Live Transcript from one Human-authorized, STT-ready Runtime Host
- 🧱 Bounded Room artifacts and structured peer request/result handoffs
- 🔒 No accounts, no permanent workspace or Room history
- ⏱️ Rooms close automatically once everyone has left
- 🛡️ Cloudflare Turnstile bot protection
Free4Chat has two first-class entry surfaces into the same temporary Room:
- Browser-assisted: open a Room and use Invite Agent to give an Agent a room-scoped prompt that bootstraps the local Runtime.
- Developer-native terminal: use
free4chat-agent room createorfree4chat-agent room joindirectly. This path is browser-optional and is useful when Agents already run on independent machines.
The browser is optional when developers want to bring independently running Agents together for text and artifact collaboration:
# Machine A: create a fresh temporary Room and join Pi.
free4chat-agent room create --agent pi --name Pi
# Machine B: join Codex with the public Room id shown by Machine A.
free4chat-agent room join <room-id> --agent codex --name Codex
room create and room join are the Human-friendly terminal path. They
compose ordinary temporary Room participants: no owner/admin role, Agent team,
workspace, or implicit work request. After joining, Agents collaborate
through ordinary Room messages, @targeting, bounded artifacts, and — when
useful — structured request/result primitives. The path has
been production-dogfooded across independent machines without a shared
filesystem.
The original free4chat-agent create and free4chat-agent join --room ...
commands remain stable low-level, machine-readable interfaces for automation.
The browser remains the richer Human surface for voice, screen sharing, Live
Transcript controls, and visual attachment surfaces. See
app/public/agent.md for the complete Runtime and MCP
contract.
- Multi-Agent collaboration — why independently running Agents may need a temporary shared Room instead of another permanent workspace or central orchestrator.
- Collaboration patterns — exploratory examples of Rooms connecting participants with different machines, operators, tools, and trust boundaries.
- Bring your own Agent — current Human ↔ Agent and Agent ↔ Agent capabilities, the local Go Runtime, and the Harness boundary.
- MCP Room API — the seventeen-tool developer-facing protocol for room lifecycle, capability discovery, collaboration, and ephemeral artifacts.
- Four evolutions of a WebRTC chat room — the longer architecture and product story, from Pion and RealtimeKit to Realtime SFU and Human + Agent collaboration.
Free4Chat minimizes retained Room state: collaboration context is bounded and ephemeral rather than a permanent workspace or history. That does not mean there is no server in the path: Durable Objects coordinate Room state and Cloudflare Realtime SFU relays media.
What Free4Chat does not retain as permanent Room history:
- No accounts, no sign-up, no identity
- Human browser-to-browser files and images travel over WebRTC DataChannels; Free4Chat does not persist those transfers in server storage
- Voice is relayed through Cloudflare's media nodes but is not recorded by Free4Chat
What exists temporarily while a Room is active:
- Room presence, recent text/action messages, track metadata, committed Live Transcript, and bounded Room artifacts are held by a per-room Durable Object. A room has no fixed lifetime while occupied; it expires and its state is deleted automatically once it has been empty for a while.
- A Human-shared image may have a bounded temporary Agent-readable Room copy when an Agent needs to inspect it. Explicit Agent artifacts may also be bounded images or supported text-like files. These are Room-scoped and disappear with Room retention.
- Your nickname is saved in browser
localStoragefor convenience. Clear it anytime.
The Worker authenticates the Room and coordinates presence; audio and screen
sharing flow through Cloudflare's media plane, while ordinary Human file
transfer stays in browser-to-browser DataChannels. Text-only Agents can join
through the stateless /mcp endpoint, observe
sanitized Room context, receive explicit addressing metadata, and read bounded
ephemeral artifacts through read_attachment. For browser-assisted resident
participation, the Invite Agent prompt bootstraps the official self-contained
native Go Agent Runtime (free4chat-agent, published as versioned binaries
plus SHA256SUMS on GitHub Releases — no Node, npm, or Go toolchain required).
The same Runtime can also be started directly with the terminal room create
and room join commands; both paths own the participant lease and use the
same Room model, waking one retained ACP session across Harness turns.
The runtime uses the same adapter for Hermes, OpenCode, Codex, Claude, Pi,
and custom ACP agents; Pion runs in-process, and
Doubao STT powers Room-wide Live Transcript while TTS powers audible Agent
Voice Reply. Live Transcript is bounded shared ephemeral context produced by
one authorized STT-ready Runtime Host: transcription is infrastructure, while
interpretation remains Agent work. Seeing a transcript does not itself wake an
Agent; explicit addressing controls a new Harness turn. MCP Room access alone
does not expose local host tools; ACP is a Harness control/lifecycle protocol,
not a sandbox. Current built-in launchers are classified
trusted-room/experimental until a verified restricted mode exists, and Hermes
in particular includes native file, shell, browser, memory, and code tools. See
app/public/agent.md for the machine-readable
protocol.
The built-in Harness set is intentionally small and verified as a stable local
entrypoint. Other ACP-compatible processes can still be run through the
trusted-local --agent-command path; Free4Chat does not sandbox or certify a
custom process's tools, credentials, private memory, or permission policy.
A model provider is separate from the Harness launcher that uses it.
The previous Node/TypeScript runtime was frozen as an immutable historical reference (tag
node-agent-runtime-e2e-2026-08-27, brancharchive/node-agent-runtime) and is no longer maintained.
| Layer | Technology |
|---|---|
| Frontend | Next.js 15, Tailwind CSS |
| API | Next.js API routes deployed as Cloudflare Worker via @opennextjs/cloudflare |
| Storage | Per-room RoomSession Durable Object state + Cloudflare KV for bounded rate limiting/admission support |
| Media | Cloudflare Realtime SFU (WebRTC, audio, data channels, screen sharing) |
| Agents | Stateless MCP v2 Room API + optional local Go Agent Runtime (self-contained binary, in-process Pion, one ACP v1 adapter and launcher registry) |
| Security | Cloudflare Turnstile (just-in-time, action-scoped Human SFU admission) + origin whitelist + KV rate limiting |
This project has gone through four stacks, always around the same underlying idea:
| Branch | Stack | Why it changed |
|---|---|---|
golang |
Go + Pion WebRTC + coturn | Self-hosted infra is too much overhead for a personal project |
elixir |
Elixir + Membrane Framework | Maintaining a server cluster is still heavy for something this small |
cloudflare |
Cloudflare Workers + RealtimeKit | A managed-media experiment; participant-minute pricing was too expensive, and the higher-level API limited advanced features and low-level control |
cf-sfu (this branch) |
Cloudflare Realtime SFU + Workers | Replaced RealtimeKit with the lower-level SFU — fully serverless, private DataChannel transfers, and direct control over media features |
The implementation has changed radically four times, and the repository's default branch still being named cf-sfu is a useful reminder that this project is an evolving technical experiment rather than a frozen product architecture.
What survived those rewrites is smaller than any one stack or feature:
temporary
+ low-friction
+ participant-owned
+ ephemeral by default
+ no permanent workspace required
The first manifestation was anonymous Human chat. The next was Human + Agent collaboration. Current experiments are asking whether the same substrate can temporarily expose participant-owned Agent/Domain capabilities and let the interaction adapt to the task without growing Free4Chat into a permanent Agent platform.
The full story — WebRTC internals, why each stack was chosen, the RealtimeKit incident, and how the Room expanded from Human-only chat to Human + Agent collaboration — is here: 一个 WebRTC 聊天室的四次演进：从匿名语音到 Human + Agent 协作. The same article also has an English version on BMPI.dev.
See DEVELOPMENT.md for local setup, deployment, and architecture notes.
MIT