Online, you are scattered. A handle here, a profile there, a domain somewhere else, and no built-in way for a stranger to know they all trace back to one person. That gap is where impersonation lives. Someone registers a lookalike handle, borrows your avatar, and there is no cryptographic fact anyone can point to that says which account is really you.
Keybase's insight, back in 2014, was to tie all those identities to a single cryptographic key by having you post signed proofs on each platform. It worked well and people trusted it. But the proofs and the verification ran through Keybase's servers, so when Zoom acquired the company in 2020, a tool built to reduce dependence on central parties turned out to depend on one after all. Keyoxide is the response: the same linking idea, rebuilt so there is no central service holding anything.
The core idea: bidirectional proof
Keyoxide works by establishing a two-way link between your cryptographic key and each account you claim. Neither direction alone is enough; both together are what make the claim verifiable.
In one direction, your key lists your accounts. An OpenPGP key can carry notations, small labeled annotations attached to the key. Keyoxide uses a notation named proof@ariadne.id whose value is a URL pointing at one of your accounts, say your Mastodon profile. Anyone who has your key can read that you claim that account.
In the other direction, the account points back at your key. You post something on that platform, a Mastodon post, a Gitea profile field, a DNS record on your domain, that contains your key's fingerprint or a statement referencing it. Now the account claims the key.
If only your key claimed the account, anyone could list any account they wanted. If only the account referenced a key, anyone could paste a fingerprint into a bio. The claim is trustworthy only when both ends agree: your key names the account, and the account names your key. An impostor would need to control both your key and the real account to forge that, which is the whole point.
The Ariadne Identity specification
The rules for how these proofs are formatted and checked are written down as an open specification called Ariadne Identity, named for the thread that led out of the labyrinth. It defines the notation format, how a verifier should fetch each side of a claim, and how to match them. Because the spec is open, Keyoxide is not the only thing that can verify a profile. Anyone can implement a verifier, and the official Keyoxide tools can be self-hosted or run from the command line rather than trusted as a service.
This is the structural difference from Keybase. The verification logic is a public algorithm operating on data that lives in your key and on the platforms. A Keyoxide instance that runs the check is a convenience, not an authority. If every Keyoxide server vanished tomorrow, your proofs would still be valid and still verifiable by any tool that implements the spec, because nothing essential was ever stored on those servers.
The proofs are not held by Keyoxide. They are held by your key and by the accounts themselves. A Keyoxide instance just reads what is already public and does the matching. That is what makes it survive the acquisition problem that ended Keybase's promise. The decentralization property, stated plainly
Beyond PGP: Ariadne Signature Profiles
Requiring an OpenPGP key was a barrier, because plenty of people who would benefit from identity proofs do not want to run the full PGP toolchain. Keyoxide added Ariadne Signature Profiles, or ASP, to address this. An ASP is a lighter-weight signed profile that carries the same kind of claims without demanding that the user adopt OpenPGP and all its key management. The signing still uses solid public-key cryptography, but the surrounding experience is simpler, which matters for a tool whose value grows with how many people actually use it.
How it compares to other identity models
| Model | Who verifies | Survives its company folding |
|---|---|---|
| Keybase | Keybase servers | Dependent on the company |
| Keyoxide | Any Ariadne-spec tool | Yes, proofs are self-hosted |
| Blue-check verification | The platform, at its discretion | Platform-controlled |
| Web of Trust | Other users' signatures | Yes, but hard to bootstrap |
The comparison worth dwelling on is the platform verification badge. When a social network puts a checkmark on an account, it is making a claim you cannot inspect and cannot reproduce. You trust the platform's process, whatever it is this year. Keyoxide inverts that: the proof is a public, mechanical check that you can run yourself, and it does not ask you to trust the goodwill or continued existence of any single organization. It sits in the same family as decentralized identifiers, approached from the practical direction of linking accounts people already have.
What Keyoxide does not solve
It is worth being clear about the boundary. Keyoxide proves that the same key controls a set of accounts. It does not prove that the key belongs to a particular real-world human, unless you already know that key is theirs. The link it establishes is between a key and its accounts, which is exactly the right tool for "is this the same person who runs the account I already trust," and the wrong tool for "is this person who they say they are in real life." Those remain different questions, and the second one always comes back to how you first established trust in the key.
There is also a practical dependency: verifying a claim means fetching the proof from each platform, so an account that gets deleted or a domain that lapses breaks that link. The system is only as durable as the accounts it points at. That is a reasonable property for what it is, but it means Keyoxide reflects your current identity graph rather than an immutable record of it.
Why this matters for how we think about trust
Identity verification that depends on a single company is verification on borrowed time, and Keybase is the case study. The value of a decentralization tool evaporates the moment a central party can be bought, coerced, or simply shut down. Keyoxide is a clean demonstration that you can get the useful property, verifiable links between your identities, without creating that single point of failure in the first place.
That principle runs through how we build Haven. Wherever a design lets a central party hold something they could be compelled to give up, that is a weakness waiting to be exploited, and the stronger choice is to arrange things so the sensitive part never sits with a party who can be pressured. For messages, that means end-to-end encryption so the service cannot read them. For identity, tools like Keyoxide show the same instinct applied to a different problem: put the proof where no one can quietly take it away.