Re: Negotiating protocols between actors or clients

First off: love it. Can't get enough. Want to be at every meeting.

Secondly: This sounds like a good Template for a whole category/shape of
FEPs and CG Reports! S/C/A (Server/client/actor) Analysis could be the new
SWOT or ACID 😎

Thirdly: Maybe we do a separate Special Topic Call, followed by some kind
of informative or process doc? The precedent here might be the [Social Web
Protocols][^1] doc, in that it builds on the taxonomy such that _any_ of
the SW Protocols could use this SCA template...

Thanks,
__bf
[^1]: https://www.w3.org/TR/social-web-protocols/

On Sat, Nov 2, 2024 at 11:33 AM a <a@trwnh.com> wrote:

> Hello all,
>
> I know that the CG meeting next week is likely to have its time filled
> with discussions of potential charters, but I'd like to bring up a
> potential CG meeting agenda item:
>
> PROPOSAL: The SocialCG should convene a task force to document protocols
> built on top of ActivityPub, including how to negotiate protocols
> client-to-client or actor-to-actor.
>
> The roles and responsibilities of this task force would include, to start
> with:
>
> 1. Defining a mechanism to signal which protocols are supported, or in
> other words, which total set of behaviors will be carried out when an
> activity is received at an outbox or delivered to an inbox. Behaviors can
> be broken down into the following categories:
>
> 1.1. Server behaviors. Which actions can be carried out automatically by a
> server? How can an actor detect that a server will understand and carry out
> side effects? Example: When an `Announce` is received in an inbox, a server
> might automatically add it to the `shares` collection... or it might not.
>
> 1.2. Client behaviors. Which actions are intended for clients to
> understand and do something with them? How can an actor negotiate a session
> between two clients? Example: Alice is using an E2EE messenger (or chess
> application), and wants to establish an E2EE conversation (or chess game)
> specifically with a client attached to Bob's actor or profile.
>
> 1.3. Actor behaviors. Which actions can the actor take or respond with, in
> response to a given activity? How can an actor be expected to act? Example:
> When Alice receives an activity referencing an object that has set
> `inReplyTo` or `context` or etc. referencing an object belonging to Alice,
> then Alice might want to Add that object to an appropriate collection. This
> behavior might also occur at the client level, if the client is configured
> to automatically manage those collections. This behavior might also occur
> at the server level, if the server is configured to automatically manage
> those collections.
>
> 2. Documenting one or more common profiles for a total set of behaviors as
> described above.
>
> 2.1. Option: A protocol for the management and replication of resources
> across servers. Define behaviors for Create/Update/Delete/Add/Remove at the
> server level, client level, and actor level. Define where and how resources
> are stored, how long resources are stored or cached, etc.
>
> 2.2 Option: A protocol for publishing "posts" to a "profile". Define what
> is a "post", what is a "profile", etc. (Some overlap with the Forum TF
> here, especially once you get to the level of defining "conversation" and
> "forum".)
>
> 2.3. Option: A protocol for publishing "activities" to an "activity
> stream". Define generic processing and shape that an activity must fit.
> Define how to identify these activities as simple notifications, in cases
> where side effects might not be needed or desired.
>
> 3. Generating one or more reports for the above items.
>
> I would love to know what other people think about this agenda item or
> general issue, and I welcome discussion of this issue both on the mailing
> list and in other venues.
>