Webtorrent is a modification to the bittorrent protocol to allow it to be used from a web browser with no plugins/extensions.
It's built on top of WebRTC.
Webtorrent and regular torrents can exist of the same file, but crucially, at least some small percentage of the people in the network have to support both webtorrent and regular torrent to act as a kind of bridge between the two.
If this isn't the case, you might have a webtorrent user who has the file, and a regular torrent user who wants the file, but the two people can't connect to eachother because they're talking different protocols, so the file won't be delivered.
Simply seeding for the 1+ hour you are watching the movie is typically enough to keep a torrent swarm healthy now that the majority of users have 10 Mbps+upload speeds. In that time, you can easily upload more data than you downloaded, meaning you are a net benefit for the swarm.
In a general sense, any video content where the bitrate is lower than the typical users upload bitrate could work for a webtorrent only swarm of 'regular' users who aren't going to do anything special for network health.
Only if they seed more than they leech. It has little to do with time. If you take a year to seed more than you leeched, you're a positive contribution to the swarm.
Problem is: they can't watch movies in their browser because they can only leech from people who are seeding from a webtorrent client.
Let's say I have a movie I want to let other people stream with their browser. I am obligated to use some javascript horror webtorrent-compatible client. If I already have a seedbox running transmission I simply cannot use that for this purpose, which is a shame
So where would transmission support come into play ? In being able to recognize files that include both web and regular torrent ? Or in being to transparently talk to web clients from transmission ? Both ?
> In being able to recognize files that include both web and regular torrent
The actual .torrent file is the same for both, so it already has support there.
> Or in being to transparently talk to web clients from transmission
This. Currently if all peers who have the data of a torrent are webtorrent clients, then transmission won't be able to download that file.
Most importantly, the webtorrent ecosystem is still small, and browser-based webtorrent-only clients suffer because frequently they can't get the file data they need because all the other peers only talk the original-torrent protocol.
Well, webtorrents are just regular torrents using websockets as a transport mechanism, since you can't just have raw sockets from a browser sandbox.
If it supported these as a transport mechanism, transmission would be able to communicate with torrent clients that run in the browser, making the potential number of peers much higher (both for swarms that are mostly in-browser, and for those that have a majority of traditional clients). It would be very useful for seeding peertube videos from transmission, for instance, which was the quoted use-case.
Webtorrent allows you to download torrents from a stock iPhone: you use a JavaScript interpreter from the app store (that is allowed as per the app store guidelines, same for Python interpreter), then just run Webtorrent that works in JavaScript only. Like that I downloaded a lot of things while outside.
Wait, you're not allowed to run anything using the BitTorrent protocol on iOS? I never had the need myself, but I just assumed it would be allowed, because there is no reasonable explanation you wouldn't. Like the whole protocol is banned from the AppStore?
As soon as it lands in transmission, I will start seeding my favourite peertube videos 24/7, and I hope others will do the same. Unless peertube videos are typically being seeded like this, I'm sceptical of the platform.
That was done recently in https://github.com/arvidn/libtorrent/pull/4123, merged to master, but hasn't been released yet.
Per the master changelog, that should be soon, I guess... https://github.com/arvidn/libtorrent/blob/master/ChangeLog