5 ms·

Matrix is a lot better than every proprietary service, but it's poor XMPP compliance currently makes it impossible to have essential features like encrypted com

by zaik 5y ago

Matrix is a lot better than every proprietary service, but it's poor XMPP compliance currently makes it impossible to have essential features like encrypted communications or adding Matrix users to multi-user chats.

Arathorn 5y ago
Unfortunately XMPP<->Matrix end-to-end encryption is a contradiction in terms. You have to speak the same protocol from end-to-end, otherwise you'd have to break the end-to-end encryption to translate from one protocol to the other. The closest you could get would be to run the Matrix<->XMPP bridge clientside alongside your Matrix client... but at that point you might almost as well be running a multihead messenger that speaks both Matrix & XMPP. In terms of adding Matrix to MUCs; i believe we're working on it in Bifrost, which is in active albeit slightly sporadic dev: https://github.com/matrix-org/matrix-bifrost https://github.com/matrix-org/matrix-bifrost.
- ZoomZoomZoom 5y ago
  > but at that point you might almost as well be running a multihead messenger that speaks both Matrix & XMPP. Yes please! There's sooo much work people put in the clients, and there are multitude of them for each network. I understand they are different and a specialized client may be better suited for unique protocol features, but I also think there should be more general clients with protocol plugins, as it was with Pidgin, Miranda and such.
- zaik 5y ago
  > Unfortunately XMPP<->Matrix end-to-end encryption is a contradiction in terms. You have to speak the same protocol from end-to-end, otherwise you'd have to break the end-to-end encryption to translate from one protocol to the other. You'd only have to speak the same encryption protocol. There already exists standards like the Signal protocol (on which OMEMO builds) or OpenPGP (which many XMPP clients support besides OMEMO). If messages can cross the border, so can public keys and encrypted messages.
  - Arathorn 5y ago
    Unfortunately this isn't true. Olm (Matrix's encryption protocol) is the same as OMEMO, which in turn is the same as libaxolotl. In fact, the OMEMO XEP even recommended Olm as an implementation for OMEMO at one point due to licensing concerns with libaxolotl/libsignalprotocol! But the fact that both protocols use the same E2EE encryption protocol doesn't help you with interoperability - given that you have to break that E2EE in order to convert between Matrix & XMPP; either on the server (ugh, defeats the whole point of E2EE) or on the client (ugh; you might as well just have a multiheaded messenger).
    - zaik 5y ago
      I'm not sure I understand. If in fact the same underlying encryption protocol is used, why can I not retrieve the public key of a Matrix user, encrypt the message and send it? Nothing here requires the server to break E2EE.
      - ThatGeoGuy 5y ago
        Because the message format is different. In XMPP, the message is an XML document according to the message schema. In Matrix, it's JSON. You can exchange the private keys, but using what format? Once that's done, you can encrypt XML on one side, but Matrix has to convert it into JSON on the other (in its own, separate format with its own fields). This can be done on the server side after decryption (no more E2EE), or on the client side (after decryption). In the latter case, you're not running a bridge anymore, you're just running an ad-hoc client for XMPP inside your matrix client.
        larma 5y ago
        In XMPP, encrypted messages can either contain encrypted XML > <message type="chat"><body>Hi there!</body></message> or raw text > Hi there! In Matrix, it's always encrypted JSON > {"type": "m.room.message", "content": {"msgtype": "m.text", "body": "Hi there!"}} It would be possible for Matrix to indicate that a room is a "raw room" and that clients should send and expect raw messages in that room - losing a few features on the go. Such raw room could be bridged over to XMPP fully end-to-end-encrypted (with small changes on either side to adjust for the differences between OMEMO and OLM). But I doubt anyone at Element will invest time into doing it and for the XMPP side it's much more work to do it "on their own" (by implementing parsing support for the encrypted JSON of Matrix as shown above). Having raw text in the encrypted content is by the way still the normal way how things work in XMPP world and is supported by every client doing E2EE - because it is basically free to implement (barely any additional code needed).
- approxim8ion 5y ago
  > You have to speak the same protocol from end-to-end, otherwise you'd have to break the end-to-end encryption to translate from one protocol to the other. Why is this any different from WhatsApp, which has a Matrix bridge? Or does that break encryption too?
  - IceWreck 5y ago
    I have no idea how the Whatsapp bridge works but it cant be end to end encrypted. Matrix to whatsapp bridge can be encrypted, whatsapp bridge to whatsapp can be encrypted, whatsapp to whatsapp is encrypted. But you have to break the chain at some point between matrix and whatsapp. Encrypted != End to End Encrypted.
    - approxim8ion 5y ago
      Seems to be my understanding as well.

