Digital reputation is a fundamental issue in distributed systems. Operators of interconnected systems often rely on a soft reputation that is opaque and unverifiable. Systems such as Mastodon and the underlying [[ActivityPub]] protocol are a great example of a decentralized, trustful system. Matrix, a chat client, company, and protocol is another example. One issue both of these examples have are problems with identity. Matrix goes to great effort to make it easy to rotate encryption keys and maintain continuity of identity across many devices. This approach is admirable but not without flaws. Mastodon makes no such attempt: if your "home server" disappears overnight, not only is your account history such as posts and photos gone, but your identity is effectively dead as well. Meanwhile, centralized chat applications such as Discord, Facebook Messenger, WhatsApp and others do not have this problem. They're conceptually simpler systems (though in practice might be more complicated due to scale) and are easier for users to get started and continue to use their platforms. WhatsApp and Facebook Messenger even claim to have end-to-end encrypted chats, though the security and details of how this is implemented are opaque to the user. Regardless, the push towards privacy via encryption is a good one. But what happens if we want to build a decentralized, federated, system to replace both the mass group chat (Matrix and Discord) and personal group chat (Facebook Messenger and WhatsApp) use-cases while simultaneously allowing for an identity that is not tied to any particular server? Below, I propose a protocol that defines a mechanism for a distributed "web of trust" using arbitrary chains of `ed25519` based signatures and a distance algorithm that decays the further away an identity is from a known trusted entity and a trust score. # Signature Chains In all cases, signatures are made with `ed25519` keypairs. ## Level -1, the User Signature chains are a relatively compact means of distributed metadata about a chain of trust. The chain begins with the users identity key, a public `ed25519` key, an expiration for the signature, a sequence number, the public key of an authoritative server, a list of zero to 3 `x25519` public keys with which encrypted messages can be sent to the intended recipient, a list of zero to 3 `ed25519` public keys which delegated authority to sign messages, and a list of zero to 6 `ed25519` keypairs for trusted "peers". Additional arbitrary metadata may be included in an `extra` subfield. The `extra` field may contain any binary information but is constrained to no more than 1024 bytes. The protocol may require that the root also contain the blockhash from a proof-of-history based network such as Solana or Ambient as an additional security. These fields and accompanying signature are called the "root" of a signature chain and are append-only assertions ordered by the sequence number. Any entity wishing to utilize any data or metadata that is part of a signature chain must make a reasonable attempt to query the authoritative server for the most recent signature chain root. ## Level 0, the Authoritative Server The next level in the signature chain is made by an authoritative server. The public key of the signature **must** match the public key describe in the root's fields to be considered valid for any use. The server must provide methods for external entities to query the latest signature chain fora given root public key. The specifics of the API are documented elsewhere. The server **must** always return the latest known signature chain for a root public key. Previous signature chains can be queried, but the response must always include the latest (highest sequence number). Authoritative servers should have at a minimum 2 keypairs, but likely more, which up to 3 signature chains being used to sign root records. One keypair is the authoritative root and is typically stored offline in cold storage. It is responsible for signing one or more delegation assertions. These assertions contain the following fields: an expiration (typically long-lived, not more than 5 years), one or more public keys to which have delegated signing authority ### Signing Signature Chain Roots An authoritative server *should* make reasonable attempts to authenticate that a user currently holds control of the root keypair using out of band methods such as challenge-response with a nonce and HMAC signature, for example. The specifics are up to the implementation (should this be standardize?). Additional authentication schemes *may* be used. Once authenticated, an authoritative server should wrap the root record with it's own signed record containing: an expiration for the signature, the certificate chain for its own authority (described above), the entire root record in question, and a sequence number. A delegated signing keypair as described above *must* be used to sign signature chain roots. ## Peers A root record may contain zero or more peer public keys. The public keys within this field are intended to be level -1 root public keys associated with users. An entity that wishes to calculate a reputation score for a user and it's corresponding authoritative server does so by collecting valid certificate chains whose roots denote the target root identity as a peer. Certificate roots whose authoritative server is the authoritative server of the target user have zero affect on reputation for this purpose. Put another way: the resulting base reputation of a target identity is the count of identities that have the target declare as a peer whose authoritative server is not the authoritative server of the target. A per-authoritative server coefficient may be applied based on the personal preferences of the entity calculating the reputation.