Second Life on GitHub

Linus wrote the git version control system specifically to suit the development of Linux.

GitHub made git mainstream, and they made lots of great features for the masses.

But there is no reason for the Linux project to change the way that they like to work just because of that.

Still, a copy of the Linux source tree is also hosted on GitHub. So it seems to me that everyone gets what they want. Linux get to continue their development in the way that they like to do it. People on GitHub can easily find the copy of Linux on GH, and browse the sources there. And they can create forks of the Linux sources on GH too.

I had no idea this existed, and have been looking for it [conceptually] for years. Thanks!

EDIT: Well it does something...

```Sure! Here is a basic client for Second Life written in Python:

import requests

# Set the base URL for the Second Life API base_url = "https://api.secondlife.com"

# Set the endpoint for the login API login_endpoint = "/login"```...

Quick overview:

Second Life / Open Simulator worlds are divided into "regions". Each region is 256m on a side on Second Life, and can be other sizes in Open Simulator. The world is about the size of Los Angeles. The viewer starts out by talking to a login server for a grid, which authorizes it to connect to a region. The viewer then talks to the region. There are short messages over UDP, and some bigger stuff over HTTPS.

Once a viewer is talking to a region, it asks the region server about adjacent regions. The viewer can then talk to a few adjacent regions, too, showing the user a big, seamless world. As the user moves around the world, connections are made to new regions, and connections to regions out of range are dropped. This is how the world scales. There are about 27,500 live regions today, each with its own simulator program, always on even if nobody is using it. Each simulator program takes about one CPU and under 4GB on a server. Second Life is currently hosted on AWS, with dedicated servers. This scales well; the world could be scaled up substantially if there was demand.

The always on feature runs up costs, but the business model is that users rent land. So costs and revenue stay in balance. Regions really are always on - trains run through regions where no one is around, for example. This architecture made more sense when Second Life had their own servers in a co-location facility.

The region servers talk to their direct neighbors. This allows movement across region boundaries. If a region goes down or is restarted, the viewer will show a water-filled hole with steep sides where the region is supposed to be. So the overall system is fault-tolerant.

Content is stored on asset servers, separate from the region servers. These are ordinary AWS web servers, front-ended by Akamai caches. Content includes textures (images in JPEG 2000 format, which is a pain to decompress fast), meshes (a documented but nonstandard format), sounds, etc. There's petabytes of content. The region servers tell the viewers what hashes (UUIDs) to ask for, the viewers get the content from the servers with ordinary HTTPS requests, and all this is assembled in the viewer into 3D images for the user.

Any user can upload new content. Uploading an image costs about US$0.05. Uploading a 3D model might cost $0.50. This is a one-time charge. As long as someone, somewhere, is using that content, it's kept on the servers. There's a garbage collection run every month or so.

Voice is outsourced to Vivox. (Vivox has problems. Not recommended for new designs.)

Coming soon is "puppetry". Second Life is now testing full body and face tracking, for those who want their avatars to run more than canned animations. This involves an entirely new data path by which viewers talk to other nearby viewers via a server that just forwards data. Second Life is getting VRchat features.

So that's what a viewer is. And that's what the architecture of a big metaverse looks like.