I think the #ActivityPub client-to-server API is extremely important and underrated.
Fediverso
120
Posts
12
Posters
120
Views
-
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.
-
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?
Here's the thing: Mastodon already has a really good API. There's a whole ecosystem of clients around it, to the point that many other Fediverse implementations adopted it, so that they can use the apps.
I don't think this is a bad thing in and of itself. But, if we want projects like Mastodon to support it, the value proposition has to provide things that the Mastodon API does not.
I think a killer feature to focus on would be identity management.
-
Here's the thing: Mastodon already has a really good API. There's a whole ecosystem of clients around it, to the point that many other Fediverse implementations adopted it, so that they can use the apps.
I don't think this is a bad thing in and of itself. But, if we want projects like Mastodon to support it, the value proposition has to provide things that the Mastodon API does not.
I think a killer feature to focus on would be identity management.
Bluesky absolutely got it right with ATproto: you can make any kind of client, not just microblogging, and it will seamlessly work with your Bluesky identity. Everything you post goes into your personal storage, and the clients that know how to interpret special data types are able to reach into your PDS and the timelines you're following to present that stuff.
ActivityPub API needs to follow a similar story.
-
Bluesky absolutely got it right with ATproto: you can make any kind of client, not just microblogging, and it will seamlessly work with your Bluesky identity. Everything you post goes into your personal storage, and the clients that know how to interpret special data types are able to reach into your PDS and the timelines you're following to present that stuff.
ActivityPub API needs to follow a similar story.
Why do I care so much about this? A few reasons.
One, I don't want to have a dozen different accounts across separate types of applications on the same network. I really hate that, it's messy and does nothing to unify my identity across all the spaces I'm active on.
Two, a seamless login across the entire network could be very powerful for discovery. Instead of having to find people to follow on Pixelfed and PeerTube, the folks I'm already connected to would already be there, right when I sign in.
Three, we could develop a new generation of rich clients that all do really different things, but all tie back to a singular identity. "Sign In With ActivityPub" could work for the entire network, and it wouldn't have to be a hack using Mastodon's API.
-
Why do I care so much about this? A few reasons.
One, I don't want to have a dozen different accounts across separate types of applications on the same network. I really hate that, it's messy and does nothing to unify my identity across all the spaces I'm active on.
Two, a seamless login across the entire network could be very powerful for discovery. Instead of having to find people to follow on Pixelfed and PeerTube, the folks I'm already connected to would already be there, right when I sign in.
Three, we could develop a new generation of rich clients that all do really different things, but all tie back to a singular identity. "Sign In With ActivityPub" could work for the entire network, and it wouldn't have to be a hack using Mastodon's API.
Finally, I think there are some serious improvements we can bring to fill the gaps that the current spec is missing. What if we had a standard endpoint for notifications?
Suppose we also developed a standard way of doing timelines as well, and used it as a springboard for custom feeds that could work with any app, any client, and any server?
There's a lot of useful stuff we could do here to make the whole thing extremely compelling for anyone building on this network.
-
Finally, I think there are some serious improvements we can bring to fill the gaps that the current spec is missing. What if we had a standard endpoint for notifications?
Suppose we also developed a standard way of doing timelines as well, and used it as a springboard for custom feeds that could work with any app, any client, and any server?
There's a lot of useful stuff we could do here to make the whole thing extremely compelling for anyone building on this network.
@deadsuperhero@social.wedistribute.org thanks for posting.
I think what makes it hard for existing implementations to support it is that if you're not AS-native (that is, consuming ActivityStreams activities directly without converting to some normalized form for your software), then it's possibly a big lift to "level up" your code to do it that way.
Like Mastodon, NodeBB ingests the activity, extracts the juicy bits, and discards the rest. It makes it hard to later on recall an activity because they were ephemeral (at least in our chain of custody).
So an entire new middleware layer needs to be built for NodeBB to catalog and store (and later, recall) these activities for ActivityPub API support.
Correct me if I'm wrong @evan@cosocial.ca!
-
@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?
-
@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.
-
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?
@deadsuperhero I donβt necessarily think we need the big players. Especially where those projects have stated their intent to stick to micro, or photo -blogging, with limited interop.
-
@deadsuperhero I donβt necessarily think we need the big players. Especially where those projects have stated their intent to stick to micro, or photo -blogging, with limited interop.
@deadsuperhero imho, building out c2s will allow new projects to bootstrap the front end, and focus on new application domains, or support multiple activity/object types.
-
@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.
@deadsuperhero @general @julian yeah, I think custom timelines are great. Some good issues in here on the topic:
-
@julian @deadsuperhero We actually have a meeting tomorrow if either of you wants to come.
https://www.w3.org/events/meetings/3432cf4c-a9fe-4f72-8de5-fa6809b57767/20260219T110000/
@evan@cosocial.ca okay, I'll see you there!
-
@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!
-
@django I would object to FedBOX having "signaled interest or intenent".
FedBOX, and the GoActivityPub library that's been built upon, simply "support" client to server and have been since it's inception 7-8 years ago.
-
Here's the thing: Mastodon already has a really good API. There's a whole ecosystem of clients around it, to the point that many other Fediverse implementations adopted it, so that they can use the apps.
I don't think this is a bad thing in and of itself. But, if we want projects like Mastodon to support it, the value proposition has to provide things that the Mastodon API does not.
I think a killer feature to focus on would be identity management.
Yes. Mastodon has always given their own product decisions precedence over healthy evolution of the ecosystem as a whole. And despite many people being very frustrated about that, I think this is perfectly valid decision. After all choosing to implement an open standard should not come with the obligation to maintain/evolve that standard. It is only smart to do so, and Mastodon did this with an eye on their own product development.
Imho it is really the broader dev ecosystem that is at fault in letting the fedi be taken hostage by past Mastodon decisions, making them the post-facto #interoperability leader. As for Mastodon API I'd argue that its users are not on the fediverse. They are on Mastodon.
Identity management may be killer feature, but only when first a sound #ActivityPub foundation is in place. AS/AP isn't as-yet robust enough to be the future of social networking. I'd say the extensibility mechanism is killer feature, and having SDK's and devtools for that.
-
Yes. Mastodon has always given their own product decisions precedence over healthy evolution of the ecosystem as a whole. And despite many people being very frustrated about that, I think this is perfectly valid decision. After all choosing to implement an open standard should not come with the obligation to maintain/evolve that standard. It is only smart to do so, and Mastodon did this with an eye on their own product development.
Imho it is really the broader dev ecosystem that is at fault in letting the fedi be taken hostage by past Mastodon decisions, making them the post-facto #interoperability leader. As for Mastodon API I'd argue that its users are not on the fediverse. They are on Mastodon.
Identity management may be killer feature, but only when first a sound #ActivityPub foundation is in place. AS/AP isn't as-yet robust enough to be the future of social networking. I'd say the extensibility mechanism is killer feature, and having SDK's and devtools for that.
Right now extensibility of #ActivityPub shapes up as custom app-by-app app-centric development where individual devs just pragmatically throw new stuff on the wire, and when their app gains any popularity or other apps to integrate in a similarish application, things are bolted onto that in random ways. That whole story really constitutes a Big Ball of Mud anti-pattern that only introduces protocol decay, tech debt, and whack-a-mole programming, that is very hard to get rid of once there exists an installed base.
The reason that we do things that way is very understandable. It works in a grassroots environment where indivualist devs find it very hard and not valuable to collaborate at scale in what amounts to a kind of design-by-consensus process. But it comes at a high cost, where interoperability is basically out the door and any app has to be shaped as a pretzel and adopt all the quirks introduced by predecessors in a particular app domain to fit itself on the wire.
-
Right now extensibility of #ActivityPub shapes up as custom app-by-app app-centric development where individual devs just pragmatically throw new stuff on the wire, and when their app gains any popularity or other apps to integrate in a similarish application, things are bolted onto that in random ways. That whole story really constitutes a Big Ball of Mud anti-pattern that only introduces protocol decay, tech debt, and whack-a-mole programming, that is very hard to get rid of once there exists an installed base.
The reason that we do things that way is very understandable. It works in a grassroots environment where indivualist devs find it very hard and not valuable to collaborate at scale in what amounts to a kind of design-by-consensus process. But it comes at a high cost, where interoperability is basically out the door and any app has to be shaped as a pretzel and adopt all the quirks introduced by predecessors in a particular app domain to fit itself on the wire.
It does not need to be that way. I am quite happy after all (after being initially frustrated) by how #ATProto has disrupted things, and opened the eyes of devs in the #ActivityPub ecosystem that we must act or lose out (stay niche, which may be fine too) to the Atmoshpere and how it enables devs to focus on service and product delivery instead of low-level wire plumbing and continuous breakages.
ATProto also shows the way that we can now follow on the #fediverse to catch up again: cocreate a similar robust basis for people to build on. #Bluesky had the advantage of a greenfield start and dedicated team unburdened by past decisions. And they build this whole Lexicon system and ways to introspect functionality.
We can do that too, solve the #LinkedData conundrum, and create an extensibility mechanism that allows devs to focus on service modeling. The more introspection this mechanism allows for, the less design-by-consensus is required, easing expansion to new domains.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@reiver there's a page on this in the primer:
https://www.w3.org/wiki/Activity_Streams/Primer/Article_and_Note
But it's not always clear.
One thing that might distinguish is presentation.
I expect an Article to appear on its own page. References to an Article in a stream or tree layout might just include title and summary, with a link to a UI to show the full text.
But lots of Note objects can fit in a stream or tree presentation.
-
@reiver I like this distinction well enough that I might implement it.
-
@smallcircles that sounds cool!
-
@reiver@mastodon.social that's a good summary for it.
-
In the old blogging software I created back in the 1990s, I had a handful of posts types
There was a type of rich-text oriented post that had a title. (Article)
And, there way another type of rich-text oriented post that did not have a title. (Note)
(There were also other types of posts, but they aren't relevant here)
These 2 types of posts were rendered / displayed differently
I.e., my 1990s software already had this distinction
-
I've seen an ongoing debate between "Note" versus "Article" in ActivityPub / ActivityStreams.
When is something a "Note"β½
When is something an "Article"β½Personally β I would probably have made the distinction this way.
An "Article" has a title.
A "Note" doesn't have a title.(In ActivityPub / ActivityStreams, a 'title' seems to tend to get represented in the "name" field.)
-
So the area where my plans go I call "Residential social networking", geo-fenced but inter-connected social networking circles that cover a city, town, or rural area, and which enable their residents to not only create content on the network, but the dynamic apps and services based on local needs that exist in the area. The intent of a residential social network is to engage people *offline* and in activities that support the local economy. Or rather strengthens the Circles of Sustainability in SX terminology:
https://coding.social/blog/reimagine-social/#circles-of-sustainability
And all this should be a relatively low-code affair, directly accessible already for a first-time dev. This requires having a mature open standards based healthy technology foundation and thriving ecosystem.
I am a developer, though with rusty coding skills these days, and I might have started a fedi app design in 2018 or so. But this would not have led to the desired outcome, just throw one more app-centric software in the mix.
-
Some implementations skip some of these steps, because they are focused only on processing messages as they arrive. So, I am reluctant to overemphasize the message processing at the expense of the personal datastore functionality.
