Across two servers

Somebody on your node and somebody on another node are, from the app’s point of view, ordinary people in each other’s list. Most of what follows is invisible to them.

Being Found

A person is found by their handle — their name at their home server. Their node answers with their identity key and where they live, and that is enough for the other node to address them.

Nobody is found by email address across servers, and nobody is listed. You have to know the handle.

Connections

You can invite somebody on another node into a connection, and they can invite you.

The invitation is staged on their side. Nothing is created — no account, no connection, no membership — until they accept it themselves. Accepting is what authorises everything that follows; a message from their server alone cannot make a connection appear on yours.

Once accepted, both sides hold the connection and both see codewords that match. Members joining and leaving, and the connection being deleted, are carried to the other side.

An invitation sent across servers only reaches somebody who already has an account. It never creates one. The one exception is described under What crosses between servers — a node may offer the invitation to trusted.codes instead so the person can register there, and that is off unless the operator turns it on.

Verifying a Code

A code held by somebody on another node verifies normally. The words are not sent; a hash is, and the node that owns the code answers.

A single-use guest code is spent on the node that owns it, once, no matter how many servers ask at the same time.

Ordinary guest codes work this way. Beacons and stamps do not travel across servers; they are resolved by their own routes.

Personal Pages and Share Links

Somebody on another node can reach your personal page or a share link and ask to connect.

Your node decides. The link’s own policy applies, your allowlist applies, and if the link is set to manual approval you are asked, exactly as you would be for somebody on your own server. Your allowance limits apply too. A request that is refused leaves nothing behind — no shadow account, no pending row, no notification.

Deleting an Account, Removing a Device

When somebody deletes their account, their node tells the others, and each one removes what it held: memberships, staged invitations, the record of that identity.

When a device is removed, the removal is announced so other nodes stop accepting anything from that device’s key. A node records the removal even for devices it has never seen.

What Does Not Work Across Servers

Some exchanges are named and recognised but not built. A node that receives one refuses it and tells the sender it is not implemented; nothing is half-done and the sender can retry later, once both sides have it.

Not implemented today:

• Transferring ownership of a connection to somebody on another node, or handing it over.
• Sponsorship — granting, revoking or asking about an entitlement one node gives a person on another.
• Announcing that an identity key has been rotated, or that identity details have changed.
• The slower fallback route for delivering a share when the direct one did not apply.

What an Operator Can Switch Off

Each of these surfaces is a setting on the node that receives it. An operator can turn off code lookup, incoming claims on share links, incoming invitations, group exchanges, or discovery itself.

Switched off, the feature does not fail loudly for the other side — it answers as though there were nothing there. That is deliberate: a node that is not taking part should not advertise what it is holding back.

Federated invitations are delivered by email, so a node with no email transport configured keeps every federation surface off until one is.