[stebalien]

It's a stop-gap because people want DMs and implementing them correctly (decentralized, e2e encrypted, etc.) is non-trivial. Rushing e2e encryption is not a good idea (and no, you can't just slap on matrix/signal and call it a day).

The alternatives are to:

1. Wait a bit longer for something half-baked that appears to meet the goals (i.e., something you're going to regret but will be unable to replace). 2. Wait even longer for something perfect.

By making the protocol centralized and stupid-simple, it's also stupid-simple to replace in when everyone is done painting the perfect bikeshed.

[pavel_lishin]

> By making the protocol centralized and stupid-simple, it's also stupid-simple to replace in when everyone is done painting the perfect bikeshed.

But we all know that the more temporary the fix, the more permanent it becomes.

[stebalien]

In my experience, temporary fixes are more likely to "stick" the better they are at addressing the problem. The fact that nobody is satisfied with this fix is a good sign.

[MyFedora]

There is nothing more permanent than a temporary solution.

[neiman]

> By making the protocol centralized and stupid-simple, it's also stupid-simple to replace in when everyone is done painting the perfect bikeshed.

Can you recall any example of anyone replacing a centralized protocol with a decentralized one?

[ncallaway]

Didn’t Bluesky ship centralized, and then later replaced the centralized protocol with the decentralized at proto?

[neiman]

Did they? Heh, I didn't know that. But I thought they launched with the AT protocol already, no?

[ncallaway]

They did, which is why it seems like a relevant example to your question. They shipped centralized, and have already replaced the centralized service they shipped with a decentralized service.

[threeseed]

Threads sits on top of the Instagram infrastructure.

And they have added ActivityPub integration moving everything closer to decentralisation.

Given how much of a win-win for Meta it is it wouldn't surprise me to see all their networks move in that direction.

[troupo]

> Given how much of a win-win for Meta

How much?

> to see all their networks move in that direction.

Why would they? What exactly will the move entail?

[threeseed]

a) They can monetise content that didn't originate on their platform.

b) It shifts regulators attention from them to closed platforms like X.

c) They can leverage their advantages e.g. ad serving, safety to push competitors into niches.

[troupo]

> They can monetise content that didn't originate on their platform.

They have been doing it for years.

> It shifts regulators attention from them to closed platforms like X.

It doesn't. Threads is just as closed (despite integrating an open protocol), and is still subject to the same scrutiny and provisions as the rest of Meta's products.

> They can leverage their advantages e.g. ad serving, safety to push competitors into niches.

So, let me get it straight. Facebook gained so much from adopting a decentralized protocol so they will inevitably move in the same direction that:

- they will use it to remain the only centralized service?

- they will use it to do the same thing they do before (serve ads, collect user data etc.) but somehow will be absolved of regulations and scrutiny?

[mgraczyk]

Facebook messenger is not completely decentralized, but it is E2E encrypted now after years of struggle with governments and UX. It's definitely possible to move centralized systems to be more decentralized.

[rglullis]

How is that an answer to the question?

[mgraczyk]

It's an example of somebody replacing a centralized protocol with a more decentralized one. It's also one of the biggest direct messaging platforms in the world with E2E encryption.

[troupo]

How is it decentralized? It's running from and through Facebook servers.

[mgraczyk]

Facebook cannot read your messages, so it is more decentralized than a system that stores messages in plaintext (or stores the decryption keys).

[wmf]

Bluesky.

[o11c]

e2e encryption is a net loss for a lot of use cases. Particularly, most DMs are spam in my experience.

Spam prevention is much harder if the server can't see the message. Spam reporting can be done with sufficient effort, but stopping the known spam from reaching the user in the first place is impossible (the closest you can get is a client-side scan before actually showing the message to the user, which requires downloading the whole message just to show "number of incoming messages" indicator or else having the indicator lie).

And of course, E2EE is a lie if you're visiting a website anyway.

[derefr]

It is my understanding that many E2EE chat systems won't actually E2EE your initial message to someone you aren't already mutual in-app contacts with.

Either E2EE is something you "upgrade" an existing conversation into (only after both sides consent to the conversation); or E2EE is something that only inherently establishes once both sides have sent one-another a message; or E2EE is something you can only enable before you start a conversation, if you already have the other person's public key (which you only get when you request to add them as a contact, and they accept.)

I think schemes like this balance privacy with spam-prevention quite well: privacy-conscious people can explicitly add each-other before either person says anything / can send intentional small-talk as pairing messages; while everyone else gets the benefit of a central spam-filter sitting between them and messages from strangers.

[noman-land]

Except they'll never replace it because they'll be too busy making some other feature stupid simple by centralizing it and we'll be back to centralized social media.