[remirk]

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]

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]

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]

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.)