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

I sometimes picture fediverse as one of these old horseracing toys from the 50s, where the horses represent all the various perspectives and expectations people have of the fediverse. There is no horse to bet on, positions change all the time, horses change tracks randomly. And furthermore there no finish line, the race is an endless slog. The prize of a robust #ActivityPub protocol forever out of reach, getting more elusive as time progresses.

[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)

[silverpill@mitra.social]

@smallcircles @raphael @julian @mariusor I was comparing Mastodon and a spec-compliant ActivityPub server, from a user perspective. My claim is that even the most advanced implementations of ActivityPub API are on the same level as Mastodon API.

If you want to go beyond Mastodon API capabilities, you need a truly generic server. Something akin to Nostr relay.

[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?

[smallcircles@social.coop]

@silverpill @raphael @julian @mariusor

Yes, I agree. Though I would rather see a generic server having much less functionality than a Mastodon API exposes, since much of that is app-specific, Microblogging domain already. The generic server should make Mastodon possible as a solution design modeled on top of its #ActivityPub networking layer.

In such a way where we can finally consider the protocol layer to be robust, and are able to treat it as a black box, and are not confronted with all its implementation details when we are doing a solution design.

I think we are probably on the same page, but..

> If you want to go beyond Mastodon API capabilities, you need a truly generic server. Something akin to Nostr relay.

This I would reformulate as:

"If you want to go beyond an app-centric fediverse bound to a Microblogging domain, then you need a generic server conformant to the ActivityPub specification."

Which also indicates I think we need to aggregate puzzle pieces into an AP 2.0

[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.

[smallcircles@social.coop]

@silverpill @raphael @julian @mariusor

Btw, damn we should've caused this entire discussion thread to somehow flow to #SocialHub to have it in the archives. Instead of on "now you see me, now you don't" channel. Peekaboo. 🫣

https://social.coop/@smallcircles/116141469199837056

Here today, gone tomorrow, who made notes? The post-facto interoperability leaders did. Those who happened to be around at the right time to hear things being said on the grapevine.

We need a proper Grassroots standardization process, and a Grassroots open standard that is able to healthily evolve. The good organization of this is just as important as the technical robustness of the protocol, which is the solution artifact at the end of the open standards cocreation pipeline.

[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

[smallcircles@social.coop]

@silverpill @raphael @julian @mariusor

The killer app for the fediverse is not nomadic identity. That is either a protocol capability or may refer to an Identity Management app, a solution design.

Problem is, it is no use discussing here. No convergence takes place, other than spontaneous / random convergence. But it does not lead anywhere, not to a common consensus. Not to robust foundations to build on without continuous worries that things break. Microblog communications does not support this, and lacking that support manual processes are needed.

Even the #ActivityPub #FEP only offers convergence to certain extent. The process is a band-aid, a best-we-have.

In analogy of the horserace, spontaneous convergence and ad-hoc alignment on FEP puzzle pieces by implementers equates to the horseback riders figuring out some basic rules to avoid serious accidents. But this FEP adoption at the same time warps the track, hems them in, alters reality and the future.

https://social.coop/@smallcircles/116144523324279704

[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]

@raphael @trwnh @mariusor I am not moving any goalposts, this is how I always imagined a generic server.
Also I didn't say that X Y and Z are incompatible with ActivityPub API. They might be compatible, but that doesn't make them generic.

[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.