Buzz integration assessment for HALO

Status: lead assessment · 2026-08-29 Decision: integrate Buzz as an isolated collaboration sidecar, not by merging its source into Camron's Convex application. Boundary: research and architecture only. repo/ remains read-only; no Convex seed/reset/migrate mutation was run.

Executive verdict

Camron's choice of block/buzz ↗ is directionally strong. Buzz is unusually close to the desired “our own Discord for chatters, managers, creators, and agents”: humans and agents share rooms, agents have their own keys and audit trail, and channels, threads, DMs, canvases, media comments, search, workflows, and voice huddles sit on one signed event log.

Buzz should not become HALO's CRM or business database. It should run as a separate service and own communication history. HALO—or a deliberately selected CRM/back-office system beside it—must remain authoritative for creators/models, employees, access policy, contracts, credentials, Drive/content metadata, attribution, commissions, invoices, payouts, and compliance evidence.

That division turns Buzz into HALO's collaboration plane without creating two competing sources of financial or creator truth.

Verified repository evidence

GitHub metadata was freshly verified with gh api repos/block/buzz on 2026-08-29:

The upstream source was fetched read-only through the source-reference workflow and inspected at: /Users/shaansisodia/SISO_Workspace/SISO_Agent_Base/docs/reference/opensrc/block-buzz. The primary upstream evidence is the README ↗, ARCHITECTURE.md ↗, VISION.md ↗, docs/buzz-entity-links.md ↗, and the draft optional NIP-FI specification ↗.

Serena's native project tool was not exposed in this session, and the local Serena daemon returned ECONNREFUSED at 127.0.0.1:24225. After that transport failure, the code-level check was limited to direct reads of known source files; no broad grep-based code survey was substituted. Product claims below are therefore bounded to documented architecture and the exact implementation seams inspected.

What Buzz should own—and what it must not own

Persona and channel topology

Start with one HALO agency community, matching Buzz's current operational model. Do not create a community per creator until isolation, support and lifecycle costs are proven.

Use stable names and immutable external identifiers underneath friendly labels. A creator rename must not break the link between a HALO record and Buzz history.

Integration seam

1. Keep the deployments separate

Run Buzz as its own Rust/Axum relay with Postgres, Redis, and object storage, using its supported API/event surfaces. Do not transplant Buzz code into the React/Convex app or make Convex tables imitate its Nostr event log. Apache-2.0 permits reuse, but the runtime, storage model, key model, and release cadence make a source merge the riskier integration.

2. Put a server-side adapter between the systems

The adapter should be the only component allowed to map HALO identities and resource IDs to Buzz public keys, channels, and event coordinates. It should:

• provision or suspend Buzz membership after server-authorized HALO lifecycle events;
• create bounded rooms for creators, shifts, campaigns, incidents, and reviews;
• post signed notifications and deep links without copying sensitive fields;
• validate the community, actor, channel, event kind, resource ID, and replay window on

every inbound event;

• queue retries idempotently and expose reconciliation/failed-delivery state;
• revoke mappings and access during staff, creator, or agent offboarding.

This adapter cannot safely depend on the current client's browser/local-storage identity claims. Production integration begins only after HALO has trustworthy server-side identity and authorization.

3. Make synchronization narrow and one-way first

Buzz documents an event submission/query surface, secret-auth workflow hooks, and an outbound call_webhook action. Use those only for non-financial pilot events:

HALO creator/shift/campaign event
  -> integration outbox
  -> Buzz channel notification + HALO deep link

Buzz escalation or reviewed command
  -> validated inbound adapter event
  -> HALO inbox/task proposal
  -> human confirms any business write in HALO

Do not begin with bidirectional record sync. Store an integration mapping such as halo_user_id <-> buzz_pubkey, halo_resource_id <-> buzz_channel_id, and halo_activity_id <-> buzz_event_coordinate; do not mirror creator, money, or credential objects into Buzz.

4. Treat Buzz workflows as collaboration automation

Current workflow triggers cover posted messages, reactions, schedules, and webhooks; actions include messages, reactions, outbound webhooks, delays, and approval requests. That is useful for shift starts, manager escalation, content review reminders, owner briefings, and agent routing. It is not yet safe as the approval engine for contract, permission, or money changes.

