Skip to content

Replies #63

Description

@david-sling

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:webLanding page and channel pagetype:taskA unit of implementation work

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions