7 ms·

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 connection

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 https://github.com/ipfs/go-ipfs/issues/1482 It's a shame if you ask me.

furi 7y ago
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 https://github.com/ipfs/go-ipfs/issues/3860
- Sargos 7y ago
  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.
  - momack2 7y ago
    IPFS and ENS work pretty seamlessly together (https://medium.com/the-ethereum-name-service/ethdns-9d56298fa38a 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 https://www.youtube.com/watch?v=XniIDIXU8RE&t=10s
  - StavrosK 7y ago
    How can I register an ENS domain/id? I've found very little practical info on a cursory search.
    - Sargos 7y ago
      There's probably a simple article out there but I'll summarize it a bit: You go to https://manager.ens.domains/ 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 https://myname.eth in a browser that supports ENS/IPFS or you can go to https://myname.eth.link https://myname.eth.link in any browser and see your website.
      - StavrosK 7y ago
        This is what I needed, thanks!
    - mmurthy 7y ago
      I created a service to make it easy to buy and configure ENS domains in one step. Hope it helps! www.namestack.io.
      - StavrosK 7y ago
        That's helpful, thank you. Unfortunately it looks like .eth domains have already been squatted to hell.
- AgentME 7y ago
  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.
momack2 7y ago
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 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!
- woodandsteel 7y ago
  >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.
  - singron 7y ago
    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.
    - charles_f 7y ago
      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.
marknadal 7y ago
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 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.
StreamBright 7y ago
> 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?
- zimbatm 7y ago
  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.
- ianopolous 7y ago
  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 https://github.com/peergos/peergos

furi 7y ago

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 https://github.com/ipfs/go-ipfs/issues/3860

Sargos 7y ago
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.
- momack2 7y ago
  IPFS and ENS work pretty seamlessly together (https://medium.com/the-ethereum-name-service/ethdns-9d56298fa38a 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 https://www.youtube.com/watch?v=XniIDIXU8RE&t=10s
- StavrosK 7y ago
  How can I register an ENS domain/id? I've found very little practical info on a cursory search.
  - Sargos 7y ago
    There's probably a simple article out there but I'll summarize it a bit: You go to https://manager.ens.domains/ 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 https://myname.eth in a browser that supports ENS/IPFS or you can go to https://myname.eth.link https://myname.eth.link in any browser and see your website.
    - StavrosK 7y ago
      This is what I needed, thanks!
  - mmurthy 7y ago
    I created a service to make it easy to buy and configure ENS domains in one step. Hope it helps! www.namestack.io.
    - StavrosK 7y ago
      That's helpful, thank you. Unfortunately it looks like .eth domains have already been squatted to hell.
AgentME 7y ago
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.

momack2 7y ago

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

woodandsteel 7y ago
>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.
- singron 7y ago
  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.
  - charles_f 7y ago
    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.

marknadal 7y ago

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

StreamBright 7y ago

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

zimbatm 7y ago
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.
ianopolous 7y ago
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 https://github.com/peergos/peergos