How it works (no jargon)

1. You have two keys

Imagine a lock and a key. The lock you bolt to the front door of your house — anyone can walk up and look at it. The key you keep in your pocket — only you can open the lock with it.

Public-key cryptography works exactly the opposite way: the public key is the lock (visible to everyone), and the private key is the only thing that can produce a signature the public key recognises.

2. Your domain is the lobby

The public key has to live somewhere people can find it. We publish ours at:

https://born.engineer/.well-known/did.json

That's it. Any verifier in the world makes one HTTP request to that URL, reads the public key, and can now verify anything you've signed. The W3C calls this format did:web — "the identity that lives on the web at this domain".

3. Signing

When you sign a post, three things happen behind the scenes:

1. The post is hashed — a fingerprint is produced that changes if a single character changes.
2. That hash, plus a timestamp and your identity, are wrapped into a small message.
3. Your private key produces a signature of that message.

The signature is short — about 90 characters — and gets pasted into the block under your post.

4. Verifying

When someone runs the post through a verifier:

1. The verifier fetches your public key from the DID document.
2. It recomputes the hash of the post.
3. It runs the signature, the recomputed hash, and the public key through the verification math.

If anything changed — one comma, one word, the timestamp — the math fails. There's no in-between. It's the same Ed25519 algorithm used to secure your SSH connections and your phone's app store updates.

5. Key rotation

Worried about losing the key? The DID document supports listing more than one. When you rotate, you add a new key and keep the old one listed for a while — old signatures stay verifiable, new ones use the new key.

That's the whole system. A domain, a key, a few bytes of math. Everything else is product polish on top.