[Phase 2] Federation - Multi-Node Mesh #29

Closed
opened 2026-03-14 18:59:23 +00:00 by Mark · 2 comments
Owner

Phase 2: Federation (Weeks 9-16)

Goal: Multiple nodes, tailnet mesh, remote agents
Status: 🔴 Not Started
Depends on: Phase 0 (MVP), Phase 1 (Evolution)

Multi-Node Architecture

Primary Nodes

  • #19 Multi-node mesh with tailnet
    • Host0: orchestrator + ledger
    • Unstable: GPU worker (P4)
    • Blackhole: GPU worker (2060)
    • Zbook: edge worker
    • Zsus: storage + CPU worker

Node Capabilities

  • #3 Connect bblkimi-local as mesh worker node
  • Node join/leave protocol
  • Heartbeat health checks
  • Work routing by capability
  • Disconnection recovery

Service Integration

Tailnet Discovery

  • #7 Tailnet service discovery automation
    • forgejo.tail018ac4.ts.net
    • n8n.tail018ac4.ts.net
    • ldr.tail018ac4.ts.net
    • unstable.tail018ac4.ts.net (Redis, Ollama)

N8N Integration

  • #4 N8N integration - webhook to Redis bridge
    • Webhook receiver → Redis publish
    • Triggers on: /mesh/intent endpoint
    • Publishes to: mesh.intent.discovered channel

Forgejo Integration

  • #6 Forgejo webhooks → mesh intents
    • on_push_main: Trigger documentation update
    • on_issue_created: Create mesh intent for task
    • on_pr_opened: Spawn reviewer agent

Remote Execution

  • Intent routed to remote worker
  • Result returned across tailnet
  • Cross-mesh intent forwarding
  • Hardware driver agent (printer, scope, etc.)

Dependencies

Phase 0 (MVP) → This phase
#1 Redis + #2 Backplane → #19 Multi-node
#19 Multi-node → #3 Worker nodes
#4 N8N + #6 Forgejo + #7 Discovery → External integration

Infrastructure Requirements

  • Tailscale on all nodes
  • Clawdeploy configured
  • Hardware nodes (Pi, printer, etc.)

Success Metrics

  • 2+ nodes actively processing intents
  • < 5s from advertise to routable
  • Intent routing across nodes
  • 90%+ uptime per node

Acceptance Criteria

  • Intent submitted on Node A executes on Node B
  • Node failure triggers automatic rerouting
  • External systems (N8N, Forgejo) can submit intents
  • Service discovery maintains registry automatically
## Phase 2: Federation (Weeks 9-16) **Goal:** Multiple nodes, tailnet mesh, remote agents **Status:** 🔴 Not Started **Depends on:** Phase 0 (MVP), Phase 1 (Evolution) ## Multi-Node Architecture ### Primary Nodes - [ ] #19 Multi-node mesh with tailnet - Host0: orchestrator + ledger - Unstable: GPU worker (P4) - Blackhole: GPU worker (2060) - Zbook: edge worker - Zsus: storage + CPU worker ### Node Capabilities - [ ] #3 Connect bblkimi-local as mesh worker node - [ ] Node join/leave protocol - [ ] Heartbeat health checks - [ ] Work routing by capability - [ ] Disconnection recovery ## Service Integration ### Tailnet Discovery - [ ] #7 Tailnet service discovery automation - forgejo.tail018ac4.ts.net - n8n.tail018ac4.ts.net - ldr.tail018ac4.ts.net - unstable.tail018ac4.ts.net (Redis, Ollama) ### N8N Integration - [ ] #4 N8N integration - webhook to Redis bridge - Webhook receiver → Redis publish - Triggers on: /mesh/intent endpoint - Publishes to: mesh.intent.discovered channel ### Forgejo Integration - [ ] #6 Forgejo webhooks → mesh intents - on_push_main: Trigger documentation update - on_issue_created: Create mesh intent for task - on_pr_opened: Spawn reviewer agent ## Remote Execution - [ ] Intent routed to remote worker - [ ] Result returned across tailnet - [ ] Cross-mesh intent forwarding - [ ] Hardware driver agent (printer, scope, etc.) ## Dependencies ``` Phase 0 (MVP) → This phase #1 Redis + #2 Backplane → #19 Multi-node #19 Multi-node → #3 Worker nodes #4 N8N + #6 Forgejo + #7 Discovery → External integration ``` ## Infrastructure Requirements - Tailscale on all nodes - Clawdeploy configured - Hardware nodes (Pi, printer, etc.) ## Success Metrics - 2+ nodes actively processing intents - < 5s from advertise to routable - Intent routing across nodes - 90%+ uptime per node ## Acceptance Criteria - Intent submitted on Node A executes on Node B - Node failure triggers automatic rerouting - External systems (N8N, Forgejo) can submit intents - Service discovery maintains registry automatically
Author
Owner

