4kevinking

Hello Hackernews!

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

https://bigroom.video here's a clickable link since HN doesn't parse URLs in the description :)

I'm actually getting this spam now (started a couple months ago). Would love advice on how to get rid of it!

Thanks for the feedback! You can copy an escaped version by clicking the icon in the upper-right.

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

That's a mocked-up css animation, not a video of the actual email. Feel free to try the demo in the API dashboard to see the full UX.

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.

Hi HN!

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.

Looking forward to your questions and feedback!

Sorry for the inconvenience. You can also find the install instructions on the help screen of the app.

Good to hear you're liking U2F on Krypton. Android support was released last week, and Firefox/Safari support is coming soon!

krypt.co | Software Engineer | Boston, MA | Full-time | Onsite | https://krypt.co/jobs

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.

Reach out to us at hello@krypt.co

kryptco.co | Software Engineer | Boston, MA | Full-time | Onsite | https://krypt.co/jobs

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.

Reach out to us at hello@krypt.co

Point taken, the intention is to make each command more succinct and we overloaded the functionality of `kr add` to do so.

`kr add` will add your public key if no members are specified. The user being modified is whichever is being logged into. So if you have an ssh alias "bastion" that specifies user "jump" in your SSH config, `kr add bastion` adds your public key to user "jump". Just like when SSHing into a server, you can override the default user in the form `kr add user@bastion`.

This is only the first iteration of `kr add`, and we will be adding more advanced access control in the near future, including authenticating as one user but modifying another.

Totally agree with 3., we'll add this to our roadmap.

Thanks!

Yes in this case the Krypton SSH key pair is long-lived, but the certificate issued to it by the server would be short-lived.

How are users authenticating to this 2FA CA in the first place? Instead of using username/password and 2FA, users could authenticate to the CA using Krypton and then use the issued certificate for short-lived access.

If Krypton using a long-lived SSH keypair is a non-starter, automatic key rotation could be added down the line (sort of like being forced to change your password but this would be automated).

The SSH key stored in Krypton can be signed just like a local key-pair. The public key is stored in ~/.ssh/id_krypton.pub and SSH will look for the cert at ~/.ssh/id_krypton-cert.pub.

Windows support is slated for the first half of this year (you can follow this issue: https://github.com/kryptco/kr/issues/87 ). In what environment did the kr install fail? We only currently support Bash on Ubuntu(16+) on Windows.

Krypton Core (storing/using your SSH/PGP keypair) will be free forever. Stay tuned over the next couple months for updates regarding the teams product.

Thank you for letting us know. We have a fix for this in the pipeline and will update the issue when it's released.

In both cases you would lose access to your key, similar to losing a Yubikey. You can find instructions for provisioning a backup phone here: https://krypt.co/docs/start/backup.html . The upcoming teams product will make backup as simple as having multiple team admins that can re-provision each other in the event one loses their phone.

Yes, Krypton also works over bluetooth (currently implemented on Mac and iOS/android).

We currently support Bash on Ubuntu on Windows, but PuTTY/Cygwin support is further off.

A code execution exploit on your Android phone would result in being able to approve automatically, but without Kryptonite, a trojan in _any_ of the apps on your computer could steal your SSH key and use it unhindered, like what recently happened to Handbrake [https://threatpost.com/handbrake-for-mac-compromised-with-pr...]

great to hear, thanks!

fish shell should be working now, let us know if you have any other issues!

Correct, we currently only support one key, but multiple key support is in the works!

I think you may have misunderstood our architecture. SMS doesn't play any role in Kryptonite and all communication between the phone and computer is encrypted and authenticated. Check out a full explanation of the architecture here: https://blog.krypt.co/the-kryptonite-architecture-a385e7aaa3...

Thanks, will fix this asap. We have tested on bash, zsh, and fish on macOS but it seems we missed an edge case. I'll follow up with your ticket.

The current version is designed for hosted services like GitHub, redeployable infrastructure, and servers to which multiple people have access. We totally understand your use case and are actively working on implementing transferring a key to another device or printing out a paper backup.

Point taken. Unfortunately when you touch the key you still can't verify exactly what you are approving.

That is correct. We will also soon release a way to copy a key from one device to another by scanning a QR code.

I didn't realize that, thanks for letting us know! We're actively working on this