@Jain

> But thats not a good idea since every server/client has different flavors/advantages so a unified API would prevent customizations...

nop, that's what one can use ap extensions for (json-ld is good in making different stuff interoprate, if that is what is wanted, that's why it's used), or if you really must, make api points for your unique stuff, but let ap handle the objects of the core protocol

> But let me make an example: if you wana look at a post/object, the whole conversation will be loaded at once. If you would make the server more stupid, the client would have to query anything manually.

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-inreplyto
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies

those two already cover loading an entire conversation on a single get request (get the post you wanna render, and you get what it is a reply to, and stuff that replies to it)

> Take for example the configuration of blob.cat. We allow an unauthentic user to query the public timeline. We also allow to query the conversation of a whole thread, but in a very limited way. Many other instances prevents to load anything if you are not authenticated...

this all can be done via just... returning different stuff from the ap api, depending on auth, and https://w3c-ccg.github.io/zcap-spec/ might make this easy with capabilities (i need to read the spec in full, but it looks like it does)

> Beside of that, if you look at it from a IT Security Perspective, you have to assume that even if you lock down the ap api, lock down the client api, use a whitelist, that still posts of your instance could be found on unlocked client apis on a server which you federate with.

this could be mitigated if the way client operate were to go to the origin to get the full definition of objects, not one's cached/federated home server. tho about this, i like and dislike this approach, and i'll elaborate on that later when i am a bit deeper into developing libactivity