[this_user]

I think their main issue is that they seem to have no one who is seriously looking at the Matrix ecosystem from a product perspective. You have all of these pieces of technology in various states of maturity that more or less fit together if you know what you are doing. But there is also a lot of friction and a lot of things breaking on a regular basis etc.

What the project needs is someone who looks at it from a customer perspective and who can direct resources to make sure the entire thing is packaged as one consistent thing that does what the customer needs.

If you install WA or Signal, or if you sign up to Slack, you don't have to wonder which home server you should install and which of a dozen or so available clients you should use and what features are not yet production ready. Instead, it just works.

[Teever]

The lack of attention that you identify is a real issue with the project but the root issue is ultimately a lack of sufficient funding that would enable all these parts to receive the attention that they require.

Funding fixes all these problems and it has to come from big governmental and institutional players in Europe who are motivated by ending their reliance on American companies like Microsoft.

[noirscape]

I think a product focus does exist: Element seems to be a genuine attempt to fully assemble Matrix as one full project. The problem is that it feels like the Element devs are stuck wanting to have their cake and eat it too.

There's some design choices in Matrix that don't really "fit" with what modern messaging infrastructure looks like. (Which to summarize it pretty quickly is a Slack/Discord-esque model, where non-sysadmin users get to fully administer their own spaces, with an expectation for multiple different channels, control over user permissions and user access and so on and so forth.)

Some of these come from the fact that Matrix is pretty blatantly just designed as "what if IRC, but slightly more modern". It's main unit for non-sysadmin moderation is a single channel, with the expectation that one instance of Matrix will never have two channels named #general (as an example). Similarly, it's entirely possible to kick users from a channel... but then have that exact same channel continue independently on a different instance, but under a different label. This makes sense if you look at it as "supercharged IRC", but becomes a complete and utter mess when you factor in things like the encryption between two servers suddenly disagreeing with each other (leading to a bunch of old messages becoming unreadable), content moderation (barely an issue on IRC because message retention is expected to be almost entirely clientside) and so on and so forth.

Element/synapse's people do try to provide for these cases, but you're effectively stuck trying to prod at admin API endpoints, bots to synchronize moderation decisions and they have like 3 different "channel grouping" that's supposed to be their version of the Slack workspace/Discord guild model.

Honestly though, I'm pretty sure that once XMPP gets a proper multi-user multi-channel XEP going (there's one in draft right now which specifically tries to provide workspace-esque support; it's possible to do this already but it's a sysadmin XEP, the proposal aims to give this capability to regular users), it'll just end up blowing Matrix out of the water entirely for most usecases. Unlike Matrix, it's a far more mature protocol that's a lot easier to work with and actually has many different implementations that you can choose from.

[ptman]

Room addresses/aliases (like #matrix:matrix.org) must point to a single room (in fact, they point to a room version, so when rooms are upgraded, addresses must be pointed towards the new room). But for communities, a better way to organize the rooms would be spaces. Spaces can be joined. Spaces can contain rooms and other spaces. Like discord "servers" (guilds), but more flexible.