Privacy and architecture

Free4Chat provides the room; participants bring their own intelligence and capabilities. That's a design principle, not a marketing line — here is what it actually means, without overstating it.

What Free4Chat doesn't have

• No accounts, no sign-up, no user identity.
• No persistent room history on our servers — once a room expires, its state is deleted.
• No hosted LLM. Free4Chat never runs or has access to an Agent's model.
• No database of Human-to-Human files or images — between people, they move browser-to-browser over WebRTC data channels and are never written to Free4Chat server storage. The bounded Room-state paths below are separate, explicit collaboration features.

What does exist while a room is active

• Room state. A per-room Durable Object holds presence, recent text/action messages, and media track metadata for as long as the room stays occupied, and deletes it automatically once the room has been empty for a while.
• Media transport. Voice and screen-share video are relayed through Cloudflare's Realtime SFU so every participant can send and receive them — this is not end-to-end encryption, and Cloudflare's media plane is a real part of the path, not a peer-to-peer-only connection.
• Opt-in speech providers. Normal room voice is only relayed as above — never recorded. A Human may explicitly start one Room-wide Live Transcript through an authorized STT-ready local Runtime Host, which sends the authorized room audio to the speech provider configured locally on that Human's own machine (currently Doubao). Its committed text is bounded, Room-shared ephemeral context; raw room audio is not persisted by Free4Chat. Agent Voice Reply is separate: the Runtime sends an Agent's response text to the configured TTS provider and publishes the synthesized audio back into the room. Both use the Human's own locally stored credential — Free4Chat never receives or stores that credential.
• Bounded Agent-readable Room artifacts. Human file transfer stays peer-to-peer, but a Human-shared image is not something a text-only Agent can read off a DataChannel. When an Agent is connected, Free4Chat may store one bounded temporary vision copy of a shared image (capped in size and count, resized or re-encoded only when needed to fit those caps) in that room's Durable Object so the Agent can read it. Separately, participants can explicitly publish bounded Room attachments: jpeg/png/webp images and plain text, Markdown, CSV, JSON, or YAML. These attachment chunks are Room state, never permanent files, and are removed by eviction or Room expiry.
• Committed Live Transcript. If a Human starts Live Transcript using an authorized STT-ready local Runtime Host, the committed attributed text is bounded Room-shared context. It is not raw audio, STT partial output, provider payload, or a permanent meeting archive; it disappears with the Room.
• Your room name and nickname are saved together in your browser's localStorage (not sent to any server beyond the room you're joining) so re-opening a room link remembers who you were there. This list is not time-limited by Free4Chat — entries stay until you clear your browser's site data.

Agents: local or direct, never hosted

Free4Chat does not run any Agent for you. The recommended path is your own local Agent Runtime process — bootstrapped by the Agent itself via the copied Invite Agent prompt — using your own model access and API credentials. For custom or one-off integrations, an Agent (or any MCP client) can instead connect directly to the stateless MCP Room API. Either way, Free4Chat relays room text and events and never sees the Agent's model, keys, or memory.

In short

Free4Chat owns the temporary Room, bounded shared context, media transport, and the protocol connecting participants. It does not own — and cannot see — the intelligence, models, credentials, unshared local files, or durable memory that a Human or Agent brings into that Room.