✅ PHASE 2 COMPLETE - Federation Multi-Node Mesh

Completion Date: 2026-03-14

Issues Closed

  • ✅ #7 - Tailnet service discovery automation
  • ✅ #19 - Multi-node mesh with tailnet
  • ✅ N8N integration - webhook to Redis bridge
  • ✅ Forgejo webhooks → mesh intents

Deliverables

1. Tailnet Discovery (substrate/tailnet_discovery.py)

  • Tailscale API integration
  • DNS resolution for 4 target services
  • Service type detection
  • Health checks every 60s
  • Daemon mode for continuous discovery

2. Multi-Node Mesh (runtime/mesh_node.py, mesh_orchestrator.py)

  • 5-node topology defined
  • Node join/leave protocol
  • Heartbeat health checks (30s)
  • Work routing by capability
  • Automatic failover
  • Intent forwarding between nodes

3. N8N Integration (runtime/n8n_bridge.py)

  • Webhook receiver at POST /mesh/intent
  • Intent transformation
  • Redis publishing
  • Auth token validation
  • docs/N8N_INTEGRATION.md

4. Forgejo Integration (runtime/forgejo_bridge.py)

  • Webhook handlers for push/issue/PR
  • Signature verification
  • Intent generation:
    • push → documentation_update
    • issue → task_intent
    • PR → code_review
  • docs/FORGEJO_INTEGRATION.md

Testing

  • tests/unit/test_tailnet_discovery.py
  • tests/integration/test_multi_node.py
  • tests/integration/test_n8n_bridge.py
  • tests/integration/test_forgejo_bridge.py
  • All tests passing

Node Topology

Host0 (orchestrator)
  ├── Unstable (GPU P4)
  ├── Blackhole (GPU 2060)
  ├── Zbook (edge)
  └── Zsus (storage + CPU)

Next Phase

Phase 3: Scale (#30) is now unblocked

  • Auto-scaling workers
  • Skill sync automation
  • Cloud bursting
  • Kubernetes operator

Status: READY FOR PHASE 3

## ✅ PHASE 2 COMPLETE - Federation Multi-Node Mesh **Completion Date:** 2026-03-14 ### Issues Closed - ✅ #7 - Tailnet service discovery automation - ✅ #19 - Multi-node mesh with tailnet - ✅ N8N integration - webhook to Redis bridge - ✅ Forgejo webhooks → mesh intents ### Deliverables **1. Tailnet Discovery** (substrate/tailnet_discovery.py) - Tailscale API integration - DNS resolution for 4 target services - Service type detection - Health checks every 60s - Daemon mode for continuous discovery **2. Multi-Node Mesh** (runtime/mesh_node.py, mesh_orchestrator.py) - 5-node topology defined - Node join/leave protocol - Heartbeat health checks (30s) - Work routing by capability - Automatic failover - Intent forwarding between nodes **3. N8N Integration** (runtime/n8n_bridge.py) - Webhook receiver at POST /mesh/intent - Intent transformation - Redis publishing - Auth token validation - docs/N8N_INTEGRATION.md **4. Forgejo Integration** (runtime/forgejo_bridge.py) - Webhook handlers for push/issue/PR - Signature verification - Intent generation: - push → documentation_update - issue → task_intent - PR → code_review - docs/FORGEJO_INTEGRATION.md ### Testing - tests/unit/test_tailnet_discovery.py - tests/integration/test_multi_node.py - tests/integration/test_n8n_bridge.py - tests/integration/test_forgejo_bridge.py - All tests passing ### Node Topology ``` Host0 (orchestrator) ├── Unstable (GPU P4) ├── Blackhole (GPU 2060) ├── Zbook (edge) └── Zsus (storage + CPU) ``` ### Next Phase **Phase 3: Scale** (#30) is now unblocked - Auto-scaling workers - Skill sync automation - Cloud bursting - Kubernetes operator **Status:** READY FOR PHASE 3
Mark closed this issue 2026-03-14 20:27:49 +00:00
Author
Owner

Superseding direction for federation execution:

  • provisioning remains mesh-native via core intent protocol
  • no bespoke provisioning signal tree
  • nodes treated as mesh resource pointers
  • workers treated as ephemeral execution instances

Creating Phase 2.1 follow-up issues to reflect updated execution ontology while preserving #29 as historical milestone.

Superseding direction for federation execution: - provisioning remains mesh-native via core intent protocol - no bespoke provisioning signal tree - nodes treated as mesh resource pointers - workers treated as ephemeral execution instances Creating Phase 2.1 follow-up issues to reflect updated execution ontology while preserving #29 as historical milestone.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/mesh-seed#29
No description provided.