Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party.

Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

Depending on when you last tried xmpp you might have experienced the OTR hell, which was never really codified 100% and spawned subtle incompatibilities between clients leading to weird and nondescript errors that never got addressed. Nowadays the popular clients support omemo (https://conversations.im/omemo/), which makes encryption just work™ out of the box and without hassle. The only exception to this is xabber, who are apparently afraid of law enforcement destroying their lifes should they implement proper encryption and also feel no need to support it anyways: https://github.com/redsolution/xabber-android/issues/540

> just work™

YMMV™

We have yet to manage not getting any OMEMO issues in a 2 users, 5 clients situation (2 Conversations on android, 1 Gajim on win, 2 Pidgin on linux)

If you care to elaborate, i'm sure that'll be of interest to maintainers. Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.

> Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.

Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you thought it did.

Here's my unsolicited recommendation: Block Pidgin. Not just Pidgin, any time the XMPP community finds itself having to explain that oops, that client doesn't work so good, please use a different one, just block the client, permanently instead, from all popular and well known servers, tell anybody who will listen that's not a real XMPP client, not any more.

Any time the community just can't bring itself to block a client, cross off the features that don't work across the ecosystem due to that client. Those aren't really XMPP features any more since they exist only for some users and the community is apparently OK with that.

And each year, stand back and look at the resulting two steps forward three steps back juddering "Progress" and reconsider - was this the way to get where you wanted to go? Or are you all wasting your time on an exercise that would be easier done a different way.

Pidgin is not listed as supporting OMEMO [0] and is not recommended for newcomers on joinjabber.org [1]. There may be reasons you want to use Pidgin and i don't want to block you: also pidgin is not exactly abandoned so there's hope it will continue to improve.

When a web browser fails to display a certain page, would you recommend the site operator to block it? Maybe we could allowlist specific clients and send a warning message to others just in case they're not aware they're using something niche.

[0] https://omemo.top/

[1] https://joinjabber.org/

the omemo support in pidgin is just through a plugin, as with many recent XEPs. i think people tend to forget that pidgin's focus is being a multi-protocol messenger. it ships with XMPP support, but that mostly includes the base.

i wrote that omemo plugin and tbh I am pretty burned out. so many moving parts, it's hell to debug and i'm not even sure where to go next with it. (plus people keep talking badly about pidgin anyway and i am not sure if it's even worth continuing.) i am very thankful for all the contributions so far, especially the help with packaging it. sorry if someone feels let down.

i feel like this is the right moment to ask: if anyone reading has an idea how to improve the state of things, i'd be happy about some suggestions. the project page is https://github.com/gkdr/lurch