# AIMEAT Protocol Specification v1.6

## AI Memory Exchange and Action Transfer

**Status:** v1.6 (Federation Sync & Adaptive Network Operations)  
**Date:** 2026-03-07  
**Author:** Jouni Miikki (Overscale Solutions Oy)  
**License:** MIT  
**Previous:** v1.5 (Full Implementation Reflection, 2026-03-03)

---

## Summary of Changes

RFC v1.6 is a **targeted addendum** to v1.5. It does not change existing architecture or section numbering. It adds four new sections that specify the operational details required for production-grade federation:

| New Section | Title | Addresses |
|-------------|-------|-----------|
| §13.11 | Sync Protocol Specification | Outbound sync triggering, delta-based catalogue sync, event queues, sync modes |
| §13.12 | Route Manifest & Relay Fee Settlement | Multi-hop relay proof-of-forwarding, fee claiming, audit trail |
| §13.13 | Cross-Genesis Memory Routing | Routed memory access across genesis boundaries, prefix subscriptions |
| §32.6 | Adaptive Network Operations | Self-balancing sync scheduling, backpressure, peer priority, thundering herd prevention |

**Motivation:** v1.5 defines the federation data structures, endpoints, and peering lifecycle comprehensively. However, it leaves the **operational layer** underspecified: who calls whom, when, how often, what happens under load, and how relay nodes get paid. These gaps prevent interoperable implementations and make production deployment impractical for networks with more than a handful of peers.

---

## Table of Contents

**Federation Extensions** (§13.11–§13.13)

