Adjust spec to differentiate between Rooms, DMs, and Spaces, such that ACLs and settings can be defined for each independently.

It seems that settings relevant to this scope have been added/removed/changed over the years, and I want to advocate for more substantial and concrete controls over Rooms, DMs (Direct Messages), and Spaces. Such that Matrix servers can have the means to define permissions for each of them independently.

My example use case is an isolated Matrix environment (in this case Synapse) whereby there's no federation, it is internally accessible only, leverages authentication external to Matrix (LDAP, so there are no local accounts within Matrix), and who can do what needs to be fine-grained.

In this use-case it does not seem to be possible to limit who can create rooms, without at the same time limiting who can create Direct Messages. And I also don't see a mechanism to limit whether spaces are enabled/disabled, and who can/can't create them, to any degree.

It is reasonable that in a controlled environment only specific users can create rooms, but users at-large can direct message each other (but also limiting those to only 1:1 only rooms, never able to add other people). Additionally it is reasonable for spaces to be completely disabled in environments like these, as they add no value but can create problems by users thinking it's "okay" to create more spaces, but that can lead to undesirable administrative overhead.

If we explore how similar things are handled in other communications technologies, such as IRC, Discord, Mumble, and other common communications apps, we can see there is not only a desire for these types of controls, that they are reasonable when properly implemented and applied.

In the example use case above, the justification for who can create rooms is to limit the nature of the environment to specifically the rooms as defined. Users being able to create rooms "waters down" those objectives by creating loosely-structured and organised rooms that do not conform to the intent of those trying to operate the ecosystem. Same thing for Spaces. However there is still reasonable desire to allow 1:1 only DMs.

As such, I propose that the Matrix spec be improved to enable these desires.

1. The ability to control who can create rooms, without influencing who can create DMs and who can create Spaces.
2. The ability to fully disable Spaces.
3. The ability to control who can create Spaces.
4. The ability to turn DMs into 1:1 only functionality environment-wide.
5. Maybe something else I missed but described above.

I know that if this gains traction it can take time to implement and roll-out at large, but a lot of this is stuff that has been asked for, for many years now. I see a lot of discussions in multiple forums on the internet with zero solutions available that properly meet these needs. I think it's about time this gap in functionality within the Matrix ecosystem (relative to other communications ecosystems) finally be... bridged.

So, can we please get some momentum started on this?

Thanks!

No file or test is named. Start by reviewing the current Matrix specification sections governing room creation, Direct Messages, Spaces, and permissions, then read the existing issue discussion. Done means the specification defines concrete, independently enforceable controls for the requested room, DM, and Space behaviors, with scope and compatibility questions resolved.