Ett spørsmål om gangen.

HAVEN på ett minutt

HAVEN er et åpent forsøk på å organisere digitale verktøy rundt mennesker, tydelige formål og avgrenset autoritet.

I dag må vi ofte gi en tjeneste mer informasjon og makt enn oppgaven egentlig krever. De samme opplysningene ender ofte i flere, separate siloer. En tillatelse er gjerne en lang tekst og én knapp. Når noe går galt, kan det være vanskelig å se hvem som fikk gjøre hva.

HAVEN foreslår en annen grunnstruktur. Funksjonalitet deles i små deler, kalt Cells. En forespørsel skal beskrive formålet. Autoritet skal gis uttrykkelig og avgrenset. Handlinger kan gi en forståelig kvittering. Identitet og erfaring skal gjelde i den sammenhengen de hører til, ikke bli en nøkkel eller poengsum som følger et menneske overalt.

Dette er ikke én ferdig verdensplattform. Det finnes implementerte protokollbyggesteiner, tester og avgrensede brukerreiser. Andre deler er piloter eller forskning. Den forskjellen er en del av forklaringen, ikke liten skrift.

Hvorfor begynner vi med mennesket?

Fordi et verktøy ikke er vellykket bare fordi systemet kjører. Det må øke menneskets evne til å forstå, velge, skape og høre til.

HAVENs rotformål er enkelt formulert: Alle mennesker er like mye verdt. Det er en normativ beslutning, ikke et forskningsfunn. Spørsmålet er hva setningen krever av programvaren.

Den krever blant annet at vi ikke rangerer mennesker med en global score, at formålet med en forespørsel blir synlig, og at autoritet kan avgrenses og trekkes tilbake. Den krever også at «mer kontroll» ikke blir en ny fulltidsjobb for brukeren. Gode standardvalg og forståelig hjelp er en del av menneskelig handlingsrom.

EU har valgt en beslektet retning i erklæringen om digitale rettigheter: den digitale omstillingen skal sette mennesker, verdier og grunnleggende rettigheter i sentrum. Det beviser ikke at HAVEN lykkes. Det viser at utgangspunktet deles av flere enn oss.

En vanlig dag med HAVEN

Tenk deg at en konferansedeltaker vil be om et møte – uten å gi fra seg hele kontaktlisten, alle notatene eller en livslang tillatelse.

Først ser mottakeren hva forespørselen gjelder. Kanskje den inneholder navn, ønsket tema og en kort begrunnelse. I den skisserte flyten blir resten liggende privat. Mottakeren kan godta, avslå eller be om en avklaring.

Hvis forespørselen godtas, får avsenderen ikke «tilgang til personen». En riktig avgrenset flyt gir bare den autoriteten den konkrete handlingen trenger. Etterpå kan begge se en kvittering: lagret, avvist eller feilet.

Dette er den typen avgrenset reise HAVEN allerede har arbeidet med i en konferansepilot. Kvitteringen kan si hva som skjedde i den aktuelle huben. Den kan ikke bevise hva et menneske gjør senere, eller at hele HAVEN er sikkert.

Tillit uten poengsum

HAVEN prøver ikke å gi deg en karakter. Det prøver å gjøre det tydelig hva som er avtalt, hvilket bevis som finnes, og hvor langt beviset faktisk rekker.

Et borettslag kan vite at Kari og Ola samarbeidet godt om fellesrommet. Et verksted kan bekrefte at Ola gjorde et bestemt bidrag. Ingen av delene gir grunnlag for å si at Ola er «87 prosent pålitelig» i alle deler av livet.

Derfor skal forbindelser ha et verb og en sammenheng: «har samarbeidet med», «kan bekrefte dette bidraget», «har fått tilgang til dette rommet frem til fredag». Kilde, tidspunkt og omfang er viktigere enn en samlet rangering.

Et bevis er ikke det samme som sannhet

Kryptografi kan hjelpe oss å se hvem som sa noe og om innholdet er endret. Den kan ikke avgjøre om påstanden er klok, rettferdig eller sann i alle relevante betydninger.

Et digitalt bevis kan for eksempel vise at et universitet utstedte et vitnemål. Det gir et langt bedre grunnlag enn et skjermbilde uten kilde. Men vi må fortsatt vite om vi stoler på universitetet for akkurat denne typen påstand, om beviset er gyldig, og om informasjonen er relevant for formålet.

