Hi everybody, I’m new here.
I discovered ActivityPub recently. After reading the spec, I have a question concerning the inbox.
As far as I have understood, when the client is reading his inbox, he reads the activities that have been posted by a server in the exact same format. I find that quite surprising. For me, when the servers receives an activity, it performs some operation and when the client query the server, the response should have an Ad Hoc format specific for the client.
Did I miss something ?
C2S is about interoperability between any kind of Client and any kind of Server. What that looks like in practice is yet to be seen, but it means that yes the standard ActivityPub inbox payload is sent from the Server to Client and it is up to the Client to render each inbox item as it seems appropriate.
This would let any Client “just work” with Pleroma, PeerTube, Funkwhale (if they supported C2S) out of the box.
The C2S protocol basically replaces the REST paradigm and the custom APIs built with it.
Edit: A Client implementation, for example, could decide to use the inbox to construct a list of not-deleted-IRIs of objects, and then make an AP request fetching those objects and rendering them asynchronously.
A different Client implementation could render Activities directly (“Addison created this note: …”) in addition to the above.
A different client could cache and render Objects based only on what is received in Creates in its inbox.
Etc.
Nothing prevents a client from using specific APIs, but then they’re tied to specific ActivityPub software and are no longer pure C2S.
A different client could cache and render Objects based only on what is received in Creates in its inbox
Just to be sure to understand, the client you are talking about in this case is the “final client” (I mean the mobile device or the webapp reading the inbox) or the server receiving the message in the inbox ?
Well, that’s the theory part, in the way it’s implemented in Pleroma (Kroeg is another server with AP C2S but I haven’t used it, other AP server implementations do not have AP C2S but only their own API or a copy of another’s API) all activities are transformed to a Internal Representation to simplify parsing of them (basically dynamically-typed structure in JSON-LD to a more statically-typed structure in JSON). And all clients are given the same activities, there is no negociation to know about clients anyway so no reason to give them different data.
As @cjs mentioned, the point of the Client to Server part of the ActivityPub spec is that servers should be interchangable, and clients hold the majority of the display logic. This is a design paradigm it shares with SMTP, among others. While only a few ActivityPub servers have implemented this part of the specification, the amount of choice and freedom this gives to users is really valuable.
Ok but I guess it also comes with a lot of limitation ?
For instance, in an application which allow private messaging between 2 users. If, as a client, I would like to display the 10 last messages + the total number of messages I have received (potentially large). That mean I have to increment a counter client side each time I read a message from the inbox to know the number of messages ?
This kind of thing is much more easy to manage on server side (because the messages are stored on server side and is the “source of truth”)
Yes. I tend to use “peer” when talking about S2S or federation.
I view this as a form of freedom. Your client can compute the last ten messages and stop processing. Another client can show everything reverse chronologically. Yet a different client can render only images and videos.
This is all independent of the server implementation. It does require more work in the client, possibly optimizations such as caching.
When fetching an inbox, it could return an OrderedCollectionPage for pagination. Unfortunately, I’m not sure there’s a C2S Server convention on the query parameters (such as length plus offset, or a continuation token) at that IRI to fetch a particular page of the inbox. Might be a good topic for a SocialCG discussion if it isn’t already.
Ok I think I get the point. It works like emails. For “complex” features, the mail client can also be a server (like gmail for instance) but in this case the final client (webapp, mobile app) is not the one that read the ActivityPub inbox.
[2019-11-26 16:54:09+0000] ayorosmage via SocialHub:
Ok so in this case the Activity is simplified (or enriched) by the server before sending it on the inbox. Is that right ?
If ActivityPub would be implemented like email is: yes.
In practice an activity is present only one time in the database and inbox content is generated by selecting the items according to the visibility (to/cc/…).