Matrix for the win.
It already has interoperability with bridges.
Also you can self host and don’t need to disclose your phone number to a private company to use it.
Comment on Sweeping EU rules for tech giants take effect today. Here’s what’s changing | CNN Business
noodlejetski@lemm.ee 8 months ago
Users of messaging apps such as Signal or Viber, meanwhile, could soon be able to send chat messages directly to people who use Meta’s Messenger and WhatsApp platforms
Signal and Threema have already announced that they have no plans doing that.
Matrix for the win.
It already has interoperability with bridges.
Also you can self host and don’t need to disclose your phone number to a private company to use it.
I still don’t get why.
Because you can’t end to end encrypt if you don’t have control over both ends. You’d need to trust the other end. Signal doesn’t and their user base especially doesn’t.
Yes, sure, but why not simply point out that the communication between Signal and Whatsapp, for example, is not sufficiently encrypted? If someone doesn’t use Signal or Theema, you can only communicate with this person anyway if you use the corresponding app. That’s not any more secure. I just think that Signal & Co. could gain a lot of users if they also allowed (insecure) communication with other messengers. Encryption between users who both use Signal, for example, is not affected by this.
Yeah I really don’t get it. Signal even had something similar. They made it so you could use the app as an SMS client as well. All your contacts would show up and if they didn’t have a Signal account, you could just send them SMS’s. They removed the feature, but they can obviously do it.
Why do you need to control both ends for E2EE? Both ends need a public and private key to encrypt and decrypt messages. You need a method of key exchange. I would prefer to have an offline method (phone call, in-person) of validating a key (like iMessage and Signal have). But I don’t see a reason to need to control both ends.
Probably because different messaging platforms have different opinions on how to implement encryption, and those opinions are baked into their infrastructure at a pretty low level. If two platforms don’t support a common encryption system, the only way to move traffic between them is to decrypt and re-encrypt the data at the boundary between platforms, giving both platforms access to the unencrypted messages.
Mandating a common system for E2EE seems like a good step 2, but just getting them to exchange messages at all is a good first step that doesn’t require anyone to change their backend to support a different encryption mechanism.
Would it be technically impossible to implement such a feature if both companies would work together or is it just too much hassle?
OTR?
thehatfox@lemmy.world 8 months ago
A nice as it would be to have, I don’t get how the messaging interoperability is going to work in practice. The different platforms have many technical differences between them at the backend, and also mismatched user facing feature sets. Ironing all of the that out into some sort of common ground is going to be difficult, especially without it being very janky.
I wouldn’t be surprised if this is kicked into the long grass eventually.
DandomRude@lemmy.world 8 months ago
It would certainly be a technical challenge. But I think the utility would be very high. In my experience, it’s difficult to convince people to use an app like Signal if they can’t use it to communicate with their Whatsapp contacts (etc.).
Redex68@lemmy.world 8 months ago
It would probably just use RCS as the backend and have some different functionalities, they could easily just highlight “this person isn’t using Signal so chat features are limited”. Hell, Signal had exactly this when they made the app work as an alternative SMS client. They removed that feature, but it existed previously.
lolcatnip@reddthat.com 8 months ago
They all have the capability to support a UI where you type a message, hit send, and the message is delivered. This proves it’s possible to make and support an interface that hides all the backend complexity. If they don’t expose the same functionality through an API, it’s because they don’t want to, not because it’s too hard.
I’m sure there will be some features that aren’t fully supported across messaging platforms, but for basic use cases like sending a text or an image, there’s really no excuse.
Redex68@lemmy.world 8 months ago
It would probably just use RCS as the backend and have some different functionalities, they could easily just highlight “this person isn’t using Signal so chat features are limited”. Hell, Signal had exactly this when they made the app work as an alternative SMS client. They removed that feature, but it existed previously.
lolcatnip@reddthat.com 8 months ago
Nah, fuck RCS. There is no reason for a mobile carrier to be involved in anything besides voice calls and TCP/IP traffic. Any protocol that requires participation from carriers beyond delivering TCP/IP packets is broken by design. It’s like designing a water faucet that somehow can’t work without active cooperation from your local water company.
smileyhead@discuss.tchncs.de 8 months ago
Voice is also debatable.
VoLTE is such a mess. It requires OS, modem and phone operator to all work together, where I heard none of them is often to the spec. As of now voice calling should be a simple Internet based app, maybe with autoconfiguration to not break “inset SIM and done” habits.
maynarkh@feddit.nl 8 months ago
The big platform has to develop an open API to implement standard message, image and video traffic. No need for a common standard, as long as everyone can implement the eg. open Whatsapp API.
Appoxo@lemmy.dbzer0.com 8 months ago
The same way as users have set up a bridge between Matrix and discord.