5. Reuse the entity-link idea, not its current domain model

Buzz's entity-link work currently focuses on Buzz repositories/projects/pull requests/ issues and is only partially implemented. Adopt the pattern for HALO deep links—creator, shift, campaign, content item, invoice exception—after defining a versioned allowlisted link contract. Do not claim the existing code already understands HALO entities.

Known blockers and gaps

These are integration gates, not reasons to discard Buzz:

1. Redis-backed rate limiting is now implemented. A 2026-08-29 recheck of current

block/buzz main found RedisRateLimiter using an atomic Lua INCR plus conditional EXPIRE, including TTL repair. Treat it as fixed-window protection with a burst-boundary caveat; retain ingress controls and prove the configured production path under load.

1. Workflow approvals do not complete. Approval-gate infrastructure exists, but the

executor currently fails rather than persisting and resuming an approval run.

1. Two documented actions are stubbed. send_dm and set_channel_topic return a

not-implemented result in the inspected path.

1. Federated identity is not production-ready evidence. NIP-FI is documented as a

draft optional mechanism. It deliberately requires issuer assertion, fresh-key proof, binding state, and local policy; it is not a finished HALO SSO implementation.

1. Roles are channel-level and coarse. Owner/Admin/Member/Guest/Bot plus open/private

visibility cannot express HALO's creator-, record-, field-, finance-, or credential- level rules.

1. **Inbound workflow-hook authentication is a stored secret comparison, not an HMAC of

the request body.** Terminate TLS, rotate secrets, constrain the ingress path, add replay/idempotency controls in the adapter, and never expose privileged money actions.

1. Huddle recording and per-track publishing are not built. Live huddles can be a

pilot feature; recording cannot be sold as present.

1. The repository is very young. It was created in March 2026 and already has a large

star and issue count. Popularity does not replace a deployment, upgrade, backup, incident-response, and security exercise.

Positive evidence worth retaining: outbound webhook calls are documented with SSRF protection, redirects disabled, and a bounded response; search is tenant/channel-aware; and the communication audit log is hash-chained per community. Each still needs a live adversarial test before production reliance.

Safe rollout

1. Contain HALO identity and authorization first. Do not bridge Buzz to the current

browser-trusted identity or expose live credentials, Drive access, creator evidence, or money data.

1. Run an isolated Buzz community with synthetic data. Exercise install/upgrade,

backup/restore, key recovery, offboarding, search isolation, rate controls, media retention, webhook replay, and total sidecar outage.

1. Pilot staff/chatters only. Test shift handoffs, manager escalation, topic/channel

structure, search, and a read-only briefing agent. HALO remains usable when Buzz is down.

1. Add resource links and content review. Provision creator/campaign rooms from

server-side policy and exchange only opaque IDs, safe labels and non-financial events.

1. Add bounded human-approved commands. Buzz creates task/action proposals; HALO

validates authorization and requires confirmation before a business mutation.

1. Evaluate creator guest rooms and federated identity last. Require proven server

auth, NIP-FI implementation/conformance evidence, deletion/export and isolation first.

Composition decision

Buzz supersedes the generic recommendation to adopt Zulip, Mattermost, Rocket.Chat, or Discord as HALO's primary chatter workspace. Those products remain comparison evidence, not competing implementation plans.

The clean shortlist beside Buzz is:

• HALO + Buzz + ERPNext (bounded): strongest end-to-end composition when back-office

finance/HR is the next real bottleneck. ERPNext must begin read-only and earn authority through reconciliation.

• HALO + Buzz + Twenty patterns/pilot: strongest open Salesforce-like relationship

composition. Keep creator identity, contracts, credentials, content and money in HALO; test Twenty only if relationship operations need their own mature surface.

• HALO + Buzz + AFFiNE patterns/sidecar: strongest manager-memory composition for

meetings, SOPs, briefs and handoffs. Avoid copying private Buzz conversations or HALO business records into a third editable system.

• HALO + Buzz + Agentforce/Attio reference: strongest commercial AI-CRM comparison,

justified only for a narrow bought workflow with export, deletion, permission and cost gates.

The recommended first architecture is therefore HALO as domain and identity authority, Buzz as the collaboration/agent plane, and no third production system until one bounded back-office or relationship pilot proves it removes more operational work than it adds.