Re: Negotiating protocols between actors or clients

>  So, to me, what you're describing are *server side effects*. Maintaining
a thread is a great example. [...]  clients can use fallback behaviours if
the server doesn't maintain the state. In this particular example, by
updating the `thread` collection directly with `Add` and `Remove`
activities.

The side effects don't have to be handled by the server, though! For a
generic ActivityPub server, you generally cannot expect any additional side
effects beyond what is described in ActivityPub. (It's all SHOULD stuff,
but at maximum you might expect a server to handle
Follow/followers/following and maybe Like/likes and Announce/shares for
you.) For anything not handled by the server, it is up to the client to
handle side effects; either the client is programmed to automatically use
the API to issue certain activities, or the user can choose to issue
activities manually. (That's a matter of automation, really.)

>  I don't think it's necessary to specify that a server supports the base
AP side effects (follows, likes, replies, etc.) but it would be nice to
indicate it for other side effects.

The problem is that the "base AP side effects" are all SHOULD, not MUST. In
the case that a server implementation chooses to neglect the SHOULD
recommendations regarding followers/following/liked/likes/shares, the
client is potentially capable of issuing Add/Remove activities, but it
needs to know that it can/should do this -- there is no way of
knowing/guaranteeing what a generic server will or will not do for the
actor automatically, so there is no way of knowing whether the client needs
to handle these responsibilities.

We have a Primer page at
https://www.w3.org/wiki/ActivityPub/Primer/Server-Managed_Collections which
nominally covers this component, but even if the generic ActivityPub server
manages all of followers/following/liked/likes/shares for the actor, this
still completely leaves out other collections like
replies/context.*/thread/members/attendees/etc. -- these kinds of
collections are typically managed by monolithic client+server
implementations, if at all. The federation protocol doesn't say anything
about these. (The Primer page erroneously claims that the replies
collection is managed by the server, but the ActivityPub spec says nothing
about the replies collection.)

Things get more complicated when you consider situations where more than
one client is reading simultaneously from the same inbox. Which client is
responsible for managing which collection? If you don't have an answer to
this, you might just find that for n clients, n Add activities are issued
whenever some specific criteria is met. If a Remove is issued in between,
you can no longer guarantee whether the object is in the collection or not.
All consistency and predictability flies out the window. (If you really
think about it, "server side effects" can be conceptually thought of in
terms of an "internal client" which handles side effects within the
outbox/inbox POST handler, without needing to use the API.)

>  I think the best way to implement this signal is by adding a property to
the actor object.

It would probably make the most sense on the inbox, but it could also make
sense on the actor. Either way, "where it goes" is less of a concern than
"what does it look like" and "what does it do". It also depends on whether
an activity is intended for a client or for an actor. (The client may
itself be an Application actor!)