DFOS beyond DFOS: sign-in, domains, and your own keys
SEPTEMBER 4TH, 2026
Platforms today make your identity real by hosting it. Your @ is real because it appears on their domain. Your work is real because their page says it is. Both remain true only while the platform exists and chooses to keep saying so, and the cost of that dependence tends to rise over time.
DFOS is built around a different split.
The platform is where convenience lives: sign-in, the app, the store, chat, and everything that should feel effortless.
The protocol is where continuity lives: who you are and what you made, represented as signed records anyone can independently verify without treating DFOS as the final authority.
This week, that split became concrete in three ways:
- Use your DFOS identity to sign in elsewhere
- Bind it to a domain you control
- Add keys DFOS never possesses, including an exit key designed to let the same identity continue beyond DFOS
DFOS currently holds the default platform key for your account, so ordinary use doesn’t require key management. That custody is a convenience layer, not a permanent dependency. Control can move progressively into your hands.
The aim is simple: DFOS should be useful without being indispensable.
No platform, including this one, should be the thing that makes you or your work real.
The DFOS Protocol
The DFOS platform—this app, the store, chat, and everything around them—implements an open-source protocol built around three goals:
- Your identity should remain meaningful without the DFOS cloud
- Signed attribution should be independently verifiable, by anyone, without asking us
- Public verification should not require publishing the underlying private content
The protocol works over ordinary, even untrusted, web servers using established open standards.
Your identity, posts, and releases are represented as signed records. A server can disappear, withhold a record, or fall behind. What it cannot do is make a rewritten or falsely attributed record pass verification. Anyone can retain, mirror, and re-serve the signed history without becoming an authority over it.
The server is a carrier, not the authority. The proof travels with the work instead of remaining trapped inside a platform database.
What’s live today:
- Every account, space, and group has a permanent protocol identity
- Your public posts carry independently verifiable authorship signatures
- A read-only view of the protocol is served by relay.dfos.com, and anyone can run their own relay
- explore.dfos.com resolves those records and reruns every check directly in your browser
Here is my DID, and here is the identity for the DFOS HOME space.
Sign in with DFOS
Sell access on DFOS. Honor it anywhere.
Sign in with DFOS, or SIWD, lets an external site or application connect to your DFOS identity and, with your approval, selected information about your spaces and groups.
The interaction is familiar: click a button, see who is asking and what they want, then approve or decline—but what happens underneath is a bit different.
For identity-only sign-in, the site receives a challenge signed by a key on your identity chain. It verifies that proof against the chain instead of relying on an account assertion only DFOS can validate. You’re proving that you control a particular DID.
Private information is a separate layer. A site can request things like your email address or space and group memberships, but those scopes are shown clearly on the consent screen and disclosed only after you approve. Identity proofs can be independently verified; private attributes stay private and are shared selectively through scoped, revocable credentials.
The developer guide walks through the complete integration, and the SIWD specification is the normative version.
You can also try the demo site. Its source is a complete working integration. Tech Itch and Vinny already have SIWD running on their own sites.
Verified domains
If you control a web domain, you can now bind it to your DFOS identity or to the identity of a space.
For your account, this lives under Settings → Verified domain. For a space, it’s under Studio → DFOS Protocol.
The binding works in both directions:
- Your identity chain claims the domain
- The domain answers back through a DNS TXT record or a well-known file
Together, those records establish common control of the DID and the domain, checkable by anyone, without DFOS acting as the authority between them.
Your domain becomes an external, independently resolvable name for your protocol identity, and your identity can prove its relationship to a place on the web you already control.
Live today:
- dfos.com speaks for the DFOS HOME space
- bvalosek.com speaks for me
- techitch.com and robertl.in have bound theirs
- A handful of spaces have connected their own domains over the last few days
Your own keys
You can now add two kinds of user-controlled keys to your identity from Settings → DFOS Protocol.
A signing key is a key you hold that can sign you in and sign records as your identity. It lets you act as yourself without relying exclusively on the platform-held key, but cannot change the identity itself.
An exit key is a controller key held only by you. It is designed so that the same identity and its existing history can continue under your control beyond DFOS. DFOS does not possess the key and cannot use it.
An exit key does not write to the DFOS-projected chain. It is a precommitted right of continuation rather than a one-click migration: the key is on your chain now, and the door is built before anyone needs to walk through it.
Most people don’t need an exit key in day-to-day use. It’s an advanced continuity mechanism for anyone who wants to ensure their identity remains usable independently of DFOS.
It is only useful if you still have it when you need it, so store it somewhere you could reach after losing access to your DFOS account—and verify that you can actually recover it before treating it as safe. The keys and recovery reference covers custody and recovery testing.
Open-source ecosystem
A lot also landed in the open-source DFOS repository: BIP-39 local vaults and recovery, user-controlled key management and signing, a new typed API client, a complete SIWD reference integration, and continued work across the relay, Explorer, specifications, and developer tooling.
The core protocol is frozen at v1. SIWD, origin binding, and the reference toolchain iterate on their own tracks.
The idea behind all of this is simple: convenience without captivity.
DFOS can host the interface, mediate transactions, make coordination easy, and provide the product experience around your work. It shouldn’t remain the final authority over whether you exist, what you made, or whether your history is still valid.
The Developers channel is the best place to talk through the protocol, ask questions, or get oriented if you’re considering an integration.
See y’all around on DFOS and the protocol ✌️
