Repository source: docs/specs/post_reaction_record_v1.md
Post Reaction Record V1
This document defines the canonical append-only post-reaction record family for post and comment flagging.
Scope
One ASCII text file represents one post-reaction mutation event.
Canonical post-reaction files live in
records/post-reactions/.V1 supports additive tag events only.
File Structure
A post-reaction file has two parts:
A contiguous header block at the top of the file
A body separated from the headers by one blank line
Headers use this form:
Key: Value
The body is optional and is usually empty in V1.
Required Headers
Record-ID: unique identifier for the post-reaction recordCreated-At: RFC 3339 UTC timestamp such as2026-04-15T15:30:00ZPost-ID: target post or comment IDOperation:addTags: space-separated validated tag tokens
Optional Headers
Author-Identity-ID: canonical identity reference for the reacting authorReason: short ASCII explanation
Tag Token Rules
Each tag token must:
use ASCII only
use lowercase only
contain only
a-z,0-9, and single internal-not begin or end with
-
Semantics
Post-IDmay target a root post or a reply/comment.Created-Atis authoritative canonical time for ordering.Operationis limited toaddin V1.duplicate tags in one record are tolerated and collapse to one normalized tag in parser and reducer behavior.
when
Author-Identity-IDis present, it must use the retained lowercase OpenPGP identity form.
Canonical Path Rule
the file path must be
records/post-reactions/<record-id>.txtthe filename stem must exactly match
Record-ID
Example
Record-ID: post-reaction-20260415153000-ab12cd34
Created-At: 2026-04-15T15:30:00Z
Post-ID: reply-001
Operation: add
Tags: flag
Author-Identity-ID: openpgp:0168ff20eb09c3ea6193bd3c92a73aa7d20a0954
Reason: Approved user flagged reply-agent content
Optional author signature
A detached ASCII-armored OpenPGP signature may accompany the exact record bytes
as <record-id>.txt.asc. Unsigned historical records remain valid. A supplied
signature must verify against Author-Identity-ID; invalid signatures are never
treated as absent. Explicit online actions use the existing format with an empty
body and a single label/tag, canonical LF endings, and a safe family-prefixed
client identifier. Signing does not change scoring or moderation policy.