Nivå 2 · Slik er HAVEN bygd

Fra én idé til byggesteiner du kan kontrollere.

På forsiden er HAVEN én idé: dataene blir hos deg, og den som vil bruke dem, må spørre. Her ser du hvordan det er tenkt bygd, steg for steg. Hvert steg sier om det finnes i kode i dag, og lenker videre til den tekniske beskrivelsen.

1 · Entitet og identiteter

Én person, mange ansikter.

En person eller organisasjon kaller vi en entitet. Entiteten har én identitet per sammenheng, med egen nøkkel. Det beskytter personvernet: det finnes ingen global ID som noen kan slå opp.

Kari og hennes identiteter

Én entitet, tre identiteter i tre domener.

Det betyr

Ingen global ID. Ingen kan slå opp «hele Kari».
Ingen automatisk kobling. Identitetene henger ikke sammen av seg selv.
Kari kan koble dem selv, og trekke koblingen tilbake. Koblingene ligger hos henne, ikke i et felles register.

Implementert Domenebundne identiteter og kobling til samme entitet finnes i kode med tester.

Gå dypere: identitetsmodellen i HAVEN-boka →

2 · Cellen

En liten tjeneste som passer på seg selv.

Programvaren i HAVEN består av små celler. En celle eies av én identitet, holder sine egne data og har sine egne regler for hvem som får lese og skrive. Hvert kall til cellen har med seg hvem som spør.

Fire måter å snakke med en celle

I protokollen heter de Absorb, Emit, Meddle og Explore.

Cellen avgjør selv

Er du eieren? Da får du tilgang.
Hvis ikke: har du en gyldig avtale som dekker akkurat dette? Da får du tilgang innenfor avtalen.
Ellers: avvist. Avslaget logges.

Ingen sentral tjeneste blir spurt om lov. Sjekken skjer i cellen, ved hvert kall.

Implementert Protokollen og tilgangssjekken finnes i åpen kode for Swift, og delvis i Python og Go.

Gå dypere: cellens grensesnitt → · Se testbeviset for tilgangssjekken →

3 · Avtale og formål

Den eneste veien inn går gjennom en avtale.

Alle andre enn eieren kommer inn gjennom en avtale. Den sier hva som skal brukes, hvorfor, og hvor lenge. Blir den godtatt, blir den en signert kontrakt som kan trekkes tilbake.

Fra forespørsel til kontrakt

Formålet sier hva dataene skal brukes til. Retten til å bruke dem kommer bare fra kontrakten.

Fem spørsmål som alltid bør kunne besvares

Hvem ba om handlingen? Hva var formålet? Hva fikk den lov til? Hvor lenge gjaldt det? Hva skjedde faktisk? Avtalen er der svarene skal bo.

Implementert Avtaler, kontrakter og tilganger finnes i kode med tester. Brukerflatene rundt dem er prototyper.

Gå dypere: avtaler og kontrakter → · formål → · et helt eksempel →

4 · Noder og bro

Ingen plattform i midten.

Cellene kjører på noder. Nodene snakker direkte med hverandre over en bro. En celle på en annen node ser ut som en lokal celle, og den cellen avgjør fortsatt selv hvem som får gjøre hva.

To noder

Broen flytter bare meldinger. Nøkkelen blir hos Kari.

Delvis Noder og bro kjører i dag, men nodene driftes av HAVEN selv. At hvem som helst kan drive sin egen node, er målet, ikke dagens situasjon.

Gå dypere: noden → · broen →

5 · Hendelser og spor

Det som skjer, skal kunne etterprøves.

Cellene sender hendelser til hverandre. Hendelser kan pakkes i signerte konvolutter som peker bakover til den forrige, slik at et spor ikke kan endres i ettertid uten at det synes. Det er grunnlaget for kvitteringen du skal få.

Et spor av signerte konvolutter

Stiplet: finnes som bibliotek med tester, men brukes ennå ikke i flyten mellom celler.

Delvis Signerte hendelser finnes i kode. Varig lagring og avspilling er ikke garantert ennå.

Gå dypere: hendelser og livsløp →

6 · Hvem passer på reglene?

Koden håndhever. Digipomps holder reglene åpne og etterprøvbare.

I HAVEN er det cellen som sier nei, ikke et sentralt kontor. Men noen må forvalte reglene cellene følger, og sørge for at det går an å sjekke om en tjeneste faktisk følger dem. Den rollen har Stiftelsen Digipomps.

Det Digipomps gjør i dag

Forvalter protokollen. CellProtocol er åpen kode, og reglene står i HAVEN-boka og i maskinlesbare kontrakter.
Bygger håndhevelsen inn i koden. Tilgangssjekken i cellen, avtalen som eneste vei inn og tester som viser at feil forespørsler avvises.
Drifter nodene. I dag kjører HAVEN-nodene hos oss. Det er en praktisk start, ikke målet.
Holder seg selv til regning. Påstander får status, og rettelser føres i en offentlig logg.

Det vi bygger mot

Prøver alle kan kjøre. Åpne tester som viser om en tjeneste sier formålet, ber om minst mulig, gir kvittering og lar deg stoppe.
Åpne lister over hvem som er betrodd. For eksempel hvilke utstedere eller ideelle organisasjoner som er godkjent. Godkjenningen skal kunne ses og etterprøves.
Mindre makt hos oss over tid. Flere implementasjoner, flere som drifter noder, og mulighet til å forlate systemet.
Et skille mot det kommersielle. Protokollen og grunnreglene skal være et fellesgode. Kommersielle tjenester, også DiMy, skal bygge på dem uten å eie dem.

Grensen: En stiftelse gjør ikke programvaren sikker, og den gjør ikke Digipomps nøytral. Hvordan beslutninger fattes og kontrolleres uavhengig, er ikke publisert ennå. Det står som åpne oppgaver på om-siden.

Delvis Håndhevelsen i koden finnes. Åpne samsvarsprøver, betrodde lister og uavhengig kontroll er ikke på plass.

Gå dypere: fellesgoder og forvaltning → · om Stiftelsen Digipomps →

Videre

Byggesteinene finnes. Mye av helheten gjenstår.

To sider går et nivå dypere: én som skiller det som finnes i kode fra det som bare er planlagt, og én om spørsmålene vi ikke har svar på.