I'm over here theorizing what an ATProto-based "metaverse" might look like

I'm over here theorizing what an ATProto-based "metaverse" might look like (I think I want to call a section of the metaverse, bound by a protocol or closed platform, a "galaxy"; and under a protocol, the next level might be "sector"). Using a lot of the existing mechanisms Bluesky uses, and a few new ones.

A full, vertical service (think Bluesky or VRChat) would include:

• A personal data service (PDS), which would remember the user's avatar, favorites list, etc, and store published worlds and avatars. I'm not 100% sure how support works but you should be able to use any PDS for this -- so if you already have an account at Bluesky, you can simply sign in to that and let them store your stuff.
• An auto-scaling service of some kind to actually manage game sessions. This should be protocol-based, of course, and ideally it should be engine-agnostic.
• A PLC directory that hosts the did:plcs of users using that vertical service. Of course it would next crawl plc.directory, and any other PLC directories it sees in DID documents it receives through other means.
• A graph service (relay?) that handles discovery of new worlds and avatars.
• It doesn't use any of Bluesky's lexicons. Instead, it opts to fork them. The feed-gen system is one example of this; it would connect to the graph service to create and return recommendations, very much like the various world rows in VRChat and feeds in Bluesky.
• A limited-use avatar system, where World Viewers (App Views for the ATP-based metaverse) might need to be blessed to render them (to help fight ripping the avatars) and users would need to be blessed (labeled?) to wear them. This could enable the use of Fortnite or Roblox avatars on other platforms, if they wanted to.
• Avatars would probably manage their own physics, animations, and interactions -- World Viewers should have one button dedicated to the avatar, so it can open a menu or perform an action or something.
• Avatars and worlds would be handled like posts. You can maybe even comment on them and like them, and also favorite them (which would add them to a list). Editing (or rather, submitting replacement versions and potentially "labeling" them as replaced?) might be important to submit revisions.
• Avatars would need to either have multiple engine versions or one agnostic version (which would probably be .glb/.gltf). Worlds, however, would need to match to a World Viewer (the official World Viewer offering would probably be in either Unity or Godot, but support for Unreal World Viewers would exist too). You might be able to get away with a world-per-Viewer mapping... (The VRChat Client, if it joined this galaxy, would be considered a World Viewer.)
• A moderating labeling service for worlds and avatars, which all users who sign up with the official app view would be subscribed to by default. If you sign in with a Bluesky account or other PDS you'll be asked, but not required, to add it.
• The official mediating servers would not allow users with certain labels to connect. You can build your own, but there will be no official self-hosting option. (This is both from a responsibility perspective and a profit perspective.)
• Maybe a banner ad service, right out the gate. You use their SDK or whatever to put ad banners in your world, get it approved (i.e. it's in a good spot, it's not too big, etc), and you can make some of the money the company makes from running ads in your world. (This might be a good way to make it a sustainable operation. Maybe.)
• Optionally, you can opt out of using banner ads and run PSA banners instead. (Or, of course, neither.)

I feel like this would be a lot harder to achieve, and make a lot less sense, with ActivityPub:

• ATProto has inherent portability. You don't have to be on the Official PDS to participate.
• ATProto's PDSes appear to be app-agnostic storage facilities, which makes them good for this.
• ATProto's identity system, domain handles mapped to DIDs (which are technically optional, I think), means that one identity can be shared across multiple World Views (sectors?), including avatars, names, and authorizations (inventory!).
• ActivityPub offers no built-in method to upload media, nor any system to safely proxy or validate downloads. Each AP implementer has their own mechanism for this (although most of them just use Mastodon's).
• There are very few ActivityPub implementations, all unpopular, that actually implement its client-server API, so you lose the advantage of account reusability: you can't use your Mastodon account to join an ActivityPub-based world, or to store your avatar.

Other technical bits:

• Maybe the URL for a world might look like: at://disney.go.com/world.cloudcuckoo.world/d7wi5gm9p6qz
• and for an avatar:
• at://epicgames.com/world.cloudcuckoo.avatar/augip2mfho9d
• of course these are the impermanent/display versions, and supporting software probably should actually link to the at://did:* version instead.
• these both would link to metadata, like world name and description, and links to thumbnails and the world itself on different platform-worldview combinations