7 ms·

The thing that concerns me about this is that while Matrix might be a more modern protocol today, it won't be long before the world moves and it requires an upg

by dnel 8y ago

The thing that concerns me about this is that while Matrix might be a more modern protocol today, it won't be long before the world moves and it requires an upgrade, and extendability has been the killer feature that has helped XMPP survive a long time albeit not to prosper. Unless the problem of convergence is solved this will haunt evolving distributed networks no matter how strongly they start.

Arathorn 8y ago
Matrix is very extensible too; it's just that we aim to merge extensions as rapidly as possible into the core monolithic spec, rather than having them get fragmented into optional extensions.
- dnel 8y ago
  I wonder what happens when there's 10 implementations of the matrix spec controlled by different groups. Being able to indicate where the implementation gap is seems like a strength rather than a weakness.
  - Arathorn 8y ago
    Hm, even when there are 10 different server implementations (or the ~50 client implementations there are today), we’d hope they would align to the same spec - just as with HTTP, SMTP, TCP/IP etc. There’s room for experimentation without introducing fragmentation, and any useful experiments would hopefully rapidly get merged into the spec. And if they don’t then yes, you risk a fork on that particular feature (the equivalent of only Exchange supporting email recalls, or browser vendor extensions), but it’s not the end of the world.
    - seba_dos1 8y ago
      I'm not sure if there's really a place around for an IM network that's moving forward about as fast as HTTP, SMTP and TCP/IP are :)
    - dnel 8y ago
      it really depends, if the features are difficult to implement it may not be very quick at all, we see this with XMPP often where features take years to implement or never appear. If a homeserver targets a particular use-case then they may actively choose to ignore certain features that are not relevent. Really when people talk about the flaws of XMPP they often have in mind the problems of private e2e encrypted chat on mobile which is a hard problem to crack, but there's many more private servers inside organisations that don't even federate and work fine for how they are used. This flexibility perhaps makes it better to view XMPP as a toolkit for building networks out of, similar to how IRC networks which have a converged set of servers but outside that network all bets are off. The idea of viewing XMPP as a single network inevitably causes it to look fragmented but there are pockets within the network that interoperate just fine they just don't identify themselves as a group.
heavenlyhash 8y ago
The thing is... with XMPP, it's things that are really, utterly critical like the concept of messages having IDs that are left in the "extensions". You can't build a sane protocol when something like "IDs" are a complete fend-for-yourself wilderness. I've written about this previously: https://news.ycombinator.com/item?id=12908619 https://news.ycombinator.com/item?id=12908619 Long story short, if you ever try to implement something in XMPP/XEPs, you'll learn the hard way why it never seems to gain any traction. Very, very quickly. There are real technical reasons. Extensibility is good. I believe the Matrix developers when they say it's extensible. (I've been a user for several years now. Features regularly get added in backwards-compatible and smooth ways.) Extensibility in the way XMPP tried to go about it -- for patching over core inadequacies of the basic protocol -- is not the same beast.
- NoGravitas 8y ago
  What would really help with XMPP is some idea of profiles - like a Jabber2018 profile that requires all of the XEPs used by Conversations[0]. That way, client and server implementers would know exactly what they need to be compliant with other implementations using the same profile. [0]: https://conversations.im/ https://conversations.im/
  - MattJ100 8y ago
    That exists. Here are the 2018 profiles (they are split into basic/advanced): https://xmpp.org/extensions/xep-0387.html https://xmpp.org/extensions/xep-0387.html They are only part of the solution however because: - Open-source projects are developed by volunteers, and implement what their users (actually typically their developers) want implemented. Having a document that says "you should implement these things" is good for guidance, but it doesn't magically get them implemented. - Commercial projects will implement the things that they can get revenue from. Having a document that says "you should implement these things" doesn't magically make those things earn the company money. E.g. in the open-source category, Pidgin is the classic example of a once-popular client that has fallen behind (with feature requests for some "new" protocol features open on their bug tracker for many many years). The document doesn't fix this part. But yes, I do agree it's an essential part of solving the problem.

by dnel 8y ago

Arathorn 8y ago

Matrix is very extensible too; it's just that we aim to merge extensions as rapidly as possible into the core monolithic spec, rather than having them get fragmented into optional extensions.

dnel 8y ago
I wonder what happens when there's 10 implementations of the matrix spec controlled by different groups. Being able to indicate where the implementation gap is seems like a strength rather than a weakness.
- Arathorn 8y ago
  Hm, even when there are 10 different server implementations (or the ~50 client implementations there are today), we’d hope they would align to the same spec - just as with HTTP, SMTP, TCP/IP etc. There’s room for experimentation without introducing fragmentation, and any useful experiments would hopefully rapidly get merged into the spec. And if they don’t then yes, you risk a fork on that particular feature (the equivalent of only Exchange supporting email recalls, or browser vendor extensions), but it’s not the end of the world.
  - seba_dos1 8y ago
    I'm not sure if there's really a place around for an IM network that's moving forward about as fast as HTTP, SMTP and TCP/IP are :)
  - dnel 8y ago
    it really depends, if the features are difficult to implement it may not be very quick at all, we see this with XMPP often where features take years to implement or never appear. If a homeserver targets a particular use-case then they may actively choose to ignore certain features that are not relevent. Really when people talk about the flaws of XMPP they often have in mind the problems of private e2e encrypted chat on mobile which is a hard problem to crack, but there's many more private servers inside organisations that don't even federate and work fine for how they are used. This flexibility perhaps makes it better to view XMPP as a toolkit for building networks out of, similar to how IRC networks which have a converged set of servers but outside that network all bets are off. The idea of viewing XMPP as a single network inevitably causes it to look fragmented but there are pockets within the network that interoperate just fine they just don't identify themselves as a group.

heavenlyhash 8y ago

The thing is... with XMPP, it's things that are really, utterly critical like the concept of messages having IDs that are left in the "extensions". You can't build a sane protocol when something like "IDs" are a complete fend-for-yourself wilderness. I've written about this previously: https://news.ycombinator.com/item?id=12908619 https://news.ycombinator.com/item?id=12908619 Long story short, if you ever try to implement something in XMPP/XEPs, you'll learn the hard way why it never seems to gain any traction. Very, very quickly. There are real technical reasons. Extensibility is good. I believe the Matrix developers when they say it's extensible. (I've been a user for several years now. Features regularly get added in backwards-compatible and smooth ways.) Extensibility in the way XMPP tried to go about it -- for patching over core inadequacies of the basic protocol -- is not the same beast.

NoGravitas 8y ago
What would really help with XMPP is some idea of profiles - like a Jabber2018 profile that requires all of the XEPs used by Conversations[0]. That way, client and server implementers would know exactly what they need to be compliant with other implementations using the same profile. [0]: https://conversations.im/ https://conversations.im/
- MattJ100 8y ago
  That exists. Here are the 2018 profiles (they are split into basic/advanced): https://xmpp.org/extensions/xep-0387.html https://xmpp.org/extensions/xep-0387.html They are only part of the solution however because: - Open-source projects are developed by volunteers, and implement what their users (actually typically their developers) want implemented. Having a document that says "you should implement these things" is good for guidance, but it doesn't magically get them implemented. - Commercial projects will implement the things that they can get revenue from. Having a document that says "you should implement these things" doesn't magically make those things earn the company money. E.g. in the open-source category, Pidgin is the classic example of a once-popular client that has fallen behind (with feature requests for some "new" protocol features open on their bug tracker for many many years). The document doesn't fix this part. But yes, I do agree it's an essential part of solving the problem.