Expand description
Pins — CORD-04 §7. A pin does not quote a message; it proves one.
One Pin List per Channel on the Control Plane (vsk 11, coordinate
pins_locator(community_id, channel_id)), replaced entire per edit like the
Banlist. Each entry carries the original kind-20013 seal verbatim plus the
message’s disclosed NIP-44 keys, so any reader able to open the list’s form
verifies author, words, Channel, and signed time — holding no history and no
old keys. Compaction re-wraps the head across rotations, which is the whole
point of the placement.
Wire format shared with Armada’s pins.ts — entry JSON, both content forms,
and the caps are cross-client surface. Divergence silently breaks pin
verification between clients.
Structs§
- Edited
Content - PinEdit
Bundle - An Edit’s proof bundle: the same disclosure, for the revision.
- PinEntry
- One wire entry. Optional fields are omitted when absent (matching the
reference implementation’s JSON), and unknown fields are carried through
extraso republishing an entry never strips what a newer client added. - Read
PinList - A read list: its entries, or the fact it stayed dark.
- Verified
Pin - A pin that passed the full §7 verification — safe to render.
Enums§
- PinBuild
Failure - Why a message could not be pinned — each cause needs a different answer.
Constants§
- PIN_
MAX_ CONTENT_ BYTES - PIN_
MAX_ ENTRIES - Structural caps (CORD-04 §7 Limits) — a violating edition reads as EMPTY.
Functions§
- build_
pin_ edit_ bundle - Build an Edit’s proof bundle from its opened stream — the same disclosure
as an entry, for the revision (§7 Edits). Verification-mirrored like
build_pin_entry: refuse to build whatverify_edit_bundlewould drop. - build_
pin_ entry - Build a pin entry from an opened chat message, with the reason attached on refusal. Requires the Channel’s stream conversation key at the message’s epoch — i.e. the pinner can read what they pin. A pinner told “that message is from an epoch you no longer hold” when the real cause is a non-encrypted seal would retry forever, so the caller gets the distinction.
- pin_
killed_ by - Whether a kind-5 kills this pin: matched by the RECOMPUTED rumor id against
the delete’s
etags, honored only when the delete’s author equals the pin’s proven author. - read_
pin_ list - Read a pin list edition’s
content(§7 Limits): the byte cap judged on the exact carried bytes by every reader; the entry cap by whoever can open the form. A violating or unreadable-as-JSON edition reads as an EMPTY list — never refused from the fold. - serialize_
public_ pin_ list - Serialize a pin list’s
contentfor a PUBLIC Channel (plaintext — the plane’s wrap is the gate). Errors on a cap violation: a writer must never publish an edition every reader would read as empty. - serialize_
sealed_ pin_ list - Serialize for a PRIVATE Channel: the entries sealed under the Channel’s
group conversation key at
epoch. Both caps are checked on the final carried bytes, the sealed envelope living INSIDE the byte cap. - verify_
pin_ entry - The §7 verification, holding nothing but the pin and the list’s Channel:
seal kind + signature → MAC → decrypt → rumor checks (author equality, chat
kind, channel binding) → recomputed id.
Noneon ANY failure; a failed entry is dropped alone, its edition folds normally. - with_
proven_ edit - Attach the newest provable Edit to an entry (§7 Edits). Requires the Channel conversation key of the Edit’s own epoch — i.e. the curator can read it. Returns the entry unchanged when the Edit cannot be proven, so a refresh never downgrades a good pin into a broken one.