User:Baldemoto/sandbox
Design
| ← Previous revision | Revision as of 04:46, 19 April 2026 | ||
| Line 23: | Line 23: | ||
The decoupling of hosting, aggregation, and indexing rests on two properties of the data itself. First, each record is cryptographically attested: records are incorporated into the repository's Merkle search tree, a hash-addressed tree whose keys are maintained in sorted order. The tree's root content identifier (CID) is included in a commit signed by the account's signing key, whose public half is published in the account's DID document. Second, the repository is content-addressed: each record is named by the cryptographic hash of its contents, and the tree's root hash is a deterministic function of the records it contains. |
The decoupling of hosting, aggregation, and indexing rests on two properties of the data itself. First, each record is cryptographically attested: records are incorporated into the repository's Merkle search tree, a hash-addressed tree whose keys are maintained in sorted order. The tree's root content identifier (CID) is included in a commit signed by the account's signing key, whose public half is published in the account's DID document. Second, the repository is content-addressed: each record is named by the cryptographic hash of its contents, and the tree's root hash is a deterministic function of the records it contains. |
||
Together, these properties mean that any service that receives a record, together with its inclusion proof and the signed commit, can verify the record was authored by the claimed account without trusting the service that delivered it. Any two servers holding the same set of records compute the same root hash and can be verified against the same commit signature. |
Together, these properties mean that any service that receives a record, together with its inclusion proof and the signed commit, can verify the record was authored by the claimed account without trusting the service that delivered it. Any two servers holding the same set of records compute the same root hash and can be verified against the same commit signature. Functionally, this means anyone who replicates a user's repository holds data of equivalent cryptographic validity to what the user's PDS itself holds, and an account's identity can be migrated to a new host without compromising the continuity of previously published content. |
||
These properties are visible in the structure of records themselves. A record retrieved from a PDS, encoded in JSON, has the following form: |
These properties are visible in the structure of records themselves. A record retrieved from a PDS, encoded in JSON, has the following form: |
||
