Files
gastown/docs/federation.md
Steve Yegge 020784a70d Update federation.md URI scheme to use hop:// (gt-6r18e.4)
- Changed gt:// to hop:// for HOP protocol URIs
- Added beads:// scheme for cross-repo references
- Documented local short forms (prefix routing)
- Updated implementation status

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-30 16:24:08 -08:00

4.2 KiB

Federation Architecture

Multi-workspace coordination for Gas Town and Beads

Overview

Federation enables multiple Gas Town instances to reference each other's work, coordinate across organizations, and track distributed projects.

Entity Model

Three Levels

Level 1: Entity    - Person or organization (flat namespace)
Level 2: Chain     - Workspace/town per entity
Level 3: Work Unit - Issues, tasks, molecules on chains

URI Scheme

Full work unit reference (HOP protocol):

hop://entity/chain/rig/issue-id
hop://steve@example.com/main-town/gastown/gt-xyz

Cross-repo reference (same platform):

beads://platform/org/repo/issue-id
beads://github/acme/backend/ac-123

Within a workspace, short forms are preferred:

gt-xyz           # Local (prefix routes via routes.jsonl)
gastown/gt-xyz   # Different rig, same chain
./gt-xyz         # Explicit current-rig ref

See ~/gt/docs/hop/GRAPH-ARCHITECTURE.md for full URI specification.

Relationship Types

Employment

Track which entities belong to organizations:

{
  "type": "employment",
  "entity": "alice@example.com",
  "organization": "acme.com"
}

Cross-Reference

Reference work in another workspace:

{
  "references": [
    {
      "type": "depends_on",
      "target": "hop://other-entity/chain/rig/issue-id"
    }
  ]
}

Delegation

Distribute work across workspaces:

{
  "type": "delegation",
  "parent": "hop://acme.com/projects/proj-123",
  "child": "hop://alice@example.com/town/gastown/gt-xyz",
  "terms": { "portion": "backend", "deadline": "2025-02-01" }
}

Agent Provenance

Every agent operation is attributed:

Git Commits

# Set per agent session
GIT_AUTHOR_NAME="gastown/crew/joe"
GIT_AUTHOR_EMAIL="steve@example.com"  # Workspace owner

Result: abc123 Fix bug (gastown/crew/joe <steve@example.com>)

Beads Operations

BD_ACTOR="gastown/crew/joe"  # Set in agent environment
bd create --title="Task"     # Actor auto-populated

Event Logging

All events include actor:

{
  "ts": "2025-01-15T10:30:00Z",
  "type": "sling",
  "actor": "gastown/crew/joe",
  "payload": { "bead": "gt-xyz", "target": "gastown/polecats/Toast" }
}

Discovery

Workspace Metadata

Each workspace has identity metadata:

// ~/gt/.town.json
{
  "owner": "steve@example.com",
  "name": "main-town",
  "public_name": "steve-gastown"
}

Remote Registration

gt remote add acme hop://acme.com/engineering
gt remote list

Cross-Workspace Queries

bd show hop://acme.com/eng/ac-123    # Fetch remote issue
bd list --remote=acme                # List remote issues

Aggregation

Query across relationships without hierarchy:

# All work by org members
bd list --org=acme.com

# All work on a project (including delegated)
bd list --project=proj-123 --include-delegated

# Agent's full history
bd audit --actor=gastown/crew/joe

Implementation Status

  • Agent identity in git commits
  • BD_ACTOR default in beads create
  • Workspace metadata file (.town.json)
  • Cross-workspace URI scheme (hop://, beads://, local forms)
  • Remote registration
  • Cross-workspace queries
  • Delegation primitives

Use Cases

Multi-Repo Projects

Track work spanning multiple repositories:

Project X
├── hop://team/frontend/fe-123
├── hop://team/backend/be-456
└── hop://team/infra/inf-789

Distributed Teams

Team members in different workspaces:

Alice's Town → works on → Project X
Bob's Town   → works on → Project X

Each maintains their own CV/audit trail.

Contractor Coordination

Prime contractor delegates to subcontractors:

Acme/Project
└── delegates to → Vendor/SubProject
                   └── delegates to → Contractor/Task

Completion cascades up. Attribution preserved.

Design Principles

  1. Flat namespace - Entities not nested, relationships connect them
  2. Relationships over hierarchy - Graph structure, not tree
  3. Git-native - Federation uses git mechanics (remotes, refs)
  4. Incremental - Works standalone, gains power with federation
  5. Privacy-preserving - Each entity controls their chain visibility