thoughts about how the protocol could be split up

the room-module approach

if not all features are needed for all usecases, perhaps making a way for
features to be added on top, maybe like a smart-contract sort of thing,
would be idea . they could run sandboxed in an environment like wasi, making
web compatibility easy, and if they could be defined at the begining of the
room, as an idea . this has the drawback of making things potentially harder
to understand and federate to matrix, but not necesarrily, this could
definitely work and be a good approach, as it would allow users to setup any
moderation rules they wanted, as an example, allowing for things even like,
consensus moderation, or other forms of decentralized moderation, as an
example

the extensions approach

the extendable approach is more like, have a base protocol that is needed to
support all usecases, and then add additional things the server / client can
support to allow for different use cases, like chatting, or whatever, this
has the drawback of making things more segmented though, but it has the
advantage of being simpler, and allowing things to be defined in advance,
and compatibile servers will know how to handle these things

the flexible approach

the flexible approach is not really to split them at all, as the client parts of
the spec, are still included in the protocol, all that is really split up
here, is that the protocol allows for unofficial extensions, by simply
making the protocol rather flexible, but this allows clients to perform a
lot of undefined behaviour, so long as it does not require any server-side
validation