Make any site multiplayer in a few lines. Serverless WebRTC matchmaking
70 comments
·August 25, 2025kabes
haxiomic
You're not wrong! Serverless is a funny term. Cloud companies use serverless to mean you don't have to provision and manage the server yourself, but it is still very much serverful technically speaking. This is neat in that you don't even need to setup anything with a cloud provider yourself to enable p2p connections
_heimdall
I've always seen the distinction as "serverless" meaning there wasn't a set group of servers always on and instead they provision up and down on demand.
Only avoiding provisioning and managing the server just means you are renting rather than self-hosting.
layoric
The VPS is like renting office space. You don't own the space, but for the most part get to use it how you want, and all the responsibilities that come with that.
"Serverless" is like paying for a hot desk by the minute, with little control of your surroundings, but it is convenient and cheap if you only need it for an hour.
numpad0
My mental model is "we handle interpreter restarts for you, so forget about systemd unit files and CEO's laptop with minimized tmux"
null
kaoD
I've always been obsessed with true P2P WebRTC with QR codes but, at least back in the day, Firefox fails the offer under a very short timeout (~5 secs IIRC) which made out of band signaling completely impossible.
littlecranky67
serverless nowadays means "no server in YOUR infrastructure"
6r17
I didn't know about the QR-Code solution how does it work ?
numpad0
Normally you need a "lobby" server that collects and lists available other clients and pass along connection details. You have no servers in P2P setup, so the "signaling" information has to be shared "out-of-band", like through QR code or super secret invite link or avian IPv4 or something.
6r17
wait but this should only work on locals / close networks shouldn't it ? i thought you still need some proxying in other cases (hence the turn) - i really need to study this again asap tough
moffkalast
They say that serverless stacks have the highest server bills.
kamranjon
Awesome way to demonstrate exactly what your library does - also the library itself is a great concept - was just looking for something just like this the other day.
araes
Small nitpick. Tried logging in simultaneously with a desktop and a phone to make it wasn't BSing, and it was actually sending moves/fruit correctly. Yes, appears to. However, found out phones don't update on touchmove. Only on final touch.
Be nice if it used:
const [sendMove, getMove] = room.makeAction('pointerMove')
window.addEventListener('pointermove', e => sendMove([e.clientX, e.clientY]))
If necessary it can then use "PointerEvent.pointerType" to find the actual type.
https://developer.mozilla.org/en-US/docs/Web/API/Element/poi...
Otherwise, neat capability, and there's at least several different concepts it seems like it would be enabling of. Mapping / GIS, you could see where other people are browsing on somewhere like Google Maps. Maybe leave little markers that fade with time. Temporary file sharing where you broadcast a list of available files after logging on and peers can send requests. Dropbox-esque send yourself stuff with a home system that's always logged on. Computer-aided design (CAD/CAE/CAM) or stuff like blender/photoshop, work on models/images together. Obvious stuff like word/excel. Field Service Management, collaborative service calls.
Admittedly, also enabling of botnets, darkweb, and other such ideas. However, such is the nature of a lot of these types of technologies.
araes
Made a site to try out the framework. Mostly just testing that it works and actually produces something.
Swapped over to having birds instead. Little bit confusing how to actually implement some of the functionality and how some of the functions work. Otherwise, relatively easy to set up and have working.
evbogue
I use Trystero as one of the transfer methods on wiredove. it's super cool. it doesn't always work because punching thru NAT is a pain, but when it does work it's awesome. Trystero is also cool if you want to hook up a webcam or a video meeting with the minimal amount of code.
Reubend
WOW this is cool! I love this, but as a nitpick, how scalable is it to do each connection peer to peer? Doesn't that mean that I have to keep a stream connection open for everyone who I want to include in the room?
michaelt
> how scalable is it to do each connection peer to peer?
I can tell you roughly how it works for webrtc video calls.
If you're in a 5-person peer-to-peer webrtc video call where you receive 4 streams of video, you also need to send 4 streams of video. This is scalable in a sense; the uplink and downlink requirements are equal.
The problem comes if you're in a 100-person meeting, and the application logic has hidden 95 people's video to save on bandwidth. In that case, while you'd only receive 4 streams of video you'd have to send 99.
In practice, webrtc video calling often uses an 'SFU' or 'Selective Forwarding Unit' where you send one video stream to the vendor's cloud server and they forward it to the other people in the meeting. This also benefits people on asymmetric connections, and mobile users where uploading costs battery life, and users behind highly restrictive firewalls where webrtc's NAT traversal fails to work.
jech
> If you're in a 5-person peer-to-peer webrtc video call where you receive 4 streams of video, you also need to send 4 streams of video. This is scalable in a sense; the uplink and downlink requirements are equal.
The issue is not with the throughput: a typical videoconference requires 700kbit/s per stream, so even 12Mbit/s upstream should be enough for 20 streams or so. The issue is with having to encode the video separately for every receiver.
WebRTC adapts to the available throughput by encoding the video separately for every receiver, with different parameters. If you're in a five-person peer-to-peer conference, you decode four videos simultaneously, which is fine, but you're also encoding your video four times, which is not.
An SFU works around the issue by not reencoding the video: the SFU merely decrypts the video and reencrypts it with the public key of every receiver. Since AES is implemented in hardware, the reencryption comes essentially for free.
(Of course, that implies that the SFU needs to use other techniques for bandwidth adaptation, such as simulcast or scalable video coding (SVC). See slides 10-12 of https://galene.org/galene-20250610.pdf if you're interested.)
Wowfunhappy
> This is scalable in a sense; the uplink and downlink requirements are equal.
But don't most home connections have a slower uplink than downlink? Mine certainly does.
bhaney
> how scalable is it
Considering the site just spams my error console with
DOMException: Failed to construct 'RTCPeerConnection': Cannot create so many PeerConnections
ermir
When I experimented with this a few years back a true NxN room would cap around 8 people when using PCs and 4 on mobile, the bottleneck is encoding/decoding of the video. For larger rooms you need a server to route the video to all recipients, this is called an SFU. With an SFU you can have hundreds of participants, but not everyone can speak or be seen at once.
For audio-only the sky is the limit. I used to work on a voice-based social media and you also need an SFU here as well, but I added a few mixing features so that multiple incoming audio streams would be mixed together into a single outgoing one. Was very fun (and scalable).
kabes
It's not very scalable. Regular rules of webrtc apply, so once you go to a certain number of users, you would have to use an SFU approach.
zknowledge
to the person who's cursor I chased around for more than a couple of minutes, I don't know why I did that and I apologize.
kookamamie
> Serverless
uses someone else's network for signaling
Paedor
Hey cool! I once hacked together a serverless game like this using firebase as an intermediary. https://github.com/amdson/rtcpvp / https://amdson.github.io/rtcpvp. I remember wishing this existed, setting up ICE p2p was truly not enjoyable.
dmotz
https://github.com/dmotz/trystero
Direct link to the underlying source code.
jjangkke
Few things
1) Serverless isn't really serverless and we are sick of this AWS speak. The trend lasted briefly but it isn't appealing when you are metered for every little thing and unable to SSH into a host and resolve issues
2) You can already do matchmaking easily with FOSS self-hosted solutions. These don't cost a lot of computing or bandwidth but some developers think its a chaotic and resource heavy problem.
maxlin
This is mad, I love it. Way more "serverless" than what the term is commonly used for!
sotspecatcle
Cool, not working in Safari for me though.
quietfox
It worked for me in Safari for a while, but then the entire browser stopped working.
pacha3000
it's laggy as hell on firefox. but works nice on chrome. won't use it
This isn't serverless. It's just using someone else's servers for the SDP signaling. And in a production app you'd likely also need turn servers and maybe SFU servers.
There are some true serverless approaches out there for the signaling, e.g. where both peers scan each other's QR code, but that obviously has very limited use.