Unresolved issues surrounding Follow activities

First, some context…

What the C2S spec says:

6.5 Follow Activity

The Follow activity is used to subscribe to the activities of another actor.

The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor’s following Collection when and only if an Accept activity is subsequently received with this Follow activity as its object.

What the S2S spec says:

7.5 Follow Activity

The side effect of receiving this in an inbox is that the server SHOULD generate either an Accept or Reject activity with the Follow as the object and deliver it to the actor of the Follow. The Accept or Reject MAY be generated automatically, or MAY be the result of user input (possibly after some delay in which the user reviews). Servers MAY choose to not explicitly send a Reject in response to a Follow , though implementors ought to be aware that the server sending the request could be left in an intermediate state. For example, a server might not send a Reject to protect a user’s privacy.

In the case of receiving an Accept referencing this Follow as the object, the server SHOULD add the actor to the object actor’s Followers Collection. In the case of a Reject , the server MUST NOT add the actor to the object actor’s Followers Collection.

Note

Sometimes a successful Follow subscription may occur but at some future point delivery to the follower fails for an extended period of time. Implementations should be aware that there is no guarantee that actors on the network will remain reachable and should implement accordingly. For instance, if attempting to deliver to an actor for perhaps six months while the follower remains unreachable, it is reasonable that the delivering server remove the subscriber from the followers list. Timeframes and behavior for dealing with unreachable actors are left to the discretion of the delivering server.

Special collections:

5.3 Followers Collection

Every actor SHOULD have a followers collection. This is a list of everyone who has sent a Follow activity for the actor, added as a side effect. This is where one would find a list of all the actors that are following the actor. The followers collection MUST be either an OrderedCollection or a Collection and MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

Note: Default for notification targeting

The follow activity generally is a request to see the objects an actor creates. This makes the Followers collection an appropriate default target for delivery of notifications.

5.4 Following Collection

Every actor SHOULD have a following collection. This is a list of everybody that the actor has followed, added as a side effect. The following collection MUST be either an OrderedCollection or a Collection and MAY be filtered on privileges of an authenticated user or as appropriate when no authentication is given.

In summary… C2S Follow puts a Follow activity in your outbox, your server waits for an Accept, then adds that actor to following. S2S Follow takes a Follow activity in your inbox, your server wraps it in Accept/Reject and delivers that. S2S Accept Follow adds that actor to followers. (All of this is SHOULD language.)

However, this leaves some things too ambiguous…

Following only a subset of activities

By default, when you Follow an Actor, most implementations interpret that as a sign of interest in every single activity that the actor publishes, similar to the note in 5.3 (“The follow activity generally is a request to see the objects an actor creates.”). But there is no way to signal an interest in receiving only some of the activities. Perhaps the only possible concession here is the streams property of an actor, but there is basically nothing to guide implementations aside from a passing mention that is only 10 words long:

streams
     A list of supplementary Collections which may be of interest.

This suggests a pull-based approach, where you can GET the streams of an actor… but you cannot have the actor deliver any activities from those streams. Nor is it explicitly defined whether these collections contain activities or objects, or what the collections are actually for (aside from heuristically guessing based on the name of the collection?) Perhaps there could be a way to consistently understand these collections and maybe follow just those streams instead of the actors, but that would require…

Following non-actor objects

Per 6.5, “The Follow activity is used to subscribe to the activities of another actor.” But sometimes you don’t necessarily care what a single actor does with multiple objects, you care about what multiple actors are doing with a single object.

AFAIK some implementations interpret Follow Object to generally mean that the software will deliver any activities targeting that object to any actor that has expressed interest through the Follow Object activity. Perhaps this should be formalized, as the following are currently not agreed upon:

  • Who should you send the Follow Object to? The attributedTo actor? Does following that object imply also following the actor?
  • How should you keep track of followed objects? Should they be added to the following collection like actors? Should individual objects define a followers collection?
  • How do you know if an object is followable? If you send a Follow Object to remote software, it may not understand it. Is the presence of a followers collection enough for this? Does it also need attributedTo? Some other method?

Practical applications

As prior art, Google+ Collections come to mind. For each post made to Google+, a user could choose to address it to Public, or to selected users (like actors), or to a Circle (like a collection of actors), or to a Community (like a group), or to a Collection (like a category/stream). This could be seen as confusing since it wasn’t really well-explained to users what any of these concepts meant, and Google+ also used Circles both for addressing those users and for viewing posts from those users, whereas most other services have a separate Lists feature for viewing posts from a subset of users. In essence, users can categorize their posts at the same time as they choose who to address them to. Consider the following hypothetical documents:

{
"id": "https://social.example/actors/1",
"type": "Person",
"inbox": "https://social.example/inboxes/1",
"outbox": "https://social.example/outboxes/1",
"followers": "https://social.example/actors/1/followers",
"streams": ["https://social.example/collections/1"]
}
{
"id": "https://social.example/objects/1",
"type": "Note",
"content": "a simple note",
"attributedTo": "https://social.example/actors/1",
"followers": "https://social.example/objects/1/followers"
}
{
"id": "https://social.example/collections/1",
"type": "OrderedCollection",
"items": ["https://social.example/objects/1"],
"followers": "https://social.example/collections/1/followers"
}
{
"id": "https://social.example/activities/1",
"type": ["Create", "Add"],
"actor": "https://social.example/actors/1",
"object": "https://social.example/objects/1",
"target": "https://social.example/collections/1",
"to": 
  [
  "https://social.example/actors/1/followers",
  "https://social.example/objects/1/followers",
  "https://social.example/collections/1/followers"
  ]
,
"cc": ["as:Public"]
}

Etc

Any comments, additions, etc. about this?

1 Like

I should also add some discarded approaches that I considered at one point while thinking about this but determined to be too problematic:

  • interpreting a Follow as subscribing to multiple actors instead of just one
  • multiple outboxes (although this might still be applicable to other problems, just not this one for now)
  • using Profiles instead of Actors (though this could still be done, it would be unsupported in current implementations; it would however become possible to Follow Profile instead of Follow Actor)
  • having objects just be made into actors, a la the concept of message passing in computer science (although this adds a lot of complexity because objects generally only need a small part of what Actor provides)
  • hackily having multiple actors representing the same Person, but using them to create objects, then Announcing those from a more “central” actor (too complicated and unwieldy)

@cwebber please see “following non actors” (‘streams’)

See also github

jaywink

Evan

1 Like

It seems to me that if you want to Follow an Object, then this object must have a dedicated proxy Actor for any activities on this Object. Unless I’m missing something, there’s no need to overthink it: the Object's Actor could be an `Application

Sure, but how should we discover this?

As stated above I went with attributedTo and the presence of a followers property, but perhaps it may be better to use an explicit endpoint like inbox?