Hacker News Reader

Comment by stirner | Hacker News Reader

Why not use IPFS, which is specifically designed for this sort of usage and will be more resilient?

Seems js-ipfs[0] is not quite ready for prime time (though it's close) and the author had a requirement to do everything from a browser.

https://github.com/ipfs/js-ipfs/

Unfortunately it looks like WebRTC support and DHT support isn't planned for this current release of js-ipfs according to their roadmap [1], both of which could be a giant leap forward in enabling truly decentralized apps.

Bittorrent DHT doesn't actually run in the browser yet either [2], so WebTorrent in the browser currently only has access to the tracker infrastructure, and thus isn't as decentralized as one might think.

[1] https://github.com/ipfs/js-ipfs/blob/master/ROADMAP.md

[2] https://github.com/feross/webtorrent/issues/288

(IPFS dev here)

We've been working hard to get js-ipfs to a working level and just last week announced it's ready. While it's still early days and we have plenty to do to make it even more robust, we have it fully working with WebRTC support as of today.

We've developed some apps and demos that essentially enable you to create dynamic content and apps on IPFS, purely in the browser. We do have to currently rely on a centralized Pubsub (in a similar fashion to torrent trackers) but we're working on to provide a decentralized pubsub mechanisms as part of IPFS.

Regarding persistency: js-ipfs and the main ipfs (native go-ipfs) networks are not yet connected but we're very close to having that. Once they all communicate in the same network, we can provide a lot better persistency as users don't have to keep the tabs open in the browser.

Take a look at some of the examples of what can be done today with js-ipfs, that is fully in the browser:

https://github.com/haadcode/orbit (specifically https://github.com/haadcode/orbit/tree/js-ipfs)

https://github.com/ipfs/paperhub

https://github.com/haadcode/orbit-db

https://github.com/haadcode/proto2

Hi! (Another IPFS dev here :))

IPFS supports today WebRTC, TCP, uTP and WebSockets, thanks to the multi transport approach libp2p[0] offers. In fact, that is how Orbit works, a chat app build completely in JS, using IPFS, on the browser without any plugins. Check:

- http://orbit.libp2p.io/ - https://github.com/haadcode/orbit

The js-ipfs DHT is underdevelopment, in fact, we have an implementation, but it is not compatible with go-ipfs so we are not rolling it out, yet.

To check the latest updates on the project and learn whats next, check our log https://github.com/ipfs/js-ipfs/issues/30#issuecomment-22604...

[0] - libp2p is the network stack of IPFS, also a standalone project https://github.com/ipfs/specs/tree/master/libp2p

Something I've never understood regarding the "Bittorrent DHT" ... is it a singular hash table that's utilized for all BT activity, or are there many Bittorrent DHT's, and when somebody says "Bittorrent DHT" they're just referring to the concept?

The "Bittorrent DHT" is one big Distributed Hash Table [1] in the sky. As you participate, you become a node, and you'll receive a subset of the data in the entire node network. Here's a StackOverflow answer explaining the mechanics: https://stackoverflow.com/questions/1332107

There is actually another one called "Azureus DHT" which came first [2]. It's another big hashtable in the sky, and the Azureus/Vuze clients can connect to either DHT. All other clients only use the second one, the "Mainline DHT", which was an official extension to the protocol [3].

[1] https://en.wikipedia.org/wiki/Distributed_hash_table [2] http://www.bittorrent.org/beps/bep_0005.html [3] https://wiki.vuze.com/w/Distributed_hash_table

Thank you for helping me understand better.

I didn't know about it. I chose webtorrent because I potentially also wanted to have content created from the app to be long term on the torrent network if people are seeding the content.

There was a discussion about the world's oldest torrent, where others and I mused about solutions to the problem of ephemeral seeds: https://news.ycombinator.com/item?id=10962305

I suggested that one could maybe bridge Bittorrent and IPFS, then someone suggested that IPFS would be ideal for being the 'canonical' source of the file while the other protocols (HTTP, BT, WT) are merely ways to access the file.

The Internet Archive seeds all of our items' torrents since 2012. IPFS is a more straightforward way for us to be sure we've got independent seeds of all of our content. Got 25 petabytes of disk?

I've always wanted to write a distributed ArchiveTeam torrent server that, instead of distributing crawlers for ingestion, equally distributed IA torrents to distributed end-user storage (in a VM most likely). If seeding for a torrent dropped below a threshold, that torrent would be advertised to other client nodes to download and then serve themselves. Client VMs could come and go, and the announcer would always ensure remote storage was handled in an orderly fashion.

Perhaps this year is the year!

Uhhh, 20 GB free...

I'm just a third-party, but if you were to get in touch with the IPFS team to host a limited amount of IA content as a proof-of-concept, I'm sure it would be a great publicity for both of your organizations.

We're in touch with them, yes, and we have a proof-of-concept node.

> then someone suggested that IPFS would be ideal for being the 'canonical' source of the file while the other protocols (HTTP, BT, WT) are merely ways to access the file.

Hey! That was me! I still believe its a great idea ;)

Reply on news.ycombinator.com