4 ms·

Ah yes. Which version of OMEMO are you going to use? Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE ver

Ah yes. Which version of OMEMO are you going to use? Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE versions of OMEMO. There's the original OMEMO version from the Android client Conversations and the Gnome client Dino, the newer OMEMO:1 which is used by the Windows client UWPX, and the newer OMEMO:2 that is used by the KDE client Kaidan. NONE of the different versions can even talk to each other. I have Jabber clients that talk the protocol from BEFORE it was standarized as XMPP, and they can still talk just fine with a client from this year. However, a client talking OMEMO from 4 years ago cannot talk to a client talking OMEMO from this year. I join the sibling commenter in saying "PLEASE, NO MORE IDEAS WE HAVE ENOUGH".

MattJ100 2y ago
> Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE versions of OMEMO. This is false. You can see the reality in this data (excuse the URL): https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++software.name%2C%0D%0A++xeps.number+as+xep_num%2C%0D%0A++xeps.title+as+xep_name%2C%0D%0A++xep_version+as+implemented_xep_version%0D%0Afrom%0D%0A++implementations%0D%0A++join+xeps+on+implementations.xep_id+%3D%3D+xeps.id%0D%0A++join+software+on+implementations.software_id+%3D%3D+software.id%0D%0Awhere%0D%0A++xeps.number+%3D+384%0D%0Aorder+by%0D%0A++implemented_xep_version%3B https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++softwar... As you can see, practically all clients are on the same version (0.3). The outliers are UWPX and Kaidan, which both took the unusual decision of being incompatible with the rest of the ecosystem without working on the upgrade path. UWPX is not actively maintained (no releases for a couple of years, and the Github repo is archived). That leaves Kaidan, which is (as far as I know) actively maintained and they deliberately chose to be incompatible with the rest of the ecosystem (for now). I agree it's an unusual choice, but the XMPP ecosystem is diverse and not centralized and nobody can control what people want to do with their time spent working on their open-source projects. EDIT: To clarify some things that are probably non-obvious to people outside the XMPP sphere, the link I gave shows Prosody and Mongoose as supporting OMEMO 0.8.3. They are not clients, but servers - they are compatible with all versions of OMEMO and so are not relevant when it comes to interoperability. And QXmpp is the backend library of Kaidan, by the same developers.
- AshamedCaptain 2y ago
  How is this false? The clients I mentioned cannot talk with each other, and your page is showing exactly that. You then say UWPX is discontinued as an excuse, which I could accept... if it wasn't because the problem is that it is implementing a _newer_ version of the protocol than most clients in your list! So it's not "incommunicado" because it is too old, it is incommunicado because it is too new! Why would the time since the last release have any effect, then? Kaidan is actually implement what appears to be the _current_ version of the spec, so if anything the problem is going to even get worse over time, not better. Is there _any_ client which actually implements multiple versions of the protocol so that it can actually talk with clients from multiple eras at the same time? Otherwise this is literally worse than Matrix, and that's saying.
  - MattJ100 2y ago
    No, the other clients apart from UWPX and Kaidan (which for obvious reasons very few people use) implement the same version of OMEMO. They do this because, contrary to what you're implying, developers in the XMPP community care about people being able to communicate with each other successfully :) The upgrade path for any E2EE protocol is generally non-trivial, and we're not quite there yet with OMEMO. It's something we are working on, as a community, which is why you'll see the transition to newer versions happen across all clients at roughly the same time. The new spec is being worked on, for example some of the more recent changes were specifically to make the upgrade path smoother. There may be more tweaks to make before we're ready for the first clients to start the transition. This kind of thing is not easy, though I appreciate that it may seem that way when you're looking on from the outside.
    - AshamedCaptain 2y ago
      > No, the other clients apart from UWPX and Kaidan (which for obvious reasons very few people use) A funny thing to say for the 2nd and 3rd most downloaded XMPP-specific clients (from the MS Store and Flathub respectively). Certainly this does not include distro data, but Kaidan is also #1 result on Google when I search "KDE XMPP". > which is why you'll see the transition to newer versions happen across all clients at roughly the same time. That's precisely what I'm not seeing. Whenever I try to update my Jabber ecosystem, there's always some incompatibility, and OMEMO has (in recent days) been always at the center of it. Example a couple years ago: Conversations deciding to remove libotr quite early in the OMEMO story, and later other clients chasing suite. Now I try to update things again and see there's yet another breaking protocol change. It doesn't help that you point that the new protocol is not ready yet but it is already published (as draft) as a XEP and implemented by multiple popular clients. I'm sure they had "good" security reasons to move forward, even if most users couldn't care less about it (same as what was argued when OTR was dropped).
