<em><strong>NOTE:</strong> If you're looking for the Matrix website, go to <ahref="https://matrix.org">Matrix.org</a>. If you're looking for the Matrix hosting service, go to <ahref="https://modular.im/">Modular.im</a>. This project is not affiliated with either of those two.</em>
<em><strong>NOTE:</strong> If you're looking for the Matrix website, go to <ahref="https://matrix.org">Matrix.org</a>. If you're looking for the commercial Matrix hosting service, go to <ahref="https://modular.im/">Modular.im</a>. This project is not affiliated with either of those two.</em>
</p>
<p>
Hi! This will eventually be the website for Modular Matrix, a project to build a modular JavaScript SDK for the <ahref="https://matrix.org">Matrix protocol</a>, as an alternative to the <code>matrix-js-sdk</code>.
</p>
<p>
Currently there's not really anything here yet, though you can have a look at the <ahref="https://www.npmjs.com/org/modular-matrix?tab=packages">already-published packages</a> if you're curious about how things are going.
Currently there's not much here yet, though you can have a look at the <ahref="https://www.npmjs.com/org/modular-matrix?tab=packages">already-published packages</a> if you're curious about how things are going.
</p>
<p>
You can contact me on Matrix as <ahref="https://matrix.to/#/@joepie91:pixie.town">@joepie91:pixie.town</a>.
</p>
<h2>Primary design goals</h2>
<p>
These are not the *only* goals, but they are the most important ones, and the ones that are most often overlooked in library design.
</p>
<ul>
<li>
<strong>Modularity.</strong> 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.
</li>
<li>
<strong>Exhaustive documentation.</strong> There shouldn't be a single undocumented thing in the external API. All modules are <em>fully documented</em>; including examples, API reference, high-level concepts, and gotchas to watch out for.
</li>
<li>
<strong>Readability.</strong> Ideally, it should be possible to learn the Matrix protocol by reading the implementation.
</li>
<li>
<strong>Maintainability.</strong> 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.
</li>
<li>
<strong>Reliability.</strong> 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.
</li>
</ul>
<p>
The common theme here is that Modular Matrix is designed to be <em>human-friendly</em>. It's not about clever technical hacks or micro-optimized implementations that exploit runtime specifics, but about creating a set of libraries that are <em>pleasant to work with</em> and don't yield unpleasant surprises.
