@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

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

@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

@smlckz @raphael @silverpill @julian @mariusor @tastapod

Good opportunity to rewatch that #RichHickey vid

Immediately from the slide at the start:

> Avoiding misconception is the first and cheapest place to tackle [undesirable outcomes].

I'd argue that #Misconception is the biggest problem we have atm to lift the #ActivityPub fediverse to higher levels. We know this for years, but in a chaotic grassroots environment there was no one to solve it, and any attempt was trying to herd cats.

Also I should add that in your blog posts I really liked the references to #Evolution, which is also the basis and key focus of Social experience design. #SX methodology is a combination of emergent design and evolutionary practices (through 'self-servicing', holistic approach, and feedback loops).

https://coding.social/blog/reimagine-social

#SX #SocialCoding

@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 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 it's why mastodon went with the concept of "stamps" as http resources that could be fetched to retrieve latest state (200 / 404). you no longer need a complete ordered history of activities and you don't need to calculate the current state from those activities.

subscription records would work the same way and could be extended to allow subscribing only to certain activities instead of an unfiltered everything

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

@steve @silverpill now if only AP had officially defined conformance profiles to this effect... (the "activity publishing profile" and the "notification delivery profile", to be clear)

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

@silverpill @steve the type information is largely unnecessary and shouldn't factor into handling CRUD, especially if the objects are managed by the client. the authorization/trust model for which activities are allowed to CRUD which objects is important but can be something other than fe34 (such as an explicit access control policy or authorization resource). also multiple CRUD mechanisms may be in use.

@silverpill @steve regarding as:result itself there are some other ideas that have come up in past years so good to discuss those in a more focused thread:

- either marking activities as the "result of" (maybe "in response to"?) another activity could update the other activity to refer to the later activities, or the "result of" property is defined as a @\reverse property of as:result
- quote stamps currently use result for the stamp itself, not a Create activity for it

@silverpill @steve also the server's main responsibility being publishing and therefore needing to mint an identifier for the top level activity, we should ask if the server is expected to assign any inner ids as well? assigning ids changes the graph so it's not clear cut. <how does the server know *which* ids to assign and which ones not to?> is an open question (and maybe blank node identifiers are actually in practice required to avoid ambiguity?)

@silverpill @steve so we might need to recommend that these "side effect" activities in as:result SHOULD have fragment identifiers, to be able to refer to them later? or do we intend to never refer to them later? we could say they're transient activities so don't need to be referred to later (only processed in-order).

lastly as:result itself maybe doesn't have these semantics defined, so should a subproperty or different property be used, or do we skip non-CRUD results?