4 ms·

IPFS is essentially web (here meaning htmls css & javascript) over torrent + a distributed hash table. Correct me if I am wrong but isn't this just freenet with

IPFS is essentially web (here meaning htmls css & javascript) over torrent + a distributed hash table. Correct me if I am wrong but isn't this just freenet without the anonymity or kind of like tribler but for websites instead of pirated files?

mburns 11y ago
IPFS shares a lot of similarities to the Freenet datastore, yes. Both support static and dynamic keys that map to content-addressed URIs and can be accessed via a DHT. IPFS lets you selectively (opt-in) save data locally and host it, unlike Freenet which can cache and serve that data to other clients without user action. The lack of Freenet's anonymity feature means it can perform much faster and even be implemented in client-side javascript (Work In Progress) which will drastically increase user adoption.
- _prometheus 11y ago
  (IPFS Dev) Yeah, we have many similarities with Freenet, but we also have significant differences. You mention the lack of anonymity, and yep, that's definitely one -- to speak more about this: this parts from our content model. Among explicit constraints, we have: - content must be able to move as fast as the underlying network permits. this rules out designs like freenet's and other oblivious storage platforms, as the base case. Like you said, they're just way too slow for most of IPFS use cases. But, these can be implemented trivially with the use of privacy focused transports (like Tor and I2P -- there's actually work towards this and people are getting close), content encryption, and so on. - IPFS nodes should be able to only store and/or distribute content they _explicitly_ want to store and/or distribute. This means that computers that run IPFS nodes do not have to host "other people's stuff", which is a very important thing when you consider that lots of content in the internet is -- in some for or other -- illegal under certain jurisdictions. Legitimate companies have way too much in their plate to additionally worry about potentially be storing a ton of illegal stuff. For serious companies like Google to use IPFS, we need to have a mode of operation that allows implementations to ONLY move the content THEY want to move. - Websites/Webapps must be able to operate entirely disconnected -- this means that it should be possible to build applications which create data locally, signed by the user, which can be distributed encrypted end-to-end to other users, without needing to ever touch specific backbone servers. This means users can move the data end-to-end via the closest route possible and in disconnected networks (think users on mobile phones on a plane using messaging webapp or web game and moving the bits over bluetooth or an ad-hoc wifi network. And this also means users in the broader internet do not _need to_ rely on backbone servers -- the model we're going for is that dedicated computers in the backbone CAN of course and SHOULD help, but you shouldn't HAVE TO RELY on them. Can write more about this :)
  - mirimir 11y ago
    If you could compare/contrast with Tahoe-LAFS, that would be cool.
bascule 11y ago
It's an idea as old as Xanadu, which predates the web by decades: http://www.xanadu.com/ http://www.xanadu.com/ But see also: - BitTorrent's Project Maelstrom - GNUnet - Tahoe-LAFS - MaidSafe - MojoNation, the technology that inspired BitTorrent ...just to name a few. The problem with these systems is they don't provide a whole lot of compelling benefits over the regular web, and generally provide a worse user experience. Solving the UX problem is the real hurdle to adoption.
- david_ar 11y ago
  See https://github.com/ipfs/faq/issues https://github.com/ipfs/faq/issues for comparisons to existing systems. The plan is for IPFS to be able to transparently integrate with the existing web, e.g. https://github.com/ipfs/ipfs.js https://github.com/ipfs/ipfs.js
  - chmike 11y ago
    This system looks overly complex. Too many components, too many protocols, ... It will be hard to maintain as source code, and it will be a brittle infrastructure.

mburns 11y ago

IPFS shares a lot of similarities to the Freenet datastore, yes. Both support static and dynamic keys that map to content-addressed URIs and can be accessed via a DHT. IPFS lets you selectively (opt-in) save data locally and host it, unlike Freenet which can cache and serve that data to other clients without user action. The lack of Freenet's anonymity feature means it can perform much faster and even be implemented in client-side javascript (Work In Progress) which will drastically increase user adoption.

_prometheus 11y ago
(IPFS Dev) Yeah, we have many similarities with Freenet, but we also have significant differences. You mention the lack of anonymity, and yep, that's definitely one -- to speak more about this: this parts from our content model. Among explicit constraints, we have: - content must be able to move as fast as the underlying network permits. this rules out designs like freenet's and other oblivious storage platforms, as the base case. Like you said, they're just way too slow for most of IPFS use cases. But, these can be implemented trivially with the use of privacy focused transports (like Tor and I2P -- there's actually work towards this and people are getting close), content encryption, and so on. - IPFS nodes should be able to only store and/or distribute content they _explicitly_ want to store and/or distribute. This means that computers that run IPFS nodes do not have to host "other people's stuff", which is a very important thing when you consider that lots of content in the internet is -- in some for or other -- illegal under certain jurisdictions. Legitimate companies have way too much in their plate to additionally worry about potentially be storing a ton of illegal stuff. For serious companies like Google to use IPFS, we need to have a mode of operation that allows implementations to ONLY move the content THEY want to move. - Websites/Webapps must be able to operate entirely disconnected -- this means that it should be possible to build applications which create data locally, signed by the user, which can be distributed encrypted end-to-end to other users, without needing to ever touch specific backbone servers. This means users can move the data end-to-end via the closest route possible and in disconnected networks (think users on mobile phones on a plane using messaging webapp or web game and moving the bits over bluetooth or an ad-hoc wifi network. And this also means users in the broader internet do not _need to_ rely on backbone servers -- the model we're going for is that dedicated computers in the backbone CAN of course and SHOULD help, but you shouldn't HAVE TO RELY on them. Can write more about this :)
- mirimir 11y ago
  If you could compare/contrast with Tahoe-LAFS, that would be cool.

bascule 11y ago

It's an idea as old as Xanadu, which predates the web by decades: http://www.xanadu.com/ http://www.xanadu.com/ But see also: - BitTorrent's Project Maelstrom - GNUnet - Tahoe-LAFS - MaidSafe - MojoNation, the technology that inspired BitTorrent ...just to name a few. The problem with these systems is they don't provide a whole lot of compelling benefits over the regular web, and generally provide a worse user experience. Solving the UX problem is the real hurdle to adoption.

david_ar 11y ago
See https://github.com/ipfs/faq/issues https://github.com/ipfs/faq/issues for comparisons to existing systems. The plan is for IPFS to be able to transparently integrate with the existing web, e.g. https://github.com/ipfs/ipfs.js https://github.com/ipfs/ipfs.js
- chmike 11y ago
  This system looks overly complex. Too many components, too many protocols, ... It will be hard to maintain as source code, and it will be a brittle infrastructure.