
Serverless Sync in Web Apps Using Bit Torrent - kinlan
https://paul.kinlan.me/serverless-sync-in-web-apps/
======
kodablah
Neat use of web torrent. Now if only we could do it with live data instead of
persistent data, have built in encryption, and anonymize the peers we'd have
the perfect decentralized internet :-)

~~~
bytefactory
You mean something like this? :)

[https://zeronet.io/](https://zeronet.io/)

~~~
kodablah
Where is the anonymity? It is unreasonable to use TOR in my opinion because
despite being only a few exit nodes, it's not truly P2P then (and therefore
can be slow). Tribler tried something similar. Someone needs to build an onion
router of peers without defined relays or exit nodes (think of it as everyone-
is-a-relay TOR, it's one of my future ideas[0]). This will speed things up
substantially and can definitely work when you don't have the limitations of
TOR like working w/ all TCP connections (e.g. HTTP). Maybe they could make
every ZeroNet node a hidden service, I dunno.

Also, I have researched a lot about plausible deniability of publicly
available yet distributed data. I have never seen a system that stores public
data without them (clarity edit: node runners) being able to find out whether
they are storing a piece of something they don't like. I started a thread
about it on the Maidsafe forum recently [1]

0 - [https://github.com/cretz/software-
ideas/issues/2](https://github.com/cretz/software-ideas/issues/2) 1 -
[https://forum.safenetwork.io/t/unencrypted-data-
question/969...](https://forum.safenetwork.io/t/unencrypted-data-
question/9698)

~~~
dublinben
From what you've described, it seems like i2p would satisfy the requirements
of your first paragraph and Freenet would satisfy the requirements of the
second. Both of these networks have been around for over a decade, so they're
not as in vogue as newer projects.

~~~
kodablah
I have only slightly looked at i2p, but sadly appears the only impl requires a
JVM. I have researched freenet and it does not appear to provide plausible
deniability for public data (sorry on mobile and can't link easily).

~~~
icebraining
It does provide plausible deniability, since you have no control over what
files go to your node (files are spread as people request them) and they are
encrypted, hence you can't easily know what they contain.

~~~
kodablah
Both [0] and [1] seem to suggest that if you make the data "public" then
someone can know they have a piece.

"It is hard, but not impossible, to determine which files that are stored in
your local Freenet Datastore"

"Of course, the decryption keys, which are contained in links to the files,
may be publically posted on some other site - they have to be if the site
creator wants people to visit their site. But if you've never had knowledge of
that link, which is very plausible if there are thousands of Freenet sites,
you can't be expected to know what is contained in the encrypted files in your
Freenet node."

0 - [http://security.stackexchange.com/questions/12811/how-
does-f...](http://security.stackexchange.com/questions/12811/how-does-freenet-
maintain-access-to-freesites-while-retaining-plausible-deniab)

1 -
[https://wiki.freenetproject.org/Plausible_deniability](https://wiki.freenetproject.org/Plausible_deniability)

------
_bdog
Now someone could make a Chrome plugin for YouTube, which seamlessly seeds the
watched videos and, when it goes offline, loads from Bittorrent.

~~~
anonbanker
Or when the site gets a DMCA takedown request. Or when content is blocked in
your country.

There seriously needs to be a Youtube killer, and this would be a good
starting point.

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

~~~
kodablah
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/](https://github.com/ipfs/js-ipfs/)

~~~
lewisl9029
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](https://github.com/ipfs/js-
ipfs/blob/master/ROADMAP.md)

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

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

~~~
niftich
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](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](https://en.wikipedia.org/wiki/Distributed_hash_table)
[2]
[http://www.bittorrent.org/beps/bep_0005.html](http://www.bittorrent.org/beps/bep_0005.html)
[3]
[https://wiki.vuze.com/w/Distributed_hash_table](https://wiki.vuze.com/w/Distributed_hash_table)

~~~
uptown
Thank you for helping me understand better.

------
martinald
Very cool. I imagine when bittorrent first starting how cool this would be to
do if we had something like webtorrent

Two problems:

1) WebTorrent isn't very persistent. It requires people keep the tab open and
I don't think the current WebTorrent to existing torrent clients federation
really solves anything interesting. Unless you've got high volumes of traffic
it doesn't help much.

2) Bandwidth and storage got so cheap. S3 et al is really pricey but you can
get insane deals on colo and bare mental boxes these days. Ok, you're not
going to get s3 ease of use and reliability, but webtorrent is going to be way
worse on both those points.

~~~
niftich
S3 can serve over the Bittorrent protocol though.

In fact, there are several viable configurations to bridge between WebTorrent,
Bittorrent, and S3. For example, you can have S3 directly serve over
Bittorrent and use Amazon as a tracker; or you can have the HTTP URL to S3
serve as a BEP19 webseed, which is now supported in recent WebTorrent.

~~~
kinlan
/me runs to learn more.

~~~
diegorbaquero
Check this: [https://medium.com/@diegorbaquero/how-to-create-a-swarm-
cdn-...](https://medium.com/@diegorbaquero/how-to-create-a-swarm-cdn-for-free-
with-webtorrent-bfa09d193f71)

~~~
kinlan
thanks!

------
michaelbuckbee
So I only kind of understand magnet links. But it seems like I could create a
Chrome plugin that took every page I visited and turned the assets into magnet
links and started request/seeding them on pageload. Is that analogous to what
they're doing?

~~~
kinlan
You need access to the Blob data to seed that. You could get that by making
HTTP requests to each of the resources on the page and then to seed that
(however, as soon as you navigate away from the page there are no more seeders
so the data is no longer available)

~~~
michaelbuckbee
Well plugins are powerful things - I bet you could cache blobs in the browser
for a bit as long as it was still open.

------
moosingin3space
This is really cool. Wonder how hard it would be to develop double-ratcheted
multi-user chat or a distributed game using WebTorrent.

------
235337
Anyone have suggestions on how to block sites like this from downloading
without permissions?

edit: So blocking XHR requests seems to do the trick.

------
visarga
The app is quite interesting and I was amazed until I realized the play button
doesn't display the circular progress indicator on time. It has an ugly lag.
This is why web apps are not quite there yet. And yet it is amazing they can
record, store and sync audio like that. Almost like real apps.

~~~
kinlan
That is me being lazy and showing a demo/concept experience, not because the
web platform can't do this.

------
mdjeu
Maybe this a bit tangential, but I was just thinking lately how it would be
nice to use some decentralized communication backend to word processing
software to enable shared collaborative editing of documents. Sort of like
Google Docs, but without a centralized server.

------
pmlnr
If there wasn't a 'cloud' in the picture how seeding is done I'd even believe
it's serverless. Sorry for being a cynic, but what if there is no tracker
available?

~~~
kinlan
It's a very fair point, I chose the word serverless to imply no traditional
back-end. One extension that I am looking forward to seeing is the use of DHT
in to the WebTorrent that (at least in my head) can eliminate the need for
trackers.

The important point in my head is that I can distribute audio files to anyone
who is seeding client-to-client rather than pass through a traditional server
that I would host.

------
solidr53
I was surprised to find out that the torrent fetching part of the prototype
didn't happen in the service worker . Which is obviously the most cool place
for it.

------
zeveb
This sounds really cool, but it also sounds like a really easy way for malware
(delivered, say, in a drive-by malicious ad) to exfiltrate data from a
browser.

~~~
kinlan
In this case, the content is only stored local to the domain - sure someone
could put the data that is some sort of Malware as the file that is synced,
but they could also HTTP request it too...

The theory at least is that the sandbox of the browser will stop it from
getting out from there and keep the user safe.

~~~
kinlan
Worth thinking about more though!

------
chj
It's great to share data, however, how can a torrent solution support services
like web API?

~~~
geocar
Well, one way I did it was by creating fake torrents with an unlikely
info_hash (if you see the all-0xaa's hash on bittorrent crashing your client a
few weeks ago, that's me).

In this way, I can get use public WebTorrent signalling servers to establish
the WebRTC connections between my (non-bittorrent) clients.

You can distinguish between clients and servers (if you don't want a P2P
model) by having clients claim to need this unlikely info_hash, and servers
seed it. In this way, WebTorrent's websockets server won't link clients to
other clients.

