- Use the same identity across applications.
- Give your work a verifiable history.
- Let collaborators or software act within permissions you grant, without your keys.
A DFOS identity begins with a signed record, not a registration in a central directory. Its did:dfosidentifier is derived from that first operation, and it stays the same as the identity's keys and services change. Every later key proves possession of itself, bound to its role and its position in the chain.
An application verifies a sign-in against that signed history rather than against an account at one host. A domain you control can point to the identity, with a matching claim recorded on the identity itself.
A signed content record names its document by cryptographic hash. Anyone holding the record and the identity history it references can check who signed it without opening the document.
A reader who does receive the document can check that the bytes match the commitment. Those are two separate results: signed attribution is one check, document integrity is another.
A document can be public or served only to selected readers, and distributing its signed record does not require distributing its contents. The protocol commits to a document by hash. It does not encrypt, and whoever serves a document can read it.
Give a collaborator permission to update one content chain. Give an application access to one resource. A permission is a signed credential naming the identity it authorizes, and for credential-gated API calls that party proves possession of its own key and binds the proof to the particular request.
Delegation is linear and narrowing: each hop can drop resources, drop actions, and shorten expiry, and it can never widen what it was given. A credential expires at the time it names and can be revoked before then, and a verifier enforces a revocation once it holds it.
Create identities, sign records, and verify them on your own machine. The CLI signs and stores operations locally, and publishing to a relay is a separate, explicit step. A relay is HTTP storage and exchange for signed records, with optional document hosting, and anyone can run one. You do not need an account on the DFOS platform to begin.Full documentation.
curl -sSL https://protocol.dfos.com/install.sh | shAlso available viabrew install metalabel/tap/dfosanddocker pull ghcr.io/metalabel/dfos
# create the seed your keys derive from, and write the phrase down
dfos vault create personal
# create your identity — one key, minted from that vault
dfos identity create --name myname
# sign your first record — every signing command names the identity it acts as
echo '{"$schema":"https://schemas.dfos.com/post/v1","format":"short-post","body":"gm"}' | dfos --as myname content create -
# tired of typing it: set the standing default
dfos config set default-identity myname
# see it
dfos content list
# re-verify the chain, locally
dfos content verify <contentId>
Verification answers who signed a record and whether a document matches its commitment. It does not establish that a signed claim is true: the chain shows what was signed, never who was at the keyboard.
The protocol does not encrypt documents, and a relay operator reads every blob it stores. Nothing obliges a relay to keep your chain. An identity chain is linear per view, nothing arbitrates between relays that admitted different successors, and which relay you read is which view you get.
The DFOS platform holds a signing key for your account by default, so ordinary use needs no key management, and you can add keys it never holds. Keep your own copies of your chain and your documents.
Verification implementations in five languages, checked against the same deterministic test vectors. The protocol specificationis the single source of truth.
R E A D T H E P R O T O C O LCoredid:dfos — self-certifying, transport-agnostic identifiersCredentialsDelegated authorization, revocation, standing access, and attenuationContent ModelJSON Schema content types committed via content-addressed CIDs