[andrewmcwatters]

WebSockets are not an appropriate medium for VR in the most common use case today: real-time video games.

Even if you're not building a video game today and want to do something other-VR esque, I guarantee that you will inevitably end up recreating something the video game industry has done in the last 22-23 years.

Everything real-time the author of this article suggests is in the realm of something you would want for VR.

It makes sense to just take what both industries of web development and game development currently understand and build on that.

So let's take that to its logical conclusion. Let's say you wanted to navigate virtual worlds. You're going to end up having some sort of "navigator" or "explorer" or end up going on some sort of virtual "safari" of sorts.

You'll do that probably initially with HTTPS or talk to some HTTPS-based server. WebSockets are not sufficient for real-time VR based work, so you'll probably end up with some sort of, let's say, WebUDP or WebSockets with UDP functionality.

Everyone will end up wanting to build their own layers of abstraction over and over again and again so entry-level web and game developers have something to do, so it'll look like some incarnations that build on or supersede Three.js. Why?

Because everyone will have a different interpretation of what they want their camera, or user entity or actor to be able to do.

So, you'll need HTTPS, web-based UDP, some sort of localplayer series of libraries or framework, then you'll need levels or maps, because to do any sort of VR, you need a world, or worlds you can navigate.

Huh, weird. All of this just sounds like someone porting Quake to the web with VR. How boring.

Of course, if someone says "OK, yep, let's do it then," it won't be anything like that, or it will, but only superficially, because that's what happens when you live long enough to see people take technologies the broader population already knows about and cram them together.

The alternative is that Zuckerberg is an old person and no one was asking for a metaverse, just video games that don't suck eggs, and that Meta is just Mark's way of graduating Facebook to an Alphabet-type conglomerate in order to keep growth moving forward.

I seriously feel bad for kids today. You have what, Fortnite, Minecraft, and Roblox to play and that's it? Too many micro transactions and low quality games.

No 30-something is asking to put on a headset and go to the VR equivalent of Something Awful, which would probably look like a back alley with players farting on each other Jaykin' Bacon-style. You want a metaverse? That's what it would look like. There's always going to be some Something Awful/4chan/Facepunch equivalent.

No one is like "oh yeah I wanna go to work and sit in a virtual cubical with my Meta® Quest 3," and yet there are some people really disconnected from reality who think people are actually asking for that instead of, like, affordable housing or something. Weird.

[spywaregorilla]

> I seriously feel bad for kids today. You have what, Fortnite, Minecraft, and Roblox to play and that's it? Too many micro transactions and low quality games.

Yes, those are the only 3 video games.

[bigyikes]

Even if they were… they’re pretty great games. Roblox is what originally got me into programming, and Minecraft took that further. I probably wouldn’t have the software job I have today without these games.

Fortnite is fun too, and paying for silly skins and dances isn’t so bad.

[bborud]

Back up a bit, take a breath, read the HTTP 3 draft. Again, no need to reinvent the wheel. Let evolution take its course and piggyback on work that is already being done.

"Everyone" wanting to build their own layer on top of a transport that is mature isn't an argument for building yet another transport. It is just as likely that "everyone" will want to build their own transport. And do it badly.

[andrewmcwatters]

Yeah, no one is going to do that, dude. No one who has a good idea of what they'd like this so-called metaverse to look like is going to wait around with their thumb up their bum while they wait for the IETF to sort out HTTP/3.

Everything you need to do this today already exists. You're right, you don't need to reinvent the wheel, but you'd just be screwing yourself working with a platform as crusty and stupid to work with as the web. You can reuse web protocols, but any sane person today will probably end up building a user agent unburdened by the stupidity web standards groups.

Plus a majority of usefulness wouldn't be done with HTTP. It would be done with DNS so you can do things like vrp:sweetbroandhellajeff.world, reliable UDP for anything meaningfully real-time, and some RPC protocol for packet handling. Why? Because video games do that today.

If you built a fork of Quake and exposed a way to "navigate" to worlds with an address bar of sorts, you'd be 80% of the way there.

You'll need a level format to standardize on, and various other standards would need to emerge, and most of them are probably going to be derivatives or outright ports of existing ones that are in use today.

An informal standard would emerge based on a popular client, then some attempts to hijack it would emerge. Why? Because that's what happened in the past, and what would happen all over again.

If you want to do it quickly, you're not going to use a web browser. You're talking about the same category of people who refuse to implement client side include for the web.[1]

[1]: https://github.com/whatwg/html/issues/2791

Edit: People already know what the requirements are at a minimum because video games exist, and all VR tech today is based on long-existing video game development techniques.

Do you want a floor? Walls? Textures? Guess you're gonna need a level format to standardize on then, yeah? Yeah.

[bborud]

Why would you need to wait when there's already running code you can use? It isn't as if the world's developers are sitting on their hands waiting for IETF to mint a new RFC before implementing.

And if nobody knows the requirements for the "metaverse" yet, then it would be too early to conclude what is needed, right?

UPDATE: turns out Facebook is heavily involved in quic and HTTP 3 already so it is likely they will go that route: https://engineering.fb.com/2020/10/21/networking-traffic/how...

[jayd16]

Unless you need twitch-shooter level ping times in your web app, websockets/TCP is fine. The rendering is client side after all. Nothing about VR rendering would involve the web stack anyhow.

Http/3 is UDP.

So whats wrong with http exactly?

[ahupp]

Just having UDP somewhere in the stack isn't sufficient. The reason game protocols use UDP is because (among other things) they can precisely define when to block on missing data and when to ignore it and keep going.

For example, lets say a client is sent 3 sequential packets, p0, p1, and p2. Sadly, p1 has been dropped by network goblins. What should the client do? Well, that depends on what is in the packets. If p0-2 are messages like "append this value to a list", then it's pretty important for them to all arrive, and in-order. But if p0-2 are sequential updates to the coordinates of something then it doesn't matter if p1 is lost; you get the right final state regardless.

So in the case where you're interacting with something that's continuously moving (like, say, a person in VR) you can essentially never block on transient packet loss because there's always an update coming 10ms later. That's a big deal in terms of making the experience feel fluid.

[jayd16]

It's really not that big a deal. You certainly don't need perfect 10ms packets for most games. Client side prediction goes a long way. For something like VR the physics would need robust client side handling anyway. 10ms isn't good enough.

If we're talking about a virtual web, we will not be spending the server resources on always connected apps the majority of the time. Surely we'll have heavy client side scripting for most interactions.

[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.

[andrewmcwatters]

What's wrong with HTTP is that there's no real benefit to using it in a real-time environment. There's no point. We use reliable UDP abstractions today to accomplish this. Everyone does. There are countless articles on why TCP didn't work for video games, or of the ones that use it today, it's in an extremely limited sense.

I can't think of a single reason why you would go out of your way to serve HTTP over UDP for the purpose of communicating to a user agent for s/video games/virtual reality/, because no one has done that in over 20 years and if it was a good idea, it would have been done by now. But no one does it. Because there's no point.

[andrewmcwatters]

You severely underestimate the application of real-time positioning needs in 3D software. "Twitch-shooter" is an amateur way to describe such an application; real-time positioning is desirable anywhere. Interp only gets you so far.

[jayd16]

I work in games and it's definitely fine for a lot of applications.

[andrewmcwatters]

Great, so do I, and we can disagree all day.

[Shared404]

> Meta is just Mark's way of graduating Facebook to an Alphabet-type conglomerate in order to keep growth moving forward.

Or that Facebook-the-company was receiving lots of bad press, and this is a way to dodge some of it.