16 ms·

IPFS Project Roadmap

242 points by robto 7y ago

techntoke 7y ago
Would love to see Arch/Alpine Linux repo move to IPFS by default. Would also like to see better integration with Git, and an SCM platform comparable to GitHub (or GitLab). That could really get the developer community heavily involved in the project if it was sponsored by Protocol Labs.
- whyrusleeping 7y ago
  Yeah! That's a thing we're working towards. We're currently looking into apt and npm, both efforts are coming along pretty well and driving development towards fixing the bottlenecks preventing it from "just working". https://github.com/ipfs-shipyard/npm-on-ipfs https://github.com/ipfs-shipyard/npm-on-ipfs https://github.com/ipfs-shipyard/apt-on-ipfs https://github.com/ipfs-shipyard/apt-on-ipfs
rob-olmos 7y ago
It's nice to see #2 for package managers, something I've been thinking about recently. I haven't look much into this yet, but I wonder if IPNS could provide a step forward in supply chain protection since package signing isn't available yet in certain managers/repos or not commonly utilized.
fiatjaf 7y ago
The vision of a IPFS-powered web working is beautiful. However I would love to see a reference implementation that works at minimum and not just drains out your computer up to latest resource it may have. If we're so near the "production-ready" status of the reference implementations then I think that goal will never be achieved.
- robto 7y ago
  That's what's got me excited - they've managed to articulate a vision for the future that I'm totally on board with: decentralized, privacy respecting, and user owned. I really want to see that vision become a reality.
  - marknadal 7y ago
    it is already here! If you use a mix of SSB, GUN, DAT, IPFS, & WebTorrent. SSB = Social-like P2P data. GUN = Firebase-like P2P data. SEA = End-to-end encryption. ( https://gun.eco/docs/SEA https://gun.eco/docs/SEA ) DAT = GIT-like P2P data. IPFS = Images/assets. WebTorrent = Video-like P2P data.
    - philips 7y ago
      Are there example applications with some complexity on GUN?
      - marknadal 7y ago
        Yes, D.Tube, The Internet Archive, Notabug.io (warning: its getting spammed by altrighters currently), etc. Only saw your comment now, will reply on Twitter too - long time no see since #hashtheplanet !
        philips 7y ago
        It would be great to get case studies with some information on how they use the platform into the docs. GUN sounds reasonable from the description but it is really difficult to visualize using it in a larger app.
        marknadal 7y ago
        Case studies would be great, nobody is getting paid tho. What info you looking for? I can try digging it up for you. Notabug basically does everything Reddit does + more. Would that qualify as a larger app? What in particular, what do you think would be difficult?
  - Razengan 7y ago
    For the internet to be truly decentralized, it needs to be so at the physical connectivity layer as well. Perhaps a worldwide swarm of drones creating a mesh network.
- dymk 7y ago
  I see this comment often when IPFS is discussed - but the devil is in the details when it comes to replacing the underlying tech of "the web" with something else. How does an IPFS powered website do dynamic content? User sessions? Is all the client's session data encoded in the IPFS address itself? Even if there's no user sessions, but the page content updates, how do you continuously point clients to fetch the right updated page (e.g. how would you implement a Hacker News style aggregator that updates every minute)? IPFS does static content just fine - CAS-es are wonderful for that - but websites are much more than static content.
  - fiatjaf 7y ago
    Dynamic content is not the problem. I don't want dynamic content. I think HTTP and servers are the way to go on dynamic content. I just tried, for years, to use IPFS as a way to distribute static content (you know, stuff that will never ever change, even if that stuff is referenced from a dynamic location), and the problems I encountered were so many I finally gave up. I would love to see all these problems solved and IPFS working very well in the next few years, but I'm afraid the IPFS people are very good in making press releases and presentations, but not in delivering really good software as they say they do. Anyway, they have no obligation to deliver anything to anyone -- except maybe the people who entered the Filecoin ICO.
    - dymk 7y ago
      If you want IPFS to be a replacement technology for the web, you need dynamic content. Else, it's a useful static content distribution network, but it's not "the web", not even in the sense of what the web was in the 90s, or the "web" any more than Bittorrent is. Now, obviously, they're under no obligation to deliver anything. But I'm trying to understand what you mean when you say: The vision of a IPFS-powered web working is beautiful Only handling the static part of webhosting is something, but it's not everything.
      - resonious 7y ago
        I'm under the impression that the original comment was referring to an IPFS-powered web, rather than the web being powered by IPFS. Good ol' HTTP servers will continue to form the web as we know it, and IPFS can provide a new web of static content.
- deleted 7y ago
  [deleted]
nullobject 7y ago
This is exciting. I would love to make it to the 1st IPFS Camp in June.
caprese 7y ago
I've been considering Swarm distributed file system because of its closeness with the Ethereum development. It seems to do the same thing and works already but hardly gets any press. IPFS and the Protocol Lab's Filecoin sale seemed to generate a lot of marketing despite it becoming clearer later that Filecoin is for an unrelated incentivized network. It is hard understand the pros and cons of choosing to use IPFS over Swarm, or where they are in comparative development cycle. I know many decentralized applications that opt for IPFS for their storage component, and know of the libraries to help different software stacks with that. But I can't tell if it is right for me, versus the state of Swarm.
- nonsens3 7y ago
  Swarm and IPFS together with Filecoin try to address the same problem - persistent data storage in a decentralised network. Swarm is not at all "working already" - the incentivisation layer for nodes to store data for other users is not implemented and currently mostly theoretical and work-in-progress. IPFS is more mature in comparison to Swarm, but the underlying architecture is rather different.
  - caprese 7y ago
    What is Swarm's intended incentivisation layer and where can I read about their plans? It seems like all documentation including plans are outdated, and I was ignored in their gitter chatroom where devs wanted to talk about dev things and outreach people seemed nonexistent. I see things being stored on Swarm without incentives, like plain text
    - nonsens3 7y ago
      Swarm documentation might not be perfect, but it is not outdated - https://swarm-guide.readthedocs.io https://swarm-guide.readthedocs.io I believe the chapters about PSS, Swarm Feeds, ENS, Architecture, among others, are mostly up-to-date. You can read about the incentivisation layer at https://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/orange-papers/1/sw%5E3.pdf https://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/ora... Currently incentivisation is not integrated or implemented in Swarm, so a user has no guarantees about what happens with their uploaded content. If the node hosting it disconnects from the network, it will be gone. The plans to address this are through the sw^3 protocols suite and/or erasure coding. Regarding plain text - it doesn't really matter what bytes you store in Swarm - encryption is implemented and you can store non-encrypted or encrypted bytes, this has nothing to do with incentives for persistent storage. We try to do outreach and answer community questions when possible, but the team is not big and this is currently done on a best-effort base, we could definitely improve on that front, I agree.
0xb100db1ade 7y ago
I love the idea of IPFS, but I can't think of a use case not covered by torrents. Would someone mind enlightening me regarding what sets IPFS apart from torrents?
- confounded 7y ago
  Websites?
- fwip 7y ago
  Main feature is automatic data-sharing between distributions. With torrents, everything is siloed, and data is only exchanged between peers of that torrent. IPFS doesn't care /why/ you're getting information or the link you found it from, just that it can find it by its hash. Say you distribute "Julie's Webcast Complete Series" and somebody else distributes "Julie's Webcast - Episode 3, with Russian subtitles," peers and seeders from both distributions can share data for the shared content. Similarly, updating a dataset only requires downloading the new data. This is done automatically, both per-file hashing and (optionally, not sure the current state) of in-file block hashing.
  - xj9 7y ago
    this is an implementation detail of the DHT client. if you have enough cooperating bit torrent clients set up to seed a sparse swarm like IPFS does, you could do the same thing. which begs the question, why fork the DHT in the first place? there are BEP drafts that cover all of the features that IPFS (and DAT for that matter) bring to the table. my guess: there isn't a lot of money in making yet another bit torrent client.
    - StavrosK 7y ago
      Yeah but you can't add an episode to the torrent later and have all existing peers seed the old episodes in the new torrent automatically.
      - xj9 7y ago
fwip 7y ago
"2019 Goal: The most used code and binary Package Managers are powered by IPFS." That's kind of stupid-ambitious for 2019 when another 2019 goal is "a production-ready implementation" and IPFS has been around for 3 years already. This isn't a roadmap, it's a wishlist. And I'm someone who wants to see IPFS succeed.
- StavrosK 7y ago
  The IPFS client is such an untunable memory hog that I turn it off whenever I'm not using it (which, of course, defeats the entire purpose). I would be ecstatic if we had something like the old uTorrent, but for IPFS. A nice UI, easy configuration, an ultralight implementation. It would be a dream come true.
  - deleted 7y ago
    [deleted]
  - threeme3 7y ago
    Exactly this: such an ultralight, accessible implementation would make it better suitable to run on embedded devices and mobile phones. And since we still live in as fairly disconnected world this is probably an area where IPFS can accelerate.
    - dsswh 7y ago
      We live in the world of NATs that effectively prevents any p2p networks.
    - hecturchi 7y ago
      I kind of made this https://github.com/hsanjuan/ipfs-lite https://github.com/hsanjuan/ipfs-lite May not be ultralight (running a DHT node isn't, but it does remove a lot of crust).
  - bradleyhb 7y ago
    When you say nice UI, do you mean a GUI?
viksit 7y ago
One of the biggest challenges with IPFS in my mind is the lack of a story around how to delete content. There may be a variety of reasons to delete things, - Old packages that you simply don't want to version (think npm or pip) - Content that is pirated or proprietary or offensive that needs to be removed from the system But in its current avatar, there isn't an easy way for you to delete data from other people's IPFS hosts in case they choose to host your data. You can delete it from your own. There are solutions proposed with IPNS and pinning etc - but they don't really seem feasible to me last I looked around. This list as @fwip said is great as a wishlist - but I would love to see them address some of the things needed in making this a much more usable system as well in this roadmap.
- tick_tock_tick 7y ago
  I doubt there will every be a way to delete content as every legitimate method of deleting will be commandeered for censorship. Even if they did add something you can never really know the other nodes actually deleted it.
  - fwip 7y ago
    Sometimes, censorship is good. For a silly example, if somebody somehow filled this comment section with images of goatse, it would be nice if we could take that down. I definitely agree from a technical level, you can't ever guarantee the deletion of files on somebody else's machine. So the question is, how do we build systems that enable users to protect their communities, without them becoming yet another tool for abuse?
    - Risord 7y ago
      If soft delete is ok there is no problem. But should it be part of protocol or application layer is another question.
    - tlrobinson 7y ago
      > For a silly example, if somebody somehow filled this comment section with images of goatse, it would be nice if we could take that down. So maybe don't build a Hacker News clone on top of IPFS? It's not meant to be to be a solution to every problem.
microcolonel 7y ago
Discovery performance is the biggest issue I see. If I deliberately load the same file on a couple of peers, it can take hours (or forever) to be able to find a peer with that file to pin it. It is clumsy and difficult to explicitly connect to peers (because you can't just try to discover peers at an address, you need to include the node ID as well), and even if you manage to enter the right information, you won't necessarily succeed at connecting to the peer the first time.
Ericson2314 7y ago
If you want to do package managers, your #1 priority should be Nix. Don't do something more popular where you help less, go with the thing that you can really provide the killer missing feature. Nix + IPFS has been tried before, but what was missing is the Nix-side hierarchical content addressing of large data (not just plans). With the "intensional store" proposal, this should finally happen. Please push it along. Data shouldn't be hashed like Nix's NARs, or IPFS's UnixFS for maximum interopt. Instead please go with git's model for all it's problems. Thanks, hope someone can take me up on this because I'm up to my neck with other open source stuff already.
- sideeffffect 7y ago
  there's been some effort https://github.com/NixOS/nix/issues/859 https://github.com/NixOS/nix/issues/859
  - Ericson2314 7y ago
    Right but not connected to the intentional store.
ezoe 7y ago
IPFS is a joke. They have name lookup feature but relies on traditional DNS! What are they thinking? Also, if the IPFS's idea of working as local server is sound, BitTorrent DNA(browser plugin, steaming video over BitTorrent) should had been worked. It seems to me, they suffered NIH syndrome. They tried to reinvent the wheel. The P2P file transfer protocol over IP has already been covered by BitTorrent. What we need is a nice front end which use BitTorrent protocol as back end and offer a illusion of Web site.
- miguelrochefort 7y ago
  The real innovation is making files content-addressable.
  - Lx1oG-AWb6h_ZG0 7y ago
    Don’t magnet links solve that for torrents?
  - cjslep 7y ago
    Hate to break it to you, but Freenet has been doing that since the year 2000. It's amazing how many things that are popular now are simply re-discovery of Freenet features.
- viraptor 7y ago
  > IPFS is a joke. They have name lookup feature but relies on traditional DNS! This is not a criticism. That's describing a feature. Yes, they do have that. You could implement your own name resolution in a different way if you need that.
- StreamBright 7y ago
  On the top of that when you ask them about it the answer usually is: - but this is decentralized - it is not a bug|lack of implementation but a feature
anandology 7y ago
In addition to apt and npm, I would like to see docker image distribution powered by IPFS. It really feels stupid to pull images from a central registry sitting on the other side of the globe when the image is already present in the next node in your kubernetes cluster.
- DuskStar 7y ago
  That would make many things much easier, and I would enthusiastically use it.
- aiNohY6g 7y ago
  https://github.com/miguelmota/ipdr https://github.com/miguelmota/ipdr
- posnet 7y ago
  If it's for your own cluster, uber open sourced a docker p2p registry explicitly for use with clusters. https://eng.uber.com/introducing-kraken/ https://eng.uber.com/introducing-kraken/
- justincormack 7y ago
  There is a big issue, that ipfs uses its own hash mechanism (hash of protobuf of dag), while registries (and most other existing content based distribution mechanisms) use sha256 hashes of the whole content. eg see https://github.com/ipfs/notes/issues/269 https://github.com/ipfs/notes/issues/269 So you can't simply interop between the two without some sort of lookup to convert hash functions. It is hugely frustrating, as basically different content based distribution mechanisms cant work together. In theory docker image registries support pluggable hash functions, although it is not clear to me that the ipfs function is even very well defined outside its own code. We could start to add a second hash calculation to every registry operation, but it would be a performance hit which some users would not like. (tree based content hashes that allow parallelisation are nice, but the ipfs one is very ipfs specific and more complex than it needs to be I think).
paulsutter 7y ago
So I can store a file in ipfs by its hash, but there’s no way to link to the next version of the file. I can only link to older versions? I’m a giant advocate for decentralized architectures but so far I’ve never found a use for it that doesn’t rely on a centralized way to find out about new data
- johntash 7y ago
  I'm not super familiar with ipfs, but I _think_ ipns is supposed to solve that problem. > Inter-Planetary Name System (IPNS) is a system for creating and updating mutable links to IPFS content. Since objects in IPFS are content-addressed, their address changes every time their content does. That’s useful for a variety of things, but it makes it hard to get the latest version of something. https://docs.ipfs.io/guides/concepts/ipns/ https://docs.ipfs.io/guides/concepts/ipns/
- AgentME 7y ago
  It doesn't have to be 100% decentralized to be useful though. A central server could be in charge of linking the hash to the latest ipfs directory of files. (Or they could use ipns, but let's ignore it for a moment.) But then all of the files are available from a decentralized cloud of users, from everyone running ipfs and hosting the content. And if the central server giving the latest hash ever goes down, people will still be hosting the files and people can find the latest directory hash elsewhere.
- troymc 7y ago
  A file in ipfs is stored/addressed by a hash of its content. If you know the hash of the next version and put that in the file, then that hash will affect the hash/address of the file itself. But the hash of the next version depends on the hash of the _next_ next version, and so on out to infinity... and you almost certainly don't know all those hashes, so you can't compute the hash of the next version, so you can't compute the hash of the current version, if it must contain the hash of the next version.
deleted 7y ago
[deleted]
kamfc 7y ago
What's the difference between DAT and IPFS? I'm trying to understand all these new technology with a grand aspiration to replace the current infrastructure. https://ipfs.io/ https://ipfs.io/ https://datproject.org/ https://datproject.org/ https://beakerbrowser.com/ https://beakerbrowser.com/
pdxww 7y ago
This is not a roadmap, but rather a wishlist. There is a fundamental problem that IPFS needs to solve first. This problem is called an efficient WebRTC-based DHT. In order to change the web, IPFS needs to become usable in the browsers. Since the backbone of IPFS is DHT, there need to be an efficient UDP-based solution for "DHT in the web". Right now this isn't possible and reasons are not just technical, but political. The IPFS team would need to convince all major players that enabling this DHT scenario is a good idea.
- nmca 7y ago
  I actually wrote a DHT that operated over WebRTC itself with in-band signalling for my undergrad thesis, in the application/js layer. Total PITA, but a ... "good?" learning experience.
  - pdxww 7y ago
    How could you possible make such a DHT? We live in the world of NATs, especially symmetric NATs, where each mobile phone user gets assigned a random ip:port every time it makes a connection. DHT, on the other hand, needs every node to have a persistent address that can be contacted any time. In other words, with the NATs, a DHT node cannot cache a bunch of peers and contact them later because those peers are no longer available at those addresses, so every time a node re-joins DHT, it needs to restart the bootstrapping process from scratch, from those initial hardcoded bootstrap servers. Effectively this makes this DHT a fully centralized system. WebRTC cannot solve this problem.
    - zzzcpan 7y ago
      DHT doesn't need every node to have a persistent reachable address from every other node directly. It's ok if some have persistent addresses, some can be reachable after NAT traversal or only through other nodes acting as relays.
    - nmca 7y ago
      You have some proportion of power users that are outside NAT and WebRTC (they run a non-browser executable), their addresses can be shared over the network and stored locally. They provide STUN on rejoining, but are not hard-coded. (Overall, yes this whole thing is a vaguely bad idea. But not totally degenerate / non viable, just not practically worth it.)
woodandsteel 7y ago
I have a question for the IPFS people. I am a non-techy who really likes the IPFS idea and wants to see it succeed. However, whenever this topic comes up here at HN, we get a bunch of people who say they tried to use it but it was basically unworkable, like too much RAM usage and various sorts of failures. And rarely does anyone respond by saying that it is working just fine for them. So my question to the IPFS people is, when is it going to get really usable? I am asking for something reasonably specific, like 2 or 3 years, or what? And I am supposing that would mean a different promise/prediction for each main different use case. So how about some answers, not just "We are aware of those problems and are working on them"
- momack2 7y ago
  As you seem to foresee - being "really usable" depends on the use case. The one we're focused on this year is package managers - and making IPFS work really well for that use case in particular. There is lots of room for improvement on performance and usability - setting the package managers goal gives us really a specific target to focus and deliver on. This won't solve "all the problems" (there's a lot to solve for package managers alone!) - but will help us take a big step forward in production readiness and hopefully knock out a swath of performance issues experienced by everyone.

242 points by robto 7y ago

Would love to see Arch/Alpine Linux repo move to IPFS by default. Would also like to see better integration with Git, and an SCM platform comparable to GitHub (or GitLab). That could really get the developer community heavily involved in the project if it was sponsored by Protocol Labs.

whyrusleeping 7y ago
Yeah! That's a thing we're working towards. We're currently looking into apt and npm, both efforts are coming along pretty well and driving development towards fixing the bottlenecks preventing it from "just working". https://github.com/ipfs-shipyard/npm-on-ipfs https://github.com/ipfs-shipyard/npm-on-ipfs https://github.com/ipfs-shipyard/apt-on-ipfs https://github.com/ipfs-shipyard/apt-on-ipfs

rob-olmos 7y ago

It's nice to see #2 for package managers, something I've been thinking about recently. I haven't look much into this yet, but I wonder if IPNS could provide a step forward in supply chain protection since package signing isn't available yet in certain managers/repos or not commonly utilized.

fiatjaf 7y ago

The vision of a IPFS-powered web working is beautiful. However I would love to see a reference implementation that works at minimum and not just drains out your computer up to latest resource it may have. If we're so near the "production-ready" status of the reference implementations then I think that goal will never be achieved.

robto 7y ago
That's what's got me excited - they've managed to articulate a vision for the future that I'm totally on board with: decentralized, privacy respecting, and user owned. I really want to see that vision become a reality.
- marknadal 7y ago
  it is already here! If you use a mix of SSB, GUN, DAT, IPFS, & WebTorrent. SSB = Social-like P2P data. GUN = Firebase-like P2P data. SEA = End-to-end encryption. ( https://gun.eco/docs/SEA https://gun.eco/docs/SEA ) DAT = GIT-like P2P data. IPFS = Images/assets. WebTorrent = Video-like P2P data.
  - philips 7y ago
    Are there example applications with some complexity on GUN?
    - marknadal 7y ago
      Yes, D.Tube, The Internet Archive, Notabug.io (warning: its getting spammed by altrighters currently), etc. Only saw your comment now, will reply on Twitter too - long time no see since #hashtheplanet !
      - philips 7y ago
        It would be great to get case studies with some information on how they use the platform into the docs. GUN sounds reasonable from the description but it is really difficult to visualize using it in a larger app.
        marknadal 7y ago
        Case studies would be great, nobody is getting paid tho. What info you looking for? I can try digging it up for you. Notabug basically does everything Reddit does + more. Would that qualify as a larger app? What in particular, what do you think would be difficult?
- Razengan 7y ago
  For the internet to be truly decentralized, it needs to be so at the physical connectivity layer as well. Perhaps a worldwide swarm of drones creating a mesh network.
dymk 7y ago
I see this comment often when IPFS is discussed - but the devil is in the details when it comes to replacing the underlying tech of "the web" with something else. How does an IPFS powered website do dynamic content? User sessions? Is all the client's session data encoded in the IPFS address itself? Even if there's no user sessions, but the page content updates, how do you continuously point clients to fetch the right updated page (e.g. how would you implement a Hacker News style aggregator that updates every minute)? IPFS does static content just fine - CAS-es are wonderful for that - but websites are much more than static content.
- fiatjaf 7y ago
  Dynamic content is not the problem. I don't want dynamic content. I think HTTP and servers are the way to go on dynamic content. I just tried, for years, to use IPFS as a way to distribute static content (you know, stuff that will never ever change, even if that stuff is referenced from a dynamic location), and the problems I encountered were so many I finally gave up. I would love to see all these problems solved and IPFS working very well in the next few years, but I'm afraid the IPFS people are very good in making press releases and presentations, but not in delivering really good software as they say they do. Anyway, they have no obligation to deliver anything to anyone -- except maybe the people who entered the Filecoin ICO.
  - dymk 7y ago
    If you want IPFS to be a replacement technology for the web, you need dynamic content. Else, it's a useful static content distribution network, but it's not "the web", not even in the sense of what the web was in the 90s, or the "web" any more than Bittorrent is. Now, obviously, they're under no obligation to deliver anything. But I'm trying to understand what you mean when you say: The vision of a IPFS-powered web working is beautiful Only handling the static part of webhosting is something, but it's not everything.
    - resonious 7y ago
      I'm under the impression that the original comment was referring to an IPFS-powered web, rather than the web being powered by IPFS. Good ol' HTTP servers will continue to form the web as we know it, and IPFS can provide a new web of static content.
deleted 7y ago
[deleted]

nullobject 7y ago

This is exciting. I would love to make it to the 1st IPFS Camp in June.

caprese 7y ago

I've been considering Swarm distributed file system because of its closeness with the Ethereum development. It seems to do the same thing and works already but hardly gets any press. IPFS and the Protocol Lab's Filecoin sale seemed to generate a lot of marketing despite it becoming clearer later that Filecoin is for an unrelated incentivized network. It is hard understand the pros and cons of choosing to use IPFS over Swarm, or where they are in comparative development cycle. I know many decentralized applications that opt for IPFS for their storage component, and know of the libraries to help different software stacks with that. But I can't tell if it is right for me, versus the state of Swarm.

nonsens3 7y ago
Swarm and IPFS together with Filecoin try to address the same problem - persistent data storage in a decentralised network. Swarm is not at all "working already" - the incentivisation layer for nodes to store data for other users is not implemented and currently mostly theoretical and work-in-progress. IPFS is more mature in comparison to Swarm, but the underlying architecture is rather different.
- caprese 7y ago
  What is Swarm's intended incentivisation layer and where can I read about their plans? It seems like all documentation including plans are outdated, and I was ignored in their gitter chatroom where devs wanted to talk about dev things and outreach people seemed nonexistent. I see things being stored on Swarm without incentives, like plain text
  - nonsens3 7y ago
    Swarm documentation might not be perfect, but it is not outdated - https://swarm-guide.readthedocs.io https://swarm-guide.readthedocs.io I believe the chapters about PSS, Swarm Feeds, ENS, Architecture, among others, are mostly up-to-date. You can read about the incentivisation layer at https://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/orange-papers/1/sw%5E3.pdf https://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/ora... Currently incentivisation is not integrated or implemented in Swarm, so a user has no guarantees about what happens with their uploaded content. If the node hosting it disconnects from the network, it will be gone. The plans to address this are through the sw^3 protocols suite and/or erasure coding. Regarding plain text - it doesn't really matter what bytes you store in Swarm - encryption is implemented and you can store non-encrypted or encrypted bytes, this has nothing to do with incentives for persistent storage. We try to do outreach and answer community questions when possible, but the team is not big and this is currently done on a best-effort base, we could definitely improve on that front, I agree.

0xb100db1ade 7y ago

I love the idea of IPFS, but I can't think of a use case not covered by torrents. Would someone mind enlightening me regarding what sets IPFS apart from torrents?

confounded 7y ago
Websites?
fwip 7y ago
Main feature is automatic data-sharing between distributions. With torrents, everything is siloed, and data is only exchanged between peers of that torrent. IPFS doesn't care /why/ you're getting information or the link you found it from, just that it can find it by its hash. Say you distribute "Julie's Webcast Complete Series" and somebody else distributes "Julie's Webcast - Episode 3, with Russian subtitles," peers and seeders from both distributions can share data for the shared content. Similarly, updating a dataset only requires downloading the new data. This is done automatically, both per-file hashing and (optionally, not sure the current state) of in-file block hashing.
- xj9 7y ago
  this is an implementation detail of the DHT client. if you have enough cooperating bit torrent clients set up to seed a sparse swarm like IPFS does, you could do the same thing. which begs the question, why fork the DHT in the first place? there are BEP drafts that cover all of the features that IPFS (and DAT for that matter) bring to the table. my guess: there isn't a lot of money in making yet another bit torrent client.
  - StavrosK 7y ago
    Yeah but you can't add an episode to the torrent later and have all existing peers seed the old episodes in the new torrent automatically.
    - xj9 7y ago

fwip 7y ago

"2019 Goal: The most used code and binary Package Managers are powered by IPFS." That's kind of stupid-ambitious for 2019 when another 2019 goal is "a production-ready implementation" and IPFS has been around for 3 years already. This isn't a roadmap, it's a wishlist. And I'm someone who wants to see IPFS succeed.

StavrosK 7y ago
The IPFS client is such an untunable memory hog that I turn it off whenever I'm not using it (which, of course, defeats the entire purpose). I would be ecstatic if we had something like the old uTorrent, but for IPFS. A nice UI, easy configuration, an ultralight implementation. It would be a dream come true.
- deleted 7y ago
  [deleted]
- threeme3 7y ago
  Exactly this: such an ultralight, accessible implementation would make it better suitable to run on embedded devices and mobile phones. And since we still live in as fairly disconnected world this is probably an area where IPFS can accelerate.
  - dsswh 7y ago
    We live in the world of NATs that effectively prevents any p2p networks.
  - hecturchi 7y ago
    I kind of made this https://github.com/hsanjuan/ipfs-lite https://github.com/hsanjuan/ipfs-lite May not be ultralight (running a DHT node isn't, but it does remove a lot of crust).
- bradleyhb 7y ago
  When you say nice UI, do you mean a GUI?

viksit 7y ago

One of the biggest challenges with IPFS in my mind is the lack of a story around how to delete content. There may be a variety of reasons to delete things, - Old packages that you simply don't want to version (think npm or pip) - Content that is pirated or proprietary or offensive that needs to be removed from the system But in its current avatar, there isn't an easy way for you to delete data from other people's IPFS hosts in case they choose to host your data. You can delete it from your own. There are solutions proposed with IPNS and pinning etc - but they don't really seem feasible to me last I looked around. This list as @fwip said is great as a wishlist - but I would love to see them address some of the things needed in making this a much more usable system as well in this roadmap.

tick_tock_tick 7y ago
I doubt there will every be a way to delete content as every legitimate method of deleting will be commandeered for censorship. Even if they did add something you can never really know the other nodes actually deleted it.
- fwip 7y ago
  Sometimes, censorship is good. For a silly example, if somebody somehow filled this comment section with images of goatse, it would be nice if we could take that down. I definitely agree from a technical level, you can't ever guarantee the deletion of files on somebody else's machine. So the question is, how do we build systems that enable users to protect their communities, without them becoming yet another tool for abuse?
  - Risord 7y ago
    If soft delete is ok there is no problem. But should it be part of protocol or application layer is another question.
  - tlrobinson 7y ago
    > For a silly example, if somebody somehow filled this comment section with images of goatse, it would be nice if we could take that down. So maybe don't build a Hacker News clone on top of IPFS? It's not meant to be to be a solution to every problem.

microcolonel 7y ago

Discovery performance is the biggest issue I see. If I deliberately load the same file on a couple of peers, it can take hours (or forever) to be able to find a peer with that file to pin it. It is clumsy and difficult to explicitly connect to peers (because you can't just try to discover peers at an address, you need to include the node ID as well), and even if you manage to enter the right information, you won't necessarily succeed at connecting to the peer the first time.

Ericson2314 7y ago

If you want to do package managers, your #1 priority should be Nix. Don't do something more popular where you help less, go with the thing that you can really provide the killer missing feature. Nix + IPFS has been tried before, but what was missing is the Nix-side hierarchical content addressing of large data (not just plans). With the "intensional store" proposal, this should finally happen. Please push it along. Data shouldn't be hashed like Nix's NARs, or IPFS's UnixFS for maximum interopt. Instead please go with git's model for all it's problems. Thanks, hope someone can take me up on this because I'm up to my neck with other open source stuff already.

sideeffffect 7y ago
there's been some effort https://github.com/NixOS/nix/issues/859 https://github.com/NixOS/nix/issues/859
- Ericson2314 7y ago
  Right but not connected to the intentional store.

ezoe 7y ago

IPFS is a joke. They have name lookup feature but relies on traditional DNS! What are they thinking? Also, if the IPFS's idea of working as local server is sound, BitTorrent DNA(browser plugin, steaming video over BitTorrent) should had been worked. It seems to me, they suffered NIH syndrome. They tried to reinvent the wheel. The P2P file transfer protocol over IP has already been covered by BitTorrent. What we need is a nice front end which use BitTorrent protocol as back end and offer a illusion of Web site.

miguelrochefort 7y ago
The real innovation is making files content-addressable.
- Lx1oG-AWb6h_ZG0 7y ago
  Don’t magnet links solve that for torrents?
- cjslep 7y ago
  Hate to break it to you, but Freenet has been doing that since the year 2000. It's amazing how many things that are popular now are simply re-discovery of Freenet features.
viraptor 7y ago
> IPFS is a joke. They have name lookup feature but relies on traditional DNS! This is not a criticism. That's describing a feature. Yes, they do have that. You could implement your own name resolution in a different way if you need that.
StreamBright 7y ago
On the top of that when you ask them about it the answer usually is: - but this is decentralized - it is not a bug|lack of implementation but a feature

anandology 7y ago

In addition to apt and npm, I would like to see docker image distribution powered by IPFS. It really feels stupid to pull images from a central registry sitting on the other side of the globe when the image is already present in the next node in your kubernetes cluster.

DuskStar 7y ago
That would make many things much easier, and I would enthusiastically use it.
aiNohY6g 7y ago
https://github.com/miguelmota/ipdr https://github.com/miguelmota/ipdr
posnet 7y ago
If it's for your own cluster, uber open sourced a docker p2p registry explicitly for use with clusters. https://eng.uber.com/introducing-kraken/ https://eng.uber.com/introducing-kraken/
justincormack 7y ago
There is a big issue, that ipfs uses its own hash mechanism (hash of protobuf of dag), while registries (and most other existing content based distribution mechanisms) use sha256 hashes of the whole content. eg see https://github.com/ipfs/notes/issues/269 https://github.com/ipfs/notes/issues/269 So you can't simply interop between the two without some sort of lookup to convert hash functions. It is hugely frustrating, as basically different content based distribution mechanisms cant work together. In theory docker image registries support pluggable hash functions, although it is not clear to me that the ipfs function is even very well defined outside its own code. We could start to add a second hash calculation to every registry operation, but it would be a performance hit which some users would not like. (tree based content hashes that allow parallelisation are nice, but the ipfs one is very ipfs specific and more complex than it needs to be I think).

paulsutter 7y ago

So I can store a file in ipfs by its hash, but there’s no way to link to the next version of the file. I can only link to older versions? I’m a giant advocate for decentralized architectures but so far I’ve never found a use for it that doesn’t rely on a centralized way to find out about new data

johntash 7y ago
I'm not super familiar with ipfs, but I _think_ ipns is supposed to solve that problem. > Inter-Planetary Name System (IPNS) is a system for creating and updating mutable links to IPFS content. Since objects in IPFS are content-addressed, their address changes every time their content does. That’s useful for a variety of things, but it makes it hard to get the latest version of something. https://docs.ipfs.io/guides/concepts/ipns/ https://docs.ipfs.io/guides/concepts/ipns/
AgentME 7y ago
It doesn't have to be 100% decentralized to be useful though. A central server could be in charge of linking the hash to the latest ipfs directory of files. (Or they could use ipns, but let's ignore it for a moment.) But then all of the files are available from a decentralized cloud of users, from everyone running ipfs and hosting the content. And if the central server giving the latest hash ever goes down, people will still be hosting the files and people can find the latest directory hash elsewhere.
troymc 7y ago
A file in ipfs is stored/addressed by a hash of its content. If you know the hash of the next version and put that in the file, then that hash will affect the hash/address of the file itself. But the hash of the next version depends on the hash of the _next_ next version, and so on out to infinity... and you almost certainly don't know all those hashes, so you can't compute the hash of the next version, so you can't compute the hash of the current version, if it must contain the hash of the next version.

deleted 7y ago

[deleted]

kamfc 7y ago

What's the difference between DAT and IPFS? I'm trying to understand all these new technology with a grand aspiration to replace the current infrastructure. https://ipfs.io/ https://ipfs.io/ https://datproject.org/ https://datproject.org/ https://beakerbrowser.com/ https://beakerbrowser.com/

pdxww 7y ago

This is not a roadmap, but rather a wishlist. There is a fundamental problem that IPFS needs to solve first. This problem is called an efficient WebRTC-based DHT. In order to change the web, IPFS needs to become usable in the browsers. Since the backbone of IPFS is DHT, there need to be an efficient UDP-based solution for "DHT in the web". Right now this isn't possible and reasons are not just technical, but political. The IPFS team would need to convince all major players that enabling this DHT scenario is a good idea.

nmca 7y ago
I actually wrote a DHT that operated over WebRTC itself with in-band signalling for my undergrad thesis, in the application/js layer. Total PITA, but a ... "good?" learning experience.
- pdxww 7y ago
  How could you possible make such a DHT? We live in the world of NATs, especially symmetric NATs, where each mobile phone user gets assigned a random ip:port every time it makes a connection. DHT, on the other hand, needs every node to have a persistent address that can be contacted any time. In other words, with the NATs, a DHT node cannot cache a bunch of peers and contact them later because those peers are no longer available at those addresses, so every time a node re-joins DHT, it needs to restart the bootstrapping process from scratch, from those initial hardcoded bootstrap servers. Effectively this makes this DHT a fully centralized system. WebRTC cannot solve this problem.
  - zzzcpan 7y ago
    DHT doesn't need every node to have a persistent reachable address from every other node directly. It's ok if some have persistent addresses, some can be reachable after NAT traversal or only through other nodes acting as relays.
  - nmca 7y ago
    You have some proportion of power users that are outside NAT and WebRTC (they run a non-browser executable), their addresses can be shared over the network and stored locally. They provide STUN on rejoining, but are not hard-coded. (Overall, yes this whole thing is a vaguely bad idea. But not totally degenerate / non viable, just not practically worth it.)

woodandsteel 7y ago

I have a question for the IPFS people. I am a non-techy who really likes the IPFS idea and wants to see it succeed. However, whenever this topic comes up here at HN, we get a bunch of people who say they tried to use it but it was basically unworkable, like too much RAM usage and various sorts of failures. And rarely does anyone respond by saying that it is working just fine for them. So my question to the IPFS people is, when is it going to get really usable? I am asking for something reasonably specific, like 2 or 3 years, or what? And I am supposing that would mean a different promise/prediction for each main different use case. So how about some answers, not just "We are aware of those problems and are working on them"

momack2 7y ago
As you seem to foresee - being "really usable" depends on the use case. The one we're focused on this year is package managers - and making IPFS work really well for that use case in particular. There is lots of room for improvement on performance and usability - setting the package managers goal gives us really a specific target to focus and deliver on. This won't solve "all the problems" (there's a lot to solve for package managers alone!) - but will help us take a big step forward in production readiness and hopefully knock out a swath of performance issues experienced by everyone.