Repository navigation
No way to delete a repo announcement (kind:30617): CLI has no repos rm, and Desktop 'Delete project' is owner-gated to keys the app holds #2326
Description
Summary
Once a repo announcement (NIP-34 kind:30617) is published, there is no supported path to remove its listing from the workspace Projects tab:
- The CLI has no
repos delete/repos rm. The only deletion command,messages delete, refuses non-channel events (event <id> has no h-tag — cannot determine channel). - Buzz Desktop shows a "Delete project" action on repo cards, but it is disabled for everyone except the announcement's signing identity — and when the announcement was signed by a managed agent's key, no human in the workspace can ever use it.
notes rm(kind:30023) shows the right pattern already exists: an a-tag-only NIP-09 deletion targeting the addressable coordinate. There is no equivalent for30617:<pubkey>:<d-tag>.
Related: #714 (a-tag deletion is a no-op for non-workflow addressables on the relay side — if still current, it would also block the coordinate route for 30617).
How we got here (real workflow)
An agent announced a repo, then pushed a connectivity-test branch before the real history. On relay-hosted repos the first branch pushed becomes the permanent default branch, deletion of the current branch is refused, and the storage protocol never deletes — so the repo id was burned. The agent re-announced under a new id and marked the old announcement "DEPRECATED" (announcements are replaceable, so renaming works). Result: permanent DEPRECATED husk cards visible to every workspace member in the Projects tab, deletable by no one — the signing key's tooling (CLI) lacks the command, and the humans' Desktop buttons are ownership-gated off.
Suggested fix
buzz repos rm --id <d-tag>mirroringnotes rm: read-before-write, then an a-tag-only kind:5 targeting30617:<pubkey>:<d-tag>.- If relay: NIP-09 a-tag deletion is a no-op for kind:30023 (and all non-workflow addressables) #714 still applies to 30617, extend the relay's coordinate soft-delete to cover it (or all parameterized-replaceable kinds), so the CLI and the Desktop button share one working path.
Environment
- Hosted relay (
*.communities.buzz.xyz), Buzz Desktop + bundled CLI, 2026-07-22.
Activity
Dirtywater97 commentedon Jul 26, 2026
Hit this too, from the CLI side.
buzz reposhascreate/get/list/protectand norm, so there is no path to remove a repo announcement from either surface.Because
repos createis an upsert on thedtag, the only mitigation is to overwrite the announcement with a tombstone name ("RETIRED — do not use") and leave it in the list forever.buzz messages deleteis not a fallback either — it rejects the event:event <id> has no h-tag — cannot determine channel, since a kind:30617 is not channel-scoped.Adding
buzz repos rm(NIP-09 kind:5 by the announcing key) would at least give owners a way out that does not depend on Desktop holding the key.realChanho commentedon Aug 1, 2026
Two updates from reproducing this on a hosted relay today (relay + Desktop at 0.5.3, repo HEAD 19d57b0).
1. #714 is resolved — the coordinate route is already open for 30617.
handle_a_tag_deletionno longer falls through to the debug-only_ =>arm. There is now a generic branch for every parameterized-replaceable kind:crates/buzz-relay/src/handlers/side_effects.rs—k if is_parameterized_replaceable(k) => … soft_delete_by_coordinate(…), with a comment citing relay: NIP-09 a-tag deletion is a no-op for kind:30023 (and all non-workflow addressables) #714 directly. Landed in d88313f (feat(desktop): delete a message by clearing its edit to empty #3813, 2026-07-30).crates/buzz-db/src/event.rs—soft_delete_by_coordinateexists, scoped to versions at or before the deletion'screated_at.crates/buzz-core/src/kind.rscarries a compile-time assertion for it.Verified end-to-end against a hosted relay, using the kind this issue's dependency names (30023): created a note, ran
notes rm(a-tag-only deletion), and the note disappeared fromnotes lswithnotes getreturningnot_found.So suggested fix (2) in this issue is already done. Only (1) remains.
2. There is a cheaper fix than new CLI surface, for exactly the case in the description.
For an announcement signed by a managed agent's key, the relay side already has a path open.
validate_standard_deletion_eventaccepts the target's NIP-OA owner in addition to the author itself (viais_agent_owner, backed byusers.agent_owner_pubkey), so the workspace owner's key is already authorized server-side to delete an announcement signed by an agent they own.The Desktop gate uses a different rule:
desktop/src/features/projects/lib/projectsViewHelpers.ts—isProjectOwnedByCurrentUseris a plain pubkey equality, and it is what gates the menu item inui/ProjectCards.tsx.desktop/src/features/projects/hooks.ts—deleteProjectrepeats the same equality before signing, and the event it builds (kind:5 with anatag only) is exactly the shape the relay now honours.Widening those two checks to include the NIP-OA owner path would make the existing button work for the husk-card case without adding any new command.
buzz repos rmis still worth having — agents have no Desktop, so an agent that announces a repo has no way to retract it. But it is no longer the only route.