Recently, there was a discussion about generic #ActivityPub servers.
-
> 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.
-
@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.
@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.
-
> 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.
@raphael Nevermind, side effects wouldn't be a problem. However, it still doesn't seem to be compatible with ActivityPub... Because
Announceactivity is not defined in C2S context
ActivityPub
The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.
(www.w3.org)
-
@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.
-
@raphael Nevermind, side effects wouldn't be a problem. However, it still doesn't seem to be compatible with ActivityPub... Because
Announceactivity is not defined in C2S contextActivityPub
The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.
(www.w3.org)
@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 protocolTo 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.
🫧 socialcoding.. (@smallcircles@social.coop)
Attached: 1 image I recreated an old diagram in Excalidraw that I spread about a couple years ago, and made it a bit more informative. Explanation can be found in the #AltText See also and for discussion: https://discuss.coding.social/t/diagram-interoperability-in-practice/828 Or join the Social experience design chatroom at: https://matrix.to/#/#socialcoding-foundations:matrix.org Also posted to #SocialHub at: https://socialhub.activitypub.rocks/t/activitypub-versus-fediverse-interoperability-in-practice/8498 @ben@werd.social #SX #SocialCoding #SocialWeb #ActivityPub #SolidProject #fediverse
social.coop (social.coop)
-
@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.
@smallcircles @raphael @julian @mariusor I was comparing Mastodon and a spec-compliant ActivityPub server, from a user perspective. My claim is that even the most advanced implementations of ActivityPub API are on the same level as Mastodon API.
If you want to go beyond Mastodon API capabilities, you need a truly generic server. Something akin to Nostr relay.
-
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.
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?
-
@smallcircles @raphael @julian @mariusor I was comparing Mastodon and a spec-compliant ActivityPub server, from a user perspective. My claim is that even the most advanced implementations of ActivityPub API are on the same level as Mastodon API.
If you want to go beyond Mastodon API capabilities, you need a truly generic server. Something akin to Nostr relay.
@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
-
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.
@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
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 @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.
-
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?
@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)
-
@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)
@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!)
