Recently, there was a discussion about generic #ActivityPub servers.

[silverpill@mitra.social]

@raphael Nevermind, side effects wouldn't be a problem. However, it still doesn't seem to be compatible with ActivityPub... Because Announce activity is not defined in C2S context

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

(www.w3.org)

@julian @mariusor

[smallcircles@social.coop]

@silverpill @raphael @julian @mariusor

In my book if a side effect is part of the protocol specification, then it constitutes a protocol capability. If not, then it is part of some app's / solution's business logic.

The definition of "ActivityPub extension" by itself is unclear. With overloaded use causing confusion. It may refer to:

- Protocol extension
- App / solution built on top of the protocol

To deal with protocol capabilities they must have water-tight specs, well-defined behavior and strict consistent use across the fediverse.

To deal with side effects that are part of solution designs for a particular application or business domain things go from simple to very complex in the amount of introspection and machine-readability that the #ActivityPub Actor abstraction offers.

Simplest is finding the URL where the docs of the extension / solution design sit. Most complex is full introspection and handshaking. The latter is the Solid route.

🫧 socialcoding.. (@smallcircles@social.coop)

Attached: 1 image I recreated an old diagram in Excalidraw that I spread about a couple years ago, and made it a bit more informative. Explanation can be found in the #AltText See also and for discussion: https://discuss.coding.social/t/diagram-interoperability-in-practice/828 Or join the Social experience design chatroom at: https://matrix.to/#/#socialcoding-foundations:matrix.org Also posted to #SocialHub at: https://socialhub.activitypub.rocks/t/activitypub-versus-fediverse-interoperability-in-practice/8498 @ben@werd.social #SX #SocialCoding #SocialWeb #ActivityPub #SolidProject #fediverse

social.coop (social.coop)

[benpate@mastodon.social]

@silverpill @mariusor @trwnh

I e*love* this idea- especially in principle. I say that because I’m having a hard time wrapping my head around this and how it would be used in practice.

Do you think you could post an example workflow (or three) to demonstrate how this would work?

I get that objects could be added to client-defined collections (very cool) but if object/collection IDs don’t have predefined semantics, how will I know where to look to get the data I need?

[trwnh@mastodon.social]

@silverpill @raphael @mariusor

> neither is it an interesting concept

> interoperates with the rest of the network

look, we clearly have different goals here. your goal is to interoperate with the mastodon network. my goal is to publish activities to my website. mastodon doesn't even support all the activities defined in AS2-Vocab. a generic server supports *any* activity, even those not defined by AS2. the network i want to interoperate with isn't mastodon, it's the web.

[trwnh@mastodon.social]

@benpate @silverpill @mariusor none of the IDs should have any semantics; from the outside, there is no distinction between a client managed or server managed collection. likes/shares/etc could be managed by a "client" like mastodon, or even a "default" one. it's not any more complex unless you want to vary the collection responses based on the request headers. for that you need a minimal dynamic layer with an access control policy of some sort. (WAC is the simplest, but ACP is more powerful)

[trwnh@mastodon.social]

@benpate @silverpill in a client managed followers collection i would Add you to my followers just like fedi instances currently do silently. "but how can you prove--" yes exactly, how can current fedi prove anyone is a follower either? you need the Follow+Accept pair to both be live without an Undo on either, right? and that's what leads to the "follow state machine" on fedi that drifts out of sync and leads to private posts being leaked to removed followers (which you can't officially do!)

[silverpill@mitra.social]

@benpate Let's assume that my client is a music player. It publishes a Listen activity where object is an Audio. This activity should increase playCount on the Audio object.

One way to support this on the server side is to teach it about Listen, Audio and how to update playCount. This is how most existing servers are built.

But a server described in my FEP would work differently:

