[paulgb]

Hey HN! I'm a co-founder of Jamsocket, happy to answer any questions. We've previously been on HN for Plane, which is the open-source engine behind Jamsocket. https://news.ycombinator.com/item?id=33178797

Sorry for the website performance issues, I've disabled the animation which should help.

[stunt]

The session thing looks really cool, but when do I need it? I can develop a simple real-time app using socket.io or a service like Pusher.

Why would I choose this instead? That isn't clear to me yet.

[paulgb]

If you write a socket.io service that uses broadcast, and then scale up to more than one server, your users will be split between those servers and won’t be broadcast to the other. Jamsocket allows you to generate a unique hostname for each room that ensures that every user is talking to the same server. That server can still use socket.io in addition to Jamsocket; they work at different layers of the stack.

Pusher solves the problem of scaling in a different way, which is by giving you an HTTP endpoint to send events to. It’s better for large broadcast groups (e.g. sending people sports scores) but doesn’t run any compute for you.

[pcthrowaway]

Can you clarify pricing? "From $25" is terribly opaque. What are the billing criteria?

[paulgb]

Thanks for the feedback, I agree and it's something that we're working improving.

Currently most people are paying the $25 flat rate; for this we bump the per-backend memory limit to 2GB and give them a soft limit of 20 concurrent backends, up to 24h duration for those backends, and enable eager image pushing for faster start times. The pricing will become more sophisticated over time as we deal with a wider variety of usage patterns.

The bring-your-own-compute model is a bit clearer because it's simpler for us to model from the side of our own costs. That has a $25/month base fee plus $10 per “server month” of compute connected to the control plane. For bring-your-own-compute there is no cost or limit to the backends that run, since they run on our customer's own hardware.

[pcthrowaway]

Thanks for clarifying.

So how does the price scale with the limit on concurrent backends? That's the really important factor in determining whether this is feasible (though I assume given a baseline of 20 it probably wouldn't be, for me, right now)

Also, how does BYOC differ from using Plane or Socket.io?

[paulgb]

At scale it becomes a bit less one-size-fits-all, because compute requirements can vary so much. Eventually we will probably have different backend types the same way that Amazon has different instance types, but for now we tend to talk things through with the customer one-on-one (feel free to reach out at the email in my profile if you want to talk about a use case).

BYOC is essentially a hosted instance of Plane with our hosted container registry, web UI, and command-line tool for deployment.

Jamsocket could be used to spin up a socket.io WebSocket server.

[Donckele]

Yep, your homepage breaks on my imac/firefox due to webgl.

[paulgb]

Sorry about that, thanks for reporting. Can you elaborate on how it breaks -- does it freeze up or not display at all?

[hdidhdish]

most sane people disable webgl and enable per domain

[paulgb]

Fair enough, I have fixed it so that it doesn't break without webgl.

[juberti]

Do you support WebTransport in addition to WebSockets?

[paulgb]

Not yet but if you have a use case in mind, I'd love to hear more about it. I'm pretty excited about QUIC/WebTransport/HTTP3.

[juberti]

The basic idea would be a simple voice conferencing bridge that you connect to via WebTransport. There are a number of more interesting things that we would be interested in if we could get this sort of basic scenario working.