I started Telodendria 1 because I wasn't happy with any of the other Matrix homeserver implementations. Simply put, the state of Matrix homeserver implementations is kind of sad, and maybe that speaks to a flaw with the Matrix specification—though that's a topic for another discussion.
I say the state of the Matrix homeserver ecosystem is sad because (1) there aren't a lot of viable options, and (2) the only viable options are not that great for me.
At the time of writing, the official Matrix website lists the following homeserver implementations:
This seems like a large list of homeserver implementations, but when we break it down, here's what we find:
So it looks like our list is down to just these four options:
We have a few different programming languages represented in this list of potential homeserver solutions. Conduit is written in Rust, Dendrite is written in Go, and Synapse is written in Python and Rust. This means that out of the box, I already need to install one or more compilers before I can even try to build the code for these homeservers. Synapse is the worst, because it requires both Python and Rust.
To me, Rust, Python, and Go are simply too large of dependencies to have on my production server. Additionally, they all make pulling in dependencies from unaudited sources too easy. so I immediately rule them out for being too bloated and insecure. That leaves me with Construct, which is written in C++. While I'd prefer C, I'm actually not opposed to C++, because the compiler that ships with my operating system does support C++.
Construct looks nice at first glance; it is actively maintained, written in a nice enough language, is licensed under a BSD license, etc. But at this point, we need to talk about what all of these homeserver implementations—including Construct—have in common: a lot of dependencies. Now, I'm not saying they share a lot of dependencies, I'm saying that each project has a very large dependency tree. This means that if I were to download the source code for any one of these projects, I wouldn't be able to do anything with it until I install an absolutely massive amount of compilers, frameworks, and libraries first.
Despite Construct being written in C++, which should theoretically compile just fine on a base OpenBSD, it has the following dependencies which would need to be installed:
These are roughly the Ubuntu packages, which is what Construct mentions on the project wiki. I purposely gave each package its own line to show just how many dependencies this actually is. This prevents Construct from being a viable option for me, because I can't just download the source code, build it, and then have a working Matrix homeserver. I don't want all of these packages on my server. And, unfortunately, Construct is probably on the small side. I highly doubt the other viable Matrix homeserver implementations have fewer dependencies.
So what is a digital minimalist like me to do? Is the Matrix specification just too bloated to allow simple homeservers to exist? Quite possibly, but I do trust that it is reasonably secure, and I think the people that want to stay in contact with me appreciate the ease of use. Either way, I'm invested in Matrix now, so whether it aligns with my views is irrelevant. That being said, I do think it is possible to create a minimal Matrix homeserver that does align with my views.
At least, that's what I'm trying to do with Telodendria. My goal is to make it depend only on the following, and nothing more:
That's it. All three of those things are built into any reasonably
complete Unix-like operating system. Of course, if you're going to
hack on Telodendria, you will also need tools like cvs(1), patch(1),
and indent(1), but all of those are built into any reasonably
complete Unix-like operating system as well.
The reason this whole post has been about dependencies is because dependencies are important. They can be a source of security vulnerabilities, build system breakage, and more. I personally believe that software should have as few dependencies as possible. Software should be simple enough that it doesn't need a lot of dependencies. For some of the largest projects, some dependencies are unavoidable, but for most part, I think dependencies that should be thought about carefully before including them.
I get that Telodendria will never be some sort of free-standing Matrix homeserver. It will always depend on POSIX, C, and TLS. But those things are so well tested and ubiquitous that pretty much every other piece of software that exists depends on them as well, so I hardly see that as a bad thing.
At the end of the day, Telodendria strives to be minimal, as minimal as possible. This makes it lightweight, and small. This also makes it a lot easier to audit. Security vulnerabilities exist only in the code I write, not somebody elses. That appeals to me. It appeals to me that I can download a single tarball, extract it, run the build script, and have a working binary, all on a base OpenBSD install. That's my vision for Matrix, and who knows, maybe Telodendria will be an in-base program that eventually ships with OpenBSD.
All the existing Matrix homeservers aren't practical for me, because
they require so much extra software. I'm trying to prove that a Matrix
homeserver doesn't need all that extra bloat and it can be a standard
system daemon just like httpd(8) or smtpd(8).
If you want to help out, join me at #telodendria-general:bancino.net and
check out the project website!
© 2019-2024 Jordan Bancino.