We definitely want to implement these features, the question was whether they should hold back releasing support for federation or not. Since federation is a core constraint on any features we'd like to build, the team felt that there is no reason to hold federation back, and that releasing it as it's ready makes sense.
We're thinking about Bluesky as both a product and a protocol (informing each other's design), and you're 100% right that for the end user, the product itself is what matters. Because we've taken on the decentralization constraint, we take longer to "catch up" to features that centralized platforms tend to have from the start, but it's definitely going to be a major area of focus for us going forward. (Ofc Mastodon isn't centralized, but note that it's had a few years of head start on feature development. We'll get there.)
For a decentralized protocol doing things right is much more important than doing things fast, it is very difficult (and in a lot of cases impossible) to break backwards compatibility.
DMs on any other service also have no privacy. Signal or Telegram could read your DMs by simply releasing an update to their code, for example. You always have to trust the person running the service you use. (Unless you have E2EE/something like OTR, in which case you have to trust the persom who makes that code!)
The whole point of end-to-end encryption is that you don't have to trust the people running the service you use.
If Signal releases a malicious update (and they don't provide reproducible builds), it is very much possible for you to know about it, as everything is on your device. Even if the binaries are different from the source code, decompilers, analyzing network traffic, etc. gives the community a good chance at catching malicious updates. Mastodon admins can simply pull up your plaintext DMs on their servers and no one will ever know.
> The whole point of end-to-end encryption is that you don't have to trust the people running the service you use.
Well then I guess it's pointless because it doesn't accomplish that.
(The actual point, FYI, is that you don't have to trust all of: them, their hosting providers, your ISP, the ISPs between, the government, and their mom.)
> it is very much possible for you to know about it
"Possible" != "done"
> analyzing network traffic
How are you gonna do that? Surely if they wanted to sniff it would still just look like any other encrypted data
> gives the community a good chance at catching malicious updates
Sure, when the same application is used by everyone, which is not true in either the Mastodon world or the new Bluesky-small-instances world
I think Mastodon has a pretty good balance here – when you try to send a DM it explicitly tells you that it will not be encrypted: https://u.ale.sh/Vo1ahx.png
And the linked privacy policy goes into further detail (at least on my instance, mstdn.io):
> Please keep in mind that the _operators of the server and any receiving server may view such messages_, and that recipients may screenshot, copy or otherwise re-share them. Do not share any sensitive information over Mastodon.
Overall, I think it's safe for most chit-chat, and for anything more serious you can add link to Matrix or your email and PGP key in your profile.
As a sidenote, I'd also like to point out that a lot of serious communication nowadays still happens over unencrypted email. You can consider it whataboutism, but it's still worth remembering IMO. (And of course, like others pointed out, DMs on Twitter aren't encrypted, too, so it's the status quo here.)
Just make ci releases with daily updates. Good luck reverse engineering and auditing that.
If the protocol is not open, you have to rely in the clients provided by the vendor, and you can slip a backdoor throigh easily.
When did you last audit your Signal client? Where is “the commjnity” organizing this effort and publishing the results?
Debian shipped an entropy lowering in house patch despite the “many eyeballs” fos years (for OpenSSL). Don’t lure yourself into false feeling of security bevause of the “community” might be doing something. Only count on defenses surely in place, with traceable operation and output history, with responsibles who are allocated resources for the work and having stakes at its outcomes.
I think it's sensible to have at the very least federation function as intended ahead of DM's as I imagine DM is another part pretty contingent on federation due to the privacy issues becoming approximately 10x more complicated with federation. ;-) Twitter is having it easy.
Videos might be more of a resource issue. Hardly a good time to launch videos almost at the same timeframe as they spike their user base by going public.
We're thinking about Bluesky as both a product and a protocol (informing each other's design), and you're 100% right that for the end user, the product itself is what matters. Because we've taken on the decentralization constraint, we take longer to "catch up" to features that centralized platforms tend to have from the start, but it's definitely going to be a major area of focus for us going forward. (Ofc Mastodon isn't centralized, but note that it's had a few years of head start on feature development. We'll get there.)