3 ms·

Before you dismiss XMPP and seek for alternatives that need at least another 5-10 years to be actually usable (looking at you [matrix]) you might want to take a

Before you dismiss XMPP and seek for alternatives that need at least another 5-10 years to be actually usable (looking at you [matrix]) you might want to take a look at how far XMPP has come in the last 2-3 years. The Android client Conversations (https://Conversations.im https://Conversations.im) is a prime example on what can be achieved with XMPP today. In band images, emojis, End-to-end encryption, group chats…

y0ghur7_xxx 10y ago
conversations is really nice. thanks for making it. one problem i have with it, that gchat solves really well, is how it behaves when you have a desktop client and conversations open at the same time. when someone using conversations writes to me, what i expect is that i get the message on my desktop, as well as on my mobile client. but conversations will ALWAYS ask the user where he wants to send the message, if on my phone or on my desktop client. this should not happen. it should just send it without the resource set, and let the xmpp server figure it out.
- drdaeman 10y ago
  > but conversations will ALWAYS ask the user where he wants to send the message Must be a bug (or OTR requirement, as OTR doesn't work with multiple devices). XMPP clients shouldn't require sender to choose the recipient's resource, unless sender is explicit that they want to target a specific device.
- inputmice 10y ago
  This is a confinement of OTR. OTR was never made for modern day instant messaging. Use OMEMO or send unencrypted messages and you won't have this problem.
Arathorn 10y ago
inputmice: I hear your Conversations app is really nice, and it's great to see XMPP is evolving well. Rather than being defensive about XMPP and badmouthing matrix, perhaps we can just bridge both ecosystems and both sides and clients benefit from wider reach? Especially when some tech like interoperable E2E ratchet implementations is of direct use for both ecosystems. The two protocols have entirely different designs and philosophies and do different things. It's like claiming that NNTP competes with SMTP because you can uses them both to hold conversations. Please can we both just get along? :) In terms of matrix's usability: i'd say it's been very usable for the last 6 months or so - and given the size and activity visible to the matrix.org homeserver, others seem to concur.
- inputmice 10y ago
  I'm not bad mouthing anything. It's just that Matrix doesn't solve any problems XMPP hasn't already solved or could have solved with an extension. Matrix is basically a pointer to a stream of messages. You could have easily made this into a XEP. In fact there have been ideas in the XMPP community called MAM subscriptions that are basically the same thing. Even if that extension would have been a radical change in C2S communication as long as S2S stays the same you could have built your protocol on an existing infrastructure. I mean I rather have people use matrix than a closed system like WhatsApp or Signal. But I honestly don't see the point for developing a new protocol other than JSON over HTTP fits better into the zeitgeist and NIH syndrome.
  - Arathorn 10y ago
    Claiming that matrix needs 5-10 years to be 'usable' seemed to be unnecessarily and unproductively negative, hence my objection to badmouthing when we could instead be working together productively :) The last thing decentralised comms needs is in-fighting. I think the root of the contention here is that you don't seem to understand what Matrix does - this is probably my fault for failing to explain it better to you in person at FOSDEM. It is not a pointer to a stream of messages. The whole point is to store arbitrary data (e.g. room history and state) as a directed acyclic graph shared over all the participating servers. It's a big distributed datastructure with eventual consistency semantics which happens to be usable for chat. Or any other kind of real-time requirements. If you wanted to compare it to a XEP, then FMUC would be a better comparison than MAM subscriptions. And yes, you're right that one could have built it on top of the XEP stack of standards, just like FMUC did. We could also have layered it on top of IRC. Or IMAP. Or NNTP. Or ZMQ. Or MSRP. Or Psyc etc. Instead, we chose to layer on HTTP in order to keep it as simple as possible - we simply don't need most of the abstractions that XMPP provides. And we believe it's easier for a protocol to get traction if it has a single monolithic spec which defines feature compatibility profiles for interop than if it's a huge collection of optional extensions. In the end, these are both subjective opinions, but I see no harm in there being two different philosophies out there for solving the problem of interoperable communication. Especially as it's not a competition, given both can 'win' by bridging together.

y0ghur7_xxx 10y ago

conversations is really nice. thanks for making it. one problem i have with it, that gchat solves really well, is how it behaves when you have a desktop client and conversations open at the same time. when someone using conversations writes to me, what i expect is that i get the message on my desktop, as well as on my mobile client. but conversations will ALWAYS ask the user where he wants to send the message, if on my phone or on my desktop client. this should not happen. it should just send it without the resource set, and let the xmpp server figure it out.

drdaeman 10y ago
> but conversations will ALWAYS ask the user where he wants to send the message Must be a bug (or OTR requirement, as OTR doesn't work with multiple devices). XMPP clients shouldn't require sender to choose the recipient's resource, unless sender is explicit that they want to target a specific device.
inputmice 10y ago
This is a confinement of OTR. OTR was never made for modern day instant messaging. Use OMEMO or send unencrypted messages and you won't have this problem.

Arathorn 10y ago

inputmice: I hear your Conversations app is really nice, and it's great to see XMPP is evolving well. Rather than being defensive about XMPP and badmouthing matrix, perhaps we can just bridge both ecosystems and both sides and clients benefit from wider reach? Especially when some tech like interoperable E2E ratchet implementations is of direct use for both ecosystems. The two protocols have entirely different designs and philosophies and do different things. It's like claiming that NNTP competes with SMTP because you can uses them both to hold conversations. Please can we both just get along? :) In terms of matrix's usability: i'd say it's been very usable for the last 6 months or so - and given the size and activity visible to the matrix.org homeserver, others seem to concur.

inputmice 10y ago
I'm not bad mouthing anything. It's just that Matrix doesn't solve any problems XMPP hasn't already solved or could have solved with an extension. Matrix is basically a pointer to a stream of messages. You could have easily made this into a XEP. In fact there have been ideas in the XMPP community called MAM subscriptions that are basically the same thing. Even if that extension would have been a radical change in C2S communication as long as S2S stays the same you could have built your protocol on an existing infrastructure. I mean I rather have people use matrix than a closed system like WhatsApp or Signal. But I honestly don't see the point for developing a new protocol other than JSON over HTTP fits better into the zeitgeist and NIH syndrome.
- Arathorn 10y ago
  Claiming that matrix needs 5-10 years to be 'usable' seemed to be unnecessarily and unproductively negative, hence my objection to badmouthing when we could instead be working together productively :) The last thing decentralised comms needs is in-fighting. I think the root of the contention here is that you don't seem to understand what Matrix does - this is probably my fault for failing to explain it better to you in person at FOSDEM. It is not a pointer to a stream of messages. The whole point is to store arbitrary data (e.g. room history and state) as a directed acyclic graph shared over all the participating servers. It's a big distributed datastructure with eventual consistency semantics which happens to be usable for chat. Or any other kind of real-time requirements. If you wanted to compare it to a XEP, then FMUC would be a better comparison than MAM subscriptions. And yes, you're right that one could have built it on top of the XEP stack of standards, just like FMUC did. We could also have layered it on top of IRC. Or IMAP. Or NNTP. Or ZMQ. Or MSRP. Or Psyc etc. Instead, we chose to layer on HTTP in order to keep it as simple as possible - we simply don't need most of the abstractions that XMPP provides. And we believe it's easier for a protocol to get traction if it has a single monolithic spec which defines feature compatibility profiles for interop than if it's a huge collection of optional extensions. In the end, these are both subjective opinions, but I see no harm in there being two different philosophies out there for solving the problem of interoperable communication. Especially as it's not a competition, given both can 'win' by bridging together.