larma

Yes, the whole app will be Linux Mobile ready soonish, but priority was to have the main screen first and get everything ready in-time for Debian stable inclusion

I wouldn't call it a fundamental difference. If I was to concatenate the 3 XMPP RFCs and the suggested XEPs from the compliance suite linked, I would end up with a monolithic spec.

Every now and then, when a new compliance suite is published, I'd need to update the one concatenated document aka. monolithic spec. A new compliance suite in XMPP "activating" a XEP is like "merging" an MSC. For as long as a XEP is not part of the compliance suite, it's not part of the monolithic spec (it's still just an MSC) and you don't have to mess with it.

The only real difference is that the current version of XMPP spec is a document with links to other documents whereas the current version of Matrix spec is a document with links inside the document itself.

> nobody can tell me that bugs don't happen

They do happen. And whenever someone does make use of them, that's considered unlawful - which is absurd considering that the bug is part of the code and thus part of the law.

Most of so called circulating supply is not circulating. 25% are in addresses that have been dormant for more than 5 years. Several percent are locked in "DeFi" or long term contracts. When Bitcoiners say "circulating supply" they really just means "all coins ever mined" and you shouldn't actually use that number for any practical purpose (doesn't stop people from using it for calculating the "market cap")

The complexity of a whole protocol and running a client for it (which is effectively what you are doing when running bridges locally) is much higher than just doing the necessary part (e2ee) on the client. Also, you might be unable to run such bridge in a web client because the protocol is not based on cors-enabled http/websocket APIs.

I think implementing just the e2ee part of the WhatsApp protocol (which happens to be the Signal protocol with open-source libraries available) client-side and have a server-side bridge transport the encrypted messages over to WhatsApp and vice-versa is a sensible option not mentioned in that blog post. Yes, worst-case it means that for interoperability you have to create a bunch of message encryption routines. But we are effectively talking about iMessage and WhatsApp - Facebook Messenger doesn't do e2ee and no other company that built a widely used personal IM system is big enough to be covered by DMA.

Regarding moderation and spam: I think a company with €7.5B yearly revenue should be reasonable able to build something such that moderation and spam prevention are also possible with federation. Google already does a pretty decent jobs in spam filtering with e-Mails, I guess they should be able to do something similar with IM.

> server typically has done termination of the encrypted call streams as it does its routing.

Dino already supports some kind of "double encryption", where even if DTLS-SRTP is terminated at a media routig or bridging server, there is another SRTP encryption layer. This allows for end-to-end encryption even when DTLS-SRTP is terminated by a server for WebRTC compliance (as WebRTC requires to encrypt using DTLS-SRTP even if transported media was already encrypted through other means).

Vala is a nice, modern niche language for GTK development. It certainly can also be used for other things, e.g. it can be compiled to WASM, but GTK development really is focus. Also the language is actively developed and getting updates with new feature. While originally inspired by C# it nowadays also incorporates features known from other modern languages like Kotlin.