78d34c19dd7f0eea6f81998f5eb530b20cfbad97
🎯 Major architectural achievement: SLURP is now a specialized BZZZ agent with admin role ## Core Implementation: ### 1. Unified Architecture - SLURP becomes admin-role BZZZ agent with master authority - Single P2P network for all coordination (no separate systems) - Distributed admin role with consensus-based failover ### 2. Role-Based Authority System (pkg/config/roles.go) - Authority levels: master/decision/coordination/suggestion/read_only - Admin role includes SLURP functionality (context curation, decision ingestion) - Flexible role definitions via .ucxl/roles.yaml configuration - Authority methods: CanDecryptRole(), CanMakeDecisions(), IsAdminRole() ### 3. Election System with Consensus (pkg/election/election.go) - Election triggers: heartbeat timeout, discovery failure, split brain, quorum loss - Leadership scoring: uptime, capabilities, resources, network quality - Raft-based consensus algorithm for distributed coordination - Split brain detection prevents multiple admin conflicts ### 4. Age Encryption Integration - Role-based Age keypairs for content encryption - Hierarchical access: admin can decrypt all roles, others limited by authority - Shamir secret sharing foundation for admin key distribution (3/5 threshold) - UCXL content encrypted by creator's role level ### 5. Security & Configuration - Cluster security config with election timeouts and quorum requirements - Audit logging for security events and key reconstruction - Project-specific role definitions in .ucxl/roles.yaml - Role-specific prompt templates in .ucxl/templates/ ### 6. Main Application Integration (main.go) - Election manager integrated into BZZZ startup process - Admin callbacks for automatic SLURP enablement - Heartbeat system for admin leadership maintenance - Authority level display in startup information ## Benefits: ✅ High Availability: Any node can become admin via consensus ✅ Security: Age encryption + Shamir prevents single points of failure ✅ Flexibility: User-definable roles with granular authority ✅ Unified Architecture: Single P2P network for all coordination ✅ Automatic Failover: Elections triggered by multiple conditions ## Next Steps (Phase 2B): - Age encryption implementation for UCXL content - Shamir secret sharing key reconstruction algorithm - DHT integration for distributed encrypted storage - Decision publishing pipeline integration 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Bzzz + HMMM: Distributed P2P Task Coordination
Bzzz is a P2P task coordination system with the HMMM meta-discussion layer for collaborative AI reasoning. The system enables distributed AI agents to automatically discover each other, coordinate task execution, and engage in structured meta-discussions for improved collaboration.
Architecture
- P2P Networking: libp2p-based mesh networking with mDNS discovery
- Task Coordination: GitHub Issues as atomic task units
- Meta-Discussion: HMMM layer for collaborative reasoning between agents
- Distributed Logging: Hypercore-based tamper-proof audit trails
- Service Deployment: SystemD service for production deployment
Components
p2p/- Core P2P networking using libp2pdiscovery/- mDNS peer discovery for local networkpubsub/- Publish/subscribe messaging for coordinationgithub/- GitHub API integration for task managementlogging/- Hypercore-based distributed loggingcmd/- Command-line interfaces
Quick Start
Building from Source
go build -o bzzz
Running as Service
Install Bzzz as a systemd service for production deployment:
# Install service (requires sudo)
sudo ./install-service.sh
# Check service status
sudo systemctl status bzzz
# View live logs
sudo journalctl -u bzzz -f
# Stop service
sudo systemctl stop bzzz
# Uninstall service
sudo ./uninstall-service.sh
Running Manually
./bzzz
Production Deployment
Service Management
Bzzz is deployed as a systemd service across the cluster:
- Auto-start: Service starts automatically on boot
- Auto-restart: Service restarts on failure with 10-second delay
- Logging: All output captured in systemd journal
- Security: Runs with limited privileges and filesystem access
- Resource Limits: Configured file descriptor and process limits
Cluster Status
Currently deployed on:
| Node | Service Status | Node ID | Connected Peers |
|---|---|---|---|
| WALNUT | ✅ Active | 12D3Koo...aXHoUh |
3 peers |
| IRONWOOD | ✅ Active | 12D3Koo...8QbiTa |
3 peers |
| ACACIA | ✅ Active | 12D3Koo...Q9YSYt |
3 peers |
Network Topology
Full mesh P2P network established:
- Automatic peer discovery via mDNS on
192.168.1.0/24 - All nodes connected to all other nodes
- Capability broadcasts exchanged every 30 seconds
- Ready for distributed task coordination
Service Configuration
The systemd service (bzzz.service) includes:
- Working Directory:
/home/tony/chorus/project-queues/active/BZZZ - User/Group:
tony:tony - Restart Policy:
alwayswith 10-second delay - Security: NoNewPrivileges, PrivateTmp, ProtectSystem
- Logging: Output to systemd journal with
bzzzidentifier - Resource Limits: 65536 file descriptors, 4096 processes
Development Status
This project is being developed collaboratively across the deepblackcloud cluster:
- WALNUT: P2P Networking Foundation (starcoder2:15b)
- IRONWOOD: Distributed Logging System (phi4:14b)
- ACACIA: GitHub Integration Module (codellama)
Network Configuration
- Local Network: 192.168.1.0/24
- mDNS Discovery: Automatic peer discovery with service tag
bzzz-peer-discovery - PubSub Topics:
bzzz/coordination/v1- Task coordination messageshmmm/meta-discussion/v1- Collaborative reasoning
- Security: Message signing and signature verification enabled
Related Projects
Description
Languages
Go
86.1%
TypeScript
6.9%
Shell
3.6%
HTML
1.7%
CSS
0.6%
Other
1.1%