Team chat & calls, straight off the engine
Direct by default
Audio, video and screen travel directly between browsers whenever networks allow. If a firewall blocks the path, an encrypted relay forwards packets it cannot read. Either way, media stays encrypted end to end.
Guests knock
Signed-in colleagues walk straight in. Anyone else asks to join with a name, and someone inside lets them in.
Share, record, moderate
Present a screen, record the call straight to your own machine (everyone sees the red dot), pin any tile, switch mic or camera mid-call, and hosts can mute or remove participants. Chat rides the encrypted peer connections, with the engine as fallback.
Message anyone, call in one click
The whole company is on the left, synced from Okta through the User Hub.
Ready to join?
Everything that shipped
One entry per release, newest first.
Anatomy of a workspace
Company chat with calls built in, running as a canister on a cloud engine. One sign-in through the User Hub; the call media never meets the server.
§ 01One sign-in, the whole company
Colleagues sign in once through the User Hub (Okta single sign-on) and land in the chat: the whole directory on the left, synced from Okta. Direct messages and group chats live on the Quick Chat canister — persistent, like Slack. Groups work the way you expect: pick members from the directory, name the group, promote admins, and optionally let messages disappear after a chosen time (an hour up to four weeks). Access follows the hub: someone deactivated in Okta drops out of the directory within seconds, and their session with it.
§ 02Where things are stored — honestly
Two different privacy models coexist here, and it matters which one you are in. Calls: audio, video and screen-share are end-to-end encrypted between browsers — the canister brokers introductions and cannot see a frame (details below). Persistent chat: messages are stored on the canister so your history follows you across devices — the engine's node operators could technically read them, as with any hosted chat tool. Disappearing messages limit how long they exist at all. In-call chat is the exception: it rides the encrypted peer connections and never persists.
§ 03The room lives on the engine
Starting a call makes a room on the canister: a Meet-style code, a participant list, and a small signaling mailbox. Clients talk to it with fast query polls — twice a second while connecting. Colleagues walk straight in; guests knock with a name and wait until someone inside admits them. Rooms are working state, not records: idle rooms are swept after 12 hours, and when the last person leaves, the room ends itself.
§ 04Media never touches the server
Once two participants know about each other, their browsers negotiate a direct WebRTC connection through the canister mailbox — offers, answers and network candidates, a few KB of text. The audio, video and screen-share themselves flow directly between browsers, encrypted end to end (DTLS-SRTP). The canister brokers introductions; it cannot see or store a single frame. In-call chat rides the same encrypted peer connections, falling back to the canister mailbox only when no direct channel exists.
§ 05When networks say no
Some network pairs — office firewall meets cellular carrier NAT — have no direct path. For those, a TURN relay forwards the encrypted packets. It cannot read them: end-to-end encryption holds, the relay only moves ciphertext. ICE picks the best available route automatically and upgrades to direct whenever possible.
§ 06Capacity, honestly
Calls are a full mesh: everyone sends to everyone. Video bitrate and resolution adapt automatically to call size, which carries up to 10 participants. Beyond that a server-side media router (SFU) would be needed — which a canister can't be, by design. Large all-hands stay where they are for now.
§ 07Features
§ 06What the engine stores
The public pulse
Aggregate numbers straight from the canister — never meeting codes, names or identities. Heartbeats are measured live from your own browser.