Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Made IPFS Content Publishing 10x Faster

probelab.io

Post reply on HN
Print view View original

31–40 of 69 posts

Re: How We Made IPFS Content Publishing 10x Faster

#31

Post by boramalper »

Borg3 wrote: post #25
boramalper wrote: post #12

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.

Yeah.. IPFS is a bit disappointement. I was a bit exceited about it back in the day. Recently, I wanted to download sth large from archive.org, I used torrent (and my legacy torrent client) and it worked like a charm! It seems pure HTTP tracker + Torrent is good enough.

I think the biggest sin of IPFS is not working natively in web browsers—instead, requiring the use of either HTTP gateways or native apps running outside the browser.

Re: How We Made IPFS Content Publishing 10x Faster

#32

Post by boramalper »

ydj wrote: post #26
boramalper wrote: post #12

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.

At meta, there was a project for delivering binaries of internally built libraries / binaries to dev laptops using a private ipfs network. This was live for at least some period of time.

Very interesting! I wonder if it’s still live and there is any writing on it?

Re: How We Made IPFS Content Publishing 10x Faster

#33

Post by boramalper »

topgrain2 wrote: post #30
boramalper wrote: post #21

Earlier quoted context omitted.

And why would you do that? As opposed to, say, distributing via BitTorrent or serving them using a good-old HTTP server? edit: Not opposed to the idea, just curious what makes you pick IPFS over the existing alternatives.

The idea of simply mounting a filesystem and selecting from a list of titles which roms to download and add to your local games, unloading them and transparently re-downloading when you need to free up space, all without relying on a centralized host even for the file index, is pretty appealing. You can do similar things with torrents but it's not quite as "natural". Most of the emulator frontends I've seen are prett…

> The idea of simply mounting a filesystem

You can use fuse-btfs [0] for mounting torrents as filesystems! Last I checked it was a fairly mature piece of software so hopefully it doesn’t feel unnatural.

[0] https://github.com/johang/btfs

Re: How We Made IPFS Content Publishing 10x Faster

#34

Post by RobotToaster »

boramalper wrote: post #20
pixel_popping wrote: post #14

Earlier quoted context omitted.

It's funny because even in Piracy, IPFS has never really taken off and that's a massive use case.

It slowly was taking off—e.g. Library Genesis on IPFS[0]—but then IPFS introduced Bad Bits Denylist [1] which killed it on arrival. [0] https://freeread.org/ipfs.html [1] https://badbits.dwebops.pub/

Suddenly it looks a lot less decentralised.

Re: How We Made IPFS Content Publishing 10x Faster

#35

Post by throwaway8388 »

RobotToaster wrote: post #34
boramalper wrote: post #20

Earlier quoted context omitted.

It slowly was taking off—e.g. Library Genesis on IPFS[0]—but then IPFS introduced Bad Bits Denylist [1] which killed it on arrival. [0] https://freeread.org/ipfs.html [1] https://badbits.dwebops.pub/

Suddenly it looks a lot less decentralised.

Well, badbits are only enforced on the centralized http gateways. LibGen CIDs would still resolve fine using the DHT as the decentralised discovery mechanism

Re: How We Made IPFS Content Publishing 10x Faster

#36

Post by benatkin »

boramalper wrote: post #19
frollogaston wrote: post #17

Earlier quoted context omitted.

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.

I don’t think NFTs (should) count: My first impressions of web3 by Moxie Marlinspike https://moxie.org/2022/01/07/web3-first-impressions.html

Moxie doesn't trash NFTs or Web3 in that article. He just points out some limitations of the ecosystem.

Also, ipfs directly fixes one of the bigger issues:

> Instead of storing the data on-chain, NFTs instead contain a URL that points to the data.

If it's ipfs, it points to the content. If it's ipns, it points to a changeable link to the content, but one that is made consistent through the network, preventing the trick of making it differ based on the referrer.

Re: How We Made IPFS Content Publishing 10x Faster

#37

Post by [deleted] »

somat wrote: post #22
catapart wrote: post #13

Earlier quoted context omitted.

Thanks! Yeah, I kind of figured that was still the case. Not really any use cases I have that I would feel comfortable with that paradigm, but I'm glad it's available!

Is that not the same with anything published to the internet. For example I could keep your comment published and available for as long as I had interest in doing so despite any effort you may take to remove it from HN. I mean I guess tech like ipfs and bittorrent try to automate this process(keeping something on the internet as long as there is interest) but you let something out on the internet it could stay there…

[deleted]

Re: How We Made IPFS Content Publishing 10x Faster

#38

Post by iamnothere »

somat wrote: post #22
catapart wrote: post #13

Earlier quoted context omitted.

Thanks! Yeah, I kind of figured that was still the case. Not really any use cases I have that I would feel comfortable with that paradigm, but I'm glad it's available!

Is that not the same with anything published to the internet. For example I could keep your comment published and available for as long as I had interest in doing so despite any effort you may take to remove it from HN. I mean I guess tech like ipfs and bittorrent try to automate this process(keeping something on the internet as long as there is interest) but you let something out on the internet it could stay there…

True, and in fact HN will not allow you to remove your past comments after the delete period has passed. People who are obsessed with deleting their past history should probably not be posting here! (Not even a GDPR request will help you, for those in Europe.)

Re: How We Made IPFS Content Publishing 10x Faster

#39

Post by [deleted] »

hannesfur wrote: post #23

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 theo…

[deleted]

Re: How We Made IPFS Content Publishing 10x Faster

#40

Post by dannyobrien »

boramalper wrote: post #31
Borg3 wrote: post #25

Earlier quoted context omitted.

Yeah.. IPFS is a bit disappointement. I was a bit exceited about it back in the day. Recently, I wanted to download sth large from archive.org, I used torrent (and my legacy torrent client) and it worked like a charm! It seems pure HTTP tracker + Torrent is good enough.

I think the biggest sin of IPFS is not working natively in web browsers—instead, requiring the use of either HTTP gateways or native apps running outside the browser.

Actually, this works now! https://inbrowser.link/ https://github.com/ipfs/service-worker-gateway -- getting p2p working in browsers is still surprisingly hard: even the official routes like webrtc have lots of hard edge cases.
Post reply on HN