Drawbacks of P2P and a defense of Signal

It's basically the same encryption scheme as Jabber/XMPP uses with OMEMO. The two were developed around the same time. On Jabber existing rooms need to be set to "members only" and "non-anonymous" for encrypted groupchat to take place because Jabber multi-user chats enable using nicknames (only the MUC operators know your address) which prevents clients from querying each other's key.

> I had to bundle something like 30 megs of jar files for a simple hello world app.

That sounds horrible. There's pretty good XMPP libraries around nowadays, like slixmpp if python is your thing. There's also a WIP Rust xmpp library if you'd rather.

> Also some silly things like ejabberd refusing to hash passwords

That sounds creepy. However, prosody does that very well though. And it seems ejabberd supports SCRAM authentication since 2007?

> Matrix, with Element (...) If XMPP has anything like that

ConverseJS is a web-based Jabber/XMPP client that does encrypted groupchat. It's supported by other clients as well (such as Conversations on Android). Movim, the more popular Jabber web client (because it has social features) does not support OMEMO yet unfortunately.

ConverseJS may not be as user-friendly as Element though because they don't have (yet?) the $$$$$$ of VC/government money matrix has.

> still working on getting a committee together to form the standards

There is a bureaucratic tendency around the XMPP Standards Foundation, because standardization is very important to avoid lock-in. However client devs have pushed features before/meanwhile publishing specifications and bureaucracy does not seem to be a concern for (some?) devs in practice.

I have an old laptop running a bunch of different services, three of which are matrix servers. The matrix servers generally run fine with the modest amount of ram provisioned to them (2-4GB IIRC) with the exception of hiccups that occur when a user joins large federated rooms (we're talking several thousand users) and these hiccups only last for a few seconds and until the room has finished syncing to my server. The hiccups manifest as "Unable to connect to server" messages on clients which only delays messages from being transmitted to the server by a few seconds.

From my understanding once a single user has joined these rooms and triggered the server side sync these hiccups will not happen again once another user on my server joins the same rooms as the data is already synced on the server. Furthermore there are relatively few rooms that have the number of users necessary (1000s) to trigger the issue one time join issue.

To remedy this issue and for general network reorganization purposes I intend to migrate non-synapse VMs off of the laptop and onto other hardware and then I would simply delegate the old laptop for the matrix servers and scale the three VMs to give them 1/3 of the available ram whether they need it or not. I mispoke last night when I said 12gb by the way, as the laptop only holds 32gb ram so the available ram could be (32 - (ram for hypervisor) / 3)

To bring it all back to the thing I care most about which is the over all cost, if the laptop cost $300USD and I run 3 servers on it my hardware cost per server is $100 which I consider to be trivial. This is 20 cups of fancy coffee and more importantly many hobbyists already have a spare laptop sitting around or can find one for quite an affordable price.

I hope this clarifies my comment.