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.
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
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.
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.
At one job I had access to some paid AWS support tier. It's basically a bunch of consultants. We needed to process a datastream of events from user actions on a website. We asked about serverless / AWS Lambda. Their answer was something like "Well yeah it'll work but don't do that. It'll cost too much money and you'll wind up rebuilding it around EC2 anyways"
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.
I have done this a couple of weeks ago on firefox and it worked fine even with a 1 minute delay. An even easier way to share the SDP offer, at laest when the clients are in physical proximity, is using a data over sound library like ggwave.
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.
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
STUN gives back your public IP:port, TURN gives you assigned proxied IP:port.
You take that data and send to the peer over signaling connection, and they call you back on that IP:port. Most NAT implementations make and keep a temporary mapping between public port to private IP consistent[1] for few minutes, and not completely random per destination[2], so it usually works.
1: e.g. router.public.ip.example:23456 <-> 192.168.0.12:12345
2: e.g. if stun.l.google.com:12345 sent from port 23456 but if yourfriend.router.ip.example:12345 sent from port 45678
Yes. Unless the party generating the QR code first obtains its external IP address by other means, which would still require some kind of echo server.
Even then, ignoring outdated approaches like UPnP, a commonly accessible host would be needed to establish signalling with e.g. NAT hole punching for anything but the most basic of setups.
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.
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?
> 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.
> 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.)
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).
I'm the Trystero author and I'd say both libs attempt to accomplish the same goal but with very different APIs. One key difference is PeerJS uses a single centralized server by default for matchmaking, whereas Trystero offers lots of flexibility and redundancy, using various signaling connections in parallel.
The site says "Right now youʼre the only person with the page open, but you can cheat and just open this URL in another tab to see what itʼs like with others." I'm using Firefox and Chrome on Ubuntu. When I try a second tab or one in Firefox and one in Chrome my computer's network connection locks up (pings stop). I have to close the tabs and then pings to google.com come back at 30 seconds and slowly come back to normal. It appears that http://playground.nostrcheck.me/relay is the problem.
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.
On the other hand setting up the turn servers and so on for signaling before the webrtc connection is established can be a nightmare, if not using a third party service like twilio
This is so fun. You know what, you should change the picture of cursor from hand to something like, bee, or even fly, that should make it even more hilarious :-p
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.
Just a reminder that this kind of user-to-user interaction feature makes your website a "social network" according to UK regulation (and Mississippi's, and more jurisdictions coming soon), and therefore you must get copies of government ID of your users so that you can deny them access if they are underage, and rattle them to the police if you suspect they are committing thought crime by sending certain fruits. Obey the law.
I made a little multiplayer arcade game last year. I added a chat feature with TTS. About an hour after launch it was just the n word over and over again. (Also zalgo text, which somehow strained the browser more than a video game!)
I removed the chat feature.
At any rate, getting banned by OFCOM is starting to sound like a badge of honor these days.
They do, but unlike what the OP claims, you do not need to age verify your site just because you added a social element. If the purpose is not to distribute pornography/other age restricted materials and you are able to moderate the site (ie: are not facebook scale), this is not required.
The law sucks but the misinformation around it is getting out of hand.
What's even "harmful content to minors"? Even if it were restricted only to pornography--which is not--I wouldn't count with being able to "moderate" all the ways users can draw penises.
> In this Act “user-to-user service” means an internet service by means of which content that is generated directly on the service by a user of the service, or uploaded to or shared on the service by a user of the service, may be encountered by another user, or other users, of the service.
The legal text is dense but there is some analysis here:
It'd be cool if you could easily publish multiplayers games to itch.io or similar websites from Godot or Unity and have automatic matchmaking: the first player to visit the game pages gets matched automatically with the next, and so on.
You can't find the first one without the first one having static IP found from something in the page, which this thing solves using external services of developer choice, including commercial Supabase and Firebase systems. But the docs says it supports Bittorrent for that, so it's probably good.
I'd love to use an existing protocol to get (distributed?) user accounts and chat and stuff, and just build my game as a plugin for that. Or something.
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.
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.
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
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.
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.
At one job I had access to some paid AWS support tier. It's basically a bunch of consultants. We needed to process a datastream of events from user actions on a website. We asked about serverless / AWS Lambda. Their answer was something like "Well yeah it'll work but don't do that. It'll cost too much money and you'll wind up rebuilding it around EC2 anyways"
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.
I have done this a couple of weeks ago on firefox and it worked fine even with a 1 minute delay. An even easier way to share the SDP offer, at laest when the clients are in physical proximity, is using a data over sound library like ggwave.
We've circled back to dial-up modems :D
serverless nowadays means "no server in YOUR infrastructure"
I didn't know about the QR-Code solution how does it work ?
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.
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
STUN gives back your public IP:port, TURN gives you assigned proxied IP:port.
You take that data and send to the peer over signaling connection, and they call you back on that IP:port. Most NAT implementations make and keep a temporary mapping between public port to private IP consistent[1] for few minutes, and not completely random per destination[2], so it usually works.
1: e.g. router.public.ip.example:23456 <-> 192.168.0.12:12345
2: e.g. if stun.l.google.com:12345 sent from port 23456 but if yourfriend.router.ip.example:12345 sent from port 45678
woaw thank you ; will definitely hop back on this topic now ; very much appreciate the answer
Yes. Unless the party generating the QR code first obtains its external IP address by other means, which would still require some kind of echo server. Even then, ignoring outdated approaches like UPnP, a commonly accessible host would be needed to establish signalling with e.g. NAT hole punching for anything but the most basic of setups.
They say that serverless stacks have the highest server bills.
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.
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.
> Serverless
uses someone else's network for signaling
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?
> 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.
> 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.)
> 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.
> how scalable is it
Considering the site just spams my error console with
I'd say not very.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).
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.
https://github.com/dmotz/trystero
Direct link to the underlying source code.
I've been exploring PeerJS (https://peerjs.com/) recently. This seems like a similar concept. Would it give me anything that PeerJS doesn't?
I'm the Trystero author and I'd say both libs attempt to accomplish the same goal but with very different APIs. One key difference is PeerJS uses a single centralized server by default for matchmaking, whereas Trystero offers lots of flexibility and redundancy, using various signaling connections in parallel.
The site says "Right now youʼre the only person with the page open, but you can cheat and just open this URL in another tab to see what itʼs like with others." I'm using Firefox and Chrome on Ubuntu. When I try a second tab or one in Firefox and one in Chrome my computer's network connection locks up (pings stop). I have to close the tabs and then pings to google.com come back at 30 seconds and slowly come back to normal. It appears that http://playground.nostrcheck.me/relay is the problem.
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.
I wonder if we can make a live heatmap of text selections on the page, smoothed and decaying with time.
Cool, not working in Safari for me though.
It worked for me in Safari for a while, but then the entire browser stopped working.
it's laggy as hell on firefox. but works nice on chrome. won't use it
I remember cloning the twilio code for video conferencing for webrtc and it working instantly. Very cool.
On the other hand setting up the turn servers and so on for signaling before the webrtc connection is established can be a nightmare, if not using a third party service like twilio
I wanted to throw objects at others and to make things explode. That's just what it brought up in me.
This is so fun. You know what, you should change the picture of cursor from hand to something like, bee, or even fly, that should make it even more hilarious :-p
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.
Just a reminder that this kind of user-to-user interaction feature makes your website a "social network" according to UK regulation (and Mississippi's, and more jurisdictions coming soon), and therefore you must get copies of government ID of your users so that you can deny them access if they are underage, and rattle them to the police if you suspect they are committing thought crime by sending certain fruits. Obey the law.
I made a little multiplayer arcade game last year. I added a chat feature with TTS. About an hour after launch it was just the n word over and over again. (Also zalgo text, which somehow strained the browser more than a video game!)
I removed the chat feature.
At any rate, getting banned by OFCOM is starting to sound like a badge of honor these days.
how are these laws enforced outside of the UK and Mississippi?
Do those laws even apply to P2P apps without central servers?
Yes. Its defined without a technical requirement - just legal ones.
Each host will carry a legal responsibility for both what they push, and what they pull.
They do, but unlike what the OP claims, you do not need to age verify your site just because you added a social element. If the purpose is not to distribute pornography/other age restricted materials and you are able to moderate the site (ie: are not facebook scale), this is not required.
The law sucks but the misinformation around it is getting out of hand.
So if a site is completely p2p, it's illegal because it is unmoderatable?
And if so, is BitTorrent also completely illegal now, even if there's no piracy? IPFS? I2P? Tor?
Agree, with caveat - Obey the law, unless that law is made by a tyrant!
This is factually untrue and either venting or wilfully ignorant of the actual law.
Hm? Have you taken a look at the law?
https://www.legislation.gov.uk/ukpga/2023/50/section/12
What's even "harmful content to minors"? Even if it were restricted only to pornography--which is not--I wouldn't count with being able to "moderate" all the ways users can draw penises.
The act regulates "user-to-user" services:
https://www.legislation.gov.uk/ukpga/2023/50/section/3
> In this Act “user-to-user service” means an internet service by means of which content that is generated directly on the service by a user of the service, or uploaded to or shared on the service by a user of the service, may be encountered by another user, or other users, of the service.
The legal text is dense but there is some analysis here:
https://www.eff.org/deeplinks/2023/09/uk-online-safety-bill-...
And some news about Reddit: https://www.eff.org/deeplinks/2025/08/americans-be-warned-le...
Sweet API design!
Love it
It'd be cool if you could easily publish multiplayers games to itch.io or similar websites from Godot or Unity and have automatic matchmaking: the first player to visit the game pages gets matched automatically with the next, and so on.
Is there anything like that?
You can't find the first one without the first one having static IP found from something in the page, which this thing solves using external services of developer choice, including commercial Supabase and Firebase systems. But the docs says it supports Bittorrent for that, so it's probably good.
I used Trystero in exactly this way for https://www.farmhand.life/!
I've been looking for this too!
I'd love to use an existing protocol to get (distributed?) user accounts and chat and stuff, and just build my game as a plugin for that. Or something.
HN should add downvote option.