Over the last couple of months I have been working on a new way to have social events over video (https://bigroom.video).
As with the rest of the world, my last company transitioned to being completely remote with the rise of covid. We tried to emulate our old lunchroom and bar happy-hour dynamic over Zoom, but found that we could really only have one person speak at a time. With a 20 person Zoom lunch, this turns into each person telling a story one-by-one, people stepping on each others' toes, and a loss of the small dynamic conversations that would normally happen at any social event.
Bigroom has two major features that help bring the dynamism back to socializing.
Dynamic channels let you break off into a separate conversation with one click. At any social event I've been to, people are always separated into groups of 3-6 and individuals bounce between those groups. Dynamic channels allow this behavior without the rigidity of Zoom breakout rooms.
Whispering temporarily mutes your audio to everyone except one person. Click-and-hold on someone's video to start whispering, and let go of your mouse to stop. It's possible for two people to have a complete 1-on-1 conversation within a large group of people by whispering to each other.
Bigroom works on desktop Chrome, Firefox, and Safari, with mobile support planned. On the technical side, Bigroom consists of a web client and a websocket server, both written entirely in rust. I used the elm-like yew framework compiled to wasm for the frontend and async-tungstenite for the websocket backend. The entire client app compiles down to <1MB.
All video and audio is transmitted over peer-to-peer WebRTC connections. This puts a natural limit to how many people can be actively using video in a single channel (depending on the computer I find it is between 10 and 20), although I am considering a client-server architecture in the future to make it scale similarly to zoom.
Bigroom is in free open beta and doesn't even require an account to use.
This will sound facetious, but I mean it sincerely. Change email provider. I was an original "invite only" user of GMail. Eventually, I got so sick of Google's complete u-turn on their original philosophy that I changed, despite the cost in time and effort that decision entailed. It's worth it. But I will recommend you choose providers carefully. If you're not paying for it in some way (e.g. Fastmail), be concerned. Also, the ability to use your own domain is a huge boon (you'll never have to go through the excessive email-change pain again).
Thanks for the suggestion! This is on our product roadmap.
One way to track users is also to specify approve/reject redirect urls with random tokens (though we agree that private metadata is more ergonomic in this case).
AWS doesn't yet support U2F, but once they add it Krypton would work as well.
We don't currently support importing SSH private keys but are considering it in the future. You can upload your public key to AWS IAM (they only support RSA) and other cloud providers through the normal methods. `kr me` prints out your public key and it can be pasted in anywhere a local SSH public key would be added.
We've made it possible to use your phone as a U2F authenticator. Just download the Krypton app and browser extension, then pair your phone to your browser by scanning the QR code. Our goal is to make unphishable 2-factor authentication more accessible, especially to users that don't want to purchase and carry around a separate hardware fob.
I wish you just had the workstation download on the homepage again. I had to find your homebrew bottle GitHub repo to figure out how to install Krypton on my new MacBook.
Join us in fixing authentication using strong cryptography on mobile.
We are a rust-first shop, running the same rust code on iOS, Android, macOS, Linux, AWS lambda, and web. You will help us refine the core product, add new controls and multi-party authentication to the teams infrastructure, and design and develop integrations between existing identity providers and Krypton.
We're looking for engineers passionate about both systems security and user experience.
Over the last couple of months I have been working on a new way to have social events over video (https://bigroom.video).
As with the rest of the world, my last company transitioned to being completely remote with the rise of covid. We tried to emulate our old lunchroom and bar happy-hour dynamic over Zoom, but found that we could really only have one person speak at a time. With a 20 person Zoom lunch, this turns into each person telling a story one-by-one, people stepping on each others' toes, and a loss of the small dynamic conversations that would normally happen at any social event.
Bigroom has two major features that help bring the dynamism back to socializing.
Dynamic channels let you break off into a separate conversation with one click. At any social event I've been to, people are always separated into groups of 3-6 and individuals bounce between those groups. Dynamic channels allow this behavior without the rigidity of Zoom breakout rooms.
Whispering temporarily mutes your audio to everyone except one person. Click-and-hold on someone's video to start whispering, and let go of your mouse to stop. It's possible for two people to have a complete 1-on-1 conversation within a large group of people by whispering to each other.
Bigroom works on desktop Chrome, Firefox, and Safari, with mobile support planned. On the technical side, Bigroom consists of a web client and a websocket server, both written entirely in rust. I used the elm-like yew framework compiled to wasm for the frontend and async-tungstenite for the websocket backend. The entire client app compiles down to <1MB.
All video and audio is transmitted over peer-to-peer WebRTC connections. This puts a natural limit to how many people can be actively using video in a single channel (depending on the computer I find it is between 10 and 20), although I am considering a client-server architecture in the future to make it scale similarly to zoom.
Bigroom is in free open beta and doesn't even require an account to use.
Looking forward to your feedback!
-Kevin