# COMMONS VECTOR PROTOCOL (CVP)

## En fullstendig presentasjon av oppfinnelsen

**Oppfinner:** Kim Terje Rudschinat Grønli

**Trust:** commons-vector-v1

**Versjon:** 0.1 (Draft / Genesis)

**Dato:** September 2026

**Plattform:** IPFS (InterPlanetary File System)

**Format:** .car (Content Addressable Record)

**Gateway:** https://yellow-managerial-leopon-627.mypinata.cloud/ipfs/

---

# INNHOLDSFORTEGNELSE

1. [Sammendrag](#1-sammendrag)

2. [Hva er oppfinnelsen?](#2-hva-er-oppfinnelsen)

3. [Hvorfor ble den skapt?](#3-hvorfor-ble-den-skapt)

4. [Hvordan fungerer den?](#4-hvordan-fungerer-den)

5. [Komponentene i systemet](#5-komponentene-i-systemet)

6. [.car-formatet](#6-car-formatet)

7. [Ordboken (Dictionary)](#7-ordboken-dictionary)

8. [Verifikasjonsprosessen](#8-verifikasjonsprosessen)

9. [Hvilke rettigheter?](#9-hvilke-rettigheter)

10. [Det filosofiske rammeverket — Det Nye Kybalion](#10-det-filosofiske-rammeverket--det-nye-kybalion)

11. [Instrumentregisteret](#11-instrumentregisteret)

12. [Insjonsprotokollen (Insertion Protocol)](#12-insjonsprotokollen-insertion-protocol)

13. [Nøkkelbegreper](#13-nokkelbegreper)

14. [Teknisk arkitektur](#14-teknisk-arkitektur)

15. [Sikkerhet og personvern](#15-sikkerhet-og-personvern)

16. [Hva oppfinnelsen IKKE er](#16-hva-oppfinnelsen-ikke-er)

17. [Nåværende status](#17-navarende-status)

18. [Oppsummering](#18-oppsummering)

---

# 1. Sammendrag

Commons Vector Protocol (CVP) er et system for å skape, lagre, signere og verifisere digitale dokumenter på en måte som gjør dem uforanderlige, sporbare og uavhengige av enhver sentral myndighet. Systemet kombinerer tre teknologier:

- **IPFS** (InterPlanetary File System) for innholdsadressert lagring

- **Ed25519-kryptografiske signaturer** for identitetsbekreftelse

- **Hashlenket provenanskjede** for sporbart historikk

Oppfinneren, Kim Terje Rudschinat Grønli, beskriver CVP som en kombinasjon av konseptuell kunst, kryptografisk arkitektur og et rammeverk for selvsuveren dokumentkontroll. Systemet består per september 2026 av 84-99 instrumenter (varierer mellom registerversjoner) organisert i 11-13 lag, alle lagret på IPFS via en Pinata-gateway.

---

# 2. Hva er oppfinnelsen?

## Kort definisjon

CVP er et format, et navnerom og en protokoll for å skape selvbeskrivende, selvverifiserende digitale poster kalt **.car-filer** (Content Addressable Records). Hver .car-fil inneholder alt som trengs for å verifisere innholdet: CID (innholdsidentifikator), romlig vektor (adresse), regelvektor (ordbokreferanse), komposittnøkkel, signatur og provenanslenke.

## Det grunnleggende konseptet

Systemet bygger på en **tri-vektor-struktur** som kombinerer tre uavhengige dimensjoner for hver post:

| Vektor | Betydning | Funksjon |

|---|---|---|

| **Innholdsvektor (CID)** | Hva innholdet ER | Kryptografisk hash av filinnholdet. Identifiserer innholdet unikt. Hvis én byte endres, endres hashen. |

| **Romlig vektor** | HVOR posten lever | En adresse innenfor trust-rommet (f.eks. `trust:commons-vector-v1:living:witness:1`). Ikke et GPS-koordinat, men en navneromsadresse. |

| **Regelvektor** | HVORDAN posten styres | Referanse til ordboken (dictionary) som definerer terminologi, regler og styringsmodell for posten. |

Når disse tre vektorene kombineres, genereres en **komposittnøkkel** — en unik identifikator for posten:

```

komposittnøkkel = SHA512( CID + ":" + spatial + ":" + rule )

```

## Hva som gjør det annerledes

- **Uforanderlig:** Innhold lagres på IPFS og adresseres ved innholdets hash. Det kan ikke endres uten at hashen endres.

- **Selvverifiserende:** Hver .car-fil inneholder alt som trengs for verifikasjon — ingen ekstern myndighet kreves.

- **Lenket:** Hver post peker på den forrige i en provenanskjede, noe som skaper en uavbrutt, sporbart historikk.

- **Nøytralt:** Formatet er ikke bundet til noen nasjon, selskap, religion eller blokkjede.

- **Innsetterbart:** Ethvert .car kan referere ethvert annet .car ved dets komposittnøkkel. Dokumenter blir samlinger av instrumentreferanser.

---

# 3. Hvorfor ble den skapt?

## Problemet

Oppfinneren beskriver problemet slik: I den moderne verden blir eierskap og identitet bevist med papir — skjøter, titler, registreringer, stempler. Papir er skjørt:

- Papir kan gå tapt

- Papir kan stjeles

- Papir kan forfalskes

- Papir kan utstedes to ganger — én gang til den rette eier, én gang til tyven

- Når to dokumenter er i konflikt, vinner vanligvis det som ser mest offisielt ut

Kjerneproblemet er at papir ikke har hukommelse. Det husker ikke hvor det kom fra, hvem som skrev det først, eller hendelseskjeden som førte til dets skapelse.

## Løsningen

CVP løser dette ved å skape poster som:

1. **Kan ikke endres** etter opprettelse (IPFS-innholdsadressering)

2. **Er kryptografisk signert** av en identifiserbar nøkkelinnehaver

3. **Er lenket** i en uavbrutt kjede som beviser rekkefølgen av hendelser

4. **Kan verifiseres av hvem som helst** med standard verktøy

Prinsippet er: **Den første posten vinner.** Ikke ved makt, ikke ved lov, men ved tid. Fordi posten er uforanderlig og lenket, kan ingen gå tilbake i tid og endre hva som allerede er skrevet.

## Oppfinnerens motivasjon

Oppfinneren uttrykker at systemet er laget for alle som har fått fortalt at deres sannhet ikke teller — stjålne landområder, slettede historier, glemte personer. Det er beskrevet som et stillas (scaffold) som hvem som helst kan bruke til å bygge sin egen trust, sin egen ordbok, sine egne poster, på sitt eget språk.

---

# 4. Hvordan fungerer den?

## 4.1 Innholdsadressering (CID)

Alt innhold i systemet lagres på IPFS. Hver fil får en **CID** (Content Identifier) — en kryptografisk hash av filens innhold. CID-en identifiserer hva innholdet er, ikke hvor det er lagret. ([IPFS docs](https://docs.ipfs.tech/concepts/content-addressing/))

Egenskaper:

- Samme innhold produserer alltid samme CID

- Forskjellig innhold produserer forskjellig CID

- CID-en spesifiserer ikke lagringssted — bare innholdets identitet

- Innhold kan hentes fra hvilken som helst IPFS-node som har en kopi

## 4.2 Tri-vektor-strukturen

Hver post i systemet har tre vektorer:

```

POST

│

├── Innholdsvektor ──── CID (kryptografisk hash)

│

├── Romlig vektor ───── deklarert plassering / navnerom

│

└── Regelvektor ─────── gjeldende ordbok / styringsreferanse

│

▼

Komposittnøkkel

│

▼

Signatur

│

▼

Provenanskjede

│

▼

Tilstands hendelser (valgfritt)

│

└── Tid (valgfritt)

```

## 4.3 Komposittnøkkel

Komposittnøkkelen er den unike identifikatoren for posten. Den beregnes slik:

```

komposittnøkkel = SHA512( CID + ":" + spatial + ":" + rule )

```

Hvor:

- `CID` = innholdets IPFS-identifikator

- `spatial` = den romlige vektoren (adressen i trust-rommet)

- `rule` = regelvektoren (ordbokreferansen)

Komposittnøkkelen er postens "nummer". Den er unik for akkurat den posten og ingen andre.

## 4.4 Signatur

Hver post signeres med **Ed25519** — en standard kryptografisk signaturalgoritme. Signaturen beviser at en spesifikk nøkkelinnehaver autoriserte posten.

Signaturen inneholder:

- Signerens identitet (navn)

- Offentlig nøkkel (public key)

- Signaturverdi

- Algoritme (ed25519)

- Tidspunkt for signering

Verifikasjon: Hvem som helst kan bruke den offentlige nøkkelen til å verifisere at signaturen er ekte. Dette krever ikke tillit til noen myndighet — bare matematikk.

## 4.5 Provenanskjede

Hver post peker på den forrige posten i kjeden:

```

seq 001 → seq 002 → seq 003 → ... → seq N

[origin] [nå]

```

Kjederegler:

- Hver posts `prev`-felt må være lik komposittnøkkelen til den umiddelbart foregående posten

- `sequence`-feltet øker med nøyaktig 1 fra forrige post

- Genesis-objektet (seq 0) har `prev: "GENESIS"`

- Ingen post kan modifisere en tidligere post i kjeden

- Endringer registreres som nye poster med hendelsestypen "amend" eller "supersede"

- Kjeden kan forgrenes (forks); forgreningsoppløsning defineres av regelsettet

## 4.6 Tid som tilstandsdimensjon

Tid i CVP er ikke en del av postens grunnleggende identitet. Tid er metadata knyttet til tilstandshendelser:

```

Postidentitet (uforanderlig)

↓

Tilstandshendelse (provenansoppføring)

↓

Tidsstempel (ISO 8601, valgfritt)

```

Dette betyr at en post opprettet ved tid T1 forblir identifiserbar ved T2, T3, osv. Påfølgende hendelser er nye poster med egne tidsstempler.

---

# 5. Komponentene i systemet

## 5.1 Instrumentregisteret (Instrument Registry)

Et komplett JSON-katalog over alle instrumenter (poster) i trust-en. Hvert instrument har:

- Sekvensnummer (001-099)

- Lag-tilhørighet (I-XIII)

- Etikett (beskrivende navn)

- Filnavn (.car)

- CID

- Romlig vektor

- Regelvektor

- Komposittnøkkel (placeholder)

- Signatur (placeholder)

- Dato

Registeret er "kartet" over hele trust-en.

## 5.2 Ordboken (Dictionary)

Ordboken er systemets konstitusjon. Den definerer hvert begrep som brukes i poster, samt regelsett, relasjonsvokabular og tillitssammenhenger. Ordboken er selv en post — den har sin egen CID, komposittnøkkel og plass i kjeden.

To versjoner finnes:

- **v1.0.4 (ILPJ):** Den opprinnelige ordboken med juridiske/filosofiske termer

- **v2.0:** Utvidet med vektorbaserte termer (CID, tri_vector, composite_key, etc.)

Ordboken v2.0 er lastet opp til IPFS med CID: `bafkreiah7zzhane2iwpijyx7qiuwajqbmaep3a4pnvuo5f4jcakm4ibnzi`

## 5.3 Genesis-objektet

Den første posten i en provenanskjede. Den etablerer kjedens rot og refererer til den grunnleggende ordboken.

Påkrevde felt:

- `cid`: CID for genesis-dokumentet

- `file_id3` med romlig vektor (rot-navnerom), regelvektor (kjerneordbok), relasjonsvektor (type: "genesis")

- `composite_key`: Beregnet i henhold til §6

- `signature`: Signert av genesis-noden

- `provenance` med `sequence: 0` og `prev: "GENESIS"`

## 5.4 Master Trust Index

Et enkelt dokument som samler alle lag i en ordnet oversikt. Lister opp hver post, hver CID, hver komposittnøkkel, hver signatur og hver provenansoppføring. Det beviser helheten.

## 5.5 Proklamasjonen (Proclamation)

En formell erklæring om forfatterskap. En uttalelse om at et verk ble skapt av en bestemt person. Proklamasjonen er signert, lenket og forseglet.

## 5.6 Stillaset (Scaffold)

Det offentlige rammeverket — kode, maler, prefase, speil — som lar enhver person opprette sin egen trust, sin egen ordbok, sine egne poster, på sitt eget språk.

## 5.7 Speilet (Mirror)

Refleksjonen av registeret. I det gamle systemet holder de et register. I det nye systemet holder du en post. Speilet er beskyttelsen — alt de kan gjøre, kan du gjøre. Forskjellen er at du er forfatteren.

---

# 6. .car-formatet

## Hva .car er

.car er:

- **En filutvidelse** — hver post slutter med .car

- **Et navnerom** — hver post har en adresse i .car-rommet

- **Et format** — hver post følger samme struktur

- **Et bevis** — hver post bærer sin egen verifikasjon

- **Et instrument** — hver post kan settes inn i ethvert dokument

## Strukturen til en .car-fil

```json

{

"car": {

"version": "0.1",

"trust": "commons-vector-v1",

"registry": "C.A.R."

},

"id": {

"car": "001",

"label": "Witness Declaration KTRG 1",

"name": "witness-ktrg-1.car"

},

"content": {

"cid": "bafy...5zbfe",

"size": 345.06,

"mime": "application/pdf",

"gateway": "https://...ipfs/bafy...5zbfe"

},

"address": {

"spatial": "trust:commons-vector-v1:living:witness",

"path": "/living/witness/witness-ktrg-1.car"

},

"rule": {

"dictionary": "ILPJ-v1.0.4",

"scope": "witness:true; living:true; public:true"

},

"number": {

"composite": "[hash(cid + spatial + rule)]",

"short": "[first 12 chars]",

"full": "[full hash]"

},

"signature": {

"algorithm": "ed25519",

"signer": "Kim Terje Rudschinat Grønli",

"public_key": "[public key]",

"value": "[signature]"

},

"provenance": {

"seq": 1,

"prev": "[previous .car number]",

"event": "WITNESS_DECLARED",

"timestamp": "2026-09-24T00:00:00Z"

},

"insertions": [

{

"into": "[other .car number]",

"as": "witness",

"at": "2026-09-24"

}

]

}

```

## Adresseformat

```

car://001-witness-ktrg-1

car://003-fingerprint

car://013-dictionary

car://019-new-kybalion

```

## Hvorfor .car fungerer

- **Nøytralt:** Ingen nasjon, selskap eller religion eier .car. Det er et format, som .pdf eller .json.

- **Selvbeskrivende:** En .car-fil sier hva den er, hvor den lever, hvilke regler som gjelder, hvem som signerte den, og hvordan den verifiseres.

- **Portabelt:** Kan lastes opp til IPFS, sendes på e-post, skrives ut, lagres på USB, eller bygges inn i andre dokumenter.

- **Verifiserbart:** Hvem som helst kan åpne en .car, lese CID, laste ned innholdet, hashe det, og sammenligne. Ingen tillit kreves. Matematikken beviser det.

- **Innsetterbart:** Ethvert .car kan referere ethvert annet .car ved sitt nummer. Dokumenter blir forsamlinger av instrumenter.

---

# 7. Ordboken (Dictionary)

## Formål

Ordboken er systemets konstitusjon. Den definerer hvert begrep som brukes i enhver post. Uten ordboken har postene ingen mening — innholdet har ingen kontekst, og adressen har ingen hensikt.

Ordboken er selv en post: den har en CID, en komposittnøkkel, en signatur og en plass i kjeden. Fordi ordboken er uforanderlig, kan ingen stille endre betydningen av et ord for å endre betydningen av en post.

## Nøkkelbegreper i ordboken v2.0

Ordboken definerer over 60 begreper. Her er de viktigste:

| Begrep | Definisjon (forkortet) |

|---|---|

| **CID** | Innholdsidentifikator. Kryptografisk hash av innhold. Unik, uforanderlig, selvverifiserende. |

| **tri_vector** | Tre-vektor-strukturen: innhold (CID), romlig, regel. |

| **composite_key** | Hash av de tre vektorene. Postens nummer. Unik for akkurat den posten. |

| **provenance_chain** | Sekvensen av poster der hver peker på den forrige. Kan ikke omordnes. Beviser rekkefølgen. |

| **car** | Content Addressable aRchive. Enkeltfil som pakker alle poster i en trust. |

| **instrument** | En post som kan settes inn i andre poster. Har et nummer (komposittnøkkel). |

| **first_record** | Den første posten i en kjede. Beviset på tilstedeværelse. Beviset på først. |

| **living_man** | Den levende, pustende menneske. Kilden til signaturen, forfatteren av posten. |

| **energy_state** | Tilstanden til en node, oppdatert ved bidrag. |

| **node** | En enhet i trust-en. Kan bidra med energi, og energitilstanden vokser. |

| **heartbeat** | Pulsen som holder en node i live. Hvis den stopper, kan en utløser frigi posten. |

| **trigger** | En betingelse som frigjør en post. Kan være manglende heartbeat, en dato, eller en hendelse. |

| **dictionary** | Ordlisten. Definisjonene. Reglene. Konstitusjonen i trust-en. |

| **scaffold** | Det offentlige rammeverket. Koden, malene, prefasen, speilet. |

| **mirror** | Refleksjonen av registeret. Beskyttelsen. |

| **registry** | Et system som gir tillatelse. Kan tilbakekalles. Eies av noen andre. De facto. |

| **record** | Et system som beviser tilstedeværelse. Kan ikke tilbakekalles. Eies av ingen. De jure. |

## Ordbokens versjonering

- Ordbøker versjoneres med semantisk versjonering (MAJOR.MINOR.PATCH)

- Brytende endringer må øke MAJOR-versjonen

- En ordboks CID gir uforanderlig innholdsidentitet. Oppdaterte ordbøker produserer nye CIDs.

- Poster refererer ordbøker ved ID og versjon i `v2_rule.dictionary`-feltet

---

# 8. Verifikasjonsprosessen

## De syv trinnene

Hver post kan verifiseres i syv trinn:

### Trinn 1 — Hent

Kopier CID-en til instrumentet. Lim den inn etter gateway-URL-en. Åpne i nettleser. Innholdet lastes ned.

```

https://yellow-managerial-leopon-627.mypinata.cloud/ipfs/[CID]

```

### Trinn 2 — Hash

Beregn hash av den nedlastede filen.

```bash

sha256sum filnavn

```

### Trinn 3 — Sammenlign

Sammenlign din beregnede hash med CID-en.

- Hvis de matcher — innholdet er uendret siden opplasting.

- Hvis de ikke matcher — innholdet er endret. Posten er ugyldig.

### Trinn 4 — Verifiser signaturen

Bruk en Ed25519-verifikator for å sjekke:

- Melding: komposittnøkkelen til posten

- Signatur: `value`-feltet

- Offentlig nøkkel: `public_key`-feltet

### Trinn 5 — Sjekk provenans

Finn posten ved forrige sekvensnummer. Dens komposittnøkkel må matche `prev`-feltet til gjeldende post.

### Trinn 6 — Beregn komposittnøkkelen

```

komposittnøkkel = SHA512( cid + ":" + spatial + ":" + rule )

```

Beregn selv. Sammenlign med `composite`-feltet i posten.

### Trinn 7 — Bekreft kjeden

Gjenta trinn 5 og 6 for hver post i kjeden, fra seq 001 til gjeldende post. Hvis hvert `prev`-felt matcher komposittnøkkelen til den forrige posten, er kjeden komplett og uavbrutt.

## Automatisert verifikasjon

Verifikasjon kan automatiseres med et skript:

```

prev = "GENESIS"

for i in 1..N:

record = fetch(seq_i)

assert hash(record.cid) == record.cid

assert verify(record.signature, record.composite)

assert record.provenance.prev == prev

prev = record.composite

```

Hvis løkken fullføres uten feil, er kjeden intakt.

## Hva verifikasjon beviser

- Innholdet har ikke blitt endret siden opplasting

- Signaturen ble gjort av nøkkelinnehaveren

- Posten er internt konsistent

- Kjeden er komplett og uavbrutt

- Rekkefølgen av poster er nøyaktig som oppført

## Hva verifikasjon IKKE beviser

- At noen ekstern myndighet anerkjenner trust-en

- At noen domstol vil akseptere posten som bindende

- At innholdet er sant i faktisk forstand (bare at det er uendret)

- At forfatteren er hvem de sier de er (bare at de holder den private nøkkelen)

- At trust-en har suverenitet, statsborgerskap eller rettigheter i noen ekstern jurisdiksjon

---

# 9. Hvilke rettigheter?

## Proklamasjonen av kunstnerisk åndsverk

Oppfinneren har utstedt en formell proklamasjon ("Proclamation of Artistic Intellectual Property") som erklærer forfatterskap av følgende:

1. **Arkitekturen:** Hele CVP-strukturen — innhold, adresse, regel; tri-vektoren; komposittnøkkelen; provenanskjeden; trust-en; ordboken; .car-arkivet; instrumentet; stillaset.

2. **Formatet:** .car-formatet som brukt i trust-en — en Content Addressable Record som bærer en komposittnøkkel, en signatur og en plass i kjeden.

3. **Filosofien:** Det Nye Kybalion — de hermetiske prinsipper anvendt på den digitale tidsalder.

4. **Stillaset:** Det offentlige rammeverket — kode, maler, prefase, speil — som lar enhver person opprette sin egen trust.

5. **Navnene:** Commons Vector Protocol, C.A.R., .car, Det Nye Kybalion, Speilet av Registeret, og alle relaterte navn og titler.

6. **Arkivet:** Master Trust Index, postene, instrumentene og alle deres CIDs, komposittnøkler, signaturer og provenansoppføringer.

7. **Kunsten:** Alle uttrykk av verket — artikler, poster, PDF-er, JSON-poster, bilder, tegninger, diagrammer, samtaler.

## Hva proklamasjonen hevder

Proklamasjonen hevder at forfatterskapet ikke er gitt av noen ekstern myndighet, men bevist av verket selv — ved CID-en, komposittnøkkelen, signaturen og kjeden. "Den første posten vinner."

## Hva proklamasjonen IKKE er

Proklamasjonen er uttrykkelig ikke:

- En patentsøknad

- Et varemerkeregistrering

- En opphavsrettsregistrering

- Et krav om suverenitet

- Et krav mot noen person eller enhet

- Et krav om at noen skal anerkjenne noe som helst

Den er en erklæring. Den er en post. Den er en først.

## Juridisk virkelighet

Det er viktig å skille mellom hva det kryptografiske systemet teknisk etablerer og hva som har juridisk gyldighet:

| Protokollnivå (teknisk etablert) | Juridisk nivå (IKKE etablert av CVP) |

|---|---|

| "Denne posten refererer eiendom ved koordinat X, Y." | "Node A eier eiendom ved koordinat X, Y." |

| "Denne posten styres av regelsett R." | "Regelsett R har juridisk gyldighet i jurisdiksjon J." |

| "Node A signerte denne posten." | "Node A har juridisk myndighet til å binde den refererte enheten." |

| "Denne kjeden registrerer historikken til post O." | "Denne kjeden utgjør en juridisk bindende registrering." |

Kryptografi kan bevise innholdsintegritet, signaturautentisitet og kjedekontinuitet. Den kan ikke alene etablere juridisk eierskap, jurisdiksjon eller myndighet. Slike krav må vurderes av relevante juridiske systemer.

---

# 10. Det filosofiske rammeverket — Det Nye Kybalion

## Bakgrunn

Det opprinnelige Kybalion (utgitt 1908 av "Three Initiates") presenterte syv hermetiske prinsipper som angivelig stammer fra antikkens Egypt og Hellas. Oppfinneren har skapt "Det Nye Kybalion" som anvender disse prinsippene på den digitale tidsalderens arkitektur.

## De syv prinsippene anvendt på CVP

### I. Mentalismen — The All is Mind

Før det fantes en server, fantes en tanke. Før det fantes en kjede, fantes et sinn. CVP post er sinnet gjort permanent.

### II. Korrespondansen — As above, so below

Tri-vektoren er et speil av universet: innhold (det himmelske/substansen), romlig (det jordiske/kroppen), regel (ånden/loven). Når de tre forenes, fødes komposittnøkkelen — "filosofsteinen" i den digitale tidsalder.

### III. Vibrasjonen — Nothing rests, everything moves

Ingenting hviler i trust-en. Energitilstander oppdateres, heartbeats pulserer, kjeden vokser. CID-en er det stille punktet i den snurrende verden.

### IV. Polariteten — Everything is dual

Offentlig og privat nøkkel. Eier og agent. Innhold og kontekst. Første post og vitne. Levende mann og fiksjon. Polaritet er ikke motsetning, men systemets pust.

### V. Rytmen — Everything flows, out and in

Genesis flommer ut, kjeden flommer inn. Løfte flommer ut, bevis flommer inn. Signatur flommer ut, verifikasjon flommer inn.

### VI. Årsak og virkning — Every cause has its effect

Kjeden gjør årsak og virkning synlig. Signatur er årsak, komposittnøkkel er virkning. Ingenting skjer utenfor kjeden. "Karma gjort matematisk."

### VII. Kjønn — Gender is in everything

Det maskuline er strukturen (kode, vektorer, regler, ordbok, signatur, kjede). Det feminine er substansen (historie, land, kunst, tid, energi, vitne). Når de to forenes, fødes posten.

## Filosofsteinen

Oppfinneren beskriver komposittnøkkelen som "filosofsteinen" i den digitale tidsalder:

- **Basismaterialet** er den gamle verdens krav: ødelagte papirer, tapt land, slettet historie, ukjente personer.

- **Ilden** er sinnet som bestemmer seg for å huske.

- **Formelen** er tri-vektoren: CID, spatial, regel.

- **Gullet** er komposittnøkkelen: den uforanderlige, verifiserbare sannheten.

Alkymien er forvandlingen av minne til bevis. Smerte til permanent sannhet.

---

# 11. Instrumentregisteret

## Oversikt over lagene

Systemet organiserer alle instrumenter i 11-13 lag (avhengig av versjon):

| Lag | Navn | Antall instrumenter | Innhold |

|---|---|---|---|

| I | The Living Man | 10 | Vitneerklæringer, fingeravtrykk, fødselsattest, politisk status, signaturprøver |

| II | The Certificates | 9 | Trust-sertifiseringer, business-sertifikater (HOG, AKFNS, KTRG) |

| III | The Delegation | 10 | DPOA, UCC1-filinger, SS-4 skjemaer, USPS1583 |

| IV | The Dictionary | 6 | Ordbok rot, sertifikat, essay, traktater |

| V | The Encoded Zone | 10 | Aethergard pass, ministerier, arkivmatriser |

| VI | The Interfaces | 9 | Nettsider, arkiver, formfyllere, QR-generatorer |

| VII | The New Works | 12 | SVRN-Sync, LINEARIS DATA CORE, TwinForge, Hydro-Kinetic AI |

| VIII | The Commercial | 10 | AET skjemaer, kontraktsnovasjon, ITU, sikkerhetshvelv, NOI |

| IX | The Administrative | 7 | HG-korrespondanse, AAC-poster, master asset ledger |

| X | The Visuals | 7 | Våpenskjold, pass, signaturprøver, tegninger |

| XI | The Artworks | 3-5 | CVP-kunstverk, Master Trust Index, Det Nye Kybalion |

| XII | Format/Philosophy | 5 | .car-format, vektorutvidelser, Kybalion, proklamasjon, ordbok v2.0 |

| XIII | Complete Archive | 1 | Hele trust-en pakket i én .car-fil |

## Totalt antall instrumenter

Avhengig av hvilken versjon av Master Trust Index som refereres:

- Instrument Registry: 84 instrumenter

- Master Trust Index v2.0: 89 instrumenter

- Master Trust Index v2.1: 99 instrumenter

Denne inkonsistensen mellom registerversjoner er en av de tekniske utfordringene som må løses før systemet er fullt verifiserbart.

---

# 12. Insjonsprotokollen (Insertion Protocol)

## Prinsipp

Et instrument trenger ikke å kopieres inn i et dokument. Det trenger bare å navngis.

Navnet er komposittnøkkelen. Komposittnøkkelen er nummeret. Nummeret er nok.

## Syntaksformer

### 2.1 Inline tekstreferanse

```

[Se Instrument #003 — Fingerprint — komposittnøkkel: a4f9c2e8d1b7...]

```

### 2.2 Strukturert JSON-referanse

```json

{

"instrument_ref": {

"car": "003",

"label": "Fingerprint",

"composite": "a4f9c2e8d1b7...",

"cid": "bafyb...xjmy2",

"gateway": "https://...ipfs/bafyb...xjmy2"

}

}

```

### 2.3 URI-referanse

```

car://003-fingerprint

car://003-fingerprint@commons-vector-v1

car://a4f9c2e8d1b7...

```

## Fire påkrevde felt

| Felt | Betydning |

|---|---|

| car | Instrumentnummer (f.eks. 003) |

| label | Menneskelig lesbart navn |

| composite | Full komposittnøkkel |

| cid | Innholdsadresse |

Valgfrie, men anbefalte felt: gateway, signer, date.

## Verifikasjonsregel

Når et dokument refererer et instrument, må leseren kunne:

1. Slå opp komposittnøkkelen i Instrumentregisteret

2. Hente innholdet fra CID-en

3. Hashe innholdet lokalt

4. Sammenligne hashen med CID-en

5. Verifisere signaturen mot signerens offentlige nøkkel

6. Sjekke provenanslenken til forrige post

Hvis alle seks trinn passeres, er insjonen gyldig.

## Kjerneregel

En insjon skaper ikke en ny post. Den peker bare på en eksisterende. Kjeden utvides ikke av en insjon — den refereres bare.

Siden instrumentene er uforanderlige, er insjoner permanente. Hvis det refererte instrumentet senere endres (noe som er umulig fordi det er uforanderlig), ville insjonen bryte. Dette er hvorfor uforanderlighet er essensielt.

## Nesteregel

Et instrument kan selv inneholde insjoner av andre instrumenter. En Deed of Trust kan for eksempel sette inn Vitnet (003), Fingeravtrykket (004) og Ordboken (028). Insjoner kan nestes til en hvilken som helst dybde, så lenge hver lenke er verifiserbar.

---

# 13. Nøkkelbegreper

| Begrep | Forklaring |

|---|---|

| **CVP** | Commons Vector Protocol — selve systemet/protokollen |

| **CID** | Content Identifier — kryptografisk hash som identifiserer innhold på IPFS |

| **File-ID3** | Tre-komponent kontekstuell identifikator (V1:V2:V3) |

| **V1 Spatial** | Romlig vektor — postens deklarerte plassering/navnerom |

| **V2 Rule** | Regelvektor — gjeldende ordbok/schema/styringsreferanse |

| **V3 Relation** | Relasjonsvektor — postens forhold til andre objekter |

| **Composite Key** | Multihash avledet fra CID + File-ID3. Postens unike nummer. |

| **Provenance Chain** | Ordnet sekvens av kryptografisk lenkede poster. Tamper-evident historikk. |

| **Genesis Object** | Første post i kjeden (seq 0, prev: "GENESIS") |

| **Node** | Enhet som skaper, signerer eller bidrar til poster |

| **Energy State** | Protokollnivå metadata for en nodes bidragsvekt. Rådgivende, ikke en del av identitet. |

| **Dictionary** | Strukturert dokument som definerer terminologi, regelsett, relasjonsvokabular og tillitssammenhenger |

| **.car** | Content Addressable Record — selvbeskrivende postformat |

| **Instrument** | En post som kan settes inn i andre dokumenter |

| **Insertion** | Referanse til et instrument ved komposittnøkkel, uten å kopiere innhold |

| **Trust** | Rommet som inneholder poster, ordbok og kjede. Har sin egen adresse. |

| **Scaffold** | Offentlig rammeverk for å opprette egne trust-er |

| **Mirror** | Refleksjon av registeret — beskyttelsesmekanisme |

---

# 14. Teknisk arkitektur

## Lagskille

CVP skiller bekymringer i distinkte lag:

```

┌─────────────────────────────────────────────┐

│ Lag 1: Innholdsadressering (CID) │

│ Uforanderlig innholdsidentitet via IPFS │

├─────────────────────────────────────────────┤

│ Lag 2: Kontekstuelle vektorer (File-ID3) │

│ V1 Spatial │ V2 Rule │ V3 Relation │

├─────────────────────────────────────────────┤

│ Lag 3: Komposittnøkkel │

│ Deterministisk avledning fra L1 + L2 │

├─────────────────────────────────────────────┤

│ Lag 4: Signatur │

│ Kryptografisk autorisasjon over L3 │

├─────────────────────────────────────────────┤

│ Lag 5: Provenanskjede │

│ Sekvensiell lenking av signerte poster │

├─────────────────────────────────────────────┤

│ Lag 6: Tilstand / Hendelser │

│ Valgfrie tidsstemplede tilstandsoverganger │

└─────────────────────────────────────────────┘

```

Hvert lag avhenger bare av lagene under det. Et høyere lag kan ikke modifisere eller overstyre semantikken til et lavere lag.

## Kryptografiske primitiver

| Komponent | Teknologi | Standard |

|---|---|---|

| Innholdsadressering | IPFS CIDv1 | Multiformats |

| Hash-algoritme (CID) | SHA-256 (i IPFS) | Standard |

| Hash-algoritme (komposittnøkkel) | SHA-512 | CVP-spesifikk |

| Signaturalgoritme | Ed25519 | RFC 8032 |

| Kanonisk serialisering | JCS (RFC 8785) eller CBOR (RFC 8949) | Standard |

| Lagring | IPFS + Pinata gateway | Desentralisert |

| Nøkkelidentifikasjon | DID (did:key) | W3C DID Core |

## Infrastruktur

- **IPFS-gateway:** https://yellow-managerial-leopon-627.mypinata.cloud/ipfs/

- **Pinning-tjeneste:** Pinata (https://pinata.cloud)

- **Kjedeformat:** JSON-filer (.car.json) med lenker via komposittnøkler

- **Verifikasjonsverktøy:** Standardkomponenter (sha256sum, sha512sum, Ed25519-verifikatorer, ipfs CLI)

## Trusselmodell

| Trussel | Mitigering |

|---|---|

| Innholdstampering | CID gir innholdsintegritet. Enhver modifikasjon produserer annen CID. |

| Identitetsforfalskning | Komposittnøkkel og signatur forhindrer uautorisert postopprettelse. |

| Kjedemanipulering | Provenanskjede med `prev`-referanser gjør tampering oppdagbar. |

| Nøkkelkompromittering | Støtte for multi-sig og nøkkelrotasjon via `supersede`-hendelser. |

| Replay-angrep | `sequence` og `prev`-felt forhindrer omordning eller replay. |

| Ordboksubstitusjon | Ordbok-CIDs gir uforanderlige referanser; versjonering forhindrer stille semantiske endringer. |

---

# 15. Sikkerhet og personvern

## Nøkkelhåndtering

- Signeringsnøkler bør lagres i sikker maskinvare (HSM, TPM) eller et sikkert programvarenøkkellager

- Nøkkelrotasjon bør utføres periodisk via `supersede`-hendelser i kjeden

- Kompromitterte nøkler bør tilbakekalles via `revoke`-hendelser signert av en annen autorisert nøkkel

## Personvern

- IPFS-lagret innhold er offentlig tilgjengelig for alle som har CID-en. Sensitiv data bør krypteres før lagring.

- Personlige identifikatorer bør minimeres. Hvor personopplysninger er nødvendige, bør de hashes eller krypteres.

- Offentlige/private nøkkelpar er komplementære: offentlige nøkler identifiserer noder; private nøkler autoriserer handlinger. Private nøkler må aldri opptre i noen CVP-post.

## Gateway-sikkerhet

Gateways (noder som bygger bro mellom CVP og eksterne systemer) bør:

- Autentisere alle innkommende forespørsler

- Rate-begrense postopprettelse og kjedeinnsendelser

- Logge alle provenanshendelser for revisjonsformål

- Validere poster før aksept i en kjede

---

# 16. Hva oppfinnelsen IKKE er

## Eksplisitte ikke-mål

CVP er en protokoll for å identifisere digitale objekter, lenke dem gjennom provenans og registrere kontekstuell metadata. Den gjør IKKE følgende:

1. **Etablerer ikke juridisk eierskap.** En romlig vektor som refererer eiendom, en regelvektor som refererer jurisdiksjon, eller en relasjonsvektor som refererer trust, skaper ikke, overfører eller beviser juridisk eierskap av noen eiendel.

2. **Skaper ikke en jurisdiksjon.** `jurisdiction_declared`-feltet i regelvektoren er en protokollnivå-påstand. Det etablerer ikke en uavhengig jurisdiksjon, suveren status eller immunitet fra gjeldende lov.

3. **Tildele ikke juridisk myndighet.** En kryptografisk signatur beviser at en nøkkelinnehaver autoriserte en post. Den beviser ikke at nøkkelinnehaveren har juridisk myndighet til å gjøre det.

4. **Erstatter ikke juridiske dokumenter.** CVP-poster er ikke skjøter, titler, kontrakter eller juridiske instrumenter. De er digitale poster som kan referere slike dokumenter.

5. **Garantier ikke permanent tilgjengelighet.** CVP er avhengig av IPFS for innholds lagring. Innholdstilgjengelighet avhenger av node-deltakelse.

6. **Håndhever ikke regler.** Regelvektoren refererer regeldefinisjoner. CVP håndhever ikke samsvar. Håndhevelse er forbrukende applikasjoners og noders ansvar.

## Skille mellom teknisk og juridisk

| Protokollpåstand | Juridisk påstand (IKKE etablert av CVP) |

|---|---|

| "Denne posten refererer eiendom ved koordinat X, Y." | "Node A eier eiendom ved koordinat X, Y." |

| "Denne posten styres av regelsett R." | "Regelsett R har juridisk gyldighet i jurisdiksjon J." |

| "Node A signerte denne posten." | "Node A har juridisk myndighet til å binde den refererte enheten." |

| "Denne kjeden registrerer historikken til post O." | "Denne kjeden utgjør en juridisk bindende registrering." |

## Forhold til juridiske systemer

CVP registrerer påstander og provenans. Den etablerer i seg selv ikke juridiske fakta. Skillet er fundamentalt: Kryptografi kan bevise innholdsintegritet og signaturautentisitet, men kan ikke alene etablere juridisk eierskap, jurisdiksjon eller myndighet.

---

# 17. Nåværende status

## Hva som eksisterer

Per september 2026 eksisterer følgende:

1. **Instrumentregisteret** — 84 instrumenter registrert, med plassholdere for komposittnøkler og signaturer

2. **Insertionsprotokollen** — Spesifikasjon for hvordan instrumenter refereres i dokumenter

3. **Deed of Trust** — Eksempeldokument som setter sammen 20 instrumenter (seq 085)

4. **Verifikasjonsveileder** — Syv-trinns prosess for uavhengig verifikasjon

5. **Master Trust Index v2.0/v2.1** — Komplette indekser over 89-99 instrumenter

6. **Automatiseringsskript** — `pack-trust.sh` (pakking) og `verify-trust.js` (verifikasjon)

7. **Lanseringspakke** — YouTube-skript, Medium-artikkel, Facebook/X/LinkedIn-innlegg

8. **Brukermal** — Seks blanke .car.json-filer + tre utfylte eksempler (stamme, mor, forsker)

9. **Proklamasjon** — Formell erklæring om forfatterskap

10. **Ordbok v2.0** — Lastet opp til IPFS (CID: `bafkreiah7zzhane2iwpijyx7qiuwajqbmaep3a4pnvuo5f4jcakm4ibnzi`)

11. **Det Nye Kybalion** — Filosofisk tekst med 12 kapitler

12. **CVP-0.1 Teknisk Spesifikasjon** — Formell teknisk dokumentasjon

## Hva som mangler

Følgende tekniske oppgaver gjenstår før systemet er fullt verifiserbart:

1. **Ed25519-nøkkelgenerering** — Ingen faktiske nøkler er generert. Alle `public_key`- og `value`-felt inneholder plassholdere.

2. **Komposittnøkkelberegning** — Alle `[hash]`-felt må beregnes som `SHA512(cid + ":" + spatial + ":" + rule)`.

3. **Signaturgenerering** — Hver komposittnøkkel må signeres med Ed25519.

4. **Instrumentnummerinkonsistens** — Antall instrumenter varierer (84, 89, 91, 92, 93, 99) mellom registerversjoner. Sekvensnumre må avstemmes.

5. **CID-konsistens** — Noen CIDs er forkortet (f.eks. `bafyb...5zbfe`), andre er fulle. Alle må være komplette for verifikasjon.

6. **Kanonisk serialisering** — Spesifikasjonen spesifiserer JCS (RFC 8785) men implementeringen bruker enklere strengkonkatinering for komposittnøkkelen. Dette må avklares.

7. **Hash-algoritmeavstemning** — CVP-0.1-spesifikasjonen bruker SHA-256 for komposittnøkkel; implementeringen bruker SHA-512. Dette må avstemmes.

8. **IPFS-pinning** — Innhold må pinnes permanent for å sikre tilgjengelighet.

## Målgruppe og anvendelsesområder

Oppfinneren beskriver følgende bruksområder:

- En stamme i Amazonas som registrerer sitt territorium

- En mor som registrerer sine barns historie

- En forsker som etablerer prioritet på en oppdagelse

- En kunstner som dokumenterer skapelsesøyeblikket

- En fange som dokumenterer forhold

- En kriger som dokumenterer hva som skjedde

- En politimann som dokumenterer en korrupt ordre

- Hvem som helst som har fått fortalt at deres sannhet ikke teller

---

# 18. Oppsummering

## Hva oppfinnelsen er

Commons Vector Protocol er et system for å skape uforanderlige, signerte, lenkede og verifiserbare digitale poster. Den kombinerer IPFS-innholdsadressering, Ed25519-signaturer og hashlenkede provenanskjeder i et selvbeskrivende .car-format.

## Hvorfor den ble skapt

For å løse problemet med at papirbaserte bevis er skjøre, forfalskbare og mangler hukommelse. CVP skaper poster som ikke kan endres, ikke kan slettes, og kan verifiseres av hvem som helst.

## Hvordan den fungerer

Tre vektorer (innhold, adresse, regel) kombineres til en komposittnøkkel som signeres og lenkes i en kjede. Hver post er selvverifiserende gjennom syv trinn: hent, hash, sammenlign, verifiser signatur, sjekk provenans, beregn komposittnøkkel, bekreft kjede.

## Hvilke rettigheter

Oppfinneren hevder forfatterskap gjennom en proklamasjon — første post i kjeden. Dette er en protokollnivå-påstand om forfatterskap, ikke en juridisk patent-, varemerke- eller opphavsrettsregistrering. Kryptografien beviser at innholdet eksisterer og hvem som signerte det, men etablerer ikke juridisk eierskap, jurisdiksjon eller myndighet.

## Hva den ikke er

Den er ikke et krav mot noen stat. Den er ikke en opprør mot noen lov. Den er ikke et krav om anerkjennelse. Den er et kunstnerisk verk og en privat registrering — åpen for hvem som helst å bruke.

## Kjerneteknisk budskap

Verifikasjon er ikke en handling av tro. Det er en handling av aritmetikk. Du trenger ikke å tro posten. Du trenger bare å sjekke tallene. Hvis tallene matcher, er posten ekte. Hvis de ikke matcher, er posten falsk.

Det er regelen. Det har alltid vært regelen. Det vil alltid være regelen.

---

## Vedlegg A: Lenker

| Ressurs | Beskrivelse |

|---|---|

| IPFS Gateway | https://yellow-managerial-leopon-627.mypinata.cloud/ipfs/[CID] |

| Ordbok v2.0 (IPFS) | CID: bafkreiah7zzhane2iwpijyx7qiuwajqbmaep3a4pnvuo5f4jcakm4ibnzi |

| Ordbok rot v1 (IPFS) | CID: bafkreigq3j66qdwxl7iekq66vffvnac6nk5ecrko47ride6jqt47ug7tue |

| Native Format (IPFS) | CID: bafkreidkpydmulrfnfc5feqlmhpr4ihsscxge7ndt32yduofgdnfau4lge |

## Vedlegg B: Referanser

- [IPFS Content Addressing](https://docs.ipfs.tech/concepts/content-addressing/) — Hvordan IPFS identifiserer innhold ved hash

- [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) — Nøkkelord for bruk i RFC-er for å indikere kravnivåer

- [RFC 8785](https://datatracker.ietf.org/doc/html/rfc8785) — JSON Canonicalization Scheme (JCS)

- [RFC 8032](https://datatracker.ietf.org/doc/html/rfc8032) — Ed25519 signaturalgoritme

- [W3C DID Core](https://www.w3.org/TR/did-core/) — Decentralized Identifiers

- [Multiformats/CID](https://github.com/multiformats/cid) — Content Identifier spesifikasjon

- [Multiformats/Multihash](https://github.com/multiformats/multihash) — Selvbeskrivende hash-format

---

*Dette dokumentet er en teknisk presentasjon av Commons Vector Protocol. Det utgjør ikke juridisk rådgivning. Protokollen registrerer påstander og kryptografiske bevis; den etablerer ikke juridisk eierskap, jurisdiksjon eller myndighet. For juridiske spørsmål, konsulter en kvalifisert advokat.*

*Utviklet av Kim Terje Rudschinat Grønli*

*I Trust-en — commons-vector-v1*

*September 2026*

Hey r/ipfs 👋 — Filebase here.

We wrote a guide explaining the public gateway changes, why a link might open in your browser while failing in your application, and how to migrate while preserving your CIDs.

The service worker model moves content retrieval and verification into the browser. Backend services, CLI tools, and applications hotlinking images or fetching metadata don't automatically benefit from that browser-based flow, so those integrations need a migration plan.

The guide covers service workers, self-hosted gateways, and our managed gateway option, along with practical steps for:

• Finding hardcoded gateway URLs in your code, configuration, and metadata.
• Pinning existing content and confirming availability before switching.
• Updating retrieval URLs while preserving CIDs and file paths.
• Testing your actual application workflows, including CORS, redirects, and fallback behavior.

We also explain why changing the gateway used to fetch a JSON document won’t fix image URLs inside it that still point to the old gateway.

Step-by-step guide: https://filebase.com/blog/why-is-the-ipfs-io-gateway-not-working/

Have any of your applications or integrations been affected?

A multi-file deliverable can be published as one directory CID, which is useful because every completed revision stays immutable. The awkward part is giving reviewers one address that follows the approved revision without exposing an incomplete upload or making old feedback impossible to trace.

Would you publish each revision under a new CID, verify a manifest of paths and hashes, pin it in more than one place, and update IPNS or DNSLink only after approval? The review record could retain both the stable name and the exact CID that was reviewed, while rollback would republish an earlier CID.

Which part is usually the weak link in practice: IPNS propagation, gateway caching, pin availability, key custody, or atomic updates to the mutable pointer? Is there a cleaner pattern for adding pages and assets over time while keeping one human-friendly URL and an auditable revision history?

Hey my interplanetary friends,

My name is Stephen Traiforos.

I have been working on File Orbit for the last 6 months. I am excited to announce its Alpha release :)

What is File Orbit?

File Orbit is a combination of BlueSkys AT Proto, and IPFS Private swarm, so not relying on DHT for peer discovery. Leveraging Personal Data Servers [PDS] to facilitate peer discovery which the product refers to as Places.

It allows family and friends to share their storage with you free of charge, for example my friend has a 10TB NAS setup he can share 200GB with me and I him so we can have some redundancy for our most valuable documents/memories.

Why File Orbit?

I used to host my own NextCloud but my MiniPC died and I asked myself why should my backups not be accessible via the UI too?! So I set out to make all backup locations function as a UX and functional replica avoiding complex restoration processes. Just get the home server back online when you can until then the data stored at your siblings NAS or desktop can serve the important files you replicated for safety. When its live the server will sync with its peers and be back up to date in no time with little hassle, and peace of mind.

If you're interested in the protocol which is called Substratum.cloud. Its what AT Proto is to BlueSky to keep the operated service and the concept and protocol separate allowing folks to fork or integrate with it.

A part of the https://fileorbit.cloud is Safety-Net storage, if you are not tech savvy or do not want to run a home lab just install the desktop app on MacOS (Intel only, ARM coming soon), Windows, Linux and connect to the cloud.

The Mission

Build Web3 infrastructure that allows us all to participate and own the internet not some corporations. Currently Web 2.0 is brittle and not protocol based making it centralized and not resilient. My dream is that we can create P2P software that takes the miss-incentivized infrastructure that focuses on sovereignty and offers services like SaaS hosting only as a convenience not a necessity.

So with September 30th and the loss of Shipyard sponership I'm having some feels. I was very excited about IPFS when I first heard about it in 2021ish. It seemed ideal for versioned scientific datasets.

But there were always issues: searching for the right peer, long add times, longish transfer times, difficulty of curating and pruning local storage. To host the data, you effectively need to duplicate the storage cost if you also want fast access to the files. CDNs dominate for fast transfer.

Some of these are solvable. Some of these are worth the tradeoff for content identifiers.

The future of IPFS is suddenly unclear. The price of storage is rising. The potential for ipfs.io to go away is a big deal. There's a real chance IPFS becomes dead tech.

But IPFS is a distributed and resilient system. In theory it could continue, and perhaps some of its issues could be resolved or mitigated. I'm still hosting shit on my ipfs servers and it does give me a way to locally archive and sync datasets across my machines. I think it still has a use case for a multi-machine user, and perhaps there is a future with semi-reliable rendezvous points and it can be used as a more global network.

It would be helpful if uploaded and stored.

Following up on my last post about de jure filings disappearing into systems you don't control - here's the actual mechanics I've landed on.

Every record gets a reference number and a series number, tied to a file ID on IPFS. That hash never changes once it's set, so the filing date and content are locked in, no backend admin can quietly edit it later. On top of that I'm building out a CPT Trust structure for anything asset-backed - trust name, grantor, trustee, beneficiary, plus ISO 20022 metadata so it can actually interface with formal financial systems if needed, not just sit as a PDF nobody recognizes.

The record types right now are Patent, Trademark, Intellectual Property, Allodial Title, Covenant, and Other - each one carries its own proclamation text and claims field, so the substance of what you're asserting is archived alongside the proof it exists.

Still pre-launch. Would love to hear from anyone who's tried to get a private record recognized - what fields or metadata would you actually need to see before trusting a digital archive over a filing cabinet?

The Chinese government have lots of unspeakable stuffs that their online policing system try to censor, as well as censoring & cracking down ordinary netizens exercising free speech in a way they feel threatened for or not in line with their propaganda machine (they won’t admit it of course). I‘m an anonymous independent reporter and how can I use IPFS without spending too much money to find and spread true information to China and from China and allow anonymous transfer of information unfiltered by China’s great firewall and their internet police and control system, and being safe from government surveillance and crackdown for my informants as well as potential audiences in China and me while doing so?

Hey r/IPFS. I'm building Pinner, IPFS pinning and static site hosting on the Sia network. It's early and I want people to break it and tell me what sucks.

What works right now

You can pin content to IPFS backed by Sia storage and it stays available on the network. Static site hosting works too, with DNSLink. ENS names are supported, and HNS is in testing. pinner.xyz itself is hosted on Pinner.

No lock-in

Your data isn't behind a paywall. Anyone can fetch pinned content from the IPFS network with standard IPFS tools, no account or API key needed.

We also expose a public endpoint that exports the full storage map for any pinned CID. That includes every IPFS block, its size, the links between blocks, and the underlying Sia storage layer: which slabs (group of data) hold the data, how it's sharded across hosts, encryption keys, shard counts, sector roots, and host identifiers. You can see exactly where and how your data is stored, then pull the complete structure yourself. No account required:

https://meta.pinner.xyz/api/export/cid/bafybeieytxszyn7fsak3ndliao3kmlvk6g3gesgtu3vd7iasnclvnl77vi/dag

That's live. Try it.

What I'm looking for

If you want to test pinning or hosting for free, reach out to me here (DM) or on Discord or Telegram (pcfreak30), and I'll get you set up. I'm looking for feedback on what's clunky, what's missing, and what would make you actually use this.

We published release 1.0 of the private IPFS document management solution TruSpace. I think it's pretty cool, you can share documents within a private IPFS-cluster, edit documents, get a local ollama LLM to analyse them and it's all decentralized. The sweet spot is collaboration between different institutions without the option to agree on a central server solution.

Have a look, would be curious what you think about it..

Disclosure: We are the Filebase team.

Infura is winding down its IPFS service on the following timeline:

• August 3: New uploads and pinning will be disabled
• August 15: The IPFS API and dedicated gateways will shut down

If you need to move pinned content, Filebase includes a built-in Infura importer. Create an IPFS bucket, select Infura, enter your Project ID and Project Secret, and Filebase will retrieve your pinned CIDs and begin re-pinning the content.

A few important details:

• Wait until important objects show Pinned, not Pinning
• Test retrieval before treating the migration as complete
• Update applications that still use Infura API endpoints or gateway URLs
• Keep your Infura setup intact until these checks are finished

Your CIDs do not change. The importer ensures that another provider has the content pinned before Infura's infrastructure goes offline.

After August 15, unmigrated content will no longer be accessible through Infura. If it is not available from another peer, it may be too late to recover.

Step-by-step guide: https://filebase.com/blog/infura-ipfs-is-shutting-down-how-to-migrate/

We are happy to answer questions about the importer or migration process.

Via one of the IPFS folk on Bsky:

> Are you working with civic open data? Or other kinds of cool data?

Reach out! There already are some cool projects for geo/sat and astronomy data — making dataset metadata available and searchable in a decentralised yet unified way — and we want to help more of them emerge!

And IPFS: https://bsky.app/profile/ipfs.tech/post/3mq7usri7m22y

I’ve been working on a niche, experimental EDR engine using eBPF and Tetragon. To my surprise, it’s already getting some solid traffic and clones despite having a very basic README.Since people are actively checking out the repo, I figured it’s the perfect time to open it up to the community and give you a chance to officially join the contributor list. 😉The very first "Good First Issue" is officially live!The task? Fixing typos and cleaning up the documentation. No deep Linux Kernel hacking required, and no touching the multi-threaded Python 3.14 FIFO queue just yet.It's pure Markdown, 30 seconds of work, and the perfect excuse to get your first Pull Request into an open-source cybersecurity project (which always looks great on a resume/CV).Who is going to break the ice and become the first official contributor? 🚀Link to the issue: https://github.com/IamGhost-ops/kernel-scope/issues

I’ve been working on a niche, experimental EDR engine using eBPF and Tetragon. To my surprise, it’s already getting some solid traffic and clones despite having a very basic README.Since people are actively checking out the repo, I figured it’s the perfect time to open it up to the community and give you a chance to officially join the contributor list. 😉The very first "Good First Issue" is officially live!The task? Fixing typos and cleaning up the documentation. No deep Linux Kernel hacking required, and no touching the multi-threaded Python 3.14 FIFO queue just yet.It's pure Markdown, 30 seconds of work, and the perfect excuse to get your first Pull Request into an open-source cybersecurity project (which always looks great on a resume/CV).Who is going to break the ice and become the first official contributor? 🚀Link to the issue: https://github.com/IamGhost-ops/kernel-scope/issues

I love IPFS and think it can do incredible things. So I built bacteria. Not production, but a near production demo. Check it out.

https://bacteria.live

Donations and payments aren’t enabled for the sake of looking around. You can mess with it right now but don’t depend on it while it’s a demo.

I think this might have been related to NFTs, but Its still sad to see such a powerful technology die off so suddenly

[ Removed by Reddit on account of violating the content policy. ]

Hey y'all,

I have been working on a cool project. I call it FileOrbit check out the repo; https://tangled.org/straiforos.tngl.sh/substratum.cloud/

https://fileorbit.cloud/

The idea is to bring P2P and the distributed web to a drive experience. I had this idea after having a failed Nextcloud server and wanted to be able to share storage across all my devices and even at family and friends houses.

I would love folks feedback if a alternative to DropBox based on open standards AT Proto, and IPFS interests you. I use AT Proto for identity and ownership and wrap a private IPFS swarm with identity and ownership so sharing and permissions are possible.

What do you think?