13 ms·

Launch HN: Hyperbeam API (YC W22) – Multiplayer embeds of any website

96 points by declan_g 5y ago

Hi HN, we’re Philip, Amby, and Declan from Hyperbeam (https://www.hyperbeam.dev https://www.hyperbeam.dev). Hyperbeam is an API that makes it easy for developers to embed real-time multiplayer capabilities into their web apps—including any other web app that you want to provide multiplayer access to. Building software to connect people in real time is hard. We experienced this in college when we built a “watch party” site for people to watch movies together (https://hyperbeam.com https://hyperbeam.com). Other watch party solutions were unreliable, so we spent two years building tech to allow friends to watch stuff together with ease. The key piece was a “multiplayer web browser”. By that we mean a Chromium instance that you embed inside your own web app (i.e. web browser inception) which is actually hosted on a server and streamed via WebRTC, and so can be shared and controlled by multiple people at the same time. For example, say you have an online tutoring platform. An instructor can open any application in the embedded web browser and then work on it with the student together. Another use case is making non-multiplayer apps multiplayer. One of our customers wanted to add a collaborative version of Google Slides to their product, so multiple participants could navigate the slides at once. Google doesn't provide an API for that, so users had to screen share, which isn't multiplayer. With Hyperbeam, you just open up a shared instance of Google Slides and then multiple people can control it. We didn’t learn about those use cases until later, though. What happened was that we grew hyperbeam.com to 150k monthly active users and over 1M hours of video per month, but then it stopped growing. Despite this, we got into YC, and soon had multiple companies asking to buy our multiplayer browsing tech. After closing three deals, we decided to sell our multiplayer web browsers as an API. That way other companies can build products to connect others without going through two years of WebRTC hell like we did. We allow developers to embed multiplayer web browsers in their web apps with a few lines of code. Users can then visit any website from inside that web app together. Developers can specify control permissions, programmatically navigate to specific URLs, and hide the browser UI so apps appear as if they are natively integrated. Unlike screen share solutions that upload your personal computer stream to participants, Hyperbeam’s multiplayer web browsers run on our own virtual machines. This eliminates the upload speed bottleneck that many users experience. We host a Chromium browser instance on our server, record the video and audio output and stream it to all participants using WebRTC. That sounds simple, but hosting full-blown Chromium instances is challenging, especially doing it cost-effectively: what we learned is Chromium instances, at scale, love memory bandwidth a lot more than the amount of memory. Also, network unreliability, like last-mile packet loss, is also a problem, especially audio packet loss which is a lot more noticeable than video packet loss. A simple hack we have in place is literally sending every audio RTP packet twice, which improves audio quality drastically over spotty connections. Anyone is welcome to get a free playground API key and try our product! Rather than spend time building a UI for that, we’ve just put up a Google Form in the spirit of do-things-that-don’t-scale. Go to https://forms.gle/RSQhbFXbdrcqwqsc9 https://forms.gle/RSQhbFXbdrcqwqsc9, fill in your email and we promise to send you an API key right away. The API docs are here: https://showy-backpack-b3f.notion.site/Hyperbeam-API-eb9874bd1ef54c22ba7197324ce22231 https://showy-backpack-b3f.notion.site/Hyperbeam-API-eb9874b... Pricing is not transparent on our website yet—we’re still working it out. However, we’re going to use the same business model as CPaaS companies such as Agora and Twilio. We’ll charge customers a minimum amount per month and provide a set amount of participant hours. If a customer exceeds the provided participant hours, we continue charging at a fixed rate. If you want to try our tech in action, you can do that by signing up for free and creating a room using our original Hyperbeam watch party platform: https://hyperbeam.com/app/register https://hyperbeam.com/app/register Alternatively, we'll be answering questions live in our HN watch party here: https://gg.hyperbeam.com/invite/w0c6n-Ko https://gg.hyperbeam.com/invite/w0c6n-Ko We’re happy to answer any questions you have, and would love to hear your ideas for other potential use cases as well. Thanks!

vgel 5y ago
Since AFAIU it's a video stream without any DOM, is there any accessibility affordance?
- ambyjkl 5y ago
  Currently, we do not have accessibility support for the browser, we only do the video stream. The reason we haven't worked on this yet is because of our focus on watch parties, and the video stream being streamed was usually that of a video itself, so not a lot of accessibility could be added to that use case. But now that we are looking at the bigger picture, we could implement full-fledged accessibility support where we serialize the accessibility tree and send that over instead of the video stream.
  - vgel 5y ago
    Good to hear it's on the roadmap!
mwcampbell 5y ago
Congrats on your launch. I do have one concern though: > a Chromium instance that you embed inside your own web app Have you considered the accessibility ramifications of this, e.g. for blind people using screen readers? It will certainly be possible to make this accessible; indeed, that's an advantage of your approach over screen sharing. It won't be easy, but of course I believe it's still important and worth doing. My email address is in my profile if you want to discuss this further.
- ScottyFillups 5y ago
  Thank you! > Have you considered the accessibility ramifications of this, e.g. for blind people using screen readers? We are considering the accessibility ramifications now since we've pivoted toward a general API. We didn't focus on accessibility for blind people initially because we were building a watch party platform. I think offering accessibility features would give us a massive edge against technologies like screenshare! Is there a specific use-case you're thinking of?

96 points by declan_g 5y ago

vgel 5y ago

Since AFAIU it's a video stream without any DOM, is there any accessibility affordance?

ambyjkl 5y ago
Currently, we do not have accessibility support for the browser, we only do the video stream. The reason we haven't worked on this yet is because of our focus on watch parties, and the video stream being streamed was usually that of a video itself, so not a lot of accessibility could be added to that use case. But now that we are looking at the bigger picture, we could implement full-fledged accessibility support where we serialize the accessibility tree and send that over instead of the video stream.
- vgel 5y ago
  Good to hear it's on the roadmap!

mwcampbell 5y ago

Congrats on your launch. I do have one concern though: > a Chromium instance that you embed inside your own web app Have you considered the accessibility ramifications of this, e.g. for blind people using screen readers? It will certainly be possible to make this accessible; indeed, that's an advantage of your approach over screen sharing. It won't be easy, but of course I believe it's still important and worth doing. My email address is in my profile if you want to discuss this further.

ScottyFillups 5y ago
Thank you! > Have you considered the accessibility ramifications of this, e.g. for blind people using screen readers? We are considering the accessibility ramifications now since we've pivoted toward a general API. We didn't focus on accessibility for blind people initially because we were building a watch party platform. I think offering accessibility features would give us a massive edge against technologies like screenshare! Is there a specific use-case you're thinking of?