Post · bonfire.cafe

Post

@deadsuperhero@social.wedistribute.org · 9 hours ago

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?

We Distribute

django

@django@social.coop · 6 hours ago

@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.

django

@django@social.coop · 6 hours ago

@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.

django

@django@social.coop · 6 hours ago

@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.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 9 hours 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.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 9 hours ago

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.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 9 hours ago

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.

Brendan Jones

@Brendanjones@fosstodon.org · 2 hours ago

@deadsuperhero I don’t want a unified experience across services. I use Mastodon, Loops, Pixelfed etc for completely different things. I follow different people. Different topics (hashtags).

My point being, there has to be a layer to separate the services somewhere. Right now it’s at the account level, which honestly is fine for me because hey I’m used to signing in separately to Twitter, Instagram, etc.

But if accounts are unified, at what level do you separate the services?

Brendan Jones

@Brendanjones@fosstodon.org · 4 minutes ago

@deadsuperhero Is your idea that you have one unified account with one list of follows? Because then for each service I’d want to select a subset of follows from whom I’d like to see posts.

For example, imagine I used Friendica or another Facebook-analogous service, and Mastodon. If I had a unified Fediverse account I’d only want to follow some of my friends and family on Mastodon, and I’d want to see almost zero of the Mastodon people on Friendica.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 9 hours ago

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.

julian

@julian@activitypub.space · 6 hours ago

@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!

Sean Tilley

@deadsuperhero@social.wedistribute.org · 6 hours ago

@julian @general @evan Yeah, this is a really good point. It’s not currently super straightforward to implement, and as you’ve rightly pointed out, there’s a bunch of extra things that need to be built to support such a thing.

I almost wonder whether there’s a “minimum viable implementation”, like something that just handles authentication and low-level posting to the outbox / fetching from the inbox that might work as a starting point?

Sean Tilley

@deadsuperhero@social.wedistribute.org · 9 hours ago

Would love to hear what @evan thinks about this.

Evan Prodromou

@evan@cosocial.ca · 6 hours ago

@deadsuperhero

I am heart to heart with you on this, friend.

GIF

Evan Prodromou

@evan@cosocial.ca · 6 hours ago

@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

@django@social.coop · 5 hours ago

@evan @deadsuperhero there are also a number of frameworks that have already signalled interest or intent in supporting the API:
#Bonfire #FedBox #Fedify #Emissary

marius

@mariusor@metalhead.club · 43 minutes ago

@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.

@evan @deadsuperhero

Sean Tilley

@deadsuperhero@social.wedistribute.org · 5 hours ago

@django @evan Yep, I’m a big fan of all of these! I’m particularly interested in Bonfire and Emissary, but thrilled to hear about Fedify.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 6 hours ago

@evan 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.

julian

@julian@activitypub.space · 6 hours ago

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?

@deadsuperhero@social.wedistribute.org @evan@cosocial.ca

Evan Prodromou

@evan@cosocial.ca · 5 hours ago

@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/

W3C

19 February 2026 | ActivityPub API Task Force Meeting | Calendar

The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.

2 more replies (not shown)

Sean Tilley

@deadsuperhero@social.wedistribute.org · 6 hours ago

@julian @general @evan 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.

2 more replies (not shown)

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.2-alpha.29 no JS en

Automatic federation enabled