by zaik 5y ago

Arathorn 5y ago

Unfortunately XMPP<->Matrix end-to-end encryption is a contradiction in terms. You have to speak the same protocol from end-to-end, otherwise you'd have to break the end-to-end encryption to translate from one protocol to the other. The closest you could get would be to run the Matrix<->XMPP bridge clientside alongside your Matrix client... but at that point you might almost as well be running a multihead messenger that speaks both Matrix & XMPP. In terms of adding Matrix to MUCs; i believe we're working on it in Bifrost, which is in active albeit slightly sporadic dev: https://github.com/matrix-org/matrix-bifrost https://github.com/matrix-org/matrix-bifrost.

ZoomZoomZoom 5y ago
> but at that point you might almost as well be running a multihead messenger that speaks both Matrix & XMPP. Yes please! There's sooo much work people put in the clients, and there are multitude of them for each network. I understand they are different and a specialized client may be better suited for unique protocol features, but I also think there should be more general clients with protocol plugins, as it was with Pidgin, Miranda and such.
zaik 5y ago
> Unfortunately XMPP<->Matrix end-to-end encryption is a contradiction in terms. You have to speak the same protocol from end-to-end, otherwise you'd have to break the end-to-end encryption to translate from one protocol to the other. You'd only have to speak the same encryption protocol. There already exists standards like the Signal protocol (on which OMEMO builds) or OpenPGP (which many XMPP clients support besides OMEMO). If messages can cross the border, so can public keys and encrypted messages.
- Arathorn 5y ago
  Unfortunately this isn't true. Olm (Matrix's encryption protocol) is the same as OMEMO, which in turn is the same as libaxolotl. In fact, the OMEMO XEP even recommended Olm as an implementation for OMEMO at one point due to licensing concerns with libaxolotl/libsignalprotocol! But the fact that both protocols use the same E2EE encryption protocol doesn't help you with interoperability - given that you have to break that E2EE in order to convert between Matrix & XMPP; either on the server (ugh, defeats the whole point of E2EE) or on the client (ugh; you might as well just have a multiheaded messenger).
  - zaik 5y ago
    I'm not sure I understand. If in fact the same underlying encryption protocol is used, why can I not retrieve the public key of a Matrix user, encrypt the message and send it? Nothing here requires the server to break E2EE.
    - ThatGeoGuy 5y ago
      Because the message format is different. In XMPP, the message is an XML document according to the message schema. In Matrix, it's JSON. You can exchange the private keys, but using what format? Once that's done, you can encrypt XML on one side, but Matrix has to convert it into JSON on the other (in its own, separate format with its own fields). This can be done on the server side after decryption (no more E2EE), or on the client side (after decryption). In the latter case, you're not running a bridge anymore, you're just running an ad-hoc client for XMPP inside your matrix client.
      - larma 5y ago
        In XMPP, encrypted messages can either contain encrypted XML > <message type="chat"><body>Hi there!</body></message> or raw text > Hi there! In Matrix, it's always encrypted JSON > {"type": "m.room.message", "content": {"msgtype": "m.text", "body": "Hi there!"}} It would be possible for Matrix to indicate that a room is a "raw room" and that clients should send and expect raw messages in that room - losing a few features on the go. Such raw room could be bridged over to XMPP fully end-to-end-encrypted (with small changes on either side to adjust for the differences between OMEMO and OLM). But I doubt anyone at Element will invest time into doing it and for the XMPP side it's much more work to do it "on their own" (by implementing parsing support for the encrypted JSON of Matrix as shown above). Having raw text in the encrypted content is by the way still the normal way how things work in XMPP world and is supported by every client doing E2EE - because it is basically free to implement (barely any additional code needed).
approxim8ion 5y ago
> You have to speak the same protocol from end-to-end, otherwise you'd have to break the end-to-end encryption to translate from one protocol to the other. Why is this any different from WhatsApp, which has a Matrix bridge? Or does that break encryption too?
- IceWreck 5y ago
  I have no idea how the Whatsapp bridge works but it cant be end to end encrypted. Matrix to whatsapp bridge can be encrypted, whatsapp bridge to whatsapp can be encrypted, whatsapp to whatsapp is encrypted. But you have to break the chain at some point between matrix and whatsapp. Encrypted != End to End Encrypted.
  - approxim8ion 5y ago
    Seems to be my understanding as well.