[ahupp]

This isn't about saving 10ms in latency. In the case of a dropped packet, TCP can wait multiple seconds for a retransmission which blocks the whole stream. You aren't going to client-side-predict your way out of that.

QUIC in theory can support this kind of lossy transport but it's not really exposed to browsers AFAIK. WebRTC is somewhat complicated to use but can support lossy streams.

[jayd16]

Again, you're solving for a very specific type of interaction that is not necessarily needed.

Does every virtual web app need server authoritative position? No. We could imagine a world where much of the physics and rendering is client side for most apps.

Does it make sense that every virtual web app should pay for low latency server authoritative position? Also no.

Sure, some apps will want this level of synchronicity and maybe there's a place for another web standard but its silly to say that http is not feasible or that this is the only way web VR should work.

[ahupp]

Ok I see what you're getting at. Yes, there are plenty of VR apps that don't require that kind of latency control. A game that's 99% local, but shows you a leaderboard of top scorers, etc. Even an app that has a significant real-time component will have plenty of HTTP requests as well.

But the word "metaverse" appears in the first sentence of the post we're discussing, and real-time interaction with other people's avatars does call for this kind of protocol.

[jayd16]

But that's entirely my point. Even for the metaverse, the majority will be cheap async http-like calls and not always connected game servers. If IKEA is joining the metaverse, do they want to spin up a realtime game they maintain or will they want to statically host client heavy VR content?

We should focus on how we bring the lessons of past 20 years into these sci-fi concepts. We need to consider how businesses find success today and bring that to VR to be successful.