Group DMs can never be renamed — no principal ever holds owner/admin on a DM channel, and community owner has no bypass

[samuraizeke]

Motivation

Renaming a group DM is impossible for anyone, by construction:

• The relay creates DM channels under its own identity, and every participant is enrolled with the plain member role. No human ever gets owner or admin on a DM.
• The kind-41 handler (crates/buzz-relay/src/handlers/side_effects.rs) requires channel owner/admin for name/about/archived/visibility/ttl changes. The only escape hatch is being the NIP-OA owner of an owner-role agent in the channel, which a DM never has either.
• Community ownership doesn't help. There is no RELAY_OWNER_PUBKEY bypass in that code path, so even the community owner gets actor not authorized for name/about/archived/visibility/ttl changes.
• Desktop is consistent with this: ChannelManagementSheet.tsx gates the name editor on channelType !== "dm", so the control never renders.

Net effect: a group DM is stuck displaying as "Group DM (N)" (or the participant list) forever. Ran into this on a self-hosted relay wanting to name a 3-person founders DM. The only working path I found was flipping my role to owner directly in Postgres, sending the kind-41 through the relay, then flipping it back. That obviously shouldn't be the supported path.

Proposed solution

Let DM participants rename their own DM. Slack's model here is the least surprising: any member of a group DM can set its name, and the name is scoped to that conversation. Concretely, in the kind-41 privileged-tag check, treat channelType == "dm" + actor is an active participant as sufficient for the name tag (the other privileged tags can stay locked down).

Alternatives considered

• Grant the DM creator owner at creation time. Works, but resurrects the orphaned-owner problem (Add a supported, audited recovery path for orphaned channel ownership #2928) when that identity goes away.
• A community-owner bypass for channel metadata. Broader than needed for this, and Add a supported, audited recovery path for orphaned channel ownership #2928 deliberately argues against widening community-owner authority over healthy channels.
• Desktop-side local aliases (client-only names). Avoids relay changes but every participant sees a different name, which defeats the point of naming a shared conversation.

Additional context

Related but distinct: #2928 (recovering orphaned channel ownership) and #4225 (owner_only add policy has no admin override). This one differs in that there is no owner to recover — DMs never have one.

Duplicate search: none found for DM renaming specifically.

[bonpiedlaroute]

Taking this one.

Small correction first: the gate is kind:9002 (NIP-29 edit metadata), not 41 — it's
in validate_admin_event, side_effects.rs:595.

Your read is right, and I'd put it more strongly: nobody can satisfy that check on
a DM. buzz-db/src/dm.rs enrols participants with a hardcoded role
(VALUES ($1, $2, $3, 'member', $4) — commented "always member for DMs"), and a
DM never has an owner-role agent for the NIP-OA fallback either. So it isn't a rule
against renaming, it's a predicate no principal can meet — community owner included.

The handler already has the tier this needs: two lines above the check,
"topic/purpose allow any member". I'll move name onto it for channel_type == "dm"
only, with the other privileged tags still locked and a test that a rename can't
smuggle visibility through. Happy to scope it differently if you'd rather —
creator-only, or a community-owner bypass.

Desktop hides the name editor for DMs, so that unlock would be a separate PR.

[eireal]

The same ownership gap blocks two more operations, not just renaming — worth covering in one pass while you're in validate_admin_event.

Measured today on Buzz Desktop 0.5.19 (macOS) against a self-hosted relay, from a 3-participant group DM, using the bundled CLI signed with a participant's key:

Operation	Relay response
channels remove-member	400 invalid: actor not authorized
channels delete	400 invalid: only owner can delete group

Because DM participants are enrolled hardcoded as member and the channel is owned by the relay's own identity, no principal can delete a group DM or evict a participant from one — same construction you documented for name. The community owner has no bypass here either.

This matters beyond cosmetics: a stale agent identity that ends up in a group DM can never be removed, and the conversation itself can never be closed. It keeps receiving everything published there. (Related: #5754, same dead end for stale agent memberships in one-to-one DMs.)

If the fix lands as "active participant is sufficient for name", consider extending the same predicate to remove-member (self-removal at minimum, i.e. leave) and to deleting a DM whose participants all agree — otherwise DMs stay undeletable by construction after this issue closes.