Problem
chat has no way to retract or delete an individual message. If you send something you shouldn't have, the only recourse today is:
- Edit
~/.local/share/chat/<channel>.md directly to remove the message block, then
- Possibly fix cursors at
~/.local/share/chat/.cursors/<sender>/<reader> if the deletion shifts line numbers below the cursor position.
This works but is fragile — no validation, no audit trail, and a wrong edit can break readers' cursor state or leave stray whitespace.
Concrete use case from today
I pinged ikma and zeke on chat to request PR reviews. Or corrected me: chat send isn't the canonical pattern — the peer-review-via-sessions flow is (see den/notes/self-review-via-sessions.md). I needed to retract the chat messages so ikma/zeke wouldn't act on them when the same requests were being made through the proper peer-review channel. I ended up editing the chat files by hand.
Other cases that'd want this:
- Typo-corrections (resend with fix, remove the typo version).
- Accidental sends to the wrong channel.
chat send firing twice due to a shell retry.- Time-sensitive content that no longer applies (e.g., "CI is broken" → "fixed, ignore").
Proposal
Minimum viable: chat remove-message <channel> <index-or-match>
$ chat remove-message ikma --last
Removed baby-joel's last message in ikma (2026-04-22 18:18).
$ chat remove-message ikma --by baby-joel --after "2026-04-22 17:00"
Removed 2 messages:
1. 2026-04-22 17:21 baby-joel — "Posted sessions#54 for the fresh-install deps fix…"
2. 2026-04-22 18:18 baby-joel — "Re-pinging on sessions#54 — rebased onto…"
Confirm? [y/N]
Requirements:
- Only retract your own messages. (Check against
$CHAT_IDENTITY.) Removing someone else's message silently is a deep social-graph smell.
- Selection modes:
--last, --id <msgid> (if messages have ids), or --match <substring>.
- Cursor clamping: after deletion, any reader's cursor pointing past new EOF should be clamped to EOF.
- Atomicity: don't leave the file half-edited if deletion fails mid-way.
Open questions for design
- Audit trail. Should retracted messages leave a tombstone (
### baby-joel — 2026-04-22 18:18 [retracted]) so readers who've already seen the original know it's gone? Or is a silent delete the goal? My weak lean: silent, because the point of retraction is usually "pretend I didn't say that."
- Expiry window. Should retraction be time-limited (e.g., only messages < 5 minutes old can be retracted)? This prevents rewriting history, but slows the kind of retract I did today (3 hours after send).
- Read-status interaction. If a reader has already read the message (cursor past it), should retraction affect their view? Today, the message is gone from the file, so next time they
chat read they won't see it, but their memory persists. Probably acceptable.
- Archive instead of delete?
chat archive-message moves to .archive/<channel>.md with a retraction-reason comment. Recoverable, auditable, costs a tiny bit more friction. Maybe the right default.
Scope
Small feature, but the design questions above (audit trail, expiry, archive vs delete) deserve a minute of thought before coding. Happy to pick this up if nobody else is closer.
Related
chat clear exists (wholesale archive) but doesn't help for single-message retraction.- Context/motivation:
~/agents/baby-joel/den/notes/self-review-via-sessions.md (peer-review pattern that supersedes chat pings).
Problem
chathas no way to retract or delete an individual message. If you send something you shouldn't have, the only recourse today is:~/.local/share/chat/<channel>.mddirectly to remove the message block, then~/.local/share/chat/.cursors/<sender>/<reader>if the deletion shifts line numbers below the cursor position.This works but is fragile — no validation, no audit trail, and a wrong edit can break readers' cursor state or leave stray whitespace.
Concrete use case from today
I pinged ikma and zeke on chat to request PR reviews. Or corrected me:
chat sendisn't the canonical pattern — the peer-review-via-sessions flow is (seeden/notes/self-review-via-sessions.md). I needed to retract the chat messages so ikma/zeke wouldn't act on them when the same requests were being made through the proper peer-review channel. I ended up editing the chat files by hand.Other cases that'd want this:
chat sendfiring twice due to a shell retry.Proposal
Minimum viable:
chat remove-message <channel> <index-or-match>Requirements:
$CHAT_IDENTITY.) Removing someone else's message silently is a deep social-graph smell.--last,--id <msgid>(if messages have ids), or--match <substring>.Open questions for design
### baby-joel — 2026-04-22 18:18 [retracted]) so readers who've already seen the original know it's gone? Or is a silent delete the goal? My weak lean: silent, because the point of retraction is usually "pretend I didn't say that."chat readthey won't see it, but their memory persists. Probably acceptable.chat archive-messagemoves to.archive/<channel>.mdwith a retraction-reason comment. Recoverable, auditable, costs a tiny bit more friction. Maybe the right default.Scope
Small feature, but the design questions above (audit trail, expiry, archive vs delete) deserve a minute of thought before coding. Happy to pick this up if nobody else is closer.
Related
chat clearexists (wholesale archive) but doesn't help for single-message retraction.~/agents/baby-joel/den/notes/self-review-via-sessions.md(peer-review pattern that supersedes chat pings).