Frequently Asked Questions
What is the DFOS Protocol?
An open protocol for identities, signed records, and delegated permissions that any compatible application can verify for itself. Signed chains establish identity, commit documents, and produce proofs anyone can verify offline, in any language, from any source. Authorship is verifiable without trusting any server. Which view of an identity you follow is a choice of relay.
Who holds my keys?
On the DFOS platform, the platform holds a signing key for your account by default. You can add keys it never holds, from Settings. The platform's default key is a controller key: it can change the key set, and every change is written to the chain where anyone can see it. Nothing the platform does can forge a signature from a key it does not hold. Guarantees states what custody buys and what it does not.
What happens if the platform I use goes away?
Your identity chain and every proof in it are public and can be mirrored by anyone. With a controller key you hold, you continue the chain on another relay from the last operation that key controlled. Documents do not replicate with the proofs, and proofs survive only where a copy was kept: keep your own copies of your chain and your documents. Guarantees states the bounds of that continuity.
How do chains handle forks and conflicts?
It depends on the chain kind, and forks are permitted exactly where a merge function exists. Content chains are DAGs that converge to the same head deterministically on every implementation, with no consensus protocol. An identity chain is linear per view: a relay admits the first successor it sees at a position and refuses later ones rather than arbitrating between them, so two relays can serve two views of one identity. The Protocol Specification defines the convergence rule and the view model, and Relay defines relay admission.
How does the relay network work?
A relay stores and serves chains and verifies every operation it admits. It keeps each identity's log linear by admitting the first successor it sees. Two relays that admitted different operations hold two views of the same identity, and which relay you read is which view you get. Peers exchange logs; nothing arbitrates between them. The Relay specification defines the routes, the admission rules, and the profiles a relay may serve.
Do I need to run a server or connect to a network?
No. Verification is offline and self-contained. A signed chain carries everything needed to verify it: public keys, signatures, content-addressed hashes. There is no registry to query, no blockchain to sync, no API to call. A verifier needs standard cryptographic components — an Ed25519 implementation, a dag-cbor encoder, and SHA-256 — plus the identifier derivation and the chain rules, and no DFOS software. Relays are useful for storage and distribution, and recovery is the one operation that needs one: recovering the identities a seed phrase controls asks a relay's key index which identities each derived key has been proved into.
What languages are supported?
The reference implementation is in TypeScript (available as @metalabel/dfos-protocol on npm). Cross-language verification implementations exist in Go, Python, Rust, and Swift, all verifying the same deterministic test vectors from the protocol specification. The CLI is written in Go with pre-built binaries for Linux, macOS, and Windows (x64 and arm64), installable via Homebrew, curl, or Docker.
How do identity chains relate to DIDs?
Every identity chain is also a DID. The DID (did:dfos:<hash>) is derived deterministically from the hash of the chain's genesis operation, which is what makes it self-certifying. Given the chain, anyone can verify that it belongs to the claimed DID without trusting the source. The DID method specification defines how did:dfos identifiers conform to the W3C DID standard.
Can a third-party application log people in with their DFOS identity?
Yes. That is Sign In With DFOS: the application mints a challenge, a key from the user's identity chain signs it, and the application verifies the signature against the chain resolved from any relay, which is pure cryptography with no DFOS server in that check. The signing side is a hosted authorization server: the application sends the person to the authorize endpoint their identity names, and that host signs the challenge with the key it holds for them. Scopes that return a credential add a second, explicitly server-side surface, where the credential gates requests to the issuing platform's API. The Integrations specification defines the challenge, the authorize path, the verification rules, and the gated-request side.
Can an application call a DFOS API on the user's behalf?
Yes, with a credential issued at Sign In With DFOS consent and a per-request proof of possession signed by the application's own key. A captured credential is useless as a bearer token, and the resource form api:<host> lets any deployment gate itself the same way. API authentication defines the proof envelope and the verification algorithm.
Is the protocol coupled to the DFOS platform?
No. The protocol is independent. DFOS (the platform) is one implementation, but any system that implements the same chain primitives produces interoperable, cross-verifiable proofs. An identity created on one system can sign content on another. The protocol is MIT-licensed open source.
How do I inspect a chain without installing anything?
explore.dfos.com is a chain explorer that runs entirely in the browser tab. Every operation it displays is re-verified client-side, with CIDs re-derived, signatures re-checked, and the chain re-folded, so the signatures and the commitments over the bytes a relay served are proved by your own browser rather than asserted. Which view is current is still the relay's: the head, the effective keys, and whether an identity is deleted are what the relay you read serves. The explorer is MIT-licensed and in this repository; it is deployed rather than published to npm.
What do I use to read and verify chains from my own application?
@metalabel/dfos-client, the client-side kit for participating in the protocol (resolve, verify, prove) over an untrusted set of relays, with every cryptographic proof coming from @metalabel/dfos-protocol. It holds no keys: signing is always a callback the caller supplies. Its /siwd subpath carries the relying-party login kit, and its /api-auth subpath signs and verifies the per-request proofs for credential-gated APIs.
Where can I discuss the protocol?
The specification is open source on GitHub. Protocol discussion happens in the DFOS space.