@wolf480pl yes I think that is a huge part of the problem. It is very easy to completely underestimate the complexity of Instant Messaging. Sending a message from A to B seems like something every software developer can write before lunch and people don’t see how it can and will rapidly escalate from there.

But I don’t know how do communicate that to other people.

@joshix based on what's popular today: JSON.

(I'm joking, my assumption is that they chose what was the best alternative at the time. As far as I know JSON hadn't been described by Crockford at Jabber's inception)

@daniel

@mariusor @daniel JSON is worse and has less features

@joshix I am making jokes not technical decisions. Hold off on the snark please.

@daniel

@daniel The big plus of #DeltaChat is that the infrastructure is already there. Infrastructure is a big part of the problem. And obviously using mail for that is only for people born before 2000.

Second is branding: When people hear #XMPP they hear 20 years of failure of implementing robust solutions both server-side and client-side. People just don't know that after 20 years there now are server and client solutions really working.

@lazarus @daniel #XMPP is still a thriving ecosystem with lots of good FOSS developers doing interesting things.

XMPP is also used under the hood in tons of products needing instant messaging even if they are not advertised as XMPP clients, or do not federate. But look at #Matrix, only 25% of matrix servers federate.

Anyway, all three share a strong focus on protocols, but there is a big difference: https://chatmail.at does not expose protocols to client developers, just a Rust SDK.

@daniel@gultsch.social The Lemmy developers have added a user profile field where you can enter a Matrix account. It would certainly be better to also add a link to XMPP, and I believe this would be the most viable way to immediately achieve secure communication in the Fediverse.

However, it's always helpful for someone to try to "reinvent the wheel": diversity is a very prolific mother of solutions to problems that don't yet exist.

@delta @lazarus @daniel where is this "only 25% of matrix servers federate" stat from? it's pretty hard to tell what servers exist that don't federate(!)

@matrix @delta @lazarus @daniel Every protocol/standard/client has their own pros and cons. The real enemies are centralized and proprietary systems. What people really need is XMPP/Matrix/Delta interoperability.

@dragospirvu75 @matrix @delta @lazarus The way to achieve interoperability is to stop reinventing the wheel and agree on one standard. Implementing three protocols is completely unfeasible and unnecessary. This worked 20 years ago with MSN, ICQ and AIM when IM protocols had a lot less features and no E2EE. Doesn’t work today.

@daniel Someone have to solve https://soatok.blog/2024/08/04/against-xmppomemo/ issues first

@tris two things: I already said in my follow up post that if someone wants to build their own clients on top of XMPP and prefers MLS over OMEMO, the XMPP community is very open to that. A protocol is much more than just the encryption. They would still benefit from all the other things XMPP has solved.

A lot of what's in that blog post is ill-informed and bordering on disinformation and fear mongering.

@daniel Ah, fair, their work for E2EE Fedi looks interesting: https://github.com/fedi-e2ee/public-key-directory-specification

@tris there are three actively developed protocols for federated instant messaging (XMPP, Matrix, Deltachat). At least one of them is very open to new developers and new ideas and has a structure in place to collaboratively work on those ideas and bring various stake holders together. With no disrespect to that individual I don't see why there needs to be a forth protocol loosely based on ActivityPub.

@tris Soatak is an expert in cryptography. I’m not. I’m more than happy to stand on the shoulder of giants when it comes to E2EE. That’s why we used the Signal Protocol 10+ years ago for #OMEMO and are now looking towards #MLS. However, good, interoperable protocol design is so much more than just E2EE. And maybe I've learned a thing or two about protocol design in my career that they don’t necessarily know.