Gajim - 2024-07-04

Yes gajim is installed from official arch repo

Latest update is really nice It's great to see more modern interaction be implemented Thx for the great work

When outputing history, the sequence was from old to new, now it is reversed. Is it by design?

Mike Yellow: you mean history export?

The Wild: thank you

> Mike Yellow: you mean history export? Yes. ↺

hai :D

Just FYI: message moderation is broken with ejabberd 24.06 and Gajim 1.9.1

Probably because Ejabberd unintentionally broke backwards compatibility and Gajim does not seem to support version 0.3.0 of xep-0425 yet. ✏

Gajim should support both old and new

Yet somehow this combination fails.

The ejabberd dev mentioned that the fallback to pre 0.3.0 is somehow borked, so gajim must somehow end up using that.

Apparently it still deletes the message from mam, but the rest fails

OK there is an ejabberd patch now that should fix it

Hi. My workstation (Gajim 1.9.1 on Gentoo) cannot decrypt messages sent from my personal laptop (also Gajim 1.9.1 on Gentoo) or my GrapheneOS smartphone (Conversations), and vice-versa: my personal laptop and my smartphone cannot decrypt messages sent from my workstation.

On the device tab, from every device I have already trusted both other devices.

Kris: thanks for the feedback!

Jorge: delete the fingerprint in Gajim of the device that does not work

And restart

I was impatient and: 1. Closed Gajim 2. Moved ~/.local/share/gajim away 3. Restarted Gajim

That fixed the problem, but I cannot decrypt past messages on my workstation. I don't use Gajim much on the workstation, but still mildly annoying.

Can I import the decryption keys from the old .local/share/gajim?

lovetox, 👆️

OMEMO doesn't allow decrypting past messages

lovetox, or should I undo the procedure? Then I would presumedly recover old history, losing only the messages received since I first executed the procedure (today approximately 13:55).

Kris, is it not possible to implement something like Element's export/import room encryption keys?

Not really. Element is using much weaker e2ee that cycles keys rarely.

Jorge: no idea, you just removed all data and gajims created everything new

It does not matter what you do you will miss messages

Don't do this again. Only because you have a pro lem with one device you don't need to fuck your whole installation

It seems that solved the problem. Thank you lovetox__ !

lovetox__, let me try to understand Accounts -> Manage Account -> <the-account> -> Encryption (OMEMO) -> Clear Devices... That only clears the local Gajim's record of devices keys for *my own account*, correct? That will not erase Gajim's record of trusted keys for my contacts, correct?

It clears the announced publik keys on your server, afterwards every device of yours publishes it's key again. It's a mechanism that you can show your contacts that some devices of yours are not available anymore

You should press that button only if all your devices are online

> You should press that button only if all your devices are online You mean that all my relevant XMPP devices should be simultaneously online when I press that button? Or does it suffice that I can bring them online within a short time? ↺

Short time is enough, the problem is only devices that are online can re announce there public key, so contacts which write you in the meantime will only encrypt to the published decices

> Jorge: delete the fingerprint in Gajim of the device that does not work Now I understand that pushing the "Clear Devices..." button clears the announced public keys on my XMPP server. So when I delete a device fingerprint, does it also delete the public key *from the server*? ↺

no, it just destroys your local session with that device, on restart Gajim queries the public keys of that device and when you send a message it will build a new session

> And restart In what order? Assume I have devices P and F1..Fn, that is, n devices Fi that function well among themselves and one problematic device P that does not function well with any other. As I understand, I should: for((i = 0; i < n; ++i)); do delete P's fingerprint from device F${i} restart F${i} done ↺

The other procedure that makes sense would be: for((i = 0; i < n; ++i)); do delete P's fingerprint from device F${i} close F${i} done for((i = 0; i < n; ++i)); do start F${i} done

Obviously the order within the F set does not matter.

My question is whether I should completely fix each F device before moving to the next (procedure one above) or I should first ensure that all devices have had P's key deleted and are simultaneously closed, then start them all (procedure 2).

you think this way to complicated

you find the device that has the problem, and delete the fingerprints of the other devices there

thats it

then send a message and a new session will be established automatically with all other devices

The message should be sent from the problematic device?

from the device that deleted the fingerprint ✏

Thank you!

but really you shouldnt get into this situation often

if you see this often then something is wrong

for example you cannot trivially restore stuff from backup, all sessions will be broken

if you have one device inactive for a long time, like thousands of messages, other devices will stop to encrypt to that inactive device

if you then turn it on after a month, you will see a lot of "could not decrypt" but thats totally expected and nothing is wrong

you need then to send a message from that inactive device, so other devices see that its active again

in this process sometimes something can break, and then maybe you have to reset the session with some devices

for the normal day to day devices like desktop and your phone, you should not see any problem ever

i have sessions with friends that are years old

its only if you fuck around with backups, restore, or have devices that are online twice a year, where problems start

on rare occassions a misconfigured or buggy sever can also cause problems with key distribution

in any case, dont do drastic actions like, deleting everything, reinstalling, etc

its always better to investigate the problem, and this support chat is quite active, so you will always get help here