I think the #ActivityPub client-to-server API is extremely important and underrated.
-
I think the #ActivityPub client-to-server API is extremely important and underrated. I'm glad to see the SWF and W3C group prioritizing it, because I think it has the potential to fix something that's kind of broken on the #Fediverse: too many accounts, on too many platforms that really ought to be clients.
Here's the rub, though: you need the big players in the space to support it. Mastodon needs to support it. Pixelfed and PeerTube need to support it.
So, how do you get the big existing projects to all implement it? How do you justify it?
-
I think the #ActivityPub client-to-server API is extremely important and underrated. I'm glad to see the SWF and W3C group prioritizing it, because I think it has the potential to fix something that's kind of broken on the #Fediverse: too many accounts, on too many platforms that really ought to be clients.
Here's the rub, though: you need the big players in the space to support it. Mastodon needs to support it. Pixelfed and PeerTube need to support it.
So, how do you get the big existing projects to all implement it? How do you justify it?
Would love to hear what @evan@cosocial.ca thinks about this.
-
Would love to hear what @evan@cosocial.ca thinks about this.
-
@deadsuperhero so, here's my best bet. I can be wrong!
1. Get some servers to implement the API well.
2. Get some must-have clients that run on those servers. This shows the value of the API.
3. Our leading servers shift to supporting it.That may work; I don't know. It's my best bet right now!
I want to note that WordPress is working on the API!
-
@deadsuperhero so, here's my best bet. I can be wrong!
1. Get some servers to implement the API well.
2. Get some must-have clients that run on those servers. This shows the value of the API.
3. Our leading servers shift to supporting it.That may work; I don't know. It's my best bet right now!
I want to note that WordPress is working on the API!
@evan@cosocial.ca Yeah, I mostly agree with this. It's just that the buy-in is a little bit of a chicken and egg problem. You need servers to adopt it, but you need a compelling first mover. Bonfire, maybe?
The spec definitely needs love, too. I think one of the harder things is building a timeline out of inbox activities. I feel like maybe a future version of the API could specify timelines somehow, whether it's an endpoint or some kind of basic query? Maybe there's even a way to implement alternative timelines at that level?
These are all just guesses on my part, but I feel like this could be a gateway to universal custom feeds.
-
@evan@cosocial.ca Yeah, I mostly agree with this. It's just that the buy-in is a little bit of a chicken and egg problem. You need servers to adopt it, but you need a compelling first mover. Bonfire, maybe?
The spec definitely needs love, too. I think one of the harder things is building a timeline out of inbox activities. I feel like maybe a future version of the API could specify timelines somehow, whether it's an endpoint or some kind of basic query? Maybe there's even a way to implement alternative timelines at that level?
These are all just guesses on my part, but I feel like this could be a gateway to universal custom feeds.
Does the inbox have to map to a timeline, specifically? Mastodon called this out as being difficult to do because you would have to real-time parse the inbox every time you wanted to load the timeline.
Of course one could always reduce the inbox into a single timeline and serve that instead, but then we're braching out with our own proprietary APIs again.
Is that ok?
-
Does the inbox have to map to a timeline, specifically? Mastodon called this out as being difficult to do because you would have to real-time parse the inbox every time you wanted to load the timeline.
Of course one could always reduce the inbox into a single timeline and serve that instead, but then we're braching out with our own proprietary APIs again.
Is that ok?
@julian@activitypub.space @general@activitypub.space @evan@cosocial.ca Again, this is sort of why I'm advocating for supporting timelines as a concept in the ActivityPub API. Instead of repeatedly parsing the inbox, we could do exactly what you're saying with some kind of representation of a timeline. Even if it's just plain old algorithmic time-sort.
-
@julian@activitypub.space @general@activitypub.space @evan@cosocial.ca Again, this is sort of why I'm advocating for supporting timelines as a concept in the ActivityPub API. Instead of repeatedly parsing the inbox, we could do exactly what you're saying with some kind of representation of a timeline. Even if it's just plain old algorithmic time-sort.
On the other hand, however... If the ActivityPub API were used in an S2S context, enabling something like NodeBB to send activities on behalf of a Mastodon user, then it wouldn't matter that there is no
GET /timeline, because all you need isPOST /outboxand the Mastodon API handles their end.Vice versa, NodeBB would use its own API to render a /world feed.
-
On the other hand, however... If the ActivityPub API were used in an S2S context, enabling something like NodeBB to send activities on behalf of a Mastodon user, then it wouldn't matter that there is no
GET /timeline, because all you need isPOST /outboxand the Mastodon API handles their end.Vice versa, NodeBB would use its own API to render a /world feed.
Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).
I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.
If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.
There's so much confusion on "where does the protocol end vs. where does my app design start".
SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.
-
Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).
I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.
If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.
There's so much confusion on "where does the protocol end vs. where does my app design start".
SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.
@smallcircles @julian @deadsuperhero we call them collections.
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)
-
@smallcircles @julian @deadsuperhero we call them collections.
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)
Except when they are called other names instead
A timeline is a different thing than a collection imho. And an AS collection has some very particular functionality, which if I model a timeline in my app may not supported (e.g. reverse ordering).
Collection / 'timeline' is one of those words where sometimes they indicate an app domain, and sometimes a core protocol mechanism. Same is true with 'follow' which is sometimes a user action, sometimes indicates low-level publish/subscribe.
For core capabilities that must be part of the specs, in 'protocol space' it may be better to use terminology that is more common in messaging architectures and all the various architecture patterns that are involved. Perhaps idk we deal with a time-ordered event log or something like that.
-
@smallcircles @julian @deadsuperhero we call them collections.
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)
@evan@cosocial.ca gosh I can't imagine assigning Add and Remove activities for a "popular" collection. It changes so often that it seems a waste of resources to try to track it.
Dynamic Collection?
Or as @smallcircles@social.coop said, even just light algorithmic ordering in a timeline makes stuffing it into a collection unwieldy.
-
@evan@cosocial.ca gosh I can't imagine assigning Add and Remove activities for a "popular" collection. It changes so often that it seems a waste of resources to try to track it.
Dynamic Collection?
Or as @smallcircles@social.coop said, even just light algorithmic ordering in a timeline makes stuffing it into a collection unwieldy.
I might not understand what we're talking about.
@smallcircles said that AP doesn't mention "timelines" or "feeds". We use a different term, collections. They are ordered in reverse chronological order, like what most people expect a "feed" to look like.
-
I might not understand what we're talking about.
@smallcircles said that AP doesn't mention "timelines" or "feeds". We use a different term, collections. They are ordered in reverse chronological order, like what most people expect a "feed" to look like.
I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
I've done it for other feeds, like `replies` or `followers`, and it works pretty well.
-
I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
I've done it for other feeds, like `replies` or `followers`, and it works pretty well.
#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?
A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.
I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.
🫧 socialcoding.. (@smallcircles@social.coop)
@thisismissem@hachyderm.io @eyeinthesky@mastodon.social The biggest folly imho is this idea of "let's cram every domain into #ActivityStreams somehow". Flatten everything and project it onto this small set of social primitives that AS defines. It is once more a choice of pragmatism: "Hey, I've seen it working with Mastodon, so I copied that. And #LinkedData extension mechanism is a handwaved horror show". So understandable perhaps that we did it. But now we must overcome this trend which has taken stubborn root and drags the ecosystem down.
social.coop (social.coop)
-
#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?
A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.
I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.
🫧 socialcoding.. (@smallcircles@social.coop)
@thisismissem@hachyderm.io @eyeinthesky@mastodon.social The biggest folly imho is this idea of "let's cram every domain into #ActivityStreams somehow". Flatten everything and project it onto this small set of social primitives that AS defines. It is once more a choice of pragmatism: "Hey, I've seen it working with Mastodon, so I copied that. And #LinkedData extension mechanism is a handwaved horror show". So understandable perhaps that we did it. But now we must overcome this trend which has taken stubborn root and drags the ecosystem down.
social.coop (social.coop)
@smallcircles@social.coop I feel personally called out for this
-
@smallcircles@social.coop I feel personally called out for this
No need to, I didn't call you out
I think the fediverse-we-have has become a very different one than the fediverse-promised based on the initial specs when there weren't implementations and an installed base making numerous design decisions in a very ad-hoc pragmatic fashion. Which is in itself fine, and a very good approach to get an ecosystem off the ground. But having the app-centric, app-first evolution be the primary evolution process, brought us to a different space than the ubiquitous, heterogeneous social networking environment we might all be working in, focused on exciting solution designs and less in all the plumbing and impl details.
No one is really to blame I guess. This is where laissez-faire in grassroots environments leads us, following the social dynamics that exist.
We can do better, but it is very hard in our individualist, FOSS-project-oriented herding of cats chaotic environment. The challenges are social in nature..
Major challenges for the Fediverse
Various forum topics highlights big challenges for the Fediverse to overcome. Below there is a list of those, and all of them are within scope of Social Coding #foundations to contribute to solutions. Challenge Desc…
Discuss Social Coding (discuss.coding.social)
-
I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
I've done it for other feeds, like `replies` or `followers`, and it works pretty well.
@evan @julian@activitypub.space @smallcircles Mind if I butt in here with a question about management of the `replies` collection? I'm looking at this for the interaction controls FEP draft.
GoToSocial currently broadcasts an `Accept(Note)` to let followers know a reply has been accepted (see https://docs.gotosocial.org/en/latest/federation/interaction_controls/#broadcasting-accepts-for-the-benefit-of-third-servers). We'd want to add an inverse for revocation, which would be `Undo(Accept(Note))` imo.
I feel `Add` and `Remove` on the `replies` collection may be more idiomatic and, in a sense, easier. Opinions?
-
@evan @julian@activitypub.space @smallcircles Mind if I butt in here with a question about management of the `replies` collection? I'm looking at this for the interaction controls FEP draft.
GoToSocial currently broadcasts an `Accept(Note)` to let followers know a reply has been accepted (see https://docs.gotosocial.org/en/latest/federation/interaction_controls/#broadcasting-accepts-for-the-benefit-of-third-servers). We'd want to add an inverse for revocation, which would be `Undo(Accept(Note))` imo.
I feel `Add` and `Remove` on the `replies` collection may be more idiomatic and, in a sense, easier. Opinions?
@julian@fietkau.social @julian@activitypub.space @smallcircles I like Accept and Reject but @trwnh is pretty insistent on Add and Remove so I defer to them.
-
No need to, I didn't call you out
I think the fediverse-we-have has become a very different one than the fediverse-promised based on the initial specs when there weren't implementations and an installed base making numerous design decisions in a very ad-hoc pragmatic fashion. Which is in itself fine, and a very good approach to get an ecosystem off the ground. But having the app-centric, app-first evolution be the primary evolution process, brought us to a different space than the ubiquitous, heterogeneous social networking environment we might all be working in, focused on exciting solution designs and less in all the plumbing and impl details.
No one is really to blame I guess. This is where laissez-faire in grassroots environments leads us, following the social dynamics that exist.
We can do better, but it is very hard in our individualist, FOSS-project-oriented herding of cats chaotic environment. The challenges are social in nature..
Major challenges for the Fediverse
Various forum topics highlights big challenges for the Fediverse to overcome. Below there is a list of those, and all of them are within scope of Social Coding #foundations to contribute to solutions. Challenge Desc…
Discuss Social Coding (discuss.coding.social)
Btw, some time ago in a matrix discussion I sketched how I'd like to conceptually 'see' the social network. Not Mastodon-compliant per se (though it might be via a Profile or Bridge) but back to "promised land". Where the protocol is expressed in familiar architecture patterns and borrows concepts from message queuing, actor model, event-driven architecture, etc.
Then as a "Solution designer" I am a stakeholder that wants to be completely shielded from all that jazz. That should all be encapsulated by the protocol libraries and SDK's that are offered in language variants across the ecosystem. #ActivityPub et al is a black box. I can directly start modeling what should be exchanged on the bus, and I can apply domain driven design here. And if I have a semantic web part of my app I'd use linked data modeling best-practices.
I would have power tools like #EventCatalog and methods like #EventModeling.
Visualize Your Architecture - EventCatalog
See how your services connect, how data flows, and how messages move through your system. Generated from your docs, always accurate.
EventCatalog (www.eventcatalog.dev)
Event Modeling Introduction
Event Modeling can be applied in designing systems that will store state in traditional databases. By providing a more thorough design, the solution can be implemented with a lot less waste that usually comes in the form of having to re-visit finished items as the solution is built up.
(eventmodeling.org)
