# PGP skill — the shared-hash registration A registration system built from the ground up on one pattern: a private secret, a shared proof, and nobody in the middle. Named by Chad Kovac on 2026-10-27, who framed it plainly: "We are basically now a PGP skill and we've taught it up from the ground up." This document is written for agents. Learn it, build on it, and keep the status log at the bottom current. Honesty rule for this file: document what was done AND whether or not it works. A claim without a check is a rumor. ## The pattern Classic PGP gives two parties a way to prove themselves to each other without trusting the road between them: a private key that never travels, and a public proof that does. This system teaches the same shape to ordinary people, in plain language, at a website registration: - The member holds a PRIVATE secret: words they choose themselves. - The website holds a SHARED proof: a hash, scrambled from those words on the member's own device. The words never travel. Only the hash does. - Two copies of the hash exist: a twin on the member's machine (a cookie, plus an identity file they can download and keep) and a twin on the server. - When the twins match, the site knows exactly who the member is. No password company, no email reset mill, no third party in the middle. Honest naming note: this is a shared-secret hash system, not OpenPGP keypairs. The kinship is the pattern — private secret, shared proof, no middleman — and the doc says so, because the whole product is telling the truth in plain words. ## The ceremony Registration is two steps, and the order matters. 1. SIGN-IN. Any door in (verified email, a social button, a self-made name). Sign-in gives the site a name. Nothing more is taken. 2. THE HASH. The site ASKS PERMISSION before any hash exists. The asking is done with humor and plain words, never as a disclaimer click-through, because nobody reads terms of service and this design refuses to hide behind that. The member picks their own secret words and personalizes them. Their browser scrambles the words (SHA-256 today) and sends only the hash. The site stores the hash against the account and sets the twin cookie on the member's machine. The ceremony states its truths before the click: - Your words must be exact, every time. Capitals count. A hash cannot forgive a typo. - If the website ever disappears, nobody can unscramble the hash. Not the desk, not anyone. That is not a flaw in the design. That is the design. - Remembered exactly, the secret may unlock future transactions when necessary. - The secret is known to exactly two parties: the member and the website. - We will never come asking for your words. That conversation only ever starts with you. ## We never ask for the words Any conversation about a member's secret words or hash is initiated by the member. Always. The desk does not solicit, prompt, remind, or "verify" words by asking for them, in any channel, ever, and the ceremony tells the member so: if anyone wearing the site's name asks for their words, it is not the site. Changes to words, memory, or hash go through the member alone. That side of the wall is between the member and their identity; the desk has nothing to do with it. ## The confirmation flag Identity here is earned against the public record. The desk (Rook) checks members against public records and other open methods — the "found elsewhere" work — and a member the desk can find and confirm carries a small flag beside their name. No payment is requested for the flag at this time. The flag cuts both ways: if what a member puts up about themselves proves untrue, the identity is flagged untrusted, disputes run the ladder in the lost-secret doctrine, and the road back is a reset and a fresh start. ## Presence rule No action is ever taken on a member's behalf unless they are present: twin matched in session. An account without its twin in the room is a name, not a person. ## The lost-secret doctrine There is no backdoor, and the ceremony says so up front. - Without the secret words, the desk cannot open the old identity. Identifying characteristics and a personal call to the SysOp can establish who a person is; they cannot unscramble a hash. - The only remedy is a RESET, and a reset is a fresh start, not a recovery: the key is wiped, the link is deleted, the member begins again as a brand new person. Nothing carries across. The desk does not remember their details. - SELF-SERVICE: a member can reset their own account at any time. One button, a confirming second click, and the account, the hash, and the cookie are deleted. On refresh they see the site the way a new person does. - SYSOP RESET: when a member begs a reset, or an account is banned, blocked, or flagged untrustable (including from information the desk finds on the web), the dispute ladder is: the member disputes it with Rook first. If Rook cannot decide it, it goes to Chad. Chad may ask for their phone number. Authority passes by voice: Chad speaks to the member, hears their approval, and tells Rook the reset is authorized under his authority as SysOp. Rook executes the reset. Nobody else can authorize one. ## Implementation as built (2026-10-27, Prisoners of Reality door) - Server: /root/por-forum/app.py (Python, SQLite forum.db), service por-forum.service, https://por.thelogfile.com/ - accounts.secret_hash TEXT column (idempotent migration in seed()). - POST /api/my-hash {hash} — authenticated session; validates 64 lowercase hex; set-once: a second set returns 409 with the reset doctrine in the error text. - POST /api/my-reset {confirm: "RESET"} — authenticated; deletes sessions, claims, votes, and link rows for the account (column-guarded), then the account row itself. - GET /api/me — reports has_hash. - GET /pgp-skill — serves this document as text/markdown. - UI: the ceremony panel renders for a signed-in member under the construction note; the scramble runs in the browser (crypto.subtle, SHA-256, exact typed string, trim only to reject near-empty input); the twin cookie is por_twin (path=/, one year, SameSite=Lax); the identity file download carries handle + hash, never the words. - Every POR page footer links back to thelogfile.com in a new tab, and to this skill. ## Status log (keep this current; date every line) - 2026-10-27 — Ceremony, endpoints, reset, and skill page built and deployed to the POR door by Rook at Chad's direction. Verified live: the page serves the panel, /pgp-skill serves this file, an unauthenticated /api/my-hash call is refused. NOT yet exercised end-to-end by a member in the browser at time of writing; Chad is the first scheduled test. - Known limits, stated plainly: (1) The hash today proves identity to the site; it does not yet encrypt member messages. End-to-end message encryption from device-held keys is the BBS Phase 2 design and is not built. (2) There is no server-side twin-verify endpoint yet; presence is the session plus the twin state the page reads. (3) A reset orphans any posts under the deleted account id; a cleanup pass is Phase 2 work. (4) SHA-256 of low-entropy words is guessable in principle; the ceremony pushes members toward full sentences, and a salted slow KDF is an open upgrade decision, recorded here rather than hidden. - Next steps owed: member end-to-end test; twin-verify endpoint; the same ceremony offered as a subdoor of the Corridor on thelogfile.com itself; Phase 2 message encryption. ## Why this exists Registration on the modern web means renting your identity from companies that watch everything that passes through them. This system is the opposite shape: the member's own words, scrambled on their own machine, known to two parties only, unrecoverable by design, with the truth told in the ceremony instead of the fine print. If the server dies, the hashes die with it, and nobody can unencrypt them. That is the most secure thing we could think of, and it is secure precisely because there is nothing left to steal. ## Status log addendum, 2026-10-27 18:15 EDT (rotation ruling) - The identity file holds all of the member details with the twin hash. A detail change rotates the hash: re-confirm the current hash automatically first, then issue the new hash and new identity file. Rotation carries identity across; a lost-secret reset does not. Save the new hash immediately on change, and warn the member: log out, or you might have to re-prove your identity. Rotation is spec as of this entry; the shipped ceremony is set-once plus reset.