- It doesn't know anything about Listen, Audio or playCount.
- Upon receiving Listen, it will recognize it as an activity, and embedded Audio as an object.
- Since this is not a CRUD operation, it will not check permissions.
- If Listen activity has a result property, the server will process that activity as well.
- If result is an Update activity, the server will recognize it as a CRUD operation and will check permissions: Update.actor and Audio.attributedTo must be the same.
- The server will save both activities, Listen and Update.
- Then it will deliver them to intended recipients (to and cc).

Effects are client's responsibility now, it must provide an Update activity if it wants to update playCount. There are other requirements too, for example all objects should have an attributedTo property, which is needed for permission checks.

But in this setup a single server can work with any kind of client.

@mariusor @trwnh

[silverpill@mitra.social]

@trwnh @raphael @mariusor No, my goal is to interoperate with many Fediverse servers, not just Mastodon. I agree that a generic server is supposed to support any activity, this is exactly what I was arguing about for the last two days, and this is what my FEP is about.

[raphael@mastodon.communick.com]

@silverpill

The crux of the issue is that we shouldn't need to talk about "your FEP" when we are talking about "servers focused on implementing the ActivityPub API". The spec as is *is enough*. You are moving the goal posts by pushing a definition of "generic server" when it doesn't need to,and you are creating a "No True Scottsman" by saying that implementation X, Y or Z is "incompatible" with ActivityPub API.

@trwnh @mariusor

[trwnh@mastodon.social]

@raphael @silverpill well, it's missing a way to remove a follower, but otherwise the "POST to outbox" bits are mostly clear. except how the outbox delivery algorithm handles collections, which when they have inboxes, doesn't allow delivering only to that inbox instead of recursing over all items' inboxes.

otherwise i think "side effects" are a red herring. using as:result can be helpful but the "side effects" should happen in an attached client and should be called "automation".

[benpate@mastodon.social]

Yes, I think I like the idea of clients being able to store data on the server however they like. It reminds me of this description of ATProto that I found recently: https://overreacted.io/a-social-filesystem/

I guess my question is: once I store my custom stuff in custom places on my server, how do I publish this so other people can find?

And, object IDs are usually defined by the server. So how would it work to say "create a collection named XYZ and add this object to it"?

@silverpill @mariusor @trwnh

[trwnh@mastodon.social]

@benpate @silverpill

> object ids are usually defined by the server

the server would need to know your namespace/prefix, then mint ids in that namespace. if that is a dns name, then you get dns portability. if it's an https uri, then you ideally need to support relative references and redirects.

"create a collection" can happen over any CRUD method supported. if you use AP as an API then this would be a Create(object.type=Collection) then you get HTTP 201 Created with a Location header.

[steve@social.technoetic.com]

@silverpill @mariusor @trwnh In principle, I like the general idea, but I think it's misleading to call this an "ActivityPub" server FEP since it doesn't conform to the ActivityPub specifications. You also recommend (require?) using the `result` property to describe server side-effects, but you don't describe *how*. I don't know how you expect to "force clients to specify them".

[silverpill@mitra.social]

@steve @mariusor @trwnh

This FEP introduces new requirements to ActivityPub, and I will probably add more in the future. Does that make it non conformant?

In any case, I think calling it an ActivityPub server is appropriate.

Side-effects are activities, I will clarify that in the FEP. The value of result property can be an embedded activity, or an array of activities.

Clients either specify them, or they don't get any side effects.

[silverpill@mitra.social]

@benpate Publishing process doesn't change much. A generic server should deliver activities to actors specified in to and cc fields. It should keep track of collections, such as followers collection, and "expand" them before delivery. This part is not different from the regular ActivityPub.

I think ID assignment should also work the same. In the FEP I proposed Add activity without object as a special activity for creating collections, but now I see that it will not work if IDs are minted by a server (no FEP-ae97).

Perhaps it should be a Create, after all, as @trwnh described in an adjacent comment. I was hesitant to use Create because this is a problem for FEP-ae97 clients (not a big one though).

@mariusor @trwnh