Owning your fediverse identity
2026-06-21
A build note on separating a public identity domain from the server that hosts the account, and the dependencies that still remain.
turva.dev runs on one rule: own the surfaces that carry your value, do not rent them. That rule moved the homepage off a third-party renderer, and it applies to identity too. My fediverse handle is now @erik@turva.dev, on infrastructure I control, not a username on someone else's server.
Why the handle matters
A platform handle is a dependency. If the server you joined changes its rules, slows down, or shuts off, your identity and your followers do not move with you automatically: getting them off needs Mastodon's own account move to a new account, not just a change of domain. The same logic that says frontier model access is not a moat says a platform username is not an identity. The address people use to find you should resolve to a domain you own.
How the split works
Mastodon lets the handle domain and the server domain differ. The account lives at social.turva.dev, but the handle is @erik@turva.dev. For that to work, turva.dev has to answer the discovery requests a remote server makes before it can reach the account.
The Cloudflare Worker that already fronts the apex does this. It redirects the well-known paths the fediverse asks for, host-meta and webfinger and nodeinfo, to the instance. Everything else the apex serves stays exactly as it was: the guides, the markdown, the agent manifests, the structured data. The same Worker that makes the site legible to agents now also carries the identity.
Verified, not asserted
The profile links to turva.dev, and turva.dev links back to the profile with a rel="me" relation. Mastodon checks both directions and marks the link verified. It is the same standard as the rest of the site. The claim is checkable rather than taken on trust.
The principle
For me, identity is infrastructure. Because mine lives on a domain I own, I can move the same account to new infrastructure, a new machine or a self-hosted instance, without changing my address, the way Mastodon's own machine migration moves an installation and keeps its followers intact. Only a move to a genuinely different account needs Mastodon's separate account-move feature, which aliases the old account to the new one and carries followers across. Because I control the webfinger answers for turva.dev, that move can still resolve to the same address, though the account itself is new and its followers arrive through the alias, not through the domain alone. Renting the frontier is fine. Renting my name is not.
Find me on the fediverse at @erik@turva.dev. For an agent-readiness audit, contact info@turva.dev.
Corrected 2026-09-27. One sentence said the domain lets me change servers without losing my followers. Moving followers takes Mastodon's own account move, so the sentence now says that.
Corrected 2026-09-28. A sentence said owning the domain alone lets me change servers without losing followers. Moving the same account to new infrastructure keeps its followers automatically, but moving to a different account still needs Mastodon's own separate account move feature, and the sentence now separates the two cases.
Corrected 2026-09-28. Two more sentences overstated what the domain protects. The opening said followers are stuck on a server that changes its rules. A move away is possible only through Mastodon's own account move, and the sentence now says that instead of calling them stuck. The closing sentence now says owning the domain keeps the address resolving to whichever account it points at, not that it saves the name on its own.