The Unclear Impact

https://file.love/

Peer-to-peer file transfers in your browser. Painless file sharing, without installing any torrent clients 💞

Opensource, made by @midzer

@fribbledom @midzer This is pretty neat. Tested it with a silly video file: https://file.love/#e0514ebc33755e0b4e7102ed2224efa12145ea23

@fribbledom thank you very much! @midzer

@fribbledom @midzer awesomesauce.

I assume it uses RTCDataChannel? Asking, because I was looking at using it for a similar purpose, but in my case I need to use it inside a Service Worker, which I believe is not possible currently?

@rysiek @fribbledom AFAIK a (public) STUN server is used to handle out IP negotiation. A secure WebSocket connection to a (public) WebTorrent tracker handles the metadata between the peers.

I don't know whether you can establish a WebSocket connection in a service worker. This might be interesting as inactive/background tabs do throttle the transfer right now.

I might consider introducing a service worker for PWA functionality though.

@midzer @fribbledom interesting. WebSockets are available in Service Workers. But you said that's just metadata? How is *data* transferred?

@rysiek @fribbledom I'm not to deep into the BitTorrent protocol. All I know is, the initial seeder keeps the file(s) in memory and creates a metadata (.torrent file -> infohash) files which is (temporarily) registered on the public tracker via WebSocket connection.

Other peers connect to the tracker as well via the infohash. STUN server allow a direct connection between those peers (with WebRTC I guess).

@midzer @fribbledom right, thanks!

re: javascript

@rysiek looks like the newest webkit is supporting transferring RTCDataChannel to a service worker: https://wpt.fyi/results/webrtc-extensions/transfer-datachannel-service-worker.https.html?label=experimental&label=master&aligned although I imagine that’s not very useful atm, since other browsers completely lack support, and RTC connections cannot be created in the worker itself at any case

you’re probably already familiar with the relevant webrtc issue: https://github.com/w3c/webrtc-pc/issues/230 which explicitly highlights peer-to-peer content delivery as a use-case. interestingly, the last comment says that transferring to a service worker is not yet implemented even in safari, but things seem to have changed since then according to wpt

unfortunately, google seems to have blessed their http3-only webtransport https://web.dev/webtransport/#is-webtransport-an-alternative-to-webrtc-data-channels as a way to open datagram connections in workers, which doesn’t support peer-to-peer connections at all. so I wouldn’t hold my breath for service worker webrtc support in chrome blobfoxsad

@fribbledom @midzer

re: javascript

@kristof @midzer @fribbledom thanks a lot for this explanation! Yes, I am aware of the relevant WebRTC issue, but had no idea of the additional context. This is very useful.

re: javascript

@rysiek btw, this is a bit silly, but could a service worker just use sendmessage to communicate with the main page which hosts an RTCDataChannel in lieu of instantiating an RTCDataChannel itself?

this idea comes from the fact that the current API (as implemented by Safari) needs a webpage to establish the RTC channel, which then gets sent to the worker (and probably only lives as long as the page is open). so in practice, the worker first has to serve some kind of shim webpage and script, which establishes the channel and sends in to the worker – then the worker could use the channel to answer further requests

so the silly thing to do would be to (in absence of RTC channel transfer support) establish the channel in the shim webpage, and notify the worker of this fact via a message. subsequently, on any fetch request the worker would send a message to the webpage, and the webpage would answer with another message transferring some buffer with the request data. this is of course completely backwards, but FetchEvent.respondWith does take any promise, and Response objects can be created from scratch (albeit with some CORS caveats)… blobcatscience

@midzer @fribbledom

replies
1
announces
0
likes
0

re: javascript

@kristof @midzer @fribbledom
> btw, this is a bit silly, but could a service worker just use sendmessage to communicate with the main page which hosts an RTCDataChannel in lieu of instantiating an RTCDataChannel itself?

In general terms: sure, this is actually used by an js-ipfs example somewhere.

Specifically for my project: no, the point is to have a way to fetch content even before any HTML is loaded (provided that the SW has been installed before):
https://resilient.is/