We've discussed adding support for other networking protocols, but it hasn't been a priority so far. Can you share more about why it would be impactful for you?

I plan to build my own project using SpacetimeDB very soon, regardless of Quic's or other protocols' implementation into SpacetimeDB, and I believe these may be the biggest impact for what I'm hoping to accomplish on the network level, and what I think may benefit SpacetimDB as a whole.

• Secure by default
  • By requiring a TLS handshake to occur during initial connection between peers (i.e player -> server), a secure connection is able to manifest sooner than waiting for TCP + TLS.
  • IIRC Quic also encrypts packet headers, along with a few other features that make manipulating in transit data more difficult beyond just encrypting the data inside a packet.
• Multiplexing built in
  • This may pair well with one of SpacetimeDB's advertised features of handling many connections at the same time, however, I'm open to the counter point of any performance gains from built in multiplexing in Quic being negligible, compared to well made multiplexing strategies for TCP connections.

Please do correct any of my statements here, I'm still new to networking protocols, and am mostly referring to publicly advertised features of Quic that are enticing to me.

Thanks for the info! I'll forward it along to the members of our team that are more involved with the networking layer. If any of these become blocking requirements for you, please let us know!

Something that is also nice is that QUIC has built in support for unreliable datagrams, letting you make fast paced action games if you wish

and if you'll do QUIC why not implement WebTransport on top of it aswell

Hi

Thanks for all the effort put into spacetimedb, I think this is going to be big!

I am really looking forward for this because I am planning two projects right now and having this would be amazing. Perhaps not QUIC yet since the rust h3 implementation is still in development but some UDP capabilities would be amazing for things like player coordinate changes.

I have created an internal design for QUIC transport, but we're not sure on the prioritization of it internally. Will provide updates as we have them.

This would be a serious performance improvement for all of your customers, please at least activate http/2 in the meantime.

UDP protocol would be a huge performance update, cause tcp is stacking net packets at system lvl, using udp you control it by yourself.
WAITING FOR SURE

I wonder if there is a proven high-performance NGINX template we could use to update MainCloud’s config, rather than having to request dozens of individual performance-oriented tweaks.

+1, but I'll add: I would specifically like WebTransport with both reliable and unreliable packet options. WebTransport is the future of protocols, especially for games. You can send data that is unreliable and OK to lose, like movement data or the orientation of each player's camera (for tracking head movement, etc.) as unreliable, and send reliable data like attacks/damage, inventory updates, etc. as reliable.

Spacetime could default to making those unreliable updates ephemeral (in memory only) and keep the clients in sync as a "best effort" rather than guaranteed sync. You would align the persistence model with the network layer: no persist (RAM only) <=> unreliable; persist to disk (ACID) <=> reliable transport. It would be nice as a developer/user of Spacetime to be able to choose my own way if I disagree with the default, but the default should simplify the code by providing a sane opinionated baseline.

BTW, WebTransport is part of the Baseline 2026 feature-set of the web platform according to caniuse: https://caniuse.com/webtransport - even Safari has it now, so there's no longer any excuse to call it some experimental/niche platform component, any more than e.g. WebGPU. New projects like multiplayer games and simulations being built on modern web technology today should almost assuredly use WebGPU and WebTransport if performance is at all important.

My project is currently stuck in a weird situation where, I have a bespoke client/server app written completely in Rust (client and server; the client targets WASM + web platform with web-sys) and PostgreSQL backend. I rolled my own SQL and synchronization/state management, which is huge amounts of annoying code that Spacetime would make completely safe and almost trivial to write with its persistence and sync plane. But I'm using WebTransport + Flatbuffers, and ephemeral stuff is just unreliable WebTransport datagrams and only lives in memory on the server with no Postgres write.

So if I adopted Spacetime today, I would lose a certain degree of network performance in non-ideal conditions compared to everything being WebSocket (which is essentially, a previous-generation web platform networking technology as compared to WebTransport). I would gain all of Spacetime's reliability guarantees around state and persistence management, which is probably still worth it in the end, but that temporary setback in network behavior would be painful in the medium term.

... Unless you guys implemented WebTransport as a client/server protocol backend in Spacetime. :D

@allquixotic - I completely agree with you. Flatbuffers is really interesting. Do you know how that compares with how STDB does it, and is that still something that can be used?

I had a half a mind to set up a custom gateway co-located in the existing Maincloud datacentre so that the client <> Gateway path is at least web transport. I will say that websockets really lets you down if you have players that use VPNs which is particularly common for our chinese audiences.

@allquixotic - I completely agree with you. Flatbuffers is really interesting. Do you know how that compares with how STDB does it, and is that still something that can be used?

I would probably drop Flatbuffers in favor of Spacetime's Binary Spacetime Algebraic Type Notation (BSATN) if I did adopt Spacetime's protocol stack. WebTransport is more about flow/packet/loss management and the flexibility to switch between reliable and unreliable data transfers.

If you're using Spacetime's client lib, you pretty much should be using their message layer, BSATN. And if you're not using Spacetime's client lib, you lose a lot of the safety/reliability benefit of Spacetime. It's not a DB that you bolt onto an app; it's an app runtime that happens to have a DB (and also a network layer). While technically possible, completely cutting out Spacetime's protocol stack defeats most of the purpose of using it in the first place.

I had a half a mind to set up a custom gateway co-located in the existing Maincloud datacentre so that the client <> Gateway path is at least web transport. I will say that websockets really lets you down if you have players that use VPNs which is particularly common for our chinese audiences.

High latency links are an interesting application of WebTransport.

I don't know about your app, but for mine, it looks like the scope of changes needed to Spacetime to make it truly worth adopting, is quite large. The largest change is I need first-class support for non-persistent state that integrates clearly with the rest of the Spacetime technologies (like BSATN). The second largest change is support for WebTransport with both reliable and unreliable messages.

I do not think any of this is easy, and would probably constitute at least a Spacetime minor version bump if not a major version bump if it were to be released. But I'm pretty sure I know what I need to make it possible for me to adopt this project as a core part of my engine.

If it helps, Webtransport was raised as a feature request by the STDB founder and is the #4 highest voted (with credits) feature. So it might be closer than we think. If you have a few bucks or energy, give it a vote. :)

If it helps, Webtransport was raised as a feature request by the STDB founder and is the #4 highest voted (with credits) feature. So it might be closer than we think. If you have a few bucks or energy, give it a vote. :)

With some effort, this is now the number one most voted feature on the SpacetimeDB feature request site. Let's hope that moves the needle...

This is definitely top of mind! We are always following the feature list.