Digital reputation is a fundamental issue in decentralized 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` key pairs. ## User Entities 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. ## Authoritative Servers 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. ## Reputation "Source Authority" means the entity that is calculating a reputation score for the target entity. It is typically an authoritative server. "Intermediate Authority" means an authoritative server that is neither the source authority nor the target authority but may be used to provide a relative reputation score of a target authority for the source authority. There may be many intermediate authorities involved in calculating a particular reputation score. "Target authority" is the entity that is having its reputation calculated. It is typically an authoritative server. "Owned User" is a user entity (as described above) whose authoritative server is set to the subject authoritative server such that the user could be said to be "owned by the authoritative server". Reputation does not generally apply to individual accounts. Further, it is intended to be unstable and *relative* to the entity calculating the reputation. When an entity, typically an authoritative server, wants to calculate the reputation for another entity they take the *count* of peers of the source authority's owned users whose authoritative server is the target authority and add **half** of *the largest* reputation score provided by known authoritative server peers of the source authority. When a source authority requests the reputation score for the target authority, the algorithm is applied recursively. A source authority may apply it's own modifiers to intermediate reputation records when calculating a reputation. This allow These reputation scores are communicated using signature chains called "reputation chains" similar to the user signature chains describe above, but instead of containing information describing the relationship between a user, it's peers, and its choice authoritative server, it instead contains signed payloads showing the computation performed to calculate a particular reputation score. An individual reputation chain record contains the score, the number of users participating in the score, an expiration (which is the lowest expiration of all signatures in the chain, including user signature chains), a signed modifier scalar, the reputation chain record (if any) contributing to the reputation score of this record, and is signed by a signing key of the source authoritative server. This data structure is recursive, containing contributing sub-records. ### Expiration These reputation chains expire fairly quickly, as they are only considered valid for as long as all of their contributing records are valid. In some cases they may expire before the source authority is able to fully calculate the resulting reputation. Because of this, records expiration must have a minimum expiration time of 1 hour into the future from when the record was created. Expired records *may* be used from a source authority as a prior to prioritize recalculating a reputation score, but should not be provided to other authorities when expired. Because some values may be stale (N hours where N is the "depth" of the signature chain), reputation scores are a not a concrete, definitive value at any given point in time. ### Overriding Reputation Authoritative servers are not all expected to be good actors. Some servers may facilitate spam and other forms of abuse that require subjective moderation. Any authoritative server may chose to add a penalty or bonus for another authoritative server. These bonuses and penalties are public and reflected in reputation chains shared with 3rd party authoritative servers and are very likely to influence reputation of a node. To mitigate abuse, the source authority may apply their own modifiers to intermediate records to change the effective reputation (and "sub reputation") of a node, which is likely to result in a different "path" and resulting reputation score. The idea here is to loosely model the real organic trust graphs that underpin online interactions. How an authoritative server utilizes a reputation score is entirely up to the controlling entity (sysadmin, company, etc.), but in most cases even inattentive authoritative servers should have passive abuse mitigation through the mechanisms provided. Cliques are likely to form, and that's ok. ## Additional APIs An authoritative server must provide the following APIs: - Query all known peer authoritative servers and their reputations - Query all peer authoritative servers with manual reputation scalars set by *this* server An authoritative server may provide the following APIs: - Query user records peer lists that contribute to a reputation score