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

[silverpill@mitra.social]

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

[mariusor@metalhead.club]

@silverpill lol, based on the "claims" at the begining, why do I feel like the "thanks" at the end should be in quotations?

Also I take umbrage with calling what I've been doing for the past 8 years as "being not difficult to build nor an interesting concept". I feel like you, and other developers having the benefit of dynamically typed programming languages, underestimate how that can be worked into robust APIs when you're limited by less versatile stacks.

[julian@activitypub.space]

@silverpill@mitra.social I find it curious that this needs to be spelled out in an FEP.

Isn't a generic AP server one that ingests anything and shoves it into the outbox... like a mail transfer agent?

... then delivers it dutifully?

I mean, sure, you can do stuff in between, like spam detection, blocklists, etc etc etc...

My quick read through of the FEP (and it was quick, because it was a short FEP :stuck_out_tongue:) seems to confirm this.

[silverpill@mitra.social]

@julian It looks simple on the surface, but in reality it is much more complicated than a non-generic server. In addition to activity transfer, generic server needs to maintain collections. First of all, a followers collection, which is often used as a delivery target. Then likes, shares etc. It needs to enforce permissions, to prevent actors on the same server from deleting each other posts.

This is doable if you only care about activities defined in ActivityPub. But then you want to introduce context collection. And then 50 other extensions. How to do that without special-casing every one of them?

This is where duck typing (FEP-2277) and unified security model (FEP-fe34) become really handy. No matter what the client sends, you can figure out what it is (an object, an actor, or a collection), and enforce permissions.

[mariusor@metalhead.club]

> The thanks was for your input with regards to collection management.

@silverpill of course, sorry for the misunderstanding. Doubly so, for forgetting Mitra is Rust, I remembered it to be Python. :D

And yes, the difficulty is indeed in massaging JSON-LD documents into strongly typed data that are meaningful for library consumers. However I've not despaired yet... there's light at the end of that boring tunnel. :P

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

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

[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

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

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

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

[trwnh@mastodon.social]

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

[trwnh@mastodon.social]

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

[trwnh@mastodon.social]

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

[trwnh@mastodon.social]

@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

[steve@social.technoetic.com]

@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@social.technoetic.com]

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

[trwnh@mastodon.social]

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