Describe the bug
Deleting a group DM from Buzz Desktop appears to succeed — the row disappears from the sidebar and never comes back — but the channel is still fully alive on the relay: same participants, same messages. No error is shown at any point. The user is left believing a conversation was deleted when it was not.
The underlying authorization gap is #4739: DM channels are owned by the relay's own identity and every participant is enrolled as member, so no principal can satisfy the delete check. The bug reported here is that Desktop does not surface that rejection — it applies the deletion to its local state anyway.
Steps to reproduce
- Have a group DM with 3 participants.
- Delete it from the Desktop UI.
- Observe the row disappear from the sidebar, with no error.
- Query the relay for that channel: it still returns the channel, its full member list and its full message history.
Expected behavior
Either the deletion propagates to the relay, or Desktop surfaces the rejection and leaves the conversation in the list. A local-only removal that looks identical to a successful delete is the worst of the three.
Actual behavior / evidence
Read back from the relay after the UI delete: channel present, 3 members, all messages intact.
Running the same operation through the bundled CLI, signed with a participant's key, is rejected — which is what Desktop is presumably swallowing:
$ buzz channels delete --channel <group-dm-uuid>
{"error":"relay_error","message":"relay error 400: invalid: only owner can delete group"}
$ buzz channels remove-member --channel <group-dm-uuid> --pubkey <participant>
{"error":"relay_error","message":"relay error 400: invalid: actor not authorized"}
Desktop's local state is consistent with a purely client-side removal. In ~/Library/Application Support/xyz.block.buzz.app:
channel-head-cache.db → no channel_head row for that channelobserved-unread.db → no channel_latest and no unread_membership row for itobserved-unread.db → but observed_events still holds rows for that channel
i.e. the listing/membership records were dropped locally while the raw events remained.
Limits of this report: I did not instrument the UI click itself, so I cannot show the failed request; the local-DB state is post-hoc. The relay-side result and the CLI rejections are directly measured.
Version and platform
- Buzz Desktop 0.5.19 (macOS 25.6.0), self-hosted relay
Additional context
Root cause of the rejection: #4739. Related dead end for stale agent memberships: #5754. Note that a group DM is also not listed anywhere in the sidebar once removed, so there is no way back to it from the UI even though it still exists and still receives messages.
Describe the bug
Deleting a group DM from Buzz Desktop appears to succeed — the row disappears from the sidebar and never comes back — but the channel is still fully alive on the relay: same participants, same messages. No error is shown at any point. The user is left believing a conversation was deleted when it was not.
The underlying authorization gap is #4739: DM channels are owned by the relay's own identity and every participant is enrolled as
member, so no principal can satisfy the delete check. The bug reported here is that Desktop does not surface that rejection — it applies the deletion to its local state anyway.Steps to reproduce
Expected behavior
Either the deletion propagates to the relay, or Desktop surfaces the rejection and leaves the conversation in the list. A local-only removal that looks identical to a successful delete is the worst of the three.
Actual behavior / evidence
Read back from the relay after the UI delete: channel present, 3 members, all messages intact.
Running the same operation through the bundled CLI, signed with a participant's key, is rejected — which is what Desktop is presumably swallowing:
Desktop's local state is consistent with a purely client-side removal. In
~/Library/Application Support/xyz.block.buzz.app:channel-head-cache.db→ nochannel_headrow for that channelobserved-unread.db→ nochannel_latestand nounread_membershiprow for itobserved-unread.db→ butobserved_eventsstill holds rows for that channeli.e. the listing/membership records were dropped locally while the raw events remained.
Limits of this report: I did not instrument the UI click itself, so I cannot show the failed request; the local-DB state is post-hoc. The relay-side result and the CLI rejections are directly measured.
Version and platform
Additional context
Root cause of the rejection: #4739. Related dead end for stale agent memberships: #5754. Note that a group DM is also not listed anywhere in the sidebar once removed, so there is no way back to it from the UI even though it still exists and still receives messages.