@navi they tried to make a unified server <> client protocol once... But thats not a good idea since every server/client has different flavors/advantages so a unified API would prevent customizations...

> the client api is used to render the same info available from the ap api
Thats oversimplified... Yes, in the end, a post is the same. 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.

> just that many servers have auth_fetch on the ap one, and no auth on the client one
Thats very different from my experience tho. 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...

> with just makes the auth in the ap one kinda useless for stopping malicious actors
i agree on that and im in the opinion that it doesnt make sense to turn on auth_fetch at all... I do have that controversal opinion because it only makes sense in a environment where you have a whitelist instead of a blacklist.
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.
The whole purpose of the fediverse is to share informations public and there is pretty much no way around that