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

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

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.

@silverpill

@mariusor

Also, reading FEP-aea97 and I don't see anything there that my modest little server made with a "dynamic language" doesn't do already.

And It's not even like what I am doing is novel or incredibly diffiicult. If you spent a little time embracing RDF and JSON-LD, you could take a look at what Vocata did and you'd see how easy it can be implement the AP API.

@silverpill @mariusor

> And yes, the difficulty is indeed in massaging JSON-LD documents into strongly typed data that are meaningful for library consumers.

Maybe this could help: https://activitypub.mushroomlabs.com/topics/reference_context_architecture/

@silverpill @mariusor

> The behavior of Offer activity is not described in ActivityPub

You can still take the document and place in the target inboxes, leaving to the *client* to figure out what to do with it.

You don't need to describe the specific case if the general case (activities must be placed in the target inbox) is enough.

Is this your objection when you are talking about "Generic Servers"? Because if that is the case then I can definitely argue that my server is it.

@raphael

what Vocata did

This project is often brought up as an example of a generic server, but it never reached production stage. The last commit was in 2023.

It is one thing to have an idea and build a prototype, and a completely different thing to build an application that is secure and interoperates with the rest of the network.

@mariusor

@raphael Placing activities in the target inbox is not always enough, sometimes there are side effects.

In my FEP I discuss how we can deal with that.

There is more to it, see my response to @julian:

https://mitra.social/objects/019ca012-a698-5c2a-a6fa-a547373294cc

@mariusor

@silverpill

That's what I saying, though: I took the *ideas* from Vocata and implemented in a way that can work in production.

@mariusor

@silverpill

> generic server needs to maintain collections.

If you are talking about "any arbitrary collection beyond followers/following/inbox/outbox/shares/likes". I'll disagree with you.

@julian @mariusor

@silverpill

> But then you want to introduce context collection. And then 50 other extensions. How to do that without special-casing every one of them?

You don't! An extension is an extension. A Generic server only needs to support the base protocol. Extensions are optional, not a requirement.

@julian @mariusor

> @silverpill@mitra.social said:
>
> I think FEP-1b12 Announce is not compatible with ActivityPub.

Shots fired <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f525.png?v=1966e26b58b" title="" />

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

@raphael @julian @mariusor

Another example of the need for careful terminology use is in the post that @silverpill quoted above:

> prevent actors on the same server from deleting each other posts

"post"? There is no post in #ActivityPub, not as a verb and neither as a noun. While I am not worried that silverpill used the word in a wrong meaning here, the terminology easily leads to confusion where someone who interprets AS/AP to be equivalent to the fediverse we have today, pictures in their mind as Mastodon posts or toots in fedi slang, or elsewhere called statuses.

That is app terminology. AP only knows Actor, Activities, Objects, and perhaps Collections. Period. The rest is solution design.

Where they are transferred they can be said to be messages, and messaging happens.

@silverpill @raphael @julian @mariusor

Yes, I see you working hard in that quest.

But in the chaotic fediverse that evolved by post-facto interoperability that is a wicked challenge. Post-facto interop means "if I am first I can become law, and drag fediverse sideways in my image".

In another branch of this thread, there's another confusing thing. "how can a mastodon client ask the server .." and you respond with a possible URL pattern that may be defined.

> Maybe something like `/api/v1/timelines/tag/{tag}?only_media=true` ?

Perhaps Mastodon's non-generic server may have that, but not a generic server, but it is unclear which one is referred to.

Since microblogging nowhere aggregates comprehensive overview it is an echo chamber for confusion.

@silverpill @raphael @julian @mariusor

I sometimes picture fediverse as one of these old horseracing toys from the 50s, where the horses represent all the various perspectives and expectations people have of the fediverse. There is no horse to bet on, positions change all the time, horses change tracks randomly. And furthermore there no finish line, the race is an endless slog. The prize of a robust #ActivityPub protocol forever out of reach, getting more elusive as time progresses.

@silverpill @raphael @julian @mariusor

In my book if a side effect is part of the protocol specification, then it constitutes a protocol capability. If not, then it is part of some app's / solution's business logic.

The definition of "ActivityPub extension" by itself is unclear. With overloaded use causing confusion. It may refer to:

- Protocol extension
- App / solution built on top of the protocol

To deal with protocol capabilities they must have water-tight specs, well-defined behavior and strict consistent use across the fediverse.

To deal with side effects that are part of solution designs for a particular application or business domain things go from simple to very complex in the amount of introspection and machine-readability that the #ActivityPub Actor abstraction offers.

Simplest is finding the URL where the docs of the extension / solution design sit. Most complex is full introspection and handshaking. The latter is the Solid route.

https://social.coop/@smallcircles/116113963712755122

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

@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

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

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