In https://github.com/NixOS/nixpkgs/pull/337571#pullrequestreview-2266291440, @niklaskorz reported that he was unable to receive incoming messages after switching to bridges built with goolm instead of libolm on mautrix-whatsapp and mautrix-signal. I've now reproduced this on mautrix-gmessages, too, so I'm assuming it's a bug with goolm and not any individual bridge.
The incoming messages on Beeper desktop say
Unable to decrypt: Error: OLM.BAD_SIGNATURE
and on Beeper Android say
Encrypted Message
I sent the discard-megolm-session command in the control channel for mautrix-gmessages, and it looks like that's resolved the issue at least for now. I hypothesize that there's a compatibility problem around key storage that means you have to regenerate keys after switching Olm implementations, in which case it should continue to work for me through server reboots, etc., but I'll continue to monitor it and report if something different happens.
OK, bad news. An existing conversation (not the one I was testing with) is still broken after switching to goolm and discarding the megolm session. That disproves my hypothesis.
In https://github.com/NixOS/nixpkgs/pull/337571#pullrequestreview-2266291440, @niklaskorz reported that he was unable to receive incoming messages after switching to bridges built with goolm instead of libolm on mautrix-whatsapp and mautrix-signal. I've now reproduced this on mautrix-gmessages, too, so I'm assuming it's a bug with goolm and not any individual bridge.
The incoming messages on Beeper desktop say
and on Beeper Android say
I sent the
discard-megolm-session
command in the control channel for mautrix-gmessages, and it looks like that's resolved the issue at least for now. I hypothesize that there's a compatibility problem around key storage that means you have to regenerate keys after switching Olm implementations, in which case it should continue to work for me through server reboots, etc., but I'll continue to monitor it and report if something different happens.