Follow on a non-Actor object

[jaywink]

There is some confusion in the ActivityPub specification on what a Follow can be made towards.

The C2S part says "The Follow activity is used to subscribe to the activities of another actor."

https://www.w3.org/TR/activitypub/#follow-activity-outbox

This seems wrong since IMHO it should be a perfectly fine use case to Follow { Note } for example which correlates directly to the Diaspora protocol Participation (https://diaspora.github.io/diaspora_federation/entities/participation.html) which is an important mechanism to subscribe for follow-ups or updates.

This discussion came up in the ForgeFed specification building on top of ActivityPub and thinking whether an Issue also needs to be an actor.

Forum link: https://talk.feneas.org/t/following-non-actors/159

[nightpool]

I think it's perfectly fine to want to use the as2 verb Follow for such cases, but it's important to understand that it's currently outside of the scope of the ActivityPub spec and would need an extension (not least of which to the vocabulary, as we already discussed on IRC, so you know which actor you're expecting the Accept from)

While the s2s spec never explicitly comes out and says that the correct domain for the object property of a Follow is Actor, it implies it in many places, for example the SHOULD requirement quoted below:

the server SHOULD add the actor to the object actor's Followers Collection.

Obviously, non-actors do not having Follower collections and cannot fulfill this requirement. More generally, many existing systems, such as mastodon & pleroma, are only set up for following Actors and you have to think about what compatibility with such systems means.

In lieu of a dedicated UI action for following non-Actor objects, how do you expect to be compatible with such systems? (Do you expect to be compatible with such systems?) What does the user experience of opening a ticket / replying to a ticket / subscribing to a ticket look like on microblogging systems? These seems like useful use-cases to dig into—they'll help clarify whether you should use a backwards incompatible extension or work to fit issues into the Actor model.

[jaywink]

but it's important to understand that it's currently outside of the scope of the ActivityPub spec and would need an extension

I'm finding it hard to believe that it was outscoped on purpose. It feels like the spec was mainly thinking of the "people will generally only follow actors" case but failed to consider other cases. It feels like the simplest solution to following an object shouldn't be taken just because this consideration wasn't done.

