anthonyrawlins 78d34c19dd Implement BZZZ Phase 2A: Unified SLURP Architecture with Consensus Elections
🎯 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>
2025-08-08 15:44:10 +10:00

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 libp2p
  • discovery/ - mDNS peer discovery for local network
  • pubsub/ - Publish/subscribe messaging for coordination
  • github/ - GitHub API integration for task management
  • logging/ - Hypercore-based distributed logging
  • cmd/ - 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: always with 10-second delay
  • Security: NoNewPrivileges, PrivateTmp, ProtectSystem
  • Logging: Output to systemd journal with bzzz identifier
  • 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 messages
    • hmmm/meta-discussion/v1 - Collaborative reasoning
  • Security: Message signing and signature verification enabled
  • Hive - Multi-Agent Task Coordination System
  • HMMM - AI Collaborative Reasoning Protocol
Description
No description provided
Readme 276 MiB
Languages
Go 86.1%
TypeScript 6.9%
Shell 3.6%
HTML 1.7%
CSS 0.6%
Other 1.1%