6 ms·
This is false. The specification allows for you to define custom event types and fields in most places, and even specifies the naming conventions for doing so.
by joepie91_ 5y ago
This is false. The specification allows for you to define custom event types and fields in most places, and even specifies the naming conventions for doing so. There exists no requirement for it to be absorbed into the Matrix specification itself.
This is really no different than for XMPP. XEPs are also centrally managed, and you are expected to implement any proprietary extensions outside of that process.
- rektide 5y agoThat's good, & goes a long way, but it's still a fixed protocol defined in a monolithic spec. XEPs are different in that they are independent (except explicit depedencies) of each other & not a part of the core spec. If someone wants to start adding new transports, add Link Local xmpp: they can. Just write the XEP (XEP-0174). Whatever custom event types & fields there are in Matrix, it has no where near this level of extensibility.
- miloignis 5y agoI'm not sure that the existence of a core spec negates this though - you could similarly write an MSC for whatever thing you wanted, like a new low-bandwidth transport using CoAP and CBOR (MSC3079 - https://github.com/matrix-org/matrix-doc/pull/3079 https://github.com/matrix-org/matrix-doc/pull/3079) and it may or may not end up being accepted into the core spec, but the MSC exists regardless and people can implement it. (and indeed, people often implement MSCs that they like before they land in the core spec, and before something lands you generally want an implementation or two anyway)