Discussion summary

Recent discussions highlight improvements in IPFS performance, especially in DHT lookup speeds, with some users noting sub-200ms times. Concerns remain about content deletion, security, and initial download difficulties.

What the discussion says

  • IPFS lookup times have improved significantly, now often under 200ms.
  • Some users still face issues with content deletion and security concerns.
  • Performance issues like slow initial downloads and stale records are acknowledged.
  • Ongoing development aims to enhance speed and reliability.
“CID lookup is consistently <200ms from the EU.”
— throwaway8388
“It's great to see improvements in DHT performance.”
— hannesfur

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Am I the only one who has never managed to get an IPFS file to successfully download?
  • Slightly tangential to the article, which seems interesting, but the main issue with IPFS was the horrendous performance of clients which I seem to recall related to having a refresh storms, sparse routing tables, unreachable peers as well as lookup speeds. Mostly the reputation was so bad that people didn't bother with it, I dismissed it for my own project. If your only users are crypto-grift projects you're in a bad place.
  • Did you ever try to keep files on a really good storage?
  • Is it also possible to speed up lookup? I never used IPFS much as it took several minutes to find a cid.
  • Having worked on libp2p‘s DHT (Double Hashing for rust-libp2p) for a bit two years ago, it’s really great to see that there are improvements. To get to CDN level speeds though on dense networks, I still see it as an architectural flaw to not somehow encode network topology into the PeerID / identity in the DHT. A start would be to use the five RIRs. If you want to be more sophisticated, and I spent a lot of time theorising about this, you could have a dezentrally governed anycast IP address of Geo DNS to bootstrap new peers into their neighbourhood and couple that into their DHT identity. But do you want to put BGP into the hands of a decentralised system? Could you even do it in the governance structure of the internet?

    Btw when we were working on our project HyveOS, we used Batman-advs routing table to quickly (really really quick) bootstrap new peers into the system.

    Ah… sometimes i really miss working on this.

  • Is anyone still (or has anyone ever) used IPFS in production?

    I’m not talking about technology demos such as Wikipedia-on-IPFS (which indeed worked and was impressive) but where IPFS is actually being relied on for some functionality.

  • > Return control back to the user after most (not all) of the PUT RPCs have succeeded and continue with the remaining ones in the background.

    Making things faster by doing less (and not the same) been speeding up computing since forever! Can't help but feel like it's slightly misleading to call the providing ("publishing") faster when it's not actually doing the same, it's just that most parts turned async instead of waiting for confirmation.

    Wouldn't this lead to the problem where the user things everything been provided properly, but once others try to find it, the records haven't yet been published? As far as I understand, it'd still take mostly the same amount of time until the entire CID (not just some of them) are available to others, the only thing that got "faster" is the end-user UX of the one providing?

Explore Birbla archives