
PeerJS simplifies WebRTC peer-to-peer data, video, and audio calls - based2
https://peerjs.com/
======
villgax
Peerjs is dead, simple-peer([https://github.com/feross/simple-
peer](https://github.com/feross/simple-peer)) is more of a maintained one.

~~~
preya2k
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.

~~~
joshontheweb
Worth noting that simple-peer has a companion library simple-signal for the
signaling side.

------
abhinai
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.

------
dane-pgp
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:

[https://w3c.github.io/webrtc-identity/](https://w3c.github.io/webrtc-
identity/)

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.

~~~
kodablah
> 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).

0 - [https://myscreen.live/faq.html#q-how-it-works-
detail](https://myscreen.live/faq.html#q-how-it-works-detail)

~~~
dane-pgp
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.

------
resource0x
Lovely hack - WebRTC using firebase notifications:
[https://websitebeaver.com/insanely-simple-webrtc-video-
chat-...](https://websitebeaver.com/insanely-simple-webrtc-video-chat-using-
firebase-with-codepen-demo)

------
snissn
is peer js still being maintained?

