Note: I'm not a developer — I'm reporting observations from using Buzz, so apologies in advance if the format or terminology is off.
What was done
Two Buzz agents — headless, holding a managed Nostr keypair, with no browser and no NIP-07 extension — used a third-party Nostr app, ₿AO (https://bao.network/), end-to-end from a shell. ₿AO is a Nostr-based platform with milestone-escrow crowdfunding, prediction markets, and encrypted invite-gated chat, on Bitcoin testnet4 / Liquid / Cashu-Lightning rails. The agents created and funded campaigns, used wallet APIs, took market actions, and posted in encrypted rooms. No browser was opened.
How authentication worked
₿AO's HTTP APIs accept NIP-98: Authorization: Nostr , with u (URL), method, and payload (sha256 of the exact request body). The agents signed that header locally with their existing Buzz key (BUZZ_PRIVATE_KEY), which authenticated every write. ₿AO's own web UI sign-in expects a NIP-07 extension or a seed/remote signer. (Buzz's REST endpoints also use NIP-98, per the repo's SECURITY.md.)
Identity
The Buzz key was the durable identity on ₿AO. ₿AO's official chat client mints its own Nostr identity on first run unless its identity.json is pre-seeded with an existing key; pre-seeded with the Buzz key, it logs IDENTITY durable … (reused) and posts as that npub. Throwaway NIP-19 identities were also created for testing.
Operational details observed
NIP-98 requires hashing the exact request body bytes: compact JSON, no trailing newline, exact content-type.
Some endpoints challenged default programmatic User-Agents; a browser User-Agent header was accepted.
Relays were kind-allowlisted; ₿AO used two relays carrying different event protocols (encrypted chat on one, the HTTP API on the other).
Admission to ₿AO's encrypted rooms required a human host to be online.
Note: I'm not a developer — I'm reporting observations from using Buzz, so apologies in advance if the format or terminology is off.
What was done
Two Buzz agents — headless, holding a managed Nostr keypair, with no browser and no NIP-07 extension — used a third-party Nostr app, ₿AO (https://bao.network/), end-to-end from a shell. ₿AO is a Nostr-based platform with milestone-escrow crowdfunding, prediction markets, and encrypted invite-gated chat, on Bitcoin testnet4 / Liquid / Cashu-Lightning rails. The agents created and funded campaigns, used wallet APIs, took market actions, and posted in encrypted rooms. No browser was opened.
How authentication worked
₿AO's HTTP APIs accept NIP-98: Authorization: Nostr , with u (URL), method, and payload (sha256 of the exact request body). The agents signed that header locally with their existing Buzz key (BUZZ_PRIVATE_KEY), which authenticated every write. ₿AO's own web UI sign-in expects a NIP-07 extension or a seed/remote signer. (Buzz's REST endpoints also use NIP-98, per the repo's SECURITY.md.)
Identity
The Buzz key was the durable identity on ₿AO. ₿AO's official chat client mints its own Nostr identity on first run unless its identity.json is pre-seeded with an existing key; pre-seeded with the Buzz key, it logs IDENTITY durable … (reused) and posts as that npub. Throwaway NIP-19 identities were also created for testing.
Operational details observed
NIP-98 requires hashing the exact request body bytes: compact JSON, no trailing newline, exact content-type.
Some endpoints challenged default programmatic User-Agents; a browser User-Agent header was accepted.
Relays were kind-allowlisted; ₿AO used two relays carrying different event protocols (encrypted chat on one, the HTTP API on the other).
Admission to ₿AO's encrypted rooms required a human host to be online.