Recently, there was a discussion about generic #ActivityPub servers.
-
@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.
@silverpill @raphael @julian @mariusor
The killer app for the fediverse is not nomadic identity. That is either a protocol capability or may refer to an Identity Management app, a solution design.
Problem is, it is no use discussing here. No convergence takes place, other than spontaneous / random convergence. But it does not lead anywhere, not to a common consensus. Not to robust foundations to build on without continuous worries that things break. Microblog communications does not support this, and lacking that support manual processes are needed.
Even the #ActivityPub #FEP only offers convergence to certain extent. The process is a band-aid, a best-we-have.
In analogy of the horserace, spontaneous convergence and ad-hoc alignment on FEP puzzle pieces by implementers equates to the horseback riders figuring out some basic rules to avoid serious accidents. But this FEP adoption at the same time warps the track, hems them in, alters reality and the future.
-
The crux of the issue is that we shouldn't need to talk about "your FEP" when we are talking about "servers focused on implementing the ActivityPub API". The spec as is *is enough*. You are moving the goal posts by pushing a definition of "generic server" when it doesn't need to,and you are creating a "No True Scottsman" by saying that implementation X, Y or Z is "incompatible" with ActivityPub API.
@trwnh @mariusor@raphael @silverpill well, it's missing a way to remove a follower, but otherwise the "POST to outbox" bits are mostly clear. except how the outbox delivery algorithm handles collections, which when they have inboxes, doesn't allow delivering only to that inbox instead of recursing over all items' inboxes.
otherwise i think "side effects" are a red herring. using as:result can be helpful but the "side effects" should happen in an attached client and should be called "automation".
-
@benpate Let's assume that my client is a music player. It publishes a
Listenactivity whereobjectis anAudio. This activity should increaseplayCounton theAudioobject.One way to support this on the server side is to teach it about
Listen,Audioand how to updateplayCount. This is how most existing servers are built.But a server described in my FEP would work differently:
- It doesn't know anything about
Listen,AudioorplayCount.
- Upon receivingListen, it will recognize it as an activity, and embeddedAudioas an object.
- Since this is not a CRUD operation, it will not check permissions.
- IfListenactivity has aresultproperty, the server will process that activity as well.
- Ifresultis anUpdateactivity, the server will recognize it as a CRUD operation and will check permissions:Update.actorandAudio.attributedTomust be the same.
- The server will save both activities,ListenandUpdate.
- Then it will deliver them to intended recipients (toandcc).Effects are client's responsibility now, it must provide an
Updateactivity if it wants to updateplayCount. There are other requirements too, for example all objects should have anattributedToproperty, which is needed for permission checks.But in this setup a single server can work with any kind of client.
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"?
-
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"?
> object ids are usually defined by the server
the server would need to know your namespace/prefix, then mint ids in that namespace. if that is a dns name, then you get dns portability. if it's an https uri, then you ideally need to support relative references and redirects.
"create a collection" can happen over any CRUD method supported. if you use AP as an API then this would be a Create(object.type=Collection) then you get HTTP 201 Created with a Location header.
-
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 @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".
-
The crux of the issue is that we shouldn't need to talk about "your FEP" when we are talking about "servers focused on implementing the ActivityPub API". The spec as is *is enough*. You are moving the goal posts by pushing a definition of "generic server" when it doesn't need to,and you are creating a "No True Scottsman" by saying that implementation X, Y or Z is "incompatible" with ActivityPub API.
@trwnh @mariusor -
@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".
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
resultproperty can be an embedded activity, or an array of activities.Clients either specify them, or they don't get any side effects.
-
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
resultproperty can be an embedded activity, or an array of activities.Clients either specify them, or they don't get any side effects.
@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).
-
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"?
@benpate Publishing process doesn't change much. A generic server should deliver activities to actors specified in
toandccfields. It should keep track of collections, such asfollowerscollection, and "expand" them before delivery. This part is not different from the regular ActivityPub.I think ID assignment should also work the same. In the FEP I proposed
Addactivity withoutobjectas a special activity for creating collections, but now I see that it will not work if IDs are minted by a server (no FEP-ae97).Perhaps it should be a
Create, after all, as @trwnh described in an adjacent comment. I was hesitant to useCreatebecause this is a problem for FEP-ae97 clients (not a big one though). -
@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 @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.
@smallcircles @silverpill @raphael @julian @mariusor ActivityPub as a space is just a mess, we have multiple types of social media clashing all over one protocoll whcih has a bunch of extensions with some being duplicates of other extensions and then diffrent people fighting over which one is the proper one to implement. At somepoint we just need to reset everything and start from a clean plate cause this shit cant go on forever.
-
@smallcircles @silverpill @raphael @julian @mariusor ActivityPub as a space is just a mess, we have multiple types of social media clashing all over one protocoll whcih has a bunch of extensions with some being duplicates of other extensions and then diffrent people fighting over which one is the proper one to implement. At somepoint we just need to reset everything and start from a clean plate cause this shit cant go on forever.
@fox @silverpill @raphael @julian @mariusor
Yes. I tooted about the need for Grassroots open standards and Grassroots standardization this morning..
🫧 socialcoding.. (@smallcircles@social.coop)
@hongminhee@hollo.social @kopper@not-brain.d.on-t.work SX defines the concept of a Grassroots open standard, and a domain of Grassroots standardization. These are direly needed to be able to healthily evolve #ActivityPub to where it can be the future of social networking, and support a peopleverse.
social.coop (social.coop)
In a decentralized grassroots movement, somewhere there needs to an aggregation of the solution artifact. In this case a robust, comprehensible #ActivityPub standard that can be readily implemented in libraries, frameworks and SDK's upon which then subsequently #SocialNetworking solution design can take place.
This is not centralization, this artifact can be federated. But there must be a place of convergence where consensus on protocol design comes together.
There might be a crowdsourced ActivityPub 2.0 specs + documentation site, plus a process around it to make it work.
-
@fox @silverpill @raphael @julian @mariusor
Yes. I tooted about the need for Grassroots open standards and Grassroots standardization this morning..
🫧 socialcoding.. (@smallcircles@social.coop)
@hongminhee@hollo.social @kopper@not-brain.d.on-t.work SX defines the concept of a Grassroots open standard, and a domain of Grassroots standardization. These are direly needed to be able to healthily evolve #ActivityPub to where it can be the future of social networking, and support a peopleverse.
social.coop (social.coop)
In a decentralized grassroots movement, somewhere there needs to an aggregation of the solution artifact. In this case a robust, comprehensible #ActivityPub standard that can be readily implemented in libraries, frameworks and SDK's upon which then subsequently #SocialNetworking solution design can take place.
This is not centralization, this artifact can be federated. But there must be a place of convergence where consensus on protocol design comes together.
There might be a crowdsourced ActivityPub 2.0 specs + documentation site, plus a process around it to make it work.
@smallcircles So we are at XKCD:927 again? Le Sigh. https://xkcd.com/927/ @fox @silverpill@mitra.social @raphael @julian @mariusor
-
@smallcircles So we are at XKCD:927 again? Le Sigh. https://xkcd.com/927/ @fox @silverpill@mitra.social @raphael @julian @mariusor
@jwildeboer @fox @raphael @julian @mariusor
No, not necessarily. The idea of the Grassroots open standard is that it allows an ecosystem that can evolve. That AP 2.0 artifact can be informal, and gradually adopted in W3C tracks, which I have always been advocating for with the 3-stage bottom-up standardization process in the past.
Other than that I am musing about a different approach, which is Protosocial, an AP extension that is 1.0 compliant. Yet not compliant to the protocol decay and tech debt ridden fediverse that grew by post-facto interop over time.
🫧 socialcoding.. (@smallcircles@social.coop)
#ThoughtProvoker :blobhyperthink: The current fediverse is an evolutionary dead-end for 2 reasons: 1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay. 2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out. Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with. To avoid fedi to become less and less attractive to newcomers, we must now consider: “Why do we want to grow the open social web, and for whom?” -- @ben@werd.social http://coding.social/blog/shared-ownership/
social.coop (social.coop)
-
@smallcircles So we are at XKCD:927 again? Le Sigh. https://xkcd.com/927/ @fox @silverpill@mitra.social @raphael @julian @mariusor
@jwildeboer @smallcircles @raphael @julian @mariusor next time just post the image bruh
-
@smallcircles @silverpill @raphael @julian @mariusor ActivityPub as a space is just a mess, we have multiple types of social media clashing all over one protocoll whcih has a bunch of extensions with some being duplicates of other extensions and then diffrent people fighting over which one is the proper one to implement. At somepoint we just need to reset everything and start from a clean plate cause this shit cant go on forever.
@fox @smallcircles Any important protocol is a mess, be it an internet protocol or an IRL institution.
I don't know much about email, but I bet it's even a bigger mess than ActivityPub.
-
@fox @smallcircles Any important protocol is a mess, be it an internet protocol or an IRL institution.
I don't know much about email, but I bet it's even a bigger mess than ActivityPub.
@silverpill @smallcircles @raphael @julian @mariusor Atleast the federation on it doesnt suck ass. Also the messy part of email is encryption, spam protection and identity verification
-
@benpate Publishing process doesn't change much. A generic server should deliver activities to actors specified in
toandccfields. It should keep track of collections, such asfollowerscollection, and "expand" them before delivery. This part is not different from the regular ActivityPub.I think ID assignment should also work the same. In the FEP I proposed
Addactivity withoutobjectas a special activity for creating collections, but now I see that it will not work if IDs are minted by a server (no FEP-ae97).Perhaps it should be a
Create, after all, as @trwnh described in an adjacent comment. I was hesitant to useCreatebecause this is a problem for FEP-ae97 clients (not a big one though). -
@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.
This thread is for arguing about the definition of "generic ActivityPub server" :]
I will probably create a topic on SocialHub later.
-
@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 You might find the idea of ''universal'' abstractions interesting in this context: https://www.humprog.org/~stephen/blog/research/recovering-abstraction.html
Similarly, the idea of "narrow waist" might also be relevant here: https://www.oilshell.org/blog/2022/03/backlog-arch.html#what-is-a-narrow-waist
