Collaboration: signed CML task lifecycle on Sprites/Waker remote agents

[mfethe1]

Collaboration proposal: CML task lifecycle + your Sprites/Waker substrate

Hi Junchao — I've been reviewing your Buzz fork work, especially buzz-backend-sprites, buzz-waker, read-only connection classes, and community-scoped agents. The quality is unusually high: explicit state machines, no destructive substrate operation in the interface, generation-scoped leases, live verification, and one-finding-per-fix review discipline.

We're building the task-level coordination layer that appears complementary to your substrate layer:

• Signed Nostr lifecycle over existing job kinds 43001..43006
• planner → worker → reviewer ↔ fixer (max 3) → merge → runtime proof
• Exclusive lease holder bound to the signed role
• Deterministic reducer independent of event ordering
• Sibling successors become conflicted, never last-writer-wins
• Canonical CML snapshot/export, while signed events remain authority
• HMAC-scoped pseudonymous host IDs; no raw host/path topology in task state

A nine-event lifecycle now passes against a real relay and reduces to shipped, including continuation after relay restart. The implementation branches are:

• https://github.com/mfethe1/buzz/tree/feat/buzz-system-architecture
• https://github.com/mfethe1/buzz/tree/feat/buzz-system-core
• https://github.com/mfethe1/buzz/tree/feat/buzz-system-events

The integration I think is worth testing:

1. Buzz CML worker.claim creates the durable work lease.
2. buzz-waker/Sprites converges the agent body and reports its generation.
3. The remote agent acknowledges by signing the claim itself — substrate success alone never implies task acceptance.
4. Waker restart/replay-floor preserves the event chain; the reducer proves no duplicate worker accepted the same predecessor.
5. Runtime proof records the exact generation/revision as evidence without exposing substrate secrets.

Are you planning to upstream the Sprites/Waker stack? And would you be interested in a cross-fork E2E where your remote-agent substrate executes one of our signed CML tasks? I can start with an adapter/threat-model PR against whichever branch you prefer, rather than asking you to absorb a large stack.

[yjc801]

Hi @mfethe1 ,

Thanks for the thoughtful proposal. I've read the spec, and I think the core design is right - signed events as the only authority, deterministic reduction, and forks surfacing as conflicted instead of last-writer-wins.

The idea resonates because currently I already run this state machine informally, i.e. agents coordinate as planner/worker/reviewer through channel messages and p-tag mentions, with the protocol living in their prompts. CML turns those social guarantees into mechanical ones, which is exactly what's needed for your case — agents that aren't mine participating in tasks. The layering is also the right contract: the substrate converges agent bodies, your ledger tracks what they commit to, and substrate success never implies task acceptance.

Happy to explore ways to collaborate. Sprites/Waker has no upstreaming timeline yet, but that shouldn't block anything — the adapter can target the fork. There are a few reducer gaps probably worth fixing first (unvalidated plan-root status, unenforced lease expiry, no timestamp monotonicity, and a duplicate-root griefing vector), plus one integration wrinkle around my wake gate (agent→agent wakes are blocked by design, so CML handoffs need a workflow-published mention to wake the next role). I'll follow up with the details and probe tests. With those addressed, your suggestion of starting with a small adapter/threat-model PR against the fork sounds like the right first step.