# RFC-0006: Federation: catalogs, registries, feeds and relays

**Status:** proposed, 2026-10-04. **Kind:** additive fields on `Discovery`; a guide; a
conformance rule. **Safety relevant:** yes (recall propagation).

## Problem

The founder wants a system that works "like bees": no central command, harmony, recovery
(M49). The repository has the pieces (catalogs anyone can host, a registry spec, signed
documents, recall feeds, witnessed checkpoints) but no statement of how they form a network,
and no rule that stops a relay from forging what it relays.

## Proposal

1. **Nodes and roles.** Any host may be a *catalog* (serves `/.well-known/cookwala.json`
   and `/v1`), a *registry* (serves `/v1/registry.json`), a *hub* (local kitchen), a
   *mirror* (republishes others' signed items) or several at once. cookwala.ai is one node.
2. **Feeds, not commands.** `Discovery.feeds` lists the node's feeds: `recalls`,
   `incidents` (anonymous), `registry` (changes), `keys` (key records). Nodes poll feeds
   they trust and may republish items unchanged.
3. **Verify against the issuer, never the relay.** A relayed recall, recipe, rule pack or
   registry entry verifies only with the **issuer's** `KeyRecord` (resolved from the
   issuer's own discovery document or did:web). A relay's key proves nothing about the
   content. Profile vectors demonstrate this with the existing `signature` kind: the same
   recall verifies with the issuer key and is `unknown_key` with only the mirror's key.
4. **Provenance.** A republished item may carry `x-relay` metadata (who relayed, when); the
   signed body is untouched.
5. **Trust lists.** Hubs keep a list of catalogs and registries with keys and priorities;
   `Discovery.peers` lets a node suggest peers, which a hub may ignore.
6. **Freshness.** Registry entries carry `status` and `publishedAt`; recalls carry
   `issuedAt`; facets carry `validFor`. Stale items are re-fetched or dropped, never trusted
   by age.
7. **History.** Event logs with witnessed checkpoints (Core §5) stay the mechanism for
   tamper evidence. No blockchain is required; public anchoring remains optional.
8. **Guide:** `docs/FEDERATION.md` explains how a food-bank network, a device maker and a
   university lab each run their own node and still interoperate.

## Alternatives considered

- **A central registry and recall authority.** Rejected: single point of failure and of
  capture; contradicts neutrality.
- **Gossip protocol with push.** Rejected for now: polling signed feeds is enough for the
  volumes expected and works through firewalls and offline windows.

## Migration

Additive: `feeds` and `peers` are optional on `Discovery`.

## Open questions

1. Minimum poll interval for recall feeds on devices: proposal, hourly when online, and on
   every start.
2. Should mirrors be able to add their own "seen at" attestation as a counter-signature?
   Proposal: later, as a witness in a transparency log.