Encrypted repo rooms

Why it matters

Encrypted repo rooms gives ForkMesh a concrete mechanism for repo-scoped rooms encrypted before frames are sent. The default mode is authenticated shared-key transport, not end-to-end encryption: the relay derives the shared passphrase and can decrypt messages.

Project conversations often carry design, access, and coordination context, so the trust boundary must be explicit. Default rooms keep unauthenticated observers and passive network intermediaries out, but they do not hide plaintext from the relay operator.

How ForkMesh handles it

The Town Square compatibility room computes SHA-256(DATA_KEY + ":room-chat-passphrase-v1"). Every other repository computes SHA-256(DATA_KEY + ":room-chat-passphrase-v2:" + lower(owner + "/" + repo)), so a public-room key cannot decrypt a private-repository room. The relay releases that scoped passphrase only to an authenticated account or signed node authorized for the repository. Clients apply PBKDF2-HMAC-SHA256 for 210,000 rounds with the first 16 bytes of SHA-256("ForkMesh room:" + roomName), then encrypt frames with AES-256-GCM.

Only frames marked for persistence enter history. The relay keeps the newest 500 persisted frames per room for no more than 7 days; oversized frames are relayed but not retained. Since the relay controls DATA_KEY, it can derive the default room key and read that history.

Clients that support an out-of-band participant passphrase can derive a key the relay does not know. That explicit participant-key mode, not the default shared room, provides confidentiality from the relay.

Where it fits

Use default rooms when teams need repository-aware conversation with authenticated membership and encrypted transport while accepting the relay operator in the trust boundary.

Use an out-of-band participant passphrase when the relay must not be able to derive the room key.