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

@raphael @silverpill @julian @mariusor

I agree. Aboveall we need to know where protocol ends and 'app' begins. And be generally more deliberate in terminology use, and no longer talk in overloaded that has different unclear meanings to different people in different settings (to avoid saying 'contexts' one of such overloaded words

I've noticed for instance people having a very different notion of what a 'generic server' is, in definitions that are almost diametrical opposites.

My definition of generic is 'not specific' i.e. a generic server is a pure #ActivityPub protocol implementation (which is something to agree upon, what that exactly entails), having no knowledge of *any* app / solution built on top of it or 'passing through' its messaging architecture.

In the other meaning a generic server 'knows/does/has it all' i.e. it understands everything we comprise to be 'the fediverse' in a kind of hard-wired fashion based on the functionalities that (marginally) interoperate today.

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

@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 @steve this actually raises an interesting question about "side effects" and where they live. in the AP spec it's rather muddled and i've talked before about the issue of "activities as content/notifications vs activities as procedure calls". i personally err toward having no side effects, which i think were kind of a mistake for the reason you bring up (generic servers can never be aware of extended side effects).

@silverpill @steve typically i've taken a view similar to IFTTT -- the activities describe things that happen, probably already happened. one or more listeners can do whatever they want with that information. CRUD is boring to me and i would rather do that with HTTP (POST/GET/PUT/DELETE); the more interesting activities are things like Listen (scrobbles) or Arrive (checkins) or Question (stackoverflow) or so on.

@silverpill @steve it sounds like you're describing an "AP server" whose primary functionality is not "publish activities" but rather "manage CRUD for objects and Add/Remove for collections", by taking the AP "side effects" for Create/Update/Delete/Add/Remove and and saying the outbox should also check as:result.

which is cool but should probably be disambiguated.

@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest

@smallcircles You might find the idea of ''universal'' abstractions interesting in this context: https://www.humprog.org/~stephen/blog/research/recovering-abstraction.html

Similarly, the idea of "narrow waist" might also be relevant here: https://www.oilshell.org/blog/2022/03/backlog-arch.html#what-is-a-narrow-waist

@raphael @silverpill @julian @mariusor

@smlckz @raphael @silverpill @julian @mariusor

Thank you! Very nice blogs. I've been thinking about this, but in a different way, and this gives some proper food for thought. Particularly the concept of a "narrow waist".

The interface with the AS/AP fediverse should be as easy as possible to wrap ones head around when designing a new solution to be part of the social web.

The above separation is between a (closed world) msg bus of sorts for actor communication and (open world) LD knowledge graph. The abstractions offer a 1st separation of concerns. Messaging architectures have a huge body of work and best-practices that come within direct application reach.

Btw. wrt "Unix philosophy" should check out https://CUPID.dev by @tastapod that offers an alternative looser approach to formal SOLID principles.

For anyone unfamiliar with Rich Hickey, he has some brilliant vids on simplicity in design, simple vs. easy. For instance 'Hammock Driven Development':

https://www.youtube.com/watch?v=f84n5oFoZBc

@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest

@trwnh @silverpill Another interesting "side effect" twist... some of the standard side effects are conditional (like only adding an actor to a following collection after an Accept is received). I think the FEP should also cover what happens with Undo of an activity with explicit side effects. Some secondary/side activities might have clear inverses and others not (some kinds of Update?).

@steve @silverpill i assume the Undo would have a result that describes that? so Undo(Follow) might have a result of Remove from Follow.actor.following+Follow.object.followers in theory. for the other way around the Follow doesn't have a result but the Accept(Follow) has a result of Add to Follow.object.followers+Follow.actor.following

but i think Follow is a bad example because it really should be subscription record management instead, ideally.

@steve @silverpill i assume the Undo would have a result that describes that? so Undo(Follow) might have a result of Remove from Follow.actor.following+Follow.object.followers in theory. for the other way around the Follow doesn't have a result but the Accept(Follow) has a result of Add to Follow.object.followers+Follow.actor.following

but i think Follow is a bad example because it really should be subscription record management instead, ideally.

@steve @silverpill the other question is if this level of explicitness is useful. the answer AP spec gives is "no, just assume every server SHOULD do this".

and a tangent for follows: they are too stateful. you send Follow and Accept and someone knowing about those two might assume you are a follower now but not be aware of later removal or undoing (of either the Follow or Accept). this is broken in practice for years because Follow/Accept follow is not expressive enough

@trwnh @silverpill Yeah, it's not the only bad example of side effects specified in AP. Most of the side effects are optional (SHOULD) and outbox delivery (federated or local) isn't described as a side effect. I think that's one of most significant side effects of posting an activity to the outbox.

@steve @silverpill in theory POST to outbox should publish the activity, and should trigger the delivery algorithm based on audience (which is another thing handled poorly compared to even smtp which it tried to copy...)

imo that should be part of the protocol contract, and the idea of "side effects" unfortunately muddles that. the guarantee should be built into the outbox delivery algorithm and an outbox should signal this algorithm is in effect.

@trwnh @silverpill I agree about the name and the extraneous external FEP references. Even if focused on side-effects, a properly specified FEP on this topic would be a challenge.

@steve @trwnh

I am not sure if generic server is even possible without FEP-2277 and FEP-fe34. Maybe duck typing (FEP-2277) could be replaced with hierarchical types, but that would require JSON-LD processing, and I don't want to make it mandatory.

If you're certain that a different flavor of generic server is possible, I can publish the side effects part as a separate FEP. This way we can focus on areas where we are in agreement.