3 ms·

I love the idea behind Matrix and dearly want it to succeed, but unlike IRC and XMPP as well as (to a lesser extent) email and netnews, it has the inherent prob

I love the idea behind Matrix and dearly want it to succeed, but unlike IRC and XMPP as well as (to a lesser extent) email and netnews, it has the inherent problem that it implements a genuinely difficult thing: a large partition-tolerant distributed database without a central authority and even a bit of mistrust between nodes. Now that I’ve put this in writing, I wonder if there were any attempts to do this at all before the current generation of systems. (IRC and netnews basically YOLO their consistency away because they can’t afford it, which was indeed correct when they were designed, but people did a lot of distributed systems work between then and now...) That implies that a Matrix server is necessarily somewhat heavy and rather difficult to implement. This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..) I’ve spent a very limited time studying the situation so I am not going to make any dire-sounding prophecies; besides, I actively don’t want any such prophecies to come true. What I am is worried. It doesn’t take much for a protocol to become a non-interoperable tangle of implementation details, and Matrix is an extraordinarily ambitious one.

remirk 5y ago
I agree that Matrix is quite complicated. However, adding new features doesn't have to make it that more complicated. I get the impression that it's not that bad as most new features are actually based on existing parts of the protocol. Everything is just based on events in a room. Most 'special' events have a fallback mechanism to text, to insure clients that haven't implemented the event type can still show the information to the user. Replies and stickers make use of this for instance.
- mananaysiempre 5y ago
  Short and harsh (likely too harsh): My point is not that Matrix is complicated, thus we should avoid making it more so. My point is that the approach that Matrix chooses, even in its most minimal form, requires Matrix to be complex and resource-hungry, thus it seems prudent to direct attention and effort towards cultivating a multitude of implementations and deployments rather than enhancing marketability. A social argument against features, not the standard technical one.
  - remirk 5y ago
    I was replying to > The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. I don't agree the growing features is an issue.
    - mananaysiempre 5y ago
      We are in agreement as to which part you were replying to, then :) > I don't agree the growing features is an issue. And I’m not arguing that it’s an issue in itself, either. I’m arguing that it is an issue when allocated development effort in preference to growing an ecosystem, because Matrix is both (inherently) bound to have an difficult time at it and (factually) not in a good place right now from that point of view. And that is my perception of the protocol developers’ priorities. (Once there are a half-dozen independent server implementations and a decent number of clients, all with reasonably complete coverage of the current spec, this argument becomes irrelevant, so I’m not pleading featuritis here.)
kitkat_new 5y ago
Are you referring to Fractal? If so, it doesn't look like it has been given up on: https://gitlab.gnome.org/GNOME/fractal https://gitlab.gnome.org/GNOME/fractal
- mananaysiempre 5y ago
  Yes. (Looks closely.) Ouch, I wanted to reference to its state “a couple of months ago” when I looked at it, but looks like it has been half a year at least. My calendar is completely out of order it seems. In any case, it’s encouraging to hear that the development (well... rewrite) is proceeding along and E2EE is once more on the roadmap. But my point still stands, partly, because the developers have given up on implementing the protocol on their own, see e.g. https://gitlab.gnome.org/GNOME/fractal/-/commit/6bcb5e9 https://gitlab.gnome.org/GNOME/fractal/-/commit/6bcb5e9 (announcement of switch to matrix.org SDK).
