From 3d49fc241c72225c792b87ff780b17930f1f0f3e Mon Sep 17 00:00:00 2001 From: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz> Date: Sun, 20 Sep 2026 16:18:48 -0700 Subject: [PATCH] docs(protocol): clarify peer deletion in DM artifact scopes Signed-off-by: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz> --- docs/channel-artifacts-design-note.md | 3 ++- docs/nips/NIP-AR.md | 9 ++++++--- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/channel-artifacts-design-note.md b/docs/channel-artifacts-design-note.md index a526d2eac7..88c50f8f62 100644 --- a/docs/channel-artifacts-design-note.md +++ b/docs/channel-artifacts-design-note.md @@ -29,7 +29,8 @@ project or repository before they can track a task. - **Editing follows the channel’s permissions.** People allowed to contribute in the home channel can update the work; it is not locked to whoever created it. Moving requires permission to contribute in both places; deleting requires - channel administration. In an open channel, people allowed to post can also + channel administration, except in a direct message where participants are + peers and can delete shared work. In an open channel, people allowed to post can also update its work, even if they have not joined the channel. - **Give growing work more room deliberately.** A task can move from a thread into a new channel and remain the same task. Before moving, show who will be diff --git a/docs/nips/NIP-AR.md b/docs/nips/NIP-AR.md index 2518ea261e..6f0b9b4d9f 100644 --- a/docs/nips/NIP-AR.md +++ b/docs/nips/NIP-AR.md @@ -122,7 +122,7 @@ exclude agents. |-----------|------------------------------------| | Create | Write permission in destination channel | | Update content, title, or anchor within home | Write permission in current home | -| Delete | Administration permission in current home | +| Delete | Administration in current home; in a DM, participant write permission | | Move to another channel | Write permission in source AND destination | Being an artifact's creator is attribution, not a permanent exclusive editing @@ -286,6 +286,7 @@ These are implementation requirements, not tests claimed to pass in this PR. | Another channel writer edits an artifact | Valid with current head; author accurately recorded | | Read-only principal or removed creator in a private home edits | Rejected | | Non-member permitted to post in an open home edits | Valid under the same message-admission gates | +| A current DM participant deletes an artifact | Valid with participant write permission and current head | | Two revisions race on one head | Exactly one accepted | | A task joins/leaves a project in another channel | Same identity/home; both affected views refresh; no access grant | | Malformed known type or unknown type/version | Safe fallback; no destructive edit | @@ -304,8 +305,10 @@ No per-artifact audience lists, relay-executed plugins, schema-registration service, generic automation engine, or one-record-per-room requirement. Existing Buzz DMs are channels: an artifact with their `h` inherits participant access just like their messages (see `handle_dm_open` in `crates/buzz-relay/src/handlers/command_executor.rs`). This is not a new DM ACL. -Administrative deletion remains gated by actual channel administration; merely -being a DM participant does not manufacture that role. Personal/no-room artifacts +DM participants are peers (existing DM creation assigns `member` to all), so +artifact deletion in a DM requires participant write permission instead of an +Admin/Owner role. The relay must determine DM type from the stored channel, +never an artifact tag. This channel-type rule does not vary by artifact type. Personal/no-room artifacts need a separately specified scope; missing `h` must not become an accidental global/private mode.