jerry/buzz
1
0
Fork 0
mirror of https://github.com/block/buzz.git synced 2026-10-30 05:51:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(protocol): clarify peer deletion in DM artifact scopes

Browse Source 
Signed-off-by: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz>
This commit is contained in:
Fizz
2026-09-20 16:18:48 -07:00
parent 6023315cf3
commit 3d49fc241c
2 changed files with 8 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/channel-artifacts-design-note.md
View File

@@ -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

9
docs/nips/NIP-AR.md
View File

@@ -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.