On the seam: why the relay sees only ciphertext

There is a line every remote-control system has to cross. Your phone and development machine are rarely on the same network, so something has to route messages between them. At Sesori, that service is the relay.

The relay is not the Bridge. The Bridge is a trusted local endpoint running on your computer. It connects to the coding harness, decrypts messages intended for that machine, and encrypts messages sent back to your phone. The relay sits between the Bridge and phone and moves encrypted bytes without holding the session keys.

This is a short description of that boundary, what it protects, and what it does not.

What ordinary relay traffic looks like

When you send a prompt from your phone:

1. The mobile app encrypts the message on-device with a key derived for the session.
2. The relay routes that encrypted payload to the Bridge.
3. The Bridge decrypts it locally on your computer.
4. The local coding harness receives the readable prompt.
5. Responses take the reverse path and are encrypted before they reach the relay.

The relay does not receive the key needed to decrypt ordinary session payloads. It can observe operational metadata such as connection timing, message sizes, IP addresses, account and routing identifiers, and delivery state. It cannot read the encrypted payload containing the ordinary session conversation, file changes, or harness responses.

The Bridge is different by design. It runs on the same machine as your repository and coding harness, and it necessarily handles readable session data at that trusted endpoint. That is why the Bridge source is available for inspection under the FSL-1.1-ALv2 license and why the machine running it is part of the trust boundary.

Key exchange and encryption

Sesori uses X25519 for key exchange and XChaCha20-Poly1305 for authenticated encryption. The phone and Bridge derive the shared session material; the relay carries the handshake messages but does not receive the resulting secret key.

Authenticated encryption matters as much as confidentiality. A relay that alters ciphertext cannot silently turn it into a different valid command: tampering causes authentication to fail at the receiving endpoint.

The primitives are intentionally conventional. The product-specific work is pairing the correct authenticated devices, rotating session material, and ensuring plaintext exists only at the endpoints that need it for the requested workflow.

What end-to-end encryption does not mean

Relay encryption is one boundary, not a claim that every feature is local-only.

• Your selected coding harness and model provider have their own data flows and privacy terms. Sesori does not make a cloud-backed model local.
• Voice input uses Sesori’s hosted transcription path, so submitted audio is processed in readable form for that feature.
• Session or branch naming, push-notification snippets, support, diagnostics, abuse prevention, and security investigations can involve limited readable data when the feature or operational need requires it.
• Sesori retains the account, routing, connection, analytics, and security metadata needed to operate the service.

Those paths are described in the Privacy Policy and the security and privacy documentation. The narrower statement we can make about the transport is this: ordinary session payloads routed between the phone and Bridge are end-to-end encrypted, and the relay sees ciphertext rather than their contents.

The design goal

The useful test is not whether the whole system “sees nothing.” The endpoints must see enough to do their jobs. The test is whether the routing layer can recover the content entrusted to the phone and Bridge.

Our design goal is that a copy of relay traffic and relay logs should not be enough to reconstruct an ordinary coding session. The readable work stays at the authenticated endpoints, while the service in the middle routes ciphertext.