NIP-XX

Validation

draft optional

This NIP defines a Nostr event kind by which a validator — any pubkey a consumer chooses to trust — publishes its verdict on one Composition (kind 3440): the certificate survives the mechanical check and realizes the stipulation the event carries, or it does not, for a stated reason. A valid verdict is the one signal an engine-free consumer can lean on, and it is the one that admits a Composition to the activity surfaces.

Abstract

Defines kind: 3441, a regular event signed by a validator, referencing the Composition it judges and naming its composer. content carries a single status token — one reserved value, valid, meaning the certificate checked out and realizes the stipulation; every other value a decline, for that reason. The event carries nothing else — no derived tags: under exact binding a valid verdict means that the certificate’s derived outcome and depth equal the Composition’s objective and moves, so any value published here would copy the stipulation one hop from where it is signed — a second copy that can only drift. The display statement is read off the Composition, which every consumer loads anyway as the substrate.

A Validation is reactive — it judges what already exists — and final for the (validator, Composition) pair. Its subject is parameter-free: the legality of a move and the exhaustiveness of a branch are rule-system facts, not authority policy, so two honest validators cannot durably disagree about anything except an advantage criterion.

Motivation

The check is mechanical and anyone can run it — so why an event at all? Three reasons, sharpened by the cheapness of the check. Engine-free consumers need a signature to lean on, and one string comparison against valid — the statement it confirms, objective and bound, already standing on the Composition they hold. Composers need a terminating answer with a reason they can act on: the position is illegal, a defence is missing, your certificate proves a mate in 3 and you stipulated 2 are answers a client can turn into a repair; a bare “declined” is not. And the network needs the check to be replayable: a validator’s verdict is a public claim any engine-holder can refute in linear time, which makes validator trust cheap to establish and cheap to withdraw.

Specification

Event kind

kind: 3441 — a regular event per NIP-01: immutable once signed and broadcast.

Signer — the validator

Any pubkey MAY act as a validator; consumers choose which to trust, exactly as they choose rating authorities. Several validators MAY judge the same Composition independently, and divergence — beyond advantage-criterion differences and outright error — is itself a public, checkable signal.

Validator discretion

A validator examines what it chooses — typically every Composition for the games it serves, discovered by kind subscription, or by a #p subscription on its own pubkey where composers address it (kind 3440 §Addressing validators). Being addressed binds nothing: the validator-marked p tag is a routing hint, so a named validator owes no answer and an unnamed one is not thereby disqualified from judging. A composer MAY name several validators on one Composition, so finding another validator’s name on a Composition is no reason to leave it alone. An unjudged Composition is unjudged, not invalid.

What a validator MUST NOT do is publish two contradictory verdicts for one Composition — the subject is immutable and the check parameter-free, so there is nothing for a second verdict to know that the first could not. Consumers resolve an equivocating validator deterministically, per the (validator, Composition) slot: on conflict, the canonical verdict is the one with the smallest established canonical timing, ties by smallest id (Canonical Timing §Meta-resolution). A verdict whose canonical timing cannot be established never wins a conflict; if neither conflicting verdict’s can be, the validator has no canonical verdict for that Composition — its voice is void there, which is equivocation’s own reward. A validator with a single verdict for a Composition needs no timing at all: an unopposed verdict is canonical as it stands.

Timing

Never attested, and belonging to no session: a Validation’s canonical timing follows the undesignated self-timed rule (Canonical Timing §Canonical timing of an event) — its own created_at, established by retrieval from a profile-conforming timing relay the consumer trusts. It is consumed only by the slot rule above, so it matters only under equivocation: a validator who intends its verdicts to prevail in any conflict SHOULD publish them via a strict timing relay; an honest, non-equivocating validator needs nothing.

Tag	Cardinality	Value	Description
`e` `composition`	exactly one	event id, optional relay hint, marker `composition`	the Composition (kind `3440`) this verdict judges
`p` `composer`	exactly one	pubkey, optional relay hint, role marker `composer`	the Composition’s signer — routes the verdict to them via one `#p` subscription
`alt`	0 or 1	human-readable string	NIP-31 fallback (e.g. `"A validated Sanki puzzle."`)
`L`	0 or 1	a theme namespace	NIP-32 label namespace, present only on `valid` (§Themes)
`l`	0..n	a theme token, marked with that namespace	one per theme the validator read in the certificate

