Begin dit jaar kondigde Brave aan dat zijn desktopbrowser IPFS ging ondersteunen. Dit zal nog niet iedereen wat zeggen, maar Interplanetary File System is een belangrijke stap voor voorstanders van een gedecentraliseerder web. Het is niet de eerste stap, want Cloudflare zette in 2018 al een IPFS Gateway op en vorig jaar maart maakte Opera bekend IPFS bij zijn Android-browser te ondersteunen. De aandacht voor de technologie groeit en daarom wordt het eens tijd dit p2p-netwerk voor internet en dan met name het web onder de loep te nemen.
IPFS is dus een bestandssysteem, een systeem dat regelt hoe data opgeslagen en opgehaald wordt. Offline doen NTFS voor Windows, ext4 voor Linux en APFS voor macOS bijvoorbeeld hetzelfde. Systemen om bestanden via netwerken te kunnen benaderen zijn er ook al sinds de jaren tachtig van de vorige eeuw, zoals Network File System en Server Message Block. Die bestandssystemen voor netwerken werken nog op de traditionele wijze: er is een client en die wil toegang tot data opgeslagen op een server.
Zo werken veel technieken die gebaseerd zijn op het klassieke model van internet ook. Denk bijvoorbeeld aan het Hypertext Transfer Protocol voor het web. Als je een url intypt in je browser, vraagt je browser als client via een HTTP-request de data op van een adres dat behoort bij de website van de url. Die data is opgeslagen op een server. Die stuurt de data, zoals HTML-bestanden, terug naar de client. Er kunnen verschillende tussenstations zijn, zoals proxies of zoals relaynodes in het Tor-netwerk, of de data kan versneld via een webcache geleverd worden, maar het principe blijft hetzelfde: de opgevraagde data is opgeslagen op een centraal punt.
De problemen met centrale servers
Dat klassieke model van internet is enorm succesvol geweest en heeft bijgedragen aan de jarenlange groei van internet en ook van het web op dat internet. Het heeft geleid tot een complex en wijdvertakt netwerk. Dat is dankzij zijn vele routeringmogelijkheden bestand tegen uitvallen van delen ervan: het maakt niet uit hoe je tot het uiteindelijke eindpunt komt, zoals de centrale server. Als je er maar komt. Toch heeft dit model ook tal van negatieve eigenschappen, die de laatste jaren steeds meer aandacht krijgen.
Want de beschikbaarheid van veel websites en informatie is zo afhankelijk van de aanwezigheid van de corresponderende data op een enkele plek, de uiteindelijke server. Wat als die server offline gaat, de data gewist wordt of een ddos-aanval de server platlegt? Berucht is het voorbeeld van GeoCities. Yahoo trok in 2009 de stekker uit die dienst waardoor in een klap 38 miljoen GeoCities-websites voorgoed dreigden te verdwijnen. Hetzelfde leek in 2013 met de bijna 14 miljoen torrentbestanden van IsoHunt te gebeuren toen die site op de knieën gedwongen werd en dichterbij huis was het Hyves dat een gapend gat in de Nederlandse internetgeschiedenis dreigde achter te laten. Inderhaast kwamen ArchiveTeams in actie om die data van GeoCities, IsoHunt en Hyves te redden. Die staat nu bij het Internet Archive, maar de vraag is hoe toekomstbestendig de afhankelijkheid van die organisatie is voor het archiveren van relevante delen van zo'n beetje het hele internet.

