NOTE: If you're looking for the Matrix website, go to Matrix.org. If you're looking for the commercial Matrix hosting service, go to Modular.im. This project is not affiliated with either of those two.
Currently there's not much here yet, though you can have a look at the already-published packages if you're curious about how things are going.
You can contact me on Matrix as @joepie91:pixie.town.
Primary design goals
These are not the *only* goals, but they are the most important ones, and the ones that are most often overlooked in library design.
Modularity. It should be possible to build weird experimental things that don't look like a typical Matrix client or server, without having to pull in a lot of complexity you don't need, or having to hack into SDK internals. Therefore, Modular Matrix primarily consists of a lot of small, single-responsibility modules, that can be used in isolation.
Exhaustive documentation. There shouldn't be a single undocumented thing in the external API. All modules are fully documented; including examples, API reference, high-level concepts, and gotchas to watch out for.
Readability. Ideally, it should be possible to learn the Matrix protocol by reading the implementation.
Maintainability. It should always be possible to understand how the implementation approaches a particular problem, both from a high-level perspective and from an implementation-details perspective. It should always be obvious which part of the code to change, to correctly solve a problem.
Reliability. Semantic versioning is followed. APIs are, where possible, designed in a way that is hard to misuse. All library errors have clearly distinct types and metadata, so that you don't need catch-alls.
The common theme here is that Modular Matrix is designed to be human-friendly. It's not about clever technical hacks or micro-optimized implementations that exploit runtime specifics, but about creating a set of libraries that are pleasant to work with and don't yield unpleasant surprises.