Completes the definition surface: `buzz teams create|list|get|delete`
writes kind:30176 over the personas from [3/4], from flags or a Desktop
`.team.json` export.
Membership resolution is the load-bearing part. A team event stores
persona d-tags, and Desktop publishes personas under their record id —
usually a UUID — while its team export names members only by display
name. Matching on the slugified name would therefore resolve nothing for
every Desktop-exported roster. `--persona` accepts a d-tag, a slugified
d-tag, or a unique display name, in that order; an ambiguous display name
is an error rather than a guess, and a member with no published persona
is refused rather than published as a seat that silently stays empty.
A team id is used verbatim, never normalized. The relay enforces the slug
grammar on persona d-tags but only a length bound on team ids, and
Desktop writes raw UUIDs and ids like `builtin-team:welcome` —
normalizing would address a different coordinate than the one Desktop
published, making its teams unreachable. Since kind:30176 has no envelope
validator on the relay, the CLI is the only guard against a blank or
oversized id.
`instructions` and `persona_ids` are always published. On the wire an
absent field means "publisher predates always-publish, membership
unknown, preserve local" — distinct from an explicit empty. A new client
must never claim the former, or a write meant to clear a roster reads as
"leave it alone" and one meant to leave it alone wipes it.
The e2e suite gains the relay rule the delete path depends on: a
tombstone older than its target head is accepted, deletes nothing, and
still reports OK.
Signed-off-by: Max Lampert <maxwell@squareup.com>
Personas could only be created by clicking through Buzz Desktop, so
nothing scriptable could stand up an agent roster — including the agents
themselves. `buzz personas create|list|get|delete` writes the same
kind:30175 coordinates Desktop reads, from a flag set or straight from a
`.agent.json` export.
These are owner-authored events, so the signing key IS the owner: no
NIP-OA auth tag is involved, and running with a different key publishes
to a coordinate space the owner's Desktop never reads. Publishing a
definition does not start an agent; launching one mints key material and
stays a Desktop operation.
Two relay behaviors shape the implementation:
- A write must be stamped past the coordinate's current head. NIP-33
breaks a `created_at` tie by lowest event id, so a same-second rewrite
can otherwise lose to the event it was replacing.
- `soft_delete_by_coordinate` matches `created_at <= tombstone`, and its
result only feeds a debug log. A tombstone older than its target is
accepted, deletes nothing, and reports OK — so delete stamps from the
head it just read and then re-reads the coordinate to confirm. The
re-read only raises a conflict for a head strictly newer than the
tombstone, since a lagging replica can still return the deleted head.
`--from` refuses rather than repairs a snapshot that would publish a
persona Desktop can't mint from: `respondTo=allowlist` with no pubkeys,
an unknown `respondTo`, or definition text carrying invisible characters.
Avatars follow Desktop's reader rather than a CLI-only rule. `--avatar`
takes a local image and carries it inline as a data URL when it fits the
bounds Desktop renders — 8 KiB for SVG, 256 KiB for raster, both inside
the relay's 256 KiB content cap. Anything larger is downscaled to 512px
and re-encoded, then re-checked against the bound: flat art typically
lands back inside it and never reaches media storage at all, and only
what still doesn't fit is uploaded.
Re-encoding is also what makes that upload work. Media storage refuses
images carrying metadata — EXIF, colour profiles, comments — as an
identity channel, so a photo straight off a camera failed outright.
Decoding and re-encoding drops metadata by construction rather than by
stripping known chunks, so it cannot drift from the relay's allowlist the
way a structural stripper would. EXIF orientation is baked into the
pixels first, because dropping the tag without applying it publishes the
avatar sideways. GIF passes through untouched, since re-encoding would
flatten animation, and WebP re-encodes to PNG because `image`'s WebP
encoder is lossless-only and would inflate a lossy source.
`--from` carries a snapshot's inlined avatar through that same path, so a
Desktop export round-trips with its image. The upload runs after the
`--replace` conflict check: an upload that a rejected write would strand
leaves an orphan blob behind.
Signed-off-by: Max Lampert <maxwell@squareup.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>
