6 ms·

You say Matrix is not a protocol, and then you go on and compare it to another protocol. By your own logic, you are comparing apples and oranges here. Make up y

by pferde 5y ago

You say Matrix is not a protocol, and then you go on and compare it to another protocol. By your own logic, you are comparing apples and oranges here. Make up your mind, either it is a protocol or it isn't. Oh, and Matrix is plenty extensible, for example via custom event types: https://spec.matrix.org/v1.1/client-server-api/#types-of-room-events https://spec.matrix.org/v1.1/client-server-api/#types-of-roo...

Andrew_nenakhov 5y ago
Matrix is a product developed by one entity that can be installed on premise and has an api. Different instances can communicate with each other. Mattermost also has it but we don't call it a protocol.
- Arathorn 5y ago
  This is just not true. There are four main Matrix server implementations today: Synapse, Dendrite, Conduit and Construct. Conduit & Construct are written by entirely independent different parties; all four share zero code; and yet they all can communicate together (modulo beta-ness in some places). (And aside from that, Mattermost doesn't have federation; different instances can not communicate with each other. Although we hope they'll implement Matrix eventually :)
  - Andrew_nenakhov 5y ago
    Both third party implementations have beta status and all entirely independent implementations will be screwed and will stop working each time you decide to significantly change the spec in your monolithic protocil. I know, you consider xep structure of XMPP to be a problem, 'because it is hard to orient in it', but in fact it is what makes XMPP so durable and capable to work in a real federated environment.
    - gefhfff 5y ago
      Matrix is working in a real federated environment between hundreds of servers
      - Andrew_nenakhov 5y ago
        ... between server instances provided by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1]. I can see zero problems with this decisive approach. /s [1]: https://news.ycombinator.com/item?id=19421978 https://news.ycombinator.com/item?id=19421978
        gefhfff 5y ago
        > between server instances provided by a single dominant vendor No, any server instances provided by any vendor > by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1]. Server instance provider is not the same as software provider. Of course, you fall behind if you don't update. Time progresses, so does software.
        Andrew_nenakhov 5y ago
        > Of course, you fall behind if you don't update In proper federated networks (email, xmpp), you don't.
        gefhfff 5y ago
        Define proper :D What I value with Matrix is progress
        Andrew_nenakhov 5y ago
        What you perceive as progress is just a sign of immaturity of an ecosystem. One player will ALWAYS move faster because he doesn't have to check with other participants, single-handedly self-defining specs and implementing them in own software. But reliance on this model will never allow another participants to enter, and it will always be a one-vendor vehicle. Proper federated networks are ones that are already past this initial phase of fast progress and where participants have learned to work with each other.

by pferde 5y ago

Andrew_nenakhov 5y ago

Matrix is a product developed by one entity that can be installed on premise and has an api. Different instances can communicate with each other. Mattermost also has it but we don't call it a protocol.

Arathorn 5y ago
This is just not true. There are four main Matrix server implementations today: Synapse, Dendrite, Conduit and Construct. Conduit & Construct are written by entirely independent different parties; all four share zero code; and yet they all can communicate together (modulo beta-ness in some places). (And aside from that, Mattermost doesn't have federation; different instances can not communicate with each other. Although we hope they'll implement Matrix eventually :)
- Andrew_nenakhov 5y ago
  Both third party implementations have beta status and all entirely independent implementations will be screwed and will stop working each time you decide to significantly change the spec in your monolithic protocil. I know, you consider xep structure of XMPP to be a problem, 'because it is hard to orient in it', but in fact it is what makes XMPP so durable and capable to work in a real federated environment.
  - gefhfff 5y ago
    Matrix is working in a real federated environment between hundreds of servers
    - Andrew_nenakhov 5y ago
      ... between server instances provided by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1]. I can see zero problems with this decisive approach. /s [1]: https://news.ycombinator.com/item?id=19421978 https://news.ycombinator.com/item?id=19421978
      - gefhfff 5y ago
        > between server instances provided by a single dominant vendor No, any server instances provided by any vendor > by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1]. Server instance provider is not the same as software provider. Of course, you fall behind if you don't update. Time progresses, so does software.
        Andrew_nenakhov 5y ago
        > Of course, you fall behind if you don't update In proper federated networks (email, xmpp), you don't.
        gefhfff 5y ago
        Define proper :D What I value with Matrix is progress
        Andrew_nenakhov 5y ago
        What you perceive as progress is just a sign of immaturity of an ecosystem. One player will ALWAYS move faster because he doesn't have to check with other participants, single-handedly self-defining specs and implementing them in own software. But reliance on this model will never allow another participants to enter, and it will always be a one-vendor vehicle. Proper federated networks are ones that are already past this initial phase of fast progress and where participants have learned to work with each other.