Live data from Hacker News

Why build this blog, or anything, on IPFS?

teetotality.blog

41–50 of 156 posts

Re: Why build this blog, or anything, on IPFS?

#41
Disclaimer: I run the unofficial IPFS Discord and Matrix (found at https://permaweb.io/discord and /matrix) and have helped organize IPFS Meetups in SF. We also run an IPFS gateway and have built a groups app on top of IPFS and Textile.

I generally agree with the conclusion, but there's a few downsides that aren't conveyed here.

Let's look at the proposed upsides: 1) Ownership, control, censorship: That's partly correct. Ownership is fair, in the sense that you can run your node and self-host. However this is true of any self-hosting solution. You could run a Docker instance of a Wordpress or Ghost site and get ownership / control.

2) The point about censorship is muddied, however. I'll combine that point with the second upside: Resilience. Every day for the past two years, I've seen people wonder if IPFS is a magical cloud with infinite storage. People seem to think you put a file on IPFS, and it just gets replicated, censorship resistant hosting. That's not how it works. People need to pin your hash. You need to tell the world about your hash somehow. All this is done via a public list of IPs that is being broadcasted. Think of IPFS this way: you're letting people with the hash become CDNs of your content. That's cool, but that doesn't solve discovery, keeping things up, etc. IPFS doesn't encrypt the content, or the connectivity, or hide the hosts. Solutions exist around that, but they're niche, and honestly I question the motives besides just ideology.

3) Elegance. Yeah it's a really, really cool way to solve linking. As some others pointed out, it's not as fast as classic centralized links, so it's better suited currently for solutions that don't require speed.

Re: Why build this blog, or anything, on IPFS?

#42
We run a blog on top of IPFS, and we use ENS (Ethereum Name Service) to keep it always updates.

Basically you can access it if you use Opera browser or some browser extension. If not there are some gateways, like this: blog.almonit.eth.link

Re: Why build this blog, or anything, on IPFS?

#44
post #32

IPFS still has a long way to go until it is useable in my opinion. The default configuration for the desktop client will gladly keep open 1000+ peer connections and will happily degrade your usual internet experience. In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482…

To add to this there are* serious issues with naming. I wrote an app that ran on IPFS last year and throughout testing there was a persistent problem with needing to issue the testers with a new hash/link for each new version because IPNS, IPFS' decentralized naming solution, effectively doesn't work. It's supposed to give each node a unique name which can be repeatedly mapped to different hashes but publishing a new…

I consider IPNS fundamentally broken and have stopped using it. ENS is better in almost every way and is extremely reliable so it's not that big of deal.

Re: Why build this blog, or anything, on IPFS?

#45
post #43

Out of curiosity, isn’t the DNS gateway like Cloudflare ( https://blog.cloudflare.com/distributed-web-gateway/ ) a single point of failure? Is there a solution to this without having to resort to a completely different desktop app?

Well there are many gateways which provides redundancy but if ipfs really takes off I think it'll eventually need to be supported by browsers so that you're using your own ipfs node for lookups but it's seamless for you the user or developer.

Re: Why build this blog, or anything, on IPFS?

#46
post #33
post #30

The thing I worry about with IPFS is privacy. If you use IPFS directly (as intended, not via a public gateway), and you visit a site, then you are automatically going to be seeding (like a torrent) the visited content, and thus you will be announcing/broadcasting the fact to the world that you (your node/your IP) have visited it. My current understanding is that this cannot really be avoided, since one needs to be ab…

Well, one can use IPFS through Tor, and use gateways that are Tor onion services.

We do this for OpenBazaar which is built on top of ipfs and it works great. We built a Tor transport for libp2p, which is what drives ipfs's p2p networking so any libp2p app, including ipfs, can work over Tor.

https://github.com/OpenBazaar/go-onion-transport

Re: Why build this blog, or anything, on IPFS?

#47
If you replace the word "IPFS" with "BitTorrent," this article is still true. Similarly, if you replace "IPFS" with "BitTorrent" in most of the comments here, the comments are still true.

If you understand how BitTorrent works -- including its strengths and limitations -- you'll understand how IPFS works.

Re: Why build this blog, or anything, on IPFS?

#48
post #47

If you replace the word "IPFS" with "BitTorrent," this article is still true. Similarly, if you replace "IPFS" with "BitTorrent" in most of the comments here, the comments are still true. If you understand how BitTorrent works -- including its strengths and limitations -- you'll understand how IPFS works.

Minor nit: BitTorrent does not allow one to maintain a persistent URI to changing/updated data, as IPNS does.

Re: Why build this blog, or anything, on IPFS?

#49
post #40
post #33

Earlier quoted context omitted.

Well, one can use IPFS through Tor, and use gateways that are Tor onion services.

Good point about the experimental Tor support and the Onion IPFS gateways. Is there a reasonable way to use untrusted gateways while upholding the data integrity guarantees? I think it should be possible in theory.

Because data on ipfs is content addressed by hash you can always check the integrity of data you receive, in theory, although the tooling isn't there for you to easily verify the output of a gateway without your own ipfs node afaik.

Re: Why build this blog, or anything, on IPFS?

#50

IPFS still has a long way to go until it is useable in my opinion. The default configuration for the desktop client will gladly keep open 1000+ peer connections and will happily degrade your usual internet experience. In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482…

Hey IPFS person here. We actually made a change to ipfs-desktop back in Feb of last year to reduce the default connection limit to ~300 (https://github.com/ipfs-shipyard/ipfs-desktop/pull/828), and also to set desktop nodes into DHT-client mode (so they don't get lots of requests from other nodes for where to find content). If you've been running your node since back then, you can change your defaults in the desktop "settings" menu at the bottom of your IPFS config by setting '"HighWater": 300' (or whatever you prefer -- personally I like having ~600 connections). I run ipfs-desktop all the time (including on crappy hotel wifis) and don't find it gets in the way of anything.

You're right, there are a ton of great ideas and suggestions for how to make IPFS better that we haven't gotten to yet - we're working on making it easier to navigate and for more folks to help contribute. To that aim, we just created a new ipfs-docs site (in beta right now) to better explain the concepts and how-to of working in the ecosystem: blog.ipfs.io/2020-01-07-ipfs-docs-beta/ -- would love your feedback on how we can keep making that better!

Post reply on HN