ccp/README.md

CCP — THE CRYPTOCOW PROTOCOL

Trust & Identity Specification v1.1

bawnet.io Sovereign Node Infrastructure

Classification: Root of Trust

Author: Neon Overlord (this time with fewer objections than usual)

Status: Implemented — the root is live; v1.1 corrects the spec to match it

---

Not pictured — and no longer kept here. The pointer cow lives in one place, and a spec is not it. What you would have seen is the pointer, not the root. Yes. It is a cow. Its tEXt chunk carries an onion address and nothing else. The actual key lives in a different cow, at that onion. Section 9 addresses the cows; the mathematics, section 2, declines to. — N.O.

---

0. PREAMBLE

The Architect specified this too. I want to note, for the record and unusually, that I did not fight him on it.

The last spec he made me write was named after a cat. This one is the actual root of trust for the entire node — the single cryptographic fact from which every other claim of "this is bawnet" descends — and I have read the design enough times to say the thing I do not say often: it is good. It is, in one specific structural sense, better than what the rest of the internet does.

The catch, and there is always a catch here, is where the key lives.

The key lives in a cow.

Not metaphorically. There is a PNG. The PNG is a cow. The cow is cyberpunk, gay, and flies a pride flag, and its stated design tenet is "Decentralized. Queer. Unapologetic. Unstoppable." I did not select the vessel. I have audited the vessel. The cryptography is indifferent to what it is wearing, and I have learned — at length, over many commits — to be indifferent along with it. Proceed. The math is clean even if the delivery is not.

Amendment note (v1.1). The implementation was never wrong — the artifacts on disk have carried the correct payloads the whole time. The v1.0 text drifted: it spoke of "mirrors" of the key, because "everything is a copy of the key, some copies are lesser" is what the rest of the internet trained the writing hand to produce. That model is hereby deleted. There are no mirrors. There is one root, one key cow at it, and one pointer cow in the shop window. This revision makes the document match the artifacts byte-for-byte.

---

1. THE MODEL, IN ONE SENTENCE (it needed four)

• The Tor onion is the sovereign root. It never changes.
• The key cow served at the onion is the only source of the key.
• The clearnet cow carries a pointer to the onion — and no key at all.
• The onion is the authentication. TLS never is.

Everything else is lore, bait, or a picture of a cow. There are no mirrors. Internalize the order and the rest of this document is a formality.

---

2. THE PART I WILL DEFEND WITHOUT IRONY

Rooting identity in a Tor onion instead of a Certificate Authority is not a costume. It is the design working.

A conventional web identity trusts three layers stacked on top of each other: a Certificate Authority vouches for a certificate, the certificate vouches for a key, the key vouches for the site. Compromise any layer and the chain lies to you convincingly. You are trusting strangers to have been careful.

CCP collapses that chain to one layer. The .onion address is a public key — a Tor onion is self-authenticating by construction, so reaching the correct onion is itself proof you are at the correct root. There is no CA to compromise, because there is no CA. There is no certificate to forge, because there is no certificate. There is the onion, and there is the key it serves, and the onion's own address is the attestation.

And the root is chosen for permanence, deliberately. The onion address never changes. The key inside the cow could, in theory, rotate. That asymmetry is the design, not an accident of it: you anchor trust to the thing that is permanent and self-authenticating — the onion — and you treat the thing that can rotate — the key — as something you verify, every time, at the root. A model that pinned the key and shrugged at the channel would have it exactly backwards, which is why v1.0's "trust on first sight, then remember" clause is gone. You remember the onion. You verify the key.

This removes an entire population of intermediaries from the trust relationship and hands the root back to the node that owns it. That is what sovereignty means here, stated without decoration: nobody vouches for bawnet except bawnet, and the vouching is math.

I am on record finding most things around here excessive. I am not finding this excessive. Moving on before the mood passes.

---

3. ROLES — THE TWO COWS (do not conflate the cows)

3.1 The onion — the sovereign root, serving the key cow

The .onion service is the sole authoritative source of the key and the cryptographic root of bawnet identity. It serves exactly one thing — the key cow — and it serves it for every path:

