Post · BT Free Social

Post

@deadsuperhero@social.wedistribute.org · last week

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

moggie

@EverydayMoggie@sfba.social · 2 days ago

If that comes at the cost of having a single point of failure, a single place where content can be censored globally, as Bluesky has, then I would rather put up with the messiness of having separate accounts for all these services.

@deadsuperhero

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 days ago

@EverydayMoggie I understand your point, but that’s actually a categorical misunderstanding of how AT Protocol’s various layers work. The Fediverse is actually way more tightly coupled when it comes to instances and identities.

At least Blacksky has demonstrated that it’s possible to run the entire stack, and migrate absolutely everything to it from Bluesky.

Michael 🇺🇦

@heluecht@pirati.ca · last week

@deadsuperhero At Friendica we already support C2S. But it is rather limited. There are a lot of questions that will need to be answered until C2S is fully usable.

Evan Prodromou

@evan@cosocial.ca · last week

@heluecht @deadsuperhero hey, is anyone interested in participating in the API task force?

Sean Tilley

@deadsuperhero@social.wedistribute.org · last week

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.

Nik

@nikclayton@mastodon.social · last week

@deadsuperhero

"Mastodon already has a really good API".

Not really. It's inconsistent, incompletely documented, stringly typed, has a poor backward/forward compatibility story, and no clean way for other servers to extend the API without risking breakage.

E.g., https://github.com/pachli/pachli-android/issues/2043

All of these are fixable, but Mastodon GmbH has no incentive to fix them.

🫧 Social coding commons

@smallcircles@social.coop · last week

@deadsuperhero

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.

🫧 Social coding commons

@smallcircles@social.coop · last week

@deadsuperhero

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.

🫧 Social coding commons

@smallcircles@social.coop · last week

@deadsuperhero

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.

Emelia 👸🏻

@thisismissem@hachyderm.io · last week

@smallcircles @deadsuperhero I've quietly been borrowing ideas from AT Protocol for ActivityPub:
- declaring moderation actors
- supporting content labels (first party abd third party)
- looking at how custom feeds, DIDs and other tech may translate across

🫧 Social coding commons

@smallcircles@social.coop · last week

@thisismissem @deadsuperhero

I was looking at #ForgeFed which is a very sizable #ActivityPub extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi).

The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design.

All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see #SocialMedia as but a small subset of #SocialNetworking.

1 more replies (not shown)

Sean Tilley

@deadsuperhero@social.wedistribute.org · last week

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 · last week

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 · last week

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

Sean Tilley

@deadsuperhero@social.wedistribute.org · last week

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 · last week

@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 · last week

@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 · last week

Would love to hear what @evan thinks about this.

Evan Prodromou

@evan@cosocial.ca · last week

@deadsuperhero

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

GIF

Evan Prodromou

@evan@cosocial.ca · last week

@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 · last week

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

Sean Tilley

@deadsuperhero@social.wedistribute.org · last week

@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 · last week

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

Evan Prodromou

@evan@cosocial.ca · last week

@deadsuperhero so, it's a two-sided market -- clients and servers. The traditional mechanism is a "ratchet" -- build up one side, then build up the other, and then build up the first.

So, yes, servers first, then clients, then more servers, more clients, and so on back and forth.

julian

@julian@activitypub.space · last week

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 · last week

@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 · last week

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

1+ more replies (not shown)

julian

@julian@activitypub.space · last week

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 is POST /outbox and the Mastodon API handles their end.

Vice versa, NodeBB would use its own API to render a /world feed.

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

🫧 Social coding commons

@smallcircles@social.coop · last week

@julian @deadsuperhero @evan

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.

Evan Prodromou

@evan@cosocial.ca · last week

@smallcircles @julian @deadsuperhero we call them collections.

https://www.w3.org/TR/activitypub/#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.

🫧 Social coding commons

@smallcircles@social.coop · last week

@evan @julian @deadsuperhero

Except when they are called other names instead ;p

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.

Steve Bate

@steve@social.technoetic.com · last week

@smallcircles @evan An AS2 Collection cannot be a timeline (in general). It’s not even ordered. An AS2 OrderedCollection (a subtype of Collection) might be ordered by time or not, so it’s also not a timeline (in general). When they are ordered by some time value (unspecified in AP) they are often called “streams” in the spec. The Mastodon content timelines are not the same as AP activity streams although a filtered AP stream can be transformed to a content timeline.

Steve Bate

@steve@social.technoetic.com · 6 days ago

@smallcircles To follow up on the discussion from yesterday, @evan has created a proposal for another kind of “event stream” that is not necessarily associated with *any* AP collection type (see Example 1). This is more aligned with my mental model of an event feed/stream, where a timeline^1 is the history of the feed after optional filtering and content materialization. (^1 However, the terms are often used interchangeably in the Fedi.)

https://swicg.github.io/activitypub-api/sse

Server-Sent Events For the ActivityPub API

🫧 Social coding commons

@smallcircles@social.coop · 6 days ago

@steve @evan

Oh, that is very interesting. I will queue this up for inclusion in the delightful fediverse development curated list.

#Datastar may be a great library to check out here, and goes further in #hypermedia approach, where #HTMX considers itself feature-complete. Datastar uses #SSE to keep the connection to the client open. The client-side JS lib that is needed is super small. In datastar apps most of the business logic lives in the backend, and it lends itself very well for #EventSourcing. The original author/co-maintainer uses it with #NATS which also serves as the event store.

https://data-star.dev

🫧 Social coding commons

@smallcircles@social.coop · 6 days ago

@steve @evan

This is a nice video that demonstrates #EventSourcing with #Datastar + #SSE in a #Python context for the backend..

https://pyvideo.org/flaskcon-2025/death-to-the-spinner-event-sourcing-for-reactive-web-apps.html

Death to the spinner: event sourcing for reactive web apps

PyVideo.org

BT Free Social

BT Free is a non-profit organization founded by @ozoned@btfree.social . It's goal is for digital privacy rights, advocacy and consulting. This goal will be attained by hosting open platforms to allow others to seamlessly join the Fediverse on moderated instances or by helping others join the Fediverse.

BT Free Social: About · Code of conduct · Privacy ·

Bonfire social · 1.0.2-alpha.34 no JS en

Automatic federation enabled