evanp
commented
1 year ago I wrote a document on the Primer on Server-Managed Collections, based on discussion during triage:
https://www.w3.org/wiki/ActivityPub/Primer/Server-Managed_Collections
In general, it agrees with your notes, that client software should not use Add, Remove to manage these collections. We also noted that they should not be manipulated with Update or Delete.
One case we discussed where this might make sense is for moderation of collections on an object that are initiated by someone who isn't the original author. Using a Remove activity to take an inappropriate or offensive reply out of the replies list is a good example, and does not have an equivalent in the rest of the AP spec.
I'm going to mark this as Pending closure.
nightpool
There are special collections that are managed by server side-effects, such as
followersfollowinglikedon actors and possiblyreplies,likes,shareson objects. In most cases, the side-effects are the only intended way of interacting with these collections; for example, a Follow results in an Accept Follow, which has the side effect of adding them tofollowersand them adding you tofollowing; a Like has the side effect of you adding the object tolikedand them adding your Like tolikes; an Announce has the side effect of them adding the Announce toshares, and a small exception forreplieswhich may be managed manually.But there's nothing in ActivityPub explicitly preventing a user from targeting their followers/following with an Add/Remove. In the case of a Remove, you can say that there is a legitimate use-case for this; perhaps you no longer wish to follow or be followed by a certain actor. However, for Add, it's a bit weirder -- you can Add an actor to your
followersdespite never receiving a Follow from them. You can add an actor to yourfollowingdespite never receiving an Accept Follow from them.There is some language that can be interpreted along these lines, in 6.5 Follow
and in 6.6/6.7 for Add/Remove:
Taken together, we conclude that the logical
iffregarding Accept Follow is the only way to add the other actor to your following. A C2S Add/Remove would not be allowed due to "discretion".Given this: how do we signal server management instead of actor management of these collections? My initial leaning would be to exclude
attributedTofrom the representation of these collections; in the absence of any attribution, it is assumed that the collection is owned by the server running at that origin / domain / hostname. (For S2S follower removal, this would have to be a special case handled similarly to Reject Follow being sent at any time after an Accept Follow, but that's a separate topic.)Perhaps this is more important for followers/following, but it is relevant to the other "special collections" too.