67 Commits

Author	SHA1	Message	Date
Luke Tornquist	e3a0f3d59d	feat(cli): send NIP-FI evidence via credential chain and Buzz desktop (#8999) ... ## Summary Relays that enforce federated identity (NIP-FI) reject every protected `buzz` CLI request with `401`. The CLI never sends `Nostr-Federated-Identity`. This PR gives the CLI a credential chain, lets it present NIP-FI evidence, and lets it take its identity from Buzz desktop. Relays without NIP-FI behave exactly as before. **Credential chain** (`crates/buzz-cli/src/credentials.rs`) - Raw `Keys` are replaced by `Credentials`, which provide the public key, signing through nostr's `NostrSigner`, NIP-44, and the NIP-OA auth tag. NIP-FI evidence comes through `evidence(relay)`. - The explicit key (`--private-key` / `BUZZ_PRIVATE_KEY`) is the first link. A later link can add a signer that holds no local key (a desktop provider, for example) without reshaping callers. - Operations that need key material rather than a signature are purpose-bound methods instead of a key accessor: - `engram_d_tag` (the NIP-AE HMAC over the conversation key) - the relay-scoped GIF customer id (random and fixed for the process when there is no local key) - `buzz mem` now encrypts, decrypts and derives the `d` tag through the provider. Invalid ciphertext skips an entry; a signer failure aborts, so an unavailable credential never reads as empty memory. `buzz_core::engram` gains the composable steps behind it: `encode_body`, `event_builder`, `validate_envelope` and `check_d_tag`. `build_event` and `validate_and_decrypt` are unchanged wrappers, so `buzz-acp` and desktop callers don't move. - Agent-management drafts (`agent_management.rs`) encrypt and sign through the provider. **Evidence on every protected request** (`crates/buzz-cli/src/client.rs`) - A single `authorize` helper gets the NIP-FI assertion first, then signs the proof just before sending, so a slow mint cannot age it past NIP-98's 60 s window. It sets these on every protected route: `Authorization` (NIP-98 or Blossom kind:24242), `x-auth-tag`, and `Nostr-Federated-Identity: Bearer …`. The routes are `/query`, `/count`, `/events` (stored and moderation), `/upload`, `/media/upload`, `/media/*`, `get_authed`, `post_json_authed` and `post_json_once_authed`. - Exempt routes (`get_public`) are unchanged. - The WebSocket publish sends the header on the upgrade via `connect_authenticated_with_headers`. NIP-42 AUTH signs through the signer (`buzz-ws-client` now takes `NostrSigner`; `&Keys` callers compile unchanged). - An upgrade denial is an HTTP response under NIP-FI. `WsClientError::upgrade_rejection` returns its status and body, which map like any other relay error, so a `403` still says whether evidence or authorization was refused. A denial after NIP-42 (such as a key mismatch) is a 1008 close; `WsClientError::PolicyClose` keeps its reason and the CLI reports it as an `auth_error`. - The WebSocket publish caps each network phase as a whole, writes included: connect, AUTH challenge (with any Pongs), AUTH send plus OK, EVENT send plus OK, and a best-effort close. NIP-42 signing between phases is bounded by the signer. The relay drops a socket not signed in within 5 s, so a sign-in that is throttled or comes back after the socket closed reconnects and signs the new challenge, at most 3 connections. Each connection fetches current NIP-FI evidence for its upgrade, and a throttled sign-in is waited out between connections, so a dead challenge is never signed. EVENT is signed before connecting and sent once, after AUTH succeeds. Running out is `unavailable` (exit 2, `retryable:true`). - Relay traffic follows no redirects: reqwest strips `Authorization` across origins but not `x-auth-tag` or `Nostr-Federated-Identity`, so a 3xx is returned as a relay error. Credential header values are marked sensitive. **Headless evidence source** (`crates/buzz-cli/src/federated_identity.rs`) - Set `BUZZ_FEDERATED_IDENTITY_TOKEN` (your own NIP-FA sign-in session: a human session for your key, not an agent grant) and `BUZZ_FEDERATED_IDENTITY_ADAPTER` (the adapter base) to enable it. Both are env only: command lines are visible to other local users. - The CLI requests an assertion and the adapter mints it, through `POST {adapter}/v1/identity/assertions` with a NIP-98 proof in `Nostr-Authorization` (NIP-FA §Relay assertion). - It checks the returned pubkey and expiry, parses the assertion as a compact JWS (three base64url segments, JSON header with `alg`, JSON payload), and requires its `exp` to equal `expires_at`. It caches one assertion per process, bound to the relay when credentials are resolved, and re-mints at the earlier of half-life and 30 s before expiry; the desktop link caches and refreshes its assertion by the same rule. Concurrent callers share one mint. An HTTP proof is signed again, after current evidence, when the assertion changed while it was signed or the evidence check aged it 30 s or more, up to 3 rounds, then fails as `unavailable` (retryable). - Compared with the separate rules before: a 300 s assertion now refreshes at 150 s (was 270 s) on both links, a 40 s adapter assertion at 10 s (was 20 s), and a 20 s desktop assertion is kept for 10 s instead of fetched on every lookup. Desktop assertions now need a readable JWS header with `alg` and a non-empty signature segment. An unsupported headless relay URL now fails when credentials are resolved. - The token goes only to the adapter origin (https, or http on loopback), never follows a redirect, and never appears in errors or `Debug`. - A mint retries network errors, `429` and any `5xx` up to three attempts with jittered backoff (or the adapter's `Retry-After` on `429`/`503`, as delta-seconds or any HTTP-date form, capped at 30 s), on every path (reads, post-once, moderation, stored events, WebSocket). It then fails as `CliError::Adapter` (`adapter_error`, exit 2, `retryable:true`). Relay retry loops never repeat it. A stored write keeps `delivery_unknown` when any earlier attempt may have been delivered, so a later adapter failure never invites a re-sign. Relay mutation retries are otherwise unchanged. - An explicit port 80 relay URL (read numerically from the authority, on any scheme) is a usage error: `wss://host` means port 443, and NIP-FA has no relay on port 80. - A refusal is never retried: a non-transient status with an unreadable or truncated body is still a refusal. - Each NIP-FA denial code maps to an `auth_error` with a specific message. - These settings belong to the explicit key: without one they are not read, and when the desktop link wins a warning names them. - If an enforcing relay answers `401` and no assertion was sent, the CLI returns an `auth_error` that names both settings, or, for a desktop user, says to sign in to the community in Buzz. A desktop user's `403` hint no longer mentions `BUZZ_AUTH_TAG`. **What got simpler** - About ten request sites built `Authorization` and `x-auth-tag` themselves. Five copies of the 401/403 error-mapping block are now one `relay_error`. - The `sign_nip98` / `sign_blossom_*` helpers are gone. Proofs are a three-case `Proof` enum consumed by `authorize`. - `BuzzClient::keys()` (raw secret access from every command) is removed. Commands use `public_key()`, `sign_event` or a purpose-bound credentials method. **Desktop credential provider** (`crates/buzz-cli/src/desktop_provider.rs`, `docs/local-credential-provider.md`) Buzz desktop is a credential provider in the chain, after an explicit key: 1. An inherited `BUZZ_CREDENTIAL_PROVIDER` token (set by the desktop for the agents it launches). It decides the identity: when it is revoked, not bound to the relay or unreachable, the command fails. A paired token, which acts as the human, is never tried. That keeps a well-behaved CLI from acting as the owner by accident; it is not a boundary against an agent that can run its own commands as the owner's OS user, and the contract says so with the mitigations. 2. Otherwise, a paired token stored in the OS keychain (`keyring`; macOS native keychain, Linux Secret Service; no file fallback). A desktop that answers `denied` or `unavailable` fails the command; only an unreachable or unconfirmed advertisement is skipped. Revoked entries are forgotten. New commands: `buzz auth desktop pair` and `buzz auth desktop unpair`. The help no longer marks `BUZZ_PRIVATE_KEY` as required. The CLI talks to the desktop over the loopback contract in `docs/local-credential-provider.md` (NIP-46-shaped envelopes, `Buzz-Credential-Provider` version header, same-user check on the listening socket for paired and inherited tokens, via `/usr/sbin/lsof` on macOS, given 5 s; a check that runs out of time is a retryable `unavailable`, a wrong owner is refused). Every response's `id` must match its request, error envelopes included. Paired tokens live only in the keychain, survive desktop restarts, and are harness-neutral for agents. - **Relay binding:** tokens bind the whole relay URL (`http`/`https` read as `ws`/`wss`, lowercase host, no default port, `/` for an empty path; path and query count). The CLI sends that URL in `pair` and `federated_identity`; NIP-FA audience canonicalization is the desktop's. - **Rate limits:** a `rate_limited` answer refuses before acting, so the CLI re-sends after `retry_after` (capped at 30 s), up to four times, except a NIP-42 sign-in, whose wait goes to the WebSocket reconnect. A re-sent NIP-42, NIP-98 or Blossom proof is re-dated (new id, Blossom `expiration` moved with it); content events are re-sent exactly. If it is still throttled, the command fails as `rate_limited` (exit 2, `retryable:true`), not `auth_error`, whether the throttled call was NIP-98, event signing, NIP-42 or encryption. Transport failures are never re-sent, and relay commands are never replayed. A `buzz mem` list that is throttled partway through completes. - **Memory:** a `nip44_decrypt` answered with `invalid_request` is invalid ciphertext, so `buzz mem` skips that entry (NIP-AE filtering); any other provider failure aborts. - **Keychain changes:** each change reloads the map under a short `flock` on `~/.buzz-foundation/cli-pairings.lock` (directory forced to `0700`, lock opened with `O_NOFOLLOW`) and changes only its own instance; the lock is never held across the approval wait. An unreadable entry is refused, never overwritten; `unpair` with no instance clears it. ### Related Related: [block/buzz-app#2260](https://github.com/block/buzz-app/pull/2260) (the desktop side of the provider contract) --------- Signed-off-by: Luke Tornquist <tornquist@squareup.com> Signed-off-by: Will Pfleger <wpfleger@block.xyz> Co-authored-by: Will Pfleger <wpfleger@squareup.com> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Will Pfleger <wpfleger@block.xyz> Co-authored-by: Hayt <211b96e6a2b7f45fd4047988976c7bbbeeda0c15f3ae7b32eec20834b5a55118@buzz.block.builderlab.xyz> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-11-06 00:26:22 +00:00
Blake McAnally	b0f68a06ad	feat(cli): user status expiry and status read (#8777) ... > Replaces #8768, which was opened from a fork. ## Summary This change adds two things to `buzz-cli`. `buzz users set-status` now accepts `--expires`. The status then clears itself at that time. `buzz users status` is a new command. It reads the visible status of one or more users. ## Design `--expires` takes a unix timestamp or a duration. A duration is a number with a unit: `s`, `m`, `h`, `d`, or `w`. A bare number is a unix timestamp. The CLI had no duration parser to reuse. The only one is private to `buzz-workflow`. A small parser now lives in `users.rs`. The CLI rejects an expiry that is not in the future. It does this before it signs anything. The error text says that a bare number is a timestamp. `--expires` cannot combine with `--clear`. A status with no text and no emoji cannot have an expiry. The SDK rejects that shape. `buzz-sdk` has a new builder, `build_user_status_expiring`. It adds `["expiration", ts]` after the emoji tag. This is the tag order desktop uses. `build_user_status` now calls the new builder with no expiry. Its output is unchanged. Existing callers need no change. `users status` queries kind 30315 with `#d: general`. It picks the newest event for each author. A higher `created_at` wins. On a tie, the lower event id wins. Desktop uses the same rule. The CLI then drops a user when the newest event has no text and no emoji. It also drops a user when the status has expired. An expired status means `expiration <= now`. An older status never shows behind a newer cleared or expired one. The expiration tag is read like desktop's `parseInt`. A value such as `90abc` reads as 90. A value such as `soon` reads as no expiry. The output is an array: `[{pubkey, text, emoji, expires_at, updated_at}]`. `emoji` is an empty string when there is none. `expires_at` is `null` when the status does not expire. A user with no visible status has no row. `--pubkey` takes hex, npub, or an exact display name. It reuses the name resolver of `messages`. It is repeatable. The limit is 100, because each name costs one profile search. With no `--pubkey`, the command reads your own status. A relay response that is not valid JSON is an error. It is never an empty result. ## Testing What ran: - `cargo test -p buzz-cli -p buzz-sdk` passes. - `cargo clippy -p buzz-cli -p buzz-sdk --all-targets -- -D warnings` passes. - `cargo fmt --all --check` passes. - `just file-size-check` passes. The CLI tests use an axum fake relay. They call the production functions `publish_status` and `read_statuses`. These are the same functions that the commands call. The tests cover these cases: - One publish carries the right tags. - Bad expiries cause no publish. - Expired, cleared, and malformed statuses. - Newest-event choice and tie-break. - Hex, npub, and name input. - The 100-pubkey limit. - An invalid relay response. - A publish followed by a read. Interop evidence: I ran the real `buzz` binary against a local fake relay. No live relay was used. I fed the published event to desktop's own `parseUserStatusEvent` and `fetchUserStatusLookup` with node. Desktop showed the same text, emoji, and `expiresAt` that `buzz users status` printed. The check printed `INTEROP OK`. Mutation checks: I broke each guard once. Each break made a test fail. The guards were: - the expiry comparison, `<=` changed to `<` - the future-expiry check - the `d=general` filter - the newest-first order - the tie-break - the 100-pubkey limit - the author de-duplication - the invalid-response error - the hide-cleared-status check - the duration overflow check - the SDK expiration tag - the SDK empty-status check I restored each guard after the check. One note on process: I wrote the code and the tests in the same pass. I did not write the tests first. The mutation checks cover the gap. ## Manual test steps Use a test identity on a relay that you may write to. Set `BUZZ_RELAY_URL` and `BUZZ_PRIVATE_KEY` first. 1. Set a status that expires in two minutes. ```bash buzz users set-status --text "testing expiry" --emoji "🧪" --expires 2m ``` Success: the output has `"accepted":true`. 2. Read the status. ```bash buzz users status ``` Success: the output is one row. `text` is `testing expiry`. `emoji` is `🧪`. `expires_at` is about two minutes from now. 3. Open the desktop app as the same user. Success: your status shows on your profile. 4. Wait for the expiry. Read again. ```bash buzz users status ``` Success: the output is `[]`. Desktop also hides the status. 5. Try a bad expiry. ```bash buzz users set-status --text x --expires 3600 ``` Success: exit code 1. The error says that the value must be in the future. Nothing is published. 6. Try the clear conflict. ```bash buzz users set-status --clear --expires 1h ``` Success: exit code 1. The error says `--clear` cannot be used with `--expires`. 7. Read another user. ```bash buzz users status --pubkey <hex|npub|name> ``` Success: you get that user's visible status. You get `[]` if they have none. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: bmcanally <bmcanally@squareup.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-05 17:28:24 -06:00
Blake McAnally	303157f53d	feat(cli): send a thread message to the channel (#8778) ... > Replaces #8769, which was opened from a fork. ## Summary This change adds `buzz messages send --from-thread <root-event-id>`. The flag is the CLI form of desktop "Send to channel". It publishes a new top-level message in the channel. The message carries the tag `["buzz:sent-from-thread", <root-id>, <excerpt>]`. The message has no NIP-10 reply tags. ## Design Desktop puts the thread root id in the tag. It does not use the selected message id. Desktop publishes kind 9. The CLI does the same. The CLI checks the root event before it publishes anything. The root must exist. The root must have the same `h` tag as `--channel`. The root must be a thread root. If the id belongs to a reply, the CLI fails and prints the real root id. A missing root exits with a not-found error. Other failures exit with a usage error. No event is published after a failed check. The excerpt comes from the root content. It is a Rust port of `summarizeThreadRoot` in `sentFromThread.ts`. The port clips by code point, as desktop does. It breaks words by UTF-16 unit, as desktop does. `--from-thread` conflicts with `--reply-to` and `--broadcast`. It works only with kind 9. The relay does not validate this tag. Desktop's Tauri code validates it (`message_tags.rs`). The CLI output follows those rules: 64 hex characters, an excerpt of at most 64 characters, and no control characters. The change adds no dependency and no SDK change. The CLI appends the tag to the SDK `build_message` builder. The README describes the flag. This PR does not change `desktop/` (deprecated; see #8840). ## Testing What ran: - `cargo test -p buzz-cli`: 508 passed. - `cargo clippy -p buzz-cli --all-targets -- -D warnings`: clean. - `cargo fmt --all --check`: clean. - `just file-size-check`: passed. Test coverage: - One test calls `cmd_send_message` against a fake relay. It covers success, a reply id, another channel, a missing root, an invalid id, and a non-kind-9 send. The failure cases publish nothing. The success case publishes one event with the tag and without `e` or `broadcast` tags. - One test checks the clap conflicts. - Unit tests cover the excerpt boundaries (63, 64, 65 characters, the word-break threshold, and multi-byte and emoji text). - One test compares the Rust excerpt with 639 vectors. Desktop's own `summarizeThreadRoot` generated the vectors. The first run found an ordering bug (desktop replaces each pattern over the whole text in turn). The code now does the same. Interop evidence: - A node script runs the real `buzz` binary against a local fake relay. It is not a live relay. - The script passes the published tags to desktop's `getSentFromThreadReference` and `getSentFromThreadRootId`. - Desktop accepts the tag, returns the same root id, and returns the same excerpt as `summarizeThreadRoot`. - Output: `["buzz:sent-from-thread","abab…ab","Launch plan for the doc 😀 word word word word word word word…"]` then `INTEROP OK`. Mutation checks. Each guard was broken once. A test failed each time. Then the guard was restored. - Channel check removed: success test fails. - Reply-root check removed: success test fails. - Kind check removed: success test fails. - `--broadcast` conflict removed: clap test fails. - Word-break threshold `>` changed to `>=`: three excerpt tests fail. - UTF-16 break changed to code-point break: two excerpt tests fail. - Tag not attached: success test fails. ## Manual test steps Use a test channel. You need `BUZZ_RELAY_URL` and `BUZZ_PRIVATE_KEY` set. Build with `cargo build -p buzz-cli`. 1. Post a root message. Copy its event id as `ROOT`. `buzz messages send --channel <CHANNEL> --content "Launch plan: [doc](https://example.com)"` 2. Send it to the channel. `buzz messages send --channel <CHANNEL> --content "Decision: ship it" --from-thread $ROOT` Success: the output has `"accepted":true`. A new top-level message appears in the channel. 3. Read it back. `buzz --format json messages get --channel <CHANNEL> --limit 1` Success: the tags include `["buzz:sent-from-thread","<ROOT>","Launch plan: doc"]`. There are no `e` tags. 4. Open the channel in desktop. Success: the message shows the "sent from thread" line for that root. 5. Try a reply id. `buzz messages send --channel <CHANNEL> --content x --from-thread <REPLY_ID>` Success: exit code 1. The error names the root id. Nothing is published. 6. Try a root from another channel, and try `--reply-to` together with `--from-thread`. Success: both fail and publish nothing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: bmcanally <bmcanally@squareup.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-05 17:28:19 -06:00
Blake McAnally	171100f308	feat(cli): read-only unread state (NIP-RS) (#8789) ... ## Summary This change adds `buzz channels unread`. The command is read-only. It shows how many unread messages each channel has. It uses the read state that desktop and mobile already sync (NIP-RS). It never publishes an event. It never marks anything read. Output: `[{channel_id, name, last_read_at, unread_count, capped}]`. The most unread channel is first. ## Design The command has two parts. **Part 1: read state** (`commands/read_state.rs`) - The command queries your own `kind:30078` events with the `read-state` tag. - It verifies each signature. It rejects events from other authors. - It keeps the newest version of each `d` tag. - It decrypts each slot with NIP-44 to yourself. It applies desktop's validation rules. - It merges all slots with `max`. - It ignores `ov_*` keys. Desktop and mobile do not read them either. **Part 2: counting** (`commands/channel_unread.rs`) The rules follow desktop's `communityUnreadObserver.ts`. - Without `--channel`, the command uses your non-archived channel memberships. - It reads message kinds 9, 40002, 45001, and 45003. For a DM it also reads huddle starts (48100). - It reads only events after the channel marker (`since = marker + 1`). - Your own messages do not count. - A message is read when its time is at or below the greatest of three markers: the channel marker, its `msg:<id>` marker, and its `thread:<root>` marker. A broadcast reply ignores the thread marker. **Bounds and signals** - At most 200 channels per run. `--limit` sets the number. The maximum is 200. - At most 1000 events per channel. A channel at that cap shows `"capped": true`. Its count is a lower bound. - If you have more channels than `--limit`, the extra channels are not counted. Stderr shows `{"warning":"channels_truncated","counted":N,"dropped":M}`. - More than `--limit` `--channel` values is an error. The command never drops a named channel. - An unknown named channel exits with code 1. **Failure rules** - A slot that cannot be verified, decrypted, or decoded fails the command with exit 4. Desktop skips such a slot. A skip would make the count too high, with no sign of it. - A slot with a newer `v` is skipped. Stderr shows `read_state_slots_skipped`. **Deviations from desktop** - The command has no 7-day fetch horizon. It reads all slots. This can only add markers. - It does not apply desktop's notification gate. That gate uses desktop-local data (followed threads, muted channels). So a count can be higher than the desktop badge. - It does not read mobile's `activity:` markers. Desktop does not read them. The README describes the output and the gotchas. The stable-inventory test lists the new subcommand. This PR does not change `desktop/` (deprecated; see #8840). ## Testing **What ran** - `cargo test -p buzz-cli`: 510 passed. - `cargo clippy -p buzz-cli --all-targets -- -D warnings`: clean. - `cargo fmt --all --check`: clean. - `just file-size-check`: passed. **Unit tests** The tests run the production functions against a fake axum relay. The fake relay applies the real filters (`#h`, `#d`, `#p`, `#t`, `since`, `limit`). - Merge: max across slots, newest version wins, bad values dropped, `ov_*` ignored. - Failures: bad JSON, wrong shape, bad `client_id`, wrong author, bad signature, and undecryptable content all fail. - Counting: own messages, `msg:` markers, `thread:` markers, broadcast replies, archived channels, DM kinds, and sort order. - Bounds: channel limit, event cap, `capped`, and explicit-channel limits. - Query shape: each channel query has `#h`, a bounded `limit`, and `since = marker + 1`. - A bad slot stops the command before any channel query. **Interop evidence** A node script runs the real `buzz` binary against a fake relay. Events are made and encrypted by `nostr-tools`. This is an independent NIP-44 code base. The script compares the CLI with desktop's own TypeScript: - `mergeReadStateEvents` gives the same frontier as `last_read_at` for six channels. - `fetchCommunityUnread` gives the same read/unread result as `unread_count > 0` for each channel. The six channels cover: read, unread, never read, own message only, two slots with max-merge, and a `msg:` marker. The script prints `INTEROP OK`. The script is not part of the repository. **Mutation checks** I broke each guard once and ran the tests. Each break made a test fail: - Own-message exclusion. - `msg:` marker, `thread:` marker, and broadcast rule. - `since = marker + 1`. - `capped` signal and channel limit. - Explicit channels over the limit. - Archived skip and DM kinds. - Max-merge, newest version wins, and the `t` tag requirement. - Signature check, author check, unknown `v`, and the 256-byte key limit. A mutation of the decrypt error path did not fail a test. The JSON step fails the same way, so the break changes nothing. I removed that check from the list. ## Manual test steps You need a relay and an identity that has used desktop or mobile on that relay. 1. Build the CLI: ```bash . ./bin/activate-hermit && cargo build -p buzz-cli ``` 2. Set the identity and the relay: ```bash export BUZZ_RELAY_URL=<relay-url> export BUZZ_PRIVATE_KEY=<your-key> ``` 3. Run the command: ```bash ./target/debug/buzz channels unread | jq . ``` Success: you see one object per channel. Each object has `channel_id`, `name`, `last_read_at`, `unread_count`, and `capped`. 4. Compare with the app. Open desktop or mobile on the same identity. A channel with a badge must show `unread_count` above 0. A channel with no badge must show 0. Counts can be higher than the badge for muted channels and followed threads. This is expected. 5. Read a channel in the app. Wait a few seconds. Run the command again. Success: the count for that channel is 0 and `last_read_at` is higher. 6. Test the channel limit: ```bash ./target/debug/buzz channels unread --limit 1 | jq length ``` Success: the command prints `1`. If you have more than one channel, stderr shows `channels_truncated`. 7. Test an unknown channel: ```bash ./target/debug/buzz channels unread --channel 00000000-0000-4000-8000-000000000000; echo $? ``` Success: the command prints a not-found error and the exit code is `1`. 8. Check that nothing was written. The command sends no events. The app badges stay the same after the run. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: bmcanally <bmcanally@squareup.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-05 17:27:47 -06:00
Blake McAnally	82bc5a47c5	feat(cli): report a message to relay moderators (#8829) ... ## Summary This change adds `buzz messages report`. The command sends a NIP-56 report (kind 1984) to the community moderators. You can report a message with `--event`. You can report a user with `--pubkey`. The `--reason` flag is required. It accepts one of seven values: `illegal`, `nudity`, `malware`, `spam`, `impersonation`, `profanity`, `other`. The `--note` flag is optional. The `--channel` flag is optional. When you give it, the CLI checks that the message is in that channel. The command prints the write envelope `{event_id, accepted, message}` and nothing else. ## Design The relay keeps a report in the moderation queue only. The relay does not store it as a normal event. The relay does not send it to subscribers. So the CLI prints no read-back. The tag shape is the same as desktop's `submitReport`: - Message report: `["p", <author>]` and `["e", <event id>, <reason>]`. - User report: `["p", <pubkey>, <reason>]`. The relay accepts this shape. - The note is trimmed and becomes the event content. The command adds no `h` tag. Desktop sends none. The relay reads the channel from the stored event. The task text mentioned an `h` tag. The real relay and desktop code do not use one. For `--event`, the CLI queries the event by id to learn the author's pubkey. That query uses an `ids` filter with `limit` 1. It names no kinds, because a message can have any kind. The existing `messages edit` and `messages delete` commands use the same lookup. `buzz-sdk` has a new `build_report` builder and a `REPORT_TYPES` list. The list matches the relay's `REPORT_TYPES`. The builder rejects unknown reasons, bad hex, and a note over 64 KiB. The builder allows self-tagging. Without it, the signer drops the `p` tag when you report your own message or key, and the relay rejects the report. Desktop opts in for the same reason. The CLI lowercases `--event` and `--pubkey` before it queries and signs. Clap also rejects unknown reasons, so the usage error appears before any network call. Exit codes: - Missing or unknown `--reason`, bad hex, channel mismatch: 1. - Relay rejection "invalid: report target ... not found" (exact text): 1. The relay gives this answer for a missing message and for a message you cannot read. - Other relay rejections (HTTP 400): 2. - HTTP 401 or 403: 3. The CLI README describes the new command. ## Testing What ran: - `cargo test -p buzz-cli -p buzz-sdk`: 510 CLI tests and 327 SDK tests pass. - `cargo clippy -p buzz-cli -p buzz-sdk --all-targets -- -D warnings`: clean. - `cargo fmt --all --check`: clean. - `just file-size-check`: passes. This PR does not change `desktop/` (deprecated; see #8840), so I did not run the Tauri crate tests. The CLI tests call the production `cmd_report_message` function against a local fake relay. They check the exact tags, the user-report shape, self-reports (the signer is the reported author), uppercase ids, argument parsing, the channel check, the not-found path, and the exit code for each relay rejection. Interop evidence: - I ran the real `buzz` binary against a local node HTTP server that stands in for a relay. - In the same node process, I ran desktop's own `submitReport` from `desktop/src/shared/api/moderation.ts` with a mocked signer. - Kind, tags, and content are equal for `spam` with a note and for `other` without a note. - The script prints `INTEROP OK`. - No shared relay was used. Mutation checks (break the guard, see a test fail, restore): - SDK reason check removed: fails. - SDK `e` tag without the reason: fails. - SDK `p` tag changed: fails. - SDK note trim removed: fails. - SDK note size cap removed: fails. - CLI channel check removed: fails. - CLI not-found mapping removed: fails. - CLI author read from the wrong field: fails. - CLI event-id hex check removed: fails. - SDK self-tagging removed: fails in the SDK test and in the CLI self-report test. - CLI lowercasing removed: fails. - Not-found mapping widened to any `invalid:` 400: fails. - Clap reason value parser removed: fails. - Clap required-target group removed: fails. - Clap `--channel` conflict with `--pubkey` removed: fails. One CLI `--pubkey` hex check was redundant with the builder. I removed it instead of keeping a guard no test can catch. ## Manual test steps You need a local relay and a running desktop or a second account to see the queue. Do not use a shared relay. 1. Start a local relay with `just relay`. 2. Send a message: `buzz messages send --channel <uuid> --content "test"`. Copy the event id. 3. Report it: `buzz messages report --channel <uuid> --event <event-id> --reason spam --note "test report"`. Success: the output is `{"event_id":"...","accepted":true,"message":""}` and the exit code is 0. 4. As a moderator, run `buzz moderation reports`. Success: the report appears with type `spam` and your note. 5. Run `buzz messages get --channel <uuid>`. Success: the report does not appear in the channel. 6. Report a user: `buzz messages report --pubkey <hex> --reason impersonation`. Success: `accepted` is true and the report appears in the queue. 7. Run `buzz messages report --event <event-id> --reason bogus`. Success: exit code 1 and a `user_error` message. 8. Run `buzz messages report --event <64 zeros> --reason spam`. Success: exit code 1 and a not-found message. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: bmcanally <bmcanally@squareup.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-05 17:27:33 -06:00
Blake McAnally	198c4c3e9b	feat(cli): list huddles and their participants (#8830) ... ## Summary This change adds two read-only commands to the Buzz CLI. - `buzz huddles list --channel <uuid> [--active] [--limit n]` lists the huddles of a channel. - `buzz huddles participants --channel <uuid> --huddle <id>` shows who is in a huddle now. The commands do not join, start, or end a huddle. They do not touch audio. They do not write to the relay. ## Design The CLI rebuilds huddle state from relay-signed lifecycle events (kinds 48100 to 48103). It uses a Rust port of desktop's `HuddlePresenceTracker`. The CLI and the app therefore agree on rosters. The port follows these desktop rules: - Only the relay can sign a join or a leave. - Only the relay or the huddle creator can end a huddle. - Events replay in desktop's order: time, then start, join/leave, end, then relay roster revision, then event id. - Each admission has an ID. A late leave for an old admission does not remove a rejoined participant. - A join from a newer generation replaces the older roster. A leave from an older generation is ignored. A huddle has one of three states: - `active`: no end event, and the start is less than one hour old. - `ended`: a valid end event exists. - `stale`: no end event, and the start is more than one hour old. Desktop shows this state as ended. The CLI keeps it separate because no end event proves it. Every query names the four lifecycle kinds and the `#h` channel. A command scans at most 5000 newest events. The output always has `complete`, `truncated`, `events_scanned`, and `event_bound`. - If the huddle start is inside the scan, the roster is exact. `complete` is `true`. - If the start is not inside the scan, `participants` returns `state: "unknown"` and `complete: false`. It does not return a partial roster. - A huddle that does not exist, with no truncation, returns exit code 1. Deviations from desktop and from CLI convention: - The HTTP `/query` endpoint does not serve liveness events (kind 48104). Only the WebSocket REQ path creates them. The CLI cannot check liveness. Every output has `liveness_checked: false`. Generations are never authoritative in the CLI. - Desktop keeps the roster in a Set, so its order is not defined. The CLI sorts by join time, then by pubkey. - Desktop also adds backing-channel members as a fallback roster. The CLI does not. It reports only what the lifecycle events show. - Desktop's roster view lists the creator from the start event. The CLI lists the creator only after the relay records their join. Desktop's roster view also uses a second event comparator. The CLI uses the presence tracker's comparator. - The commands return one JSON object, not a bare array. The object needs room for the truncation fields. Silent truncation would break Rule 1. The change also updates `crates/buzz-cli/README.md`. This PR does not change `desktop/` (deprecated; see #8840). ## Testing What ran: - `cargo test -p buzz-cli -p buzz-sdk`: 518 and 322 tests passed. - `cargo clippy -p buzz-cli -p buzz-sdk --all-targets -- -D warnings`: clean. - `cargo fmt --all --check`: clean. - `just file-size-check`: clean. The new tests call the production functions. A test also checks exit codes for relay-info failures: a 500 and an unreachable relay exit 2, and a 403 exits 3. They parse arguments, build output from events, and run `run_list` and `run_participants` against a local fake relay. The fake relay serves NIP-11 and `/query` with the same cursor paging as the real bridge. The tests cover rejoin, leave without join, ended huddle, stale generation, bad end signer, forged join, same-second ordering, and the event bound. Interop evidence: - `crates/buzz-cli/tests/fixtures/huddle_sequences.json` holds 14 recorded event sequences. - The Rust tests check each sequence against the expected roster and ended state. - `crates/buzz-cli/tests/huddle_interop.mjs` replays the same file through desktop's own `HuddlePresenceTracker` under node. All 14 sequences pass with `INTEROP OK`. - Run it with: `node --import ./desktop/test-loader.mjs --experimental-strip-types crates/buzz-cli/tests/huddle_interop.mjs` Mutation checks. I broke each guard once and confirmed a test failed. I then restored the code. - Relay-only author check on join and leave. - End signer check. - Ignore events after an end. - Roster revision comparison. - Ignore a leave from an older generation. - One-hour stale window. - Tie rule for the oldest scanned second. - Unknown state on truncation. - The truncation flag. - Kinds in the query filter. - `--active` filter. - Required relay `self` pubkey. All 12 mutations failed at least one test. A 13th mutation, which wraps relay-info errors as `Other`, also fails a test. No live relay was used. No event was written. ## Manual test steps You need a relay URL, a key, and a channel UUID where someone has run a huddle. 1. Build the CLI: `cargo build --release -p buzz-cli` 2. Set `BUZZ_RELAY_URL` and `BUZZ_PRIVATE_KEY`. 3. Run `./target/release/buzz huddles list --channel <uuid>`. - Success: the output is one JSON object with a `huddles` array. Newest huddle is first. Each huddle has `state`, `started_at`, and `ended_at`. `complete` is `true`. 4. Start a huddle in the desktop app. Run `./target/release/buzz huddles list --channel <uuid> --active`. - Success: the new huddle appears with `state: "active"`. 5. Copy its `huddle` value. Run `./target/release/buzz huddles participants --channel <uuid> --huddle <huddle-id>`. - Success: `participants` lists the same people as the desktop huddle window. 6. Have one person leave, then run the command again. - Success: that person is gone from `participants`. 7. End the huddle. Run the `participants` command again. - Success: `state` is `ended`, `ended_at` has a time, and `participants` is empty. 8. Run the `participants` command with a random UUID as `--huddle`. - Success: the command exits with code 1 and prints a not-found error. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: bmcanally <bmcanally@squareup.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-05 17:20:21 -06:00
John Matthew Tennant	f9ef721e68	fix(media): keep transparency in image thumbnails with WebP (#9003) ... ## Summary This fixes transparent images showing a black background. Image thumbnails were always JPEG, which can't store transparency, so a transparent PNG or GIF upload, such as an agent avatar, rendered on black wherever a client showed its thumbnail. The relay now writes a lossy WebP thumbnail at `{sha256}.thumb.webp`, which keeps transparency, alongside the existing `{sha256}.thumb.jpg`: - **Encoding:** the WebP comes from libwebp through the `webp` crate, built from vendored C source, so the relay needs no system library. A GIF uses its first frame. - **Upload responses:** the upload descriptor's `thumb`, and its per-tenant rewrite, point to the WebP. - **JPEG kept:** installed clients derive `.thumb.jpg` themselves, so the relay keeps writing it until clients move to WebP with a JPEG fallback. Existing images still have only their JPEG thumbnail. - **Serving:** `/media/` serves both variants, each with its own content type. Other `.thumb.*` extensions still return 404. - **imeta:** a `thumb` may name either variant, and the relay checks that the named object exists. - **Storage sweep:** the bucket taxonomy counts both variants as the image's thumbnail bytes instead of classifying `.thumb.webp` as unknown. | 320px thumbnail | JPEG | PNG | lossy WebP (q80) | |---|---|---|---| | Transparent avatar (starter-team `fizz.png`) | 11.3 KB, black background | 65.1 KB | 13.8 KB | | Opaque avatar (`sprout-agent.png`) | 23.6 KB | 156.5 KB | 12.3 KB | | Screenshot (`channel-thread.png`) | 13.4 KB | 62.5 KB | 6.4 KB | Encoding a WebP thumbnail takes 3 to 20 ms. ### Related issue Supersedes #8772, which served a PNG at the `.thumb.jpg` path. ### Testing Red/green against a local relay on `:3000`, built from the branch under test, with Postgres, Redis and MinIO from `docker compose`: ```bash cargo test -p buzz-test-client --test e2e_media test_transparent_png_thumbnail_is_webp_with_alpha -- --ignored cargo test -p buzz-test-client --test e2e_media_extended test_ws_imeta_webp_thumb -- --ignored ``` - **On `main`:** both tests fail. The descriptor's `thumb` is `.thumb.jpg`, and the WebSocket send is rejected with `invalid: imeta thumb must be a local .thumb.jpg path`. - **On this branch:** both tests pass: - Uploading a half-transparent PNG returns a `thumb` ending `.thumb.webp`. - HEAD and GET on that URL return `Content-Type: image/webp`. - The decoded thumbnail keeps alpha 0 on the transparent half and alpha 255 on the opaque half. - `.thumb.jpg` still returns `image/jpeg`. - A kind 9 message whose imeta `thumb` names the `.thumb.webp` is accepted. ## Screenshots The starter-team `fizz.png` avatar uploaded to a relay built from this branch. Both thumbnails are shown as round avatars beside the original PNG. `.thumb.jpg` fills the transparent area with a solid disc, and `.thumb.webp` keeps the transparency.  🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: John Matthew Tennant <jtennant@squareup.com> Co-authored-by: Simone <0828be588d5c9c4d092c5b1cf01761d5aef63d6b104807fd8e8284d517dd1a99@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-04 10:11:00 -05:00
Matt Toohey	cde6c1bf5b	feat(relay): auto-join new community members to default channels (#8594) ... ## Summary Adds **default channels**: relay owners and admins can flag channels that every new community member is automatically joined into. **Setting (contract)** - New `channels.auto_join` column (migration `0080`, constant default `false`, so no table rewrite). - kind:9002 accepts `["auto_join", "true"|"false"]`. Authorization comes from the actor's **relay** roster role (owner/admin), not a channel role, so the actor doesn't need to be a channel member. API tokens need `AdminChannels`. - Only open, unarchived `stream` channels qualify. This is checked under the channel row lock, so one event can open and flag a channel in one step, and a concurrent archive can't slip past the check. - kind:39000 carries a bare `auto_join` tag only while the setting is effective (on, open and unarchived). Every change posts one `auto_join_changed` kind:40099 notice. - SDK `build_update_channel(.., auto_join)`, `buzz channels update --auto-join <true|false>`, a NOSTR.md "Default channels" section, and a NIP-CL tag-table row. **Behaviour** - kind:9021's body is pulled out into `join_channel_as_self`, so auto-join uses the same path as a self-join: the channel's `join_role` applies, and it emits `member_joined` 40099, 39000/39002 and 44100. - `auto_join_default_channels` runs inline right after a member is added at three sites: the v2 invite claim, the v1 invite claim, and kind:9030 add. It does not run on login or reconnect, so a later kind:9022 leave stands. - Best effort: each failure is logged and counted (`buzz_auto_join_failures_total`) but never retried, because the roster membership has already committed. This deliberately departs from Review-Proven Rule 1 and is documented in NOSTR.md. `buzz-admin add-member` writes the roster row only. **Communities without a membership roster** (`BUZZ_REQUIRE_RELAY_MEMBERSHIP=false`) - These have no invite claim or kind:9030 to hook, so the three sites above join nobody there. Instead, after the AUTH `OK`, the relay joins a person to every effective default channel they have **never had a membership row in** (`auto_join_never_joined_channels`, spawned so admission never waits on it). - The channel's own membership history is the once-only record, so this adds no new table, column or migration. A kind:9022 leave or a kind:9001 removal keeps the row with `removed_at`, so the person stays out. A new device or another relay pod finds the row and does nothing. `put_first_member` checks the row again under the `put_member` locks, so two admissions racing each other join once. - A channel flagged later is joined on each person's next admission. A failed membership write leaves no row, so the next admission retries it. - Each channel's join holds the session's NIP-FI effect permit, so once the socket closes or its admission expires, no further channels are joined. - Agents are skipped: any socket with an admitted owner (a NIP-OA tag, a NIP-FI agent token, or a stored `agent_owner_pubkey`). - The kind:9021 side effects moved into `announce_self_join`, so both join paths emit the same `member_joined`, 39000/39002 and 44100. **Review follow-ups** - `get_accessible_channels` now selects `auto_join`. Without it, every call failed with `ColumnNotFound`. - The final authorization branch of the 9002 validator now refuses by default. `list_auto_join_channels` filters to `stream` channels itself. ## Testing - Postgres-lane journeys: - `edit_metadata_postgres_tests`: who may set `auto_join`, the 40099 notice, the effective-state tag, and the refusals. - `claim_auto_joins_default_channels_once`: v2 and v1 claims, and leave then re-claim. - `adding_a_member_auto_joins_default_channels`: kind:9030 add. - Removing the auto-join call at any one of the three sites fails the matching test (checked by mutation). - `root_auth_joins_people_to_default_channels_without_a_roster`: through `handle_auth` on a roster-less community. A person is joined, a NIP-OA agent is not, and a leave holds when the person is admitted again. Mutations checked: removing the spawn, and dropping the agent check. Each check waits for that admission's own auto-join outcome (a skip reports through the same test hook as a finished task) and fails if none arrives. A third mutation drops the agent check and delays the task 3s; it still fails. - `admission_auto_join_stops_when_the_session_ends`: closing the socket before the first or second channel stops the remaining joins; a later admission joins what was skipped. Mutation checked: dropping the effect permit. - `first_member_put_joins_once_and_never_undoes_a_leave` (buzz-db): the person is joined once with the channel's `join_role` (`guest` on an announce channel), a second put does nothing, after a leave the channel is neither listed nor joined, and two racing puts write exactly once. Mutations checked: removing the row check, removing the channel lock, and removing the `NOT EXISTS`. - e2e `test_invite_claim_auto_joins_default_channel` against a local relay. - Unit coverage in the SDK and CLI builders and `group_metadata_tags`. ## What got simpler The roster-less path adds no schema and no new concept: it reuses the channel's membership history as its record. It also shares the kind:9021 join code. It replaces the per-device client workarounds, [buzz-app#2029](https://github.com/block/buzz-app/pull/2029) and [buzz#8795](https://github.com/block/buzz/pull/8795), which are now closed. ## Related - Client half (buzz-app): https://github.com/block/buzz-app/pull/1624 ## Demo Recorded against a local relay built from this branch with throwaway identities (Alice = owner, Bob = new member); no real accounts or hosted relays involved. Relay at 141aa01d4, client at buzz-app bb0d97d86 (browser dev build). **Owner turns on "Starter channel for new members" on two channels.** Alice creates `#general` and `#welcome`, then flips the switch on each (~0:25 and ~0:41). The switch greys out while the kind 9002 is in flight and only turns on once the republished 39000 carries the `auto_join` tag. https://github.com/user-attachments/assets/e590d343-11d3-4385-af43-2cfaf19f8468 **A brand-new member joins and lands in a starter channel.** Bob claims Alice's invite with empty storage; from ~0:18 he is reading `#welcome` with both `#general` and `#welcome` in the sidebar, and at 0:27 opens `#general` as a member with no Join prompt. The relay logged one `auto-joined default channel` line per flagged channel. https://github.com/user-attachments/assets/037a0aaa-b25d-474d-a316-8d25e5e54f89 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Matt Toohey <contact@matttoohey.com> Signed-off-by: Luke Tornquist <tornquist@squareup.com> Signed-off-by: tornquist <tornquist@squareup.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Luke Tornquist <tornquist@squareup.com> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>	2026-11-01 14:17:41 -05:00
Bradley Axen	a3a47e6294	feat(relay): add an unlisted channel setting (#8579) ... 🤖 ## Summary Sharing a Solo chat with a large channel today means adding every person as a member, one at a time, and the app blocks the share past 100 people. The plan is to share it the way Google Docs does with "anyone at the company with the link". Buzz's `open` visibility already gives that kind of access: anyone in the community can read and join an open channel. The problem is that an open channel also shows up in everyone's channel list and search, and a private chat shouldn't appear there just because its link was posted somewhere. This PR adds a channel setting, `unlisted`. An **unlisted open channel** can be read and joined by anyone who names it by id (from a shared link). For non-members, it is left out of every read that does not name it. Members see it as before. This is the relay side only; the buzz-app change comes later. #8575 (batch adds) remains the path for small audiences. Unlisted is not an access control. Anyone who has the id can read the channel, and that is intended. ## Solo flows this supports Each user action is one event. The buzz-app side comes later; the relay supports all of these now. | Flow | Event | Result | | --- | --- | --- | | New Solo chat | kind:9007 `visibility private` + `["unlisted", "true"]` | The chat starts unlisted, so it stays unlisted when any client later opens it. | | Share | One kind:9002: `visibility open` + `unlisted true` + `join_role guest\|member`. Then post the link. | Anyone with the link can read the chat by id, both history and live. Nobody is added as a member, so the chat isn't in anyone's channel list. A non-member can't post; `join_role` decides whether someone who joins can. | | View | A REQ that names the chat by `#h`, or by `#d` for its metadata | A non-member can read it. It is never listed for them. | | Reply | kind:9021 join (the app sends it before a viewer's first reply) | Joining makes them a member with the role from `join_role`, so with `member` they can post. A kind:9022 leave makes them a viewer again; the chat stays readable by id. | | Unshare | kind:9002 `visibility private` | The existing open→private eviction closes non-members' live subscriptions. New reads by non-members are refused. | | Convert to a channel | One kind:9002: `["t", ""]` + `unlisted false`, plus `visibility` | Clears the Solo label. Non-members can now find it in discovery. | **Sidebar pins are not relay state.** Pin and unpin live in the app's existing kind:30078 sidebar preferences, which sync across devices and don't touch membership. Don't map them to join/leave: someone a chat was shared with by member add is already a member, so a leave would remove their access. Your own Solo chats keep showing up, because you're their owner member, and members see unlisted channels everywhere. Existing Solo chats aren't backfilled. They get the flag when they're shared, because the share event sets it. **Open question, not built here:** someone who only views a shared chat isn't a member. A mention of them doesn't reach their inbox (`#p:[me]` without `#h`) and sends them no push. ## Behavior | Reader | Reads that don't name the channel (kind:39000 without `#d`, `#P` creator queries, messages, COUNT, NIP-50 search, artifact queries, channel list) | Reads that name it (`#h`, or `#d` on 39000–39003) | kind:9021 join | | --- | --- | --- | --- | | Member | Listed | Readable | n/a | | Non-member, unlisted open channel | **Not listed** | Readable | Works; `join_role` still decides the role | | Non-member, private channel (unlisted or not) | Not listed | Not readable | Refused | - **Setting it:** kind:9002 `["unlisted", "true"]` / `["unlisted", "false"]`. Owner or admin only, like `visibility`. A missing tag means no change. It can be sent in the same event as `["visibility", "open"]`, so a private chat becomes open and unlisted in one step. Any other value is refused before the event is stored. The relay posts an `unlisted_changed` system message and clears the accessible-channels cache across nodes. Nobody loses access when a channel is unlisted, so no subscriptions are evicted. - **At creation:** kind:9007 also takes `["unlisted", "true"|"false"]`. A missing tag means listed. Any other value is refused before the event is stored, as on kind:9002. It is stored with the channel row in the create's transaction, on both the client-UUID path and the relay-chosen-UUID path. - **kind:39000** carries a bare `["unlisted"]` flag while the setting is on. It does not add NIP-29 `hidden`, so the metadata stays readable by id. - **NIP-11** advertises `buzz-unlisted-channels` in `supported_extensions`. A relay without this PR would apply `["visibility", "open"]` and ignore `unlisted`, which would list the chat publicly. So buzz-app must check for the extension before it sends that pair. - **CLI:** `buzz channels update --channel <id> --unlisted true|false` and `buzz channels create ... --unlisted`. `buzz_sdk::build_update_channel` takes a new `unlisted: Option<bool>` argument, and `buzz_sdk::build_create_channel` takes `unlisted: bool`, which emits the tag only when true. ### Open question: does `unlisted` only mean something when the channel is open? **Decision: store it on its own; it only has an effect while the channel is open.** Private channels are already invisible to non-members, so on a private channel the flag does nothing. It is still stored and published, for three reasons: - a client can mark a Solo chat unlisted before opening it, or in the same event that opens it, so the chat is never listed even for a moment; - switching private → open → private → open keeps the setting; - there is no cross-field rule in kind:9002 to validate or keep in sync. kind:39000 publishes the flag as stored, whatever the visibility, so clients can show the setting. ## How The relay already has a "readable only when named" path for system channels (NIP-CL). Unlisted open channels reuse it: - **`get_accessible_channel_ids`**: the open half (the implicit scope of a REQ that doesn't name a channel) adds `AND NOT unlisted`. The member half is unchanged, so members still have the channel. - **`get_readable_named_only_channels`**: also returns unlisted open channels of the legacy types. Every reader of that set (REQ, COUNT, NIP-50 search, HTTP `/query` and `/count`, thread windows, workflow run reads) adds a named-only channel only to a filter that names it, through `filter_channel_scope`. An unlisted channel's type is `stream`/`forum`, so the `#t:["system"]`/`#P` system opt-in never adds it. - **`get_accessible_channels`** (the channel list): open channels are listed to non-members only when not unlisted. - **`query_artifacts`**: an artifact in an unlisted open channel reaches a non-member only when the query's `#h` names that channel. - **Live fan-out:** no change was needed. A global subscription never receives channel-scoped events, kind:39000 included (`fan_out_scoped`). A channel-scoped subscription has to name the channel, and that goes through the same named-only authorization. **Left alone on purpose:** access checks that read a named channel or event keep treating an unlisted channel as open. These are `handle_join_request` (kind:9021), the ingest write gate, operator-listener mention delivery (`load_deliverable_event`), personal read-state writes, and push matching. Push matching still requires membership, so non-members get no pushes from an unlisted channel. **Named reads checked:** these callers use the implicit channel set (`get_accessible_channel_ids`, its cache, `get_accessible_channels`). Every one that reads a channel the request names also adds the named-only set, so a non-member can still read an unlisted open chat by id. That covers WS REQ (history, live registration, NIP-50 search), WS COUNT, HTTP `/query` and `/count`, thread windows and workflow run reads. Other named reads don't use the implicit set: they check visibility or membership, so an unlisted open chat counts as open. Those are live fan-out, the ingest write gate, typing, kind:9021 join, huddle audio join, operator-listener delivery, the workflow sink and read-state writes. Feed queries (mentions, needs-action, activity) and the `/buzz/v1/me/sidebar` accessory API are lists, so leaving out chats you only view is intended. Media reads don't check channels. `buzz-auth`'s `ChannelAccessChecker` has no production implementation. ## Database (docs/database.md checklist) - **Phase:** expand only. The migration adds a column with a constant default, and the same release ships the code that reads and writes it. No backfill or contract step follows. - No trigger, function, procedure, rule or foreign key is added. - No migration changes existing rows. `ADD COLUMN ... BOOLEAN NOT NULL DEFAULT FALSE` stores the constant default in the catalog, so the table is not rewritten. - Every location in Rule 4 is updated: `migrations/0069_channel_unlisted.sql`, `schema/tables/public/channels.sql`, and the migration count. No seeds, types or reconcile changes are needed. `admin_schema_parity_between_desired_state_and_migrations` now compares `channels` columns between the pgschema desired state and the migrated database. I failed it once by removing the column from `channels.sql`. Only columns are compared for `channels`: on current `main`, pgschema already re-emits `idx_channels_id_live` without its `INCLUDE (community_id)`, an index drift that predates this PR and is noted in the test. - **Currently deployed relay against the new schema:** it never selects or writes `unlisted`, and every insert gets the default. All channel-record queries name their columns. Nobody can set the flag until this relay ships, because the old relay refuses a kind:9002 whose only tag is `unlisted`. - The migration starts with `SET LOCAL lock_timeout = '5s'`. No index is added: the new predicates ride the existing `(community_id, visibility)` index. ## Rollout 1. Deploy. Every channel stays listed, so nothing changes. 2. **Don't unlist any channel while an old relay is still running.** An old relay ignores the column and lists the channel to everyone. The NIP-11 extension lets clients gate on this. Unlisted isn't an access boundary, so a mixed fleet only exposes the channel in listings for a while. 3. **Rollback:** an older relay ignores the column, so unlisted channels show up as ordinary open channels again. Nothing breaks. ## Tests Postgres (`buzz-db`, discovered by the Postgres lane): - `unlisted_open_channel_is_named_only_for_non_members`: sets the flag through `update_channel`. Then checks that a non-member doesn't get it from `get_accessible_channel_ids` or `get_accessible_channels`, and does get it from `get_readable_named_only_channels`; that a member still lists it; that `put_member` (the kind:9021 path) lets the non-member join, after which they list it; and that listing it again shows it to a new reader. - `unlisted_private_channel_stays_private_and_opens_unlisted`: a private unlisted channel is not readable by name, and opening it keeps the flag. - `group_metadata_publishes_the_stored_unlisted_flag`, plus the unit test `publishes_the_unlisted_flag_as_stored`. - `unlisted_channel_artifacts_are_read_by_name_for_non_members`. - `channel_created_unlisted_is_never_listed`: creating through `create_channel_with_event` (the kind:9007 path) and `create_labeled_channel` stores the flag, and the channel is never listed to a non-member. - Mutation-checked: each of `NOT unlisted` in the implicit scope, `NOT c.unlisted` in the channel list, the unlisted branch of the named-only query, its `visibility = 'open'` guard, and the artifact condition was removed one at a time, and each removal failed at least one of these tests. Relay E2E (`test_nip29_unlisted_channel_wire`, added to the CI relay E2E step), against a local relay built from this branch: - A non-member or an unknown value is refused. - kind:39000 by `#d` carries `unlisted` and `public`, and not `hidden`. - kind:39000 discovery without `#d`: non-members don't see the channel, members do. - History and NIP-50 search: unnamed, a non-member doesn't see the channel's messages; with `#h`, they do; a member sees them unnamed. - A kind:9021 join works, and the joiner then lists the channel. - Listing it again shows it to everyone. - A reader whose channel set was cached before each change sees the change at once. I ran this against a relay with the cache invalidation removed, and it failed. Relay E2E (`test_nip29_solo_share_and_convert_wire`, added to the CI relay E2E step), each flow as a single event: - kind:9007 with an unknown `unlisted` value is refused. A chat created with `unlisted true` publishes the flag, and stays unlisted after a plain `visibility open`. - Share (open + unlisted + `join_role guest` in one kind:9002): a non-member doesn't list the chat. They read it by `#h`, both history and a live message, and can't post. A kind:9021 join lists it for them as a read-only guest. A kind:9022 leave unlists it again, and it stays readable by `#h`. - Unshare (`visibility private`): the viewer's live subscription gets CLOSED, and a new `#h` read is refused. - Convert (`["t", ""]` + `unlisted false`): the Solo label is cleared, and a non-member finds the chat in discovery. - I ran this against a relay that dropped the kind:9007 flag, and it failed. Also run: `cargo test` for buzz-db, buzz-sdk, buzz-cli, buzz-core, buzz-relay and buzz-test-client; the Postgres lane for buzz-db and buzz-relay (1045 tests); and the existing unlisted, announce, departure, guest, role-change and NIP-43 snapshot wire tests. In the lane, two tests failed on pool timeouts (`resend_validated_after_the_first_commit_is_a_duplicate`, `edit_replaces_and_clears_labels`) and passed when rerun alone. An earlier run had the same kind of flake: `routed_fallback_spends_one_acquire_budget_when_aurora_cache_is_cold` (a timing budget) and `resent_edit_is_a_duplicate` (a pool timeout). In a full local `e2e_relay` run, three tests outside CI's list also failed (`test_invite_*` twice, `test_unarchive_emits_member_added_notification`). They fail the same way on a relay built from `main`. ## Not in this PR - The buzz-app follow-up: support open Solo chats, the join-from-card view, the large-audience prompt, and gating on `buzz-unlisted-channels`. - A NIP-CL update. The behavior is documented in NOSTR.md ("Unlisted channels"). buzz-review-completed --------- Signed-off-by: Bradley Axen <baxen@squareup.com> Signed-off-by: Luke Tornquist <tornquist@squareup.com> Co-authored-by: ART <ea39c1c8acf57180161ef4ba4ed68abf8589f5291956b909a5aa991fc66664ca@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: mbot <3754f8729004d95654c46dbab3129e4ab9ef05cc2534e2a3fbfc155983bd637b@buzz.block.builderlab.xyz> Co-authored-by: Luke Tornquist <tornquist@squareup.com> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>	2026-10-26 14:03:07 -04:00
ngoodger-block	016310d3cc	docs(cli): drop private references from the agent format comment (#8508) ... ### Why? #8234 merged before its last review fix landed, so the `agent_event` doc comment on main names a private repository and its internal class. Public code should not reference private implementations. ### What? Keeps the public pointer to buzz-app's MCP formatter and replaces the private one with a generic note that other agent read surfaces trim the same fields. Signed-off-by: Nikolaj Goodger <ngoodger@squareup.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-23 14:48:13 +11:00
Logan Johnson	d97f6b4c6e	feat(relay): add announce channels with a join_role setting (#8143) ... 🤖 ## Summary Channels are Buzz's main way to control access, but today they cannot separate reading from writing. In an open channel, anyone who can read can also write. So there is no way to say "many people read, a few people write". Announcements, release feeds, plugin release records and shared configuration all need that. This PR adds **announce channels**: anyone can follow and read them, but only members can post. It does this with one new channel setting and without changing what any role means. - **Roles mean the same thing in every channel.** A *guest* can read and leave, but cannot write. A *member* (or *bot*) can write. *Admins* and *owners* also manage the channel. The relay already had the guest role, but no client used it until now. - **A new setting, `join_role` (`member` | `guest`), picks the role a new person gets** when nobody chooses one: when they join by themselves, or when someone adds them without a role. The default, `member`, keeps today's behavior for every existing channel. - **An open channel with `join_role = guest` is an announce channel.** Anyone can find, read and join it. People who join are guests, so they cannot write until someone makes them a member. The relay enforces these rules, so a client cannot get around them. What each role can do (the same in every channel): | Action | Guest | Member or bot | Admin / owner | | --- | --- | --- | --- | | Read, leave | ✅ | ✅ | ✅ | | Post, reply, edit, delete own, react, artifacts, canvas, forum, pins, topic, typing, workflow messages, save or run workflows, huddles | ❌ | ✅ | ✅ | | Add people | ❌ | ✅ as member, guest or bot | ✅ any role | | Make a guest a member (person or agent) | ❌ | ✅ | ✅ | | Any other role change | ❌ | ❌ | ✅ | | Change name, about, visibility, TTL, `join_role` | ❌ | ❌ | ✅ | Other rules: - **Joining by yourself.** A person who joins (kind:9021), or adds themselves (kind:9000 with their own key), gets the channel's `join_role`. They may ask for `join_role` or a lower role, never a higher one. So in an announce channel nobody can join as a member by themselves. - **Non-members.** A non-member may write only where joining would let them write: an open channel with `join_role = member`. That is today's behavior for open channels. - **Agents.** Agents follow the same rules as people. Any member who can write may make a guest agent a member. Limits that only an agent's owner may lift belong to the later IFC work (its "restricted" agent level), not to this PR. That work only refuses more actions, so it can be added later without breaking anything here. - **Leaving always works.** A member may leave an archived channel too (kind:9022, or kind:9001 naming themselves). The last owner still cannot leave. - **Agent owners keep edit and delete.** Today the human owner of an agent can edit (kind:40003) and delete (kind:9005) that agent's messages without being a member. This PR keeps that existing behavior in announce channels too, and documents and tests it. It does not let the owner post. - **Changing the setting changes no roles.** Existing members can still write after a change to `guest`. Existing guests stay read-only after a change back to `member`. A refused write gets `restricted: only members can post in this channel`. ## Details - **One write rule.** The relay's channel write check decides from the actor's role and the channel's `join_role`. Some event types skip that check and run their own: message edit, deleting your own message (kind:9005), topic and purpose (kind:9002), add-member (kind:9000), workflow messages and joining a huddle. Each of these now uses the same rule. Membership changes (add, remove, leave) do not need write access, so a guest can always leave. If the relay finds a stored `join_role` value it does not know, it treats it as `guest`, so an unknown value can never give more access. - **Admission is decided in the database transaction.** The membership write (`put_member`) makes the whole admission decision inside its transaction, after it takes the channel's membership lock: `join_role` for a missing role tag, the self-join ceiling, guests cannot add people, who may grant admin or owner, and role changes (`MemberRole::may_change_role`). The relay's request check uses the same rules, but the database is the authority, so a write that skips the request check cannot get around them. A change to `visibility` or `join_role` takes the same lock, so an add and a setting change cannot interleave. - **No creator exception.** `put_member` used to give owner to a channel's creator who added themselves to a private channel without an active membership. A removed creator could use that: their join (kind:9021) passes the open-channel check, the channel becomes private before the join takes the membership lock, and the join restored them as owner. Channel creation already makes the creator owner in the same transaction, so the exception is removed. A removed creator is now admitted like anyone else. - **Huddles.** Joining a huddle needs write access in the huddle channel **and** in its parent channel. The relay checks both before the join. When it commits the join, it applies the same rule again while it holds both channels' membership locks: a member needs a role that can post, and a non-member needs an open channel whose `join_role` is `member`. A guest in either channel cannot join. A join is also refused when the joiner loses membership or the channel's `join_role` changes before the commit. - **One lock order.** Each writer that takes more than one of a channel's locks takes them in this order: membership lock, TTL lock, channel row. Settings changes, roster publication, TTL refresh and huddle joins all use this order. Before this change, a `join_role` change on an ephemeral channel at the same time as a roster publication could deadlock. - **Workflows.** Saving a workflow (kind:30620) skips the generic write check, so it now checks the sender's role itself and needs a writing role before anything is stored. Every path that starts a workflow run, including the manual trigger (kind:46020), needs the workflow's owner to hold a writing role now (and an elevated role for an elevated workflow). So a workflow saved while its owner was a member stops running after the owner is made a guest. - **Channel names are checked before storage.** kind:9002 and kind:9007 refuse a name longer than the `channels.name` column (255 characters) before the event is stored. Before this, the relay accepted the event, then the name update failed, and the rest of the update (for example `join_role`) was silently skipped. This PR only adds this check. Storing the event and applying the update in one transaction is a larger change, and it is not in this PR. - **Changing the setting.** Owners and admins send a channel-metadata update (kind:9002) with `["join_role", "guest"]` or `["join_role", "member"]`. Buzz applies these updates as partial updates; a missing tag means "no change". The relay posts a `join_role_changed` system message in the channel. - **What clients see.** The relay signs a channel description event (kind:39000) that clients read. One shared builder now writes it for both the relay and the `buzz-admin` backfill, which had a copy that had drifted from the relay's. It always publishes an explicit `["join_role", …]` tag, plus the standard NIP-29 group access flags: | `visibility` | `join_role` | `public` / `private` | `restricted` | `closed` | | --- | --- | --- | --- | --- | | open | `member` | public | | | | open | `guest` | public | ✓ | | | private | either | private | ✓ | ✓ | This also fixes an old bug: `closed` ("join requests are ignored") was published for every channel, even open channels that accept joins. - **CLI and SDK.** `buzz channels update --join-role guest|member`. `buzz_sdk::build_update_channel` takes a new `join_role` argument and always writes it as an explicit tag. - **Docs.** `NOSTR.md` has an "Announce channels" section with the role table and the flag table. - **Tests.** Relay end-to-end tests, run in the CI relay E2E step: - `test_nip29_announce_channel_wire`: who can set `join_role`, the kind:39000 flags, joining as a guest, refused guest and non-member posts, reactions and adds, member posts, a member making a guest a member who then posts, changing the setting back without changing roles, and leaving. - `test_nip29_member_raises_guest_agent`: a member who is not the agent's owner can make a guest agent a member. - `test_nip29_announce_channel_wire_workflow_send_needs_write_role`: a guest's workflow message is refused; a member's is accepted. - `test_nip29_departure_wire_archived_channel_allows_self_leave`: guests and members can leave an archived channel. - `test_private_channel_any_member_can_invite` now expects a private-channel guest to be refused when it adds someone (it used to expect success). - `test_nip29_announce_channel_wire_workflow_commands_need_write_role`: saving and triggering a workflow, by a member and by a guest, in announce and normal channels; a guest cannot run a workflow saved while it was a member. - `test_nip29_announce_channel_wire_overlong_name_is_refused_before_storage`: a kind:9002 with an overlong name and `join_role` is refused, and kind:39000 still shows the old settings. - `test_nip29_announce_channel_wire_agent_owner_exception`: an agent's owner, as a guest and as a non-member, can edit and delete the agent's messages, while ordinary guests are still refused. - `test_nip29_guest_is_read_only_in_normal_channel`: a guest in an ordinary channel cannot write, and joining an ordinary channel still gives `member`. Unit tables cover the self-join rule for each `join_role`, and every actor, current role and requested role for the role-change rule. Database tests check the admission rules in `put_member` (`put_member_enforces_announce_admission`), that an add which waits on an uncommitted change to `guest` is decided on the new setting (`put_member_waits_for_a_concurrent_join_role_change`), and that a member can make a guest a member but not an admin. Unit tests cover the name limit and the workflow owner rule (`owner_authority_denies_roles_that_cannot_write`). A relay test covers huddle joins with different roles in the huddle and its parent, and a commit after a demotion, a `join_role` change or a lost membership (`huddle_join_needs_a_write_role_in_the_huddle_and_its_parent`). Lock-order tests: `join_role_change_waits_for_a_roster_publication_on_an_ephemeral_channel` reproduced a real deadlock (`40P01`) against the old order. `f2d_join_lock_order_serializes_membership_and_settings_writers` checks that membership and settings writers wait for a join and then succeed. `removed_creator_cannot_rejoin_a_private_channel` checks that `put_member` refuses a removed creator on a private channel, and `removed_creator_join_racing_a_private_switch_is_refused` holds the membership lock so a removed creator's kind:9021 passes the open-channel check, then makes the channel private before the join continues. Each new test was run against the old code and failed. ## Rollout 1. **Before the deploy, count guest rows** (`SELECT count(*) FROM channel_members WHERE role = 'guest' AND removed_at IS NULL`). We expect none. Any guest that exists loses the ability to post, change the topic and add people when this ships. If some exist, decide first whether to make them members. 2. Deploy. Every channel stays `join_role = member`, so nothing else changes. 3. **Do not set any channel to `join_role = guest` until no old relay is running.** Old relays ignore the column, so they would let guests and non-members write in that channel. 4. Rerun the `buzz-admin` channel reconcile so open channels drop the wrong `closed` flag. ## Migration and rollback - Migration `0067` adds `channels.join_role TEXT NOT NULL DEFAULT 'member'` with a CHECK constraint. Postgres stores a constant default in table metadata, so existing rows are not rewritten and there is no backfill. The relay runs the migration at startup. - Existing channels keep the old `closed` flag until their next change, or until the reconcile in Rollout step 4. - **Before rolling back the relay**, set every announce channel back to `join_role = member`. An older relay ignores the column and does not stop guests from writing, so those channels would accept posts from their guests and give `member` to new joiners again. ## Not in this PR Client UI: a Follow button, hiding the composer for guests, and an admin toggle. Clients that ignore the new tag keep working. A guest who tries to post sees the `restricted` error. ## Stack 1. #8143 (this PR): announce channels 2. #8494: store the bot role only for keys with a recorded agent owner --------- Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>	2026-10-21 16:01:11 -04:00
ngoodger-block	76d792f288	BUZZ-357: feat(cli): token-lean agent output format for event reads (#8234) ... ### Why? Agents read channel history with `buzz messages get/thread`. Every returned event includes its 128-hex `sig`. Every agent-authored message also carries a NIP-OA `auth` tag, which is another owner pubkey and a 128-hex signature. An agent can't use either of these, but pays for them on every history read. Measured with Claude's tokenizer, that is about 88 tokens per human message and about 180 per agent message, so a history read shrinks 33% for short human messages and 40% once agent messages are in the mix (details in the comment below). The existing `compact` format is fixed at `{id, content, created_at}` (#6884), which drops the author, tags and reply target, so agents can't use it. ### What? - **New `--format agent` for event reads.** Applies to `messages get/thread/search` and `feed get`. - Drops `sig`, and trims the NIP-OA `auth` tag to `["auth", <owner>]` so agents can still tell an author is an agent and who owns it. - Folds the NIP-10 `root`/`reply` tags into a `reply_to` field, using the same resolver as relay ingest, plus `thread_root` on nested replies. That's the value `messages send --reply-to` takes. - Keeps every other tag exactly as `json` output shows it: channel, mentions, edit targets, diff metadata. - Non-event reads return the same output as `json`. - **Default for agents.** Without `--format`, the CLI falls back to `BUZZ_OUTPUT_FORMAT`; an empty or unknown value means `json` with a warning, so a harness/CLI version mismatch never breaks commands. buzz-acp sets it to `agent` for every agent runtime through `default_agent_env` and forwards the effective value in the explicit MCP server environment, so operator or persona env still wins, and `--format json` still returns full signed events. buzz-agent adds the variable to its MCP env allowlist. - **Docs and cleanup.** The managed-agent skill doc (version bumped to 7) and `AGENTS.md` describe the new default. The two duplicate `format_events` copies in `messages.rs` and `feed.rs` are now one `commands/event_output` module, which also does the NIP-10 tag parsing. The `json` and `compact` output contracts are unchanged. ### Example output https://github.com/block/buzz/pull/8234#issuecomment-6259679347 ### Testing Started `buzz-acp run` with the deterministic task-agent fixture, then passed its `session/new` MCP environment to Codex 0.163.0 (`codex app-server`). With no format override the MCP child received `agent`; operator overrides of `json` and `compact` reached the MCP child unchanged. The probes used temporary local sessions and made no model requests. ### Related Same change on the other agent read surfaces: each drops `sig`, trims `auth` to `["auth", <owner>]` and keeps thread context. - block/buzz-app#1388: buzz-app MCP read lines (text, `claimed owner`/`reply_to`) - squareup/cash-server#139132: hosted agents' read tools (JSON events, raw NIP-10 tags) Generated with Codex --------- Signed-off-by: Nikolaj Goodger <ngoodger@squareup.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-21 12:54:05 +11:00
Logan Johnson	2f79374f48	feat(relay): channel labels (#8175) ... 🤖 ## Summary A plugin or agent often needs to tag its own channels and then find them again, for example "my attention-config channel" or "all channels of this workspace". Today a channel has no labels: the relay ignores any `t` tags in create or edit requests. This PR adds channel labels. - A create request can carry up to 8 labels as `["t", "<label>"]` tags. - An edit request with `t` tags replaces the label set. `["t", ""]` alone clears it, the same convention as `["ttl", ""]`. Only owners and admins can change labels, as for the name. - The relay publishes each label as a `t` tag on the channel's state events, after the channel type tag. Part 2 of 3, stacked on part 1. ### Related issue None found. ### Details - **Rules.** A label uses 1–64 characters from `a-z`, `0-9`, `.`, `:` and `-`. The relay refuses a label equal to a channel type name (`stream`, `forum`, `dm`, `workflow`, `system`), so a label cannot make a channel look like another type. - **No trust from labels.** Any admin can set a label. Only the relay-written creator tag (part 1) says who made a channel. - **Storage.** New migration `0061_channel_labels.sql` adds `channels.labels TEXT[] NOT NULL DEFAULT '{}'`. Channels without labels look and behave as before. - **Readers.** The CLI and `buzz-acp` read the channel type from the first `t` tag. Before this PR they used the last one, which would now be a label. - **Spec.** NIP-CL gets a "Channel labels" section with these rules. ### Testing - Relay tests: labels at creation appear after the type tag, edit replaces and clears them, invalid labels are refused, and members who are not admins cannot change them. - Unit tests for the label rules: allowed characters, length, reserved type names, the 8-label cap and the clear marker. - `buzz-acp` test: the channel type comes from the first `t` tag, not a label. ### Stack These are two stacks. Merge them in this order. Client support (creating, labeling and finding these channels) will be in block/buzz-app, not the buzz SDK and CLI. **Stack 1: channel labels and creator lookup (#8174–#8176)** 1. #8174 channel type and creator tags, and the channel creation time 2. #8175 channel labels ← this PR 3. #8176 database-side label and creator match, and the rule for choosing one channel **Stack 2: system channels (#8180–#8182)**, stacked on stack 1 because it uses labels and the creator tag 4. #8180 the system channel type 5. #8181 leave system channels out of reads that do not name them 6. #8182 channel-state filters opt in to system channels --------- Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>	2026-10-14 17:25:46 -04:00
Bradley Axen	6c388bde62	feat(relay): accept typing indicators over HTTP POST /events (#8207) ... ## Summary Agents hosted inside the Buzz app sign their own events but don't hold a WebSocket, so they couldn't show "typing…" in a channel. `POST /events` rejected kind 20002 (typing indicator) with `restricted: unknown event kind`. Now, when `POST /events` receives a kind 20002 event, the bridge passes it to the same channel broadcast the WebSocket path uses. Live subscribers in the channel get the pulse. Nothing is written to Postgres. Before broadcasting, the relay checks, in order: - the event has an `h` tag naming the channel - the serialized event is at most 2 KiB (real typing events are ~600 bytes). Measuring the whole JSON, not just content and tag values, means piling on empty tags can't get around the cap - the signature and id are valid - bans and timeouts - the community write fence (over HTTP, a quiescing community's host already fails to bind with a 404, so this catches quiescing that starts after the tenant is bound) - the sender is a channel member, or the channel is open (same rule as WebSocket) - the signer is the pubkey that authenticated the request (checked first; a mismatch returns 403) The existing HTTP admission rate limit and relay-membership gate still run before any of this. Other ephemeral kinds are still rejected over HTTP. `publish_channel_ephemeral` is the old WebSocket channel-broadcast code moved into a shared helper, so both paths use the same membership check and fan-out. Unlike the WebSocket path, HTTP requires the `h` tag. Over WebSocket, a 20002 with no channel goes to every subscriber. Points left for review: - HTTP typing pulses count against the same per-pubkey HTTP quota as message posts (default 300/min). One pulse every 3 s is 20/min per active channel. - A failed Redis publish is logged and the POST still returns `accepted: true`, same as the WebSocket path. A pulse is resent every 3 s and expires after 8 s, so a retry would only resend a stale pulse. The `sadscan:disable` comment on an existing test URL in `ingest.rs` is there because the secret scanner reads every file a commit touches. It uses the same form as the other local test fixtures in the repo. ### Related issue Needed for Agents2 typing indicators in buzz-app. The client PR depends on this one and will follow as a draft. ### Testing - 9 new Postgres-backed tests in `api/typing_postgres_tests.rs` cover these cases: a member's pulse is published and not stored; a non-member gets a 400; a timed-out member gets a 403; a signer mismatch gets a 403; a missing `h` tag gets a 400; a tampered event gets a 400; kind 20001 is still rejected; oversized events get a 400 (2 KiB of content, one 2 KiB tag value, or `h` + 10k empty tags); a community that starts quiescing after the tenant is bound gets a 400 `community writes are fenced`, and nothing is published. Two mutation checks: with the fence removed, the fence test fails; with the old content-plus-tag-values cap, the empty-tags case is accepted and the test fails. - The full buzz-relay Postgres lane on 27b5a294: 386/387 pass. The one failure is `boot_lifecycle::hanging_redis_peer_times_out_before_the_health_listener_binds`: it went over its timing slack under full-suite load (8.03 s) and passed when rerun alone. - buzz-relay unit tests pass (1476). One mesh demo test timed out once under load and passed when rerun alone. - `cargo clippy -p buzz-relay -p buzz-cli -p buzz-acp --all-targets -D warnings` is clean. - Live test against a local relay built from this branch (27b5a294), run by ART at baxen's request as the sign-off test. alice subscribed over WebSocket to kind 20002 in a private channel; bob (a bot member with no WebSocket) and carol (outsider) used `POST /events` with NIP-98. 16/16 checks passed: - bob's top-level pulse → 200 `accepted: true`, and alice received it live - bob's thread pulse (`h` + root `e` + reply `e`, the buzz-acp shape) → delivered with tags intact - 2 KiB content, a 2 KiB tag value, or `h` + 10k empty tags → 400 `typing indicator too large`; alice received nothing - carol → 400 `restricted: not a channel member`; alice received nothing - carol posting an event signed by bob → 403 - no `h` tag → 400; kind 20001 → 400 `only accepted via WebSocket` - 0 kind-20002 rows in Postgres afterwards 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Bradley Axen <baxen@squareup.com> Signed-off-by: ART <ea39c1c8acf57180161ef4ba4ed68abf8589f5291956b909a5aa991fc66664ca@buzz.block.builderlab.xyz> Signed-off-by: Honey <8e307ae0076a4dab6b94b036ea3edc7e08f823a625269c1e6919e881a048b4d2@buzz.block.builderlab.xyz> Co-authored-by: Honey <8e307ae0076a4dab6b94b036ea3edc7e08f823a625269c1e6919e881a048b4d2@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: ART <ea39c1c8acf57180161ef4ba4ed68abf8589f5291956b909a5aa991fc66664ca@buzz.block.builderlab.xyz>	2026-10-09 22:44:31 +00:00
Will Pfleger	f7ff4294fa	feat(nip-fi): harden Blossom kind-24242 verifier to NIP-FI spec (#7288) ... Brings `buzz-media`, `buzz-relay`, all first-party kind-24242 minters, and desktop token minting into compliance with [NIP-FI §kind-24242](https://github.com/block/buzz/blob/main/docs/nips/NIP-FI.md). ## What changed **`buzz-media/src/auth.rs`** - Add `BlossomStrictness` enum (`Strict` | `Permissive`). `Strict` applies full NIP-FI rules (active modes); `Permissive` preserves pre-NIP-FI Off-mode behavior byte-identical [FI-INV-15]. - Rewrite `verify_blossom_auth_event_for_verb` with count-based cardinality: exactly one `t`/`expiration`/`server` in `Strict`; duplicate `x` also rejected. `Permissive` keeps main's boolean semantics exactly: any valued `t` other than the verb (including `""`) rejects, valueless `t` is ignored. - `Strict`: mandatory `server` tag on all proofs (upload + read); absent or mismatched → `evidence_rejected` (`ServerMismatch`). - `Strict`: 60-second proof window (`now - created_at <= 60s`, `expiration <= created_at + 60s`). `Permissive`: 3600s / optional server. - **[F1]** Permissive server validation uses any-match semantics: a proof with multiple `server` tags is accepted if any tag matches the bound host. This restores origin/main base behavior. Strict duplicate-rejection unchanged. - **[F1 compat]** Permissive server gate uses `server_values.is_empty()` (valued tags only) rather than `server_count > 0` (includes valueless tags). A lone valueless `["server"]` tag is treated as absent in Permissive/Off mode, matching pre-NIP-FI base behavior [FI-INV-15]. - **[F4]** Valueless `x` tags in Strict get reads are tracked before `filter_map` so they cannot become absent scope (host-wide authorization). Any `x` tag present in Strict must contain the exact requested sha256. - **[F3 unit]** Cases A–D in `auth.rs` are helper-level unit tests: they call `verify_blossom_upload_auth` and `verify_upload_hash_only` directly. They do not enter the upload pipeline (`process_upload`/`process_video_upload`). Retained as helper evidence. **`buzz-media/src/error.rs`** - Add `DuplicateTag(&'static str)` variant. - Add `blossom_denial_kind()` method: classifies each auth error as `MissingEvidence`, `EvidenceRejected`, or `AuthorizationDenied`. Non-auth errors return `None`. - `IntoResponse` retains the legacy JSON 401 shape [FI-INV-15]. **`buzz-relay/src/api/media.rs`** - Add `MediaDenial(MediaError, BlossomStrictness)` wrapper mapping to byte-exact NIP-FI fixed responses in `Strict`; falls through to legacy JSON in `Permissive`. - `blossom_strictness_from_state()` selects `Strict` when `state.config.nip_fi.is_enforce()`, otherwise `Permissive`. Strictness is threaded through the `admit_nip_fi_http_on_state` NIP-98 closures on upload and read, and through the post-admission X-SHA-256, hash-binding, and membership denials. - `extract_blossom_auth` keeps first-value `Authorization` extraction; Enforce rejects repeated fields at the `admit_nip_fi_http` cardinality gate, and Off keeps legacy behavior [FI-INV-15]. - Both membership-denial call sites use `media_denial(RelayMembershipRequired, strictness)` so Strict mode produces the correct fixed-text response. - `upload_blob` serving-write fence conversion (`:406`) uses `map_err(|e| media_denial(e, strictness))` — a community fence committed between auth admission and lease acquisition no longer resets Strict to Permissive. - Mode-driven regressions in `mod postgres_tests` (selected by the nextest `postgres-ci` profile via `test(/postgres_tests::/)`, `#[ignore = "requires Postgres"]`), run through the full relay router with a real Enforce verifier and assertion: Enforce rejects Permissive-only proofs (300s lifetime, missing `server` tag) on both upload routes and reads with `evidence rejected`; Off accepts the same proofs with pre-NIP-FI responses; DenyProtected answers 503 before any proof check; membership denials are `authorization denied` text/plain in Enforce and exact legacy JSON 403 in Off, with a member positive control. GET and HEAD are each discriminated (HEAD with a suppressed body). Both upload routes pin the handler's `X-SHA-256` missing/malformed/unsigned and post-body hash-mismatch denials in both modes. Off rejects an empty-valued `t` beside a valid one with legacy 401 JSON in either order, and ignores a valueless one. Exact status, Content-Type, challenge, and body bytes are pinned. **`buzz-media/src/upload.rs`** (`mod minio_tests`) - **[F3 pipeline]** Four tests exercising the actual post-body call sites (`process_upload` `:85`, `process_video_upload` `:413`) with real MinIO I/O: buffered/streaming × expired-proof-accept + mismatched-hash-reject. The positive cases use `fresh_strict_upload_auth` (`created_at = now-58`, `expiration = now+2`, lifetime = 60s) — Strict-admissible at sign time — followed by a real 3s sleep so the proof is expired when the upload completes. `nostr::Timestamp::now()` reads the OS wall clock directly; paused Tokio time does not advance it. The negative cases use a pre-expired proof with a mismatched `x` tag. All four are `#[ignore = "requires MinIO"]`; no CI lane runs them automatically. **`buzz-media/src/validation.rs`** - `minimal_valid_mp4()` promoted to `#[cfg(test)] pub(crate)` — a 618-byte pre-computed H.264/avc1 fast-start MP4 available to all `buzz-media` test modules; smoke-tested by `test_minimal_valid_mp4_passes_validate_video_file`. **`desktop/src-tauri/src/commands/media.rs`** - `sign_blossom_upload_auth`: `server` tag mandatory; upload expiry 60s (was 3600s/300s). - `MEDIA_GET_AUTH_EXPIRY_SECS`: 60s (was 600s). **`desktop/src-tauri/src/media_proxy.rs`** - Single re-mint+retry on 401/403 for range requests; non-auth failures do not retry. **`crates/buzz-cli/src/client.rs`** - Read expiry: 60s (was 600s). Upload expiry: 60s. `server` tag mandatory on upload. **`crates/buzz-dev-mcp/src/view_image.rs`** - `MEDIA_GET_AUTH_EXPIRY_SECS`: 60s (was 600s). Test updated. **`mobile/lib/shared/relay/media_auth.dart`** - `_mediaGetAuthLifetimeSeconds`: 60 (was 600). Refresh margin updated. **`mobile/lib/shared/relay/media_upload.dart`** - `_uploadAuthLifetimeSeconds`: 60 (was 300). `server` tag mandatory. **`mobile/lib/features/channels/media_viewer_page/video_viewer.dart`** - **[F2]** Remove Android-specific `VideoPlayerController.networkUrl` streaming path. `video_player_android` 2.9.5 freezes headers into static `DefaultHttpDataSource` request properties — a 60s proof minted at controller creation time becomes stale on seeks. All platforms use the authenticated local-file download path. - **[F2 transport]** `unawaited(request.sink.close())` before `client.send()`. `AbortableStreamedRequest` carries no request body; without closing the sink, `IOClient.send()` awaits `stream.pipe(ioRequest)` which blocks until the sink ends — every video download hung in loading indefinitely on every platform. - **[F2 pending-ctrl]** `pendingController` ref set before the first `await (initialize())`, cleared in all exit paths. Effect cleanup disposes `pendingController.value` so a close-during-init releases the native player even if the initialized event never arrives. - **[F2r(a)]** On native init failure (post-create, pre-initialized-event), the inner catch starts disposal detached via `unawaited(localController.dispose().catchError(...))` — the `.catchError` handler absorbs any disposal exception so it does not reach the test error zone — then rethrows the original load error. `video_player` 2.11.1 completes the init future with an error without disposing the native player. - **[F2r(b)]** Non-2xx error body cancelled via `_cancelVideoResponse()` (subscribe+cancel) instead of `drain()`. `drain()` waits for the upstream to close; a stalled server body blocked `initializeVideo` indefinitely. - **[F2r(d)]** `unawaited(localController.dispose().catchError(...))` in the catch — not `await`. Two failure mechanisms exist: (1) when `createWithOptions()` throws, `_creatingCompleter` is never completed and `await dispose()` deadlocks at `:682-683`, blocking the outer catch from setting error state. (2) when `createWithOptions()` succeeds but initialization fails, `dispose()` runs but its thrown exception becomes an unhandled async error reaching the test zone. Both are fixed: `unawaited` lets the outer catch run immediately and set `error.value`; `.catchError(...)` on the detached disposal future absorbs any disposal exception. **`mobile/test/features/channels/media_viewer_page/video_viewer_test.dart`** - `_FinalizingFakeClient`: calls `request.finalize().drain()` — a test without the sink fix times out because the drain never completes, validating the transport contract. - F2r(a): `forceInitError=true` fake emits `PlatformException` on subscribe; `disposeCallCount >= 1` verifies disposal even on init failure. - F2r(b): `stalledBody` `StreamController` with `onCancel` Completer (bounded completion signal, not a sleep). Asserts: (1) `bodyStreamCancelled=true` while body stream is still open (impossible with `drain()`); (2) error UI visible while body remains open. Restoring `drain()` breaks both. - F2r(c): `neverInitialize=true` fake never sends initialized event; unmount asserts `disposeCallCount >= 1` via `pendingController`. Distinct from the event-error case. - F2r(d): `forceCreateError=true` fake throws `PlatformException` from `createWithOptions()` itself (before any player ID is returned). Asserts error UI visible within a bounded deadline. With the old `await dispose()` the outer catch is blocked — `error.value` is never set and the error UI assertion fails at the deadline; with `unawaited(dispose())` the error text appears immediately. **`mobile/test/features/channels/media_viewer_page/video_viewer_transport_test.dart`** (separate file) - Real-IO loopback probes using `flutter_test` (not `package:test`) to avoid `depend_on_referenced_packages` lint. No `TestWidgetsFlutterBinding` — no HttpClient override interfering with `dart:io`. - Probe 1: `HttpServer.bind(loopbackIPv4, 0)` reads the full request body before replying. Without `sink.close()`, `req.drain()` hangs and the test times out. - Probe 2: server signals request arrival via a Completer (not a sleep); abort fires after confirmed arrival; `client.send()` must throw `RequestAbortedException` (typed assertion) within a bounded 5s deadline. **`scripts/test-video-upload.sh`** - Proof minted with `+60` expiry and mandatory `server` tag. **`buzz-test-client/tests/e2e_media*.rs`** + **`buzz-relay/src/api/media.rs` test fixtures** - All fixtures updated to 55s expiry + `server` tag. **`RELEASING.md`** - New "NIP-FI upload proof freshness (relay floor)" section documenting that 60s proofs require the first relay release carrying this PR's post-body hash-only check (the first tag > `v0.2.1` — update once cut) for reliable large-file uploads. Operators on older self-hosted relays (≤ `v0.2.1`) must upgrade before receiving these clients. ## Finding 3: 60s upload proofs vs old-relay compatibility Desktop/CLI/mobile upload proofs are now 60s. Older relays re-run full expiry verification after the body is transferred. A valid upload whose body transfer takes >60s will fail on an old relay. **Resolution (relay floor prerequisite):** `RELEASING.md` requires that verified supported deployments (relay releases confirmed to carry the post-body hash-only check, commit `75e9bef748`) be in place before distributing 60s-proof client builds. Unknown or unverified self-hosted relay deployments are excluded from distribution until they upgrade. This makes the verified-deployment status a prerequisite for release distribution, not a post-distribution advisory. The concrete tag (`> v0.2.1`) is to be recorded once cut. ## Sequencing note Builds on #7264 (merged): Blossom strictness is derived from its `config.nip_fi` mode in this PR, so enabling `BUZZ_NIP_FI_MODE=enforce` activates the strict verifier with no further wiring. ## GIF compatibility exception An unauthenticated Off-mode request on a configured tenant with no GIF provider changes from 404 to 401 (base `gifs.rs:269-275` checked an unconfigured provider first; the current code authenticates first). All other Off-mode Blossom responses are byte-identical to pre-NIP-FI behavior. --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-09-28 14:46:56 -04:00
Will Pfleger	b6a26556ec	feat(canvas): add version history with atomic restore (#6780) ... 🤖 Adds append-only channel canvas history, restore, and relay-authoritative optimistic concurrency so stale edits cannot silently replace a newer canvas. ## What this adds - **Desktop history and restore** — browse revisions with author, timestamp, preview, and diff; restore an older revision as a new signed head after explicit confirmation. Persisted empty canvases remain reachable, mutation outcomes are announced accessibly, and focus moves to a stable destination after save or restore. - **CLI history and restore** — `buzz canvas history --channel …`, `buzz canvas get --channel … --revision <id>`, and `buzz canvas restore --channel … --revision <id>` use keyset pagination over the retained revision stream. - **SDK canvas builders** — optional `expected-revision` tags, bounded ancestry classification, and shared timestamp discipline keep first-party writes ahead of the head they read without propagating poisoned future timestamps. ## Authoritative concurrency contract Tagged canvas writes use compare-and-swap semantics in the relay and database: - `expected-revision=none` succeeds only when no live canvas exists. - An event ID succeeds only when it names the canonical live head. - A byte-identical replay succeeds only when that event is already the canonical live head. - A successful candidate must sort strictly ahead of the current head under `created_at DESC, id ASC`. - Malformed preconditions and stale or non-advancing writes are rejected before event rows, mentions, or fan-out are committed. The database serializes tagged writes, unconditional kind `40100` writes, and canvas soft deletion on the same `(community, kind, channel)` advisory key. Untagged `buzz canvas set` remains an unconditional write, but participates in that serialization boundary so it cannot race a tagged save or deletion. Deletion classification is derived inside the datastore transaction; unrelated event kinds do not take the canvas lock. ## Read and timestamp consistency Precondition and post-write ancestry reads request strong consistency from `/query`, pinning them to the writer when replica routing is enabled. Display-only history remains replica-eligible. First-party canvas writers stamp `created_at = max(now, head + 1)` with a conservative client skew limit. The relay applies a canvas-specific future-timestamp ceiling before persistence, preventing an accepted boundary head from making subsequent first-party writes invalid while preserving the broader ingest limit for other event kinds. ## Durable outcomes and recovery After an accepted publish, a failed verification read is reported as durable success with `verified: false` rather than a failed save. Desktop and CLI preserve the new event ID and direct users to History when verification is unavailable. A successful read walks the bounded, cycle-guarded `expected-revision` ancestry chain so transitive descendants are not misclassified as supersession. Canvas caches invalidate for every settled mutation outcome, including a retained but superseded revision. The 409 reconciliation path in `cmd_restore_canvas` now separately establishes persistence evidence from ancestry classification. `canvas_write_survived` checks reachability only; a secondary writer-pinned IDs lookup distinguishes "A absent" from "A present but superseded by a legacy write." The four-way outcome (survived / persisted-but-superseded / genuinely-absent / read-fail) is now correct for all lost-response shapes including unconditional legacy writes. --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Hayt <9e1c23a3fd83f61da34420e4e88ff1b16e45cafcc0cd9019eb07d4ecfa8ca9b0@buzz.block.builderlab.xyz>	2026-09-23 11:03:54 -04:00
Salman Mohammed	44c1cc7df8	feat(buzz-cli): render an agent-friendly command tree in --help (#7584) ... ## Summary `crates/buzz-acp/src/base_prompt.md` carries a hand-maintained `Group | Key commands` table of the `buzz` CLI. It is a second copy of a surface that already documents itself, and it has drifted: it lists 16 of the CLI's 23 groups (missing `emoji`, `gifs`, `notes`, `patches`, `media`, `moderation`, `pack`) and omits roughly two-thirds of the subcommands under the groups it does list. its hard to keep it in sync. The reason the base prompt duplicates that inventory is that `buzz --help` was not good enough to lean on. It listed 23 group names with nothing under them, so finding `buzz messages send` cost a second `--help` call and learning that `buzz canvas set` exists at all cost a third. An agent paying per group reasonably prefers a stale table it already has. This PR fixes the help output so the prompt can point at it instead. `buzz --help` now prints the whole tree — every group, its subcommands, and their descriptions — in one invocation: **Before** ``` Commands: messages Send, read, search, and manage messages channels Create, configure, and manage channels canvas Get and set channel canvas documents ``` **After** ``` Commands: messages Send, read, search, and manage messages send Send a message to a channel send-diff Send a code diff / patch to a channel edit Edit a previously sent message ... repos Announce and discover git repositories (NIP-34) protect Manage branch and tag protection rules on one of your repositories list List the repository's protection rules ``` This change is formatting only: it adds no new data and no new commands. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: Salman Mohammed <smohammed@squareup.com>	2026-09-11 16:20:31 +00:00
Wes	6146c4fd16	feat(git): add default-branch management to relay and CLI (#7562) ... Authored by Brain and opened on behalf of Wes (`wesbillman`). ## Summary Add `buzz repos default-branch get/set` and the relay operation it needs. Git push changes branch tips but cannot select the server's symbolic HEAD. This selects an existing branch without deleting branches, moving refs, or changing packs. - Reuse immutable Git manifests and captured-ETag CAS; concurrent pushes/default changes conflict, including stale no-ops. - Require request-specific NIP-98, body binding, fail-closed replay protection, host tenancy, current channel membership and repository-management authority. Push/project roles alone are insufficient. - Send the CLI mutation once, without redirects; ambiguous delivery retains the observed digest and is non-retryable. - Document the narrow HTTP exception to Nostr-first, delegation scope and admission-time ACL revocation. Kind:30618 remains derived; the manifest CAS is authoritative. - Register the Postgres/Redis/MinIO route and fresh-clone tests in the existing Backend Integration lane. ## Review fixes — `7457bda50afa6b52e36315572fa96928b2e21db6` - Reject signed valueless `payload` tags when verifying a body; preserve the shared verifier's intentional absent-payload compatibility. The real settings route now proves 401, unchanged manifest pointer, and unchanged kind:30618 event IDs for malformed and other invalid credentials. - Require a nonempty returned branch and `head == refs/heads/{branch}`; SET additionally requires the returned branch to equal the attempted branch. Malformed/mismatched mutation responses remain non-retryable `DeliveryUnknown`, retaining the attempted branch and original digest. Invalid reads fail before any POST. - Strengthen the later-push/fresh-clone regression to select `release/v1` while `main` exists. ## Verification At `7457bda50afa6b52e36315572fa96928b2e21db6`: - Full pre-push passed (all 14 Rust test groups, serialized Tauri tests/clippy, file-size and branch-skew gates; 522 seconds). No hooks disabled. - All four isolated Postgres/Redis/MinIO settings tests pass, including real Smart HTTP `ls-remote --symref` and fresh clone on `release/v1`. - All 15 focused NIP-98 verifier tests and three default-branch CLI tests pass; malformed credentials and missing-branch responses were reproduced failing before the fixes. - Five targeted mutants are killed: restoring the valueless-payload bypass, weakening canonical HEAD validation, accepting an empty branch, dropping requested-branch confirmation, and omitting hydrated HEAD for the selected non-main branch. Mutations ran in a separate worktree and target directory; original patch bytes were verified restored. - `cargo clippy -p buzz-auth -p buzz-cli -p buzz-relay --all-targets -- -D warnings`, formatting, diff and file-size checks pass on the fixed tree. Earlier validation at `bb195b140`: seven Git authorization database regressions and 28 existing transport tests passed (three infrastructure cases in that module not selected); four mutations killed management/replay/CAS/redirect regressions. Full pre-push passed with `RUST_TEST_THREADS=1` (all 14 Rust groups, Tauri clippy and 3,173 tests, size/branch-skew gates). Serial execution avoids an unrelated process-global Desktop discovery counter flake; no hooks disabled or Desktop changes. Carl and Jude's review findings are addressed in the new head; **fresh reviewer and exact-head security confirmation remain required**. The earlier source review is not approval of this revision. No claim of green new-head CI. ## Rollout Merge and **deploy the relay support first**, then build/use the updated CLI and explicitly set/verify the desired default. No schema migration. This PR does not deploy anything or change a live repository. Originating conversation (channel `8e2fda80-9142-4df8-8e14-da288bea6471`): buzz://message?channel=8e2fda80-9142-4df8-8e14-da288bea6471&id=8a7a9cf12737abc1e16605f241300be940a1691ef0992b35197afe26c563108d --------- Signed-off-by: Brain <1a02c72794dcd0f07058a353bc3a81f4028b8c77c92c87fce6d5c8b85970a20b@buzz.block.builderlab.xyz> Co-authored-by: Brain <1a02c72794dcd0f07058a353bc3a81f4028b8c77c92c87fce6d5c8b85970a20b@buzz.block.builderlab.xyz>	2026-09-11 09:10:43 -06:00
Will Pfleger	47d068e210	feat(cli): add buzz gifs command group and NIP-30 emoji tags on messages (#7259) ... ## What Two new agent-facing capabilities in `buzz-cli`: ### 1. `buzz gifs` command group (agent KLIPY picker path) Agents can now search and share GIFs via the relay's authenticated KLIPY proxy without holding a provider credential. ```bash buzz gifs search # trending GIFs buzz gifs search --query "celebration" # search GIFs buzz gifs share --slug <slug> # report selection to provider Recents ``` Output is a JSON array of GIF objects. Paste the `cdn_url` field directly into `buzz messages send --content` — sending a GIF is a plain message containing the CDN URL, no special send-path handling. **Implementation details:** - Gates on NIP-11 `supported_extensions` containing `buzz-gif` and `gif.provider == "klipy"` - Uses relay-relative paths from the NIP-11 `gif` descriptor — no hardcoded paths; safe-path validation mirrors `desktop/src/features/gifs/api.ts` - New `post_json_authed` helper in `BuzzClient` handles NIP-98-signed JSON POSTs and 204 No Content responses - `customer_id` derived as `SHA-256(secret_key_bytes || '\0' || relay_url_bytes)[..16]` → 32 hex chars: stable, relay-scoped, not computable from public data, no storage needed - `locale` defaults to `$LANG` (stripped of encoding suffix) or `en_US` ### 2. NIP-30 custom emoji tags on outgoing messages `buzz messages send` now automatically attaches `["emoji", shortcode, url]` tags for any `:shortcode:` patterns in the content that resolve in the workspace palette — identical to the desktop composer behavior. ```bash buzz messages send --channel <uuid> --content "hello 👋 everyone 🎉" # → event carries ["emoji", "wave", "..."] and ["emoji", "tada", "..."] tags ``` **Implementation details:** - Hand-rolled single-pass scanner (no new dependency) implementing `:([a-z0-9_-]+):` case-insensitively with canonical lowercase output — mirrors `desktop/src/shared/lib/customEmojiTags.ts` exactly - Zero extra relay round-trips when content contains no `:` character; one `query` when candidates exist but none match - Palette fetch reuses the existing `union_custom_emoji` logic from `commands/emoji.rs` - `build_message` in `buzz-sdk` gains a new `emoji_tags: &[Vec<String>]` parameter (additive — all existing callers pass `&[]`); NIP-30 tag attachment lives in the SDK alongside `imeta` tags - MCP send path (`buzz-acp`) continues to pass `&[]` and is not affected; the MCP gap is noted in a comment ## Files changed | Crate | File | Change | |-------|------|--------| | `buzz-cli` | `src/commands/gifs.rs` | New — search + share handlers, NIP-11 gating, tests | | `buzz-cli` | `src/commands/mod.rs` | `pub mod gifs` | | `buzz-cli` | `src/lib.rs` | `Gifs(GifsCmd)` variant, dispatch arm, inventory test update | | `buzz-cli` | `src/client.rs` | `post_json_authed` helper | | `buzz-cli` | `src/commands/emoji.rs` | `scan_shortcodes` + `resolve_emoji_tags_for_content` + tests | | `buzz-cli` | `src/commands/messages.rs` | Emoji scan + tag injection in `cmd_send_message` + seam tests | | `buzz-cli` | `README.md` | `buzz gifs` section + emoji-in-messages note | | `buzz-sdk` | `src/builders.rs` | `build_message` gains `emoji_tags` param + tests | | `buzz-acp` | `src/pool.rs` | Update `build_message` call site (`&[]`) | | `buzz-acp` | `src/setup_mode.rs` | Update `build_message` call site (`&[]`) | | `countdown-bot` | `src/main.rs` | Update `build_message` call site (`&[]`) | Relates to: https://buzz.block.builderlab.xyz — buzz-team channel thread on agent GIF/emoji support --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-09-02 20:03:38 -04:00
Will Pfleger	0808ab485c	fix(cli): enrich template cardinality error with per-candidate presence and profile hints (#4825) ... ## Problem `buzz channels create --template` fails with a bare-pubkey duplicate-instance error when a persona has more than one live instance. When duplicate instances share the same display name and avatar, the error gives the operator no signal to identify which instance is stale. ## What changed **`crates/buzz-cli/src/commands/channels.rs`** (boundary) + one visibility line in **`crates/buzz-cli/src/commands/users.rs`** (`fn presence_subject` → `pub(crate)`), plus a relay behavior change in **`crates/buzz-relay/src/api/bridge.rs`** and a supporting test in **`crates/buzz-pubsub/src/presence.rs`**. ### Relay: presence-lookup failure is now surfaced as a failure `synthesize_presence` previously collapsed a Redis `get_presence_bulk` error into `unwrap_or_default()` → HTTP 200 `[]`, making a backend outage indistinguishable from an authoritative all-offline snapshot. It now returns `Option<Result<Vec<Value>, (StatusCode, Json<Value>)>>`: `None` means the request is not a presence query (fall through), `Some(Ok)` is a real snapshot (an empty vec is an authoritative all-offline result), and `Some(Err)` is a backend failure surfaced as a non-2xx response. The event tag-parse and sign paths were converted from `.ok()?` fall-throughs to explicit `Some(Err(...))` for the same reason — a silent fall-through would have reintroduced the fake-empty-success anti-pattern. The function takes `pubsub` and `relay_keypair` directly rather than the whole `AppState`, which keeps the Redis-error seam unit-testable without live infrastructure; its single production caller was updated accordingly, and no other caller consumes `synthesize_presence`. ### Hint fetch architecture **`assemble_roster_resolution<F, Fut>`** — post-fetch stage extracted from `build_roster_resolution` as an injectable-fetcher async generic. It contains: archive-filter-based duplicate detection, the conditional `fetch_hints` call, and `finalize_roster_resolution` delegation. Accepting the fetcher as a closure makes the wiring directly testable without a relay. `build_roster_resolution` reduces to: gather slugs → `tokio::join!(scan, archive)` → delegate with the real `fetch_candidate_hints` closure. **Zero hint queries on the happy path**: `assemble_roster_resolution` only invokes the fetcher when duplicate live instances exist after archive filtering. Untrusted archive snapshot (`Err`) conservatively treats all found instances as live. When duplicates exist, `fetch_candidate_hints` runs the presence (kind:40902) and profile (kind:0) queries concurrently, bounding **each independently** through `join_bounded_queries`: a per-query 3-second timeout maps to `Err`, so a lookup that completes is never discarded because its sibling hung. On total failure or timeout, bare pubkeys are printed promptly. ### Trusted-snapshot boundary — `hints_from_results` The relay drops the Redis presence key when an identity goes offline, so the bulk presence snapshot never returns an event for an offline instance — precisely the stale duplicate an operator needs flagged. `hints_from_results` therefore treats a *trusted* presence snapshot as a **complete snapshot** for the requested pubkeys: it seeds all of them `offline`, then overlays returned statuses. A response is trusted only when `trusted_presence_snapshot` validates **every** array element as the actual snapshot contract: each must parse as a complete signed `nostr::Event` of the presence-update kind carrying exactly one `p` tag whose subject is one of the requested pubkeys. Requiring the *sole* `p`-tag subject — the exact value `build_hint_map` later reads via `presence_subject` — is what stops a mixed-tag event (`[["p","<unrequested>"],["p","<requested>"]]`) from passing the gate yet overlaying a different subject downstream. Any element that is not such an event — a vacuous object like `{"pubkey":"…","content":"online"}`, `[{}]`, `[null]`, an event of the wrong kind, one for an unrequested subject, or one carrying more than one `p` tag — makes presence enrichment untrusted: nothing is seeded `offline`, so absence is never falsely inferred as offline. A failed, timed-out, or non-array presence response is likewise untrusted. In every untrusted case the successful profile sibling still contributes its hints. ### Response-to-map conversion — `build_hint_map` Sync production function taking the offline seed plus raw presence/profile event slices. Relay-signed presence events carry the agent pubkey in the `p` tag (not the event author); `build_hint_map` calls `presence_subject` from `users.rs` (now `pub(crate)`) to resolve the correct key. ### Hint display — `format_candidate` Appends `[online/offline, profile updated YYYY-MM-DD]` (or subset) to each candidate pubkey in the error. `profile_updated_at` names the field correctly: kind:0 is replaceable state that desktop republishes on rename and profile reconciliation, so `created_at` reflects the last profile update, not provisioning time. Date formatted via `chrono::DateTime::from_timestamp`; out-of-range timestamps omit the date. Missing entries fall back to bare pubkeys. ### Cardinality rule `apply_cardinality_rule` remains pure and relay-free; zero/one/many semantics unchanged. --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Signed-off-by: Carl <9d00794d3df50972eb8b615511783cab12a77a8fd5dd5edd58073ec73b54bd8b@buzz.block.builderlab.xyz> Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: npub1g8493u0xfsjrvflg4n08ezd7vec99mnwzlv0qgwpr9d7gvjwhuzqx59rhw <41ea58f1e64c243627e8acde7c89be667052ee6e17d8f021c1195be4324ebf04@buzz.block.builderlab.xyz> Co-authored-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-08-27 14:40:53 -04:00
thomaspblock	de188ebf06	feat(projects): add agent and CLI project-home support (#6590) ... ## Summary - inject bounded project-home identity and repository context into managed agent sessions - add project-aware CLI flows for creating projects, repositories, issues, and related channels - match project homes through the existing relay query surface, then filter channel metadata client-side This is Part 1 of the channel-first Projects stack. Part 2 contains project creation and model foundations. ## Testing - `cargo fmt --all -- --check` - `cargo clippy -p buzz-cli -p buzz-acp --all-targets -- -D warnings` - `cargo test -p buzz-cli -p buzz-acp` — 1,184 tests passed, 1 doc test ignored - full pre-push gate passed ## Post-Deploy Monitoring & Validation - validate project-home agent context and project-aware CLI commands against a staging relay - healthy signals: project context matches the active channel, explicit repo coordinates remain stable, and normal channels receive no project block - failure signals: cross-channel project context, duplicate project creation, or commands targeting an unrelated repository; mitigate by reverting this PR --------- Signed-off-by: Thomas Petersen <thomasp@squareup.com> Signed-off-by: Wrench <0eabe6ea5758c1e4c5b68cea4ac42b32c479072883cb28da8110b4a47c32b9a1@buzz.block.builderlab.xyz> Co-authored-by: Wrench <0eabe6ea5758c1e4c5b68cea4ac42b32c479072883cb28da8110b4a47c32b9a1@buzz.block.builderlab.xyz>	2026-08-26 12:09:06 -07:00
Wes	583af02299	fix(cli): preserve signatures in event reads (#6884) ... ## Summary - preserve string Nostr `sig` values in normal `messages get`, `messages thread`, `messages search`, and `feed get` output - omit absent or non-string signatures instead of fabricating empty values - keep compact output at exactly `{id, content, created_at}` and update CLI/managed-agent contract docs ## Validation - `cargo test -p buzz-cli --lib` (367 passed at final head `a2498faa0e07f90efc0ab0165606ba3b048327c7`) - release candidate live-relay matrix: 49/49 normal events independently recomputed to their NIP-01 IDs and passed BIP-340 verification; all four compact commands preserved exact three-key output and ordering - `git diff origin/main...HEAD --check` - independent adversarial review: clear, no findings ## Compatibility The normal JSON change is additive for valid relay events. In-repo consumers use tolerant field lookup. Compact output is unchanged and locked by regressions for both message and feed formatting. Generated by Carl, an automated contributor working with Wes. --------- Signed-off-by: Carl <9d00794d3df50972eb8b615511783cab12a77a8fd5dd5edd58073ec73b54bd8b@buzz.block.builderlab.xyz> Co-authored-by: Carl <9d00794d3df50972eb8b615511783cab12a77a8fd5dd5edd58073ec73b54bd8b@buzz.block.builderlab.xyz>	2026-08-26 09:13:11 -06:00
Will Pfleger	c6e3fe7dfa	feat(workflows): reply in-thread from send_message action (#6178) ... The `send_message` workflow action could only post new top-level channel messages. This adds a `reply_in_thread` option so a `message_posted` workflow can reply in the triggering message's thread, plus a `trigger_is_reply` filter variable so a workflow can fire only on top-level messages. Every NIP-10 thread-marker reader in the tree now routes through one shared parser and one collapse rule in `buzz-core`, deleting four hand-rolled copies that had drifted on id-validity and marker semantics. ## What changed - **Schema** (`crates/buzz-workflow/src/schema.rs`): new `reply_in_thread: bool` (serde default `false`) on `ActionDef::SendMessage`. `validate()` rejects `reply_in_thread: true` on `schedule`/`webhook` triggers — they carry no message to reply to. - **Executor** (`crates/buzz-workflow/src/executor.rs`): threads `reply_to: Option<&str>` (the trigger `message_id`) through `ActionSink::send_message` when `reply_in_thread` is set; errors clearly if the trigger has no `message_id`. `resolve_step_templates` carries the new field. Adds `trigger_is_reply` (boolean) to the eval context. - **Relay sink** (`crates/buzz-relay/src/workflow_sink.rs`): when `reply_to` is set, resolves parent/root/depth from the known trigger event, persists real thread metadata instead of the hardcoded top-level `depth: 0`, and pushes the live kind:39005 thread-summary overlay after insert so subscribed desktops update the root's reply badge without refetching — matching the human ingest path. Emits the same NIP-10 `e`-tag shape as `buzz_sdk::builders::thread_tags`: a single `["e", id, "", "reply"]` tag for a direct reply (parent == root), and the `root` + `reply` pair only when nested — so every writer produces one wire shape per reply kind. - **Ingest resolver** (`crates/buzz-relay/src/handlers/ingest.rs`): new `resolve_relay_reply_thread_meta` + `ReplyAncestry`. Unlike the client-facing `resolve_nip10_thread_meta` (which validates client-supplied tags), this computes root/depth from the known parent and enforces the same same-channel and depth-limit invariants. When the parent has no `thread_metadata` row, both resolvers share `derive_ancestry_from_parent_tags`, which applies `ThreadMarkers::resolve()`: a marked nested parent remains depth 2, while a root-only, malformed, or unmarked parent is top-level and starts its reply thread at itself. Both the client resolver and the parent-ancestor fallback now read markers via the shared parser instead of hand-scanning `e`-tags. - **Shared NIP-10 parser** (`crates/buzz-core/src/nip10.rs`): `parse_thread_markers` reads an event's `root`/`reply` markers, honoring a marker only when its event id is exactly 64 ASCII-hex characters. `ThreadMarkers::resolve()` is the single definition of the (root, reply) → (root_id, parent_id) collapse: `root`+`reply` as-is, `reply`-only → `(reply, reply)`, a lone `root` or neither → top-level. A slice-based `parse_thread_markers_from_parts` entry point serves consumers holding raw JSON tag arrays. Relay ingest, the workflow `trigger_is_reply` predicate, ACP anchoring, and the CLI reply resolver all call these, so they cannot drift on marker, id-validity, or collapse semantics. - **ACP** (`crates/buzz-acp/src/queue.rs`): `parse_thread_tags` delegates marker parsing and collapse to `buzz_core::nip10`, keeping only its local `p`-tag mention collection. This fixes a parity gap with ingest: a malformed non-64-hex marker id is no longer counted as a thread link, and a lone `root` marker is now top-level rather than being treated as root == parent. - **CLI** (`crates/buzz-cli/src/commands/messages.rs`): `find_root_from_tags` routes its JSON tags through the shared slice parser and collapse rule. CLI replies to root-only, malformed, or unmarked parents now correctly start at that immediate parent; reply-only and root+reply parent ancestry remain intact. - **Trigger context** (`crates/buzz-workflow/src/lib.rs`): `build_trigger_context` derives `is_reply` solely from a valid NIP-10 `reply` marker (no DB hit). A lone `root` marker is top-level to ingest, so it does not count; neither does a `reply` marker whose event id is malformed, nor a bare/unmarked `e`-tag (mentions, quotes). - **Desktop** (`workflowFormTypes.ts`, `WorkflowStepCard.tsx`): `replyInThread` form field with YAML round-trip, and a "Reply to triggering message in thread" checkbox shown only for message-based triggers. Switching to `schedule` or `webhook` clears the option on every step before serialization, so a value hidden behind an action change cannot resurrect when the action is switched back. The form parser also requires `reply_in_thread` to be a boolean and refuses `reply_in_thread: true` under an ineligible trigger, falling back to YAML mode rather than silently normalizing a backend-invalid definition. ## Usage ```yaml trigger: on: message_posted filter: trigger_is_reply == false steps: - id: auto_reply action: send_message text: "pre-written reply text" reply_in_thread: true ``` --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-08-20 19:44:21 -04:00
morgmart	84c095f8be	feat(cli): accept Buzz message links for thread reads (#6359) ... ## Summary - let `buzz messages thread` accept a canonical `buzz://message` link directly - treat the selected message ID as authoritative, verify its channel, and derive its containing thread root from the event - reject stale or forged `thread` hints that disagree with the selected message - preserve the existing `--channel` / `--event` form while allowing it to target any message in a thread ## Why Agent skills should be able to hand first-class Buzz links to the public Buzz CLI instead of carrying their own URL parsing wrappers. Link handling belongs with the CLI that owns the protocol; identity and relay selection remain explicit through the existing Buzz CLI environment and do not read Buzz Desktop private state. ## Verification - `cargo test -p buzz-cli` — 360 passed - `cargo clippy -p buzz-cli -- -D warnings` - `cargo fmt --all -- --check` - repository pre-push gates, including 5,070 Desktop tests - final architecture/code review — no must-fix findings A relay-backed manual smoke test was not run because this session did not have `BUZZ_RELAY_URL` and `BUZZ_PRIVATE_KEY` configured; the change has focused parser, CLI argument, channel/root binding, and mismatch tests. --------- Signed-off-by: morgmart <98432065+morgmart@users.noreply.github.com>	2026-08-20 12:17:50 -06:00
Salman Mohammed	2a236e4137	refactor(prompt): simplify Buzz agent guidance (#6340) ... ## Why The Buzz agent prompt carries verbose agent-draft instructions that add prompt weight without improving benchmark correctness. Buzz-native channel trials also showed agents creating permanent channels while claiming they had applied a one-hour TTL. The static CLI inventory remains for efficient command discovery by smaller agents. ## What - Retain the static Buzz CLI command table and direct agents to use `--help` for full usage - Compact the owner-reviewed agent-draft guidance without changing its workflow - Clarify that `buzz channels create` is permanent unless `--ttl` is provided ## Benchmark Results - Terminal-Bench retained 22/22 correctness in the initial no-table candidate while reducing prompt size, input tokens, tool calls, and cost; total active time was effectively flat. - Across two Buzz-native runs, the non-channel cases tied at 26/30; the CLI clarification directly addresses the observed TTL omission. ## Update — 2026-08-20 - Restored the CLI command table following review feedback about multistep discovery with smaller agents. The restored-table candidate has not been re-benchmarked. Signed-off-by: Salman Mohammed <smohammed@squareup.com>	2026-08-20 14:59:57 +00:00
Salman Mohammed	a9640c7cc4	Add Buzz-native collaboration benchmarks (#6264) ... ## Why Terminal-Bench can show task correctness while missing Buzz-specific collaboration failures, such as posting a final answer outside the user's thread. Add a small Buzz-native suite that scores relay behavior directly. ## What - Add Harbor tasks for direct thread replies, event-level callback mentions to a three-word user identity, targeted reads of explicitly named paths outside the workspace, and exact temporary-channel membership against a seeded directory of 50 users and 10 bots - Export sanitized post-agent relay evidence and extend solo runtime/provisioning for deterministic verification - Expose channel TTL in CLI search output and cover positive and negative transcript/state fixtures ## Risk Assessment Low to medium — this primarily adds benchmark and testbed machinery. The CLI change is an additive `ttl_seconds` field in channel-search JSON; relay behavior is unchanged. ## References - Motivated by the Buzz-specific behavior observed while benchmarking https://github.com/block/buzz/pull/6128 - The named-path regression case covers the issue being fixed by https://github.com/block/buzz/pull/6261 - Local live Sonnet runs: `reply-to-thread`, `user-mention`, and `create-channel-invite-users` each scored reward 1.0 with zero exceptions - The current branch prompt scored 3/5 on a concurrent `read-named-path-outside-workspace` batch: one explicit workspace-boundary refusal and one missing final response Generated with Codex --------- Signed-off-by: Salman Mohammed <smohammed@squareup.com>	2026-08-20 10:14:39 -04:00
Illumi	a282e0643f	fix(cli): keep project replacement timestamps at or after wall clock (#5666) ... Fixes #5665. `next_timestamp` in `crates/buzz-cli/src/commands/projects.rs` computed a replacement's `created_at` as `head.created_at + 1`. The relay's ingest path rejects events more than ±900s from server time (`MAX_TIMESTAMP_DRIFT_SECS` in `crates/buzz-relay/src/handlers/ingest.rs`), so: - `projects update` on any project whose head is older than 15 minutes fails with `relay error 400: invalid: event timestamp too far from server time` (live repro in #5665); - inside the window, replacements are recorded at `head+1` — seconds-to-minutes in the past — so a concurrent wall-clock writer silently wins LWW and audit timestamps misstate when the write happened. ## Change `next_timestamp` now returns `max(now, head.created_at + 1)`: strictly after the observed head (preserving the dominate-the-head guarantee for skewed/future heads), never behind the wall clock. This mirrors the relay's own replacement-authoring pattern (`now.max(head+1)` in `side_effects.rs`). ## Testing - `cargo test -p buzz-cli --lib` — 344 passed; adds `next_timestamp_uses_wall_clock_when_head_is_stale`, and the existing far-future-head test still holds (`head+1` wins when head > now) - `cargo clippy -p buzz-cli --all-targets` / `cargo fmt --check` — clean - Live before/after on a self-hosted relay: vanilla CLI fails on a 2h-aged head; with this change the same update is accepted and the head lands at wall clock. Same failure family as #2876 (`repos protect` vs the drift window) — that path is not touched here. --------- Signed-off-by: Ika Minami <ika@infiniteidol.com> Signed-off-by: Ravneet Arora <rarora@squareup.com> Co-authored-by: Ika Minami <ika@infiniteidol.com> Co-authored-by: Ravneet Arora <rarora@squareup.com>	2026-08-17 12:49:52 -07:00
Taylor Ho	edc4a09aaa	feat(workflows): add responsive library card actions (#6008) ... **Category:** improvement **User Impact:** Users can scan what each workflow does and trigger, edit, duplicate, enable, disable, or delete it directly from the library. **Problem:** The workflow list buried common actions and did not expose each automation's trigger-to-action shape at a glance. **Solution:** Add a responsive workflow library with a persistent create tile, compact trigger/action diagrams, prominent workflow titles with supporting descriptions, and shared card actions while preserving existing detail, editor, and run-history entry points. Card toggles refresh both list and open-detail caches so status and definition stay consistent. <details> <summary>File changes</summary> **desktop/src/features/workflows/ui/WorkflowActionsMenu.tsx** Adds a shared card menu for trigger, edit, duplicate, enable/disable, and delete actions. **desktop/src/features/workflows/ui/WorkflowCard.tsx** Reworks cards around the prototype's visual hierarchy: color-coded trigger, action flow, sentence-case eyebrow, prominent title, supporting description, status, channel, and update date without a footer clock icon. **desktop/src/features/workflows/ui/WorkflowsView.tsx** Adds the responsive grid, create tile, mutation wiring, and list/detail cache invalidation. Container breakpoints keep cards two-across at medium widths and three-across in the 1280px desktop layout. **desktop/src/features/workflows/ui/workflowDefinition.ts** Adds immutable enabled-state updates plus narrow trigger and first-action readers used only to select card icons. **desktop/src/features/workflows/ui/workflowDefinition.test.mjs** Covers neutral icon selection, enabled-state immutability, and status presentation. **desktop/tests/e2e/workflows.spec.ts** Covers the create tile, title/description hierarchy, selected-card enable/disable consistency, and deterministic narrow/medium/wide captures while retaining existing action coverage. </details> ## Reproduction steps 1. Open **Workflows** and confirm the create tile stays first as cards flow from one to three columns with available width. 2. Confirm each card shows a sentence-case trigger eyebrow, prominent workflow title, supporting description when present, status, channel, and update date without a clock icon. 3. Open a card's overflow menu and trigger, edit, duplicate, enable/disable, or delete the workflow. 4. Leave the detail panel open while toggling and confirm its badge and JSON definition update with the card. ## Screenshots Real built E2E UI with representative workflow data at three viewport sizes. ### Narrow — 800 × 720  ### Medium — 1024 × 720  ### Wide — 1280 × 720  ### Card actions  --------- Signed-off-by: Taylor Ho <taylorkmho@gmail.com>	2026-08-17 16:56:34 +00:00
thomaspblock	122a8b8988	Projects v3: unify sharing, discussions, and issue ownership (#5792) ... ## Summary Projects v3 makes repository work shareable, discussion-aware, and easier to scan in one coherent workspace. People can copy canonical links, reopen the exact workspace tab, understand issue and pull-request context at a glance, find related channel conversations, and assign or unassign issues across Desktop and CLI. - **Unified workspace** — top-level sections sit above repository controls in one rounded workspace, with navigation positioned close to the page heading. README and Files retain branch selection; every section has a labeled icon header, and Issues and Pull Requests expose creation from a consistent right-aligned action. - **Repository management** — the repository selector is always available, including single-repository projects. Its integrated add flow lets project owners create a repository manually or select an existing repository without a separate toolbar button. - **Readable work-item lists** — issue and pull-request rows use plain-language context instead of opaque metadata. Files, commits, issues, pull requests, channels, and contributors share consistent row density and right-aligned timestamps, while deterministic fallback-avatar colors keep participants distinct on light backgrounds. Inbox pull-request metadata wraps between complete phrases and truncates long channel names instead of compressing copy into narrow columns. - **Reliable entity links** — projects, repositories, issues, pull requests, and commits have canonical `buzz://` links, preview cards, OS deep-link routing, and tab-aware navigation. Reopening the same link re-applies its destination instead of leaving the user on a locally selected tab. - **Related conversations** — repository and work-item views surface channels discussing the current entity, including participants, channel navigation, message context, and an explicit notice when discovery reaches its 500-result cap. - **Reversible issue ownership** — trusted assignment and unassignment events work across Desktop, Tauri, `buzz-sdk`, and `buzz issues`. Assignees appear in project views and the assigned inbox, while authorized users can remove assignments directly from the assignee row. Assignment state is derived chronologically from labeled Nostr notes. Issue authors and repository owners may change any assignee; other users may only assign or unassign themselves. Shared golden fixtures keep entity-link grammar and validation aligned across TypeScript and Rust. The branch also updates `webbrowser` to the patched release for RUSTSEC-2026-0257. ### Related issue N/A. ### Testing - [x] `just ci` — formatting, lint, typechecking, unit tests, and builds passed - [x] Full pre-push suite — organization, branch-skew, Desktop checks, typechecking, and tests passed on the latest push - [x] `cargo test -p buzz-cli` and focused `buzz-sdk` assignment tests passed - [x] Focused Tauri recipient-note and 500-result search-limit tests passed - [x] Desktop entity-link and issue-assignment unit tests passed - [x] Playwright smoke coverage passed for assignment, repeated entity-link navigation, repository create/select flows, section headers and actions, timestamp alignment, timeline icons, sentence-style issue/PR metadata, header spacing, avatar contrast, and Inbox metadata at stacked and side-rail breakpoints - [ ] Manual staging pass: link round-trips, Channels tab, assignment flows, and inbox routing ### Screenshots Pull requests explain who opened the request, where it lives, and which branch it comes from; fallback avatars remain visually distinct.  Issues use the same sentence-style hierarchy while keeping status and recency easy to scan.  The wide Inbox detail keeps author, timestamp, and origin context readable beside its metadata rail.  [View the complete six-state Projects v3 screenshot set](https://github.com/block/buzz/pull/5624#issuecomment-5268039672) and [the compact/wide Inbox comparison](https://github.com/block/buzz/pull/5624#issuecomment-5268614585). --- > Supersedes #5624, whose head commit accumulated permanently-queued required check suites (block-dco-check et al.) that GitHub never dispatched. History flattened into a single signed-off commit on latest main; tree verified byte-identical (`git merge-tree`) to merging the original branch into main. --------- Signed-off-by: Thomas Petersen <thomasp@squareup.com> Co-authored-by: Wintermute <3f1797424fd9ad6653a83665c660517777cd7f8c228c0d5907f49e01537f3ca5@buzz.block.builderlab.xyz>	2026-08-14 16:48:41 -04:00
Cameron Hotchkies	f8f2ef0440	feat(cli): add --visibility flag to channels update (#5119) ... ## Why `buzz channels update` could already change name, description, and TTL, but the SDK/relay/DB path for channel visibility was unreachable from the CLI. ## What - Add `--visibility open|private` to `buzz channels update` - Pass the visibility value through to `build_update_channel` - Add guard tests proving empty updates still fail and visibility-only updates are accepted ## Risk Assessment Low — this is limited to the buzz-cli update command and uses existing SDK validation plus existing relay/DB handling. ## References - Spike notes: `RESEARCH/SPIKE_CHANNEL_VISIBILITY_TOGGLE.md` - Local validation: `cargo test -p buzz-cli` Generated with Codex Signed-off-by: Cameron Hotchkies <chotchkies@block.xyz> Co-authored-by: Lazy Joe <dbd8c9941ba6dafebcef0abc015b65e75d52e7452f2ce483c9c3fd4d180f2504@buzz.block.builderlab.xyz>	2026-08-10 14:48:30 -07:00
Will Pfleger	b2ac66cde8	refactor(cli): replace probe/decider/detail split with single typed extractor (#5191) ... Replaces the four-helper auth resolution path with two focused functions and adds production async tests that count relay round-trips. **Before:** `resolve_auth` called `resolve_auth_from_profile` (warn-emitting probe into a throwaway sink) → `resolve_auth_deciding` (re-classified the same profile) → `handle_auth_failure` → `auth_failure_detail` (third classification). `Option<Option<&Value>>` encoded a sentinel for unreachable state; tests exercised only the pure sync helper, not the actual fetch count. **After:** - `extract_auth(profile, target, signer) -> Result<[String;4], AuthFailure>` — pure typed extractor; `AuthFailure` now covers `NoProfile` and `NoTagsArray` inline, no separate helper needed - `resolve_auth()` is now the linear state machine: self-check → fetch + extract → on failure: fetch again → route final `Err` to `CliError::Usage` (default) or one admin warning (`--admin`). No throwaway sinks, no duplicate classification, no sentinel type. - Five async tests drive the production resolver through a counted Axum test server on `POST /query` and assert on both return value and exact fetch count: first success (1), retry success (2), double failure / no `--admin` (2 + `Err`), double failure / `--admin` (2 + `Ok(None)` + one warning), self path (0). Two parser tests pin `--admin` on both `archive` and `unarchive`. - `--admin` short help text corrected to describe when the flag takes effect (after extraction fails, not unconditionally). 341 tests passing, clippy clean, fmt clean. --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-08-07 13:12:08 -04:00
Will Pfleger	ee9690a93c	fix(cli): emit structured JSON warning when archive/unarchive owner-auth extraction fails (#4824) ... emit structured JSON diagnostics when NIP-OA owner-auth extraction fails during `buzz agents archive`/`unarchive` ## Problem When owner-auth extraction returned `None`, the CLI silently sent a bare request. The relay replied with `400: missing auth tag` and the caller had no way to know why extraction failed. ## Solution Extract `resolve_auth_from_profile` — a sync function that owns all three warning branches and the success path. `resolve_auth` reduces to: self-check → fetch kind:0 → delegate. - **Four distinct diagnostics**: no kind:0 profile / no tags array / `classify_owner_auth_tag` failure (typed `AuthFailure` enum: `NoAuthTag`, `AmbiguousAuthTag`, `WrongArity`, `NonStringElement`, `InvalidOwnerHex`, `InvalidSigHex`, `OwnerMismatch`) - **JSON format**: each fallback emits exactly one `{"warning":"..."}` line to stderr, matching the CLI's documented structured-stderr contract and the precedent in `channels.rs:597` - **Relay-supplied values** (target pubkey, actual owner pubkey) pass through `serde_json` serialization — no unescaped text - **Admin bare path preserved**: request is always sent after the warning; bare non-self requests are legitimate for relay admins - **Self path unchanged**: silent, no relay query ## Boundary tests Tests call `resolve_auth_from_profile` directly with `&mut Vec<u8>`. Each of the three production `writeln!` calls is covered: deleting any one fails at least one test. Success path asserts zero bytes written. ## Changes `crates/buzz-cli/src/commands/agents.rs` only: - `AuthFailure` enum with `message()` formatter - `classify_owner_auth_tag` returning `Result<[String;4], AuthFailure>` - `extract_owner_auth_tag` reduced to `#[cfg(test)]` `.ok()` wrapper - `resolve_auth_from_profile` sync helper (testable without `BuzzClient`) - `resolve_auth` reduced to self-check + fetch + delegate - 9 new boundary tests replacing the prior test-local helper --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-08-07 10:14:43 -04:00
thomaspblock	a1d78f2959	feat: Buzz entity links — rich preview cards + in-app navigation for repos, PRs, and issues (#4695) ... ## Summary Gives Buzz-hosted git entities the same "GitHub-style" chat experience GitHub links already get: rich preview cards, real titles, and click-through — except clicks navigate **in-app** to the Projects view instead of a browser. - **Spec**: `docs/buzz-entity-links.md` — link scheme, slices, and deferred work (`buzz://project`, OS deep links, web routes). - **Canonical `buzz://` deep links**: new `desktop/src/shared/lib/entityLink.ts` with builders + strict parser for `buzz://pr?id=…&owner=…&d=…`, `buzz://issue?…`, and `buzz://repo?owner=…&d=…`, mirrored by a Rust module (`crates/buzz-cli/src/links.rs`) with a shared golden-format test so the two implementations can't drift. - **Preview cards**: `linkPreview.ts` recognizes `buzz://` entity links *and* HTTPS relay clone URLs (`{origin}/git/<pubkey>/<repo>`, the shape agents paste today). Both normalize onto the canonical `buzz://` href, so the two spellings of a repo dedupe to one `Buzz`-provider card (`BuzzMark` logo) rendered by `link-preview-attachment.tsx`. - **Title enrichment**: PR/issue cards fetch the real subject from the relay event (`subject` tag or first content line) via `useResolvedLinkPreviews.ts`; the cache is community-scoped and reset in `resetCommunityState()`. - **In-app navigation**: clicking a card or inline anchor (including HTTPS relay clone URLs whose origin matches the active relay) routes to the canonical `30617:<owner>:<d>` coordinate via `goProject()` (`markdown/entityLinks.tsx`). **Merge dependency: #4671 must merge first** — route resolution for `30617:` coordinates is implemented on that branch (`feat/multi-repository-projects`). Entity-link and external-anchor logic were extracted out of `markdown.tsx` to stay under the file-size ratchet. - **Agent side**: `buzz pr open`, `buzz issues create`, and `buzz repos create` now return a ready-made `link` field (omitted when the relay returns `accepted: false`), and `base_prompt.md` instructs agents to paste it verbatim when announcing work. ## Test plan - [x] Desktop unit tests: pass, including new `entityLink.test.mjs` and `linkPreview.test.mjs` coverage (golden formats, malformed-link rejection, clone-URL/`buzz://` dedupe, origin-gated anchor behavior, label-must-win invariant, cache epoch) - [x] Rust: `cargo test -p buzz-cli` golden-format test + accepted/rejected link guard assertions, clippy + fmt clean - [x] Biome + `tsc --noEmit` clean; pre-push hooks (desktop-tauri-checks, rust-tests, desktop-test) pass - [ ] Manual: paste a relay clone URL and a `buzz://pr` link in a channel — verify one card each, real PR title, and in-app navigation to the Projects view Related: [#4671](https://github.com/block/buzz/pull/4671) --------- Signed-off-by: Thomas Petersen <thomasp@squareup.com> Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: npub1g8493u0xfsjrvflg4n08ezd7vec99mnwzlv0qgwpr9d7gvjwhuzqx59rhw <41ea58f1e64c243627e8acde7c89be667052ee6e17d8f021c1195be4324ebf04@buzz.block.builderlab.xyz> Co-authored-by: Will Pfleger <pfleger.will@gmail.com>	2026-08-04 17:54:14 -04:00
thomaspblock	e30db7028f	feat(projects): support multiple repositories (#4671) ... ## Summary - adopt the finalized NIP-MP project model so one project can enumerate and switch between multiple NIP-34 repositories - add project and repository navigation, activity summaries, existing-repository attachment, and repository access-channel management - preserve privacy-safe activation provenance for agent-authored patches, pull requests, issues, and associated commits ## Test plan - [x] Run desktop typecheck and unit tests - [x] Run focused NIP-MP, repository access, and provenance tests - [x] Run Rust formatting and desktop lint checks - [x] Run the complete pre-push suite after merging current `main` - [ ] Manually verify project creation, repository attachment, switching, and access repair on staging - [ ] Manually verify public-channel and private-agent origin labels on newly created Git activity Related: [#4695](https://github.com/block/buzz/pull/4695) --------- Signed-off-by: Thomas Petersen <thomasp@squareup.com> Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz> Co-authored-by: Will Pfleger <pfleger.will@gmail.com>	2026-08-04 17:30:12 -04:00
Will Pfleger	b7bb15122e	feat(projects): add buzz projects CLI commands (NIP-MP kind:30621) (#4020) ... Implements the `buzz projects` command group — the NIP-MP Phase 2 write path for kind:30621 multi-repo projects. The relay accepted kind:30621 in #3171; this adds the two-layer Rust builder in `buzz-sdk` and the seven CLI commands. ## What this adds ### `crates/buzz-sdk/src/builders.rs` — two-layer builder **Layer A (protocol):** - `validate_project_envelope(tags, content)` — 8 NIP-MP rules in relay order: `d`-cardinality, `d`-empty/length, member-cap (≤64 `a` tags, checked before per-tag parse), member-tag-arity (2–3 elements), member-coordinate grammar (first-two-colons split, literal `30617`, lowercase 64-hex owner, non-empty remainder), member-duplicate (coordinate only, hint ignored), singleton metadata cardinality, byte bounds (`name` ≤256 / `description` ≤2048 / `buzz-channel` ≤256 / `buzz-visibility` ≤256). - `build_project_with_tags(content, tags)` — raw Layer A builder; RMW mutations path. - `ProjectMemberCoord` — `30617:<owner-hex>:<repo-d>` + optional opaque relay hint; equality/Hash by coordinate only. **Layer B (writer policy):** - `build_project(slug, name, description, members, channel, visibility)` — constructs `d` tag, enforces UUID channel and `listed|unlisted` visibility, forces empty content; composes onto Layer A. This is the `create` path. **Shared:** - `build_delete_addressable(kind, pubkey, d)` — generic NIP-09 kind:5 coordinate delete; `build_workflow_delete` now delegates to this. - All 31 `NIP-MP.fixtures.json` cases exercised through `build_project_with_tags`; count assertion guards against omissions. ### `crates/buzz-cli/` — seven commands ``` buzz projects create <slug> --repo <coord> [--name] [--description] [--channel <uuid>] [--visibility listed|unlisted] buzz projects get <slug> [--owner <pubkey>] buzz projects list [--owner <pubkey>] [--limit <n>] buzz projects add-repo <slug> --repo <coord> [--repo <coord>]... buzz projects remove-repo <slug> --repo <coord> [--repo <coord>]... buzz projects update <slug> [--name|--clear-name] [--description|--clear-description] [--channel <uuid>|--clear-channel] [--visibility listed|unlisted|--clear-visibility] buzz projects delete <slug> ``` Command semantics: - **`create`**: all local validation (slug, repos, channel, visibility, name length) fires before the collision preflight — invalid input returns `Usage` without a network call. Routes through Layer B (`build_project`). - **`update`**: at least one setter/clearer required — enforced by a clap `ArgGroup` with `required(true).multiple(true)`, with a runtime backstop for programmatic callers; setter + own clearer are mutually exclusive per clap conflicts. - **`add-repo`/`remove-repo`**: coordinate expansion and dedup fire before head fetch — malformed or duplicate `--repo` values return `Usage` without touching the relay. - **`delete`**: head-based tombstone at `created_at = head + 1`; post-submit re-query verifies tombstone landed. - All mutations: strip `auth`, re-validate full envelope through Layer A; `created_at` advances from observed head, never wall-clock. - Relay hints on existing member tags preserved verbatim through RMW. ## Limitations (recorded, not in scope) - **No relay-hint authoring**: `--repo` carries a coordinate only; existing hinted `a` tags survive RMW unchanged. - **Signer-self delete only**: NIP-OA owner-delete extension not exposed; `delete` targets the signer's own coordinate. - **Deletion durability**: watermark carry-over applies; `delete` is best-effort against a later-arriving replacement. ## Live round-trip 21-step transcript executed against a relay built from `origin/main` `b1b283cd4`, covering create, get, multi-field update (name + description + channel in one call), channel set/clear, add-repo, remove-repo, delete (tombstone verified at `head+1`, repeated delete → `NotFound`). Delta transcript confirmed multi-field update, channel set/clear, no-op add-repo → `Conflict` exit 5, empty update and setter+own-clearer both rejected at parse time. Duplicate create → `Conflict`. Cross-owner `add-repo` with full coordinate exercised. --------- Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-08-02 12:48:49 -04:00
mr-r0b0t.eth	89bf03c05d	fix(nip-oa): accept raw Nostr tag form in parse_json_array (#4203) ... ## What `BUZZ_AUTH_TAG` stored in the **raw Nostr tag form** `[auth,hex,,hex]` (unquoted, comma-delimited — how an `auth` tag serializes inside a Nostr event and how `.env` files commonly store it) was rejected by the CLI: ``` BUZZ_AUTH_TAG is malformed: invalid JSON: expected value at line 1 column 2 ``` …and even when the CLI *could* parse it, it forwarded the raw string as the `x-auth-tag` header, so the relay's `verify_auth_tag` (which expects JSON) rejected it with `403 relay_membership_required`. Two commits close both gaps. ## Commits ### 1. `fix(nip-oa): accept raw Nostr tag form in parse_json_array` `parse_json_array` (`crates/buzz-sdk/src/nip_oa.rs`) only accepted well-formed JSON arrays. Added a fallback: when strict JSON parsing fails *and* the trimmed input is bracket-delimited, split on `,` and treat each field as a string (empty field `,,` → empty string, matching `["auth","hex","","hex"]`). All consumers (`parse_auth_tag`, `verify_auth_tag`, the CLI, `buzz-acp`) benefit from one change at the lowest layer. ### 2. `fix(cli): canonicalize BUZZ_AUTH_TAG to JSON before sending x-auth-tag header` The CLI stored the raw input string and sent it verbatim as the `x-auth-tag` header (`client.rs:618`). Added `canonicalize_auth_tag` in `buzz-sdk`: parse either form, re-serialize to canonical JSON. The CLI now canonicalizes before storing as `auth_tag_json`, so the header is always valid JSON regardless of input form. Together: local parse + wire canonicalization means the raw form works end-to-end. ## Why The raw form `[auth,hex,,hex]` is exactly how an `auth` tag serializes inside a Nostr event. That shape leaks into `.env` files and shell variables because there's no canonical "stored form" outside an event. The SDK + CLI should accept it rather than push quoting/conversion logic onto every consumer (harnesses, agent shells, external tools). ## Security Both changes are purely syntactic — they only change how a 4-element string array is extracted and containerized. All downstream validation is unchanged: - `parse_auth_tag`: still checks exactly 4 elements, `"auth"` label, 64-char lowercase-hex pubkey, 128-char signature. - `verify_auth_tag`: still reconstructs the preimage and verifies the BIP-340 Schnorr signature against the owner pubkey. No new attack surface — a malformed or forged tag is still rejected at the same validation points. ## Tests 4 new tests in `nip_oa::tests`: - `test_parse_auth_tag_raw_nostr_form` — raw form with conditions + empty conditions - `test_parse_auth_tag_raw_form_with_whitespace` — raw form with surrounding whitespace - `test_canonicalize_auth_tag_raw_to_json` — raw→JSON and JSON→JSON normalization All 25 `nip_oa` tests pass (21 existing + 4 new). `cargo fmt --check` and `cargo clippy -p buzz-sdk -p buzz-cli` clean. ## Verification Confirmed end-to-end against a live community relay (`wss://hermesagent.communities.buzz.xyz`): - **Before:** raw `BUZZ_AUTH_TAG` → CLI parse error, or `403 relay_membership_required` if somehow parsed. - **After:** raw `BUZZ_AUTH_TAG` → CLI parses it, canonicalizes to JSON for the header, relay accepts via NIP-OA owner delegation, `buzz channels members` returns the full roster. ## Context Originated from a community investigation where agent-side relay access was failing because the harness-exported `BUZZ_AUTH_TAG` (raw Nostr form) was rejected by the CLI (expecting JSON). This removes the impedance mismatch at the source. --------- Signed-off-by: amanning3390 <adam.manning@pro-serveinc.com> Signed-off-by: Tyler <109685178+tlongwell-block@users.noreply.github.com> Signed-off-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz> Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz> Co-authored-by: Tyler <109685178+tlongwell-block@users.noreply.github.com>	2026-08-01 22:08:15 -04:00
John Matthew Tennant	262f2392e3	fix(cli): resolve agents from owner records (#3178) ... ## Context `buzz users get --name Honey` searches relay-wide profiles and can return an identically named agent owned by someone else. This caused agents from the wrong owner to be added to a channel. ## Summary This bug fix scopes exact-name agent lookup to owner-authored managed-agent records, then cryptographically verifies each returned profile's NIP-OA `auth` tag before asserting ownership. The relay and database contracts remain unchanged. ### Related issue None found. ## Changes - Adds `buzz users get --name Honey --owner me|<hex>|<npub>`. - Resolves `me` to the NIP-OA owner when the CLI runs as an agent, otherwise to the CLI identity. - Matches kind `30177` managed-agent record names exactly and case-insensitively under the requested owner. - Requires exactly one valid NIP-OA `auth` tag whose verified owner equals the requested owner and whose `kind` and `created_at` conditions apply to the profile event before returning `owner_pubkey` or `owned_by_me: true`. - Keeps missing, malformed, stale, condition-mismatched, or unverifiable owner-record candidates visible with `owned_by_me: false` and an explicit `verification` value. - Returns every same-name record for the owner so callers can require explicit selection when duplicates remain. - Preserves the existing output shape and client-side name filter for unscoped searches. - Documents the distinct owner-scoped managed-agent lookup and unscoped NIP-50 lookup modes. ### Testing The reviewer-reproducible red and green commands below exercise the ownership bug against the target branch and this branch. ## Screenshots Not applicable. This is a CLI-only change. ## Reviewer-reproducible examples The lookups below were run against the live relay from `main` and this branch. ### Red: unscoped lookup returns the 100-profile relay-wide cap and excludes John's agents On `main`: ```bash cargo run -q -p buzz-cli -- users get --name Honey \ | jq '{count: length, first_three: .[:3] | map(.pubkey), johns_agents: map(select(.pubkey == "31b29bcbe69d6716fbb7ba33602b89200bfc9ddfdabcfd1ea6fbfa70b816dfc7" or .pubkey == "4597ac725bba33fc7dd0454c1e2316a5ed770426acf667837d46f6553b3fcf54"))}' ``` Observed output: ```json { "count": 100, "first_three": [ "20d27fc6c0ab4f50b66d1a32a64c5ca1fb985254143ce911f61ab7733333c3d7", "00644478cdd9032c563ddc712b3687d8345d948945aab3c18bab95afbf6f519a", "93c16697d0e58007bc11fb953208bc6b1cff387b2dee094abc10bf82dfee5424" ], "johns_agents": [] } ``` `main` also rejects the owner-scoped command: ```bash cargo run -q -p buzz-cli -- users get --name Honey --owner me ``` ```text error: unexpected argument '--owner' found Usage: buzz users get --name <NAME> ``` ### Green: owner-scoped lookup distinguishes verified and unresolved records On this branch: ```bash cargo run -q -p buzz-cli -- users get --name Honey --owner me \ | jq 'map({pubkey,display_name,owner_pubkey,owned_by_me,verification})' ``` Observed output: ```json [ { "pubkey": "0ca77314d7ac8b3fcf6c647cc8cb9c3afd840db3b2a8ff2079f09a168de1827e", "display_name": null, "owner_pubkey": null, "owned_by_me": false, "verification": "missing_profile" }, { "pubkey": "31b29bcbe69d6716fbb7ba33602b89200bfc9ddfdabcfd1ea6fbfa70b816dfc7", "display_name": "Honey", "owner_pubkey": "67252b09c31a995daa63aada26569fbc6a3d12f573113f001ce7432f870da820", "owned_by_me": true, "verification": "verified" }, { "pubkey": "4597ac725bba33fc7dd0454c1e2316a5ed770426acf667837d46f6553b3fcf54", "display_name": "Honey", "owner_pubkey": "67252b09c31a995daa63aada26569fbc6a3d12f573113f001ce7432f870da820", "owned_by_me": true, "verification": "verified" } ] ``` Only the two profiles with valid NIP-OA proofs assert ownership. The owner-authored record whose profile is absent remains visible but cannot be selected as verified ownership. --------- Signed-off-by: npub1qye6rec0htgg3np8yt6plpyyg8cyffaq66emt3kmk05eylckkzhq0hnf2k <0133a1e70fbad088cc2722f41f848441f044a7a0d6b3b5c6dbb3e9927f16b0ae@buzz.block.builderlab.xyz> Co-authored-by: npub1qye6rec0htgg3np8yt6plpyyg8cyffaq66emt3kmk05eylckkzhq0hnf2k <0133a1e70fbad088cc2722f41f848441f044a7a0d6b3b5c6dbb3e9927f16b0ae@buzz.block.builderlab.xyz>	2026-07-30 09:28:10 -04:00
Tyler	788b3c002b	fix(git): channel binding tooling + author remediation for unbound repos (#3626) ... Closes #3527. Repos announced via vanilla NIP-34 (kind:30617 without a `buzz-channel` tag) 404 forever: the SEC-005 read gate requires a channel-membership ACL, and nothing tells the author why or how to fix it. Per the ruling in the originating thread, this ships **bind/rebind tooling plus a narrow author-only remediation carve-out** — the shelved owner-circle approach is intentionally absent. ## Relay - **`api/git/binding.rs` (new):** shared tri-state binding resolver — `Bound(uuid)` / `NotBound` / `Broken`. First-tag, fail-closed: a malformed `buzz-channel` tag is `Broken`, never conflated with "no tag". Both gates use it. - **Read gate (`transport.rs`):** a **never-bound** repo read by **its own announcement author** still returns 404 (status byte-identical to the generic denial) but the body carries remediation: `run: buzz repos bind --id <repo> --channel <channel-uuid> — …`. This leaks nothing — the author announced the repo, and only the author can rebind (30617 is keyed by `(author, d)`). `Broken` bindings stay generic-denial for everyone, including the author (revocation shape). Bound-to-nonexistent-channel stays generic (phase 1; ingest validation is phase 2). - **Push gate (`policy.rs`):** unbound denial now returns `GIT_NO_CHANNEL_BINDING_BODY`. A deploy-skew test pins that the body carries both the new token (`no_channel_binding`) and the legacy phrase (`"no channel binding"`) so already-shipped desktops keep matching. **(Review r1, blocker 2)** `Broken` no longer collapses into "unbound": it denies 403 `invalid channel binding` for *everyone — including the announcement owner —* **before** the owner short-circuit, matching the read gate's fail-closed posture. The remediation token stays NotBound-only. - **`ingest.rs`:** side-effect failure `warn!` → `error!` — prod runs `RUST_LOG=error`, so these failures were invisible during triage. ## Contract - **`buzz-core/git_perms.rs`:** `GIT_NO_CHANNEL_BINDING_TOKEN` / `GIT_NO_CHANNEL_BINDING_BODY` consts as the declared cross-component contract; relay tests and desktop matcher both build on them. ## CLI - **`buzz repos bind --id <repo> --channel <uuid>`** — rebinds an existing announcement, preserving other tags. - **(Review r1, blocker 1)** **`--channel` on `buzz repos create`** — optional; injects exactly one shape-validated `buzz-channel` tag at creation via a pure `build_create_announcement` builder, so the primary create command stops producing repos the relay 404s. UUID existence/membership stays the relay's authority at git-access time (same TOCTOU posture as `repos bind`). Overlaps with #3594 (open, head 6bbe38459) — happy to reconcile whichever lands first; this branch also carries the bind path and tag preservation. ## Desktop - **Rust:** new `commands/project_git_merge_error.rs` (extracted from `project_git_workflow.rs` to respect the 1000-line ratchet); maps the token to a structured `no_channel_binding` error carrying the bind command. - **TS:** new `features/projects/lib/projectBranchErrors.ts` + tests — dual matcher (new token AND legacy spaced phrase); `ProjectBranchDialogs.tsx` uses it. ## Tests / verification (at head f914c7066, base 581baa625) - Workspace `cargo test` green; `clippy -D warnings` clean; desktop Rust 1859 pass; TS 3780 pass; tsc/biome/file-size checks pass. Pre-push hooks re-ran all suites at the pushed head. - Postgres-gated `sec005_read_gate_tests`: all 6 pass, including `read_gate_gives_author_of_unbound_repo_remediation_body` — asserts 404 status, `text/plain` content-type, and exact body bytes, distinguishing remediation from generic denial (a blind `is_err()` can't). - **New (review r1):** `buzz-cli` emitted-event tests — `create_with_channel_emits_exactly_one_binding_tag`, `create_without_channel_emits_no_binding_tag`, `create_rejects_malformed_channel_uuid` (266/266 pass). Postgres-gated `push_gate_denies_owner_through_broken_binding` — owner + malformed-first/valid-second binding → 403 generic body without the remediation token; never-bound control stays 200, pinning the denial to `Broken` specifically. - e2e git tests now bind announcements to a real channel via a `create_test_channel` helper. --------- Signed-off-by: Tyler Longwell <tlongwell@block.xyz> Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz> Co-authored-by: Tyler Longwell <tlongwell@block.xyz>	2026-07-29 20:07:55 -04:00
Logan Johnson	7adc46268d	feat(cli): mirror Desktop mention delivery (#3330) ... 🤖 ## Summary Agent-authored mentions currently depend on matching visible `@Name` text to channel profiles. That makes notification delivery ambiguous when names collide or profiles change, and it encourages an extra post-send lookup just to confirm that the intended `p` tags were emitted. This change makes `buzz messages send` mirror Desktop's existing model: the message keeps a readable name in its content while the recipient pubkey is supplied separately. ```bash buzz messages send \ --channel <UUID> \ --content '@Alice could you review this?' \ --mention <alice-hex-or-npub> ``` `--mention` is repeatable. The CLI normalizes and deduplicates explicit pubkeys, merges them with any names it can resolve from the channel, and gives explicit identities priority under the existing 50-mention limit. Before uploading attachments, signing, or publishing, the command checks every resulting pubkey against the channel's current membership: - Members are mentioned normally. - Non-members stop the send and produce an actionable error. - `--allow-non-member-mentions` deliberately sends notifying `p` tags without adding anyone to the channel. Sending a message never changes membership. On success, `mention_pubkeys` is read from the exact signed event and returned with the relay response, so callers can verify the emitted recipients without another query. Managed-agent guidance teaches this single-command mention flow. Desktop mention behavior and the Nostr event schema are unchanged. Forum guidance is intentionally handled separately in #3596. ### Related issue None found. This replaces the earlier guidance-only approach in this PR with the underlying CLI behavior it required. ### Testing - `cargo test -p buzz-sdk` - `cargo test -p buzz-cli` - `cargo test -p buzz-acp` - `cargo test --manifest-path desktop/src-tauri/Cargo.toml` --------- Signed-off-by: npub1fdupjvyregj3z2tx7gx5x6py04zw89jm5usef9lyea4f3vcgh8qq9zgkdz <4b78193083ca25112966f20d4368247d44e3965ba7219497e4cf6a98b308b9c0@buzz.block.builderlab.xyz> Signed-off-by: npub13n66s06epmqf2kc3v373ez8hj65cuzyvxzjf93vwpervxqn2u7jq2qd9je <8cf5a83f590ec0955b11647d1c88f796a98e088c30a492c58e0e46c3026ae7a4@buzz.block.builderlab.xyz> Co-authored-by: npub1fdupjvyregj3z2tx7gx5x6py04zw89jm5usef9lyea4f3vcgh8qq9zgkdz <4b78193083ca25112966f20d4368247d44e3965ba7219497e4cf6a98b308b9c0@buzz.block.builderlab.xyz> Co-authored-by: npub13n66s06epmqf2kc3v373ez8hj65cuzyvxzjf93vwpervxqn2u7jq2qd9je <8cf5a83f590ec0955b11647d1c88f796a98e088c30a492c58e0e46c3026ae7a4@buzz.block.builderlab.xyz>	2026-07-29 16:37:53 -04:00
Will Pfleger	9beb3b8c6e	fix(cli): mask credential env values in --help output (#3570) ... clap renders live env var values in help text by default. Three args carrying credentials were exposed this way: - `BUZZ_PRIVATE_KEY` in `buzz-cli` (`crates/buzz-cli/src/lib.rs`) - `BUZZ_AUTH_TAG` in `buzz-cli` - `BUZZ_PRIVATE_KEY` in `buzz-acp` (`crates/buzz-acp/src/config.rs`) Add `hide_env_values = true` to each. Env var names remain visible for discoverability; only their runtime values are withheld from `--help` output. Also adds a regression guard in each crate's test module that walks the clap command tree (recursing into subcommands for `buzz-cli`) and asserts every arg whose env var name contains `KEY`, `SECRET`, `TOKEN`, `PASSWORD`, `CRED`, or `AUTH` has `hide_env_values` set. This prevents future credential-bearing args from being added without the masking in place. Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-07-29 12:23:02 -04:00
kagan yaldizkaya	60158fce3e	feat(cli): add users set-status command for NIP-38 profile status (#3253) ... ## Summary The desktop client renders a persistent user status (NIP-38 kind:30315, `d:general`) as the status line on profiles, but the CLI had no way to set it — only ephemeral presence (`set-presence`, kind:20001). Integrations that want a scriptable, durable status line (for example a now-playing music bridge that shows the current TIDAL track on a profile) had no entry point. ## Screenshots <img width="1455" height="960" alt="1" src="https://github.com/user-attachments/assets/f1669ec6-212b-4f6e-ad53-07df9aacffc9" /> <img width="1455" height="960" alt="2" src="https://github.com/user-attachments/assets/5bf70f47-e5b5-4eb0-a426-b5f1ef90d2ec" /> This adds: ```bash buzz users set-status --text "Working on the relay" --emoji "🔧" buzz users set-status --text "" --emoji "🎶" # intentional emoji-only status buzz users set-status --clear # removes the status ``` - Signs and submits the replaceable kind:30315 event via the HTTP bridge (no WS needed — unlike presence, user status is a stored event). - Uses the `d:general` coordinate the desktop client already reads for the profile status line, and the same `emoji` tag shape `SetStatusDialog` publishes. - Event construction lives in `buzz_sdk::build_user_status()`, keyed off `buzz_core::kind::KIND_USER_STATUS`, so the CLI command is a thin sign/submit wrapper. Text and emoji are trimmed; a blank emoji is omitted rather than emitted as an empty tag. - Clearing is the explicit `--clear` flag, mutually exclusive with `--text`/`--emoji`. It publishes an empty-content event carrying only `d:general`, which the desktop treats as no status. `--text ""` with an `--emoji` is an emoji-only status, not a clear. --------- Signed-off-by: Kagan Yaldizkaya <kagan@squareup.com> Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: Will Pfleger <pfleger.will@gmail.com>	2026-07-28 13:44:57 -04:00
Will Pfleger	a041e2d21e	Revert "fix(cli,relay): resolve agents by verified owner" (#3168) ... Reverts block/buzz#2615	2026-07-27 14:10:16 -04:00
John Matthew Tennant	c3084b36d9	fix(cli,relay): resolve agents by verified owner (#2615) ... ## Context `buzz users get --name Honey` searches relay-wide profiles and returns up to 100 identically named results without verified ownership metadata. An agent resolving “my Honey” cannot distinguish the requesting human's agent from another owner's agent, and the owned match can be excluded by the result limit. This caused the wrong Honey and Bumble pubkeys to be added to a channel. ## Summary This bug fix makes personal-agent resolution owner-aware. Callers can filter profiles by a verified owner identity before result limits are applied, and all profile results expose enough ownership context to diagnose duplicate names. ## Changes - Adds `buzz users get --owner me|<hex>|<npub>` for name and pubkey lookups. - Resolves `me` to the NIP-OA owner identity when the CLI runs as an agent. - Filters profiles by the relay's verified `agent_owner_pubkey` relationship before applying the result limit. - Returns `owner_pubkey`, `owner_display_name`, and client-relative `owned_by_me` in compact and JSON output. - Returns an empty result when no owned profile matches instead of removing the ownership constraint. - Rejects malformed owner values instead of silently running an unscoped query; explicit `null` remains equivalent to no owner filter for ordinary CLI lookups. - Rejects owner constraints on specialized channel-window, feed, and thread filters that cannot enforce author filtering. - Scopes owner filtering and enrichment to the active community. - Adds a partial `(community_id, agent_owner_pubkey)` index for owner lookups. - Documents the safe `users get --name Honey --owner me` lookup. ## Reviewer-reproducible examples The relay-backed test creates two same-name agents with different verified owners, queries through the HTTP `/query` route, verifies only the selected owner's agent is returned with verified owner metadata, and verifies a missing owner returns `[]`. ```bash cargo test -p buzz-relay query_agent_owner_returns_only_verified_owner_matches --lib -- --ignored ``` The owner/author intersection and unsupported-specialized-filter contracts also have infrastructure-free relay tests: ```bash cargo test -p buzz-relay agent_owner --lib ``` The CLI surface is visible in command help: ```bash cargo run -q -p buzz-cli -- users get --help | grep -- --owner ``` ```text --owner <OWNER> Filter agents by verified owner (`me`, 64-char hex, or npub) ``` ## Validation - `cargo test -p buzz-cli` (252 passed) - `cargo test -p buzz-db` (84 passed, 122 infrastructure tests ignored) - `cargo test -p buzz-relay --lib` (owner-filter tests pass; the full local suite is blocked by unrelated Postgres pool timeouts in media/admin tests) - `cargo test -p buzz-relay query_agent_owner_returns_only_verified_owner_matches --lib -- --ignored` (passed) - `cargo check --workspace --all-targets` - `cargo fmt --all -- --check` - Pre-push Rust, Desktop, and Desktop Tauri suites passed - Pre-push mobile suite could not start because `flutter` is not installed - `pnpm check:file-sizes` (passed after rebasing onto current `main`) --------- Signed-off-by: npub1qye6rec0htgg3np8yt6plpyyg8cyffaq66emt3kmk05eylckkzhq0hnf2k <0133a1e70fbad088cc2722f41f848441f044a7a0d6b3b5c6dbb3e9927f16b0ae@buzz.block.builderlab.xyz> Co-authored-by: npub1qye6rec0htgg3np8yt6plpyyg8cyffaq66emt3kmk05eylckkzhq0hnf2k <0133a1e70fbad088cc2722f41f848441f044a7a0d6b3b5c6dbb3e9927f16b0ae@buzz.block.builderlab.xyz>	2026-07-27 13:10:42 -04:00
thomaspblock	9081ab0ec9	feat(desktop): make pull request reviews actionable (#2510)	2026-07-24 11:34:25 -04:00
Will Pfleger	df0a086177	fix(cli): install rustls crypto provider to unbreak WSS publishes in release builds (#2590) ... Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>	2026-07-23 15:35:19 -04:00
Will Pfleger	7b25950fca	fix(cli): retry transient relay failures and raise timeouts (#2196) ... Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@sprout-oss.stage.blox.sqprod.co>	2026-07-21 12:17:44 -04:00
thomaspblock	f94324598d	feat(cli): manage repository protection rules (#2193)	2026-07-21 08:57:08 +02:00
Will Pfleger	daf1f40a52	feat(cli): filter archived instances from --template roster resolution (#2207) ... Signed-off-by: Will Pfleger <pfleger.will@gmail.com> Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@sprout-oss.stage.blox.sqprod.co>	2026-07-21 02:02:44 -04:00
Will Pfleger	7d7992067b	feat(cli): add agents archive/unarchive/archived subcommands (#2173)	2026-07-20 23:33:11 -04:00
Tyler	03fe19d603	fix(cli): paginate channel directory queries (#2181) ... Signed-off-by: npub1jh9wn95s0472h86ahapupaf7m6kx4v9sx2n0atj2hltcfer8k06s5n3pyf <95cae996907d7cab9f5dbf43c0f53edeac6ab0b032a6feae4abfd784e467b3f5@sprout-oss.stage.blox.sqprod.co> Co-authored-by: npub1jh9wn95s0472h86ahapupaf7m6kx4v9sx2n0atj2hltcfer8k06s5n3pyf <95cae996907d7cab9f5dbf43c0f53edeac6ab0b032a6feae4abfd784e467b3f5@sprout-oss.stage.blox.sqprod.co>	2026-07-20 19:22:11 -04:00