Here’s a document explaining how the Quanta platform is currently implementing it’s experimental Decentralized Identity feature. This approach not only does the identity use case but also offers a suggested way of using MFS to do data sharing, publishing, and even what you might call Darkweb and Web3 generalized storage, for publishing micro-blogs, posts, documents, wikis, etc.
This is compatible with Fediverse/ActivityPub, but not limited nor specific to Fediverse at all.
BlueSky team has (purely by coincidence) adopted these very same concepts…
This file has been truncated.
# Authenticated Data eXperiment (ADX) Overview
Bluesky is building a protocol for large-scale distributed social applications. We want public discourse to occur on open infrastructure which gives users a choice in their experience, creators control over their relationships with their audience, and developers freedom to innovate without permission from a platform.
We're calling what we’re putting out the Authenticated Data eXperiment, or _ADX_. It’s an "experiment" at this stage because the protocol is actively under development and will evolve as our understanding improves. All documentation and code is a working prototype and should be considered unstable.
The core of ADX is [self-authenticating data](https://blueskyweb.xyz/blog/3-6-2022-a-self-authenticating-social-protocol). In law, a [“self-authenticating” document](https://www.law.cornell.edu/rules/fre/rule_902) requires no extrinsic evidence of authenticity. In computer science, an [“authenticated data structure”](https://www.cs.umd.edu/~mwh/papers/gpads.pdf) can have its operations independently verified. When resources in a network can attest to their own authenticity, then that data is inherently _live_ – that is, canonical and transactable – no matter where it is located. This is a departure from the connection-centric model of the Web, where information is host-certified and therefore becomes _dead_ when it is no longer hosted by its original service. Self-authenticating data moves authority to the user and therefore preserves the liveness of data across every hosting service.
This document is a working summary of the protocol’s development which describes the various techniques and components involved.
### Understanding the protocol
ADX demonstrates two core components of self-authentication: [cryptographic identifiers](https://en.wikipedia.org/wiki/Public-key_cryptography) and [content-addressed data](https://en.wikipedia.org/wiki/Content-addressable_storage). We've built ADX using existing tools and standards when possible, including [IPLD](https://ipld.io/), [DIDs](https://w3c.github.io/did-core/), and [UCANs](https://fission.codes/blog/auth-without-backend/).
_Cryptographic identifiers_ associate users with public keys. [Self-sovereign identity](https://en.wikipedia.org/wiki/Self-sovereign_identity) is based on having cryptographic identifiers for users. Control of an account is proved by a cryptographic signature from a user, rather than an entry in a database keeping track of logins.
_Content-addressed data_ means content is referenced by its cryptographic hash — the unique digital “fingerprint” of a piece of data. Using public keys and content-addresses, we can sign content by the user's key to prove they created it. Authenticated data enables trust to reside in the data itself, not in where you found it, allowing apps to move away from client-server architectures. This creates “user-generated authority”.