(not least of which to the vocabulary, as we already discussed on IRC, so you know which actor you're expecting the Accept from)

I'm not sure I understand. I think the chat discussion was related to an Issue which would not (under current plans by fr33domlover) be managed by the person who the issue is attributedTo. I don't personally believe there is a need for a managedBy attribute for Issues. This is offtopic really for this issue tracker and this issue here as it's purely a ForgeFed consideration. For a normal Note for example, you would know the actor from the attributedTo.

Also note that responding with Accept to a Follow is not mandated by ActivityPub, it's a SHOULD.

Obviously, non-actors do not having Follower collections and cannot fulfill this requirement.

The spec doesn't forbid a Note to have a follower collection either I believe? Also, adding the follower to the followers collection is a SHOULD, not a MUST.

More generally, many existing systems, such as mastodon & pleroma, are only set up for following Actors and you have to think about what compatibility with such systems means.

Not every platform can be compatible in every way because not all platforms support all features. Besides, would it be impossible for Mastodon to support subscribing to replies of a Note for example? This would improve the reliability of getting all replies on a thread for example to the level that it is outside of microblogging environments. But whether or not Mastodon would want to do that, I don't think the specifics of how ActivityPub can be used should be considered based on the features of particular platforms. Mastodon and Pleroma are both microblogging platforms which is only a subset of social networking. When we look at "macroblogging" (like Diaspora, Friendica, etc), collecting all replies under the main post becomes much more important, for example. This is why the Diaspora protocol has the Participation entity, which works wonderfully for this purpose. I would imagine a similar need is for a forge Issue, which is where this conversation started from.

[nightpool]

It feels like much of your argument is "this would be useful—we should have it". I agree. I just don't think a reasonable person, reading the ActivityPub spec, would come away with any expectation that anything except actors could Follow and be Followed. I don't think the spec's requirements or semantics around Following make sense for non-actors, and I think sitting down and thinking what a good set of semantics and requirements for following objects looks like is better then trying to shoe-horn in the ones for actors.

I also don't believe it was outscoped on purpose. Again, I think it's a useful and valid use case. I just don't think it's covered by the current spec, and we should write an extension to cover it

[trwnh]

I get the feeling ActivityPub was written with message-passing in mind, and there's nothing explicitly saying that objects can't pass messages between each other. But those objects don't have to correspond to users. So the "vanilla" option would be to just make those objects into actors, if you expect to have them be followed. However, you also have the option of establishing some service to announce only the relevant activities to you (like how Github sends you emails*), as long as you send the appropriate signal... but there just isn't anything already specified to indicate interest in an object, or in only a subset of activities**. Still, it should also be noted that the Activity Vocabulary describes the Follow activity as such:

Indicates that the actor is "following" the object. Following is defined in the sense typically used within Social systems in which the actor is interested in any activity performed by or on the object.

So what's really needed is a standardized mechanism to indicate to an actor that you're only interested in some activities, not all. Otherwise, you're stuck with pull-based polling to check when a Collection has been updated. Or you can follow the actor and get spammed with every single activity, discarding all of the ones you're not interested in.

*This is really analogous to subscribing to a mailing list, but doing so over email. Typically you get added to a mailing list out-of-band, but you could also theoretically reply with a keyword like "subscribe", as SMS mailing lists often do. In Github's case, the mailing list management happens through your account settings.

**(There's "streams", but that's very poorly defined.)

[jaywink]

@nightpool absolutely, I didn't mean this as a "fix immediately" issue. More of a thing to keep an eye on when the next draft is iterated upon some day.

On the Feneas forum, Hubzilla/Zot/Zap developer Mike Macgirvin indicated that Zap has support for this kind of thing and Friendica developer Michael Vogel indicated Friendica already does this with ActivityPub. Socialhome will also be supporting Follow  { Note } as an example.

[evanp]

So, an Actor is anything that can generate activities and that might be addressed in activities. As the spec says:

ActivityPub actors are generally one of the ActivityStreams Actor Types, but they don't have to be.

If you want to follow a Note, check if it has an inbox property. If so, send it a Follow. If you get back an Accept, it's followable.

If you want to make your Note objects followable, give them an inbox. If you get a Follow, Accept it. When things happen with the Note, have the Note object Announce them.

I'll add some more information on this to the ActivityPub primer. But it's really important that Person objects aren't the only actors in the fediverse! Big bummer if so!

[trwnh]

i think it should be done with inbox forwarding, not Announce?

On Thu, Jul 20, 2023 at 12:26 Evan Prodromou @.***> wrote:

So, an Actor is anything that can generate activities and that might be addressed in activities. As the spec says:

ActivityPub actors are generally one of the ActivityStreams Actor Types https://www.w3.org/TR/activitystreams-vocabulary/#actor-types, but they don't have to be.

If you want to follow a Note, check if it has an inbox property. If so, send it a Follow. If you get back an Accept, it's followable.

If you want to make your Note objects followable, give them an inbox. If you get a Follow, Accept it. When things happen with the Note, have the Note object Announce them.

I'll add some more information on this to the ActivityPub primer. But it's really important that Person objects aren't the only actors in the fediverse! Big bummer if so!

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/343#issuecomment-1644312091, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ5OXZHFSSDEFF7PE6KRSDXRFS5FANCNFSM4I2IXL4A . You are receiving this because you commented.Message ID: @.***>

[evanp]

@trwnh Inbox forwarding should be implemented with an Announce activity from the actor or server.

[trwnh]

that sounds very contentious -- Announce has an existing semantic meaning that is more akin to a post kind than a forwarding mechanism. it gets added to shares and would be rendered as its own activity in the stream.

as i understand it, the mechanism for inbox forwarding is to POST the same body exactly as you received it, to any inboxes discovered by dereferencing collections owned by you. the only complication is with verifying or authenticating such forwarded activities, which led to projects like Mastodon adopting LD Signatures, and FEPs like 8b32 "Object Integrity Proof" to be worked on.

[evanp]

So, we've come back to this topic after almost a year. Here are the options I see before us:

• Better documentation about following non-AS2-Actor-type ActivityPub actors. (The definitions here are different, so I'm calling them out in the discussion). I think this meets the needs of the question, although there's a lot of conceptual slippage in here.
• Other mechanisms besides ActivityPub actor structure for following an object of any kind. One that was mentioned is prospective-search-based Follow, so that I define some properties, and receive all new activities that meet those properties, modulo authorization. Another is a separate way of following non-AS2-Actor-type actors, if needed.

My sense is that we probably need to do at least the first, maybe the second. I'm going to self-assign this one, mark it as needs Primer page, and also needs FEP.