What happens to IPFS maintenance and public infrastructure after September 30?

News
1

Shipyard announced it is winding down IPFS work:

Protocol Labs declined to renew the funding, and the projects Shipyard maintained will have no dedicated maintainers after September 30.

I run IPFS Kubo and Helia nodes and build on this stack, so before the team disperses I would like to understand a few practical things:

  1. Security: who triages vulnerability reports and ships fixes for Kubo, Boxo and Helia after September? Will the disclosure contact listed in community/SECURITY.md at master · ipfs/community · GitHub still reach anyone?
  2. Releases: will anyone cut releases at all, or should operators pin current versions and plan around that? Should we expect a community fork?
  3. Infrastructure: the post says Protocol Labs retains ipfs.io, dweb.link and delegated-ipfs.dev. Who operates them day to day after September, and what experience do they have running public infrastructure at this scale?
  4. What happens to the Service Worker Gateway at https://inbrowser.link?
  5. What happens to Badbits at https://badbits.dwebops.pub? Does it break when Shipyard turns the lights off?
  6. Direction: when NFT.Storage, Web3.Storage and then Storacha wound down its IPFS service this spring, users were pointed at Fil One (https://www.fil.one/), a paid AWS S3-compatible product. Is something similar planned for the public gateways, or will they stay a neutral public service?

None of this is a knock on the Shipyard folks, who kept these projects alive for years and are offering transition help through the end of September. The community got better notice than when Storacha or Fleek shut down abruptly. I am curious what happened to the independence announced in 2023? If a single funder’s decision can end maintenance, the Foundation looks like an accounting arrangement, not independence.

I just want to understand what’s next. Be honest with us: if the plan is to pretend these projects are maintained with LLMs, say so now, so we can plan migration away from IPFS.

5

+1, I have been through the forum, the blogs and chat, and there is nothing anywhere on this.

Narrowing the question: who maintains the Go and JS implementations after September 30?

Boxo, Helia, IPFS Desktop (Kubo).

6

@hector do you plan any official announcements/proposals here?

Especially it is important to know what will happen with the main Boxo/Kubo repositories.

7

I don’t work on Shipyard or anything related to IPFS, so not privy to any information. I saw someone published IPFS is moving beyond the sponsored gateways | IPFS Blog & News though. Which doesn’t really answer your question but that’s all we have so far as far as official infos go.

9

Hi, just joined your group. An investigation team I work with were looking at using IPFS as an alternative to YouTube’s algorithms being abused by malicious actors.
We have good funding and can crowd-source.
Can anyone put me in direct contact with someone who can discuss what you would need?
Thank you.

10

Those are very good questions, so sad that they remain unanswered.

Come on guys, just tell us everything, we can live with it.

11
12

Depressing addendum: not only did core software lose continuity, we can’t even talk about it. Whoever took over broke its Matrix delegation, so people can no longer join #ipfs-space:ipfs.io

https://federationtester.matrix.org/api/report?server_name=ipfs.io

'Get "https://ipfs.io/.well-known/matrix/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)'

:pensive_face:

13

Maybe, maybe not:

➜  ~ ipfs cat /ipns/ipfs.io/.well-known/matrix/server
{
    "m.server": "ipfs.ems.host:443"
}
➜  ~ dig +short ipfs.ems.host
k8s-core-coreingr-e213c56b76-ef68a8798c5364b0.elb.eu-central-1.amazonaws.com.
3.66.50.240
➜  ~ openssl s_client -connect ipfs.ems.host:443
Connecting to 2a05:d014:85a:a00:3361:b8e8:14d8:986a
CONNECTED(00000005)
depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=2 C=US, O=ISRG, CN=Root YR
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=YR1
verify return:1
depth=0 CN=*.element.io
verify return:1
---
Certificate chain
 0 s:CN=*.element.io
   i:C=US, O=Let's Encrypt, CN=YR1
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Sep 29 16:46:36 2026 GMT; NotAfter: Dec 28 16:46:35 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=YR1
   i:C=US, O=ISRG, CN=Root YR
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Sep  3 00:00:00 2025 GMT; NotAfter: Sep  2 23:59:59 2028 GMT
 2 s:C=US, O=ISRG, CN=Root YR
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFFjCCA/6gAwIBAgISBvdQx1kJN+vtXHF9HZ6BagDFMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNZUjEwHhcNMjYwOTI5MTY0NjM2WhcNMjYxMjI4MTY0NjM1WjAXMRUwEwYDVQQD
DAwqLmVsZW1lbnQuaW8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6
1hScuUKjqqXIZZKRk8g+gJa1JCQQn++iJKcKK1ia5BHHWq5Ki6z1PsVt8Pr0yYz8
UWHMPcm3usoWpl5I6seqWcCUYsw8Ds+du2mGeL04rvyky7AeTbBZfc/ZNyYHZLlQ
dBH+OyGMI5X1gAp5bvViqVB+1ZLBU+m3iklD5TW0rW0YLqMmqj0nkA9NeE1Icj/8
+PgT6VU5JiA0PaK1WvBZHrt6bs/OFtjHBPw/WnZGuFVXulf6Mre6tPSDewTv4IvF
0U8eOopdQ8UHskulEY5J+HWTcJVxgkvGlOJCWX1H+CODOkc31yFo4bUXz5m+UUNo
/UIz/pcLGoz7pfhMU55PAgMBAAGjggI+MIICOjAOBgNVHQ8BAf8EBAMCBaAwEwYD
VR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUhCSiP7fV
HX+vuSnselOyCUbm5NwwHwYDVR0jBBgwFoAUHy81vkYUgs1Asa55LFV4+vfUaPsw
MwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzAChhdodHRwOi8veXIxLmkubGVuY3Iu
b3JnLzA8BgNVHREENTAzggwqLmVsZW1lbnQuaW+CCiouZW1zLmhvc3SCDCoubW9k
dWxhci5pbYIJKi5yaW90LmltMBMGA1UdIAQMMAowCAYGZ4EMAQIBMC4GA1UdHwQn
MCUwI6AhoB+GHWh0dHA6Ly95cjEuYy5sZW5jci5vcmcvNzAuY3JsMIIBCwYKKwYB
BAHWeQIEAgSB/ASB+QD3AHUA1219ENGn9XfCx+lf1wC/+YLJM1pl4dCzAXMXwMjF
aXcAAAGg7kUwPAAABAMARjBEAiAesBwJRK0DOIGX0/ei3F5BiFWRF+yD0ciIrZEJ
prbzTgIgPfnnz+tgiLfvBf7Qp1MZI+O/dBQsSzz2vuyQk/mLkWMAfgAm42RuWGkh
I7w0P0ckNZs3ks0kWojYFdOTM/2ZGKtHIwAAAaDuRSYYAAgAAAUAR+GD+wQDAEcw
RQIhAMMhwzECP8XYPSpAK0n6AJEpgGJxK3ibnc/tRkemz0AgAiAsR5MPB4UOXFZL
YRkcuNKP+HkMEquY02aYolUi5qLAdjANBgkqhkiG9w0BAQsFAAOCAQEAIL2W5XFX
ZdvX+redQ7RERj7+/cRETBVPeAM+JJcrTT1o/IJSC5/ibJnpgLtb6TSNvuUlB1r8
0vo33/oIiPaoI39czq9YR08iDYYW5+B683+442W4iEaDWNwl3uGkemeroH6manX0
o9nFxu2coC1cNj5vDOvZp8wD6izTxthQcGUhJlJtEKvy6vQyGe1MtrtQwitUNAbB
mcy8lgmVGIHY7+fwTU6l0DgC6d1UY/0Oqx/wjqMKBxxoPcfJGZDb5sf2C3tFIBeA
8zL0H8D8OtFIq5E3AOTyi2bz+raS7Yh/to8cdXk4DmNzBo32Ri7BfDKYnq+crLDN
QmIdSPNOzAt5jA==
-----END CERTIFICATE-----
subject=CN=*.element.io
issuer=C=US, O=Let's Encrypt, CN=YR1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
---
SSL handshake has read 5739 bytes and written 1624 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 9B3C3E261A84ECF366FEC8A951D0A3C93C0987A7ED3401B48C1BF738C480EE85
    Session-ID-ctx: 
    Resumption PSK: 73B70FA48555484A6B24332BDD18FDF4F06967A28DED6301E7819F6334CBC5CD7385573933BCF0AF7D1A207DAEB0752F
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 600 (seconds)
    TLS session ticket:
    0000 - fc 82 24 f4 da 4e 6f 8d-d2 85 4c 43 92 49 f3 b9   ..$..No...LC.I..
    0010 - 28 42 52 63 52 37 9c 70-90 d6 ba f1 a8 8c 2c 4d   (BRcR7.p......,M

    Start Time: 1791165490
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 9EC3BDE7F34259D4540859EB93F8398D746FF0D84A6398DD3B7C1427C63EC45B
    Session-ID-ctx: 
    Resumption PSK: 3F98B09B4DDDACC65B6DDD8410602B97DCF275055D17B04D20A83410FCE90A24B69670C449D93C0D2B0FCED8B70D295C
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 600 (seconds)
    TLS session ticket:
    0000 - db 25 1a 1a 24 eb 11 e3-65 0d 33 b0 f0 ca 66 b5   .%..$...e.3...f.
    0010 - 10 f9 26 1a dc ff 14 e2-bd 5a 77 7c 9c 3e 99 05   ..&......Zw|.>..

    Start Time: 1791165490
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
^C

So, might still be up. I can’t check beyond that.

14

See the linked diagnostic tool: IPFS Matrix Space is dead for new users.

Also:
https://dist.ipfs.tech is dead
https://ipfscluster.io is dead
https://trustles-gateway.link is dead

15

This is a bummer. I’ve had a feeling that IPFS was being propped up by a reducing number of maintainers for a while.

The underlying design of IPFS is awesome, however deploying it at any kind of scale has bitten me in a big way multiple times.

  • File / Data CID’s are complex / impossible to calculate outside of the IPFS ecosystem. (Namely, the only way historically to calculate them was “while adding data to an IPFS daemon”)
  • IPNS records depend on a single publisher who has the private key. If the publishing node goes down, all is lost
    • DNS-based IPNS is great, but requires constantly updating CID’s in DNS to update content.
  • Lots of crypto / web 3 excitement which faded quickly
  • Pinning large IPFS data sets results in a long and painful pinning process with poor client tracking and a big potential to “fail” due to garbage collection
  • multiformats are complex at times and require a strong learning curve for basic fundamental things like setting IP addresses
  • choosing the “wrong” backend repository format will eat your lunch. big server-specific slow+stable formats vs small desktop fast+corruption prone means you better choose correctly or risk data loss.

I’m trying to be constructive with these points. Some may have been addressed, the list was a lot longer a few years ago, however the IPFS team has done awesome work reducing the pointy bits. (Fuse mounts of MFS come to mind)

IPFS is great, and an awesome technical design, but the core use-case really needs realigned around the realities of users.

16

There are already new releases past 30 september by the new maintainers from IPNI / protocol labs.

I was waiting for Releases · ipfs/service-worker-gateway and it released.

I feel like IPFS technologies are mature at this point so it is definitely not the end of the world.

Although Lidel undoubtfully one of the best developers in the world.

17

Although I am using crypto IPFS was never about crypto for me. Just a very convenient way to store data. To store it for free, even. So if I want to upload a file or music publicly I will do it through IPFS 10 times out of 10.

This is not true anymore for about an year now GitHub - Chara-Freedom/IPNS-Republisher: An IPNS Republisher for IPFS Kubo. · GitHub.

18

Same. I never really got the brief crypto hype for NFT’s on it. IPFS isn’t magic, and the data has to live “somewhere”

Nice! Yeah, i figured some of my pain points would have 3rd party workarounds by now (though, the fact that a 3rd party workaround is even needed for something so core is an issue :slight_smile:)

My list wasn’t a “punch IPFS while it is down” thing, I want to see it successful, just want to keep the “reality of users” visible.