4 ms·

While I've been a believer of XMPP and still believes it has a place, I have to admit that it doesn't have the appeal it once has. Now the IM protocol du jour i

by rakoo 7y ago

While I've been a believer of XMPP and still believes it has a place, I have to admit that it doesn't have the appeal it once has. Now the IM protocol du jour is Matrix, which might or might not know the same fate; who knows. And another one might come later, and there are already others today that exist and are widely used. I think it's high time we had a concerted effort to have one great UI (probably per platform), and allow all protocol enthusiasts implement the specifics of their own choosing. It's fair to say that at this point the requirements for a "modern" UI are known, and while not all protocols may be up to the task, a very high percentage can be implemented in the most famous ones.

dragontamer 7y ago
I feel like the focus of XMPP puts the effort in the wrong place. FreeNode IRC is still used because community effort to maintain the channels. Similarly, subreddits live or die by community moderation. An effort that simplifies channel maintenance, like how easy it is to open a new Subreddit (the #1 portal, a static website URL representing your community identity) is the most important step forward. Once you establish a www identity for your community, then and only then can you discuss community chat. For example, lobster.rs community meets on IRC FreeNode, a protocol established on their about page. ------ The reason Reddit, Facebook, and Discord are popular, is because of the easy web-based onboarding process for new users. There are also web guis which make it easy to start new communities. Support the WWW first, and users will come (as long as the onboarding process is as easy as competitors)
- dwaite 7y ago
  I agree, somewhat. XMPP was primarily about person-to-person communication, with group channels being a separate add-on. Part of iMessage's popularity is the ability to have group conversations the same way as those person to person communications - to the point where SMS users may get excluded from conversations. IRC is just a terrible architecture which is exposed in its protocol, but it will survive a long time because you fire it up to participate in a community, not just to talk to an individual person. IMHO paid tools like Slack got adoption when we had pre-existing protocols and clients for decades prior because it works as a package community-as-a-service (imho, to the point of being a detriment to usability). We had the technology to solve the problem, but the packaging and focus made it a legitimate product.
  - beagle3 7y ago
    > IRC is just terrible architecture IRC is for public channels (and supports direct messages). It’s far from perfect, but I wouldn’t call it terrible; it works very well for its original purpose (and has been for almost 3 decades now).
    - dwaite 7y ago
      IRC has a number of easily abused aspects of the protocol, such as giving away the recipient's direct address which may give away a great deal about their physical location. Just like XMPP it makes the mistake of tying the user's presence directly to their TCP connection, meaning a connectivity issue (such as another user flooding their IP) results in them being unable to use the system. Outside of privileged bots on open-source oriented networks, there are typically no accounts or registrations for names, so network attacks are fairly common in an attempt to regain a channel or nickname. Servers in a network generally have little to no proper recovery from partitions/splits, and a split may result in changes in moderator/administrative users due to the lack of persistent permissions. There is no attempt to recover discussions during a split, or to apply consistent ordering to communication. Splits, which should be transparent, become a highly impactful event to the users within a channel. Due to the lack of packetized responses and the simplistic method of determining an active TCP connection, it is possible to (for instance) be disconnected because of asking for a list of channels on a slow connection. It has a _lot_ of problems, and most of the ones I listed are at the network protocol layer. It is still usable for environments where there are very active administrators and few to no bad actors, but it falls apart quickly on the public internet.
  - Andrew_nenakhov 7y ago
    Group chats in XMPP (aka XEP-0045) is a pile of garbage, ill-conceived attempt to clone IRC to XMPP. It just can't properly work on mobile devices without a set of very ugly hacks to support it from breaking all the time. It should be just thrown away and replaced with a better solution (that's what we intend to do rather soon).
