CBERCBER: federation
Status: separate design specification 0.1 · 17 September 2026. This document accompanies the local core specification. It defines the boundary and requirements for cooperation; the settlement protocol has not yet been selected or implemented.
Two independent specifications
The core defines how one cooperative accounts for claims and reserve. Federation defines communication and settlement between independent instances. An instance can implement the core without federating.
Federation changes no local invariant. A received message is not an energy measurement. A claim on instance A is not reserve belonging to B. A partner's signature does not authorise that partner to create claims in another ledger.
What federation must specify
| Subject | Requirement for an executable protocol |
|---|---|
| Origin | Every claim, quote, instruction and measurement identifies the responsible instance. Users see who owes performance. |
| Identity and authority | Partners verify keys, roles and supported specification versions. Rotation and revocation follow a defined procedure. A partner cannot spend on a member's behalf. |
| Quote | Rate rule, fees, energy unit, quantity, destination, expiry and responsible parties are fixed before execution. |
| Settlement | Explicitly distinguish ownership transfer of existing claims, physical energy transfer and a prefunded counter-performance. Never silently treat them as equivalent. |
| Messages | Signed messages are bound to an incident or instruction and durably deduplicated. Delayed, duplicate and out-of-order messages have defined outcomes. |
| Reservation and completion | Each reserved position has one owner, one instruction and a defined terminal state. Waiting for a partner cannot enable double spending. |
| Failure and disputes | Define partner failure, contradictory receipts, expired quotes and physically completed but administratively unresolved deliveries. A timeout is not proof of non-execution. |
| Privacy | Partners receive only information necessary for the instruction. Federation does not publish accounts, spending patterns or individual queues. |
| Joining and leaving | Joining or leaving cannot erase obligations. Controlled winding-up and an accountable party are required. |
Boundary with the core
A federation adapter can request only the same local postings as other authorised parties. Payments move existing claims. New local claims arise only under the core contribution rule, with its physical evidence. Exchanging existing claims trades two outstanding positions; it does not create local money.
Cross-instance operations therefore require a separate execution profile. It specifies the complete state machine: preparation, reservation, execution, evidence, final settlement and recovery. It must not pretend that two independent databases and physical delivery form one atomic transaction.
Existing design work
The federation, secession and ActivityPub ideas in v0.18 remain historical design input. They do not automatically become requirements of this new federation specification. Selecting a message transport, for example, does not settle backing, liability or finality.
The first implementation profile must select one concrete operation and test partner failure and duplicate delivery. Until that profile is complete, this is an independent specification under design, not a claim of working interoperability. The local core does not need to wait for it.