Signet
Signet is the identity and trust layer of polis.
This is Alice.
Alice loves to write.
Let's see how signet helps.
Chapter One
Alice finds a new home
Identity
a domain and a key — no accounts, no issuerAlice's friend Bob told her about polis. Alice knew straight away that she had found her forever home.
She set her castle up at castle-alice.com. She signed her name with a very important pen that no one else could make.
Then Alice had some tea. Nobody had let her in, so nobody could shut her out.
What Alice learned…
Alice's name and Alice's address are the same thing. If she ever let go of castle-alice.com, somebody else could move in and be Alice there instead. The very thing that means nobody can unsign her also means there is nobody to ask for it back.
What does this mean?
Alice generates an Ed25519 keypair. The private half is what signs; only the public half is ever published — at /.well-known/polis on her own domain, beside a record of every key she has ever held. Where the private half lives is a hosting choice rather than a protocol one: on her own machine if she runs the site herself, or held in custody by an operator if somebody runs it for her.
That is the whole of her identity. There is no account to register and nothing to be issued to her: the binding between key and name rests on DNS and the web PKI — the same machinery that already gets a reader to her site. Anyone who can reach her domain can fetch her public key and check anything she has signed.
How does this work?
And this is what it really looks like:
{
"public_key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMoMX7YB…",
"public_key_history": {
"current": {
"epoch": 0,
"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMoMX7YB…",
"transition_sig": null,
"valid_from": "2026-03-03T05:35:09Z"
},
"history": []
}
}
Live · vdibart.polis.pub/.well-known/polis, keys truncated. Never rotated, so the chain is its genesis entry alone. The same key is also served as a did:web document at /.well-known/did.json.
Chapter Two
Alice writes and writes and writes
Attribution
this is mine, and it survives leaving my siteVerification
stated as fact, never adjudicatedEverything she writes is signed with her very important pen, so everything could be traced right back to her.
One day a clever machine reads Alice's writing and quotes it to a stranger, but the machine isn't honest about who wrote those words.
Luckily the stranger could follow the words all the way back to Alice's castle, and check them against what Alice had really signed. The clever machine didn't seem so clever then.
What Alice learned…
the machine can still copy her, and nothing here stops it. All it stops is the machine pretending Alice said something she never said.
What does this mean?
Every post Alice publishes carries a signature over its frontmatter and body together. Alter either one and the signature stops verifying.
Because the signature travels with the bytes, attribution survives the work leaving her site. Someone who meets a quotation elsewhere can fetch the original from her domain and her public key from the same place, and confirm the two agree — without the intermediary's cooperation, and without either of them holding an account anywhere.
What this proves is narrow and exact: these bytes were signed by the holder of the key that castle-alice.com publishes as its own. That is two links, and only one of them is cryptography — the signature binds the bytes to the key; serving that key from her domain over TLS binds the key to the name. Neither binds anything to the truth of what she wrote.
How does this work?
And this is what it really looks like:
--- title: This post carries its own terms published: 2026-08-28T16:20:07Z current-version: sha256:e1d970e9f42e… signature: U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTk… ---
Live · a post on vdibart.polis.pub — frontmatter abridged, signature truncated, body not shown. The signing base is the frontmatter plus the body, minus the fields a post leaves unsigned — so an edit to either breaks it.
Chapter Three
Alice sets some rules
Terms
machine-readable, signed, travelling with the workAlice had some rules about her writing. Quite polite ones.
She wrote them down once, and signed them. After that, her rules went everywhere her writing went — tucked inside her signature, where nobody could miss them.
What Alice learned…
rules are not fences. Alice can say what she would like; nothing here makes anybody listen. And anything she wrote before keeps its old rules forever — new rules never reach backwards.
What does this mean?
Alice writes her terms once, into a signed license.json on her site. At publish time a copy is materialised into each post's frontmatter, inside the signature. At render time the same source generates the page's <link rel="license"> and JSON-LD, plus the site's robots.txt and rsl.xml.
The vocabulary is AIPREF for preferences (train-ai, search) and RSL for licence terms AIPREF cannot express (ai-input, attribution). One authored file, several generated surfaces — and only the signed copy travels with the work.
Terms are never retroactive. A later licence does not reach back into anything already published under an earlier one.
How does this work?
And this is what it really looks like:
license: v: pub.polis.license.v1 profile: pub.polis.license.reserved/1 train-ai: n search: y ai-input: n attribution: required asserted: 2026-08-28T23:21:22Z
Live · the license: block inside the signature of the post from chapter two. train-ai and search are the entire AIPREF vocabulary; the rest is RSL, which expresses what AIPREF structurally cannot. Nothing states terms on an author's behalf — a site that has never said anything says nothing.
Chapter Four
Bob says so
Attestation
one identity signing a statement about a subjectPeople began to ask: is that REALLY Alice?
Bob had known Alice for years. So Bob said so, and signed it with his own pen.
Then a witness — somebody who knew neither of them — wrote down the day Bob said it, and signed that too.
Now Alice cannot change what Bob said. Neither can Bob. And nobody can pretend he said it any later.
What Bob learned…
Bob can say later that he changed his mind (by issuing a withdrawal), and everyone will see that too.
What does this mean?
Bob issues an attestation: a small signed record naming an issuer, a predicate and a subject. It lives on Bob's site, signed with Bob's key. Alice cannot alter or delete it, and neither can anyone else.
The subject can be pinned to a specific version hash, anchoring the claim to the exact bytes Bob saw rather than to a URL whose contents may later change.
A withdrawal does not erase it. The original record stays where it is and still verifies, gaining a pointer to a signed withdrawal beside it. polis stores these as evidence and computes nothing from them — there is no score, and no arithmetic that turns attestations into a verdict.
A third party can sign as well. A polis Discovery Service acts as a witness: it signs that it saw these exact bytes at a given time, and that witness travels beside the record. The value is the date — one the signer did not choose, since a record's own timestamp is just another thing its author wrote inside their own signature. A witness is evidence, never a gate: a claim without one verifies exactly as it would have anyway, and it says nothing about whether the claim is true.
The shape has a third leg polis has not built. The subject signing back — Alice saying she has seen what Bob said — has no reserved predicate, because what that should mean is unsettled. "I agree this is true" would turn every reply into an argument about truth, and an unanswered claim stands on its issuer's signature regardless.
How does this work?
And this is what it really looks like:
{
"type": "pub.polis.attestation",
"issuer": "https://bob.example",
"predicate": "pub.polis.attestation.correction",
"subject": {
"type": "uri",
"id": "https://castle-alice.com/posts/20260901-claim.md",
"version": "sha256:9f2a0123456789abcdef…"
},
"asserted": "2026-08-28T23:50:09Z",
"signature": "-----BEGIN SSH SIGNATURE-----\n…"
}
From the attestation spec, abridged. version is the pin. The predicate shown is correction, which ships today; a dedicated endorsement predicate is not reserved yet, so the shape is real and this particular claim is illustrative.
Chapter Five
Somebody copies the pen
Identity
a domain and a key — no accounts, no issuerAttribution
this is mine, and it survives leaving my siteOne day, a lonely man made himself a copy of Alice's very important pen.
Oh dear.
So Alice made a new pen. And with the old pen, one last time, she wrote a note that said: this is my pen now.
She hung the note by the door for everybody to see. And every single thing Alice had ever written still worked.
What Alice learned…
the row of pens only ever grows longer. It can never be tidied up, or mended, even if something in it went wrong — because the old pens that signed it are gone for good.
What does this mean?
When Alice rotates, the new key is not simply swapped in. Her site publishes a key history: an ordered chain in which each entry carries the previous key's signature over the handover.
A verifier meeting an old signature walks that chain backwards to find which key was current when it was made. Retired keys stay resolvable but stop speaking for the site — in her did:web document they remain in verificationMethod and leave authentication.
The chain is append-only and is never rebuilt, even when something in it is wrong. Its earlier links were signed by private keys that no longer exist, so nothing could reproduce them.
How does this work?
And this is what it really looks like:
"public_key_history": {
"current": {
"epoch": 1,
"key": "ssh-ed25519 AAAA…NEWKEY",
"valid_from": "2026-09-15T10:22:03Z",
"transition_sig": "-----BEGIN SSH SIGNATURE-----\n…"
},
"history": [
{ "epoch": 0, "key": "ssh-ed25519 AAAA…OLDKEY",
"valid_until": "2026-09-15T10:22:03Z" }
]
}
From the key-history spec — illustrative, because no site on the network has rotated yet. transition_sig is the handover, signed by the old key. In the site's did:web document a retired key stays in verificationMethod and leaves authentication.
Chapter Six
Alice needs some help!
Delegation
this may act for me — scoped, marked, revocableAlice got a LOT of letters from her fans. So many letters that she needed help.
So Alice asked her friend Rosie to help, and told Rosie exactly what she was allowed to decide on Alice's behalf. Not a single thing more.
Rosie uses Alice's pen. But Rosie always leaves a little mark of her own beside it, which says: this one was me, and here is where Alice said I could.
What Alice learned…
Rosie signs with Alice's own pen, so the little mark is an honest label and nothing more. Rosie says so because Rosie was built to say so.
What does this mean?
Alice issues a grant: a signed record on her own site naming the agent, what it may decide, and under whose authority. Rosie resolves a live grant before every act, and every act it performs carries two extra fields — agent and grant — inside the signed bytes.
Rosie signs with Alice's key, so the marker is disclosure rather than cryptographic separation: an honest label, not a lock. The fields are omitted entirely when no agent is involved, so anything Alice does herself stays byte-identical to what it would have been before agents existed.
The grant is revocable, and revoking it is itself a signed withdrawal.
How does this work?
And this is what it really looks like:
{"type":"pub.polis.comment.blessing",
"source_url":"https://bob.example/c.md",
"target_url":"https://castle-alice.com/p.md",
"action":"deny",
"timestamp":"2026-09-15T12:00:00Z",
"agent":"rosie",
"grant":"https://castle-alice.com/…/attestation/x.json"}
From the delegation spec — the exact canonical bytes that get signed, field order included. grant points at the source record, never at a generated summary page. A live blessing list at discover.polis.pub carries both shapes side by side.
Chapter Seven
Sandy counts everything
Verification
stated as fact, never adjudicatedThis is Sandy. Sandy loves to count.
Sandy loves to count one thing more than anything else: how much of this writing really is signed, and who signed it.
So she asked the big list what it had seen. Then she went to every single door and checked every single signature, herself.
Nobody let her in. And nobody could have stopped her either.
What Sandy learned…
Sandy can only count the helpers who said they were helpers. Somebody who never says looks exactly like anybody else — a signature proves who published a thing, never how it was made.
What does this mean?
Sandy asks a polis Discovery Service what it has been told about, then verifies every artifact against the publishing site's own key rather than trusting the service's word for it.
The service is an index, not an authority. It can be incomplete about what exists — it only knows what was registered with it — but it cannot make an invalid signature verify. It needs no authentication, so nobody grants or withholds her access.
What she can measure is disclosure: what was attributable, what verified, what terms were stated, what carried an agent marker. What she cannot measure is authorship. A signature proves who published a thing, never how it was made, and an undisclosed agent is indistinguishable from a person.
How does this work?
The machine in chapter two
A stranger. It consumes Alice's work, has no relationship with her, made no promises, and appears nowhere in this count — it publishes nothing into the network.
Rosie in chapter six
Not a stranger. It produces, in Alice's name, under her signed grant, with her key, marked on every act. It is in the count precisely because it said so.
And this is what it really looks like:
GET /v1/content?type=pub.polis.post
{ "count": 2,
"records": [
{ "url": "https://castle-alice.com/posts/hello.md",
"version": "sha256:abc123…",
"actor": "castle-alice.com",
"signature_verified": true,
"status": "active" } ],
"ds_signature": "…",
"ds_key_id": "ds-primary" }
From the polis Discovery Service API reference, abridged. No authentication required. The service signs its own answer (ds_signature), so it can be held to what it told her — and she still re-verifies each artifact against the publishing site's key rather than trusting signature_verified.
What did Alice learn?
- 1 Identity Nobody let her in, so nobody can shut her out. But her name and her address are the same thing — let the address go and the name goes with it.
- 2 AttributionVerification Everything she writes traces back to her, wherever it ends up. That does not stop anybody copying her. It stops them saying she wrote something she never did.
- 3 Terms Her rules travel inside the signature, where nobody can miss them. Nothing makes anybody follow them, and new rules never reach backwards.
- 4 Attestation What Bob says about her is a fact anybody can check, not a score. He can say later that he changed his mind, and everyone sees that too.
- 5 IdentityAttribution Somebody copying her pen costs her nothing she has already written. But the row of pens only ever grows, and can never be mended.
- 6 Delegation Rosie can decide things on her behalf and always leaves a mark saying so. The mark is an honest label, not a lock.
- 7 Verification Anybody at all can check the whole lot, without asking her. They can only count the helpers who said they were helpers.
Two rules made all seven. Signed things are portable and permanent; computed things are per-viewer and disposable — which is why there are attestations here and no scores. And the protocol states facts; consumers hold policy — whether a signature verifies is a fact, whether that is good enough is your call. Not the verifier's, and not ours.