How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
> 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 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.
NFT artwork, if you count that. Briefly checked, the ones that were traded for the most were using IPFS rather than HTTP. But I also don't trust that these aren't self-wash sales (easy given the "NF" part), also NFTs are dumb.
Small nit: most of those "IPFS" NFTs just point to a gateway HTTP URL, not an actual ipfs:// URI resolved client-side. And even when it is ipfs://, if nobody's pinning it the content vanishes anyway. Still better than a raw S3 link though.
the thing that prevented me using ipfs in anger.. (granted i may not have looked hard enough)
was that i couldn't have stuff in ipfs, and access it via posix filesystem at he same time. i'd have to store things twice.
fine for publishing, but not for having a live data set that is both used and published at the same time, as you can do with torrent.
FUSE mount for IPFS exists, tried it years back. Latency and cache invalidation made it unusable for anything with real write traffic. Great for read-only archives, terrible for a live dataset someone's actually hammering.
Protocol Labs' own products count, no? Filecoin uses IPFS under the hood for deal data, and that's real production traffic with real money. Whether that's "IPFS succeeding" or "IPFS surviving because its creators subsidize it" is a fair question though.
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.
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.
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.
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.
Last I was told about it, there was no way to delete stuff from IPFS. Nothing enforceable, at least. Setting aside that public stuff is "impossible" to delete on the internet, there's something appealing to me about being able to shut off my server. Feels like that is less possible with IPFS hosted content.
Does anyone have some perspective for me about removing content?
Imagine you created a torrent (and/or magnet link) with a file and then stopped seeding after some time. If it was popular it will probably live on, if not then eventually it disappears.
Same story as Freenet back in 2000, minus GC. Freenet at least dropped unpopular blocks under storage pressure. IPFS pins forever unless you unpin, so "delete" means "hope nobody else pinned it." DHTs don't forget, only starve.
we hit this exact wall with a pinning setup last year, DHT provide records timing out constantly on writes. ended up batching provides and firing them async instead of blocking the upload response, basically what they're describing here. cut our p99 way down, worth doing even without their reprovide sweeper changes.
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?