In my previous post ( Vircadia Directions ) on the directions I’d like to take the Vircadia project, I talked about integrating ActivityPub as the socialization backend to the metaverse-server. That has lead me to several days of researching ActivityPub, ActivityStreams, the various implmentations of same.

The idea is to use the ActivityPub system to create a “Fediverse” of virtual worlds and thus leverage an existing infrastructure and community.

The original Project Apollo metaverse-server design has a server that presents the MetaverseAPI (REST/JSON/…) and has a custom designed backend database to store information about accounts, domains, account relationships (friends, …), and domain connection information (ICE servers, chat servers, …).

The diagram to the left shows this structure (with the “domain-servers” simplified into one box that includes the “assignment clients”). In this structure, the only interface that is “standard” is the “MetaverseAPI”.

In thinking about adding ActivityPub, I first thought I’d add a MongoDB database on the backend (since everything is JSON) and an ActivityPub interface on the frontend. This would allow the existing domain-servers to talk to the metaverse-server and any other metaverse-servers and ActivityPub application to communicate with the users in that metaverse.

But this would mean writing a lot of code (the ActivityPub interface) just to interface with the metaverse database. Looking around, there are several system implmenting ActivityPub and some services that could just be used.

But then, I realized that the metaverse-server just creates and manages accounts and manages the domain-server interconnections. What if I just considered the metaverse-server a MetaverseAPI to ActivityPub protocol converter?

Since the ActivityPub protocol already has all the functions for creating and managing account as well as functions to create and and manage collections of objects (like domains), an ActivityPub server could act as the database for the metaverse-server.

ActivityPub servers already have authentication and access control conventions.

I first thought that I could just use a Mastodon server as the backend metaverse database but I believe that we will want to be extending the functionality of the server. This work is extending the ActivityPub social network model into virtual worlds so there will be special features like chat groups that only work with the people close together. Thus, location and distance need to be added to status and filtering.

At the moment, I am considering the ActivityPub-Express project which is a pretty well written NodeJS/ExpressJS/MongoDB based ActivityPub server.