Themes

A validator MAY label a valid Validation with the themes it read in the certificate: back-rank-mate, fork, deflection. Each is one NIP-32 label (l) marked with a theme namespace declared by a single L; the namespace, the token grammar and the vocabulary are the game’s business, fixed in its supporting document, never here. This NIP fixes only where themes live and what they are worth.

They live on the Validation and not on the Composition, and the reason is the whole point of putting them anywhere. A theme a composer declares is an unverifiable claim, useful for organizing and worth nothing for trusting; a theme a validator derives from the certificate is a reading of the same bytes everyone else can read, by a party a consumer already relies on for the verdict. A consumer filtering on themes is therefore filtering within what it already trusts — every event carrying a theme is, by construction, a valid verdict from a validator in its set — and no second trust decision is introduced by the feature.

Three limits, and they matter more than the mechanism:

A theme is a reading, not a verdict. The status token is exact and MUST be — two conforming validators return the same one for the same event (§The stipulation check). Themes are not held to that standard and cannot be: motifs like sacrifice or quiet move have edges a criterion draws differently, and two validators labelling the same certificate differently are both conforming. A consumer that treats a theme set as canonical is over-reading it.
Absence claims nothing. A theme that is not there means the validator did not report it — not that the puzzle lacks it. Only a theme’s presence is a signal. A client MUST NOT present “no themes” as a property of the puzzle, and MUST NOT infer from a missing theme that a filter excluding it is complete.
Themes never bear on the verdict. They are derived after the walk succeeds, they change no check, and a validator that publishes none is exactly as conforming as one that publishes twelve. A Validation whose status is not valid carries no themes at all: there was no completed walk to read them from.

Because they ride on the Validation, the labels are also replayable: any engine-holder can re-derive them from the Composition and see where a validator’s reading differs from theirs. A divergence is evidence about the two criteria, exactly as a divergent verdict is evidence about the two engines — with the difference that here, unlike there, both may be right.

Leaf classification

What makes a leaf achieved is the game’s binding, per its supporting document, which maps each reserved class to the game’s own terminal statuses; advantage is a non-terminal criterion the game MUST define deterministically, and a validator that has not published one answers unsupported. (The reference sanki binding is its supporting document, Puzzle Specification — Sanki §Leaf classification.) History-dependent draws — repetition, move limits — remain unrepresentable in a position-anchored certificate.

The stipulation check

The walk derives the certificate’s outcome — the weakest leaf class under the game’s outcome order (kind 3440 §Content) — and the verdict is valid only if that outcome equals the Composition’s stipulated objective. A sound certificate deriving anything else — weaker or stronger — is declined; game vocabularies SHOULD name this decline objective_mismatch, as the reference sanki vocabulary does.

Exactness in both directions is deliberate: the exercise is the composer’s, a mate certificate answers a different question than the draw that was posed, and republishing that answer under the stipulation it actually realizes costs exactly one event.

The depth check

One more comparison follows: the certificate’s derived depth MUST equal the Composition’s moves bound exactly. A sound certificate deriving any other depth — deeper or shallower — is declined; game vocabularies SHOULD name this decline depth_mismatch, the depth analogue of objective_mismatch, as the reference sanki vocabulary does.

The shallow direction is the one that earns the exactness: a “mate in 2” that admits a mate in 1 is a cooked problem — the composition tradition’s own verdict on a stipulation the position beats — and the family declines it by design rather than silently crediting the stronger answer, exactly as the stipulation check declines a stronger outcome. The two post-walk comparisons run in a fixed order — outcome against objective first, depth against moves second — and the first failure names the status (Puzzle Specification — Sanki §Canonical walk order, for the reference binding). Neither comparison is ever vacuous: a conforming Composition carries both tags exactly once (kind 3440 §Semantic constraints). The bound adds no parameter to verification, and the check stays linear and replayable.

Content

