How teams and trust work

A team shares vaults of hosts, keys and snippets between people, end-to-end encrypted. The hard part is not the encryption but deciding whose keys to trust: the sync server stores the team and hands out everyone’s public keys, and Sternway treats that server as untrusted. This page explains how a team works without trusting it.

The signed member list

Each team has a member list that says who is in it, which vaults it has, who may open each vault (and whether they can edit or only view), each vault’s current key version, and the owner’s privacy settings for the team (whether sessions to team hosts are recorded, whether a vault keeps session logs).

The team owner’s app signs this list with the owner’s Ed25519 key every time it changes, and each new list links to the one before it. On a team with policies and roles, admins the owner allows sign changes too, within rules every device checks. The server stores the lists and serves them, but it has no signing key, so it cannot write a list of its own.

Every member’s app checks each new list: that it follows the last one it trusted, that the right person signed it, and that the signer’s keys match the fingerprint the list names. A list that fails is refused, and the team goes on with the last one that passed (“The team’s member list could not be verified”).

The list decides everything else:

A vault key is used only if it was sealed by the owner (or an allowed admin), at a key version the list allows, for a vault the list gives this person.
A vault the server lists but the signed list does not is closed, not used.
Recording and session-log settings come from the owner’s signature, not from the server.

Safety numbers

The first time a device sees a team, it has only the server’s word for who the owner is, and the same goes for each person’s public key. That is trust on first use. A safety number closes the gap: six groups of five digits computed from a person’s public keys. If the number Sternway shows you for someone matches the one their own app shows them (Security and account › Your safety number), then the keys really are theirs, and not keys the server put in their place.

Compare numbers over a channel the server does not control: in person, a phone call, a chat you already trust. Then Mark as verified stores the fingerprint on your device. If someone’s keys change later (for example after they reset their account), their row says Safety number changed, and a team whose owner’s keys changed pauses on your device until you compare the new number.

The owner must verify a member’s safety number before handing them the team or a role that signs changes.

Accepting a team, a vault and a change

A team that appears on a device (because you joined it on another device, or because the server invented it) is pending until you accept it there, with the owner’s safety number in front of you. Until then nothing from it is used.
A vault added to a team later is pending the same way: “… shared the vault … with you”.
A team host that another member changed (its address, port, jump hosts, login, startup command and a dozen more fields) stops before the next connection, shows the old and new values with who changed them and when, and asks.
A port forward from a team vault starts only after you approved that exact rule on your device.

These prompts make changes visible; they cannot judge whether a change is honest. A member with edit access can still create a misleading host or snippet. The “changed by” name is what the writer’s own app wrote, so a dishonest member could put someone else’s name there.

What “Can view” means

The server lets a viewer read a vault but not change it. A viewer’s devices still hold the vault’s key, so they could read everything in it: “Can view” is a permission the server enforces, not a cryptographic limit.

Removing a member

Removing a member drops them from the signed list, and the vault keys they had are rotated: new keys are sealed only to the people who keep access, and the server stops serving them. They receive nothing new.

It cannot take back what they already had. A removed member keeps the items and keys they synced before, readable on their devices for as long as those devices keep them. That is true of any end-to-end encrypted system: the server never had the plaintext to withdraw. If they may have seen credentials that matter, change those credentials on the servers themselves.

An access with an end date works the same way: when it ends, the member’s app closes the vault, the server refuses them, and the owner’s app asks for a rotation. Until the rotation, the member still holds the current key.

Team policies

On a team that has turned on policies, the owner (and admins the owner allows) set rules that every member’s app applies, such as requiring the app lock or keys instead of passwords. The rules are part of the signed list, so the server cannot change them; but app rules are applied by the apps, so a modified app could ignore them, and server rules (such as requiring two-factor) are applied by the server, so a malicious server could skip them while showing them as on. Policy values and the reasons given for them are visible to the server. See Set team policies and roles and Team policies.

What the server still sees

Who is in which team, which vaults exist, who may open them, how many items they hold and how big they are, and when things change. It does not see what any item contains.

Limits, in one place

The first list of a team and each person’s first key are trusted on first use until safety numbers are compared.
The server can withhold new lists or new items, keeping a device on an older (but genuine) state; it cannot forge newer ones.
A team is as strong as its members’ oldest app: an app from before the signed list keeps older, weaker behaviour.
Removed members keep what they had.

Threat model puts these next to the other cases.