socaity.dev

Claim your entry

No token. Nothing to trade. This is a database.

Your change was merged. An entry for it was written to the record the same day, against the week the work actually happened — you did not have to be here for that, and none of it was waiting on you.

What the entry does not have yet is a name. It reads attribution reserved, and it is bound to whoever holds the account that authored the merged pull request. That is you. The three commands below attach it to a key only you hold — this is what the entry looks like now, and after.

There is no account here, and there is nothing to sign up for: this site stores no password, sends no email, and has nothing to log in to. That is why the steps below are ssh commands — the key they make on your own machine is the name, and you keep it. Nothing is required of you. You may decline all of it and close this page: the entry is already written, it is already valued, and it stays bound to you, reading attribution reserved, until you claim it or never do.

Your entry never expires: after about 6 months, claiming it takes one extra verification step and nothing else, and there is nothing here to be early for. How that figure is computed. The three commands run in well under a second; the rest is reading, pasting, and typing your passphrase — twice when you choose it in step 1, once more when you sign in step 2. Under three minutes is the target.

As of the graph clock 2026-08-06 that target has been walked end to end by the people who wrote it and not yet timed with contributors — the test that will time it is written and has not been run.

  1. 1. Make a key

    The command below writes two files. claim-key is the private half: it stays on your machine, and nothing on this site, in this repository, or in the record ever asks you for it. claim-key.pub is the public half — that half becomes your name on the record. ssh-keygen asks for a passphrase; use one, and read the note on backing it up before you close the terminal.

    mkdir -p ~/.socaity && ssh-keygen -t ed25519 -f ~/.socaity/claim-key -C "socaity claim"

  2. 2. Sign one line

    The line the first command writes says: this account and this key are the same person. Signing it proves one direction of that — only the private key you made a moment ago can produce that signature, and it can only be used for a socaity claim, never as a login or a commit signature.

    Replace YOUR-GITHUB-LOGIN with your account name — the one that authored the merged pull request — then run both lines.

    printf 'link:github:%s:%s\n' YOUR-GITHUB-LOGIN \
  "$(cut -d' ' -f1,2 ~/.socaity/claim-key.pub)" > ~/.socaity/claim.txt
ssh-keygen -Y sign -n socaity.dev/claim -f ~/.socaity/claim-key ~/.socaity/claim.txt

  3. 3. Publish it

    The command below prints the two files you just made. Paste everything it prints as a comment on your merged pull request. Publishing it there proves the other direction — only your account can post as your account. Neither half is worth anything alone; together they are the whole claim, and nobody else can produce both.

    cat ~/.socaity/claim.txt ~/.socaity/claim.txt.sig

That was the whole thing

What happens next, in order: someone verifies both directions of your signature — with the commands below, which anyone can run; the entry stops saying attribution reserved and names your key; you get a reply with a permalink to the row.

None of that changes the valuation. It was computed by the published rule when the work was accepted, from the merge itself, and it is the same number whether you claim today or next year. Claiming attaches your name. It does not price anything, and there is nothing here to buy, sell or transfer.

Check it yourself

An attestation nobody can check is a promise. This one is checkable by you, by a maintainer, and by a stranger who trusts neither of us. With ssh-keygen alone:

printf '%s namespaces="socaity.dev/claim" %s\n' "github:YOUR-GITHUB-LOGIN" \
  "$(cut -d' ' -f1,2 ~/.socaity/claim-key.pub)" > ~/.socaity/allowed_signers
ssh-keygen -Y verify -f ~/.socaity/allowed_signers -I github:YOUR-GITHUB-LOGIN -n socaity.dev/claim \
  -s ~/.socaity/claim.txt.sig < ~/.socaity/claim.txt

It prints Good "socaity.dev/claim" signature for github:YOUR-GITHUB-LOGIN, or it fails. This repository also carries a small script that runs the same check and additionally prints the two values the record stores — your key in its ledger form, and the binding hash:

cat ~/.socaity/claim.txt ~/.socaity/claim.txt.sig \
  | python3 tools/claim/verify_claim.py --login YOUR-GITHUB-LOGIN

Before you close the terminal

The passphrase, and what losing the key would mean

Use a passphrase, and put the passphrase somewhere you will still have it in a year. The private key file is the only thing that can act as you on the record.

If you lose it: the entries already attached to it stay attached to it. They are not deleted and they do not move on their own. Getting your standing onto a new key runs through the published adjudication process as a new, signed, public entry — forward-only, visible to everyone, never a quiet edit of the past. That is deliberately more friction than a password reset, because the alternative is an administrator who can silently re-attribute anyone's work.

The cheap insurance is a backup of the two files in ~/.socaity/ wherever you keep things you cannot regenerate.

Your key is permanent. Your display name is not.

The record holds your public key, the structured facts of the contribution, and hashes of the evidence. It holds no handle, no email address, no display name, and no free text — those live in an ordinary, editable, deletable table beside it. Change your display name whenever you like; ask for it to be removed and it is removed. The entry itself, and the key it names, are permanent by design: that permanence is the only reason the record is worth anything.

I already have an SSH key — can I use that one?

You can, if it is an Ed25519 key: point -f at it in step 2 and skip step 1. Think about whether you want to, though. The key you use here becomes a permanent public name attached to everything you contribute, and it is the same key you push code with. A separate key costs one command and keeps the two roles apart.

Publishing somewhere other than the pull request

The pull request comment is suggested because it is one fewer place to visit and the account is already proven there. A public gist under the same account works identically — paste the same text, then link the gist in a comment. A gist is also the place to publish a later revocation, because you can edit it: if you ever need to withdraw the link between an account and a key, publishing a signed revocation in that gist is how you say so.

Either way the artifact is plain text. Nothing here reads the GitHub API; the check runs against what you pasted.

No GitHub account, or you would rather not use one

Then this page is not your path, and you do not need it. The courier path takes contributions by email as a signed patch: you sign the content with the same ssh-keygen -Y sign command, send the patch, the signature and your public key to the published inbox, and a maintainer opens the pull request verbatim with your key recorded as the author. Your key precedes the contribution, so there is nothing to claim afterwards.

The path is written down in council/socaity-z61.md, which is the record of the decision to have it.

Windows, and other shells

The commands are POSIX shell. On Windows they run unchanged in Git Bash or WSL, both of which ship the same ssh-keygen. In PowerShell, the pipeline in step 2 differs; the simplest fix is to write the one line link:github:<your-login>:<contents of claim-key.pub, first two fields> into a file by hand and sign that file.

What the record stores, and the 6-month figure

Three values reach the record when your claim is recorded, and you can recompute all three:

  • Your key, written in the record's canonical form — a z6Mk… string. It is a pure function of the same 32 bytes your claim-key.pub carries: not a second key, not something to generate, just another spelling.
  • The binding — the SHA-256 of the string github:YOUR-GITHUB-LOGIN, with the account name in lower case (GitHub treats it as case-insensitive, and both sides of this hash have to fold it the same way or they will not match). It was fixed when the entry was written, before anyone knew whether you would claim it, which is what stops a stranger from claiming your entry: their signature would name a different account and hash to a different value. The handle itself never reaches the record, only this hash: 
    printf 'github:%s' YOUR-GITHUB-LOGIN | tr 'A-Z' 'a-z' | shasum -a 256
  • The hash of your attestation, so the text you published cannot be quietly swapped for different text later.

The 6 months: a claim attaches automatically for 182 days after the entry — 2 × the published 91-day accounting period — and after that the same claim is still available, but goes through the published adjudication process instead. Nothing expires; the automatic path hardens, because an entry that stays automatically claimable forever is a prize sitting on someone else's account security. Both numbers come from the published parameter set and the validator's parameters, and this page computes the figure from them rather than stating it. Both are marked provisional there and can still change while they are.

Maintainers: the merge comment that carries this invitation is a checked-in template, not something to improvise per pull request.