We hadden het netjes voor elkaar. Een blogpost met een video die rechtstreeks van IPFS geladen wordt — geen YouTube, geen CDN, gewoon inhoud die van het netwerk komt. Toen deelden we hem op LinkedIn. En daar viel het om.
Geen video. Geen voorbeeldweergave. Een grijs vlak met Bad Gateway.
De inhoud was niet weg. Wie de link zelf opende kreeg gewoon de video te zien. Maar het stukje web 2.0 dat ertussen zat — de preview-robot van het platform — kwam er niet doorheen. Dat is een goede binnenkomer voor waar dit artikel over gaat: IPFS werkt. Het is de plek waar IPFS de oude wereld raakt waar het schuurt.
Hieronder de zes plekken waar die twee werelden botsen. Per punt eerst de kern in gewone taal; wil je de techniek erachter, dan klap je die open.
1. De voorbeeldweergave die het niet haalt
Deel een gewone link op LinkedIn of X en je krijgt een keurig kaartje: titel, omschrijving, afbeelding. Dat kaartje maakt het platform zelf, door een robot langs je link te sturen die even kijkt wat erachter zit.
Die robot heeft haast. Hij wacht een paar seconden en gaat dan door. Bij een gewone webserver is dat genoeg — die heeft het bestand klaarliggen. Bij IPFS niet per se: als de gateway de inhoud niet toevallig al in het geheugen heeft, moet hij hem eerst bij andere nodes ophalen. Bij een video zijn dat honderden losse stukjes. Voordat het eerste stukje binnen is, is de robot al vertrokken.
Het resultaat is een foutmelding in de voorbeeldweergave, terwijl een mens die dezelfde link vijf seconden later opent gewoon de video ziet.
▸ De techniek erachter
Publieke gateways draaien meestal een reverse proxy vóór de IPFS-daemon. Antwoordt die daemon niet binnen de proxy-timeout, dan geeft de proxy een 502 Bad Gateway terug — dat is de foutmelding die je in de preview ziet, en hij komt dus van de proxy, niet van IPFS zelf.
Daar komt bij dat IPFS content-adressed is: de gateway moet de blocks actief bij peers ophalen als hij ze niet lokaal gecached heeft. Een video bestaat uit veel blocks, dus dat kost tijd — vaak meer dan de timeout van een preview-bot toestaat.
Preview-crawlers gebruiken bovendien soms andere verzoeken dan een browser (bijvoorbeeld HEAD in plaats van GET, of afwijkende headers). Dat vergroot de kans op falen bij publieke gateways extra.
Kortom: geen fout van IPFS, maar van de combinatie koude publieke gateway + groot bestand + ongeduldige robot.
2. Een adres dat niets over zichzelf zegt
Op het gewone web zegt een adres iets. brainfusion.nl/handleiding.pdf — je weet ongeveer wat je krijgt voordat je klikt.
Een IPFS-adres is een lange reeks tekens die uit de inhoud zelf berekend is. Geen naam, geen extensie, geen soort. Dat heeft een groot voordeel: die reeks is wiskundig aan de inhoud gebonden. Verandert er één byte, dan klopt het adres niet meer. Een IPFS-adres kan niet liegen over of de inhoud gewijzigd is.
Maar het zegt ook niets over wat het is. Is dit een handleiding of iets kwaadaardigs? Daar kom je alleen achter door het te openen. Het vertrouwen verschuift daarmee volledig naar de afzender: je vertrouwt niet het adres, je vertrouwt degene die het je stuurde.
De tegenwerping die je eerlijk moet maken
Hier is het verleidelijk om te zeggen dat web 2.0 het beter doet. Dat klopt niet.
Een bestandsnaam is gewoon een label dat de afzender zelf kiest. Niets op het gewone web controleert of de inhoud overeenkomt met de naam. Een bestand dat kattenfoto.jpg heet kan van alles zijn.
Het verschil is dus subtieler dan het lijkt. Een IPFS-adres kan niet liegen over de inhoud, maar zegt niets over de aard ervan. Een bestandsnaam kan wél liegen over de inhoud, en zegt evenmin iets over veiligheid.
▸ Waar dat vertrouwde gevoel dan vandaan komt
Klassieke misleidingstechnieken op het gewone web: dubbele extensies (kattenfoto.jpg.exe), gemanipuleerde MIME-types, polyglot-bestanden die tegelijk geldig zijn als twee formaten, en macro’s verstopt in “documenten”. De bestandsnaam biedt daar geen enkele bescherming tegen.
Het vertrouwde gevoel bij een gewone URL komt dan ook niet uit de bestandsnaam. Het komt uit de laag eromheen: de geschiedenis van het domein, de validatie van het SSL-certificaat, de reputatie bij browserwaarschuwingssystemen. Precies die laag ontbreekt bij een kale gateway-link.
De eerlijke conclusie: web 2.0 is niet wezenlijk betrouwbaarder over wat je te zien krijgt. Het biedt alleen meer aanknopingspunten voor reputatiesystemen — die zelf ook te omzeilen zijn. IPFS mist die aanknopingspunten, waardoor het vertrouwensprobleem naakter zichtbaar wordt. Het bestaat op het gewone web net zo goed, alleen gecamoufleerd.
3. Filters die een adres niet kunnen plaatsen
Spamfilters en beveiligingssystemen werken met reputatie. Ze kennen domeinen, houden zwarte lijsten bij, kijken hoe lang iets al bestaat en of er eerder ellende vandaan kwam.
Een IPFS-adres past daar niet in. Er is geen domein om op te zoeken en geen geschiedenis om te raadplegen. Elk adres is nieuw voor elk filter, elke keer opnieuw. En wat een systeem niet kan plaatsen, behandelt het als verdacht.
Het gevolg is grillig gedrag: vandaag komt je link door, morgen niet, zonder dat er iets aan de inhoud veranderd is.
4. Het spoor dat je niet ziet
Als je een link deelt, legt het platform dat vast — wie, wat, wanneer. Dat is bekend en logisch.
Wat minder mensen beseffen: de preview-robot laat óók een spoor achter, maar dan bij de gateway. Die registreert het tijdstip, welk adres opgevraagd werd, en van welke infrastructuur het verzoek kwam. Twee losse sporen, die te combineren zijn.
Op zichzelf onthult die gateway-registratie niet wie de afzender is — het IP-adres is van het platform, niet van jou. Maar het is wel een extra gegevensbron die er bij een gewone gedeelde link niet zou zijn.
▸ Wat er precies vastgelegd wordt
Bij de gateway is zichtbaar: het IP van de crawler-infrastructuur (niet dat van de plaatser), de user-agent, het tijdstip en het opgevraagde adres. Op zichzelf is dat niet herleidbaar naar een persoon.
De koppeling tussen gebruiker, inhoud en crawler-verzoek ontstaat bij het platform, niet bij de gateway. Grote platforms voeren daarnaast vrijwel zeker automatische controles uit op ingediende links — malware, phishing, moderatie. Een treffer tegen interne lijsten kan een signaal opleveren dat gekoppeld wordt aan de accountgegevens die het platform toch al heeft.
Geen mysterie dus, maar wel een reële extra laag informatie bovenop wat er al vastligt.
5. Wetgeving die uitgaat van één knop
Wetten rond het verwijderen van content gaan uit van één ding: dat er iemand is die op een knop kan drukken. Een server met een eigenaar, een account met een beheerder, een adres dat offline gehaald kan worden.
Bij IPFS is die knop er niet. Het adres verwijst naar de inhoud zelf, niet naar een plek waar die staat. Verwijder je het bij de bron, dan blijft het bereikbaar zolang ergens anders nog één node het bewaart. Het protocol kent simpelweg geen centrale verwijderfunctie.
Wat wél aan te spreken is, zijn de publieke gateways. Daar richt de aandacht zich dan ook op. Maar dat verplaatst het vraagstuk eerder dan het op te lossen: geblokkeerd bij de ene gateway betekent niet onbereikbaar via de andere.
▸ Het juridische grijze gebied
Regimes als de DMCA, de Europese auteursrechtrichtlijn en de DSA veronderstellen allemaal één aanspreekbaar punt van controle. Bij content-adressering ontbreekt dat: er is geen partij die “het adres” bezit.
Wie dan de tussenpersoon is die dergelijke wetgeving aanspreekt, is juridisch onduidelijk. De beheerder van de gateway? Degene die de inhoud bewaart? Niemand? De discussie lijkt op die rond aansprakelijkheid van Tor-uitgangsnodes en VPN-aanbieders, en is grotendeels onbeslecht.
Voor wie zelf een node draait is één ding wel helder: je bent aanspreekbaar op wat je bewust host en bewaart. Het grijze gebied begint bij content van anderen die toevallig via je netwerkdeelname loopt.
6. “Op IPFS” betekent niet “voor altijd”
Dit is het hardnekkigste misverstand, en het verdient de meeste aandacht.
Mensen horen “gedecentraliseerd” en denken “onverwoestbaar”. Dat is niet wat IPFS belooft. IPFS garandeert hoe je kunt controleren of iets onveranderd is — via het adres dat uit de inhoud berekend wordt. Het garandeert niet dat iets beschikbaar blijft.
Inhoud blijft alleen bestaan zolang minstens één node hem actief vasthoudt. Gebeurt dat niet meer, dan verdwijnt hij zodra de laatste node met een tijdelijke kopie zijn opruiming draait. Het adres blijft dan gewoon geldig — er is alleen niets meer om op te halen.
Populaire inhoud overleeft toevallig langer, omdat veel bezoekers tijdelijke kopieën achterlaten. Maar toeval is geen strategie. Alleen bewust en langdurig vasthouden houdt iets structureel in leven.
Wat dit betekent
Zes wrijvingspunten, en geen ervan is een reden om IPFS links te laten liggen. Het zijn de kosten van iets dat fundamenteel anders werkt dan de infrastructuur eromheen.
Wat opvalt als je ze naast elkaar zet: bijna geen enkel probleem zit in IPFS zelf. Ze zitten in de tussenlaag — de gateways, de preview-robots, de filters, de wetgeving die op een andere wereld ontworpen is. Die laag verwacht een adres dat naar een plek wijst, een naam met een geschiedenis, een eigenaar die aanspreekbaar is. IPFS levert dat niet, omdat het bewust iets anders doet.
En het eerlijkste dat je erover kunt zeggen is dit: IPFS maakt problemen zichtbaar die op het gewone web ook bestaan, maar daar netjes zijn weggewerkt. Dat een bestandsnaam niets garandeert, dat beschikbaarheid van iemands bereidheid afhangt om te blijven hosten, dat vertrouwen uiteindelijk bij mensen ligt en niet bij techniek — dat geldt overal. Op het gewone web hangt er alleen een geruststellende laag omheen.
Dat is geen argument tegen IPFS. Het is een argument om te weten waar je aan begint.
Dit artikel kwam voort uit een praktijkprobleem bij onze eigen blogpost Hoe je AI kan gebruiken?, waarin een video rechtstreeks vanaf IPFS geladen wordt. Zelf iets zelf-gehost opzetten? Neem contact op.