Of course it doesn't work on ios. The issue you linked explains that a syncthing ios implementation would be useless because the background process can't run and the way filesystem access is managed makes the whole thing more or less pointless. It's available on all better operating systems though: Windows, macos, gnu/linux, android/linux, I think even chromebooks can run it?
> this seems really complex...
Like I said, it's probably not a solution for many. A second database with shared secret is very straightforward and transparent way that anyone can grasp I think. It would definitely pass the family test for me.
> how do you sync passwords across my 3 laptops and 3 phones without a SaaS offering?
Syncthing. Set up once, runs reliably forever.
> How can I securely share credentials with family members?
I don't do this either (and don't know anyone who does) but I imagine it'd be easy to just create a different shared database for the family for that? With password store, it's also possible to set multiple different gpg keys for a specific directory. I don't think the last option is doable for most people though.
Omemo just works out of the box as well. You don't have to check the key fingerprints, noone forces you to. For people who aren't interested the chat opens and they can start writing and sending, the encryption is completely transparent.
Since there is nothing one can do to identify a specific client, you cannot just block them. If they violate the spec that should be reason enough to consider them not real clients. I personally have no experience with pidgin and xmpp, but I can recommend https://dino.im for linux. It uses omemo by default and works like a charm.
That's got nothing to do with the security problems OP complained about though. Are there even working solutions to those metadata problems apart from sending dummy decoy messages and purposeful delays on the server side to make correlating message relaying hard?
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
The benefit would be that history would be kept and be viewable from different accounts. The problem would be that the history would have to be MITM'd on the matrix-xmpp-server-bridge because the encryption models aren't compatible. The server would need to manage omemo keys for the user and would thus need ultimate trust.
Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere?
Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key.
In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident.
> This opens room for MITM attacks
Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.
XMPP and matrix solve related, but somewhat different problems. The Matrix approach is that everything is a stateful chatroom with history in which users can join or leave, while for XMPP there are only users (entities) which exchange objects that may or may not be text messages. It doesn't really care what happens after the fragments have been delivered.
I think Mozilla is a horrible leadership spending money on all the wrong things and I'd rather lose my job than donate to them. But, in all fairness, they're still way better than both Microsoft and Google. At least Mozilla isn't actively trying to make my life worse every single day.