01
Proving it happened without recording who
You should be able to: State the exact claim a verification/1 leaf makes and the one it must never make.
The claim a leaf makes is deliberately narrow: a verification of a stated assurance level happened at a stated time. The claim it must never make is anything about the person verified — no subject, no account, no contact, no token, and no identifier derived from any of those.
This narrowness is the feature. A log that proved "person X verified at time T" would be a surveillance record no identity service should keep, let alone publish. A log that proves "a level-1 verification happened at time T" is auditable evidence the service is working, with nobody’s presence disclosed.
Everything else in the format is in service of holding that line under pressure — because the easy mistakes here all look like harmless metadata and are not.
Source: flashyID — the verification/1 notary source
02
The three-field leaf
You should be able to: Name the three fields a leaf hashes over and why each is safe to reveal.
The hash pre-image is exactly three fields. An `eventId`: a fresh random id minted per event, never derived from a subject, a contact or a token — it exists only so a leaf is reproducible from the stored event and so two verifications produce two distinct leaves. An `acr`: the assurance level as a URN, a class shared by everyone at that level, not a person. And a `createdAt`: the issue time.
Each is safe to reveal because none of them is about a person. The level says how strong the check was, which is the entire point of publishing it. The time says when. The random id says only "this was one event," carrying no relationship to who it was for.
The served leaf itself is five string fields — a hash, a kind, a source, a time, and a ref — and the ref is derived from the leaf hash, never from a grant id, a session id or a subject. Nothing addressable back to a person survives into the published record.
Source: flashyID — the content-free verification leaf
03
Why no identifier enters, even hashed
You should be able to: Explain why hashing a user identifier would not protect it here.
The tempting shortcut is to store a hash of the user’s id "so it is not the real value." It fails for the same reason it fails in the mail record: a Telegram id or an email is drawn from a small, enumerable space, so an attacker reproduces the hash for every candidate and matches. A hashed small-space identifier on a public log is a reversible identifier.
So no user identifier enters the leaf at all, hashed or otherwise. The only safe handle is one with no relationship to any user value — which is why the id is freshly random and the ref is derived from the leaf hash, not from anything tied to the session or the subject.
This is the estate’s single most repeated privacy rule, and an identity service is where breaking it would do the most harm. Hashing is for integrity, never for hiding a value from a space small enough to enumerate.
Source: flashyID — a hashed small-space identifier is reversible
04
The leaf and the transparency log
You should be able to: Explain how a verification leaf becomes part of the estate-wide append-only log.
flashyID serves its leaves as a `verification/1` fragment, and flashy network’s log generator fetches that fragment the way a stranger would and folds each new leaf into the estate-wide, append-only transparency log — the same log the checkpoint course covered, the same append-only union rule, sources that cannot be read reported as unread rather than empty.
This is why the leaf had to be non-identifying: it is going into a public, permanent, cross-property log. A record that is safe behind a login is not safe in a transparency log, so the safety has to be in the leaf itself, not in where it is stored.
The payoff is a genuinely auditable identity service. Anyone can watch the log grow and confirm verifications are happening at the assurance levels claimed, over time — and learn nothing about a single person while doing so. Auditable and private are usually presented as a trade-off; a content-free leaf is how you get both.
Source: flashy network — the transparency log
05
The field order is the format
You should be able to: Explain why the canonical pre-image is pinned and how a verifier reproduces it.
A verifier reproduces a leaf’s hash by serialising the same three fields the same way, so the exact field order of the pre-image is part of the format, not an implementation detail. Change it and every hash changes, which is why it is pinned by a test — including a digest over a fixed fixture — the way the estate pins every sealer against its verifier.
Pinning the pre-image is what makes the leaf verifiable offline: a stranger with the published fields recomputes the hash independently and confirms it, needing neither the service nor trust in it. The format is the bytes, and the bytes are fixed.
That closes the theme of the course. A record can prove a sensitive event happened, be folded into a public permanent log, and reveal nothing about the people in it — if, and only if, the leaf is content-free by construction and reproducible by anyone. Design the record so the guarantee is in its shape, and privacy stops depending on anyone’s promise.
Source: flashyID — the pre-image is pinned by a test