A single status token matching ^[a-z][a-z0-9_]{0,31}$. One token is reserved: valid. Every other token is a decline, and the vocabulary is game-defined, published in the game’s supporting document. A game’s vocabulary SHOULD name at least the failure classes this NIP’s verification model distinguishes — an undecodable position, an unreadable certificate, an illegal move, a missing defense, an unachieved leaf, the stipulation and depth mismatches (§The stipulation check, §The depth check), and the out-of-scope answer unsupported — so that a decline names what the composer repairs. The reference sanki vocabulary — eight decline tokens covering exactly these classes — is specified in its supporting document (Puzzle Specification — Sanki §Validation status vocabulary).

A consumer that recognizes nothing else still answers its user’s question — is this puzzle good — by one comparison against valid, and SHOULD surface unrecognized decline tokens verbatim.

There is no transient status, and none is possible: a validator judges an event it has retrieved, so the material can never be missing at the moment of the verdict. Republishing an identical Composition after a decline is therefore never the repair; every decline names something in the event to change. (The split family this kind once served carried an unavailable token for a Solution whose Problem could not be fetched; the merge removed the second event and the status with it — this suite’s Design Notes — Puzzles §What the merge deletes.)

A decline names a reason, never a value: depth_mismatch says that the bound is wrong, never which bound is right. This follows from carrying no derived tags, and it is deliberate — the value is a pure function of the certificate, which the composer holds. A repairing client re-derives it locally and proposes the correction; nothing is transported that the recipient does not already have.

Semantic constraints

A conforming Validation MUST satisfy all of the following:

The e tag is present exactly once, carries the marker composition as its fourth element, and its value is a 64-character lowercase hex event id. The referenced event, once retrieved, MUST be a conforming Composition; a consumer that cannot retrieve it treats the Validation as unverified, never as non-conforming (retrievability is a fact about relays, not about the event).
The p tag is present exactly once, carries the marker composer as its fourth element, and its pubkey equals the referenced Composition’s pubkey.
The content matches ^[a-z][a-z0-9_]{0,31}$.
If any l tag is present, exactly one L tag is present, every l carries that namespace as its third element, and the content is valid; conversely, an L tag is present only when at least one l tag is (a namespace declaring no labels is as contradictory as labels without a namespace). A verdict that declines carries no themes, so labels on one are a contradiction the event states about itself — and this is the only constraint of the three kinds that reads the content and the tags together.

A non-conforming Validation MUST be ignored and is no evidence of examination. Tags this NIP does not define are ignored, as everywhere in Nostr, and are never grounds for rejection.

Note what constraint 4 does not do: it never inspects a theme’s value. Whether back-rank-mate is a token the game defines, whether the validator was right to read it, whether the set is complete — none of that is decidable here, and a Validation carrying a theme no consumer recognizes is perfectly conforming. An unknown theme is a theme this consumer cannot filter on, and nothing worse.

The validated state

For one Composition, over the Validations a consumer can see:

A Composition is validated if and only if, for at least one validator in the consumer’s trusted set, that validator’s canonical verdict for it (§Validator discretion) is valid.

For a non-equivocating validator — the entire honest population — the canonical verdict is simply their one verdict, and the rule reads exactly as “some trusted validator said valid”. The canonical-verdict indirection exists only to make equivocation resolve deterministically instead of splitting consumers. Beyond that there is no fold, no ranking, and no tie to break across validators, because there is nothing to arbitrate: the exercise and its proof arrived together under one signature, so a Composition has exactly one certificate and a verdict is about that certificate alone. A validated Composition’s statement — “force a mate in moves” — is its own stipulation, realized exactly.

Because the rule is a reading and not a record, nothing announces it. There is no event meaning “this Composition is now a puzzle”, no flag set on the Composition — which is immutable — and nothing for the composer or the validator to publish afterwards. An application shows a validated Composition the moment its own view of the trusted set’s Validations includes a valid one, and that is the whole of the mechanism: a consumer that has both events has the state, a consumer that has only the Composition has an unvouched artifact, and neither had to be told. It is the same shape by which a Game Session (kind 3422) appears in an application because the trusted arbiter signed it — the signature of a trusted party IS the admission, and no further act completes it.

