What crosses between servers

Nodes talk to each other in signed messages, one message per event. Each message is signed by the sending node and checked by the receiving node before anything happens with it. A message that fails the check is refused, and a message that has been seen before is refused again — a node keeps a record of every message it has already accepted.

Everything below is what those messages contain. Nothing else travels.

Finding a Person

A node publishes a discovery answer for each of its people. Ask it for a handle and it returns that person’s handle, their home server, their public identity key, and the protocol versions the node speaks. The answer is signed.

That is the whole answer. No email address, no trust score, no count of connections, no name.

If the handle does not exist, the node says so — and signs that too, so a network in between cannot invent an answer that a person is gone.

Discovery can be switched off, in which case the node is dark and other nodes cannot resolve anybody on it.

Looking Up a Code

When somebody verifies a code that belongs to a person on another node, the words themselves do not travel. Only a hash of them does.

The node that owns the code answers. Depending on what was asked, the answer is either a plain yes or no, or — for a single-use guest code being spent — the details that go with the match. The code is spent exactly once even if several requests arrive at the same moment; the ones that lose the race are told the code is already consumed.

The node that owns the code records who asked.

Invitations

An invitation sent to somebody on another node carries the two people’s public identity keys, the inviter’s display name, a reference to the connection on the inviting node, and the encrypted invitation message.

The receiving node stages it. It does not create an account and it does not create a connection. Nothing exists on the invitee’s side until the invitee themselves accepts.

There is one case where an email address crosses: when a member of a node invites somebody who has no account anywhere and the node cannot create accounts itself. The node then offers the invitation to trusted.codes, and the invited person’s email address goes with it, so that they can register there. That behaviour is a setting, it is off unless the operator turns it on, and the receiving side has to accept offers from your node as well. See your node’s Node Settings for both halves.

Connection Secrets

The material that produces the codewords two people see is wrapped by the sending person’s device for the receiving person’s device. It passes through both servers as an opaque blob. Neither server can open it.

The two people see matching codewords because their devices derive them from that shared secret. Each server also holds its own separate value for its own local bookkeeping; that value is not what the codewords come from.

The connection’s name travels encrypted.

Membership Changes

When somebody joins a connection, leaves it, or the connection is deleted, the other node is told. When somebody deletes their account, their node announces it and every other node removes what it held about that identity. When a device is removed, the removal is announced so that other nodes stop trusting that device’s key.

A node can also ask another node whether a connection it mirrors still exists and whether particular people are still in it. It may only ask about people it already names. The roster is never listed back, and a node that is not itself part of that connection is told nothing at all.

Push Notifications

A node that runs its own users still cannot send to Apple and Google directly — the credentials for the shared mobile app are not the operator’s to hold. So a node hands the device tokens to trusted.codes to deliver.

The relay carries the tokens and the kind of wake-up, nothing else. There is no title and no body. The device wakes, asks its own home server for the real data, and shows it locally. If the relay fails, nothing breaks; the app catches up the next time it is opened.

What Never Leaves

Accounts, passwords and sessions. The database itself. The plaintext of a code. The contents of a vault. The name and email address of anybody who has not been part of an exchange.

Any keys the operator supplied for optional services — geolocation, AI, the dashboards — belong to that deployment. Nobody else sees them.