Actor type and predicates

[srosset81]

• Attach a as:Person (or as:Organization or as:Group) type to WebID
• Attach AS-specific predicates such as as:name or as:preferredUsername to WebID

[srosset81]

One problem I see is that many Pod providers use the famous #me hash to differentiate the document from the webId itself. I don't know if many ActivityPub servers will look into the hash to find the actor. This is something to try.

Luckily it seems the webId specification is going to be abandonned, since no one is responsible for it anymore. A lot of people are talking about switching to DID. But in the meantime, we may be blocked by this particularity, that is not used anywhere else in the Solid world.

[srosset81]

@mrkvon asked me:

first interesting question is whether Solid webId and AP profile need to be at the same URI or not. Do you have experience with that ?

In ActivityPub there are two different things: the actor, and its profile. The profile, which is an ActivityStreams class on its own, is not mandatory. We use it in ActivityPods as a way to keep a private profile. On the other hand, the actor resource (who may be a as:Person but other actor types are allowed) must always be public, because it includes the link to the inbox, as well as the public key: so if another actor wants to communicate with this actor, it needs to have access to their actor profile.

For me, it wouldn't make sense to split the WebID and the actor, because they are very tightly related. Is this what you were suggesting @mrkvon ? Why would you want to split them ?

For an example of a WebID with ActivityPub attributes, you may have a look at my ActivityPods profile.

[mrkvon]

Why would you want to split them ?

I 💯 prefer them to stay together, if possible. I just assume that NSS or CSS pods won't respond with the particular json-ld format or content-type that ActivityPub servers might expect. Having a possibility of a separate (linked) actor or profile could mitigate that.

Please note that I'm writing without a deep understanding of actor and profile or their differences. I have a vague awareness that AP implementations may often process JSON-LD as JSON, not as RDF.

update: looking at your profile @srosset81, I think it's a good example of the nice format that AP servers might expect. Based on my brief tests, CSS doesn't treat the @context and ActivityStreams predicates in any special way, when it produces json-ld, and underlying data format is turtle (default).

[mrkvon]

One way to host actor on Community Solid Server is to PUT it with content-type:application/activity+json. We then get response with the same content-type. This seems to allow it to be resolved by Mastodon.

In this case, the actor must be a separate resource from webId profile, though. Maybe we could eventually choose predicate(s) to link an actor and webId profile together, when they can't be in the same document for technical or whatever reasons...

[jg10-mastodon-social]

My preference is to keep the webid and actor separate. They represent two logically different entities with different authorization and data access behaviours.

From a user interface perspective they absolutely could be combined but even for a power user (let alone a developer) I think it's important to understand that there is a sharp separation. The two protocols are interoperable and there are specific resources that they share access to, but they remain distinct.

[jg10-mastodon-social]

A more specific argument:

• A linked data notification inbox (which is essentially how Solid receives activities) can be discovered from any resource. A webid is not involved at all if the inbox is public append, and only involved for authorisation otherwise.
• There is only one ActivityPub inbox per actor, with actors and their inboxes discovered through webfinger. The sending actor signs activities with their private key.

A single Solid pod (with a single webid) may want multiple actors and inboxes associated, and when receiving ActivityPub activities the webid is not involved.

[mrkvon]

A linked data notification inbox (which is essentially how Solid receives activities) can be discovered from any resource.

I'm not sure it is a MUST. In practice I don't see the discovery header present when GETting a resource from CSS. The inbox linked from webId is the only (semi-)standard inbox I have seen in pods, which doesn't seem to be a MUST either.

[mrkvon]

Regarding the many-actors-per-pod approach, my intuition so far has been to prefer a single (universal) actor (in extension also the preference for a single URI for both the webId and actor). Can you elaborate on use cases for multiple actors per pod? For example when would it be desirable for a human to keep several actors or add a new one?

[jg10-mastodon-social]

That's correct - LDP inboxes are optional on resources - but they can be added to any resource. On CSS one would just PATCH the container's description resource.
https://communitysolidserver.github.io/CommunitySolidServer/latest/usage/metadata/#example-of-a-workflow-for-editing-a-description-resource

How many inboxes/actors are used depends on the use case.

• LDN is naturally geared to commenting on a resource, with the comment going to the resource's inbox.
• As a social media consumer, Mastodon, Peertube and Pixelfed are naturally geared to following, commenting, liking etc., which is why it makes sense to just use a Mastodon actor to follow all three. It's still common for people to have multiple accounts (including email accounts) for different purposes/topics - and therefore different actors.
• When sharing media, it makes sense to have a home page that is customised to a media type, which is one of the reasons that diverse ActivityPub apps exist. If someone goes to an actor's homepage. They expect to see an experience tailored to videos/photos/microblogging/blogging rather than a mishmash of everything. This lends itself to multiple actors, but could all be controlled with the same webid.