← All posts
engineering security

On the seam: how the bridge sees nothing

Sesori team 3 min read

Illustration of a key over an aurora landscape for Sesori bridge encryption

There’s a part of the Sesori architecture we keep coming back to in design conversations. We call it the seam. It’s the line that runs between your phone and your laptop — the place where messages have to be relayed somehow, because the two devices aren’t usually on the same network. Every system has one. Most of them quietly read what passes through.

Ours doesn’t.

This is a short post about why, and what it cost us to build it that way.

What the relay actually sees

When you type a message on your phone, here is what happens, in order:

  1. The mobile app encrypts the message on-device with a key derived from your session.
  2. The encrypted blob goes out over the relay.
  3. The bridge on your laptop pulls it down and decrypts it locally.
  4. Your AI assistant — running entirely on your machine — sees the plaintext.
  5. The reverse happens for everything coming back.

The relay’s job is to move bytes from one device to another. That’s it. It does not have a key. It cannot derive one. If we were compelled to hand over a year of relay logs, the result would be a directory of opaque binary the size of your conversations and nothing else.

We use X25519 for the key exchange and XChaCha20-Poly1305 for the symmetric encryption. There is nothing exotic here — these are well-vetted modern primitives, and we picked them because they are boring. The interesting work is in the pairing.

The pairing problem

The hardest part of building this wasn’t the math. It was getting keys onto both devices without ever letting our servers touch them, and without making the user scan a QR code every time they switch laptops.

The trick: both devices already have an authenticated identity through your sign-in (Apple, Google, GitHub, or email). We use that identity to anchor a pairing handshake — the phone and the bridge each prove possession of the same account, then derive a shared secret directly between themselves. The relay carries the handshake messages but cannot decrypt them or replay them.

What this means in practice: you install the bridge, run

sesori-bridge

sign in to the app with the same account, and the two find each other. No QR. No copy-paste. No “type this 6-digit code.” It looks like nothing happened, and that’s the whole point.

What it cost us

A few things, honestly. We can’t show you a transcript view in some admin panel — we don’t have access to your transcripts. We can’t analyze “what kinds of prompts work best with Sesori” in aggregate, because we never see the prompts. When something goes wrong, we can’t peek at your message and say “oh, here’s the issue.” We have to rebuild the failure state from your description.

This is fine. It’s the right trade. The thing we’re shipping is a remote control for your AI session — and a remote control that can read everything you say is not actually a tool. It’s a wiretap with a UI on top.

A line we like

A teammate phrased the design goal early on, and we still think about it:

The relay infrastructure should be vanishable. If our entire backend disappeared overnight, no message you ever sent should be readable by anyone who pulls the logs from a backup.

That’s the whole spec, really. The math is in service of that line.

Coming soon