Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
How We Made IPFS Content Publishing 10x Faster (probelab.io)
48 points by dennis-tra 1 hour ago | hide | past | favorite | 5 comments
 help



> 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?


Is it also possible to speed up lookup? I never used IPFS much as it took several minutes to find a cid.

Actually, lookup is super fast - CID lookup is consistently <200ms from the EU [0]. The original slowness came mostly from stale records and NAT’d peers that were indexed in the DHT which has since been mostly resolved.

[0] https://probelab.io/ipfs/dht/#chart-ipfs-dht-lookup-performa...


When’s the last time you tried? It must be much faster now. Check: https://probelab.io/ipfs/dht/#chart-ipfs-dht-lookup-performa...

Are the defaults still leaking your whole internal and external IP allocations to the dHT still?

Its security posture was absolutely fucking gross the last time I reviewed it.

And of course, there's a shitcoin bolted on as well. Last thing I want to do is feed into FileCoin. Of course, everything new these days has some financial interaction crap bolted on to entice speculators and ilk.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: