CBERCBER: federatie
Status: aparte ontwerpspec 0.1 · 17 september 2026. Dit document staat naast de lokale kernspec. Het beschrijft de afbakening en eisen aan samenwerking; het verrekenprotocol is nog niet vastgesteld of geïmplementeerd.
Twee zelfstandige specs
De kernspec bepaalt hoe één coöperatie claims en reserve boekt. Deze federatiespec bepaalt hoe onafhankelijke instances met elkaar communiceren en afrekenen. Een instance kan de kern uitvoeren zonder te federeren.
Federatie verandert geen lokale invariant. Een ontvangen bericht is geen energiemeting. Een claim op instance A is geen reserve van instance B. Een handtekening van een partner geeft die partner geen recht om claims in een ander grootboek te creëren.
Wat federatie moet regelen
| Onderwerp | Vereiste voor een uitvoerbaar protocol |
|---|---|
| Herkomst | Iedere claim, offerte, opdracht en meting benoemt de verantwoordelijke instance. De gebruiker ziet wie de verplichting draagt. |
| Identiteit en bevoegdheid | Partners verifiëren elkaars sleutels, rollen en ondersteunde specversies. Sleutelwissels en intrekking hebben een vastgelegde procedure. Een partner kan niet namens een lid betalen. |
| Offerte | Koersregel, kosten, energie-eenheid, hoeveelheid, bestemming, geldigheidsduur en verantwoordelijke partijen liggen vast vóór uitvoering. |
| Verrekening | Er wordt expliciet gekozen wat werkelijk verhuist: eigendom van bestaande claims, fysieke energie of een vooraf gefinancierde tegenprestatie. Die drie worden nooit stilzwijgend gelijkgesteld. |
| Berichtverwerking | Berichten zijn ondertekend, incident- of opdrachtgebonden en duurzaam gededupliceerd. Vertraagde, dubbele en verkeerd geordende berichten hebben een gedefinieerd resultaat. |
| Vastzetten en afronden | Iedere gereserveerde positie heeft één eigenaar, één opdracht en een vastgelegde eindtoestand. Geen dubbel uitgeven tijdens wachten op een partner. |
| Uitval en geschil | Het protocol bepaalt wat gebeurt bij wegvallen van één partij, tegenstrijdige ontvangstbewijzen, verlopen offertes en een levering die fysiek wel, maar administratief nog niet vaststaat. Een timeout is geen bewijs dat niets is uitgevoerd. |
| Privacy | Partners ontvangen alleen wat nodig is voor deze opdracht. Federatie publiceert geen accounts, bestedingspatronen of individuele wachtrijen. |
| Toetreding en vertrek | Aansluiten of vertrekken wist geen open verplichtingen. Er is een gecontroleerde afwikkeling en een aanspreekbare verantwoordelijke. |
Grens met de kern
Een federatie-adapter kan uitsluitend dezelfde lokale boekingen aanvragen als andere bevoegde partijen. Betalen verplaatst bestaande claims. Nieuwe lokale claims ontstaan alleen via de inbrengregel van de kern, met de vereiste fysieke onderbouwing. Als twee partijen bestaande claims ruilen, is dat een ruil van twee uitstaande posities, geen nieuwe lokale geldschepping.
Voor een cross-instance handeling is daarom een afzonderlijk uitvoeringsprofiel nodig. Dat profiel legt de complete toestandsmachine vast: voorbereiding, reservering, uitvoering, bewijs, definitieve afwikkeling en herstel. Het mag niet doen alsof twee onafhankelijke databases en een fysieke levering één atomische transactie vormen.
Bestaande ontwerpideeën
De federatie-, secessie- en ActivityPub-ideeën uit v0.18 blijven bewaard als historische ontwerpinput. Ze zijn niet automatisch regels van deze nieuwe federatiespec. De keuze van berichttransport beslist bijvoorbeeld nog niets over dekking, aansprakelijkheid of afwikkeling.
De eerste uitwerking moet één concreet profiel kiezen en op partneruitval en dubbel aanbieden toetsen. Totdat dat profiel compleet is, is dit een zelfstandige specificatie in ontwerp en geen claim van werkende interoperabiliteit. De lokale kern hoeft daarop niet te wachten.