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

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

[smallcircles@social.coop]

@fox @silverpill @raphael @julian @mariusor

Yes. I tooted about the need for Grassroots open standards and Grassroots standardization this morning..

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

@hongminhee@hollo.social @kopper@not-brain.d.on-t.work SX defines the concept of a Grassroots open standard, and a domain of Grassroots standardization. These are direly needed to be able to healthily evolve #ActivityPub to where it can be the future of social networking, and support a peopleverse.

social.coop (social.coop)

In a decentralized grassroots movement, somewhere there needs to an aggregation of the solution artifact. In this case a robust, comprehensible #ActivityPub standard that can be readily implemented in libraries, frameworks and SDK's upon which then subsequently #SocialNetworking solution design can take place.

This is not centralization, this artifact can be federated. But there must be a place of convergence where consensus on protocol design comes together.

There might be a crowdsourced ActivityPub 2.0 specs + documentation site, plus a process around it to make it work.

#SX #SocialCoding

[jwildeboer@social.wildeboer.net]

@smallcircles So we are at XKCD:927 again? Le Sigh. https://xkcd.com/927/ @fox @silverpill@mitra.social @raphael @julian @mariusor

[smallcircles@social.coop]

@jwildeboer @fox @raphael @julian @mariusor

No, not necessarily. The idea of the Grassroots open standard is that it allows an ecosystem that can evolve. That AP 2.0 artifact can be informal, and gradually adopted in W3C tracks, which I have always been advocating for with the 3-stage bottom-up standardization process in the past.

Other than that I am musing about a different approach, which is Protosocial, an AP extension that is 1.0 compliant. Yet not compliant to the protocol decay and tech debt ridden fediverse that grew by post-facto interop over time.

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

#ThoughtProvoker :blobhyperthink: The current fediverse is an evolutionary dead-end for 2 reasons: 1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay. 2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out. Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with. To avoid fedi to become less and less attractive to newcomers, we must now consider: “Why do we want to grow the open social web, and for whom?” -- @ben@werd.social http://coding.social/blog/shared-ownership/

social.coop (social.coop)

[fox@social.hostnetwork.xyz]

@jwildeboer @smallcircles @raphael @julian @mariusor next time just post the image bruh