5 ms·

This is a very poor comparison - just off the cuff, most of the big negatives listed for Matrix are plainly untrue. The most irritating probably being it saying

This is a very poor comparison - just off the cuff, most of the big negatives listed for Matrix are plainly untrue. The most irritating probably being it saying that Matrix is not an open extensible protocol, where it very much is. The core protocol undergoes evolution through an open, standardized process that anyone can participate in, shepherded by a separate foundation. The protocol itself, based around JSON, allows clients to define new event types (for instance, the Telegram bridge uses a special event type for when someone on Telegram replies to a message with an image) without the server having to understand them. Also, why is its encryption yellow? It's a solid design that's undergone paid independent review, based upon Signal's e2ee. There's more, but I since editing isn't open to the public I don't suppose its worth expending more effort to fix and argue with.

rektide 5y ago
A process that defines how to build a single, core, monolithic protocol is not extensible. No matter how open the development process. Ultimately to advance Matrix you need to get the Matrix devs to check off on your work and it has to be built in to the Matrix protocol. The whole point of extensibility is permissionlessness & ability to work off core. For some reason Matrix advocates keep thinking they have some claims to say Matrix is extensible, and they're wrong.
- joepie91_ 5y ago
  This is false. The specification allows for you to define custom event types and fields in most places, and even specifies the naming conventions for doing so. There exists no requirement for it to be absorbed into the Matrix specification itself. This is really no different than for XMPP. XEPs are also centrally managed, and you are expected to implement any proprietary extensions outside of that process.
  - rektide 5y ago
    That's good, & goes a long way, but it's still a fixed protocol defined in a monolithic spec. XEPs are different in that they are independent (except explicit depedencies) of each other & not a part of the core spec. If someone wants to start adding new transports, add Link Local xmpp: they can. Just write the XEP (XEP-0174). Whatever custom event types & fields there are in Matrix, it has no where near this level of extensibility.
    - miloignis 5y ago
      I'm not sure that the existence of a core spec negates this though - you could similarly write an MSC for whatever thing you wanted, like a new low-bandwidth transport using CoAP and CBOR (MSC3079 - https://github.com/matrix-org/matrix-doc/pull/3079 https://github.com/matrix-org/matrix-doc/pull/3079) and it may or may not end up being accepted into the core spec, but the MSC exists regardless and people can implement it. (and indeed, people often implement MSCs that they like before they land in the core spec, and before something lands you generally want an implementation or two anyway)
- Yoric 5y ago
  I've been using Matrix with non-standard events to communicate between bots. Works nicely. Between that and the standardization process, what else would you want?

rektide 5y ago

A process that defines how to build a single, core, monolithic protocol is not extensible. No matter how open the development process. Ultimately to advance Matrix you need to get the Matrix devs to check off on your work and it has to be built in to the Matrix protocol. The whole point of extensibility is permissionlessness & ability to work off core. For some reason Matrix advocates keep thinking they have some claims to say Matrix is extensible, and they're wrong.

joepie91_ 5y ago
This is false. The specification allows for you to define custom event types and fields in most places, and even specifies the naming conventions for doing so. There exists no requirement for it to be absorbed into the Matrix specification itself. This is really no different than for XMPP. XEPs are also centrally managed, and you are expected to implement any proprietary extensions outside of that process.
- rektide 5y ago
  That's good, & goes a long way, but it's still a fixed protocol defined in a monolithic spec. XEPs are different in that they are independent (except explicit depedencies) of each other & not a part of the core spec. If someone wants to start adding new transports, add Link Local xmpp: they can. Just write the XEP (XEP-0174). Whatever custom event types & fields there are in Matrix, it has no where near this level of extensibility.
  - miloignis 5y ago
    I'm not sure that the existence of a core spec negates this though - you could similarly write an MSC for whatever thing you wanted, like a new low-bandwidth transport using CoAP and CBOR (MSC3079 - https://github.com/matrix-org/matrix-doc/pull/3079 https://github.com/matrix-org/matrix-doc/pull/3079) and it may or may not end up being accepted into the core spec, but the MSC exists regardless and people can implement it. (and indeed, people often implement MSCs that they like before they land in the core spec, and before something lands you generally want an implementation or two anyway)
Yoric 5y ago
I've been using Matrix with non-standard events to communicate between bots. Works nicely. Between that and the standardization process, what else would you want?