Hello, I’m working with the Open Metaverse Interoperability Group (OMI) on figuring out how we might use ActivityPub to represent identity across multiple virtual worlds. Identity in this case being, at a minimum, display name and a url to the person’s avatar model.
Our definition of the metaverse aligns pretty closely with the fediverse. We believe that the metaverse is composed of a series of interconnected virtual worlds. No one organization can control the metaverse and anyone can create and host a connected virtual world. We’re focused on determining pieces that can be interoperable and this identity spec is the first of one of those possible points of interoperability.
I attended the W3C SocialWeb CG meeting this morning and brought up a concern from some people in our community. ActivityPub is a large spec, creating a full implementation is a lot of work. Right now we could get away with only requiring the data expressed in the Actor object and a small extension for the avatar model. Would encouraging members of our community to focus on supporting this small subset of the spec and allowing for servers that only implement the inbox/outbox and activities that modify the Actor object be in line with the views of this community? I’ve seen ActivityPub servers that only support certain subsets of the spec, but this is a very extreme case. Would we be creating a mess if we encouraged people to do this?
I don’t see how we can require users wishing to develop their own server implementations for our use case to implement the whole ActivityPub spec. Certainly, some will take the existing full implementations like Mastodon and extend it to support OMI’s specs. But people want to be able to implement the whole stack themselves. Removing requirements for additional complexity that we won’t use seems like a good way to get people on board with ActivityPub in our field.
If you’re talking only about identity, then you don’t even need a server application, strictly speaking — a static json file with the actor would suffice. You only need the inbox if you want to receive activities. And I can’t recommend my own approach enough: treat ActivityPub as an API you expose for other servers to interact with.
Hey! First off, welcome! Sorry I couldn’t be at the meeting this morning, since it’s during my working hours, but this is a very interesting space and I’m really glad to see more standardization around it!
However, I’m a little confused about this question—the server to server spec is already very minimal, doing almost the bare minimum needed to set up a actor-based publish/subscribe framework.
It sounds like what you want isn’t an actor-based publish/subscribe framework, and instead you just want to use ActivityStreams 2 for representing information about your social network. AS2 is a separate spec defining the data model that ActivityPub implements its pub/sub functionality on top of. If you’re not looking for any of the publish/subscribe functionality of ActivityPub, then maybe starting with as2 is a better bet?
This is neato! I spent a while pondering, and my thinking goes: pub/sub is useful for mesh behavior that is client-driven, as opposed to server-driven.
Accounts publish links to datastreams that import meshes and their transforms.
Subscribing to an account means rendering that account’s meshes in 3D space.
Under this framework, even avatars are client-driven meshes.
There’s no existing metaverse this robust and extensible. ActivityPub-conforming interoperability is practical only if you’re willing to navigate the unfamiliar territory of a novel metaverse framework.
If you’re talking only about identity , then you don’t even need a server application, strictly speaking — a static json file with the actor would suffice.
It sounds like what you want isn’t an actor-based publish/subscribe framework, and instead you just want to use ActivityStreams 2 for representing information about your social network.
Thank you both for pointing that out! I get caught up with the inbox/outbox concepts of ActivityPub, but you’re right, we’re looking at the Actor’s data more than the federated pub/sub aspect of it. But even still, it can be fairly simple to implement. I’ll go back to our community with these responses and see what people think.
Also, that conformance thread is very helpful, thank you @aschrijver!
This is a great suggestion for @robertlong . ActivityPub is a bit of a turducken of specs, inside is ActivityStreams 2 which gives you the actor model & vocabulary, and ActivityPub on top is pretty much just adding a few properties to the Actor for federated pub/sub endpoints (inbox, outbox, followers, following, et c) and the implementation details of those endpoints.
It makes sense as a starting point. I think you’ll find pretty quickly that you want ActivityPub as well to make it functional. e.g. You’ve got an actor object, but how does one change their current avatar? ActivityPub client-to-server offers a standardized protocol (post an Update activity to one’s outbox) and then ActivityPub server-to-server distributes it so that your contacts are made aware of your new avatar.
However, if you start with ActivityStreams 2, then any progression into ActivityPub can be smooth and incremental, so it makes sense as a starting point.