Give recommendation on how to identify an "actor" in the spec

[evanp]

from @trwnh in #469:

Define "actor"

This is relevant in the following scenario:

Say you discover a random JSON-LD document with ldp:inbox present. How do you know that it accepts ActivityPub activities at its inbox, or that it follows ActivityPub semantics for those activities?

One way to be somewhat sure of this is to check if the Content-Type on the document exactly matches an ActivityStreams media type: application/ld+json; profile="https://www.w3.org/ns/activitystreams" or application/activity+json. However, this is something that has been described in proposals like https://w3id.org/fep/96ff as not sufficient -- it has been pointed out that one can use AS2 and not AP. Consequently, this FEP suggests using a Link header with rel=type, but this mechanism would not be available outside of an HTTP context, such as when a document is persisted on-disk. Therefore, it would make more sense to have a type/class defined within the normative ActivityStreams context that explicitly signals these semantics.

I am not immediately sure whether https://www.w3.org/ns/activitystreams#Actor needs to be defined or whether it could fulfill this role, but based on the criticism in the FEP above, it might need to be something more explicit like ActivityPubActor and not just Actor. This subpoint may be resolvable by writing a FEP defining such a type.

(There is a tangential point regarding AS2 and the AS2 non-normative ontology, where Actor does not exist as a class, and therefore all "AS2 Actor types" are actually directly subclassing from Object instead.)

Note also: this could maybe be also possible by duck-typing based on the presence of something like as:outbox.

[evanp]

I think the only way you can tell if the inbox accepts activities is to send one!

There's a whole section on Actor objects in the specification. I think the main way to tell that something is an AP actor is if it has all the required properties (inbox, outbox, followers, following, liked). If an object does not have those, or only has an inbox, you can try it, but there's no guarantees.

I think the work of deciding what to do with an incomplete actor is probably best handled as a primer page, not in the spec.

[evanp]

So I think the question is if we receive an object like this, perhaps as a part of another payload:

Publishers should do this:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "id": "https://example.com/foo",
   "inbox": "https://example.com/foo/inbox",
   "outbox": "https://example.com/foo/outbox",
   "following": "https://example.com/foo/following",
   "followers": "https://example.com/foo/followers",
   "liked": "https://example.com/foo/liked",
   "type": "Person"
}

If consumers see this, they have to guess. There's not a 100% certainty, but there is a strong probability that it is an AP actor.

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "id": "https://example.com/foo",
   "inbox": "https://example.com/foo/inbox",
   "type": "Person"
}

[evanp]

The other way we could do this is with an Actor type, and we use multi-typing or "inheritance" in to mark an actor.

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": ["Document", "Actor"],
   "id": "https://example.com/doc/1",
   "inbox": "https://example.com/doc/1/inbox",
   "outbox": "https://example.com/doc/1/outbox"
}

[nightpool]

What user story does this serve? When are users "encountering random JSON-LD objects in the wild" that don't have an ActivityPub actor type? (what does "in the wild" mean here? Presumably it doesn't mean "through the UI of my social networking client")

EDIT: i guess maybe the more relevant question is "Why do you care if an actor has an outbox or not?". If it has the required properties for displaying it in the UI (name, photo, bio, etc), you can show it to users. If it has an inbox, you can send activities to it. If it doesn't want to respond to your ActivityPub activities—that's its prerogative, no matter what reason it's choosing to ignore your activities for (doesn't support them, has you blocked, etc)

[trwnh]

user story: "as a user/client, i want to know that i can send specifically Activity objects to this inbox and have them be processed according to activitypub semantics."

"activitypub semantics" in this case refers to the side effects of activitypub activities as described in the activitypub spec. right now, you just have to guess, based on the presence of other properties, sort of like "duck typing":

• if it has as:followers and ldp:inbox then i can probably send a Follow
• if it has as:likes and either it has ldp:inbox or it has as:attributedTo that has ldp:inbox, then i can probably send a Like
• if it has as:shares and either it has ldp:inbox or it has as:attributedTo that has ldp:inbox, then i can probably send an Announce

or in practice everyone just assumes you can always send these activities at any time, without any knowledge of whether the side effects will get processed as you expect.

If it doesn't want to respond to your ActivityPub activities—that's its prerogative, no matter what reason it's choosing to ignore your activities for (doesn't support them, has you blocked, etc)

i don't think "just continue to send activities anyway" is the ideal outcome here. it's not about knowing that your side effects will get processed (because, as you point out, there are valid reasons they might not get processed), but rather, it's about hinting that there is a possibility that side effects will be processed. the presence of followers implies some support for Follow. the presence of likes or shares implies support for Like or Announce.

right now, again, we only have duck-typing to go off of. inbox and outbox are the only required properties of activitypub "actors". so if something has both inbox and outbox, we can guess that it will generally behave according to activitypub semantics, and that maybe you shouldn't bother sending it LDN payloads that aren't of type Activity or a sub-type.

[nightpool]

user story: "as a user/client, i want to know that i can send specifically Activity objects to this inbox and have them be processed according to activitypub semantics."

That's not a user story, that's a developer story: https://www.w3.org/TR/design-principles/#priority-of-constituencies

[trwnh]

it's a user story when i need to decide who i'm sending to. i want to have some idea of what they'll do with my activity. right now, there's not even a hint of that. "actually you have no idea what will happen" is generally user-hostile system design.

[silverpill]

I wrote FEP-2277: ActivityPub core types (pre-draft), where an algorithm for identifying different object classes is presented, and a corresponding self-consistent classification. That algorithm has been successfully used "in the wild" for a prolonged time.

tl;dr: actor object can be identified by the presence of inbox property.

In addition to this issue, the FEP may help resolve several others:

• Formally define "activity" at the spec level #469 (according to the algorithm in the FEP, activity can be defined as "object with actor property and without inbox property").
• Is Actor a core type? activitystreams#633
• Delivering to Collections can be ambiguous #486