For example, should hashtags be actors?
If one implementation treats something as an Actor that would not be considered to be an Actor by other implementations, what happens when they try to federate and send messages to each other?
Any recommended “standards” or commonly understood rules of thumb for what should and should not be an Actor?
This is up to the implementation. I imagine messages that aren’t understood will simply be dropped.
if it can perform an Activity, it is an Actor. Actor is required to have inbox and outbox, per https://www.w3.org/TR/activitypub/#actor-objects
Probably not – you’d probably want to pursue “Following non-actor objects” from Unresolved issues surrounding Follow activities and the surrounding discussion.
Thanks for the tip, that’s a useful discussion.
It’s interesting to note that there are several “Actor types” defined: https://www.w3.org/TR/activitystreams-vocabulary/#actor-types and Group is one of them. In #software:andstatus data model I recently implemented Groups as a kind of Actors. Because they both can be Recipients in the Activities.
But it’s not that easy with Group’s profile, inbox, outbox… Maybe we can think of some User writing a broadcast message on behalf of the Group?!
As I currently see in initial #software:mastodon implementation of #activitypub:c2s “Followers of AndStatus” group has this id https://mastodon.social/users/AndStatus/followers and it’s represented as an “OrderedCollection” object, and not as an Actor. Unfortunately…
The model right now in most implementations that use Group is to treat the outbox as a “wall” similar to Facebook. Followers of the Group are its members, and when the Group actor receives a message from one of its members, it publishes an Announce to its outbox. Of course it is possible at an application level to authorize as the Group itself and publish a status attributedTo the Group actor directly, rather than one of its members.
The Collection should be dereferenced to find each member Actor, since it is a collection of actors and not an actor itself. Do also note that the type field does not have to be Actor or one of its subtypes; the real definition of an actor is that it must have both inbox and outbox. Types within ActivityPub are merely a suggestion on how to process data (as defined by the @context schema).
I think that automatically wrapping each Activity into Announce looks ugly.
The group (i.e. a Server hosting the group) should act nearly transparently. My experience (dealing with activity recipients…) shows that having a group in the explicit list of recipients is enough for a client app to understand, why any activity arrived AND enough to properly address recipients in a reply to such an activity.
Naturally, if you reply to a post, which was sent to “GroupA”, it’s natural to add that group to the list of reply’s recipients thus keeping the same audience in the loop of discussion.
Yes, but the type of a Group (type of an Actor) shouldn’t be “OrderedCollection”.
The question is: what Group’s “endpoint” should point to a list of its members (to that "OrderedCollection of Actors)? That endpoint is not inbox or outbox…
PS: Regarding groups @trwnh you may be interested in this post: https://github.com/andstatus/andstatus/issues/248
It works, though. The other way it can be done is inbox forwarding technically… But I’m only talking about other actors posting on the wall of the Group, which would be Announced into the outbox.
Yes, that would be the ideal case.
It would be followers which SHOULD be included (although membership in a group does not have to be public information, so the endpoint may require authorization or may not be present). It should not be necessary to know the members of the group, as addressing should be done to the Group, and the Group should handle any incoming posts addressed to the group.
As another user pointed, according to ActivityPub spec Followers and Following really are Collections, so I shouldn’t expect to find a “Followers group” object on a server… Groups implementation
Ah, yeah, followers/following aren’t Group actors.
Mastodon doesn’t support Group actors, but if it did, then you might expect the Group to be mastodon.social/users/AndStatus or something like that (i.e., in the actor namespace).