Shipyard kondigt aan dat zij per 30 september 2026 stoppen met al hun werk aan IPFS, omdat de financiering vanuit Protocol Labs niet wordt verlengd.
Belangrijkste punten uit het artikel:
- Terugblik: Shipyard heeft de afgelopen drie jaar bijgedragen aan de IPFS-gatewayinfrastructuur, HTTP-native benaderingen en verifieerbare websites via
inbrowser.link.
- Gevolgen voor onderhoud: Diverse projecten, waaronder Kubo, Helia, Boxo en IPFS Desktop, verliezen hun toegewijde beheerders voor bugfixes en nieuwe functies.
- Infrastructuur: Het beheer van publieke diensten zoals
ipfs.io en dweb.link stopt. De toekomst van deze domeinen en infrastructuur wordt bepaald door Protocol Labs.
- Transitie: Het team blijft tot eind september beschikbaar om vragen te beantwoorden en de overgang naar andere beheerders zo soepel mogelijk te laten verlopen.
Het einde van IPFS bij Shipyard
We hebben moeilijk nieuws om te delen met de IPFS-gemeenschap en de bredere peer-to-peer gemeenschap.
Protocol Labs heeft ons laten weten dat de financiering van Shipyard niet zal worden verlengd. Hoewel we dankbaar zijn voor de steun en het vertrouwen dat ze de afgelopen ruim twee jaar in ons hebben gesteld, zijn we uiteraard teleurgesteld door deze uitkomst. Als direct gevolg hiervan zal Shipyard de IPFS-gerelateerde engineering, het onderhoud en de infrastructuuroperaties afbouwen. Onze laatste dag van IPFS-gerelateerd werk is 30 september 2026.
Terugblik op onze bijdragen
De afgelopen drie jaar is het ons een voorrecht geweest om te helpen bij het vormgeven van het moderne IPFS-ecosysteem en gebruikers te voorzien van veerkrachtigere, zelfsoevereine technologie. Enkele hoogtepunten van ons werk zijn:
- Het leveren van verifieerbare websites en downloads direct in de browser via
inbrowser.link.
- Het herontwerpen van de IPFS-gatewayinfrastructuur om ongeveer 3x meer verkeer te verwerken, terwijl de operationele- en onderhoudskosten met circa 80% zijn verlaagd.
- Het verder ontwikkelen van HTTP-native benaderingen voor IPFS, die de implementatie, ontwikkeling en operationele kosten aanzienlijk vereenvoudigen in vergelijking met traditionele hosting op basis van libp2p.
- Het onderhouden en verbeteren van veel van de kernimplementaties, bibliotheken en publieke infrastructuur waar het IPFS-ecosysteem dagelijks op vertrouwt.
We keken ernaar uit om het volgende hoofdstuk voor IPFS in te vullen: aanzienlijk eenvoudigere HTTP-native implementaties, veerkrachtige en duurzame content routing, ondersteuning voor grote native SHA-256-objecten, pseudonieme hosting en retrieval via Tor en onion-services, en vele andere ideeën die IPFS significant toegankelijker zouden maken. Helaas krijgen we niet de kans om deze inspanningen zelf te voltooien.
Praktische gevolgen
De praktische implicaties reiken verder dan Shipyard alleen. Onder andere betekent dit het volgende:
- Onderhoud van projecten: Projecten die door Shipyard worden onderhouden, zullen geen toegewijde beheerders meer hebben die verantwoordelijk zijn voor nieuwe functies, bugfixes, releases of beheer op de lange termijn. Dit betreft onder andere: Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check en anderen.
- Upstream bijdragen: De bijdragen van Shipyard aan upstream-projecten zoals
go-libp2p en js-libp2p zullen stoppen.
- Standaarden: Ons werk aan IPFS-specificaties, standaarden en bredere coördinatie binnen het ecosysteem komt ten einde.
- Publieke infrastructuur: Shipyard stopt met het beheren van de publieke infrastructuur die het momenteel beheert, waaronder
ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, de IPFS-bootstrap nodes, collaboratieve clusterinfrastructuur zoals Wikipedia-on-IPFS en aanverwante diensten. Protocol Labs, als eigenaar van de bijbehorende domeinen en infrastructuur, zal bepalen wat de toekomst hiervan wordt.
Transitie en afsluiting
Ons doel voor de komende weken is om het IPFS-ecosysteem in de best mogelijke positie achter te laten voor wat er ook volgt.
We blijven beschikbaar tot het einde van september om te helpen bij die transitie. Als u software onderhoudt, infrastructuur beheert of vertrouwt op werk waar Shipyard verantwoordelijk voor is geweest, aarzel dan niet om contact op te nemen. We zullen alles doen wat redelijkerwijs mogelijk is om vragen te beantwoorden, context te bieden en de overgang zo soepel mogelijk te laten verlopen.
Ten slotte willen we iedereen bedanken.
Dank aan iedereen die code heeft bijgedragen, pull requests heeft beoordeeld, issues heeft gemeld, experimentele functies heeft getest, infrastructuur heeft gedraaid, heeft deelgenomen aan discussies over standaarden, of simpelweg geloofde in het idee dat content geadresseerd moet worden op basis van wat het is in plaats van waar het staat: dank u wel.
Het is een eer geweest om samen met deze gemeenschap te bouwen. Hoewel dit hoofdstuk van IPFS bij Shipyard wordt afgesloten, blijven we trots op wat we samen hebben bereikt. We hopen dat het werk dat we hebben verricht een sterk fundament vormt voor alles wat hierna komt.
Het einde van IPFS bij Shipyard
We hebben moeilijk nieuws om te delen met de IPFS-gemeenschap en de bredere peer-to-peer gemeenschap.
Protocol Labs heeft ons laten weten dat de financiering van Shipyard niet zal worden verlengd. Hoewel we dankbaar zijn voor de steun en het vertrouwen dat ze de afgelopen ruim twee jaar in ons hebben gesteld, zijn we uiteraard teleurgesteld door deze uitkomst. Als direct gevolg hiervan zal Shipyard de IPFS-gerelateerde engineering, het onderhoud en de infrastructuuroperaties afbouwen. Onze laatste dag van IPFS-gerelateerd werk is 30 september 2026.
Terugblik op onze bijdragen
De afgelopen drie jaar is het ons een voorrecht geweest om te helpen bij het vormgeven van het moderne IPFS-ecosysteem en gebruikers te voorzien van veerkrachtigere, zelfsoevereine technologie. Enkele hoogtepunten van ons werk zijn:
- Het leveren van verifieerbare websites en downloads direct in de browser via
inbrowser.link.
- Het herontwerpen van de IPFS-gatewayinfrastructuur om ongeveer 3x meer verkeer te verwerken, terwijl de operationele- en onderhoudskosten met circa 80% zijn verlaagd.
- Het verder ontwikkelen van HTTP-native benaderingen voor IPFS, die de implementatie, ontwikkeling en operationele kosten aanzienlijk vereenvoudigen in vergelijking met traditionele hosting op basis van libp2p.
- Het onderhouden en verbeteren van veel van de kernimplementaties, bibliotheken en publieke infrastructuur waar het IPFS-ecosysteem dagelijks op vertrouwt.
We keken ernaar uit om het volgende hoofdstuk voor IPFS in te vullen: aanzienlijk eenvoudigere HTTP-native implementaties, veerkrachtige en duurzame content routing, ondersteuning voor grote native SHA-256-objecten, pseudonieme hosting en retrieval via Tor en onion-services, en vele andere ideeën die IPFS significant toegankelijker zouden maken. Helaas krijgen we niet de kans om deze inspanningen zelf te voltooien.
Praktische gevolgen
De praktische implicaties reiken verder dan Shipyard alleen. Onder andere betekent dit het volgende:
- Onderhoud van projecten: Projecten die door Shipyard worden onderhouden, zullen geen toegewijde beheerders meer hebben die verantwoordelijk zijn voor nieuwe functies, bugfixes, releases of beheer op de lange termijn. Dit betreft onder andere: Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check en anderen.
- Upstream bijdragen: De bijdragen van Shipyard aan upstream-projecten zoals
go-libp2p en js-libp2p zullen stoppen.
- Standaarden: Ons werk aan IPFS-specificaties, standaarden en bredere coördinatie binnen het ecosysteem komt ten einde.
- Publieke infrastructuur: Shipyard stopt met het beheren van de publieke infrastructuur die het momenteel beheert, waaronder
ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, de IPFS-bootstrap nodes, collaboratieve clusterinfrastructuur zoals Wikipedia-on-IPFS en aanverwante diensten. Protocol Labs, als eigenaar van de bijbehorende domeinen en infrastructuur, zal bepalen wat de toekomst hiervan wordt.
Transitie en afsluiting
Ons doel voor de komende weken is om het IPFS-ecosysteem in de best mogelijke positie achter te laten voor wat er ook volgt.
We blijven beschikbaar tot het einde van september om te helpen bij die transitie. Als u software onderhoudt, infrastructuur beheert of vertrouwt op werk waar Shipyard verantwoordelijk voor is geweest, aarzel dan niet om contact op te nemen. We zullen alles doen wat redelijkerwijs mogelijk is om vragen te beantwoorden, context te bieden en de overgang zo soepel mogelijk te laten verlopen.
Ten slotte willen we iedereen bedanken.
Dank aan iedereen die code heeft bijgedragen, pull requests heeft beoordeeld, issues heeft gemeld, experimentele functies heeft getest, infrastructuur heeft gedraaid, heeft deelgenomen aan discussies over standaarden, of simpelweg geloofde in het idee dat content geadresseerd moet worden op basis van wat het is in plaats van waar het staat: dank u wel.
Het is een eer geweest om samen met deze gemeenschap te bouwen. Hoewel dit hoofdstuk van IPFS bij Shipyard wordt afgesloten, blijven we trots op wat we samen hebben bereikt. We hopen dat het werk dat we hebben verricht een sterk fundament vormt voor alles wat hierna komt.
Groetjes,