BlueTemplar 7y ago
While it's worrying that Matrix uses the layer 7 HTTP (does it make it "layer 8"?) compared to XMPP's potentially more efficient use of layer 4 TCP, it's still better than the closed alternatives... (And JSON > XML !)
- dependenttypes 7y ago
  It is actually a good idea to use https rather than your own protocol because then your network provider/government will not be able to (easily) find out that you aren't just making https requests using your browser. Useful for people living in oppressive governments as well as employees/students under restrictive firewalls. In addition to that this will get more efficient once we have http over quic.
  - BlueTemplar 7y ago
    Quic seems to be the UDP equivalent to TCPcrypt? Both of which should be used by default on the Internet? But why should in your examples "the authorities" care or not whether you are using a browser over HTTP(S) or any other kind of software/protocol? If any communication channel is available, it's possible to send any kind of VPN traffic through it. Bits are bits. Especially when encrypted, so the censor has no idea as to what is inside...
    - BlueTemplar 7y ago
      Also, IPSec.
    - dependenttypes 7y ago
      > But why should in your examples "the authorities" care or not whether you are using a browser over HTTP(S) or any other kind of software/protocol? You are going to be more suspicious if you are using $protocol-specific-for-encrypted-chat than if you are just browing the web. > Bits are bits I agree, but this does not stop my ISP from throttling my SSH speed.
  - Uehreka 7y ago
random3 7y ago
I was going to mention SSBC (ssbc.github.io). Is there a good write-up comparing the two?
- emmelaich 7y ago
  I guess you mean patchwork in particular? > A decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB). https://www.scuttlebutt.nz https://www.scuttlebutt.nz
ppjet6 7y ago
I want to say "it's complicated". Probably any single protocol could be used to build a client that Slack or WhatsApp or [insert your target here] users would appreciate with good designers, (and/or with really little to no education.) Multi-protocol clients are generally not optimal. The set of features that can be used will be the lowest common denominator, and if it's not the case there will be discrepancies in the design. (Same story for bridges.) Every protocol has their set of trade-offs, and every developer has their opinion on what's best (or the least worst). Also not every developer work with designers or have designing skills(!) It's good for developers to be able to write what they want and how they want it. It's fine if their intended target is already with their circle of friends on the platform (if their is a target at all). It's less practical if the target is outside and their circle is not on the platform (network effect/peer pressure etc.). That's a general "issue" in Free Software, (I'd say in software, maybe anywhere? it's just more visible here.) Some might say waste of resources, but who gets to decide what to do with others' free time.. no easy answers. (Sorry to spoil the fun by trying to rationalize :p) I for one value freedom, through decentralisation (or federation as some like to insist on), and as technicalities I believe standard and extensibility of said standard are necessary. XMPP seems to fit this role ok enough to me.
- rakoo 7y ago
  Of course I'm not saying that people should stop working on what they want, they are free to spend their time however they want. I'm looking at it the other way: what if I want to create a protocol but can't be bothered to work on the UI, because I'm no designer ? I'm not even talking about multi protocol clients because, as you said, it tends to level downwards rather than upwards. But if I could "fork" the UI and slap my protocol on it, instead of having to build it from scratch, I'd save a lot of time.

by rakoo 7y ago

dragontamer 7y ago

I feel like the focus of XMPP puts the effort in the wrong place. FreeNode IRC is still used because community effort to maintain the channels. Similarly, subreddits live or die by community moderation. An effort that simplifies channel maintenance, like how easy it is to open a new Subreddit (the #1 portal, a static website URL representing your community identity) is the most important step forward. Once you establish a www identity for your community, then and only then can you discuss community chat. For example, lobster.rs community meets on IRC FreeNode, a protocol established on their about page. ------ The reason Reddit, Facebook, and Discord are popular, is because of the easy web-based onboarding process for new users. There are also web guis which make it easy to start new communities. Support the WWW first, and users will come (as long as the onboarding process is as easy as competitors)

dwaite 7y ago
I agree, somewhat. XMPP was primarily about person-to-person communication, with group channels being a separate add-on. Part of iMessage's popularity is the ability to have group conversations the same way as those person to person communications - to the point where SMS users may get excluded from conversations. IRC is just a terrible architecture which is exposed in its protocol, but it will survive a long time because you fire it up to participate in a community, not just to talk to an individual person. IMHO paid tools like Slack got adoption when we had pre-existing protocols and clients for decades prior because it works as a package community-as-a-service (imho, to the point of being a detriment to usability). We had the technology to solve the problem, but the packaging and focus made it a legitimate product.
- beagle3 7y ago
  > IRC is just terrible architecture IRC is for public channels (and supports direct messages). It’s far from perfect, but I wouldn’t call it terrible; it works very well for its original purpose (and has been for almost 3 decades now).
  - dwaite 7y ago
    IRC has a number of easily abused aspects of the protocol, such as giving away the recipient's direct address which may give away a great deal about their physical location. Just like XMPP it makes the mistake of tying the user's presence directly to their TCP connection, meaning a connectivity issue (such as another user flooding their IP) results in them being unable to use the system. Outside of privileged bots on open-source oriented networks, there are typically no accounts or registrations for names, so network attacks are fairly common in an attempt to regain a channel or nickname. Servers in a network generally have little to no proper recovery from partitions/splits, and a split may result in changes in moderator/administrative users due to the lack of persistent permissions. There is no attempt to recover discussions during a split, or to apply consistent ordering to communication. Splits, which should be transparent, become a highly impactful event to the users within a channel. Due to the lack of packetized responses and the simplistic method of determining an active TCP connection, it is possible to (for instance) be disconnected because of asking for a list of channels on a slow connection. It has a _lot_ of problems, and most of the ones I listed are at the network protocol layer. It is still usable for environments where there are very active administrators and few to no bad actors, but it falls apart quickly on the public internet.
- Andrew_nenakhov 7y ago
  Group chats in XMPP (aka XEP-0045) is a pile of garbage, ill-conceived attempt to clone IRC to XMPP. It just can't properly work on mobile devices without a set of very ugly hacks to support it from breaking all the time. It should be just thrown away and replaced with a better solution (that's what we intend to do rather soon).

