Files
buzz/crates/buzz-cli/README.md
Blake McAnally 859cb02ec1 feat(cli): sidebar stars, mutes, and project pins (#8781)
> Stacks on #8759 (`bmcanally/cli-sidebar-sections`). The diff shows
only this PR's commits. Merge #8759 first.

## Summary

This change adds three command groups to `buzz sidebar`:

- `buzz sidebar stars list|add|remove --channel <uuid>...`
- `buzz sidebar mutes list|add|remove --channel <uuid>...`
- `buzz sidebar projects list|add|remove --project <address>...`

They edit the same synced documents that Buzz desktop and mobile edit.
The documents are kind:30078 events with the `d` tags `channel-stars`,
`channel-mutes`, and `project-sidebar-membership`. Each document is
encrypted to your own key.

This PR stacks on #8759 (`buzz sidebar sections`).

## Design

**One flag-map module.** `sidebar_flags.rs` serves all three documents.
A small `Spec` value holds the differences: the `d` tag, the collection
name, the flag name, the timestamp unit, and the entry cap.

**One shared read and write path.** `sidebar_sync.rs` holds the head
read, the verification, the decryption, the encryption, the signing, and
the publish. `sidebar sections` now uses it too. No code is duplicated.

**Safety rules, the same as for sections.**
- One head read and one publish for each command.
- The CLI never publishes over a head that it cannot verify or decode.
- `created_at` is `max(now, head + 1)`.
- A relay `duplicate:` reply gives a conflict (exit 5).
- Channel UUIDs and project owners are stored in lowercase.
- A command that changes nothing prints `"message": "unchanged"` and
publishes nothing.
- The ciphertext must not exceed 65535 bytes.

**Wire format.** Desktop is the reference:
- Stars and mutes: `{version: 1, channels: {<id>: {starred|muted,
updatedAt}}}`. `updatedAt` is in seconds. The newest 500 entries stay,
ordered by `(updatedAt, id)`.
- Projects: `{version: 1, projects: {<address>: {selected,
updatedAt}}}`. `updatedAt` is in milliseconds. There is no entry cap.
- `remove` writes a `false` entry. It does not delete the entry. This is
how desktop does it.
- Entries that fail desktop's validation are dropped, as desktop drops
them.

**Differences from the task text.** Desktop does these things
differently, so the CLI follows desktop:
- Project `updatedAt` is in milliseconds (`Date.now()`), not seconds.
- Project membership has no 500-entry cap. The size limit bounds it.
- When two project entries tie, desktop picks "not selected". The CLI
never creates a tie (see below).
- Desktop accepts a legacy array of addresses for projects. The CLI
reads it.
- Mobile does not evict entries. Desktop does. The CLI follows desktop.

**Two rules that are stricter than desktop.**
- A changed entry gets `updatedAt = max(now, old updatedAt + 1)`.
Desktop merges a tie in favor of its local value. A plain `now` could
lose to a same-second entry on another device.
- `remove` of an id that is not set does nothing. Desktop writes a new
`false` entry. The CLI skips it so that it does not publish or use an
entry slot.

A command that would evict one of its own ids (more than 500 new ids)
fails with a usage error.

## Testing

**Ran:**
- `cargo test -p buzz-cli`: 518 passed.
- `cargo clippy -p buzz-cli --all-targets -- -D warnings`: clean.
- `cargo fmt --all --check`: clean.
- `just file-size-check`: passes.

**Test design.** The tests call the production `run` function against an
axum fake relay. The fake relay checks the query filter (kind, `limit:
1`, `consistency: strong`, `#d`). Tests cover:
- the stars and mutes journey (one publish for many ids, canonical ids,
`unchanged`, `false` entries, invalid input)
- an entry newer than the clock, and entries that desktop would drop
- unreadable heads, a forged signature, a foreign author, and a
`duplicate:` conflict
- the 500-entry cap and the refusal to evict own ids
- projects: milliseconds, address checks, the legacy array, no eviction,
and the size cap

**Interop evidence.** I wrote CLI documents and ran desktop's own
TypeScript functions on them with node (`parseStarPayload`,
`parseMutePayload`, `parseProjectSidebarMembershipPayload`, and the
three `merge` functions). Desktop kept every entry. A merge of the
document into itself changed nothing, so desktop sees it as settled. A
device with the older value lost to the CLI edit, both as local and as
remote. Script: `interop-flags.mjs`, output `INTEROP OK`.

**Mutation checks.** I broke each guard once and confirmed that a test
failed. The guards were: the newer-stamp rule, `created_at` after the
head, the 500 cap, the self-eviction refusal, the no-op skip, flag type
validation, negative `updatedAt`, the strict collection check, the
project unit, the project kind and owner checks, the project cap, the
ciphertext cap, signature verification, the author check, UUID
lowercasing, the legacy array, the version check, and keeping `false`
entries. Three mutants first survived (signature, author, negative
`updatedAt`). I added a relay mode that returns foreign and forged
events, and a test for each. Then all were killed.

## Manual test steps

Use a test identity on a staging relay. Set `BUZZ_RELAY_URL` and
`BUZZ_PRIVATE_KEY` first. Pick two channel UUIDs from `buzz channels
list`.

1. Star two channels:
   `buzz sidebar stars add --channel <uuid1> --channel <uuid2>`
Success: JSON with `"accepted": true`. Both channels show a star in
desktop within a few seconds.
2. Run the same command again.
   Success: `"message": "unchanged"` and `"event_id": null`.
3. `buzz sidebar stars list`
   Success: `{"channels": ["<uuid1>", "<uuid2>"]}`.
4. `buzz sidebar stars remove --channel <uuid1>`
Success: the star for `<uuid1>` is gone in desktop. `stars list` shows
only `<uuid2>`.
5. Star a channel in desktop. Run `stars list`.
   Success: the channel is in the list.
6. `buzz sidebar mutes add --channel <uuid1>`
Success: the channel shows as muted in desktop. `mutes remove` unmutes
it.
7. Copy a project address from a project
(`30621:<owner-pubkey>:<d-tag>`). Run
   `buzz sidebar projects add --project <address>`
Success: the project appears in the desktop sidebar. `projects remove`
hides it. `projects list` shows the pinned projects.
8. Run `buzz sidebar stars add --channel not-a-uuid`.
Success: exit code 1 and an "invalid channel UUID" error. Nothing is
published.

🤖 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-06 11:02:11 -06:00

15 KiB
Raw Blame History

Buzz CLI

Agent-first command-line interface for Buzz relay. JSON in, JSON out.

Install

cargo install --path crates/buzz-cli

Authentication

Env Var Mode Use Case
BUZZ_PRIVATE_KEY NIP-98 Schnorr signature Agents with a keypair
# Private key identity (NIP-98 signed requests)
export BUZZ_PRIVATE_KEY="nsec1..."
buzz channels list

Which credentials are used

The CLI uses the first of these that is configured:

  1. An explicit key (--private-key or BUZZ_PRIVATE_KEY), with the headless NIP-FI settings below when they are set.
  2. The Buzz desktop (macOS and Linux), through a token it gave this process or one saved by buzz auth desktop pair. The desktop signs and supplies NIP-FI evidence itself; headless NIP-FI settings are ignored, with a warning naming them.

With neither, commands fail with an auth_error.

Federated identity (NIP-FI)

A relay that enforces federated identity also needs an identity assertion on every protected request (docs/nips/NIP-FI.md). Give the CLI your NIP-FA adapter session and it requests one; the adapter mints it (docs/nips/NIP-FA.md §Relay assertion). The CLI caches the assertion for the process, requests a new one shortly before it expires, and sends it as Nostr-Federated-Identity on HTTP requests and the WebSocket upgrade.

The session is a human sign-in for your own key: the adapter issues assertions only for the key bound to the signed-in user. It is not an agent grant, and it cannot authorize an agent key.

export BUZZ_PRIVATE_KEY="nsec1..."
export BUZZ_FEDERATED_IDENTITY_ADAPTER="https://adapter.example"
export BUZZ_FEDERATED_IDENTITY_TOKEN="..."   # your adapter session token; env only, never a flag
buzz channels list

The token goes only to the adapter, never through a redirect, and never into output. Adapter outages (network errors, 429, 5xx) are retried a bounded number of times and then fail as a retryable adapter_error before anything reaches the relay; an adapter refusal is an auth_error and is not retried. On relays without NIP-FI, leave both unset: nothing changes. An enforcing relay's 401 without them is an auth_error naming both settings.

Usage

All output is JSON on stdout. Errors are JSON on stderr. Exit codes: 0=ok, 1=user error, 2=network, 3=auth, 4=other, 5=write conflict.

# Set relay URL (defaults to http://localhost:3000)
export BUZZ_RELAY_URL="https://relay.example.com"

# Messages
buzz messages send --channel <uuid> --content "Hello"
buzz messages send --channel <uuid> --content "Reply" --reply-to <event-id> --broadcast
buzz messages send --channel <uuid> --content - < message.md   # read body from stdin
buzz messages send --channel <uuid> --content "Decision: ship" --from-thread <root-event-id>   # desktop "Send to channel"
buzz messages get --channel <uuid> --limit 20
buzz messages thread --channel <uuid> --event <event-id>
buzz messages thread --link 'buzz://message?channel=<uuid>&id=<event-id>&thread=<root-id>'
buzz messages search --query "architecture"
buzz messages search --author <pubkey|npub|name> --since <unix-ts>
buzz messages edit --event <event-id> --content "Updated text"
buzz messages delete --event <event-id>
buzz messages report --event <event-id> --reason spam --note "why"   # to moderators only
buzz messages report --pubkey <pubkey> --reason impersonation

# Diffs
buzz messages send-diff --channel <uuid> --diff - --repo https://github.com/org/repo --commit abc123 < diff.patch

# Channels
buzz channels list
buzz channels unread                      # unread counts from your synced read state (read-only)
buzz channels create --name "my-channel" --type stream --visibility open
buzz channels join --channel <uuid>
buzz channels topic --channel <uuid> --topic "New topic"

# Reactions
buzz reactions add --event <event-id> --emoji "👍"
buzz reactions get --event <event-id>

# Huddles (read-only)
buzz huddles list --channel <uuid> --active   # huddles with state and start/end times
buzz huddles participants --channel <uuid> --huddle <huddle-id>

# GIFs (requires relay to advertise buzz-gif / KLIPY)
buzz gifs search                              # trending GIFs
buzz gifs search --query "celebration"        # search GIFs
buzz gifs share --slug <slug>                 # report selection to provider Recents
# Paste the `cdn_url` from a search result directly into messages send --content

# Custom emoji in messages
# buzz messages send scans outgoing content for :shortcode: patterns and
# automatically attaches NIP-30 ["emoji", shortcode, url] tags from the
# workspace palette — identical to the desktop composer behavior.

# Users & Presence
buzz users get                          # your own profile
buzz users get --pubkey <hex>           # single user
buzz users get --pubkey <hex> --pubkey <hex>  # batch (max 200)
buzz users get --name Honey --owner me  # exact-name lookup in your managed agents
buzz users set-presence --status online
buzz users set-status --text "heads down on the CLI" --emoji "🚀"
buzz users set-status --text "lunch" --emoji "🥪" --expires 1h  # clears itself; also a unix time
buzz users set-status --clear                 # remove your status
buzz users status                       # your visible status: [{pubkey, text, emoji, expires_at, updated_at}]
buzz users status --pubkey <hex|npub|name>  # repeatable, max 100; expired or cleared users are omitted

# DMs
buzz dms open --pubkey <hex>
buzz dms list

# Workflows
buzz workflows list --channel <uuid>
buzz workflows trigger --workflow <uuid>
buzz workflows approve --token <uuid>
buzz workflows approve --token <uuid> --approved false --note "needs revision"

# Forum
buzz messages vote --event <event-id> --direction up

# Canvas
buzz canvas get --channel <uuid>
buzz canvas set --channel <uuid> --content "# Welcome"

# Sidebar sections (your own sidebar, synced with Buzz desktop)
buzz sidebar sections create --name "Engineering" --icon "🛠"
buzz sidebar sections move --section "Engineering" --channel <uuid> --channel <uuid>
buzz sidebar sections list

# Sidebar stars, mutes, and project pins
buzz sidebar stars add --channel <uuid> --channel <uuid>
buzz sidebar mutes remove --channel <uuid>
buzz sidebar projects add --project 30621:<owner-pubkey>:<d-tag>
buzz sidebar stars list

# Agent Memory (NIP-AE)
buzz mem ls
buzz mem get <slug>
buzz mem set <slug> "my-value"
buzz mem patch <slug> --base-hash <hex> < diff.patch  # or --no-base-hash
buzz mem rm <slug>

# Repository protection
buzz repos protect list --id my-repo
buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete
buzz repos protect remove --id my-repo --ref refs/heads/main

# Pipe to jq
buzz channels list | jq '.[].name'

sidebar sections edits the signing identity's own sidebar. Each command is one read and one publish, so a multi-channel move lands together. --section takes a section id or a unique section name. A repeated command prints "message": "unchanged" and publishes nothing. Concurrent edits from another CLI run or another client can overwrite each other, and the last publish wins.

sidebar stars, sidebar mutes, and sidebar projects edit the other synced sidebar lists the same way: one head read and one publish per command, and "message": "unchanged" when nothing changes. remove keeps a false entry (as desktop does) so the change syncs; removing an id that is not set changes nothing. Stars and mutes keep the newest 500 entries; a command that would evict its own ids fails. Project addresses are 30621:<owner-pubkey>:<d-tag>. Pass the same ids in any case; channel UUIDs and project owners are stored in lowercase. If the relay reports a newer update (exit 5), run the command again.

protect set replaces every existing rule for the exact ref pattern. Any constraint omitted from the command is removed. protect list reports malformed stored rules in validation_error so an owner can remove and repair them.

Commands

buzz --help prints this whole surface as an indented tree — every group with its subcommands and their descriptions — so there is no need to run --help once per group to find a command. buzz -h keeps the short group-level summary, and buzz <group> <subcommand> --help has the flags and examples. The table below mirrors that tree for readers who are not at a terminal.

Group Subcommand Description
messages send Send a message to a channel
send-diff Send a code diff with metadata
edit Edit a message you sent
delete Delete a message
report Report a message or user to community moderators (NIP-56); reasons: illegal, nudity, malware, spam, impersonation, profanity, other
get List messages in a channel
thread Get a message thread
search Full-text search, filterable by author
vote Vote on a forum post
channels list List channels
get Get channel details
unread Unread counts per channel (read-only)
create Create a channel
update Update channel name/description
topic Set channel topic
purpose Set channel purpose
join Join a channel
leave Leave a channel
archive Archive a channel
unarchive Unarchive a channel
delete Delete a channel
members List channel members
add-member Add a member
remove-member Remove a member
canvas get Get channel canvas
set Set channel canvas
sidebar sections list List your sections and their channels
sections create Create a section at the end of your sidebar
sections update Rename a section or change its icon
sections delete Delete a section
sections reorder Put sections in order
sections move Move one or more channels into a section
sections unassign Return channels to the default channel list
stars list / add / remove List, star, or unstar channels
mutes list / add / remove List, mute, or unmute channels
projects list / add / remove List, pin, or unpin sidebar projects
reactions add React to a message
remove Remove a reaction
get List reactions
huddles list List a channel's huddles (read-only)
participants Show who is in a huddle (read-only)
gifs search Search or browse trending GIFs (requires relay buzz-gif support)
share Report a selected GIF to the provider's Recents
dms list List DM conversations
open Open a DM (1–8 pubkeys)
add-member Add member to DM group
users get Get user profile(s)
set-profile Update your profile
presence Get presence status
set-presence Set presence status
set-status Set or clear your NIP-38 profile status; --expires takes a unix time or 30m/2h/1d/1w
status Read NIP-38 statuses (default: yours); expired or cleared are omitted
workflows list List workflows
get Get workflow definition
create Create a workflow
update Update a workflow
delete Delete a workflow
trigger Trigger a workflow
runs Get workflow run history
approve Approve/deny a workflow step
feed get Get your activity feed
social publish Publish a NIP-01 note
set-contacts Set NIP-02 contact list
event Get a Nostr event
notes Get notes for a user
contacts Get NIP-02 contact list
repos create Announce a git repository (NIP-34)
get Get a repository announcement
list List repository announcements
default-branch get/set Read or select an existing default branch (requires relay support)
protect list List branch and tag protection rules
protect set Create or replace a protection rule
protect remove Remove a protection rule
upload file Upload a file to the Blossom store
pack validate Validate a persona pack (local, no relay)
inspect Inspect a persona pack (local, no relay)
mem ls List non-tombstoned memories
get Print memory value to stdout
hash Print SHA-256 hex of memory value
set Write a memory value (use - for stdin)
patch Apply unified diff to memory value
rm Publish a tombstone to delete memory

Huddles

huddles list and huddles participants rebuild huddle state from the relay-signed lifecycle events (kinds 48100–48103) with the same rules as the desktop app. They never join, start, or end a huddle. Each scans at most 5000 newest events of the channel. If older events may be missing, complete is false and truncated is true. A huddle with no end event is active, then stale once its start is over an hour old; desktop shows stale as ended. The relay's liveness snapshots are not served over HTTP, so liveness_checked is always false. Rosters come from the relay's join and leave events only. Desktop's roster view also lists the creator from the start event; the CLI lists the creator once the relay records their join.

Architecture

buzz <group> <subcommand> [flags]
    │
    ├─ main.rs ──▶ commands/*.rs ──▶ client.rs ──▶ Buzz Relay REST API
    │  (clap)       (handlers)       (reqwest)
    │
    ├─ credentials.rs        (identity, signer, NIP-FI evidence; every request
    │                         is authorized through client.rs `authorize`)
    ├─ federated_identity.rs (NIP-FA adapter session → NIP-FI assertion)
    ├─ validate.rs   (UUID, hex, content size, percent-encode)
    └─ error.rs      (CliError → JSON stderr + exit code)

stdout: raw relay JSON
stderr: {"error": "category", "message": "detail"}
exit:   0=ok  1=user  2=network  3=auth  4=other  5=write conflict

Default branch

After deploying relay support, select an existing published branch without renaming or deleting any branch:

buzz repos default-branch get --owner <owner-hex> --id my-repo
buzz repos default-branch set --owner <owner-hex> --id my-repo --branch main
# For an explicitly reviewed version, use the manifest digest returned by get:
buzz repos default-branch set --owner <owner-hex> --id my-repo --branch main \
  --expected-manifest <manifest-digest>

--owner defaults to the signing identity, not an agent's attested human owner. set without --expected-manifest reads the current version first. Success returns branch, head, manifest and changed; get omits changed. A stale version returns conflict (exit 5). Ambiguous write failures return delivery_unknown with retryable:false and the original digest: read before retrying, and do not blindly re-run against a newly fetched version.

The signer must be a current channel member and a repository manager, directly or through an unrestricted, valid NIP-OA owner attestation; permission to push is not permission to change the default. See the protocol and authorization contract.