As a community, we often ask ourselves how to attract more users to #XMPP.
General Discussion
22
Posts
11
Posters
4
Views
-
@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.
-
-
@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.
-
As a community, we often ask ourselves how to attract more users to #XMPP. Yet the real tragedy is that people would rather build something entirely new (loosely based on email or #ActivityPub) than consider XMPP. Need end-to-end encryption by default? If compatibility with existing XMPP clients is a secondary concern, you can implement it in your own solution while still benefiting from our two decades of experience in instant messaging.
@daniel Someone have to solve https://soatok.blog/2024/08/04/against-xmppomemo/ issues first
-
undefined daniel@gultsch.social shared this topic
-
@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.
-
@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
-
@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 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.
-
@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.
@daniel @tris I'm also genuinely surprised that people believe that ActivityPub, a protocol even named after its purpose, to publish activities, is a good protocol to pursue private instant messaging. The goals of those two couldn't be more detrimental.
I do see a purpose of being able to reuse your "ActivityPub identities", which actually are just WebFinger identities. Maybe someone should specify how to discover XMPP accounts via WebFinger and push that as a solution for AP messaging?
-
@daniel @tris I'm also genuinely surprised that people believe that ActivityPub, a protocol even named after its purpose, to publish activities, is a good protocol to pursue private instant messaging. The goals of those two couldn't be more detrimental.
I do see a purpose of being able to reuse your "ActivityPub identities", which actually are just WebFinger identities. Maybe someone should specify how to discover XMPP accounts via WebFinger and push that as a solution for AP messaging?
@pixelschubsi @tris Yes, agreed. Tremendous value in reusing identities and login credentials. Big skepticism with regards to using AP as a protocol. One can probably kinda make it work… But why? What’s the benefit?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@pixelschubsi @tris Yes, agreed. Tremendous value in reusing identities and login credentials. Big skepticism with regards to using AP as a protocol. One can probably kinda make it work… But why? What’s the benefit?
-
@daniel @tris I'm also genuinely surprised that people believe that ActivityPub, a protocol even named after its purpose, to publish activities, is a good protocol to pursue private instant messaging. The goals of those two couldn't be more detrimental.
I do see a purpose of being able to reuse your "ActivityPub identities", which actually are just WebFinger identities. Maybe someone should specify how to discover XMPP accounts via WebFinger and push that as a solution for AP messaging?
-
@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.
-
@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.
-
@daniel Ah, fair, their work for E2EE Fedi looks interesting: https://github.com/fedi-e2ee/public-key-directory-specification
-
@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 Someone have to solve https://soatok.blog/2024/08/04/against-xmppomemo/ issues first
-
@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.
