I think the #ActivityPub client-to-server API is extremely important and underrated.
Fediverso
94
Posts
11
Posters
61
Views
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles alternatively add the Reply itself, parallel to likes/shares collections. it depends on whether you think the replies collection should always contain a specific type of object, which i don't think is something you can guarantee because publishers can do anything with it. similar to how some publishers include activities in threads and some include notes.
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles i think the issue here is that projects are doing things that may or may not get widely adopted, then if the proposals ever change, they have to deal with older software only understanding the old thing they tried. (this is where i would say something about protocol capability negotiation)
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles
> 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.
@trwnh 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...)
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles i think the issue here is that projects are doing things that may or may not get widely adopted, then if the proposals ever change, they have to deal with older software only understanding the old thing they tried. (this is where i would say something about protocol capability negotiation)
@trwnh 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.
-
@trwnh 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.
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles this makes me really wish people didn't overload the AS2 vocab so much, and were less afraid of defining their own extensions. you could swing it so that the same activity is an Add, Accept, and ReplyAck. it sucks that we have to pick one instead of using whatever makes sense. (developers: please support multityping and/or duck typing! composability is the only true path to extensibility, and one size never fits all...)
-
@trwnh 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.
@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. -
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.
@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.
-
@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 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.
-
@steve 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.
@mariusor @smallcircles @evan I’m not sure I completely follow. A timeline is ordered by time. I agree that an unordered collection could be sorted by time to create a timeline. The AP OrderedCollection “stream” is a kind of rigid presorting that anticipates what an AP client would want. However, I also agree that even those could be reordered (by time or otherwise) and/or filtered in the client to provide custom views of the activity stream.
-
@mariusor @smallcircles @evan I’m not sure I completely follow. A timeline is ordered by time. I agree that an unordered collection could be sorted by time to create a timeline. The AP OrderedCollection “stream” is a kind of rigid presorting that anticipates what an AP client would want. However, I also agree that even those could be reordered (by time or otherwise) and/or filtered in the client to provide custom views of the activity stream.
@steve 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.
-
@steve 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.
@mariusor @smallcircles @evan Yes, it can be done in the client or the server, or both. I’d like to see an interoperable way to define custom timelines (a kind of user-defined timeline algo) that the server maintains. A Mastodon account list timeline is a super simple version of it, but AP could provide something much more powerful (advanced filtering, merging, ranking, …). Ideally, these could be shared and customized further on the client side.
-
@mariusor @smallcircles @evan Yes, it can be done in the client or the server, or both. I’d like to see an interoperable way to define custom timelines (a kind of user-defined timeline algo) that the server maintains. A Mastodon account list timeline is a super simple version of it, but AP could provide something much more powerful (advanced filtering, merging, ranking, …). Ideally, these could be shared and customized further on the client side.
@steve 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.
-
@steve 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.
@mariusor @smallcircles @evan I think you read something other than what I wrote. 😀. I’m describing *user-defined* timelines where the heavy lifting is done in a server. That server would be (or could be) *general purpose* and not specific to an activity domain. I definitely wasn’t suggesting a monolithic, tightly-coupled client/server architecture. I want my timeline definitions to be portable and interoperable.
-
@mariusor @smallcircles @evan I think you read something other than what I wrote. 😀. I’m describing *user-defined* timelines where the heavy lifting is done in a server. That server would be (or could be) *general purpose* and not specific to an activity domain. I definitely wasn’t suggesting a monolithic, tightly-coupled client/server architecture. I want my timeline definitions to be portable and interoperable.
@steve 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.
-
@steve 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.
> 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.
-
> 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.
@smallcircles @mariusor @evan C2S is described (too loosely, but…) in the ActivityPub spec. There is a client and server aspect to C2S. A C2S client is software that uses that protocol/API to interact with an ActivityPub C2S-capable server (general or domain-specific). When I refer to an ActivityPub Client, I mean software using C2S rather than consumers of ActivityPub-related data in general.
-
@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 @smallcircles 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.
-
@steve @smallcircles 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.
@steve @smallcircles I also agree that activities are more primary than content objects like notes and images in ActivityPub. That is by design and reflected in the name of the data format, API and federation protocol.
-
@steve @smallcircles I also agree that activities are more primary than content objects like notes and images in ActivityPub. That is by design and reflected in the name of the data format, API and federation protocol.
> 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.
-
@steve @smallcircles I also agree that activities are more primary than content objects like notes and images in ActivityPub. That is by design and reflected in the name of the data format, API and federation protocol.
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.
-
@smallcircles @mariusor @evan C2S is described (too loosely, but…) in the ActivityPub spec. There is a client and server aspect to C2S. A C2S client is software that uses that protocol/API to interact with an ActivityPub C2S-capable server (general or domain-specific). When I refer to an ActivityPub Client, I mean software using C2S rather than consumers of ActivityPub-related data in general.
@steve 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...
Gli ultimi otto messaggi ricevuti dalla Federazione
-
-
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
-
Week in Fediverse 2026-02-20
Servers
- snac v2.90
- Castopod v1.15.0
- Ktistec v3.3.0
- tootik v0.21.1
- Badgefed v0.1.1
- Gush! v0.0.30
- Wanderer v0.18.5
- PieFed v1.6.6
- Our technical direction (Mastodon)Clients
- Sengi v1.8.0
- tooi v0.21.2
- Summit v1.77.0
- Aria v1.4.3
- Pixelix v4.3.2Tools and Plugins
- feed2fedi v3.5.0
- PeerTube Browser: A video discovery project for the federated PeerTube networkProtocol
- FEP-34c1: Collection Filtering using TREE Hypermedia Vocabulary
Articles
- Where Does Community Live?
- Why MAEPs? What should they look like?
- how to not regret c2s
- Reimagining Fediverse Advocacy
- FR#154 – Search and Community-----
#WeekInFediverse #Fediverse #ActivityPub
Previous edition: https://mitra.social/objects/019c5906-05c0-87bf-8302-8226a8513c00
-
@mariusor 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 ¯\_(ツ)_/¯
-
@smallcircles @steve sure. I am not a fan of the idea that AP is a message-passing system; it's a read-write API.
-
@thisismissem 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
-
@evan @benpate @steve @mariusor @smallcircles 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
-
Rather than sharedInbox I was more thinking that by implementing the HTTP API and msg exchanges in a well-prescribed manner, these would effectively model an event bus conceptually. After which you can talk about it as a higher abstraction that exists, and not get lost in the reeds of the impl details anymore.