W3Cs modell for Verifiable Credentials skiller mellom utsteder, innehaver og kontrollør. Det er nyttig fordi opprinnelse og integritet kan undersøkes maskinelt. Men teknologien fjerner ikke behovet for menneskelig og institusjonelt skjønn.

NISTs arbeid med «zero trust» formulerer et beslektet sikkerhetsprinsipp: nettverksplassering eller eierskap skal ikke i seg selv gi implisitt tillit. Autentisering og autorisering er egne vurderinger.

En avtale før tilgang

En forespørsel er ikke en tillatelse. Det høres selvfølgelig ut, men mange digitale systemer gjør skillet uklart.

I HAVEN beskriver en forespørsel hva noen ønsker å gjøre: lese et felt, sende en invitasjon eller utføre en avgrenset handling. En kontrakt beskriver hvilken autoritet som faktisk er gitt – til hvem, for hvilket formål, under hvilke vilkår og eventuelt hvor lenge.

Det er en bedre mental modell enn «har tilgang / har ikke tilgang». Du kan låne noen nøkkelen til sykkelboden uten å gi dem hovednøkkelen til huset. På samme måte bør digitale tjenester få den minste autoriteten oppgaven trenger.

CellProtocol har byggesteiner for Agreements, Contracts og capabilities. Det betyr ikke at all programvare i HAVEN allerede bruker dem riktig. Hver brukerreise må testes, også for avslag, utløp og feil.

Hva er en Cell?

En Cell er en liten, avgrenset komponent med ett tydelig ansvar og et felles språk for å samarbeide med andre komponenter.

Tenk på et godt verksted. Du ønsker ikke én enorm maskin som bare produsenten forstår. Du ønsker verktøy med tydelige oppgaver, kjente koblinger og mulighet til å bytte ut én del uten å rive hele rommet.

En Cell kan ta imot en strøm, arbeide deterministisk med den og sende en ny strøm videre. Den kan beskrive hva den kan gjøre. En Resolver finner riktig Cell og skal håndheve eier- og tilgangsregler. Et Scaffold er miljøet som finner, setter sammen og viser Cells.

Målet er gjenbruk og forståelige grenser. Gevinsten er ikke bevist bare fordi delene er små. Flere komponenter kan også bety flere kontrakter, versjoner og driftsgrenser. Derfor må HAVEN måle faktisk gjennomføringstid, feil og læringskostnad i piloter.

Formål før produktnavn

Ofte vet du hva du vil oppnå før du vet hvilket produkt som kan hjelpe deg.

«Jeg vil forstå dette vedtaket» er et formål. «Jeg trenger app X» er bare én mulig løsning. HAVEN bruker formål som et semantisk lag for å finne relevante verktøy, forklare hvorfor en handling foreslås og definere et mål som kan undersøkes.

Et formål er ikke en skjult gjetning om motivene dine. Det bør være deklarert, forståelig og mulig å korrigere. Hvis systemet ikke vet, skal det si «ukjent» i stedet for å bygge en hemmelig profil.

Dette er også nyttig i samarbeid. Når uenighet oppstår, kan vi spørre om vi er uenige om målet, om midlene eller om bevisene. Det er mer produktivt enn å la alle argumentere for hvert sitt verktøy.

Produktivitet uten å gjøre mennesker til måltall

Målet er ikke å presse flere klikk ut av hvert menneske. Målet er å fjerne unødvendig friksjon og gjøre det lettere å skape noe som betyr noe.

Små gjenbrukbare Cells, forståelige avtaler og mindre dobbeltarbeid kan spare tid. Men modularitet kan også gi flere koblinger å forstå. En god idé på et ark er ikke en produktivitetsgevinst.

Derfor bør piloter måle mer enn fart. Hvor lang tid tok oppgaven? Hvor mange feil oppsto? Kunne løsningen brukes på nytt? Forsto mennesket hva som skjedde? Ble belastningen flyttet fra organisasjonen til brukeren?

Livskvalitet og kollektiv glede er designmål, ikke effekter vi tar for gitt. Vi må undersøke nytte, autonomi, tilhørighet, belastning og hvem som faktisk får gevinsten.

Et demokrati trenger mer enn en app

Teknologi kan støtte deltakelse. Den kan ikke skape representativitet, legitimitet eller politisk vilje alene.

OECDs tillitsundersøkelse viser en tydelig sammenheng mellom opplevd politisk handlingsrom og tillit til offentlige institusjoner. Folk som opplever at de har en stemme, rapporterer gjennomgående mer tillit. Det betyr ikke at en digital løsning automatisk gir bedre demokrati.

