As a community, we often ask ourselves how to attract more users to #XMPP.
General Discussion
9
Posts
4
Posters
0
Views
-
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.
-
System moved this topic from Uncategorized
-
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
I'm guessing there are complex problems in IM space that they don't realize they'll have to solve from scratch, which XMPP already solved for them.What are these problems?
-
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 I think people have never truly forgiven XMPP for being an XML based protocol.
-
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.
I consider this a failure on our part but I don’t really know what to do about it. Most arguments against #XMPP don’t hold if you’re building from scratch anyway:
• #Conversations_im looks very outdated: OK, but you are developing your own clients anyway.
• XMPP doesn’t have an SDK: Neither does your #ActivityPub or email stack
• OMEMO is insecure and I would prefer #MLS: Yes, let’s work on that together and you’ll still benefit from XMPP’s 100+ solved IM problems.
-
@daniel I think people have never truly forgiven XMPP for being an XML based protocol.
@mariusor @daniel what would've been a better alternative?
https://www.process-one.net/blog/stop-telling-us-xmpp-should-use-json/
-
@daniel
I'm guessing there are complex problems in IM space that they don't realize they'll have to solve from scratch, which XMPP already solved for them.What are these problems?
@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.
-
@mariusor @daniel what would've been a better alternative?
https://www.process-one.net/blog/stop-telling-us-xmpp-should-use-json/
@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)
-
-
Gli ultimi otto messaggi ricevuti dalla Federazione
-
-
-
@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)
-
@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.
-
@mariusor @daniel what would've been a better alternative?
https://www.process-one.net/blog/stop-telling-us-xmpp-should-use-json/
-
I consider this a failure on our part but I don’t really know what to do about it. Most arguments against #XMPP don’t hold if you’re building from scratch anyway:
• #Conversations_im looks very outdated: OK, but you are developing your own clients anyway.
• XMPP doesn’t have an SDK: Neither does your #ActivityPub or email stack
• OMEMO is insecure and I would prefer #MLS: Yes, let’s work on that together and you’ll still benefit from XMPP’s 100+ solved IM problems.
-
@daniel I think people have never truly forgiven XMPP for being an XML based protocol.
-
@daniel
I'm guessing there are complex problems in IM space that they don't realize they'll have to solve from scratch, which XMPP already solved for them.What are these problems?
