It‘s not exactly dead, but also not very active either.
Thanks for suggesting simple-peer. But as far as I can see it does not offer a simple signaling approach like PeerJS. In PeerJS you can just use a simple ID to connect two peers. Either by using the public PeerJS signaling Server or by hosting your own instance.
I love the API but something about the developers doesn't look right. One of the developers has their twitter account suspended while the other has their github account not working. The activity on the project itself seems to be fairly recent though so it is all very confusing.
What I haven't found is a peer-to-peer way of mutually-authenticating identity for a WebRTC connection. Perhaps it is possible to build it out of this:
but it seems that the assumption is that a remote domain acts as a trusted match-maker. Ideally two peers could use a pre-shared secret or an offline-signed message to authenticate instead.
If this were possible, then two browsers could act as a basic serverless VPN, layering an encrypted link over the WebRTC data channel which is safe even against an SSL-decrypting MitM.
Key distribution is generally the weakest link in any public use crypto system, both because it's a fundamentally hard problem and because people are the weakest link. If you built a "peer to peer" crypto system based around offline token sharing for identity, 99% of your users would email or text message their secrets to each other and more importantly 99+% of your users would accept a token they received from the other party that way.
> Ideally two peers could use a pre-shared secret or an offline-signed message to authenticate instead
You can easily share offers and answers that are encrypted offline. It's how you share (i.e. signaling) that's the problem. I used gun.js the other day, and I used a js nacl impl to encrypt the offer/answer each way[0]. As the ipfs js dht gets better you'll be able to use that. Where you'll need a trusted third party is if you need a turn server due to firewall/nat issues (some say approx a quarter of net users).
That's incredible, and extremely close to the hypothetical use case I was imagining, which I thought was impossible to solve.
Could you adapt that technology into a system for allowing a computer in one location to browse the web using the (relatively unrestricted) network connection of a computer in another location?
I'm thinking of times when you're away from home (where your PC is running) and stuck using a web browser on another PC that has an aggressive filtering and/or monitoring policy. That's why in my threat model I imagined that there was a MitM that effectively operates a trusted CA.
The difference between screen sharing and being a web proxy is presumably that the "sending" browser is also accepting navigation requests (from the "receiving" browser) which control the URL and scrolling/clicking of an iframe in the page that hosts the web app itself. I suppose that capturing the clicks on hyperlinks would be the hardest part, unless you could do some clever conversion between pixel locations and DOM elements.
The TURN server doesn't need to be trusted as it never receives keys or sees unencrypted traffic, it only forwards encrypted traffic. It can still track metadata (who you're transferring data to), but it doesn't need to be trusted any more than your ISP.