The state is pure and consumer-computable: same trusted set, same events, same answer, with no authority deciding it. It is also stable and monotone for non-equivocating validators — a verdict is final for its (validator, Composition) pair and nothing revises or retracts, so a Composition validated once stays validated for that consumer. The qualification is deliberate: an equivocating validator’s later contradictory verdict can change which of its verdicts is canonical (or void its voice entirely, §Validator discretion), and that is intended — a validator that contradicts itself has forfeited stability, not the model. A Composition declined by one validator may still be validated by another the consumer trusts; a consumer that trusts several validators and sees them disagree holds a checkable signal, not a paradox: any engine-holder can replay both verdicts and see which is wrong.

Credit

One name, attribution and nothing more: the composer — the Composition’s signer, author of both the exercise and its proof. The credit is permanent by construction: there is no second contributor to rank against, and no later event moves it. Where several Compositions share one exercise (kind 3440 §Duplication), each carries its own composer’s credit; none displaces another, and the earliest is not thereby canonical — nothing in this family selects between them, and a consumer that merges them for display SHOULD credit all of them.

Client guidelines

Feeds and profiles. A Composition enters activity surfaces — the composer’s profile, their timeline, their followers’ timelines — only at the first valid Validation from a trusted validator, rendered with its realized stipulation and the composer’s credit resolved to a profile (kind 0). Before that it renders only where its author goes looking for it. This is the diffusion path: author-signed artifact, validator-signed overlay admitting it to the feeds — no authority key between composer and audience, and no feed slot without a replayable verdict. The gate applies to every path into a feed, including indirect ones: a reaction, a repost or a curated set pointing at an unvalidated Composition MUST NOT carry it into an activity surface, or the gate is decorative.
Playing a validated composition. The certificate answers every defence, so an engine-free client can play the opponent with any covered reply — varying them across attempts — and can offer the defender’s longest resistance by descending the deepest subtree at each node. Accept the solver’s move iff it matches the certificate’s move at the current node. Where several validated Compositions share one exercise (kind 3440 §Duplication), accept the move iff it matches the node move of at least one of them still consistent with the moves played so far, then narrow the set to those that remain consistent: a player who finds a proved alternative key is answering correctly, and rejecting them because the client loaded a different proof is a defect. A client that does not merge exercises plays one Composition and is equally conforming.
Repairing a decline. Map the status token to the step it invalidates rather than to a generic error: a broken position sends the composer back to the board, a broken proof to the search, a mismatch to a choice between correcting the certificate and restating the stipulation the certificate actually realizes. Re-derive the correct value locally — the verdict does not carry it (§Content).
Verifying (optional). Any engine-holding party MAY replay a validator’s check — linear time — and drop a validator that misjudges. That is the entire trust mechanism, and it is enough.
Watching. Validators: subscribe to kind 3440 for the games served, or to #p on their own pubkey for addressed work. Composers: #p on their own pubkey for their verdicts. Consumers: kind 3441 by trusted authors, joining #e to the Compositions they display.

Security considerations

A validation is an assertion with a linear-time refutation. No search stands between a consumer and a recount. False valids and false declines are equally checkable; detection, not prevention, is the guarantee, and it is enough because the cost of checking is the cost of reading.
No slot to race. With one certificate per Composition and no canonical selection, there is nothing for an observer to front-run: an attacker who copies a published Composition publishes a second artifact under their own key, competing for attention and never for a protocol-assigned credit. Consumers that merge duplicate exercises SHOULD present the earliest created_at first and credit all composers.
Validator pluralism. Divergent verdicts across validators — an advantage criterion, a bug — are public and attributable; consumers scope trust per validator, as with every authority family. A validator addressed by a p tag has no privileged standing: the composer chooses whom to ask, the consumer chooses whom to believe, and the two choices are independent by design.
What a valid does not say. It says the certificate realizes the stipulation. It does not say the key is unique, that the position is aesthetically sound, or that the position ever occurred in the referenced game. Clients SHOULD NOT render valid as an endorsement of anything but the stipulation.

References

Composition (kind 3440) — the stipulated position and its certificate, the artifact this kind judges.
Canonical Timing — canonical timing and the meta-resolution behind the (validator, Composition) slot rule.