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?
damon likes this.
reshared this
Sean Tilley
in reply to Sean Tilley • • •Evan Prodromou
in reply to Sean Tilley • • •like this
Sean Tilley e damon like this.
General Discussion reshared this.
Evan Prodromou
in reply to Evan Prodromou • • •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!
like this
Sean Tilley e damon like this.
damon reshared this.
Sean Tilley
in reply to Evan Prodromou • • •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
in reply to Sean Tilley • • •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
Sean Tilley
in reply to julian • • •Evan Prodromou
in reply to Sean Tilley • • •@general @julian yeah, I think custom timelines are great. Some good issues in here on the topic:
github.com/swicg/activitypub-a…
swicg/activitypub-api
GitHubjulian
in reply to Sean Tilley • • •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.
@deadsuperhero@social.wedistribute.org @evan@cosocial.ca
like this
Sean Tilley e infinite love ⴳ like this.
🫧 socialcoding..
in reply to julian • • •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.
🫧 socialcoding.. reshared this.
Evan Prodromou
in reply to 🫧 socialcoding.. • • •we call them collections.
w3.org/TR/activitypub/#collect…
ActivityPub
www.w3.org🫧 socialcoding..
in reply to Evan Prodromou • • •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.
🫧 socialcoding.. reshared this.
Steve Bate
in reply to 🫧 socialcoding.. • • •🫧 socialcoding.. reshared this.
🫧 socialcoding..
in reply to Steve Bate • • •I agree with what you say.
On the use of "stream(s)" I did a search in both specs, and it is only very sparsely used in the meaning of a stream rather than an Activity Streams document or object.
One time mentioned as "Activity Streams consumer" in #ActivityStreams core and another mention in the Security considerations section.
> Publishers or Consumers implementing Activity Streams as a stream of public data ..
And twice in #ActivityPub where it says both inbox and outbox where it mentions "the outbox stream", "the inbox stream", and one other mention in definition of "Social API" where it is said to provide a "social stream of the user's actor".
So I would not consider this formal language terminology right now. That said, it would be good to further formalize the concept of a Stream, as it is a higher-order concept that'll help lift discussions out of nitty gritty impl detail territory.
Steve Bate
in reply to 🫧 socialcoding.. • • •I agree. It’s not formal at all. There’s also the “streams” property associated with AP actors.
streams: A list of supplementary Collections which may be of interest.
Also, not formal. I’d also think they’d need to be OrderedCollections to be considered a stream.
🫧 socialcoding..
in reply to Steve Bate • • •Yes, OrderedCollections.
I wonder what you think about what I wrote in another toot, to define normative architecture patterns as building blocks, instead of having the most granular social primitives being the puzzle pieces that everyone shuffles together in their own unique ways causing endless confusions..
social.coop/@smallcircles/1160…
🫧 socialcoding..
2026-02-19 22:46:06
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •marius
in reply to Steve Bate • • •I think
we need to emphasize that timelines can be built from regular collections, even unordered ones, by using some intermediate representations specific to the type of timeline that a client wants to render.
The fact that the specification does not directly support a mapping between a collection and a responsive timeline, *DOES NOT MEAN* one can't be built from it, only that it requires a little more effort on the client side.
My goto example is how rich mail clients allow responsive mailbox representations on top of a much less expressive collection method that IMAP provides compared to ActivityPub.
@smallcircles @evan
reshared this
General Discussion reshared this.
Steve Bate
in reply to marius • • •marius
in reply to Steve Bate • • •yes, that's how I meant it. A client fetches as much of the collection as it can, then applies whatever rules it wants to transform the result into a "timeline" when the user asks for it.
This however most likely requires local caching of the collection to have decent latency.
@smallcircles @evan
General Discussion reshared this.
Steve Bate
in reply to marius • • •🫧 socialcoding..
in reply to Steve Bate • • •marius
in reply to Steve Bate • • •frankly I disagree with this point. Servers should be simple. We need to move away from the paradigm of custom purpose ActivityPub servers that Mastodon pushed where the client and server are the same service.
Timelines should be orthogonal to the ActivityPub specification and, in my opinion, kept well away from it.
What's the benefit for my client application to know what your server's preferred timeline representation is?
Let's not go down the path where everything looks like a nail because we really like hammers.
@smallcircles @evan
reshared this
General Discussion reshared this.
🫧 socialcoding..
in reply to marius • • •I think it depends on the use case. It would be good or best practice to model things on the client that can be on the client, and not have them on a hosted platform that may become a new point of centralization and/or FOSS/vendor lock-in.
But there may also be legit use case for server applications that require a timeline. Perhaps a service that exposes a huge dataset to the fedi, archives, knowledge bases, etc.
Steve Bate
in reply to marius • • •🫧 socialcoding..
in reply to Steve Bate • • •marius
in reply to Steve Bate • • •apologies, I take "server" in the context of ActivityPub discussion to be an "ActivityPub server", not all the other web-servers involved in the process.
And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.
@smallcircles @evan
General Discussion reshared this.
🫧 socialcoding..
in reply to marius • • •> And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.
Indeed. Another term that I see people use in different meaning, also when talking about C2S.
In one meaning the user device is referred to, that you might need to hole-punch with to have a full AP server, or which depends on a server relay.
And the other meaning as role. As in client/server roles, pure conceptual, and which might swap too.
Steve Bate
in reply to 🫧 socialcoding.. • • •🫧 socialcoding..
in reply to Steve Bate • • •Yes. And again same here 😀
Just pointing out the Babylonian speech confusion that we haven't overcome yet.
marius
in reply to Steve Bate • • •out of curiousity why do you make a difference between a consumer of AcitvityPub (assumedly you mean something that fetches ActivityPub using HTTP GET) and a C2S client?
My assumption is that if something fetches ActivityPub objects and is capable of rendering it to another representation for its users, that's a client to server client.
Client to server has two sections: consumer and producer and I think anything that fulfills any of those can be called a C2S client...
@smallcircles @evan
Steve Bate
in reply to marius • • •Emelia 👸🏻
in reply to Steve Bate • • •reshared this
🫧 socialcoding.. e General Discussion reshared this.
Ben Pate 🤘🏻
in reply to Emelia 👸🏻 • • •Just checking my memory.. this concept exists already, yes?
w3.org/wiki/ActivityPub/Primer…
Are you just saying that the new API spec should include this? Or am I missing something?
ActivityPub/Primer/proxyUrl endpoint - W3C Wiki
www.w3.orgGeneral Discussion reshared this.
Evan Prodromou
in reply to Ben Pate 🤘🏻 • • •Yes, proxyUrl already exists. There's a use case here:
github.com/swicg/activitypub-a…
The only other way I've seen this use case discussed is with client-side HTTP Signature keys. There's some kind of negotiation between the server and the client, and then the client can make requests to remote servers using HTTP Signature and a key it controls.
Remote object access
evanp (GitHub)General Discussion reshared this.
Emelia 👸🏻
in reply to Evan Prodromou • • •my understanding of proxyUrl is that it's just fetching a remote object, but without forwarding authorization
For many cases you want to forward the request as the authenticated user to the remote server, not doing the request anonymously
General Discussion reshared this.
marius
in reply to Emelia 👸🏻 • • •it's not explicitly saying to forward authorization, but to me that's implied from "require authentication":
proxyUrl: Endpoint URI so this actor's clients may access remote ActivityStreams objects which require authentication to access
w3c.github.io/activitypub/#pro…
@evan @benpate @steve @smallcircles
ActivityPub
w3c.github.ioGeneral Discussion reshared this.
Evan Prodromou
in reply to marius • • •I have implemented it requiring OAuth on one side and using HTTP Signature on the other. I think you need to use the user's authorization for private content or to respect personal blocks. It sucks for caching but ¯\_(ツ)_/¯
@thisismissem @benpate @steve @smallcircles
General Discussion reshared this.
marius
in reply to Evan Prodromou • • •General Discussion reshared this.
Ben Pate 🤘🏻
in reply to Evan Prodromou • • •Yeah, this is how I'd expect it to work (with the possible addition of *also* allowing cookie auth on the client side)
But yeah. Locally authenticated user from my client -> my server, then HTTP signature from my server -> your server
@evan @mariusor @thisismissem @steve @smallcircles
General Discussion reshared this.
Evan Prodromou
in reply to Ben Pate 🤘🏻 • • •With all the standard warnings around proxies!
@mariusor @thisismissem @steve @smallcircles
General Discussion reshared this.
Emelia 👸🏻
in reply to Evan Prodromou • • •yeah, it's the only way to do it.
But this infrastructure actually is what enables things like the AT Protocol "proxy through my PDS to the bluesky app view" or "proxy through my PDS to a custom feed generator" functionality.
That's how that all works.
reshared this
General Discussion reshared this.
Emelia 👸🏻
in reply to Ben Pate 🤘🏻 • • •marius
in reply to Emelia 👸🏻 • • •I have just implemented that for the GoActivityPub servers and it's easier than it sounds.
The only important step required is to convert the client authorization token (presumably an OAuth2 bearer token) to a valid actor and then further to a valid Private Key with which to sign the remote request. After that the only thing remaining is to pipe verbatim the received response to the client...
@steve @smallcircles @evan
reshared this
General Discussion reshared this.
Emelia 👸🏻
in reply to marius • • •marius
in reply to Emelia 👸🏻 • • •which is what proxyUrl is supposed to do, right?
Did you mean it in a different way?
@steve @smallcircles @evan
marius
in reply to Steve Bate • • •yes, but something dumb that only fetches a URL and converts the resulting ActivityPub into a valid other type of representation is a valid client in my opinion. That's what I mean, was that unclear?
@smallcircles @evan
Steve Bate
in reply to marius • • •clear. I agree it’s a kind of “client”, just not necessarily a C2S client.
marius
in reply to Steve Bate • • •OK, but why?
I feel like I explained my position relatively clearly, I would like to understand yours, even though I feel some animosity has started to crop up.
@smallcircles @evan
General Discussion reshared this.
Steve Bate
in reply to marius • • •🫧 socialcoding..
in reply to Steve Bate • • •Evan Prodromou
in reply to 🫧 socialcoding.. • • •I think in particular the terms "publisher" and "consumer" from AS2 and "client" and "server" from AP don't always map cleanly, especially with HTTP POST requests.
When a client delivers an activity to the actor's outbox, the client is the publisher of that activity, and the server is the consumer.
Same when a sending server (publisher) delivers an activity to a receiving server (consumer).
reshared this
🫧 socialcoding.. e General Discussion reshared this.
Evan Prodromou
in reply to Steve Bate • • •so, a client could send some kind of definition for the timeline ("only Create/Image or Create/Video activities from the inbox where the image is tagged 'caturday'") and then the server sorts data into that timeline? That sounds like a neat feature.
However, I think there might be some definitions that are so common that we could just define them in a spec, like `notifications`.
General Discussion reshared this.
Steve Bate
in reply to Evan Prodromou • • •marius
in reply to Steve Bate • • •I've just seen a FEP-34c1 today which uses the TREE hypermedia vocabulary (which I wasn't familiar with) to ask from servers a particular representation of existing collections. Have a look if it's similar to your ideas.
codeberg.org/fediverse/fep/src…
@evan @smallcircles
fep/fep/34c1/fep-34c1.md at main
Codeberg.orgmarius
in reply to marius • • •my reasoning about the ActivityPub client/server model is that the servers form just a just a dumb pipeline to dispatch content from clients to other clients.
When servers are just storage, then everything can be much more flexible. Clients can be as expressive as they want and make whichever assumptions about what "good data" looks like, while servers are just dumb pipes that accept and dispatch everything that's a valid JSON-LD document.
@smallcircles @evan
Evan Prodromou
in reply to Steve Bate • • •The `inbox` and `outbox` are both sequences ordered by time. I think that should meet your requirements for a 'timeline'?
I think it's fair to call the outbox the actor's 'feed'? It is a feed of all their activities.
General Discussion reshared this.
Evan Prodromou
in reply to Evan Prodromou • • •General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •> I think it's fair to call the outbox the actor's 'feed'?
The actor's event bus in a pure event based approach. 😃
Does that break AP? Current fediverse?
Can AP be considered an event-driven architecture of sorts (or restrained as such in a solution design)?
I really like the Motivating use cases section of the AS specs, and the primer that sits on the W3C wiki to that. Those might be further formalized so they are applied consistently.
Evan Prodromou
in reply to 🫧 socialcoding.. • • •I know what an "event bus" is but I don't think it applies here. Usually it means a global data structure that attached processes can add events to and read events from. We don't have that in ActivityPub.
I think it's fair to say that activities are like events.
I also like the use cases and primer.
General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •Well, but a part of the specs can certainly be considered a message bus with channels conceptually.
Channel is the name that AsyncAPI uses, which maps to domain aggregates and actor streams.
But considering things purely event-based is stretching it, and may be better to discern between commands and events.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •Btw, wrt fediverse we really live in a multiverse by all the different perspectives people have towards what the network should or should not provide. All having different physics.
Where ActivityPub is gravity, and fediverse is entropy and chaos, and universes have become inaccessible over time, past stations.
Evan Prodromou
in reply to 🫧 socialcoding.. • • •General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •No, it is more than just metaphors. It is that both domain/scope and architecture patterns aren't clearly defined, while the terminology is borrowed from a whole range of them. This makes one person think that AP is for whole different purposes than the next person.
Is AP for modeling existing social media or for social networking, encompassing many more domains? For content publishing or also for distributed services? Linked data hypermedia or message oriented architecture. Problem is, it is all of that, depending on who you ask.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •Evan Prodromou
in reply to 🫧 socialcoding.. • • •maybe? I guess you could consider the `sharedInbox` to be like that.
I think that activities sent to the API by a client are kind of like commands, but they can also be events that happened on a different system.
If I got an achievement in a game, and that was sent as an activity to the API, it's more like an event notification than a command.
General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •Evan Prodromou
in reply to 🫧 socialcoding.. • • •General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •It is both, like in that diagram draft.. or at least could be considered such (the notes apply to Protosocial musings).
social.coop/@smallcircles/1160…
🫧 socialcoding..
2026-02-19 21:52:35
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •Another issue: Unclear protocol layers.
> I am not a fan of the idea that #ActivityPub is a message-passing system; it's a read-write API.
I'm not sure what a "read-write API" is, really. It 's a fuzzy term, whereas message based systems have well-defined architecture patterns and a body of IT knowledge and practice to apply them in robust communication systems. A 'Message API' has a generic, consistent interface.
The overarching goal of AS/AP should be empowerment of the Solution developer so they can directly focus on building use cases for their application or business domain. They should not have to think about any of the intrinsics of the protocol, like particular GETs and POSTs used to model protocol capabilities in the HTTP transport layer.
Solution design then involves:
0. Model the domain
1. Data modeling, msg formats + validation
2. Define actor msg exchange patterns
3. Document design
--
4. Improve these steps. Add native protocol + tool support over time.
Evan Prodromou
in reply to 🫧 socialcoding.. • • •it's ok if you haven't heard of a REST API. It's an API that uses HTTP for reading and writing data. Wikipedia has a good
article about it:
en.wikipedia.org/wiki/REST
architectural style for client-server applications
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)reshared this
🫧 socialcoding.. e General Discussion reshared this.
Evan Prodromou
in reply to Evan Prodromou • • •one anti-pattern I dislike seeing in ActivityPub discussions is that only one interaction defined in the ActivityPub spec is valid: an HTTP POST to an actor's `inbox` for server-to-server interactions.
We can use HTTP GET to fetch additional data about objects, actors and collections.
General Discussion reshared this.
Evan Prodromou
in reply to Evan Prodromou • • •So, I disagree that we have to exclusively adopt a message-passing paradigm for ActivityPub.
EDIT: note that it's exclusive.
General Discussion reshared this.
Christine Lemmer-Webber
in reply to Evan Prodromou • • •General Discussion reshared this.
🫧 socialcoding..
in reply to Christine Lemmer-Webber • • •> it's ok if you haven't heard of a REST API.
Well, you be you. I consider this a 'typical Evan remark' by now, dripping with sarcasm. It is a weird fit for someone who want to lead the #SocialCG efforts, I'd say.
Ah well. What I am talking about is architecture and design, and all the things that allow people to easily form a clear mental picture on how things fit together, wrap their head around the fediverse.
A HTTP interface is a very low-level thing, and clearly but one of the many moving parts that play a role in #ActivityPub based solution development.
Never defining this well, and having the documentation be scattered all across the fediverse in 1,001 random locations doesn't help. Meanwhile the dev talk that is going on for years remains very inefficient due to endless Babylonian speech confusion.
social.coop/@smallcircles/1161…
@cwebber @steve
🫧 socialcoding..
2026-02-21 15:59:23
General Discussion reshared this.
Evan Prodromou
in reply to 🫧 socialcoding.. • • •hey, Arnold.
I don't think argument from ignorance is a good way to have a discussion.
I chose to take you at your word that you didn't know what a "read-write API" is, and that you couldn't figure it out from context clues, so I dropped a link to Wikipedia.
What would you have done, if you were me?
General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •So why don't you use the word REST? I never encountered "read-write API". It is an informal term.
But that is not the point. You can have a REST API, fine. But that says nothing in itself. What does it expose? You might say "Duh.. ActivityPub!" but that is not very informative either. There is the notion of message exchange, and of an addressing mechanism, indicating higher level abstractions that conform to well-known architecture patterns, and would allow us to have more productive communication, delve less in implementation details and confusions of protocol behavior with solution design functionality, for starters.
Evan Prodromou
in reply to 🫧 socialcoding.. • • •I'm fine with that.
However, I think ActivityPub builds up persistent state on the server side which can be read and used by other processors.
For example, when I `Like` something, it goes into my `liked` collection, and the activity goes into the `likes` for that object. The `Like` activity goes into my `outbox` and others' `inbox`. People can review that information and use it.
General Discussion reshared this.
Evan Prodromou
in reply to Evan Prodromou • • •General Discussion reshared this.
Evan Prodromou
in reply to Christine Lemmer-Webber • • •thanks for that important clarification.
It does use message-passing, but not exclusively. I'll update my reply.
General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •Evan Prodromou
in reply to 🫧 socialcoding.. • • •awesome.
So, would you like me to review your diagram and give comments? I don't know what you're looking for from me in this conversation.
General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •Evan Prodromou
in reply to 🫧 socialcoding.. • • •General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •Evan Prodromou
in reply to 🫧 socialcoding.. • • •General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •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:
coding.social/blog/reimagine-s…
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.
How We Reimagine the Social Web
Social coding commonsnaturzukunft
in reply to 🫧 socialcoding.. • • •Evan Prodromou
in reply to 🫧 socialcoding.. • • •General Discussion reshared this.
Dr Kim Foale
in reply to Evan Prodromou • • •just to note this is the ballpark i've been working in for a little while now
gfsc.community/whats-happening…
What's happening where you live? Re-introducing PlaceCal
Dr Kim Foale (Geeks for Social Change)reshared this
🫧 socialcoding.. e General Discussion reshared this.
🫧 socialcoding..
in reply to Dr Kim Foale • • •Thank you, Kim! I enjoyed our chat, and really like your paper outlining Community Technology Partnership formal methodology, so lemme include the direct link below:
tandfonline.com/doi/full/10.10…
Dr Kim Foale
in reply to 🫧 socialcoding.. • • •Evan Prodromou
in reply to Evan Prodromou • • •That said, I think it would be great to have reverse chronological ordered collections of objects created by the actor.
It would be nice to use `streams` like `endpoints`, as an object, and define properties like `notes`, `images`, `places` and so on off of it.
Unfortunately the loose definition and lack of examples for `streams` makes it hard to use. It's probably better just to define them as top-level properties of the actor.
General Discussion reshared this.
Evan Prodromou
in reply to Evan Prodromou • • •I also agree that having a separate "home timeline" and "notifications timeline" makes sense. There's an open user story for that:
github.com/swicg/activitypub-a…
Separate notifications and home feed
evanp (GitHub)General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •The way I see it, this has the wrong stakeholder name of "ActivityPub API client developer" i.e. spec implementer, and a Home Feed is something I may want as a "Solution developer" stakeholder. In other words that library or SDK that offers me the Social API should allow me to model that.
The user story was also brought up by Mastodon, a Microblogging solution built on top of AP (ideally).
Evan Prodromou
in reply to 🫧 socialcoding.. • • •General Discussion reshared this.
Steve Bate
in reply to Steve Bate • • •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.)
swicg.github.io/activitypub-ap…
Server-Sent Events For the ActivityPub API
swicg.github.io🫧 socialcoding..
in reply to Steve Bate • • •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.
data-star.dev
Datastar
Datastar🫧 socialcoding.. reshared this.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •This is a nice video that demonstrates #EventSourcing with #Datastar + #SSE in a #Python context for the backend..
pyvideo.org/flaskcon-2025/deat…
Death to the spinner: event sourcing for reactive web apps
PyVideo.org🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •Note that there is an accompanying issue in the #ActivityPub API repository, where I transferred my reply to in the following comment:
github.com/swicg/activitypub-a…
I also added a very nice demonstration that is interesting for the #Mastodon folks, as it is using #Ruby in the event-sourced set up.
github.com/ismasan/sourced_tod…
Push delivery
evanp (GitHub)julian
in reply to Evan Prodromou • • •@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.
🫧 socialcoding.. likes this.
Evan Prodromou
in reply to julian • • •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.
Evan Prodromou
in reply to Evan Prodromou • • •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.
@smallcircles
General Discussion reshared this.
🫧 socialcoding..
in reply to Evan Prodromou • • •#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.
social.coop/@smallcircles/1160…
🫧 socialcoding.. reshared this.
julian
in reply to 🫧 socialcoding.. • • •@smallcircles@social.coop I feel personally called out for this 😛
cc @evan@cosocial.ca
🫧 socialcoding..
in reply to julian • • •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..
discuss.coding.social/t/major-…
Major challenges for the Fediverse
Discuss Social Coding🫧 socialcoding.. reshared this.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •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.
eventcatalog.dev/features/visu…
eventmodeling.org/
Visualize Your Architecture - EventCatalog
EventCatalogreshared this
🫧 socialcoding.. e General Discussion reshared this.
damon
in reply to 🫧 socialcoding.. • • •Create your first social app
Docs🫧 socialcoding..
in reply to damon • • •Thank you. Yes, indeed. As it happens I was just in chat with Sébastien yesterday. They'll give a presentation at the #Solid Practitioners Meetings on the 5th of March.
#ActivityPods is positioned to bring "app development" to the intersection of the #ActivityPub and #SolidProject ecosystems, and that is very valuable. And also an #OpenStandards focused initiative.
I have revamped the #fediverse delightful lists to de-emphasize app domains and apps that have already established themselves, to highlight the innovative projects that can bring fedi to higher levels. @activitypods is on the developer list.. delightful.coding.social/delig…
They are well positioned to offer the 'Solution developer' stakeholders an attractive set of tools. And the opportunity is to marriage the best of 2 worlds. Which is at the same time the big challenge, coping with the worst of 2 worlds. The other day I tooted about this here: social.coop/@smallcircles/1161…
delightful fediverse development
delightful.coding.social🫧 socialcoding..
2026-02-22 11:07:59
infinite love ⴳ
in reply to 🫧 socialcoding.. • • •if only the application domain of activitystreams was activities and streams... ;)
i do think it causes a lot of confusion to stray away from activities as content, instead using them as vehicles for state changes (which will never be consistent, not even eventually consistent).
back when atompub and atom+as1 were a thing, the "feed entry" was atom semantics and the "activity stream" was as1 semantics. they coexisted in the same xml file. it worked well enough.
reshared this
🫧 socialcoding.. e General Discussion reshared this.
🫧 socialcoding..
in reply to infinite love ⴳ • • •Yes, for the ideation on Protosocial as an #ActivityPub compliant extension (going back to the roots with blank slate W3C specs) I imagined mapping the AS primitives to consistent protocol capabilities and thereby define a set of normative architecture patterns, like "this is how we do CRUD, this is Publish/Subscribe, this is an Event stream and this a Collection", etc.
Then Protosocial library and SDK implementers would need to deal with #ActivityStreams at a low-level plumbing impl detail, while solution developers would have a higher-level API to invoke these patterns. And other than that would not need to touch #ActivityStreams which is now entirely reserved to making AP work on the wire.
A combination of linked data practices and schema-based design would be used for both open-world and closed-world extension modeling. But here too the solution developer should be shield from the nitty gritty internal mechanics.
reshared this
🫧 socialcoding.. e General Discussion reshared this.
Julian Fietkau
in reply to Evan Prodromou • • •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 docs.gotosocial.org/en/latest/…). 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?
Interaction Controls - GoToSocial Documentation
docs.gotosocial.orgGeneral Discussion reshared this.
Evan Prodromou
in reply to Julian Fietkau • • •infinite love ⴳ
in reply to Evan Prodromou • • •personally i think three things happen generally, which could each be described by their own activity in succession:
1) the original Activity is posted.
2) you can Accept or Reject the Activity.
3) as a result, you can Add or Remove the Activity to the corresponding AP collection.
this holds for Like and Announce 1:1. Follow we currently Add the Follow.object instead, but i think we ought to store the actual Follow activity in a follows collection.
General Discussion reshared this.
infinite love ⴳ
in reply to infinite love ⴳ • • •General Discussion reshared this.
infinite love ⴳ
in reply to infinite love ⴳ • • •infinite love ⴳ
in reply to infinite love ⴳ • • •infinite love ⴳ
in reply to infinite love ⴳ • • •infinite love ⴳ
in reply to infinite love ⴳ • • •General Discussion reshared this.
infinite love ⴳ
in reply to infinite love ⴳ • • •General Discussion reshared this.
Julian Fietkau
in reply to infinite love ⴳ • • •That's kinda what I'm getting at, yeah. The goal is to express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view. Followers and other observers are made aware this reply is accepted and can be shown similarly in other places that want to honor the poster's reply filters, so observers don't need to iterate over the replies collection all the time.
@evan @julian@activitypub.space @smallcircles
General Discussion reshared this.
Julian Fietkau
in reply to Julian Fietkau • • •The GTS interaction controls docs mention the replies collection, but only tangentially. For the purpose of conversation backfilling (which GTS doesn't do yet) I'm wanting to emphasize that the replies collection is the source of truth for replies curated by the object owner.
The Accept(Note) is essentially a hack to allow interactions from servers that don't implement GTS's ReplyRequest activity. I'll discuss with them how best to signal reply acceptance.
@evan @julian@activitypub.space @smallcircles
General Discussion reshared this.
infinite love ⴳ
in reply to Julian Fietkau • • •> express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view
i get that, but the question is whether you can claim this understanding universally for all peers. as it stands, Accept is very vague wrt this. Accept(Note) meaning "Add to replies collection" might be a thing gts does, but that's their interpretation of Accept, not the definition.
General Discussion reshared this.
infinite love ⴳ
in reply to infinite love ⴳ • • •> replies collection is the source of truth for replies curated by the object owner.
this is fine i think, but the way to do this usually is HTTP GET. you could notify of changes to the replies collection, or you could reify the Reply and then Accept that?
the Reply has an instrument which is the Note. it has clear side effects to Add the instrument to the object.replies. the side effects can be gated behind Accept/Reject like following currently works.
General Discussion reshared this.
infinite love ⴳ
in reply to infinite love ⴳ • • •infinite love ⴳ
in reply to infinite love ⴳ • • •reshared this
General Discussion reshared this.
Julian Fietkau
in reply to infinite love ⴳ • • •There's also this, yeah. GTS interaction controls have already gone through one breaking schema revision from version 0.19 to 0.21 (with 0.20 trying to manage both), and a core goal of the FEP I'm working on is to not break compatibility again.
Sending out an Add in addition to the Accept(Note) that's already happening should be non-breaking for existing implementations, I'm pretty sure. What's left to decide is whether it's a good idea.
@evan @julian@activitypub.space @smallcircles
General Discussion reshared this.
infinite love ⴳ
in reply to Julian Fietkau • • •infinite love ⴳ
in reply to infinite love ⴳ • • •actor: alice
type: as:Accept, as:Add, _:ReplyAck
object: <the reply>
target: <the replies collection>
_:postRepliedTo: <op>
for the Accept, you need to understand it as "accepting the object into the target", which is apparently a thing in AS2-Vocab.
for the Add, you need to understand it as Add is defined -- no surprises there, i think?
for the ReplyAck, it can be whatever you define. here i've used an extension postRepliedTo property.
Julian Fietkau
in reply to infinite love ⴳ • • •The GTS implementation comes with a vocabulary extension, so adding another activity type would be an option.
I guess the reason they didn't do that for this case (I wasn't around for the decision) is that the Accept(Note) thing is itself a backward compatibility hack that they hoped to be able to drop eventually, when more servers would send ReplyRequests (which can be Accept-ed directly), and adding a new type would have felt too much like “enshrining” it.
@evan @julian@activitypub.space @smallcircles
infinite love ⴳ
in reply to Julian Fietkau • • •Julian Fietkau
in reply to infinite love ⴳ • • •julian
in reply to Julian Fietkau • • •@julian@fietkau.social in a parallel conversation not about interaction controls, @rimu@piefed.social made the case for batching events, which I'm going to repurpose as an argument against sending additional activities for backward compatibility (unless absolutely necessary.)
> As a user can do a great number of notable things (posting content, liking content, following others) each minute and there can be thousands of instances to send to, a great many POST requests can be sent in a short amount of time.
>
> For example if 5 people cast 20 votes and there are 500 instances, the instance hosting the community containing the posts being voted on must send 5 * 20 * 500 = 50,000 HTTP POSTs.
Julian Fietkau likes this.
Julian Fietkau
in reply to julian • • •I'm doing my best to realistically prioritize traffic load as well, yeah. The case of accepting an incoming reply will be frequent, whereas the one where you first accept a reply, then change your mind and revoke the acceptance, would be expected to be relatively rare.
The easy way out for me would be to just not touch that part of the spec, leave it as Accept(Note), and see what implementers do with it.
@rimu
Julian Fietkau
in reply to infinite love ⴳ • • •This is in the context of a FEP draft which prescribes a meaning (including desired side effects) for compliant implementations.
Hence my fidgeting with the vocabulary. The effects are the goal, the question is how they should be expressed and broadcasted. (Principle of least surprise, potential compatibility with existing implementations that look at the replies collection, concerns around server traffic...)
@evan @julian@activitypub.space @smallcircles
infinite love ⴳ
in reply to Evan Prodromou • • •> use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
i'm tracking inbox items and outbox items as separate from the activity content/payload. no source release yet but the idea is that inboxes receive "notifications" instead of "activities". notifications have their own timestamps so receiving a notification whose activity content claims to be in the future/past won't cause any confusion for readers.
Evan Prodromou
in reply to julian • • •We actually have a meeting tomorrow if either of you wants to come.
w3.org/events/meetings/3432cf4…
19 February 2026 | ActivityPub API Task Force Meeting | Calendar
W3CSean Tilley likes this.
Sean Tilley
in reply to Evan Prodromou • • •Evan Prodromou
in reply to Sean Tilley • • •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.
General Discussion reshared this.
django
in reply to Evan Prodromou • • •#Bonfire #FedBox #Fedify #Emissary
Sean Tilley likes this.
Sean Tilley
in reply to django • • •Sam Clemente
in reply to Evan Prodromou • • •@evan
Definitely interested in a universal client-server API for my own app
That was a partial hurdle to originally creating it until I decided to bite the bullet and build on the Mastodon API for now (since that's where my Social Web account lives)
General Discussion reshared this.
Sean Tilley
in reply to Sean Tilley • • •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
in reply to Sean Tilley • • •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.
wakest ⁂ reshared this.
Sean Tilley
in reply to Sean Tilley • • •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.
Sean Tilley
in reply to Sean Tilley • • •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
in reply to Sean Tilley • • •@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 likes this.
Sean Tilley
in reply to julian • • •@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?
🫧 socialcoding..
in reply to Sean Tilley • • •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.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •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.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •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.
🫧 socialcoding.. reshared this.
Emelia 👸🏻
in reply to 🫧 socialcoding.. • • •- declaring moderation actors
- supporting content labels (first party abd third party)
- looking at how custom feeds, DIDs and other tech may translate across
🫧 socialcoding..
in reply to Emelia 👸🏻 • • •@thisismissem
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.
Ricardo Antonio Piana likes this.
🫧 socialcoding.. reshared this.
Emelia 👸🏻
in reply to 🫧 socialcoding.. • • •Sean Tilley likes this.
Sean Tilley
in reply to Emelia 👸🏻 • • •Stefan
in reply to Sean Tilley • • •What's broken on the Fediverse, explain?! 🤔
#ActivityPub #Fediverse
Michael 🇺🇦
in reply to Sean Tilley • • •Evan Prodromou
in reply to Michael 🇺🇦 • • •General Discussion reshared this.
Michael 🇺🇦
in reply to Evan Prodromou • • •Theoretically I'm interested in stuff like that. But on the other hand I suffer from a really short attention span and mostly I'm not able to follow lengthy conversations without losing focus.
But I can provide what I expect from an API, so that consider it fully usable.
moggie
in reply to Sean Tilley • • •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
in reply to moggie • • •@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.