Show HN: I built a fun video meeting app with 2D physics and proximity chat (flat.social)
Hi HN!
https://flat.social is a web video meeting app for organising fun online meetings & social events. Each participant can move around and talk with others in their proximity.
Here is a quick demo if you wanna see it in action: https://youtu.be/Y2yH3twjrx4
I’ve been on it solo for around a year right now. Tech used is Next.js, Typescript, PIXI.js on the front-end and Node, Mediasoup, Socket.io and Matter.js (physics engine) on the backend.
Feel free to jump in into the demo room (https://flat.social/f/Flat.Social-Demo) to say hi, I’ll be hanging out there throughout today.
Would love to hear your thoughts on it!
67 comments
[ 4.0 ms ] story [ 253 ms ] threadGreat work! I loved how responsive it's. There is fun to play with animations. The flying emojis, and animations!!!
Love the backgrounds but needs some improvements as well :)
What’s the future revenue model? How expensive are the servers?
I'm experimenting with the revenue model right now, would be happy to hear any input on the current pricing I set out.
As per the servers cost - it's directly correlated to the usage. It runs audio, video and physics on the backend so high CPU instances are needed to run it smoothly. It's quite optimised for now though and a couple droplets are enough.
There is also some super interesting middle ground between full video forwarding and selective reencoding by using SVC for cheap video resizing on the backend.
Bandwidth will be a high cost no matter what (and anyone planning to scale up real-time video better be prepared to move off the cloud at some point) but needing compute resources for encode/decode on the backend makes large scale realtime video infeasible for any reasonable cost. The only successful large scale deployments push most compute work to the clients.
An extra decode/encode step also adds latency and the total latency budget before UX is impacted is small.
Even with say n=5, P2P pushes the required upstream bandwidth beyond what is practical with tight realtime constraints on a surprising proportion of home and office connections, especially when Wi-Fi is involved. SFU cuts the upstream bandwidth requirement to be constant rather than a factor of how many other participants are in the conference.
There's also the fact that a significant proportion of offices, and an increasing proportion of homes, simply cannot establish the needed P2P connectivity due to double NAT, firewall, etc. For them you'll be providing a TURN server, which brings back the bandwidth requirement.
The bandwidth costs, if you move off the clouds, are actually quite manageable compared to the compute costs if you try to do decode/encode on the servers.
If we are talking about doing realtime video at large scale, we can assume that there is good ops competency in-house. If not, honestly, what are you doing?
Managing fleets of servers across several of the "automation-friendly-but-not-cloud" providers using modern tools is not difficult for some moderately-expensive-but-not-as-expensive-as-cloud-services ops engineers.
I do like the idea of an online proximity focused office space but I couldn't get my team to buy into the idea of it. Async messaging on slack is preferred.
The games look particularly interesting - I've been in meetings where everyone uses awkward verbal games to break the ice, but this would be so much more fun
My CEO wanted to introduce Gather with the idea that everyone would be in it working all day. He wanted to be able to "stroll by" whenever to see what people are up to. The team unanimous voted against this so we didn't get it.
I worked at an org ($30B) and it was used for happy hours (as in drinking if you wanted) in the couple of related teams. Since we've been working from home since 2020. It worked alright, some groups would form but it's like real life, if you're more social more 'gather' around you.
At the beginning it all felt gimmicky and felt like the novelty factor would wear off quite quickly, but there was this one specific instance that made it "click" in everyone's head, and it happened right at the end of a regular meeting.
We finished the discussion and most attendants quickly dispersed, some people were still at the table trying to fix a bug, and we needed some input from this one specific person to do so. So someone just strolled to where that person was, and asked him to come to the table. It all felt very natural, and the way we were able to quickly get the information we needed without having to awkwardly drag a bunch of people into a Google Meet was just magical.
Today we use it everyday, full time, it all feels very natural and we don't really think about it, because it works so well.
Recently the CTO also opened a "floor" (I.E another Gather instance entirely) for the sales and marketing team (whose headcount in the hundreds) and linked both "floors" using their "portal" feature. Awesome!
Fun idea!
Well done OP, I wish you lots of success. I know from experience that as a solo dev this flat.social is an amazing outcome.
Also - which JS library do you use to voice chat and video calls? I wanted to implement voice chat myself.
EDIT: it was just archived - https://github.com/capnmidnight/Calla
As per the JS library for audio/video - I have used Mediasoup.
The WebRTC portion was all implemented through Jitsi Meet, and I eventually grew to regret that direction. My current work uses just a CoTURN instance with a fully custom backend for managing multiplayer.
The user interface was only ever intended to be a demo, I didn't have any interest in running it as a FOSS project in its own right, and it while I would say it was certainly a competent implementation, it also wasn't anything ground-breaking in any way.
That basically leaves just the core audio graph management as anything that was valuable in the project. That part still lives on in my project at work, but considering I basically gave up on trying to run FOSS projects after some deep introspection on my experiences with running FOSS projects, I don't put much effort into documenting my code anymore. But if you want to see the audio graph management stuff, the latest version is here: https://github.com/capnmidnight/Juniper/tree/master/src/Juni....
The WebRTC system that I now use is largely this on the client (https://github.com/capnmidnight/Juniper/blob/master/src/Juni...) plus this on the server (https://github.com/capnmidnight/Juniper/tree/master/src/Juni..., which is a SignalR hub in an ASP.NET Core app, but should make the signaling flow clear). And then this code uses the client (https://github.com/capnmidnight/Juniper/blob/master/src/Juni...)
Calla was originally built to be an integration with Jitsi Meet. You'd setup a standard Jitsi Meet server and then write an app that connected to it as a wholly separate interface from Jitsi's standard interface.
Unfortunately, there were some major issues with this approach.
1) I used it for work, but last August changes in WebRTC broke Jitsi for a while and I had to scramble to stand up my own WebRTC TURN server to continue our operations.
2) Jitsi's lib-jitsi-meet was not very well documented (While there were docs on each function call, there wasn't much on flows for putting it all together, especially when it came to sequence of events involving joining rooms, listing users already in the room, etc.), and there were no official TypeScript .d.ts files for the project, so it made it hard to keep up with changes.
3) Performance was never that great. While Jitsi supported data channels, for some reason they were completely unreliable for anything more than 4 messages a second. I wasn't able to figure out why.
I had always intended Calla to be an audio and networking management library. It just got to be too much work to maintain Calla, especially considering most people didn't actually want Calla as a library but instead wanted more of a full app repo they could clone and minimally modify to make their own old-school-RPG-like meeting rooms. I only made the 2D RPG app to be an expedient demo, but I am personally more focused on VR apps (and actually one in particular at work).
I am just surprised that a solo developer or a small team can build something so interesting and fun. I would'nt even know where to start.
I couldn't see anythig on your website that addresses any of these sorts of concerns?
The dangers are all too real with online social spaces; douchebaggery, perving and harassment. The examples I gave are common mitigations (e.g. movement algos that prevent someone being boxed in to a corner can provide a way for somone to escape an uncomfortable interaction - without it, they can be stuck) already implemented by similar platforms.
Look up any metaverse review and they're full of this shitty behaviour. If spaces don't think about this aspect, then those that are targetted will just not come back.
If there's one thing builders of social platforms should have learned from the last decade it's that they can't ignore the downsides of how their tools are going to be used.
This looks like it was built for team social events. If you’re getting harassed and bullied on your team, you have bigger problems you need to take care of.
So let's not pretend these problems can't exist, or can just be hand-waved away with "well you can just leave". That's not how real social interactions work, especially those with employee/employer externalities attached.
If it's used for team interactions: If you're being bullied by your teammates and/or boss, no amount of software moderation is going to fix that. Go talk to HR about it, quit, and/or go to the NYT with a juicy story.
> That's not how real social interactions work
What are you talking about? Unless you're being physically stopped from leaving somewhere, you can leave. If you're being physically stopped from leaving somewhere, call the police and hopefully you've taken a self defense class and/or have pepper spray on you.
Please mind that the demo room is an open space to show off the features. Once you create your own flat, you are able to edit moderators, guest list, allowed email domains, banned list and keep the flat open and closed whenever you want. There is also ability to kick & ban.
> I've seen others implement things like personal boundaries, hiding from others, and avoiding being boxed in by others.
I find this very interesting. After all, it's a space governed by a physics engine which can potentially bring another dimension of annoying things that one can do. In flat.social you can push other people, magnetise yourself to others and so on.
Nevertheless, users do not move with keyboard only - you can also move by "flying" yourself around with a mouse or a drag event. If you want to remain static, you can anchor yourself to a spot on the map and no one will be able to box you into a corner or to disturb a conversation by pushing around.
Ask any woman what it's like to go to a tech conference, and then try to guess if they would be comfortable using a tool like yours as it currently stands.
Why did you ignore their reply to you entirely?
> Please mind that the demo room is an open space to show off the features. Once you create your own flat, you are able to edit moderators, guest list, allowed email domains, banned list and keep the flat open and closed whenever you want. There is also ability to kick & ban.
What would you do in a Zoom call with co-workers, friends, or attendees of a presentation who were disruptive? You'd kick them or leave.
The same argument for booting disruptive people could be made for conferences, too. Yes, it's much easier with smaller and more closely-knit teams, but it still happens. And your suggestion is _only_ any good for closely-knit teams. Once it starts getting used for more open-attendance events, that starts to fall apart.
We don't have to theorise about this stuff from first principles, we can see exactly this behaviour panning out for real in existing social systems today. Kick or leave as the two options doesn't cut it there, so why should it be sufficient here?
Edit - no way for me to delete my account though
Just as a note - the reason I decided to stop using it was it was too hard for me to find anyone else on there, just kind of gave up and left.
I agree with some other comments on here about trying to offload more processing on the client but for now I think you have a viable product to first find your market and then you can work to optimize later. No idea if its technically possible but I wonder if you could create a slack plugin to make it as few clicks as possible for remote teams to spin one of these up? Ideally you could render it in the slack channel but that's probably not feasible (unless you're able to pitch Slack/Discord on it?). Great work, good luck!
I recently introduced a "floor builder" which allows you to select different tiles that you would like to use in your flat. This might be something more serious with professional looking meeting rooms or more fun with a dinosaur and a swimming pool.
Elements pipeline - I render most of the elements in blender. I also need to tell the physics engine where the walls are for the new elements for blocking audio, video and movement.
As per offloading more work to the client - that's what I'm trying to avoid. I'd like to make flat.social as tech-inclusive as possible and make sure that it works on weaker devices. Processing audio, video and the game itself is already enough so when possible, I try to offload the work to the backend.
Also, Slack integration is pretty much ready but still in testing :) While I do not think that it's possible to render the app itself within a Slack channel, there are couple shortcuts that might be useful for teams/communities who want to organise recurring events with Slack notifications.
I think you have enough features so to me the challenge is finding how to make it feel like it already lives inside the applications people are already using for work (like Slack). Imagine a trailer that demonstrates how one command can launch this amazing adventure. Something like "Your next /happyhour awaits"