ActivityPub client developer experience is something like this.

[django@social.coop]

ActivityPub client developer experience is something like this.

Building a coherent feed with stateful objects requires comparing an Activity from the inbox, with what’s in your outbox.

#ActivityPub #c2s #DevEx

[django@social.coop]

Of course implementations may vary but the spec isn’t clear, so let’s improve this, yeah! https://github.com/swicg/activitypub-api/issues/52

[django@social.coop]

There isn’t anything that says my server should return the latest known state of a post, including my interactions with it.

And sure, I can refetch any activity from the inbox via proxyUrl (except non-public), but nothing guarantees my server will add the current remote state of a post to its internal representation and return this.

So this forces a thick client situation, to have what should be fairly standard User Experience.

[mariusor@metalhead.club]

> There isn’t anything that says my server should return the latest known state of a post, including my interactions with it.

@django yes there is. When a client fetches the ID of an object, be it activity or regular Note/Article/Image/etc you receive the "canonical version" of that object. All the interactions that were ever operated on that object should be reflected on its representation. I think you're overcomplicating things...

[django@social.coop]

@mariusor ok, and what if the remote server doesn’t expose a likes endpoint? (the server may just not support, or the actor hides it)

Or even if it does, you have to get the collection page to find your actor. And that’s just likes, now add Announces, Bookmarks, and the whole context and reply chain.