BlueTemplar 7y ago

While it's worrying that Matrix uses the layer 7 HTTP (does it make it "layer 8"?) compared to XMPP's potentially more efficient use of layer 4 TCP, it's still better than the closed alternatives... (And JSON > XML !)

dependenttypes 7y ago
It is actually a good idea to use https rather than your own protocol because then your network provider/government will not be able to (easily) find out that you aren't just making https requests using your browser. Useful for people living in oppressive governments as well as employees/students under restrictive firewalls. In addition to that this will get more efficient once we have http over quic.
- BlueTemplar 7y ago
  Quic seems to be the UDP equivalent to TCPcrypt? Both of which should be used by default on the Internet? But why should in your examples "the authorities" care or not whether you are using a browser over HTTP(S) or any other kind of software/protocol? If any communication channel is available, it's possible to send any kind of VPN traffic through it. Bits are bits. Especially when encrypted, so the censor has no idea as to what is inside...
  - BlueTemplar 7y ago
    Also, IPSec.
  - dependenttypes 7y ago
    > But why should in your examples "the authorities" care or not whether you are using a browser over HTTP(S) or any other kind of software/protocol? You are going to be more suspicious if you are using $protocol-specific-for-encrypted-chat than if you are just browing the web. > Bits are bits I agree, but this does not stop my ISP from throttling my SSH speed.
- Uehreka 7y ago

random3 7y ago

I was going to mention SSBC (ssbc.github.io). Is there a good write-up comparing the two?

emmelaich 7y ago
I guess you mean patchwork in particular? > A decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB). https://www.scuttlebutt.nz https://www.scuttlebutt.nz

ppjet6 7y ago

I want to say "it's complicated". Probably any single protocol could be used to build a client that Slack or WhatsApp or [insert your target here] users would appreciate with good designers, (and/or with really little to no education.) Multi-protocol clients are generally not optimal. The set of features that can be used will be the lowest common denominator, and if it's not the case there will be discrepancies in the design. (Same story for bridges.) Every protocol has their set of trade-offs, and every developer has their opinion on what's best (or the least worst). Also not every developer work with designers or have designing skills(!) It's good for developers to be able to write what they want and how they want it. It's fine if their intended target is already with their circle of friends on the platform (if their is a target at all). It's less practical if the target is outside and their circle is not on the platform (network effect/peer pressure etc.). That's a general "issue" in Free Software, (I'd say in software, maybe anywhere? it's just more visible here.) Some might say waste of resources, but who gets to decide what to do with others' free time.. no easy answers. (Sorry to spoil the fun by trying to rationalize :p) I for one value freedom, through decentralisation (or federation as some like to insist on), and as technicalities I believe standard and extensibility of said standard are necessary. XMPP seems to fit this role ok enough to me.

rakoo 7y ago
Of course I'm not saying that people should stop working on what they want, they are free to spend their time however they want. I'm looking at it the other way: what if I want to create a protocol but can't be bothered to work on the UI, because I'm no designer ? I'm not even talking about multi protocol clients because, as you said, it tends to level downwards rather than upwards. But if I could "fork" the UI and slap my protocol on it, instead of having to build it from scratch, I'd save a lot of time.