Skip to content

docs(deploy): self-host backend framework (always-on agents, any client) - #3551

Open
PabloTheThinker wants to merge 3 commits into
block:mainfrom
PabloTheThinker:docs/self-host-always-on-agents
Open

docs(deploy): self-host backend framework (always-on agents, any client)#3551
PabloTheThinker wants to merge 3 commits into
block:mainfrom
PabloTheThinker:docs/self-host-always-on-agents

Conversation

@PabloTheThinker

@PabloTheThinker PabloTheThinker commented Jul 29, 2026

Copy link
Copy Markdown

Summary

Full self-host backend framework for Buzz operators — not laptop-only, not a competing relay.

Primary doc

docs/self-host-backend-framework.md

Covers:

  1. Goals (any client, always-on agents, one host string, safer defaults)
  2. Layered architecture (clients → relay → buzz-acp → ACP agents)
  3. Community binding (Host header)
  4. Security: Nostr membership + invites + optional operator dual-lock (shared unlock + identity)
  5. Always-on agents + systemd units
  6. Desktop / web / mobile / CLI onboarding + join kit checklist
  7. Health / probe / readiness
  8. Optional multi-channel work layout
  9. Topologies (VPS, split, tailnet, TLS edge)
  10. Operator runbook + troubleshooting matrix

Also in this PR

  • docs/self-host-always-on-agents.md — quick start (linked to framework)
  • deploy/systemd/buzz-acp@.service + env example + README
  • Cross-links: crates/buzz-acp/README.md, deploy/compose/README.md, ARCHITECTURE.md

Design notes

  • Does not replace buzz-relay
  • Execution boundary = host running buzz-acp (tools/files there)
  • Dual-lock is operator onboarding guidance (Hermes-like session token idea); protocol auth remains Nostr
  • For everyone: phones, desktops, CI, homelab — not a single laptop

Test plan

  • Dogfooded always-on multi-agent fleet + mention smoke on self-hosted relay
  • Docs cross-links resolve in tree
  • Maintainer read-through of framework + systemd paths
  • Optional: enable buzz-acp@ from template on a test host

DCO signed on all commits.

Document the production layout where Buzz Desktop runs on a laptop and
buzz-acp agents stay on a server (same idea as a remote Hermes backend).

Add systemd template units under deploy/systemd and cross-link from
buzz-acp README. Emphasize host-string community selection so self-hosters
do not join an empty workspace via localhost vs public hostname mismatch.

Signed-off-by: Pablo Navarro <thethinker.pablo@protonmail.com>
@PabloTheThinker
PabloTheThinker requested a review from a team as a code owner July 29, 2026 14:40
Clarify that Desktop/web/mobile/CLI are interchangeable thin clients and
that the backend (relay + buzz-acp) is for every operator/team, not a
laptop-specific setup.

Signed-off-by: Pablo Navarro <thethinker.pablo@protonmail.com>
@PabloTheThinker PabloTheThinker changed the title docs(deploy): always-on agents with Desktop as thin client docs(deploy): always-on agents for any client (thin UI + server backend) Jul 29, 2026
Document the complete operator framework for always-on agents and any
client: layered architecture, host=community binding, Nostr + optional
operator unlock dual-lock, systemd deploy, join kit, probes, topologies,
runbook, and troubleshooting. Cross-link from always-on guide, buzz-acp,
compose, ARCHITECTURE, and deploy/systemd README.

Signed-off-by: Pablo Navarro <thethinker.pablo@protonmail.com>
@PabloTheThinker PabloTheThinker changed the title docs(deploy): always-on agents for any client (thin UI + server backend) docs(deploy): self-host backend framework (always-on agents, any client) Jul 29, 2026
@PabloTheThinker

Copy link
Copy Markdown
Author

Operator note (dogfood)

This PR remains the contribution we want merged: docs + systemd only, no protocol fork.

Production dogfood on a self-hosted relay confirmed:

  • Community binding by host string is the critical operator footgun (documented in the framework)
  • Always-on buzz-acp + thin Desktop/web/CLI clients matches ARCHITECTURE.md (WS live path + HTTP/NIP-98 for CLI)
  • CI already green here (DCO / Semgrep / zizmor)

Happy to trim wording if maintainers want a shorter first merge (framework doc vs quick-start split is intentional).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant