Hacker News Reader

Comment by nullstyle | Hacker News Reader

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

It's a shame if you ask me.

View on HN

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!

>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

I love the idea of IPFS, but let me ask you the question, when is it finally going to be ready for people to easily deploy? A year from now, 3 years, 5 years? Or maybe you have no idea?

Don't give some vague answer about how you are working on it. Give me a reasonably specific prediction, or say you have no idea.

Isn't this kind of an unreasonable demand? It's not like software isn't ready for anyone one day and ready for everyone the next. Considering just about nobody can give an accurate software development forecast for even objective milestones, it seems ridiculous that there would be any reasonable answer to this.

Beyond the question of the possibility of giving a precise answer, did OP lose sight of basic courtesy?

As far as I know IPFS is an open system contributed to by volunteers. Making those kind of demands for deadlines in such an aggressive tone is way out of place.

No, I am just asking for honesty. Either they have some sort of idea when it will be basically usable, or they don't. I am not saying they have to meet a deadline, I am asking when they think they are going to get there.

And why do they need to be defended by others? If I am being unreasonable, why don't they just say that themselves?

Who says they need to defend themselves? If I come across somebody making unreasonable demands I ignore them.

I am not asking for an exact answer, just an approximate one. And if they honestly have no idea, then they should say that.

I want to call out this attitude as incredibly entitled and related to the exact root cause of all the open-source drama we've been seeing lately.

Hi! Thanks for taking the time to respond and correct my outdated info. Unfortunately, It seems your info is also outdated: I just installed 0.10.2 for Mac and it's by default using (600,900) for the low and high watermarks and routing type is set to dht rather than dhtclient.

Since I've got you here, I'd be happy to give a little feedback: The constellation of websites for the protocol labs projects, their different visual styles, their different states of decay/maintenance, the interlinking back and forth with source files in github, and the undocumented status of all these projects really lend to a maze-like and poor learning/browsing experience. If it were my project, I would dump all the different sites and consolidate under one web presence. I never know if what I'm reading is current, or planned and not done, or old and out of date, or just bugged. As an example, there are even broken links on the readme at https://github.com/ipfs/ipfs. The number of TODOs or unresponsive links in README files in the various github repos (under the various github organizations) adds to the frustration of trying to learn your work. As an example, take the readme at https://github.com/ipfs/go-hamt-ipld : It's been recently worked on, and yet the entire table of contents are broken links and the examples section is literally just "//TODO". I think y'all should consolidate efforts, kill or privatize the projects that are unusable by the outside world, and in general start developing things to a more complete state before adding new stuff.

I've tried several times now to incorporate IPFS into my developer toolbelt and have aborted my attempt each time due to this or that rough edge that you don't learn about unless you spend time trolling through the github issues. It seems like each time I've come back y'all have added more unfinished stuff (congrats on the filecoin testnet!) and the rough edges still remain. As an example, I just added a 7 gigabyte file (an xcode disk image) through the desktop client: It peaked at around 15gb of ram during the process and the client offered _zero_ visual feedback while it was working. In fact, while the client says my repo is the correct size, the xcode image I added doesn't actually show up in the file browser. It's all very painful to work with. ipfs, ipld and libp2p hit the right notes in their promotional material to entice someone who wants to help the decentralized web grow, and I would love for these projects to be what they aspire and claim to be, but it all just seems to fall apart rather quickly when you actually start to use them for something beyond your tutorials.

> I just installed 0.10.2 for Mac and it's by default using (600,900) for the low and high watermarks and routing type is set to dht rather than dhtclient.

(600,900) watermarks suggest you had an old config (ipfs-desktop will respect pre-existing config and won't override values). Just change watermarks manually to (50,300) and restart.

If you run daemon via ipfs-desktop the routing preference from config file is ignored: Desktop runs daemon with an explicit command line parameter (--routing=dhtclient) to avoid DHT server traffic.

Hope this helps.

Thanks for the heads up. I didn't realize I had left the old config in place.

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 name -> hash mapping can take several minutes and then lookup of that name can take several minutes even on the node that published it in the first place. Names also need to be republished every 24 hours or so or they disappear from the network, which in my opinion harms the claims of decentralization.

* = unless something has radically changed in the last few months and they just haven't closed the GitHub issue: https://github.com/ipfs/go-ipfs/issues/3860

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.

IPFS and ENS work pretty seamlessly together (https://medium.com/the-ethereum-name-service/ethdns-9d56298f...), but some folks also want the mutable pointers layer of IPNS too. We're working on making that faster: https://www.youtube.com/watch?v=XniIDIXU8RE&t=10s

How can I register an ENS domain/id? I've found very little practical info on a cursory search.

There's probably a simple article out there but I'll summarize it a bit:

You go to https://manager.ens.domains/ to register a .eth address and on the settings page for your domain you add a Content record and point it to ipfs://Qma7nxS98CAb2BTaxLJBSFozxxSp5XTu6tMtCrKcRQ9ByV or whatever the IPFS hash of your website is.

After that you can visit your site at https://myname.eth in a browser that supports ENS/IPFS or you can go to https://myname.eth.link in any browser and see your website.

This is what I needed, thanks!

I created a service to make it easy to buy and configure ENS domains in one step. Hope it helps! www.namestack.io.

That's helpful, thank you. Unfortunately it looks like .eth domains have already been squatted to hell.

I really wish everything written about IPFS would just ignore IPNS, and stop presenting it as a standard part of IPFS. The thing IPNS tries to do can be done better by the existing DNS system (which works fine combined with IPFS) or blockchain-based systems like ENS. IPNS is a slow incomplete tech demo glued to the rest. Ignoring IPNS won't impact your understanding of the rest of IPFS. I don't think people relying on IPFS even use IPNS for anything but a curiosity, and it's so bad that I expect many people get turned off of IPFS because they get confused by IPNS's flaws or assume that the rest of IPFS works as badly.

IPFS is good at content-addressed storage. IPNS is not part of content-addressed storage. Tutorials about IPFS should ignore IPNS, and talk about alternative ways to link to IPFS links, like using DNS.

> IPFS still has a long way to go until it is useable in my opinion.

Now we just need to figure out what to use it for. I think the largest successful experiment of distributed file storage was Wuala. At the beginning it was similar to IPFS, using random home devices to store data, doing some clever calculation and splitting of files to guarantee that a file is likely always available. Emphasis on likely.

They had nice features:

- keep files private

- share files with other registered users

- share files with unregistered users, through a keyed hyperlink

- publish files

- backup

- file synchronization

- file versioning

At the end they migrated away from using random home nodes for storage and went for central servers. Not sure about the motivation behind it but I would really like to know. Did that happen because of business requirements or some technical limitations?

Building on top of other people's infrastructure is expensive.

Each node can disappear at any time and is really hard to predict. To compensate for that you will need to upload your data to more nodes. You have to deal with backward and forward-compatible updates because both client and server versions updates are also not under your control. There are also more complicated issues of trust and bad actors that can affect the product.

Now you have a datacenter. The clients upload their data exactly once. Your server software has at most two concurrent versions during deployment. Security is handled in a traditional fashion with DDoS firewalls and pentesting. Your whole software stack is much simpler because you can build on top of more solid assumptions.

Skype also used to be P2P until the Microsoft acquisition where they moved towards hosted nodes. Some people say it's so that Microsoft can spy on everybody but I really believe that the main reason was so that they could improve the QoS.

I was a huge fan of Wuala, and was very disappointed when they got bought and then shut down. My understanding is they always stored a central copy of everything on their servers to 100% guarantee availability. The P2P copies merely helped with bandwidth. I think their main innovation is the cryptree data structure for access control. We use a more advanced version of that in Peergos[1].

[1] https://github.com/peergos/peergos

I know so many projects with barely any popularity being forced to move off of IPFS cause of performance problems.

DAT,SSB don't work in browser.

WebTorrent is the original better choice.

But I'm seeing most big projects move to GUN (mine, https://github.com/amark/gun). Internet Archive, HackerNoon others using it in production, with over 10M+ users, decentralized.

If IPFS team doesn't seriously fix their performance issue within 2 years, they're gonna see a lot of backlash. With $250M+ raised and 100+ employees this should be possible, I know they can do it, dWeb would be better for it.

Reply on news.ycombinator.com