{"action":"created","issue":{"url":"https://api.github.com/repos/webtorrent/webtorrent/issues/1492","repository_url":"https://api.github.com/repos/webtorrent/webtorrent","labels_url":"https://api.github.com/repos/webtorrent/webtorrent/issues/1492/labels{/name}","comments_url":"https://api.github.com/repos/webtorrent/webtorrent/issues/1492/comments","events_url":"https://api.github.com/repos/webtorrent/webtorrent/issues/1492/events","html_url":"https://github.com/webtorrent/webtorrent/issues/1492","id":355298971,"node_id":"MDU6SXNzdWUzNTUyOTg5NzE=","number":1492,"title":"Idea: WebSockets as an alternative to WebRTC","user":{"login":"feross","id":121766,"node_id":"MDQ6VXNlcjEyMTc2Ng==","avatar_url":"https://avatars2.githubusercontent.com/u/121766?v=4","gravatar_id":"","url":"https://api.github.com/users/feross","html_url":"https://github.com/feross","followers_url":"https://api.github.com/users/feross/followers","following_url":"https://api.github.com/users/feross/following{/other_user}","gists_url":"https://api.github.com/users/feross/gists{/gist_id}","starred_url":"https://api.github.com/users/feross/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/feross/subscriptions","organizations_url":"https://api.github.com/users/feross/orgs","repos_url":"https://api.github.com/users/feross/repos","events_url":"https://api.github.com/users/feross/events{/privacy}","received_events_url":"https://api.github.com/users/feross/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-08-29T19:24:01Z","updated_at":"2018-08-29T20:36:11Z","closed_at":null,"author_association":"MEMBER","body":"Lots of torrent clients can't add WebRTC support because the protocol is too complicated and difficult to integrate. This is slowing WebTorrent adoption in traditional desktop torrent clients. See https://github.com/transmission/transmission/issues/47, for example.\r\n\r\nI've been thinking about this a bit. It's probably possible to make something work over WebSockets. Here's a rough sketch.\r\n\r\n1. Desktop peers would run a WebSocket server and do whatever NAT hole punching they normally do (UPnP, NAT-PMP, tell the user to set up static port mapping, or just hope that the user has a public IP).\r\n\r\n2. Browser peers would discover desktop peers through normal means, so probably trackers and PEX for now (and eventually we could extend the DHT to support WebSocket in addition to UDP).\r\n\r\n3a. Browser peers connect to desktop peers using WebSocket using an address like `ws://12.34.56.78` when possible.\r\n\r\n3b. One complication is that the browser blocks connections to insecure origins (`ws://`) from secure origins (`https://`). So `ws://` can't be used all of the time. Ideally, we could use `wss://` instead. However that requires the WebSocket server to have a domain name and a certificate signed by a CA. 😢\r\n\r\n3c. Here's a workaround. Say a user on a secure web origin wants to connect to a desktop peer at `12.34.56.78`. They would connect to `wss://12-34-56-78.force-tls.com`. The `force-tls.com` domain would have DNS set up to return whatever IP is passed in the subdomain. So the DNS for `12-34-56-78.force-tls.com` would resolve to `12.34.56.78`. The `force-tls.com` domain would use wildcard certificate to ensure that all of these domains are signed. The secret key for this certificate would be public and any torrent app could use it in their WebSocket server.\r\n\r\n3d. So, in this system, TLS isn't actually being used for security. This is just a hack to help secure origins (`https://`) connect to WebSocket servers running in desktop peers without requiring those desktop peers to buy a domain name and get a TLS certificate that is trusted by the browser peers' browsers.\r\n\r\n3e. Anyone could run one of these \"force TLS\" services cheaply. They're generic and have nothing to do with the BitTorrent protocol, so it's likely risk-free to just run one of these as a public service, not unlike a DHT bootstrap node. It's just a DNS server that maps `12-34-56-78.force-tls.com` to the IP address `12.34.56.78`.\r\n\r\n4. Browser to browser connections, as well as desktop to browser connections would continue to require WebRTC. But if a desktop client does not want to support WebRTC (understandably), then they can still provide value to browser peers by running a WebSocket server to allow browser peers to initiate connections to them.\r\n\r\nThoughts?\r\n\r\n(I originally brainstormed this idea with @mafintosh and I was inspired by @diasdavid's work on js-ipfs.)"},"comment":{"url":"https://api.github.com/repos/webtorrent/webtorrent/issues/comments/417096955","html_url":"https://github.com/webtorrent/webtorrent/issues/1492#issuecomment-417096955","issue_url":"https://api.github.com/repos/webtorrent/webtorrent/issues/1492","id":417096955,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNzA5Njk1NQ==","user":{"login":"strypey","id":313316,"node_id":"MDQ6VXNlcjMxMzMxNg==","avatar_url":"https://avatars0.githubusercontent.com/u/313316?v=4","gravatar_id":"","url":"https://api.github.com/users/strypey","html_url":"https://github.com/strypey","followers_url":"https://api.github.com/users/strypey/followers","following_url":"https://api.github.com/users/strypey/following{/other_user}","gists_url":"https://api.github.com/users/strypey/gists{/gist_id}","starred_url":"https://api.github.com/users/strypey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/strypey/subscriptions","organizations_url":"https://api.github.com/users/strypey/orgs","repos_url":"https://api.github.com/users/strypey/repos","events_url":"https://api.github.com/users/strypey/events{/privacy}","received_events_url":"https://api.github.com/users/strypey/received_events","type":"User","site_admin":false},"created_at":"2018-08-29T20:36:11Z","updated_at":"2018-08-29T20:36:11Z","author_association":"NONE","body":"@lgrahl \r\n> From my perspective, it looks like there is no demand or no one is willing to implement it in which case an alternative wouldn't help.\r\n\r\nThere are Transmission folks saying they would be much more enthusiastic about supporting WebTorrent if it worked with WebSockets instead of (or as well as) WebRTC. Eg see:\r\nhttps://github.com/transmission/transmission/issues/47#issuecomment-416740849\r\n\r\nAs a user of an ancient netbook, I find PeerTube unusable, and I suspect WebRTC is the culprit, because none of the voice chat apps that use it (eg Jitsi Meet) work properly for me either. So although I can't help with implementation, I'd definitely +1 a WebSockets option."}}
{"actor":{"display_login":"strypey"}}