Er zijn meer problemen met de client-server-opzet. Regimes of bedrijven kunnen de toegang tot voor hen gevoelige of ongewenste gegevens makkelijk blokkeren, zoals we in de afgelopen jaren hebben gezien. In landen met een matige infrastructuur kan het lang duren voor bestanden binnengehaald zijn, waardoor er een groot verschil is tussen de internetervaring in welvarende landen en de rest van de wereld. Dat is helemaal het geval als bestanden een lange afstand via netwerken moeten overbruggen. Last but zeker not least: de distributie van content vanaf centrale plekken brengt hoge kosten met zich mee als het om grote hoeveelheden data gaat. Dat heeft er voor gezorgd dat praktisch gezien alleen een handjevol techgiganten nog bepaalde diensten kunnen aanbieden. Alleen onderling lijken ze nog te kunnen concurreren met video-, game-, app-, muziek- en opslagdiensten.
/i/2003262568.jpeg?f=imagenormal)
Van Global naar Galactic naar Interplanetary
:fill(white):strip_exif()/i/2004156320.jpeg?f=imagemedium)
Die problemen staan al jaren op de radar van organisaties die streven naar een decentraal web, of DWeb, of Web3. In de praktijk gaat het daarbij overigens vaak om een gedistribueerd netwerk in plaats van alleen decentraal. Een van die organisaties is in ieder geval Protocol Labs. De oprichter van Protocol Labs is Juan Benet, die tijdens zijn studie computerwetenschappen aan Stanford geïnspireerd raakte door het succes van de peer-tot-peernetwerken van begin 2000, zoals Napster, Gnutella, BitTorrent en Skype. In 2013 bedacht hij dat een beter systeem voor het delen van datasets en het bijhouden van versies van datasets mogelijk moest zijn, door de voordelen van het versioning-systeem van Git te combineren met mogelijkheden van BitTorrent. Dit systeem zou als aanvulling op HTTP moeten dienen. Volgens Benet is HTTP weliswaar het succesvolste gedistribueerde systeem van bestanden tot nu toe, maar is het niet geschikt voor de huidige uitdaging van 'heel veel data, altijd beschikbaar'. In 2014 publiceerde hij daarop een whitepaper met zijn oplossing: het Interplanetary File System. Aanvankelijk koos hij overigens de naam Global File System, maar dat bestond al waarna de keuze op Galactic File System viel, maar ook de afkorting GFL bleek al in gebruik. De uiteindelijke naam is nog steeds een hommage aan Intergalactic Computer Network van begin jaren zestig, een van de eerste concepten voor een datanetwerk, bedacht door J.C.R. Licklider.
Benets ambities waren groot. Volgens hem kon IPFS het wereldwijde web veranderen. De basis van het systeem ligt in content adressing, in tegenstelling tot location adressing bij HTTP. Met andere woorden: IPFS richt zich bij het opvragen van de content niet op de locatie van de content of waar in een netwerk die data opgeslagen is, zoals een webserver met een bepaald adres en domeinnaam. In plaats daarvan adresseert het systeem de content zelf, op basis van een cryptografische hash, ongeacht waar de data zich in een netwerk bevindt.
In zijn paper beschrijft Benet het combineren van enkele techieken om IPFS mogelijk te maken. Het systeem gebruikt distributed hash tables voor het beheer van metadata bij het p2p-systeem en BitTorrents technieken voor het uitwisselen van datablokken. Het neemt enkele verdere eigenschappen van BitTorrent over zoals het belonen van nodes die bijdragen in een netwerk en het geven van prioriteit aan 'zeldzame' bestandsdelen bij het ophalen van data, om seeders die hele bestanden aanbieden vervolgens te kunnen ontlasten. Daarnaast gebruikt het beheer van publieke en privésleutels van Self-Certified Filesystem of SFS, een gedistribueerd bestandssysteem dat in 2000 ontwikkeld werd en waarbij bestanden te adresseren zijn via een pathname dat begint met /sfs/location:hostid. De locatie is bij SFS het ip-adres of de domeinnaam en hostid is een hash die mede gebaseerd is op een publieke sleutel. Hiermee is het sleutelbeheer losgetrokken van het bestandssysteem en clients kunnen beveiligde verbindingen opzetten zonder eerder van de server gehoord te hebben.
De werking van IPFS
Grofweg gezien bestaat de verdere uitwerking van IPFS uit vier onderdelen. Het eerste is het adresseren van content via een unieke identificatie, de Content Identifier, of CID. Daarnaast is er een systeem voor het structureren van data-objecten met de naam Interplanetery Linked Data en tenslotte zijn er de distributed hash tables voor het kunnen vinden van content en BitSwap voor het ophalen van datablokken.
Stel, je wilt content publiceren op IPFS. Dat kan om van alles gaan, van video en websites tot applicaties, enzovoorts. De eerste stap is dan dat deze data lokaal op je eigen systeem wordt opgedeeld in chunks. Identieke chunks worden later in het netwerk als redundant beschouwd en via deduplicatie verwijderd voor efficiënte transfers. Bij corrupte chunks hoeft niet het hele bestand opnieuw opgevraagd te worden, alleen dat stukje. Vervolgens krijgen alle bestanden van de content een CID, dit is een hash met metadata, om een naam te geven aan elk databestand in een netwerk. Die pointer is permanent: als je als gebruiker die CID opvraagt, krijg je ook altijd dat bijbehorende bestand en geen ander bestand. De hashes maken het dus meteen verifieerbaar dat het ook echt om de bestanden gaat die een gebruiker moet hebben. In feite gaat het om een multihash: een hash met prefixes. Dit maakt het onder andere mogelijk over te stappen op andere hashingalgoritmes dan het gebruikte SHA-256 en maakt ook het interpreteren van de data mogelijk. Zo is te interpreteren of het bij de data om bijvoorbeeld Bitcoin, Ethereum of JSON gaat.
De hashes komen vervolgens in een Merkle DAG-datastructuur, vergelijkbaar met het objectenmodel van Git. De Merkle DAG of Merkle Directed Acyclic Graph is een boomstructuur met stam, vertakkingen en blaadjes en het verschil met een traditionele Merkle-boomstructuur is dat de 'blaadjes', de deelbestanden, aan meerdere 'stammen' gelieerd kunnen zijn. Anders gezegd: de hashes van versies van hoofdbestanden of mappen, bij IPFS de Root CID van een node, zijn het gevolg van die van deelbestanden. De hashing werkt dus van onder naar boven. Als een bestand onderaan de structuur gewijzigd wordt, wijzigt die hash, maar ook de bovenliggende hashes van hoofdbestanden of mappen en zelfs die van versies van die hoofdbestanden of mappen.
IPFS bouwt die Merkle DAG-datastructuren op met zijn Interplanetery Linked Data-techniek en het doel is dus om alle onderdelen van bestanden en mappen adresseerbaar te maken, niet alleen de root-CID, de hoofd-identifier van de video, website, wetenschappelijke paper, presentatie, applicatie, maar ook eventuele onderdelen daarvan. Dat maakt het bijvoorbeeld mogelijk certificaten aan te spreken of transactiegegevens die onderdeel zijn los te adresseren en toe te voegen aan een blockchain.
Als je de content vervolgens op het IPFS-netwerk publiceert, kunnen anderen deze ophalen en via hun cache dat bestand ook beschikbaar maken. Zo ontstaat een netwerk van caches voor de content. Ze kunnen die content vastpinnen om deze beschikbaar te houden, als ze dat niet doen maakt garbage collection dat deze automatisch verwijderd wordt. Vereist is het bijhouden wie in het netwerk welke CID heeft. IPFS gebruikt daarvoor een routing table die gedistribueerd is onder de gebruikers door middel van distributed hashing tables, waarbij Kademlia gebruikt wordt om bij te houden wie weet wie welke CID heeft. Kademlia zorgt er ook voor dat gebruikers de content krijgen van de peers die het dichtst in de buurt zijn voor snelle overdrachten.
Alle bestanden op het netwerk hebben nu een unieke identifier, ze zijn opgedeeld en beschikbaar gemaakt en gedeeld over een netwerk; dan resteert het probleem met het ophalen ervan. Hiervoor is Bitswap verantwoordelijk. Dit is een protocol dat nodes gebruiken om verlanglijstjes te sturen naar peers. Dit zijn lijstjes met root-CID's, oftewel de content, die ze willen ontvangen. Via want-have-requests en don't-have-antwoorden kunnen ze zo aangeven wat ze willen, hebben en niet hebben. Als geen van de peers de CID's hebben, vraagt Bitswap aan de distributed hash table wie die wel hebben.
Zelf IPFS gebruiken
Als je zelf een IPFS-node wilt draaien en zo bijvoorbeeld content beschikbaar wilt maken of downloaden, kan dat via de command-line of een programma voor macOS, Windows of Linux. In aanvulling daarop kun je een add-on gebruiken voor Chrome, Edge, Firefox en Opera. En zoals hiervoor gezegd heeft Brave vanaf versie 1.19 standaard ondersteuning voor IPFS. Gateways maken het mogelijk om met IPFS via de browser contact te maken. Protocol Labs heeft zelf de gateway https://ipfs.io, maar derde partijen zoals Cloudflare kunnen ook gateways aanbieden. Er is een lijst beschikbaar van publieke gateways.
Bij het gebruik van IPFS zul je merken dat het systeem datapaden gebruikt en geen url's en dat de namen door het gebruik van de hashes te lang zijn om te onthouden en niets zeggen over de content, zoals ipfs://QmY6pHjpF9HeruZJwBdBt9mXsN6FokhpcDva71NyPvuatd. Browsers die IPFS ondersteunen kunnen bestanden ophalen van paden met /ipfs/{cid}. Ook kunnen ze overweg met protocollen als ipfs://, ipns:// en dweb:. Zo opent de browser een snapshot van Wikipedia via IPFS bij het invoeren van het datapad ipns://en.wikipedia-on-ipfs.org/wiki/.
Wikipedia was een van de eerste sites die via een snapshot beschikbaar kwam via het online bestandssysteem, als onderdeel van het Distributed Wikipedia Mirror-project. Dat gebeurde in 2017 toen de encyclopedie geblokkeerd werd in Turkije. Protocol Labs gebruikte het als showcase voor het netwerk, waarbij het de voordelen bij censuur benadrukte: er is maar één node in een netwerk nodig om de content voor iedereen beschikbaar te maken.
Aangezien IPFS een bestandssysteem is, is het voor veel meer dan alleen websites te gebruiken. Bedrijven kunnen het voor tal van diensten en applicaties inzetten en daarbij voordeel halen uit de mogelijkheden met loadbalancing, caching, deduplicatie en het ontlasten van servers. Een logische toepassing is de inzet voor een Content Delivery Network, zoals Netflix die momenteel heeft in samenwerking met providers. Het kan ook ingezet worden als onderliggend systeem voor messagingplatforms, zoals Berty.tech, dat ook op lokale netwerken en via bluetooth werkt. Videoplatform DTube gebruikt het om de belasting op zijn servers te verlichten en PeerPad.org maakt het samenwerken aan opgeslagen documenten mogelijk. De Amerikaanse fabrikant KODA ontwikkelt een robothond met de naam Koda-9 die onder andere beveiligingsbeelden gedecentraliseerd opslaat. Daarnaast wordt er gewerkt aan gedistribueerde, serverloze databases. Zo gebruikt OrbitDB IPFS. Ook is er een extensie voor Nextcloud waarmee gebruikers externe opslag op IPFS kunnen inzetten. IPFS is te combineren met Ethereum voor distributed apps, of dapps, waarbij de frontend op IPFS opgeslagen is en de back-end, of smart contract, op de blockchain van Ethereum.
Die flexibiliteit maakt meteen het verschil met BitTorrent inzichtelijk. Ook dat is natuurlijk een gedistribueerd opslagsysteem, dat eveneens in combinatie met browsers en voor het ontlasten van servers kan werken. BitTorrent breekt bestanden 'domweg' op in gelijke blokken, maar IPFS kan dankzij de Merkle DAG-structuur afzonderlijke bestanden of subsets van content in een map adresseren en verbinden aan andere nodes, wat de mogelijkheden aanzienlijk vergroot.
Problemen met IPFS
Dat betekent niet dat er geen openstaande problemen met IPFS zijn. Het systeem vergt momenteel veel bandbreedte, ondanks deduplicatie en andere technieken om de efficiëntie te verbeteren. Standaard is het weliswaar mogelijk om met behulp van publieke en private sleutels te garanderen dat je bestanden van een betrouwbare bron ontvangt, en dankzij hashing weet je ook dat dit ook echt de juiste bestanden zijn, maar voor nodes en relayservers is geen authenticatie, wat een beveiligingsrisico is.
Dan is er nog het probleem van het updaten van de content. Bij elke update van een onderdeel van een bestand of map, maakt IPFS een nieuwe CID aan. Gebruikers moeten op de hoogte gesteld worden van die nieuwe CID, aangezien de oude blijft bestaan. De oude CID vervangen op de locatie door de nieuwe is niet aan de orde, want het hele idee is dat IPFS bestanden lokaliseert op basis van de content zelf. De oplossing tot nu toe is het Interplanetary Naming System, dat maakt dat steeds dezelfde pointer gebruikt kan worden bij updates van bestanden. Dit systeem doet dat door naar een identifier van de peer te verwijzen: die verandert dus niet, ook als de hash van het gezochte bestand wel wijzigt. Het probleem is dat InterPlanetary Naming System traag werkt.
Sowieso is het natuurlijk niet handig gebruikers te verwijzen naar bestanden met als naam de hash, zoals ipfs/QmbezGequPwcsWo8UL4wDF6a8hYwM1hmbzYv2mnKkEWaUp. Daar is dan weer DNSLink voor bedacht, dat voor een koppeling tussen dns en IPFS zorgt. De link in de dns-records van een domein maakt dat gebruikers met een eenvoudige naam doorverwezen kunnen worden naar de hash. In combinatie met het Interplanetary Naming System komt dat de snelheid echter ook niet ten goede.
Een fundamenteel probleem is dat er veel nodes vereist zijn om het systeem te laten werken, maar waarom zou je een node opzetten om bestanden van anderen te cachen en uit te serveren? De oplossing die daarvoor bedacht is, ligt bij, hoe kan het ook anders, cryptovaluta. Gebruikers kunnen Filecoin gebruiken om cryptocoins te verdienen als incentive om nodes voor opslag op te zetten. Filecoin-nodes zijn automatisch IPFS-nodes, maar een IPFS-node hoeft geen Filecoin-node te zijn. Filecoin-gebruikers bieden in feite opslagcapaciteit voor bijvoorbeeld grote hoeveelheden data en voor langere tijd aan, en krijgen daarvoor betaald.
/i/2004156254.png?f=imagearticlefull)
Tot slot
Over aandacht heeft het Interplanetary File System niet te klagen. De integratie in Brave heeft het project een nieuwe impuls gegeven. Een groot deel van de bedrijven en projecten die werken met het systeem, komen uit de hoek van voorstanders van decentralisatie van internet en Web 3.0, maar ook bij andere partijen groeit de interesse. Zo werkte Protocol Labs vorig jaar samen met Netflix aan verbeteringen voor Bitswap. Met de release van IPFS 0.5.0 richtte het project zich op het verbeteren van de snelheid van de routering, dus aan de problemen met het systeem wordt actief gewerkt. In 2019 werd IPFS door 'honderdduizenden' mensen gebruikt en gateways ontvingen gemiddeld zo'n 13 miljoen requests per dag voor dagelijks in totaal 5TB. Recentere cijfers kon het project Tweakers nog niet geven, maar het lijkt waarschijnlijk dat die cijfers flink gestegen zijn. Koersstijgingen van Filecoin zoals die begin februari plaatsvonden kunnen daarbij natuurlijk helpen. Tegelijkertijd gaat het nog duidelijk om technologie die zich in de kinderschoenen bevindt en zijn er tekortkomingen met snelheid, gebruikersvriendelijkheid en massa-adoptie te overwinnen. Ongeacht of internet verandert naar iets wat je met hippe termen Dweb of Web 3.0 zou kunnen noemen, kan IPFS een rol spelen bij hoe we in de toekomst omgaan met de opslag van grote hoeveelheden data en hoe grote en kleine partijen content kunnen publiceren.