Either encrypt it such that only the authorized user can read it, or require the authorized user to retrieve it directly. Or don't lead users to expect that you're offering any privacy.

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.

I would expect that only authorized users can access authenticated data and that we don't blindly assume a foreign server is 110% trustworthy at all times.

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?

One would hope that a protocol designed in 2018 would have more security than email.

> How is that different from email?

Expectations have evolved just a bit since 1982. We've learned things. Competent protocol designers don't ignore decades of improvement in the state of the art.

Also, and/or as part of that--

1. Email was expected to be mostly business email, and the operator of the instance was expected to be the business involved... meaning they were fairly likely to "own" the content anyway. Insofar as people were thinking about personal email, the expectation was that, in the long term, you'd be running your own server. Which you should still be doing.

2. Even if that broke down, you at least expected that the person you were sending mail to had some much closer relationship with their server operator than you usually do with a social media operator. Or with GMail.

3. Users were much more sophisticated and could reasonably be expected to understand the risks.

4. Nobody actually expected there to be all that much "embarrassing" content that people wanted to keep private.

5. Cryptography was far less widely understood, and most people thought it was legally risky to use it because of export controls and various government threats.

6. Nobody was offering a security setting and then failing to deliver on the obvious expectation it created.

> It would be a scandal if a popular mail server implementation allowed any account on the server to read private emails.

Indeed. And what Pixelfed is doing is also bad. That doesn't change the fact that the protocol is a bad design... unforgiveably bad any time after about 2000.

That's not how it should work though. The post should get encrypted only once with a symmetric key i.e. AES, and then this gets encrypted with each of the followers' public keys. So it's not the post itself but the encryption key that must be scaled. This is how PGP-encrypted E-mail works.

Oh! This is about posts! Sure, otherwise it's not private really.

> if you have 10k followers you’re proposing to encrypt every post 10k times?

I mean, yes. Why you’re sending a “private” post to ten thousand people is another question.