Part 2: Your identity is not an account
Part 2 of a series introducing Mesaĝkesto, a protocol for secure messaging between self-certifying identifiers.
Recap
In Part 1 we argued that every identifier we use today is leased — a number from a telecommunication provider, an address inside someone's domain, a domain rented from a registry — and that the lease is the lock-in. The first of the three properties we said a platformless system needs was this:
Your identifier is created and controlled by you. Not assigned, not allocated, not looked up in anyone's table.
That sounds like a slogan. It isn't — it's a construction, it's about thirty years old in its essentials, and it's worth understanding because everything else in this series is downstream of it.
Identity vs Identifier
Identity is a complex topic, for the sake of this series we would define it as set of data attributes attached to you. Those attributes are collected over time, based on which you can build up who you are, your reputation and continuity in interaction with others. Analogically to analog world, attributes in form of the documents (ID card, passport, driving license) are linked to you via biometrics - a unique stable identifier, we need similar identifier in digital space. Identifier which only you can create and control. Upon this identifier you would be able to create your digital identity and bring your own identity with you allowing to create platformless ecosystems and freedom of movement in digital space.
The trick
Let’s start from what we need, because the interesting part is how impossible it sounds.
A name in digital space that is unique, that only its owner can act as — no company nor registry able to take it or speak in its voice — that stays stable for decades, and that anyone can verify without consulting an authority. That last one matters most: the moment verification means asking somebody, that somebody owns the name.
Uniqueness
The catch is that every mechanism we have for uniqueness is a coordinator — a numbering plan, a registry, a database with a unique index. Someone stands at the door writing names in a ledger, which is exactly how they come to own the ledger, and everything in Part 1 followed from that.
How can you be sure nobody else picks your name when there is nobody to ask for?
The way out is simple: make the pool of possible names so vast that nobody ever picks the same one twice — not merely improbable, but improbable on the scale of everyone who has ever lived choosing names for the lifetime of the universe without a single clash. Pick at random from a pool that big and you need no ledger at all. This is what entropy is used in cryptography.
That gets us uniqueness and nothing more, because anyone who sees a random string can copy it.
Verifiable
We need a name that is public — names are for sharing — while whatever makes it yours stays private. A public half and a private half, bound together, such that anyone can verify that link.
Which is what a keypair is. Invented for another purpose, it happens to be the missing shape: a private key nobody else has, and a public counterpart, unique in that enormous space, that anyone can use to confirm you hold the private half without ever seeing it. Your public key becomes the base for your identifier.
That's it. No registration, no lookup, no permission, no fee. You made a name that nobody issued to you, that nobody else will ever hold, and that has a property no leased name has: it proves itself. If I have your identifier and you sign something, I can check the signature against the key the identifier is derived from and know it was you — without asking a company, a registry, or a certificate authority whether this is really you. That's what "self-certifying" means.
Compare that to how verification works today. When you check that an email really came from a colleague, or that a website is really your bank, you are ultimately trusting a chain of organisations: a certificate authority, a registrar, a mail provider, a numbering authority. They are mostly competent and mostly honest, and they are also exactly the parties who can take your name away, reprice it, or hand it to a court. Self-certifying identifiers remove them from the loop — not because those organisations are bad, but because you shouldn't need to trust anyone to know who you're talking to.
Stable over time
If your name is your key, what happens when your key is compromised?
For a naive self-certifying identifier, the answer is: you're finished. Your name is that key. Rotating to a new key means becoming a new person — telling everyone you know, losing everything linked to the old name (good old GPG). We've just rebuilt the disaster from Part 1 with a different landlord, namely entropy.
Real systems can't work that way. Keys leak. Phones are stolen. Algorithms weaken. Any identity meant to last decades must survive its own keys.
The resolution is to stop thinking of an identifier as a key and start thinking of it as the beginning of a history.
The log
To solve the problem of stability we need to abstract your identifier from the keys, keeping the cryptographic relationship so it stays verifiable. To accomplished that Your identifier is derived from your first keys and “meta data” — we call it the inception of your identity. From then on, every change to your keys is another event, appended to an append-only, signed record: a key event log (KEL).
Each event is signed by the keys that the previous event established. So the log is self-verifying end to end: start from the inception event, walk forward, check each signature with the keys the previous entry named, and you arrive at the current state — these are the keys that control this identity today. Anyone can do this. It needs no authority, only the log which is end-to-end verifiable.
Your name is now the first link in a chain, not a key. Keys come and go underneath it; the name is stable across all of them. Rotation stops being an identity-ending event and becomes routine maintenance. The logs keeps track what is the current state of your identifier (which keys are the latest).
Pre-rotation, or: surviving a theft
There's a subtlety here that is the single cleverest part of the design, and it's worth slowing down for. If rotation is just "sign a new event with your current key naming a new key", then an attacker who steals your current key can rotate you out — sign an event installing their key, and now the log says they control your identity. Verification would be perfectly correct and completely useless. So rotation is committed to in advance. When you create your identity you also generate the next key and record only its hash in the inception event. The future key itself never touches the network, never sits on the device you use daily, and can live in cold storage. When you rotate, you reveal the key that matches the committed hash and commit to a further one.
Now consider the thief. They have your current signing key — they can sign messages as you, which is bad. But they cannot rotate, because a valid rotation must reveal a key matching a hash that was published before they arrived, and they don't have it. You, however, do. You rotate to your pre-committed key, the log records it, and every verifier who reads the log learns that the stolen key is no longer authoritative — including retroactively, for anything signed after that point.
Compromise becomes recoverable without losing your name. No other identity system in everyday use gives you that. Lose control of a domain or a phone number and the recovery process is a support ticket and a plea. Here it's a signed event you can produce yourself.
A bit of infrastructure
Self-certifying identifiers comes with a cost, since you are creating them on your own device we have to deal with the problems which normaly platforms are taking care of, mainly: accessibility and duplicity detection.
Accessibility
When we replace a fixed public key with a changeable log of keys (the KEL), we create a new challenge: how does everyone always have access to the latest version of that log?
Think of it like this: your identifier is now your "name," but the keys you use to sign messages can change over time—like updating your password. If someone needs to verify that a message really came from you, they need to check your current key. But if your key just changed, they need to see that change before they can trust your new signature.
This means your log—the complete history of all your key changes—must be always available to anyone who wants to verify you. Whether it's a friend, a bank, or a business partner, they all need to be able to access your up‑to‑date KEL at any moment.
This is where the propagation infrastructure comes in—it's the system that makes your KEL available to everyone who needs it. But here's the key point: you don't have to trust this infrastructure.
Why? Because your KEL is end‑to‑end verifiable. That means when someone receives your log, they don't just take it at face value. Instead, they verify it on their own machine—checking the cryptographic signatures, the hash chain, and the entire history themselves.
So the infrastructure's only job is accessibility, not authority. It's like a library that holds books: you don't trust the library to tell you what's true; you trust the content of the book itself. The library just makes sure the book is there when you want to read it. Similarly, the propagation infrastructure just makes sure your KEL is available—but the final verification always happens locally, on the verifier's own device.
Duplicity detection
So what happens if someone tries to cheat—showing one version of their key history to you and a different one to someone else? That's where watchers come in.
Watchers are independent observers that constantly watch and store copies of everyone's key logs with whom you are interacting. They don't have to be trusted—they just need to be there. If a controller tries to be duplicitous, different watchers will see different versions of the log. When you go to verify someone, you can check with multiple watchers. If their stories don't match, you've caught the cheat.
The watchers' job isn't to decide what's true—it's simply to collect and show you the evidence. Because every event is cryptographically signed, the controller can't deny having created both versions. The proof is undeniable. The watchers just make sure you can find it.
Trust hasn't disappeared here — it has changed shape. Instead of trusting an organisation that grants you your name and can revoke it, you rely on a set of observers whose job is only to say "yes, I saw this, and I saw nothing conflicting" — chosen by you, replaceable by you, and unable to speak for you.
Finding someone
A verifiable log is only useful if you can get hold of it. This is discovery, and the important thing about it is how little it is. Discovery in this world is an OOBI — an out-of-band introduction — which is nothing more than a hint: this identifier's log can probably be fetched over there. A URL, a QR code, a line in a chat. What matters is what it is not. It is not authoritative. Nobody has to vouch for the hint's honesty, because whatever you fetch is verified against the identifier you already have — if the log doesn't check out, or doesn't lead to the identifier you were told about, you discard it and nothing is lost. A hostile hint gets you a useless download, not a wrong answer. That inverts the usual arrangement. DNS answers are trusted because of where they came from; a signed log is trusted because of what it is, so the place it came from doesn't need to be trusted at all. Discovery becomes a convenience layer, and convenience layers are easy to replace, mirror and run redundantly — precisely because nothing depends on their integrity.
And yes, first contact still needs a real-world moment: someone scans a code, clicks a link, reads a fingerprint aloud. That isn't a shortcoming, it's inherent — you exchange phone numbers the same way, and unlike a phone number, what you exchange here can't be reassigned to a stranger later.
What this buys us for messaging
Now to the point of the series. Three consequences follow directly. Your provider is an entry in your log. Alongside your keys, your log can publish roles: statements like this identifier hosts my message box, signed by you. That's how a sender's box learns where to deliver. Read that sentence again with Part 1 in mind — the pointer to your provider is a signed line in a record you control, and moving to another box is a new signed line. Your correspondents don't need to be told; they resolve your log and find the current answer. Nobody has to run a forwarding service, because nothing about your name ever mentioned the old box.
In pratical world to hold an identifier you need a hardware, place to store it and use it, this is done through your devices like laptop and phones. But Your devices are not you. A laptop and a phone shouldn't share one signing key, but they also shouldn't be two unrelated identities. Delegation solves it: your identity delegates a child identifier to each device, with its own keys and its own log, verifiably subordinate to yours. Lose the phone and you revoke one delegate. Your name is untouched, your other devices are untouched, and your contacts see a routine event rather than a catastrophe.
What's hard about this
The names are ugly. A hash isn't ewa@example.com, and it never will be. Human-meaningful naming belongs at the edge, in your own address book — you label an identifier "Ewa" the way you label a phone number, locally, under your own control. It's a genuine UX problem, and it's a much better problem to have than a global namespace someone owns.
Key loss is still serious. Rotation saves you from theft; it doesn't save you from losing every key and every pre-committed key at once. Delegation, multi-signature control and social recovery all help, and none of them is a solved, friendly, everyday experience yet.
Availability isn't free. Witnesses and discovery have to actually be running for verification and first contact to work smoothly. The failure mode is degraded rather than catastrophic — a stale view, not a stolen name — but it's real infrastructure, and infrastructure that someone has to operate.
Where this leaves us
We now have names nobody issued, that survive compromise, that carry their own proof, and that publish — in a record you control — where to reach you. Which means we can finally ask the question this series is actually about: what does a box have to do, if the identity does all this work? The answer turns out to be gratifyingly little.
Next: The Mesaĝkesto — signed envelopes, strict ordering, and why "give me everything after number N" is a better foundation than any acknowledgement protocol.
