Hacker News new | ask | show | jobs
by niftich 2936 days ago
The post makes it sound like it's a copy of https://github.com/cjb/serverless-webrtc uploaded to IPFS; examining the code [1] shows that '23.21.150.121' is hardcoded for STUN.

This was seemingly set up by Wesley Dawson [2] at Mozilla in 2013, at which point it was an EC2 machine in AWS us-east-1. It subsequently made it into various gists and projects as a public STUN server.

Later in 2013 Mozilla changed over to using a hostname in Firefox instead [3], and much later Firefox 41 removed [4] Mozilla's STUN servers from being defaults.

I'm not sure how one would go about confirming that this service is still pro bono and not malicious, and whether it's likely to stick around in the future.

[1] https://github.com/cjb/serverless-webrtc/blob/master/js/serv... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=807494 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=920991 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1143827

3 comments

Thanks for that informative answer.

So we have a serverless web-chat with a stun-server that might go offline at any time.

I don't know a solution to do the chat really serverless. One option would be to use ethereums whisper, so we can use all eth-nodes to handle the webrtc-connection. This would not be 'really' serverless but at least surely work for a long time.

Ethereum is trying to be a lot of things and has some pretty severe architectural problems. I bet the Mozilla stun server lasts longer.
Exactly, how is STUN not centralized in this solution??
A single hard-coded STUN server is a big face-palm for a "serverless" chat app. `ipfs.io` could at least host their own STUN server. As long as they disable TURN, it shouldn't require much bandwidth. It's not like very many people are actually going to actually use this...
Too bad it isn't developed anymore. i already try to use it, but i was facing hard time with this lib.