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

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

[steve@social.technoetic.com]

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

Not at all. I was referring to the `Add` without an `object` to create a collection (instead of Create/Collection, I assume).

[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

[silverpill@mitra.social]

@steve @mariusor @trwnh Yes, this is wrong and I am going to replace Add with Create. I forgot that non-FEP-ae97 clients can't mint identifiers.

[fox@social.hostnetwork.xyz]

@smallcircles @silverpill @raphael @julian @mariusor ActivityPub as a space is just a mess, we have multiple types of social media clashing all over one protocoll whcih has a bunch of extensions with some being duplicates of other extensions and then diffrent people fighting over which one is the proper one to implement. At somepoint we just need to reset everything and start from a clean plate cause this shit cant go on forever.