As I discussed in my ideas on Vircadia Directions, it would be cool to implement virtual world federation using existing social networks. I discussed ActivityPub but the other one mentioned is Matrix.
Both ActivityPub and Matrix are open-source, non-centralized federation systems with active and busy communities. But they each seem to be built for different appliction designs and have different architectures and uses.
Let me discuss each.
Matrix is a decentrialized infrastructure where anyone can run a “home-server” that links into the larger synchronization space. The collection of “home-server”s implement “rooms” which contain JSON objects that are signed and securely synchronized across the home servers. Matrix design leans toward security and authorization so there is a strong emphasis on identity and encryption.
The base communication system is JSON sent between clients and servers using HTTP REST operations, the model presented is of “rooms” that are magically distributed across all of the connected home-servers. Of course, there are optimizations so rooms are only synchronized across home-servers with clients that are listening to those rooms. Encryption and identity management prevent snooping and corruption.
Matrix application model leans toward the concept of chat rooms with decentralized infrastructure thus applications that mimic Discord or IRC are easy to implement. But the infrastructure has been generalized into a de-centralized, JSON object synchronization system which enables applications like IoT sensor devices reporting status and many more applications.
One downside is that, even though room contents are synchronized between homeservers that have room clients, the room contents themselves “live” on that room’s homeserver. If that one homeserver is down, then the room is unavailable. This means Matrix is a distributed communication system rather than a distributed data system.
- Secure encrypted communication.
- “Rooms” could fit with chatting in domains.
- Not completely distributed
- Adding a metaverse-server to the federation would involve connecting it to a Matrix home-server;
- One needs a “matrix account”. When a user creates a metaverse-server account, the metaverse-server would have to create an account on a home-server
ActivityPub is a W3C standard (the group that does the web application level standards like HTML, CSS, SVG, URL, RDF, …) that defines client-to-server and server-to-server interactions which implement a decentralized “social network”. Through multiple JSON-formatted HTTP requests, content in “streams” is added to, read, edited and deleted while activity notifications and content is distributed.
The definitions of ActivityPub is very much around “micro-blogging” (think Twitter). ActivityPub defines “actors” who each have an “inbox” and “outbox”. An actor POSTs a message to their outbox and the message is sent to the inboxes of addressed recepients. Actors can also have “collections”. A defined collection is “followers” thus a message can easily be addressed to one’s “followers” (like Twitter). This would be like a Tweet that shows up in the “streams” of the receivers (if a user views their inbox like user’s view their Twitter stream).
This is how Mastodon implements a distributed micro-blogging service where many servers make up a system where one could “follow” people and bots from other servers and view one’s own stream of subscribed posts.
Using other W3C standards, identities are distributed, referenced “names” can be dereferenced WebFinger into URLs to inboxes and profiles, messages can be authorized HTTP Authentication and verified HTTP Signatures.
- Identites can easily be created and shared across federated servers
- Actors and collections could fit with chatting in domains and groups.
- REST/JSON APIs allowing scripts easy access to users, actors, …
- Not completely distributed
- Would have a lot of URL traffic between metaverse-servers