4 ms·
Even if Rocket.Chat used the same E2EE scheme as Matrix, you would still have to re-encrypt, given the application-layer protocols are not the same. RC's messa
by Arathorn 4y ago
Even if Rocket.Chat used the same E2EE scheme as Matrix, you would still have to re-encrypt, given the application-layer protocols are not the same. RC's messages are a blob of JSON which looks nothing like Matrix's JSON events. To preserve E2EE throughout you'd have to speak precisely the same protocol - e.g. Matrix+Megolm or XMPP+OMEMO or whatever, or effectively run a multihead stack (one which can speak both Matrix & Rocket.Chat), which isn't exactly elegant.
This is the disadvantage of bridges, alas: if you want E2EE, you need to be on the same protocol throughout.
- CameronNemo 4y agoYou can run bridges on the client, but that is not well supported right now.
- Arathorn 4y agoTrue, although this is one step away from being a multihead messenger, effectively. It's just that the protocol-specific modules are daemons using a standard API rather than in-process. For instance, I can't think of a way that one would run an Element Web<->Rocket.Chat bridge clientside, as web browsers can't use local web services, short of a service worker... but by the time you're running a dedicated service-worker for a webapp which lets it talk to another webapp, it's basically become a multihead msgr.
- jeroenhd 4y agoI believe the eventual intention is to run a bridge in the client, allowing for perfect secrecy. Matrix itself is showing signs of running a homeserver on every client (though that's still experimental). Both projects are still a long way away, though. To be fair, though E2EE is perfect for a general purpose messenger, I don't think it's necessary per se. Group chats that would normally appear on IRC don't have a need for E2EE (and verifying everyone in a public room is also extremely impractical!) which seems like a perfect use case for this integration.