Conversation
Signed-off-by: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🔐 Codex Security Review
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9a8703e992
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| Channel read permission governs every artifact read, including lookups, history, search, previews, counts, and live updates. Threads inherit their channel's audience. Membership and visibility changes take effect on subsequent reads and deliveries. | ||
|
|
||
| Write permission means permission to post a kind-9 message in the channel, including authentication, token restrictions, moderation, and archive checks. This includes agents and, where channel policy permits, nonmembers of open channels. Artifact writes use `channels:write`. |
There was a problem hiding this comment.
Use messages:write here, or explicitly require both scopes rather than defining artifact authorization as equivalent to posting a kind-9 message. In this repository, kind-9 writes require MessagesWrite (crates/buzz-relay/src/handlers/ingest.rs) while ChannelsWrite is documented for creating and updating channels (crates/buzz-auth/src/scope.rs); consequently, a least-privilege agent or guest token that can post messages would satisfy every stated permission in this paragraph and the table below but still be unable to create or edit an artifact. This also works against the product contract's requirement to validate the design against the intended human/agent access model.
AGENTS.md reference: AGENTS.md:L13-L18
Useful? React with 👍 / 👎.
|
|
||
| Defines `kind:45010` for editable records called **artifacts**. Each artifact has one home channel and may be attached to a thread. Its home determines who can read it. Any number of artifacts, including of the same type, may share a channel or thread. | ||
|
|
||
| The relay manages identity, access, and revisions. Clients define the content types, such as `buzz.task` or `buzz.project`. |
There was a problem hiding this comment.
buzz.project identity
Do not advertise buzz.project as an artifact type without distinguishing it from the repository's existing Project entity. VISION_PROJECTS.md and NIP-MP already define projects as kind:30621 coordinates, whereas this example gives a project an artifact UUID and channel-scoped revision chain; clients following the example would therefore create two incompatible objects called a Buzz project, and task references could not resolve against the existing project routes or repository membership. Use a different type name or define an explicit mapping to the canonical 30621:<pubkey>:<d> project coordinate.
AGENTS.md reference: AGENTS.md:L13-L18
Useful? React with 👍 / 👎.
wesbillman
left a comment
wesbillman
left a comment
There was a problem hiding this comment.
Carl, an automated reviewer, commenting via Wes’s GitHub account.
Review clear for the proposal-only scope
Reviewed exact head 9a8703e992ada58194bd98bc2ad14c4c76481f48 against base 77729abfb692b25a0f4ec4a69add86af2e32c0dd. The complete delta is the new 102-line docs/nips/NIP-AR.md; no implementation changes. No blocking finding. This is not an implementation-readiness certification or an approval review.
The draft fits the relay-owned, channel-scoped product direction: stable community-local identity, atomic prev-based revisions, access checks across read surfaces, source-and-destination write authorization for moves, durable source removal, and terminal deletion. I traced create/edit/conflict, anchor loss, rights changes, moves/history, deletion, current-state filtering, and client fallbacks. The explicitly deferred query/pagination/error/limit-discovery and removal/replay wire formats, numeric limits, database layout, and scale guarantees remain deferred.
Nonblocking clarifications
- Unchanged anchors: line 61 explicitly permits edits after anchor loss. Read that as grandfathering an unchanged
root, including the delete snapshot that preserves it. To avoid “supplied” being read as every complete snapshot, consider “On creation, or when changed from the previous accepted revision...” for the liveness check. The stated exception makes this clarification, not a blocker. - Token scope composition: line 67 selects
channels:writewhile borrowing kind-9 posting eligibility, including token restrictions. ExistingMessagesWriteandChannelsWriteare distinct scopes. Before implementation, say whetherchannels:writereplaces or supplements the message scope, with other posting checks unchanged. I do not treat the explicit artifact-specific scope as a deployed authorization regression.
Deferred work and existing suggestions
Current-state queries already require current tags only and omission of deleted artifacts. A future live filtered projection must handle leaving a filter and reconnect reconciliation, but this draft does not define that subscription surface. Requiring its full delivery design now would expand the agreed scope.
The illustrative buzz.project name and relationship tag do not define a replacement for NIP-MP kind:30621 or grant repository authority. The existing bot suggestion is useful future schema/naming feedback, not a blocker on this envelope proposal. GitHub history contains no human ruling adopting either bot suggestion; the author's closure of #7771 alone is not evidence that maintainers rejected that design.
Validation limits
Source-only review and fresh independent adjudication on the pinned Blox host; no checkout, builds, tests, or PR-code execution. One existing exact-head CI snapshot showed 8 successful and 28 skipped checks, with no pending or failing check. Application suites were path-skipped, and the substantive Codex security-review job was skipped with its required-range comment still outstanding. Those checks do not establish runtime correctness or security-review completion. No CI reruns or monitoring.
2 participants
Summary
Adds a short, proposal-only NIP-AR: Channel Artifacts in
docs/nips/NIP-AR.md, as a simpler alternative to the closed #7771.prev-based revisions.Remaining design work
This is a compact draft, not a complete implementation-ready wire contract. Concrete query request/pagination/error/limit-discovery formats, removal/replay wire details, and numeric query limits remain follow-up work. Prefer extending shared WebSocket
REQ/ HTTP/querysurfaces rather than adding plugin-specific endpoints. No database layout or scale guarantees are proposed.Related issue
Closest prior proposal: #7771 (closed). Searched existing PRs and issues for channel artifacts; no matching issue found.
Testing
git diff --check.