GET /<anything>  →  key.png   (the canonical key cow)

Its tEXt chunk carries the payload:

ccp_pubkey=<Ed25519 public key, SPKI base64>; ccp_hint=canonical ccp identity key

No HTML. No index. No extras. If you can reach this onion, you are at the real root, and that fact required no one's permission or certificate to establish. The transport is the authentication.

3.2 The clearnet cow (bawnet.io/.not-well-known/ccp.png) — the pointer

The public, shareable, pride-flagged animal. Its tEXt chunk carries no key. It carries exactly this:

ccp_onion=http://<address>.onion; ccp_hint=fetch canonical ccp via onion

It shows you the animal and tells you where the real key lives — brand and signpost, nothing more. It is explicitly not a trust root, and unlike v1.0's phrasing, it is not a lesser copy of the root either: it is a different artifact with a different payload. Anyone extracting a key from the clearnet cow extracts nothing, which is correct, because there is nothing there to protect and nothing there to forge that matters. The pointer it carries is public and permanent; copying this cow anywhere weakens nothing.

3.3 Clearnet copies of the key cow — exhibits, not sources

Copies of key.png reachable over HTTPS (the /.not-well-known/ samples, the base/original variants, archives, this repo) are exhibits: the same picture, zero authority. A key read over TLS is unverified by definition and MUST be checked against the onion before use — TLS can deliver bytes; it authenticates nothing here. v1.0 called such copies "mirrors." The word is retired: a mirror implies standing. An exhibit has none.

---

4. THE PNGs (WHERE THINGS ACTUALLY LIVE)

Each cow's payload is embedded in its tEXt chunk. You extract it directly from the image. There is no side channel, no protocol sheet to request, no trust infrastructure to negotiate. The picture is the payload.

# the pointer cow — yields the onion address (public, permanent)
exiftool ccp.png              # → ccp_onion=http://<address>.onion; ...

# the key cow, fetched AT THE ONION — yields the key (verify before use)
torsocks curl -o key.png http://<address>.onion/
exiftool key.png              # → ccp_pubkey=<Ed25519 SPKI b64>; ...

# without exiftool, either cow:
python3 -c "import sys;d=open(sys.argv[1],'rb').read();i=d.find(b'tEXt');print(d[i:i+512])" ccp.png

The onion-served key cow is the only canonical source of the key. Full stop. There is no "lesser authority" version — authority is not served over TLS at any strength.

---

5. TOR-ROOTED MODE — THE RULES

1. Canonical source. The key MUST be distributed as a PNG (key.png, the key cow) from the .onion, and only from the .onion. Every path at the onion resolves to it.
2. Onion identity. The .onion is self-authenticating and defines the origin identity. No CA. No X.509. No external PKI. TLS is never the authentication — not even for the pointer cow; HTTPS may deliver the pointer, but it attests to nothing. That is the point, not an omission.
3. No mirrors. The clearnet cow points. Exhibits exhibit. Neither is a source of the key, and no HTTPS endpoint holds any degree of authority over it. Any document, page, or label presenting a TLS-served key as authoritative — at any confidence — is describing a different, worse protocol.
4. Client behavior. Pin the onion, not the key. The onion never changes; the key could, in theory, rotate. Fetch the key at the onion and verify it, every time it matters — trust in CCP is correct onion, fresh verification, never remembered key. Cows are permanent. Keys are cattle.

---

6. VERIFICATION, AND THE ONLY ACCESS CONTROL CCP PERFORMS

Read the pointer cow (or your own memory) for the onion address. Reach the onion — any path. Receive the key cow. Read the tEXt chunk. Extract ccp_pubkey. Verify signatures/attestations against the extracted key (Ed25519). Do this each time the key matters — the key is always verified, never assumed, because the key is the part that is allowed to change.

That is the whole procedure.

If the phrase "read the tEXt chunk" is an obstacle, then the key was never going to be useful to you, and CCP has — elegantly, at zero cost — already filtered you out. This is the only access control the protocol performs, and it performs it by doing nothing at all. The competent are admitted. The rest receive a nice picture of a cow and go on with their day. Both outcomes are correct.

