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