diff --git a/configuration/sources/modular-matrix/index.html b/configuration/sources/modular-matrix/index.html
index e43703b..e55ece0 100644
--- a/configuration/sources/modular-matrix/index.html
+++ b/configuration/sources/modular-matrix/index.html
@@ -8,16 +8,44 @@
Modular Matrix
- NOTE: If you're looking for the Matrix website, go to Matrix.org. If you're looking for the Matrix hosting service, go to Modular.im. This project is not affiliated with either of those two.
+ 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.
Hi! This will eventually be the website for Modular Matrix, a project to build a modular JavaScript SDK for the Matrix protocol, as an alternative to the matrix-js-sdk.
- Currently there's not really anything here yet, though you can have a look at the already-published packages if you're curious about how things are going.
+ 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.
+