HAVEN undersøker mer beskjedne byggesteiner: et innspill kan få synlig formål og kilde, motargumenter kan holdes adskilt fra støtte, og oppfølging kan få en etterprøvbar historikk. Det kan gjøre det lettere å se om innspill ble mottatt, behandlet eller avvist.

Men den vanskelige delen står igjen. Hvem inviteres? Hvem mangler tid, språk eller trygghet til å delta? Hvem har beslutningsmakt? Hva skjer når myndighetene ikke følger opp? En pen flyt kan også bli symbolsk deltakelse.

Kan bidrag og verdi kobles bedre?

Vi undersøker om sporbare kontrakter, bidragsbevis og simulerbare regler kan føre mer verdi tilbake til individer og fellesskap.

Mange digitale tjenester blir mer verdifulle når mennesker bidrar med data, arbeid, kuratering, omsorg eller oppmerksomhet. Likevel er det ofte uklart hvem som fikk verdien, hvilke regler som ble brukt, og om bidragsyteren kunne protestere.

En mulig HAVEN-retning er å knytte et avgrenset bidragsbevis til en synlig fordelingsregel. Regelen kan simuleres før den brukes og føre en andel til individ, fellesskap og nødvendig drift.

De vanskelige spørsmålene er selve arbeidet: Hvem definerer et bidrag? Hvordan fanges usynlig arbeid? Hvem kan manipulere målingen? Hvem kan klage? Hva er den juridiske klassifiseringen?

Åpne byggesteiner som fellesgode

Hvis et digitalt fundament skal beskytte menneskers handlingsrom, bør ingen enkelt leverandør alene få definere spillereglene.

Åpen kode gjør det mulig å undersøke og gjenbruke løsninger. En ideell forvalter kan redusere enkelte interessekonflikter. Men verken åpen kildekode eller en stiftelsesform gjør et system automatisk nøytralt.

Nøytralitet krever konkrete mekanismer: tydelige vedtekter, åpne beslutninger, uavhengig kontroll, mulighet til å forlate systemet, flere kompatible implementasjoner og en kultur for å publisere feil og begrensninger.

HAVENs mål er at protokollen og de grunnleggende semantiske reglene kan være et fellesgode. Kommersielle tjenester skal kunne skape verdi på toppen uten å få eierskap til menneskets identitet eller hele økosystemets definisjonsmakt.

Det som virker, det vi tester, og det vi håper å lære

HAVEN er et reelt utviklingsarbeid med kode, tester og kjørende demonstrasjoner. Helheten er ikke ferdig bevist.

Implementert og testet i avgrensede deler

CellProtocol har runtimebyggesteiner og kontrakttester for Cells, strømmer, eksplisitt autoritet, avgrenset identitet, Purpose og Claim-modeller. Det finnes også Scaffolds og en lokal agent med tydelige sikkerhetsgrenser.

Pilot og demonstrasjon

Enkelte konferanse-, profil-, tilgangs- og betalingsbevisflyter er demonstrert eller målrettet testet. En avgrenset konferansereise viser hva som deles, hva som forblir privat og hvilket utfall huben registrerte.

Forskning og retning

Generisk offentlig sidepublisering, demokratiske deltakelsesprosesser og full verdifordeling er ikke ferdige mekanismer. ContributionProof og ValuePoolPolicy er spesifisert som retning; en runtime for bred verdifordeling er utsatt til simulering og ledgergrunnlag er godt nok.

Det vi ikke hevder

Ingen universell sikkerhet, global skala, regulatorisk avklaring, ferdig verdiøkonomi eller dokumentert samfunnseffekt.

Dette lover vi ikke

Troverdighet begynner med å si høyt hva prosjektet ikke kan dokumentere.

• Vi lover ikke at HAVEN løser ulikhet eller «fikser demokratiet».
• Vi lover ikke en global omdømmescore, global person-ID eller skjult atferdsprofilering.
• Vi lover ikke at en signatur gjør en påstand sann.
• Vi lover ikke at selvhosting alene gir sikkerhet eller personvern.
• Vi lover ikke at credits, tilgang eller utbetalinger er regulatorisk avklart uten en konkret juridisk vurdering.
• Vi lover ikke global skala før den er målt.

Det vi kan love, er en arbeidsmåte: skille formål fra påstand, skille bygget fra ønsket, søke motargumenter, føre kilder nær teksten og gjøre avgrensningen synlig.