Arathorn 5y ago
> This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..) It's one thing to be uncharitable; it's another thing to be spouting stuff which is demonstrably false. There are three usable server implementations participating in the network; synapse, dendrite and conduit (four, if you include construct). Synapse runs fine on a VPS with 2-4GB of RAM for almost all personal usage patterns, so snark about "servers you can afford" is BS. In addition to that we reduced its RAM footprint by 2-3x over the last few months (https://twitter.com/matrixdotorg/status/1434912387933560837 https://twitter.com/matrixdotorg/status/1434912387933560837). The GNOME Fractal team hasn't given up at all - they just chose to rewrite the app for Gtk4, shifted to using matrix-rust-sdk in order to focus on the GUI layer and have been busier than ever. Meanwhile, there are tens of other implementations - a non-exhaustive list of the clients and SDKs today implementing E2EE is: * Separate core team implementations: * matrix-js-sdk (TypeScript) * Element Web * SchildiChat * Cinny * Thunderbird * matrix-ios-sdk (ObjC) * Element iOS * Nio * Seaglass (on hold) * matrix-android-sdk2 (Kotlin) * Element Android * SchildiChat Android * matrix-android-sdk (Java), obsolete * Riot Android * matrix-rust-sdk (Rust) * “Corroded” Element Android * Weechat-rs * Fractal * Daydream (archived) * Hydrogen SDK (JavaScript) * Hydrogen * Independent community implementations: * famedly-sdk (Dart) * FluffyChat (Web, Android, iOS) * matrix-nio (Python) * pantalaimon * weechat-matrix * mirage * mtxclient (C++) * nheko * mautrix (go) * gomuks * syphon (Dart) * chatty (C) * matrix-bot-sdk (TypeScript) * TeamSpeak 5 (proprietary) * purple-matrix (C) (incomplete) > I’ve spent a very limited time studying the situation This is clear.

remirk 5y ago

I agree that Matrix is quite complicated. However, adding new features doesn't have to make it that more complicated. I get the impression that it's not that bad as most new features are actually based on existing parts of the protocol. Everything is just based on events in a room. Most 'special' events have a fallback mechanism to text, to insure clients that haven't implemented the event type can still show the information to the user. Replies and stickers make use of this for instance.

mananaysiempre 5y ago
Short and harsh (likely too harsh): My point is not that Matrix is complicated, thus we should avoid making it more so. My point is that the approach that Matrix chooses, even in its most minimal form, requires Matrix to be complex and resource-hungry, thus it seems prudent to direct attention and effort towards cultivating a multitude of implementations and deployments rather than enhancing marketability. A social argument against features, not the standard technical one.
- remirk 5y ago
  I was replying to > The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. I don't agree the growing features is an issue.
  - mananaysiempre 5y ago
    We are in agreement as to which part you were replying to, then :) > I don't agree the growing features is an issue. And I’m not arguing that it’s an issue in itself, either. I’m arguing that it is an issue when allocated development effort in preference to growing an ecosystem, because Matrix is both (inherently) bound to have an difficult time at it and (factually) not in a good place right now from that point of view. And that is my perception of the protocol developers’ priorities. (Once there are a half-dozen independent server implementations and a decent number of clients, all with reasonably complete coverage of the current spec, this argument becomes irrelevant, so I’m not pleading featuritis here.)

kitkat_new 5y ago

Are you referring to Fractal? If so, it doesn't look like it has been given up on: https://gitlab.gnome.org/GNOME/fractal https://gitlab.gnome.org/GNOME/fractal

mananaysiempre 5y ago
Yes. (Looks closely.) Ouch, I wanted to reference to its state “a couple of months ago” when I looked at it, but looks like it has been half a year at least. My calendar is completely out of order it seems. In any case, it’s encouraging to hear that the development (well... rewrite) is proceeding along and E2EE is once more on the roadmap. But my point still stands, partly, because the developers have given up on implementing the protocol on their own, see e.g. https://gitlab.gnome.org/GNOME/fractal/-/commit/6bcb5e9 https://gitlab.gnome.org/GNOME/fractal/-/commit/6bcb5e9 (announcement of switch to matrix.org SDK).

Arathorn 5y ago

> This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..) It's one thing to be uncharitable; it's another thing to be spouting stuff which is demonstrably false. There are three usable server implementations participating in the network; synapse, dendrite and conduit (four, if you include construct). Synapse runs fine on a VPS with 2-4GB of RAM for almost all personal usage patterns, so snark about "servers you can afford" is BS. In addition to that we reduced its RAM footprint by 2-3x over the last few months (https://twitter.com/matrixdotorg/status/1434912387933560837 https://twitter.com/matrixdotorg/status/1434912387933560837). The GNOME Fractal team hasn't given up at all - they just chose to rewrite the app for Gtk4, shifted to using matrix-rust-sdk in order to focus on the GUI layer and have been busier than ever. Meanwhile, there are tens of other implementations - a non-exhaustive list of the clients and SDKs today implementing E2EE is: * Separate core team implementations: * matrix-js-sdk (TypeScript) * Element Web * SchildiChat * Cinny * Thunderbird * matrix-ios-sdk (ObjC) * Element iOS * Nio * Seaglass (on hold) * matrix-android-sdk2 (Kotlin) * Element Android * SchildiChat Android * matrix-android-sdk (Java), obsolete * Riot Android * matrix-rust-sdk (Rust) * “Corroded” Element Android * Weechat-rs * Fractal * Daydream (archived) * Hydrogen SDK (JavaScript) * Hydrogen * Independent community implementations: * famedly-sdk (Dart) * FluffyChat (Web, Android, iOS) * matrix-nio (Python) * pantalaimon * weechat-matrix * mirage * mtxclient (C++) * nheko * mautrix (go) * gomuks * syphon (Dart) * chatty (C) * matrix-bot-sdk (TypeScript) * TeamSpeak 5 (proprietary) * purple-matrix (C) (incomplete) > I’ve spent a very limited time studying the situation This is clear.