Model Justification

An alternate approach would be to create a "virtual world browser," which is a universal virtual world client, just like a web browser is a universal HTML client. Unfortunately, that's a terrible idea, for several reasons:

1. Virtual worlds are about interacting with lots of people. That's very different from the model of a web browser, and thus requires a different approach.
2. Virtual worlds are about real-time, interactive, low-latency 3D. This requires a very different approach than the current "web 2.0" web services.
3. The amount of technology that goes into doing a 3D world is two orders of magnitude greater (or more) than what goes into doing a 2D web page. If there were a universal client, it would either have to re-implement everything that all the current providers already have to some arbitrary new standard, or it would have to standardize on one incumbent provider technology. Neither is likely to be popular among all the other virtual world providers.
4. With universal clients, you don't actuall solve the "what does a unified world look like" problem. Each client would have to disconnect from one system, and connect to another system, for each new "place" that was visited.
5. It will make innovation very hard, because you couldn't really get enough support on client and server side to get critical mass. As an example, it took 15 years before the majority (and not all!) web browsers supported client-side XSL with any consistency. Virtual worlds have orders of magnitude more complexity in them than XSL, so I hope we can find a better model.
6. Compare to 3D online games, where everybody have to use the same version of the client software for the game to work. What if virtual world site A *required* client version 1.32, but site B *required* 1.29?

Instead hooking the servers together on the back end looks a lot more attractive:

1. It's a problem a virtual world provider has to solve anyway, so it might as well be solved in a standard way.
2. It allows the well-tuned server/client infrastructure that already exists to be re-used, providing a much better user experience.
3. It allows a virtual world hosting provider to innovate, because the client and server can be kept in sync using whatever patching system that provider likes.
4. The user has a relationship with a VWSP (Virtual World Service Provider), similar to he/she has a relationship with an ISP, or an e-mail provider. It's up to that single VWSP to provide a high-quality experience. That's a lot easier to manage than getting arbitrary levels of quality from arbitrary point-to-point connections on the web.
5. The incremental engineering effort to get there from here is small, with no danger of favoring one platform over another, or requiring re-implementation of technology that's taken 10 years to build.

Thus, this proposal will get to the interoperable, open "3D web" a lot quicker, with more diversity, fewer bugs, a lot cheaper than the proposal of a universal virtual world client.