I think the #ActivityPub client-to-server API is extremely important and underrated.
Fediverso
87
Posts
11
Posters
46
Views
-
@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...
-
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.
@steve @smallcircles I also agree that having a separate "home timeline" and "notifications timeline" makes sense. There's an open user story for that:
-
@steve @smallcircles I also agree that having a separate "home timeline" and "notifications timeline" makes sense. There's an open user story for that:
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).
-
> 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.
@smallcircles @steve 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.
-
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).
@smallcircles @steve please comment on the issue!
-
@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...
@mariusor @smallcircles @evan C2S has client-side and server-side aspects (different, but overlapping, behavioral requirements, etc.). Both sides consume *and* produce AP data (pull and push for S2S, currently only pull for C2S). Fetching AP data (URI dereferencing) is common to both C2S and S2S.
-
@mariusor @smallcircles @evan C2S has client-side and server-side aspects (different, but overlapping, behavioral requirements, etc.). Both sides consume *and* produce AP data (pull and push for S2S, currently only pull for C2S). Fetching AP data (URI dereferencing) is common to both C2S and S2S.
@steve @mariusor @smallcircles @evan this is a huge thread, but off-cuff comment: C2S will need a "proxy" where you can fetch a remote object **with** identity/authentication
-
@smallcircles @steve 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.
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.
-
@steve @mariusor @smallcircles @evan this is a huge thread, but off-cuff comment: C2S will need a "proxy" where you can fetch a remote object **with** identity/authentication
@thisismissem @steve @mariusor @smallcircles @evan
Just checking my memory.. this concept exists already, yes?
https://www.w3.org/wiki/ActivityPub/Primer/proxyUrl_endpoint
Are you just saying that the new API spec should include this? Or am I missing something?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@steve @mariusor @smallcircles 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`.
-
@smallcircles @steve I understand that people make their own metaphors for how AP works.
-
@smallcircles @steve 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.
-
@benpate @thisismissem @steve @mariusor @smallcircles
Yes, proxyUrl already exists. There's a use case here:
https://github.com/swicg/activitypub-api/issues/10
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.
-
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.
-
@thisismissem @steve @mariusor @smallcircles @evan
Just checking my memory.. this concept exists already, yes?
https://www.w3.org/wiki/ActivityPub/Primer/proxyUrl_endpoint
Are you just saying that the new API spec should include this? Or am I missing something?
-
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.
-
@steve @mariusor @smallcircles @evan this is a huge thread, but off-cuff comment: C2S will need a "proxy" where you can fetch a remote object **with** identity/authentication