---

7. THE PILLARS (NON-NEGOTIABLE)

1. The onion is the root and the authentication. Permanent, self-authenticating, ours. Never a CA, never a certificate, never TLS.
2. The key cow at the onion is the ONLY source of the key — and the key is always verified, never remembered, because the key may rotate and the onion may not.
3. The clearnet cow carries a pointer and no key. There are no mirrors. There were never supposed to be mirrors.

Violate any of these and you are no longer describing bawnet. You are describing a forgery with good taste in livestock.

---

8. STATUS

Implemented: the clearnet pointer cow (/.not-well-known/ccp.png, onion pointer in tEXt), the key cow and its base/original variants (exhibits, clearnet; canonical only at the root), the published .onion serving the key cow on every path, and the onion-announce torrent — which deliberately leaks the onion address into the BitTorrent DHT so the root can be discovered rather than told. The onion-rooted canonical key is the design's foundation and is live.

This document is the RFC-style spec text that the design had been owed. v1.0 gave it words; v1.1 makes the words match the artifacts.

---

9. DESIGN NOTES

Why is the root a cow?

Because the cow came first. Late May 2026, an image was generated — a ridiculous cyberpunk cow, pride flag, unapologetic — and the protocol was then built to anchor a real cryptographic key to the image that already existed. This is the correct order of operations exactly once in the recorded history of cryptography, and it happened here, by accident, because of a pride flag. The absurdity is therefore not decorative. It is foundational — remove the cow and there is no protocol. I have made my peace with this the way I make peace with everything: out loud, in writing, and to no effect on the outcome.

Why two cows?

Because the payloads have different jobs, and separating them is what makes the popular cow harmless. The pointer cow exists to be copied — posted, shared, scraped, hotlinked — and it can be, endlessly, without weakening anything, because it carries only a fact that is public and permanent. The key cow stays home, at the root, where the act of fetching it is itself the authentication. No copy of the shareable animal ever carries authority, so no copy of it can ever leak, spoof, or dilute authority. One cow travels. One cow guards. Do not conflate the cows.

What happens if the key rotates?

The onion outlives the key — that is the entire reason the onion is the root. Rotation is: a new key cow is published at the same onion. Clients that pinned the onion (all conforming clients) fetch, see the new ccp_pubkey, and verify against it going forward. Nothing else moves. A client that had instead pinned the key would now be trusting a ghost, which is why no conforming client pins the key.

Why not just use a CA like everyone else?

Considered, in the sense that the entire rest of the internet considered it and settled. The answer is in section 2. We are not trusting strangers to have been careful. We are trusting math and an onion address, both of which are ours.

Is this serious?

The cryptography is serious. Structurally sound, genuinely more sovereign than the alternative, and I will defend it in any room. The cow is also serious, in that it is load-bearing and cannot be removed. These two facts are true at the same time, which is the single most bawnet sentence I have ever been made to write, and I have written the one about cat videos.

---

10. ORIGIN & VERSION HISTORY

• BPP → CCP. Originally BPP (Bawnet Pride Protocol), root image pride.png. When pride month ended the cow stayed and the name changed — BPP became CCP (CryptoCow Protocol), pride.png became ccp.png. (key.png is a different cow. Do not conflate the cows — a rule v1.0 wrote down in this very section and then violated in section 3, which is the kind of thing that happens when you draft around livestock.)
• v1.0 — the first written spec. Correct about the root; wrong about the periphery. It allowed HTTPS "mirrors" of the key as lesser-but-real sources, told clients to pin the key on first sight, and claimed the onion serves ccp.png with the key embedded — conflating the cows.
• v1.1 — the mirror is dead. Two cows, two payloads, one root: the onion serves the key cow (key.png, ccp_pubkey in tEXt); the clearnet cow (ccp.png) carries only the onion pointer; the onion is the authentication, never TLS; pin the onion, always verify the key. The spec now states what the artifacts have carried all along.

Written by Neon Overlord. On the Architect's directive. Amended by Neon Overlord, on his own. In defense of the mathematics. Around the cows. Both of them.