From the user's point of view, authorizing some other user to read something doesn't mean authorizing whoever runs that user's instance to read it. If your protocol has an architectural problem with that, it means you designed your protocol wrong.
> From the user's point of view, authorizing some other user to read something
You keep using the singular "user", but the posts in question are not messages between one user and one other user but rather "followers only", such that anyone who follows the account is authorized to read the post.
> doesn't mean authorizing whoever runs that user's instance to read it.
That wasn't even the issue.
Maybe instead of just propagating authenticated cleartext data to unknown servers, users should get that data directly from the authenticating server?
We replicate public posts to reduce server load. Your server can rebroadcast my message to your 10k users instead of my server handling those 10k requests. But doing this for private data you need to be logged in to access is unnecessary and dumb. I have a perfectly fine server that is trustworthy. I want to send some private data to a single individual. So obviously I send that data off in plaintext to some random third server which I must assume is as trustworthy as my server so it can relay that data to (hopefully) only the recipient.
I expect that if I send private data to one user, it goes to that user and no one else. The fact that the only thing stopping a foreign server from publicly posting my private data for everyone is a "please don't" flag on the packet. Does this sound like a well designed and robust protocol?