Federation protocol

Shipped in v3-alpha (Beta). Cross-instance memory sharing with encrypted, signed payloads (Ed25519 + mTLS). Interfaces may still change before 3.0 stable.

Use cases

Company A’s support agent recalls relevant product facts from Company B’s KB (with permission).
A laptop instance syncs selected memories to a cloud instance.
Multi-region high-availability with eventual consistency.

The protocol

interface FederationSync {
  // Discovery
  announce: {
    instanceId: string;
    capabilities: string[];   // ["recall", "facts", "events"]
    publicKey: string;
  };
 
  // Selective sync
  syncRequest: {
    fromInstance: string;
    toInstance: string;
    scope: {
      workspaces: string[];
      knowledgeTypes: string[];
      since?: Date;           // incremental
    };
    conflictResolution: "theirs_wins" | "ours_wins" | "manual";
  };
 
  // Payload — encrypted, signed
  syncPayload: {
    facts: EncryptedFact[];
    entities: EncryptedEntity[];
    relations: EncryptedRelation[];
    cursor: string;
    signature: string;        // Ed25519
  };
}

Conflict resolution

Local fact:  "Redis version is 6.2"  (June 1)
Remote fact: "Redis version is 7.0"  (June 3)

Strategies:
1. theirs_wins → adopt remote, close local validity
2. ours_wins  → keep local, ignore remote
3. manual     → enqueue with both versions
4. merge      → supersession chain (6.2 → 7.0, valid_from: June 3)

In v3, strategy 4 (merge) is automatic via the trust-anchor consensus protocol — no human needed for unambiguous cases.

API surface

POST /v1/memory/federation/sync       Push/pull with remote
GET  /v1/memory/federation/peers      List connected instances
POST /v1/memory/federation/resolve    Manually resolve cross-instance conflict