rakoo 2y ago
> I join the sibling commenter in saying "PLEASE, NO MORE IDEAS WE HAVE ENOUGH". Funnily enough, that was my comment :) I agree with you if email is enough, and I tend to believe it is enough for much more than we use it for. Deltachat shows it is possible to use it for diregt messages and, thanks to webxdc, enough for collaborative pads and games even. xmpp is the step beyond if you want to add retrievable content, thanks to pubsub, but if it's not needed we should focus on making email more usable as a transport protocol.

MattJ100 2y ago

> Almost all Jabber clients (that have had any update in the last 4 years) use different AND INCOMPATIBLE versions of OMEMO. This is false. You can see the reality in this data (excuse the URL): https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++software.name%2C%0D%0A++xeps.number+as+xep_num%2C%0D%0A++xeps.title+as+xep_name%2C%0D%0A++xep_version+as+implemented_xep_version%0D%0Afrom%0D%0A++implementations%0D%0A++join+xeps+on+implementations.xep_id+%3D%3D+xeps.id%0D%0A++join+software+on+implementations.software_id+%3D%3D+software.id%0D%0Awhere%0D%0A++xeps.number+%3D+384%0D%0Aorder+by%0D%0A++implemented_xep_version%3B https://data.xmpp.net/explore/xmpp?sql=select%0D%0A++softwar... As you can see, practically all clients are on the same version (0.3). The outliers are UWPX and Kaidan, which both took the unusual decision of being incompatible with the rest of the ecosystem without working on the upgrade path. UWPX is not actively maintained (no releases for a couple of years, and the Github repo is archived). That leaves Kaidan, which is (as far as I know) actively maintained and they deliberately chose to be incompatible with the rest of the ecosystem (for now). I agree it's an unusual choice, but the XMPP ecosystem is diverse and not centralized and nobody can control what people want to do with their time spent working on their open-source projects. EDIT: To clarify some things that are probably non-obvious to people outside the XMPP sphere, the link I gave shows Prosody and Mongoose as supporting OMEMO 0.8.3. They are not clients, but servers - they are compatible with all versions of OMEMO and so are not relevant when it comes to interoperability. And QXmpp is the backend library of Kaidan, by the same developers.

AshamedCaptain 2y ago
How is this false? The clients I mentioned cannot talk with each other, and your page is showing exactly that. You then say UWPX is discontinued as an excuse, which I could accept... if it wasn't because the problem is that it is implementing a _newer_ version of the protocol than most clients in your list! So it's not "incommunicado" because it is too old, it is incommunicado because it is too new! Why would the time since the last release have any effect, then? Kaidan is actually implement what appears to be the _current_ version of the spec, so if anything the problem is going to even get worse over time, not better. Is there _any_ client which actually implements multiple versions of the protocol so that it can actually talk with clients from multiple eras at the same time? Otherwise this is literally worse than Matrix, and that's saying.
- MattJ100 2y ago
  No, the other clients apart from UWPX and Kaidan (which for obvious reasons very few people use) implement the same version of OMEMO. They do this because, contrary to what you're implying, developers in the XMPP community care about people being able to communicate with each other successfully :) The upgrade path for any E2EE protocol is generally non-trivial, and we're not quite there yet with OMEMO. It's something we are working on, as a community, which is why you'll see the transition to newer versions happen across all clients at roughly the same time. The new spec is being worked on, for example some of the more recent changes were specifically to make the upgrade path smoother. There may be more tweaks to make before we're ready for the first clients to start the transition. This kind of thing is not easy, though I appreciate that it may seem that way when you're looking on from the outside.
  - AshamedCaptain 2y ago
    > No, the other clients apart from UWPX and Kaidan (which for obvious reasons very few people use) A funny thing to say for the 2nd and 3rd most downloaded XMPP-specific clients (from the MS Store and Flathub respectively). Certainly this does not include distro data, but Kaidan is also #1 result on Google when I search "KDE XMPP". > which is why you'll see the transition to newer versions happen across all clients at roughly the same time. That's precisely what I'm not seeing. Whenever I try to update my Jabber ecosystem, there's always some incompatibility, and OMEMO has (in recent days) been always at the center of it. Example a couple years ago: Conversations deciding to remove libotr quite early in the OMEMO story, and later other clients chasing suite. Now I try to update things again and see there's yet another breaking protocol change. It doesn't help that you point that the new protocol is not ready yet but it is already published (as draft) as a XEP and implemented by multiple popular clients. I'm sure they had "good" security reasons to move forward, even if most users couldn't care less about it (same as what was argued when OTR was dropped).

rakoo 2y ago

> I join the sibling commenter in saying "PLEASE, NO MORE IDEAS WE HAVE ENOUGH". Funnily enough, that was my comment :) I agree with you if email is enough, and I tend to believe it is enough for much more than we use it for. Deltachat shows it is possible to use it for diregt messages and, thanks to webxdc, enough for collaborative pads and games even. xmpp is the step beyond if you want to add retrievable content, thanks to pubsub, but if it's not needed we should focus on making email more usable as a transport protocol.