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.

Check out https://github.com/dino/dino/issues/1193

> 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.

While Dino and all of its dependencies can be compiled and run on Windows and macOS, this process is tedious and GTK isn't really well-tested on anything but Linux, resulting in worse UX when not going the extra mile of doing targeted modifications for these platforms. This hopefully improves with the migration to GTK4.

The XMPP Standards Foundation publishes a document once a year stating a set that decent XMPP clients and servers should implement. The current one, https://xmpp.org/extensions/xep-0459.html even has a specific section on calling (it doesn't cover group calls yet).

It does work, but UX isn't as good and installation is a little tricky. Check out the wiki page here: https://github.com/dino/dino/wiki/macOS

Friends and family all use XMPP via Conversations and/or Dino. I also join a few channels of FOSS projects on Matrix or IRC with a bridge. You can even bridge calls to SIP and PSTN via https://jmp.chat/.

I run my own server (any 5 bucks VPS can do), but there is a large number of public servers that also work good. Make sure to pick one with a good ranking at https://compliance.conversations.im/

In XMPP, encrypted messages can either contain encrypted XML

> <message type="chat"><body>Hi there!</body></message>

or raw text

> Hi there!

In Matrix, it's always encrypted JSON

> {"type": "m.room.message", "content": {"msgtype": "m.text", "body": "Hi there!"}}

It would be possible for Matrix to indicate that a room is a "raw room" and that clients should send and expect raw messages in that room - losing a few features on the go. Such raw room could be bridged over to XMPP fully end-to-end-encrypted (with small changes on either side to adjust for the differences between OMEMO and OLM).

But I doubt anyone at Element will invest time into doing it and for the XMPP side it's much more work to do it "on their own" (by implementing parsing support for the encrypted JSON of Matrix as shown above).

Having raw text in the encrypted content is by the way still the normal way how things work in XMPP world and is supported by every client doing E2EE - because it is basically free to implement (barely any additional code needed).

HTTP would be fine as well, you could GET an XML with the form to fill and POST the XML with form data.

But: - HTTP forms might be less flexible when it is about structured data. - HTML needs a complex renderer software

Remember that this stuff might need to work on low resource devices and over low bandwidth connections.

Which modern serialized protocol do you envision here? That comes with good extensibility by design?

Just the fact that XML is old, doesn't mean it's bad. It might be a bit unnecessary verbose or hard to parse for constrained devices, but luckily there is EXI to solve these issues when efficiency is key.

microG GmsCore is a FLOSS (Free/Libre Open Source Software) framework to allow applications designed for Google Play Services to run on systems, where Play Services is not available.

Dino is native, which means it is more likely to get proper support of hardware accelerated video encoding/decoding, best case leading to less energy consumption during video calls.

My Laptop's fan always runs full speed when being in a Jitsi conference for more than a few minutes.

We fixed some issues with OMEMO in the last months, so if your experience is a little bit older, those might be fixed already. If not, please report.

Dino has a very limited plugin system, extending it is planned for future releases. We are also interested in adding support for A/V calling and we already have some pieces of code for it, though nothing in a quality for actual usage.

Last time I checked, Pidgin lacked proper support for multi device by not supporting Message Carbons (XEP-0280, required to receive messages on multiple devices when both are online at the same time) and Message Archive Management (XEP-0313, required to catch up with messages received while only another device was online).

There is probably also other examples of XMPP features that Pidgin does not and likely will never support, due to its nature of being multi-protocol (basically limiting features to the smallest common feature set).

No. OTR was not considered due to its lack of multi device support. OTRv4 now supports multi device, so it could be an additional option once it becomes standardized for XMPP. We are also monitoring development around MLS.

We are aiming for support for the Librem 5 and other smartphones that use a more GNU/Linux-ish environment. For Android there is conversations.im with a similar feature set.