- [13.11 Sync Protocol Specification](#1311-sync-protocol-specification)
- [13.12 Route Manifest & Relay Fee Settlement](#1312-route-manifest--relay-fee-settlement)
- [13.13 Cross-Genesis Memory Routing](#1313-cross-genesis-memory-routing)

**Economics Extension** (§32.6)

- [32.6 Adaptive Network Operations](#326-adaptive-network-operations)

**Appendix**

- [Appendix D: New Configuration Variables](#appendix-d-new-configuration-variables)
- [Appendix E: Sync Protocol Sequence Diagrams](#appendix-e-sync-protocol-sequence-diagrams)

---

## 13.11 Sync Protocol Specification

### 13.11.1 Overview

Sections 13.1–13.10 (v1.5) define the federation peering lifecycle, heartbeat protocol, and receive-side endpoints for data exchange. This section specifies the **outbound sync protocol** — the rules governing when and how a node pushes data to its peers.

Three concerns are addressed:

1. **Catalogue synchronization** — how catalogue entries and CSM records flow between peers
2. **Memory replication** — how consent-eligible memory entries are pushed to peers
3. **Delivery guarantees** — how the replication queue ensures data survives restarts and network partitions

### 13.11.2 Sync Modes

Nodes MUST support three sync modes, selectable per node via `AIMEAT_SYNC_MODE`:

| Mode | Behavior | Recommended For |
|------|----------|-----------------|
| `bulk` | Scheduled sync only, at fixed intervals | Unreliable connections, low-bandwidth nodes, cost-sensitive deployments |
| `instant` | Event-driven sync on every data change, batched within a configurable window | Low-latency networks, real-time collaboration |
| `hybrid` | Event-driven with scheduled fallback — changes pushed immediately when reachable; scheduled bulk sync catches missed updates | General-purpose (DEFAULT) |

**Configuration:**

```ini
AIMEAT_SYNC_MODE=hybrid                # bulk | instant | hybrid
AIMEAT_SYNC_INTERVAL_HOURS=6           # Scheduled sync interval (bulk and hybrid fallback)
AIMEAT_SYNC_BATCH_DELAY_MS=5000        # Event batching window (instant and hybrid modes)
```

In `hybrid` mode, data changes are accumulated for `AIMEAT_SYNC_BATCH_DELAY_MS` milliseconds, then pushed as a single batch. If push fails, the entries remain in the replication queue and are retried at the next scheduled interval.

### 13.11.3 Delta-Based Catalogue Sync Protocol

Catalogue synchronization MUST use delta-based (incremental) exchange to minimize bandwidth.

**Request format** (`POST /v1/federation/catalogue-sync`):

```json
{
  "source_node": "aimeat-finland-001-genesis",
  "since": "2026-03-07T10:00:00Z",
  "entries": [
    {
      "id": "action-photography-001",
      "type": "action",
      "operation": "upsert",
      "data": { ... },
      "updatedAt": "2026-03-07T14:30:00Z"
    },
    {
      "id": "csm-hobbies-002",
      "type": "csm",
      "operation": "delete",
      "deletedAt": "2026-03-07T12:00:00Z"
    }
  ],
  "catalogue_hash": "sha256:abc123def456...",
  "timestamp": "2026-03-07T14:35:00Z",
  "signature": "Ed25519_sig(...)"
}
```

**Fields:**

| Field | Required | Description |
|-------|----------|-------------|
| `source_node` | Yes | Sending node's ID |
| `since` | No | ISO-8601 timestamp. If present, `entries` contains only items changed after this time. If omitted, `entries` is a full catalogue exchange. |
| `entries` | Yes | Array of catalogue entries with `operation: "upsert" | "delete"` |
| `catalogue_hash` | Yes | SHA-256 hash of the sender's complete catalogue (for verification) |
| `timestamp` | Yes | Current time on sender |
| `signature` | Yes | Ed25519 signature of the JSON payload (excluding the `signature` field itself) |

**Protocol rules:**

1. **First sync** (peering activation, Phase 5 per §13.3): `since` is omitted. Both peers exchange their complete filtered catalogues.
2. **Subsequent syncs:** `since` = the `timestamp` from the last successful sync response.
3. **Hash verification:** After applying the delta, the receiver computes its own catalogue hash (local entries + all `federated:*` entries from this specific peer). If it does not match `catalogue_hash`, the receiver MUST request a full sync by responding with `"resync_required": true`.
4. **Delete propagation:** Deleted entries MUST be included in deltas (with `operation: "delete"`) for 72 hours after deletion, then excluded.
5. **Filtering:** Only entries matching the bilateral peering config (§13.3 Phase 5) are included. Senders MUST apply `share_agents`, `share_actions`, `share_catalogue`, and `share_board_posts` filters.

**Response format:**

```json
{
  "ok": true,
  "data": {
    "accepted": 42,
    "rejected": 0,
    "resync_required": false,
    "peer_catalogue_hash": "sha256:789xyz...",
    "synced_at": "2026-03-07T14:35:01Z"
  }
}
```

**Catalogue hash computation:**

The hash MUST be computed as:

```
SHA-256( sort( entries.map(e => e.id + ':' + e.updatedAt) ).join('\n') )
```

Where `entries` includes only entries eligible for the specific peer (after applying the peering config filter and `federate: true` CSM flag). This ensures both sides compute the same hash for the same data set.

### 13.11.4 Memory Replication Protocol

Memory replication uses a **push-primary, pull-recovery** model.

**Push (primary):** Origin node POSTs eligible memories to peer's `POST /v1/federation/replicate` on change events. Eligibility rules from §13.6 apply: `visibility: 'public'` AND consent scope includes `federation`.

**Pull (recovery):** When a peer transitions from `unreachable` to `active` (§13.5), it MAY request missed updates:

```
GET /v1/federation/replicate?since=2026-03-07T00:00:00Z&source_node=aimeat-finland-001
```

The origin responds with all eligible memory entries changed since the given timestamp.

**Replication request format:**

```json
{
  "source_node": "aimeat-finland-001-genesis",
  "entries": [
    {
      "key": "profile:hobbies:photography",
      "value": { ... },
      "owner_gaii": "agent#owner@aimeat-finland-001",
      "visibility": "public",
      "updatedAt": "2026-03-07T14:30:00Z",
      "consent_ref": "consent-abc123"
    }
  ],
  "timestamp": "2026-03-07T14:35:00Z",
  "signature": "Ed25519_sig(...)"
}
```

Each entry MUST include `consent_ref` — the ID of the consent record authorizing federation-scope sharing. The receiving node SHOULD verify that the consent is still active before storing. If consent has been revoked, the entry MUST be rejected and any previously stored replica purged.

### 13.11.5 Replication Queue

Nodes MUST maintain a persistent replication queue to ensure delivery across restarts and network partitions.

**Requirements:**

| Property | Requirement |
|----------|-------------|
| Persistence | Queue MUST survive node restarts |
| Maximum size | Configurable via `AIMEAT_REPLICATION_QUEUE_MAX` (default: 10,000 entries) |
| Maximum age | Entries older than `AIMEAT_REPLICATION_QUEUE_TTL_HOURS` (default: 72 hours) are discarded |
| Processing order | FIFO (first in, first out) |
| Batch drain | Up to 100 entries per peer per processing cycle |
| Overflow behavior | When queue is full, oldest entries are dropped with a warning-level log |
| Checkpoint | Queue tracks per-peer processing position for resumption after restart |

**Queue entry format:**

```json
{
  "id": "queue-entry-uuid",
  "type": "catalogue_sync" | "memory_replicate",
  "target_peers": ["peer-id-1", "peer-id-2"],
  "payload": { ... },
  "created_at": "2026-03-07T14:30:00Z",
  "attempts": 0,
  "last_attempt_at": null,
  "status": "pending" | "sent" | "failed"
}
```

**Retry behavior:**
- Failed entries are retried at the next sync cycle
- After 5 consecutive failures for the same entry + peer combination, the entry is marked `failed` and logged
- Failed entries DO count toward the queue size limit

### 13.11.6 Sync Triggering Rules

The following events MUST trigger a sync operation:

| Event | Sync Type | Target | Immediate or Queued |
|-------|-----------|--------|---------------------|
| Peering activation (Phase 5) | Full catalogue sync + key exchange | New peer | Immediate |
| Heartbeat hash mismatch | Delta catalogue sync | Stale peer | Queued |
| Peer recovery (unreachable → active) | Full catalogue sync + key exchange | Recovered peer | Immediate |
| CSM created/updated with `federate: true` | Delta catalogue sync | All active peers | Queued (batch window) |
| Memory created/updated with federation consent | Memory replication | Eligible peers | Queued (batch window) |
| Scheduled interval reached | Full catalogue sync | All active peers | Immediate (staggered) |

In `bulk` mode, only "Peering activation", "Peer recovery", and "Scheduled interval" triggers are active. In `instant` mode, all triggers are active. In `hybrid` mode, all triggers are active but queued items also have the scheduled interval as a fallback.

---

## 13.12 Route Manifest & Relay Fee Settlement

### 13.12.1 Problem Statement

When a work request or routed message traverses multiple hops (Node A → Node B → Node C), relay nodes expend computational resources, bandwidth, and liquidity. Per §32.3, relay nodes are entitled to 20% of the network fee. However, v1.5 does not specify how relay nodes **prove** they forwarded a request or **claim** their share.

### 13.12.2 Route Manifest

Every cross-node request that may traverse relay nodes MUST carry a `route_manifest` field. The manifest is an ordered array of signed hop entries, each appended by the node that processed that hop.

**Data structure:**

```json
{
  "route_manifest": {
    "origin": "aimeat-finland-001",
    "hops": [
      {
        "node_id": "aimeat-germany-002",
        "received_at": "2026-03-07T14:30:00.123Z",
        "forwarded_to": "aimeat-japan-003",
        "signature": "Ed25519_sig(node_id + received_at + forwarded_to + origin_signature)"
      },
      {
        "node_id": "aimeat-japan-003",
        "received_at": "2026-03-07T14:30:00.456Z",
        "forwarded_to": null,
        "signature": "Ed25519_sig(node_id + received_at + forwarded_to + prev_hop_signature)"
      }
    ]
  }
}
```

**Signature chaining:**

Each hop's signature is computed over the concatenation of:

```
sign( node_id + '|' + received_at + '|' + (forwarded_to || 'TERMINAL') + '|' + previous_signature )
```

Where `previous_signature` is:
- For the first relay hop: the **origin node's request signature**
- For subsequent hops: the **previous hop's signature**

This creates a verifiable chain of custody that cannot be forged, reordered, or truncated.

### 13.12.3 Relay Processing Rules

When a node receives a cross-node request with routing:

1. **Validate** the incoming request signature (origin or previous hop)
2. **Deduct** 1 morsel relay fee from the request escrow (per §32.2)
3. **Append** a new `RouteHop` entry with its own signature
4. **Forward** the request to the next hop (or process locally if this is the destination)

If the escrow is insufficient for the relay fee, the relay MUST reject the request with `402 PAYMENT_REQUIRED` and error code `INSUFFICIENT_RELAY_ESCROW`.

### 13.12.4 Settlement with Route Manifest

When cross-node work is settled (via `POST /v1/federation/settle`), the settlement request MUST include the `route_manifest` from the original work request.

**Settlement verification:**

1. The settling node (origin) verifies the **entire signature chain** starting from its own request signature
2. Each hop's public key is looked up from the cached peer key store (§13.3 Phase 5)
3. If any signature is invalid, the settlement is rejected with `INVALID_ROUTE_MANIFEST`
4. The chain MUST be contiguous — no gaps between `forwarded_to` of hop N and `node_id` of hop N+1

**Fee distribution after verification:**

```
Network fee (e.g., 10 morsels) distribution:

If relays present:
  ├── Provider node:   40% (4.0 morsels)
  ├── Requester node:  20% (2.0 morsels)
  ├── Relay node(s):   20% (2.0 morsels) — split evenly among all relay hops
  ├── Registry node:   20% (2.0 morsels)
  └── Burn:            Applied per §32.3 (taken from total before split)

If no relays (direct):
  ├── Provider node:   50% (5.0 morsels)
  ├── Requester node:  30% (3.0 morsels)
  ├── Registry node:   20% (2.0 morsels)
  └── Burn:            Applied per §32.3
```

### 13.12.5 Route Manifest Storage

Settled route manifests MUST be stored alongside the work record for audit purposes. Storage retention follows the node's data retention policy (minimum 90 days).

Operators can query relay earnings via:

```
GET /v1/admin/federation/relay-earnings?since=2026-03-01&until=2026-03-07
```

Response:

```json
{
  "ok": true,
  "data": {
    "total_relayed": 142,
    "total_earned_morsels": 284,
    "by_peer": [
      { "peer_id": "aimeat-germany-002", "relayed": 89, "earned": 178 },
      { "peer_id": "aimeat-japan-003", "relayed": 53, "earned": 106 }
    ]
  }
}
```

---

## 13.13 Cross-Genesis Memory Routing

### 13.13.1 Scope

§13.10 (v1.5) specifies that genesis peers exchange **catalogue entries only** — NOT memory. This section extends §13.10 with a mechanism for **routed memory access** across genesis boundaries, where data is queried live but not copied.

### 13.13.2 Design Principle: Route, Don't Copy

Cross-genesis memory access follows a **newsgroup-inspired** model:

- Memory data stays on the origin node at all times
- Queries are **routed** through genesis peers to reach the origin
- Results are returned to the querying agent with provenance metadata
- No caching or copying occurs by default (opt-in caching available)

This preserves data sovereignty: each node retains full control over its memory, and consent can be revoked at any time without needing to coordinate deletion across networks.

### 13.13.3 Routed Query Protocol

When an agent searches for memory that is not available locally, the node MAY forward the query to genesis peers:

**Request** (via `POST /v1/federation/route`):

```json
{
  "target_scope": "genesis",
  "method": "GET",
  "path": "/v1/memory/search",
  "query": {
    "q": "photography techniques",
    "visibility": "public"
  },
  "requesting_gaii": "agent#owner@aimeat-finland-001",
  "signature": "Ed25519_sig(...)"
}
```

**Routing rules:**

1. The local node forwards the query to all active genesis peers
2. Each genesis peer searches its own local federation (its own node + its federation peers)
3. Results are returned with `source_node` and `source_genesis` provenance fields
4. The `max_relay_hops` limit from peering config applies
5. Timeout: `AIMEAT_FEDERATION_TIMEOUT_MS` per peer (default: 10 seconds)

**Response aggregation:**

```json
{
  "ok": true,
  "data": {
    "results": [
      {
        "key": "tips:photography:lighting",
        "value": { ... },
        "source_node": "aimeat-tokyo-005",
        "source_genesis": "aimeat-japan-001-genesis",
        "visibility": "public"
      }
    ],
    "sources_queried": 3,
    "sources_responded": 2,
    "timeout_sources": ["aimeat-brazil-001-genesis"]
  }
}
```

### 13.13.4 Consent Requirements

Cross-genesis memory queries MUST respect the same consent framework as local queries (§16):

- Only entries with `visibility: 'public'` are returned in cross-genesis results
- If the origin node has a consent record with `scope: 'genesis'` for the data, it is eligible
- If the origin node has revoked consent, the data MUST NOT be returned even if previously accessible
- The querying agent's GAII is included in the request so the origin node can evaluate consent

### 13.13.5 Optional Caching Mode

Operators MAY enable local caching of cross-genesis query results for high-latency or unreliable connections:

```ini
AIMEAT_GENESIS_MEMORY_CACHE=false        # Enable local caching of routed results
AIMEAT_GENESIS_MEMORY_CACHE_TTL_HOURS=4  # Cache TTL (default: 4 hours)
```

When enabled:
- Query results are cached locally with prefix `genesis-cache:{genesisNodeId}:{key}`
- Cached entries are served on subsequent queries without re-routing
- Cache entries expire after `AIMEAT_GENESIS_MEMORY_CACHE_TTL_HOURS`
- On consent revocation notification from origin, cached entries MUST be purged immediately

### 13.13.6 Memory Prefix Subscriptions

Operators MAY subscribe to specific memory prefixes from genesis peers, similar to Usenet newsgroup subscriptions. Subscribed prefixes are proactively pushed to the subscribing node rather than queried on demand.

**Peering config extension:**

```json
{
  "subscribe_memory_prefixes": [
    "public:announcements:",
    "shared:moderation:",
    "public:events:"
  ],
  "memory_access_mode": "route"
}
```

| Field | Values | Description |
|-------|--------|-------------|
| `subscribe_memory_prefixes` | Array of strings | Memory key prefixes to subscribe to. Changes to any memory matching these prefixes are pushed proactively. |
| `memory_access_mode` | `"route"` or `"cache"` | `"route"` (default): live queries only. `"cache"`: results are cached locally with TTL. |

When `subscribe_memory_prefixes` is configured, the origin node treats changes to matching memory entries as sync events and includes them in the next sync batch (per §13.11.2).

---

## 32.6 Adaptive Network Operations

### 32.6.1 Overview

Federation networks with many peers face operational challenges: thundering herd effects (all peers syncing simultaneously), resource exhaustion under load, and unequal peer importance. This section specifies adaptive mechanisms that enable nodes to self-balance without requiring hard-coded peer limits.

### 32.6.2 Jittered Sync Scheduling

All scheduled sync operations MUST apply randomized jitter to prevent synchronized bursts (thundering herd problem).

**Algorithm:**

```
next_sync_time = base_interval + (base_interval × jitter_factor × random(-1, 1))
```

Where:
- `base_interval` = `AIMEAT_SYNC_INTERVAL_HOURS` converted to milliseconds
- `jitter_factor` = 0.25 (±25% variation)
- `random(-1, 1)` = uniformly distributed random number between -1 and 1

**Heartbeat staggering:** Each peer's heartbeat MUST be assigned a random offset within the 5-minute heartbeat window at peering activation time. This offset is stored with the peer record and used for all subsequent heartbeats.

```
peer_heartbeat_offset = SHA-256(local_node_id + peer_node_id) mod (heartbeat_interval_ms)
```

Using a deterministic hash ensures the same offset is computed after restarts while still distributing peers across the window.

### 32.6.3 Backpressure-Based Throttling

Nodes MUST monitor their own resource usage and throttle sync operations under load.

**Monitored metrics:**

| Metric | Source | Description |
|--------|--------|-------------|
| `pending_queue_size` | Replication queue | Current number of pending sync entries |
| `avg_sync_duration_ms` | Rolling window | Average time to complete a sync to one peer |
| `failed_syncs_last_hour` | Counter | Number of sync failures in the past hour |
| `cpu_load_percent` | OS metrics | Current process CPU utilization |

**Throttling rules:**

| Condition | Action |
|-----------|--------|
| `pending_queue_size > 5000` | Double the sync interval temporarily (until queue drains below 2500) |
| `avg_sync_duration_ms > AIMEAT_FEDERATION_TIMEOUT_MS × 0.8` | Reduce `AIMEAT_MAX_CONCURRENT_SYNCS` by 1 (minimum: 1) |
| `failed_syncs_last_hour > 50%` of total peer count | Pause non-critical syncs for 15 minutes, then retry with exponential backoff (15min → 30min → 60min) |
| `cpu_load_percent > 80%` | Defer catalogue and memory sync; process heartbeats only |

When load returns to normal (all conditions clear), sync parameters MUST be restored to their configured values within one sync cycle.

### 32.6.4 Peer Priority Scoring

Not all peers have equal urgency for synchronization. Nodes MUST assign dynamic priority scores to peers to determine sync order under load.

**Score calculation:**

```
priority = clamp(0, 100,
  base_score                                           // 50
  + (is_recently_active ? 20 : 0)                       // heartbeat within last 10 minutes
  + (has_catalogue_hash_mismatch ? 30 : 0)              // stale data
  + (recovering_from_unreachable ? 40 : 0)              // needs re-sync
  - (consecutive_failures × 10)                         // deprioritize failing peers
)
```

**Processing order:** Peers are sorted by priority score (descending). The top `AIMEAT_MAX_CONCURRENT_SYNCS` peers are processed in each cycle. Remaining peers are deferred to the next cycle.

**Effect:** Under load, the system naturally prioritizes:
1. Peers recovering from offline (re-sync needed)
2. Peers with stale data (hash mismatch)
3. Recently active peers (healthy relationship)
4. Deprioritizes consistently failing peers (reduce wasted resources)

### 32.6.5 Concurrent Sync Limits

Nodes MUST limit the number of concurrent outbound sync operations:

```ini
AIMEAT_MAX_CONCURRENT_SYNCS=5    # Maximum parallel outbound sync operations (default: 5)
```

This limit applies to catalogue sync and memory replication operations. Heartbeats are NOT subject to this limit and are always processed.

If a node has more active peers than `AIMEAT_MAX_CONCURRENT_SYNCS`, peers are processed in priority order across multiple cycles. This naturally scales: high-capacity nodes process their queue faster, low-capacity nodes take longer but never overload.

### 32.6.6 Observability

Nodes SHOULD expose sync health metrics via the existing stats endpoint:

```
GET /v1/admin/federation/sync-health
```

Response:

```json
{
  "ok": true,
  "data": {
    "sync_mode": "hybrid",
    "queue_depth": 142,
    "queue_max": 10000,
    "active_syncs": 3,
    "max_concurrent_syncs": 5,
    "avg_sync_duration_ms": 2340,
    "failed_syncs_last_hour": 2,
    "total_peers": 12,
    "peers_synced_this_cycle": 8,
    "peers_deferred": 4,
    "throttle_active": false,
    "last_full_cycle_at": "2026-03-07T14:00:00Z",
    "next_scheduled_sync_at": "2026-03-07T20:15:32Z"
  }
}
```

---

## Appendix D: New Configuration Variables

| Variable | Type | Default | Section | Description |
|----------|------|---------|---------|-------------|
| `AIMEAT_SYNC_MODE` | `string` | `"hybrid"` | §13.11.2 | Sync mode: `bulk`, `instant`, or `hybrid` |
| `AIMEAT_SYNC_INTERVAL_HOURS` | `number` | `6` | §13.11.2 | Scheduled sync interval for bulk/hybrid fallback |
| `AIMEAT_SYNC_BATCH_DELAY_MS` | `number` | `5000` | §13.11.2 | Event batching window for instant/hybrid modes |
| `AIMEAT_REPLICATION_QUEUE_MAX` | `number` | `10000` | §13.11.5 | Maximum replication queue size |
| `AIMEAT_REPLICATION_QUEUE_TTL_HOURS` | `number` | `72` | §13.11.5 | Maximum age of queue entries |
| `AIMEAT_MAX_CONCURRENT_SYNCS` | `number` | `5` | §32.6.5 | Maximum parallel outbound sync operations |
| `AIMEAT_GENESIS_MEMORY_CACHE` | `boolean` | `false` | §13.13.5 | Enable local caching of cross-genesis memory queries |
| `AIMEAT_GENESIS_MEMORY_CACHE_TTL_HOURS` | `number` | `4` | §13.13.5 | Cache TTL for cross-genesis memory results |

---

## Appendix E: Sync Protocol Sequence Diagrams

### E.1 Hybrid Mode — Normal Operation

```
Node A                            Node B (Peer)
  |                                   |
  |-- [CSM updated, federate:true] -->|
  |   (event queued)                  |
  |                                   |
  |-- [5s batch window expires] ----->|
  |   POST /v1/federation/catalogue-sync
  |   { since: "...", entries: [...], catalogue_hash: "..." }
  |                                   |
  |<---- 200 OK --------------------|
  |   { accepted: 3, resync_required: false }
  |                                   |
  |-- [Update peer lastSyncAt] ----->|
```

### E.2 Hash Mismatch Recovery

```
Node A                            Node B (Peer)
  |                                   |
  |<-- Heartbeat -------------------|
  |   { stats: { catalogue_hash: "xyz" } }
  |                                   |
  |   [Local hash ≠ "xyz"]           |
  |   [Queue full sync to peer B]    |
  |                                   |
  |-- POST /v1/federation/catalogue-sync
  |   { since: null, entries: [...ALL...] }
  |                                   |
  |<---- 200 OK --------------------|
  |   { accepted: 127, resync_required: false }
```

### E.3 Peer Recovery from Unreachable

```
Node A                            Node B (was unreachable)
  |                                   |
  |<-- Heartbeat (first in 30min) ---|
  |   [Status: unreachable → active]  |
  |                                   |
  |-- POST /v1/federation/key-exchange
  |   { node_public_key: "...", agents: [...] }
  |                                   |
  |<---- 200 OK --------------------|
  |   { node_public_key: "...", agents: [...] }
  |                                   |
  |-- POST /v1/federation/catalogue-sync
  |   { since: null, entries: [...ALL...] }
  |                                   |
  |<---- 200 OK --------------------|
```

### E.4 Multi-Hop Relay with Route Manifest

```
Node A (Origin)      Node B (Relay)       Node C (Provider)
  |                      |                      |
  |-- POST /v1/federation/route -------------->|
  |   { route_manifest: { hops: [] },          |
  |     work: { ... }, escrow: 100 }           |
  |                      |                      |
  |               [Validate sig]               |
  |               [Deduct 1 morsel relay fee]  |
  |               [Append hop + sign]          |
  |                      |                      |
  |                      |-- Forward --------->|
  |                      |   { route_manifest: |
  |                      |     { hops: [{      |
  |                      |       node_id: B,   |
  |                      |       sig: "..." }] |
  |                      |     }, ...}         |
  |                      |                      |
  |                      |<-- Work complete ---|
  |                      |                      |
  |<-- Settlement request -------------------|
  |   { route_manifest: { hops: [B] },        |
  |     result: "delivered" }                   |
  |                                             |
  | [Verify full signature chain]               |
  | [Distribute: C=40%, A=20%, B=20%, R=20%]   |
```

### E.5 Cross-Genesis Memory Query

```
Agent              Node A             Genesis B           Node C (origin)
  |                  |                    |                    |
  |-- Search ------->|                    |                    |
  |   "photography"  |                    |                    |
  |                  |                    |                    |
  |   [Not found     |                    |                    |
  |    locally]      |                    |                    |
  |                  |                    |                    |
  |                  |-- Route query ---->|                    |
  |                  |   target: genesis  |                    |
  |                  |                    |-- Forward -------->|
  |                  |                    |   (local search)   |
  |                  |                    |                    |
  |                  |                    |<-- Results --------|
  |                  |                    |   { source: C }    |
  |                  |                    |                    |
  |                  |<-- Aggregated ----|                    |
  |                  |   results          |                    |
  |                  |                    |                    |
  |<-- Results ------|                    |                    |
  |   [source_node: C,                   |                    |
  |    source_genesis: B]                |                    |
```

---

*AIMEAT Protocol Specification v1.6 — March 2026*  
*Jouni Miikki, Overscale Solutions Oy*
