Part of Stem. This page defines authority peer, the first of the two peer classes sync uses instead of random sampling.
An authority peer of a space is a peer that has authenticated as an account holding live write, admin or sync access over the space root, or that is the space's declared site; authority peers are where a space's blobs originate and where they are expected to be complete.
A space's content is written by its owner and its writers. Each of them runs one or more peers (a laptop, a phone, an agent server) that hold their key. The site that publishes the space holds a sync grant and is online. Those peers, together, are where every blob of the space first appears and where a complete copy is expected to live. A daemon that wants a space up to date asks them. It does not need to ask anyone else, and asking strangers would only leak which spaces it cares about.
How a peer becomes known as an authority peer
A peer is a connection identified by a libp2p key; it carries no account. It becomes an authority peer for a space on the local daemon in one of three ways:
It calls Authenticate on the local daemon as an account that the local authority graph shows holding write, admin or sync over the space root.
The local daemon connected to it as the space's site: the root's site.peer attribute names its peer id, and a live sync grant to the account the site peer authenticates as confirms the relationship.
The local daemon itself holds a key for such an account, in which case it is an authority peer for the space and other peers will treat it as one after it authenticates to them.
Peers of the owner's other devices are authority peers by rule 1 because the owner holds admin. An agent server holding a delegated write grant is an authority peer by rule 1. A reader is not: read does not make a peer authoritative, because a reader may hold a partial copy and has no duty to serve.
What authority peers are for
Sync for a scope reconciles with the space's reachable authority peers first and, for a follow or pin policy rule, keeps a Watch open on at least one of them.
A daemon that publishes a blob into a space offers it to the space's authority peers, so that the owner's devices and the site converge in seconds.
When a scope cannot be completed from authority peers, the daemon falls back to trusted peers, then to peers named in the policy rule, and stops. There is no sampling of unknown peers.
How a daemon finds the addresses of authority peers it has never met is routing, which Stem leaves as HM24 has it: the site's address from its site attribute, bootstrap gateways, and the peer table exchanged with ListPeers. Open: a provider record keyed by space, signed by an authority peer, so that a fresh install can find a space's site without a gateway.
Today (HM24)
The daemon has an "authority tier" made of the space's siteUrl host, found by an HTTPS lookup, and hard-coded gateway peers; after that it samples up to twenty connected and stored peers. The roadmap wants to narrow sync toward explicit trust relationships. Stem's authority peers are that narrowing, defined from the authority graph rather than from DNS.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime