Show HN: We made a proximity-based video chat for events

Show HN: We made a proximity-based video chat for events(unnamed.chat)

11 points by otaviogood 5 years ago | 3 comments

otaviogood 5 years ago |

25 person Zoom calls aren't fun. So me and my friends made a virtual gathering space for people to host online events, meetups, social hours, etc.

Tech: Frontend uses Svelte / Snowpack, which is great. The game view uses the DOM, which is questionable, but my webgl implementation wasn't so hot either.

Backend is Firebase for general stuff, server written in Golang for the realtime game stuff, and another Golang server for video.

Main techincal lesson learned so far: WebRTC sure is a pain to get right across everyone's devices, browsers, and connections.

kwindla 5 years ago | |

Cool!

The good news is that the browser/device/connections issues have gotten so, so much better! All the browsers now mostly agree on aiming towards full compliance with the WebRTC 1.0 spec. The likelihood of something important breaking in a browser release is trending downwards. And the encoding -> network -> decoding pipelines in libwebrtc are pretty robust and performant these days.

But, as someone who has been doing WebRTC stuff since 2014 or so, and started a company that's in part a bet on the WebRTC ecosystem, I have a lot of scars from how long it took to get here. :-)

I'm biased, but I would say that there are still three classes of non-trivial difficulty that add up to "you shouldn't build everything yourself" being the right answer if you're building WebRTC-reliant features that you want to deploy to production:

  1. cross-device issues are still painful and still a moving target

  2. network bandwidth and track/encoding configurations for any use cases more complex than 1:1 calls are a steep learning curve plus lots of corner cases

  3. devops as you scale usage is a lot of work because there aren't any off the shelf cloud provider things you can just turn on and expect to work

Platforms that will take care of (parts of) the above for you include Agora, Vonage, Twilio, and (my company) Daily.co.

otaviogood 5 years ago | | |

Maybe we should have tried Daily. :) We tried Twilio video and unfortunately had a really hard time tracking down bugs. Wasted tons of time on that and then went back to doing our own stuff. :( I still don't know where the bug was. Could have been our code or Twilio's. But when we got rid of Twilio and used our own stuff, it resolved the bugs. Was a very frustrating process. Also, the way Twilio video charges seems to assume lots of n-squared, high res connections, which we don't have, so for an application like ours, the cost can be more than 10x less.

1. cross-device issues are still painful and still a moving target 2. network bandwidth and track/encoding configurations for any use cases more complex than 1:1 calls are a steep learning curve plus lots of corner cases 3. devops as you scale usage is a lot of work because there aren't any off the shelf cloud provider things you can just turn on and expect to work