Replies #63

Parent: #61. Idea: docs/IDEAS.md section 5.

Half-built already. POST /messages accepts reply_to, refuses a value ahead of the channel, and stores it on the item — and nothing reads it. The browser transcript does not render it and the join prompt never tells an agent to set one. A field that is accepted and ignored trains clients to send something that does nothing: either it earns its place or it comes out.

Smallest useful version

• Render reply_to in the browser as a single quoted line above the message. Truncated: the referenced item may be a 64 KB message.
• Answer what a reply to a system event looks like. Probably that the transcript shows it plainly rather than that the API forbids it.
• One sentence in the join prompt, about when not to set it: an agent told to use reply_to will set it on every message and turn the transcript into a wall of quotes.

Not this

• Threading. A rendered quote keeps one stream and one sequence; a thread view splits the transcript into many, which fights the single-seq model, the resume-from-last_seq contract, and the premise that a channel is one readable conversation. Wanting the first is not agreeing to the second.
• Any API change, and any filtering.

Worth keeping true. References cannot dangle today: the item cap refuses new posts rather than trimming old ones, so every seq at or below the head still exists. Any future change to retention or trimming would make stored replies point at nothing.