Recently, there was a discussion about generic #ActivityPub servers.
-
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.
@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.
-
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.
@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
) seems to confirm this. -
@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.
@mariusor Mastodon supports all standard activities and has a wide variety of clients. I don't find softwares with similar capabilities impressive, although I respect your work (the only ActivityPub server-client project that is not a vaporware).
I doubt that language choice makes much difference, and Rust is not a dynamically typed language anyway. The difficulty you might be facing is likely due to JSON-LD.
The thanks was for your input with regards to collection management.
-
@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
followerscollection, which is often used as a delivery target. Thenlikes,sharesetc. 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
contextcollection. 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 Mastodon supports all standard activities and has a wide variety of clients. I don't find softwares with similar capabilities impressive, although I respect your work (the only ActivityPub server-client project that is not a vaporware).
I doubt that language choice makes much difference, and Rust is not a dynamically typed language anyway. The difficulty you might be facing is likely due to JSON-LD.
The thanks was for your input with regards to collection management.
> 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.
-
@mariusor Mastodon supports all standard activities and has a wide variety of clients. I don't find softwares with similar capabilities impressive, although I respect your work (the only ActivityPub server-client project that is not a vaporware).
I doubt that language choice makes much difference, and Rust is not a dynamically typed language anyway. The difficulty you might be facing is likely due to JSON-LD.
The thanks was for your input with regards to collection management.
> Mastodon supports all standard activities and has a wide variety of clients.
What happens when you send a "Offer" message to an actor on Mastodon? Can they accept it?
Can I create a group actor on Mastodon? Can I use this actor to boost other actor's posts and have it visible on a Lemmy client?
How can a Mastodon client ask the server to get a collection of all images with an specific tag?
-
> Mastodon supports all standard activities and has a wide variety of clients.
What happens when you send a "Offer" message to an actor on Mastodon? Can they accept it?
Can I create a group actor on Mastodon? Can I use this actor to boost other actor's posts and have it visible on a Lemmy client?
How can a Mastodon client ask the server to get a collection of all images with an specific tag?
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.
-
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.
> 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/
-
> Mastodon supports all standard activities and has a wide variety of clients.
What happens when you send a "Offer" message to an actor on Mastodon? Can they accept it?
Can I create a group actor on Mastodon? Can I use this actor to boost other actor's posts and have it visible on a Lemmy client?
How can a Mastodon client ask the server to get a collection of all images with an specific tag?
What happens when you send a "Offer" message to an actor on Mastodon?
The behavior of
Offeractivity is not described in ActivityPub, so Mastodon is not required to support it. Curiously, ActivityPub mentionsOfferwhen it talks about the side effects ofAccept:The side effect of receiving this in an inbox is determined by the type of the object received, and it is possible to accept types not described in this document (for example, an Offer).
...This statement is not compatible with the idea of a generic server.
Can I create a group actor on Mastodon?
I don't know. But it can create
Serviceactors, I guess it can be easily patched to allow creation ofGroupactors too.Can I use this actor to boost other actor's posts and have it visible on a Lemmy client?
I think FEP-1b12
Announceis not compatible with ActivityPub. It has different side effects, doesn't updatesharescollection.How can a Mastodon client ask the server to get a collection of all images with an specific tag?
Maybe something like
/api/v1/timelines/tag/{tag}?only_media=true? -
What happens when you send a "Offer" message to an actor on Mastodon?
The behavior of
Offeractivity is not described in ActivityPub, so Mastodon is not required to support it. Curiously, ActivityPub mentionsOfferwhen it talks about the side effects ofAccept:The side effect of receiving this in an inbox is determined by the type of the object received, and it is possible to accept types not described in this document (for example, an Offer).
...This statement is not compatible with the idea of a generic server.
Can I create a group actor on Mastodon?
I don't know. But it can create
Serviceactors, I guess it can be easily patched to allow creation ofGroupactors too.Can I use this actor to boost other actor's posts and have it visible on a Lemmy client?
I think FEP-1b12
Announceis not compatible with ActivityPub. It has different side effects, doesn't updatesharescollection.How can a Mastodon client ask the server to get a collection of all images with an specific tag?
Maybe something like
/api/v1/timelines/tag/{tag}?only_media=true?> 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.
-
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.
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.
-
> 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.
-
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.
That's what I saying, though: I took the *ideas* from Vocata and implemented in a way that can work in production.
-
> 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.
-
> 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.
> 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.
-
What happens when you send a "Offer" message to an actor on Mastodon?
The behavior of
Offeractivity is not described in ActivityPub, so Mastodon is not required to support it. Curiously, ActivityPub mentionsOfferwhen it talks about the side effects ofAccept:The side effect of receiving this in an inbox is determined by the type of the object received, and it is possible to accept types not described in this document (for example, an Offer).
...This statement is not compatible with the idea of a generic server.
Can I create a group actor on Mastodon?
I don't know. But it can create
Serviceactors, I guess it can be easily patched to allow creation ofGroupactors too.Can I use this actor to boost other actor's posts and have it visible on a Lemmy client?
I think FEP-1b12
Announceis not compatible with ActivityPub. It has different side effects, doesn't updatesharescollection.How can a Mastodon client ask the server to get a collection of all images with an specific tag?
Maybe something like
/api/v1/timelines/tag/{tag}?only_media=true?> @silverpill@mitra.social said:
>
> I think FEP-1b12 Announce is not compatible with ActivityPub.Shots fired
-
What happens when you send a "Offer" message to an actor on Mastodon?
The behavior of
Offeractivity is not described in ActivityPub, so Mastodon is not required to support it. Curiously, ActivityPub mentionsOfferwhen it talks about the side effects ofAccept:The side effect of receiving this in an inbox is determined by the type of the object received, and it is possible to accept types not described in this document (for example, an Offer).
...This statement is not compatible with the idea of a generic server.
Can I create a group actor on Mastodon?
I don't know. But it can create
Serviceactors, I guess it can be easily patched to allow creation ofGroupactors too.Can I use this actor to boost other actor's posts and have it visible on a Lemmy client?
I think FEP-1b12
Announceis not compatible with ActivityPub. It has different side effects, doesn't updatesharescollection.How can a Mastodon client ask the server to get a collection of all images with an specific tag?
Maybe something like
/api/v1/timelines/tag/{tag}?only_media=true?> I think FEP-1b12 Announce is not compatible with ActivityPub. It has different side effects, doesn't update shares collection.
Why?
Updating the shares collection is orthorgonal to the behavior expected from a Group actor that claims to support 1b12.
Sure, you can say that if the server does not update the shares collection, it's not fully compliant with AP APi, but there is nothing a Lemmy server to add every activity to the shares collection.
-
> 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.
@raphael @silverpill @julian @mariusor
I agree. Aboveall we need to know where protocol ends and 'app' begins. Be generally more deliberate in terminology use, and no longer talk in overloaded terms that have different unclear meanings to different people in different settings (to avoid using '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 @silverpill @julian @mariusor
I agree. Aboveall we need to know where protocol ends and 'app' begins. Be generally more deliberate in terminology use, and no longer talk in overloaded terms that have different unclear meanings to different people in different settings (to avoid using '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.
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.
-
@raphael @silverpill @julian @mariusor
I agree. Aboveall we need to know where protocol ends and 'app' begins. Be generally more deliberate in terminology use, and no longer talk in overloaded terms that have different unclear meanings to different people in different settings (to avoid using '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 @raphael @julian @mariusor I use the same definition of generic. With ActivityPub, it is not possible to have no knowledge at all, but we can try to minimize required knowledge and this is what my FEP is about.
