forked from lda/telodendria
1139 lines
43 KiB
HTML
1139 lines
43 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
|
|
<meta name="author" content="Jordan Bancino">
|
|
<meta name="description"
|
|
content="Telodendria, a Matrix homeserver written in ANSI C.">
|
|
|
|
<meta property="og:title"
|
|
content="Telodendria | A Matrix Homeserver written in ANSI C.">
|
|
<meta property="og:type" content="website">
|
|
<meta property="og:url"
|
|
content="https://telodendria.io">
|
|
<meta property="og:description"
|
|
content="Telodendria, a Matrix homeserver written in ANSI C.">
|
|
|
|
<link rel="stylesheet" href="style.css">
|
|
<link rel="icon" href="assets/Telodendria-196x196.png">
|
|
|
|
<title>Telodendria | A Matrix Homeserver written in ANSI C.</title>
|
|
</head>
|
|
<body>
|
|
<img id="logo" src="assets/Telodendria-500x500.png" alt="Telodendria Logo" />
|
|
<h1 id="telodendria">Telodendria</h1>
|
|
<p>
|
|
<b>Telodendria:</b> The terminal branches of an axon.
|
|
</p>
|
|
<div class="msg-error">
|
|
<b><i>Note:</i></b> <b>Telodendria</b> is under <i>heavy</i> development.
|
|
Please see the <a href="#project-status">Project Status</a>.
|
|
</div>
|
|
<p>
|
|
<b>Telodendria</b> is a Matrix homeserver implementation written from
|
|
scratch in ANSI C. It is designed to be lightweight and simple, yet
|
|
functional. <b>Telodendria</b> differentiates itself from other Matrix
|
|
homeserver implementations because it:
|
|
<ul>
|
|
<li>
|
|
Is written in C, a stable, low-level programming language with a long
|
|
history, low build and runtime overhead, and wide compatibility.
|
|
</li>
|
|
<li>
|
|
Is written with minimalism as a primary design goal. Whenever possible
|
|
and practical, no third-party libraries are pulled in to the source
|
|
code. Everything <b>Telodendria</b> needs is custom written. As a
|
|
result, <b>Telodendria</b> depends only on a standard C compiler and
|
|
POSIX C library to be built, both of which are built in to a good
|
|
Unix-style operating system already, which means you shouldn't have
|
|
to install anything extra.
|
|
</li>
|
|
<li>
|
|
Uses a flat-file directory structure to store data instead of a
|
|
database. This has a number of advantages:
|
|
<ul>
|
|
<li>It makes setup and maintenance much easier.</li>
|
|
<li>
|
|
It allows <b>Telodendria</b> to run on systems with fewer resources.
|
|
</li>
|
|
<li>
|
|
It provides both runtime and data safety and stability. Since no
|
|
database is running, there's fewer things that could go wrong because
|
|
there's a lot less code running on the system.
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
Is packaged as a single small, statically-linked and highly-optimized
|
|
binary that can be run just about anywhere. It is designed to be
|
|
extremely easy to set up and consume as few resources as possible.
|
|
</li>
|
|
<li>
|
|
Is permissively licensed. <b>Telodendria</b> is licensed under a
|
|
modified MIT license, which imposes few restrictions on what you can do with
|
|
it.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
<b>Telodendria</b> is on Matrix! Check out the official Matrix rooms:
|
|
</p>
|
|
<table>
|
|
<tr>
|
|
<th>Room</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>#telodendria-releases:bancino.net</code>
|
|
</td>
|
|
<td>
|
|
Get notified of new releases.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>#telodendria-general:bancino.net</code>
|
|
</td>
|
|
<td>
|
|
General discussion and support for <b>Telodendria</b>.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>#telodendria-issues:bancino.net</code>
|
|
</td>
|
|
<td>
|
|
Report issues with <b>Telodendria</b>.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>#telodendria-patches:bancino.net</code>
|
|
</td>
|
|
<td>
|
|
Submit code patches to the <b>Telodendria</b> project.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<h2 id="table-of-contents">Table of Contents</h2>
|
|
<ul>
|
|
<li>
|
|
<a href="#telodendria">Telodendria</a>
|
|
<ul>
|
|
<li><a href="#table-of-contents">Table of Contents</a></li>
|
|
<li><a href="#download">Download</a></li>
|
|
<li><a href="#building-the-source">Building The Source</a></li>
|
|
</li>
|
|
<li><a href="#configure">Configure Telodendria</a></li>
|
|
</li>
|
|
<li>
|
|
<a href="#project-status">Project Status</a>
|
|
<ul>
|
|
<li><a href="#phase-1">Phase 1: Getting Off The Ground</a></li>
|
|
<li><a href="#phase-2">Phase 2: Building A Foundation</a></li>
|
|
<li><a href="#phase-3">Phase 3: Welcome To Matrix</a></li>
|
|
<li><a href="#phase-4">Phase 4: A Real Homeserver</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#documentation-status">Documentation Status</a></li>
|
|
<li><a href="#rationale">Rationale</a></li>
|
|
<li><a href="#project-goals">Project Goals</a></li>
|
|
<li><a href="#getting-support">Getting Support</a></li>
|
|
<li>
|
|
<a href="#contributing">Contributing</a>
|
|
<ul>
|
|
<li><a href="#reporting-issues">Reporting Issues</a></li>
|
|
<li>
|
|
<a href="#Developing">Developing</a>
|
|
<ul>
|
|
<li><a href="#getting-the-code">Getting The Code</a></li>
|
|
<li><a href="#code-style">Code Style</a></li>
|
|
<li><a href="#the-build-script">The Build Script</a></li>
|
|
<li><a href="#submitting-patches">Submitting Patches</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#license">License</a></li>
|
|
<li><a href="#contributors">Contributors</a></li>
|
|
<li><a href="#change-log">Change Log</a></li>
|
|
<li><a href="#resources">Resources</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<h2 id="download">Download</h2>
|
|
<p>
|
|
<b>Telodendria</b> is distributed as source tarballs, in true Unix
|
|
fashion. If you want, you can verify the checksum of your download,
|
|
and check the signature. To check the signature, you'll need
|
|
<code>signify</code>, and the signify public key:
|
|
<a href="/telodendria-signify.pub">
|
|
telodendria-signify.pub</a>.
|
|
</p>
|
|
<p>
|
|
If your operating system has an official package or port of
|
|
<b>Telodendria</b>, you should prefer to use that instead of manually
|
|
downloading the source and building it. If your operating system's
|
|
package or port is too out of date for your tastes, please contact
|
|
the package's maintainers to notify them, or offer to update the
|
|
package yourself.
|
|
</p>
|
|
<table>
|
|
<tr>
|
|
<th>Version</th>
|
|
<th>Download</th>
|
|
<th>Checksum</th>
|
|
<th>Signature</th>
|
|
</tr>
|
|
<!--
|
|
<tr>
|
|
<td>v0.0.0</td>
|
|
<td>
|
|
<a href="/pub/v0.0.0/Telodendria-v0.0.0.tar.gz">
|
|
Telodendria-v0.0.0.tar.gz
|
|
</a>
|
|
</td>
|
|
<td>
|
|
<a href="/pub/v0.0.0/Telodendria-v0.0.0.tar.gz.sha256">
|
|
SHA256
|
|
</a>
|
|
</td>
|
|
<td>
|
|
<a href="/pub/v0.0.0/Telodendria-v0.0.0.tar.gz.sig">
|
|
Signify
|
|
</a>
|
|
</td>
|
|
</tr>
|
|
-->
|
|
<tr>
|
|
<td colspan="4" style="text-align: center;">
|
|
No downloads here yet. See the
|
|
<a href="#project-status">Project Status</a> for more
|
|
information.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
You can check out the change log <a href="#change-log">here</a>.
|
|
</p>
|
|
<h2 id="building-the-source">Building The Source</h4>
|
|
<p>
|
|
<b>Telodendria</b> is designed to be light enough that it can be built
|
|
from source on just about any operating system. It only has the
|
|
following requirements, all of which should be already available to
|
|
you on a sufficiently complete operating system:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
A standards-compliant C compiler with a POSIX.1c standard library. Because
|
|
<b>Telodendria</b> is written in ANSI C and sticks to POSIX.1c features, it
|
|
should compile on almost any compiler and operating system with minimal
|
|
effort, but the following compilers and operating systems are known to work:
|
|
<ul>
|
|
<li>GCC on Linux</li>
|
|
<li>Clang on OpenBSD, Linux, and WSL</li>
|
|
<li>
|
|
Tiny C Compiler (<b>Note:</b> must remove
|
|
<code>-Wl,-static -Wl,-gc-sections</code> from <code>LDFLAGS</code>)
|
|
on OpenBSD.
|
|
</li>
|
|
</ul>
|
|
Other compilers should work as well, but you may have to play with the
|
|
flags.
|
|
</li>
|
|
<li>
|
|
POSIX base utilities, including <code>find</code>, <code>stat</code>,
|
|
<code>env</code>, and compliant <code>sh</code>-like shell.
|
|
</li>
|
|
</ul>
|
|
<div class="code">
|
|
$ . tools/env.sh
|
|
$ td build
|
|
</div>
|
|
<p>
|
|
If everything went well, that will produce <code>build/telodendria</code>,
|
|
which you can then place wherever you want, and run as a system daemon.
|
|
See the <code>contrib</code> folder for configuration examples.
|
|
</p>
|
|
<p>
|
|
If you're going to be doing more than just building the code, see
|
|
<a href="#the-build-script">The Build Script</a> for full documentation on
|
|
what the <code>td</code> script can do.
|
|
</p>
|
|
<h2 id="configure">Configure Telodendria</h3>
|
|
<p>
|
|
<b>Telodendria</b> is designed to be extremely configurable. As such, it has
|
|
a fairly extensive configuration file. The configuration file is passed to
|
|
the <b>Telodendria</b> binary with the <code>-c</code> option, and is
|
|
typically called <code>/etc/telodendria.conf</code>. It uses OpenBSD-style
|
|
syntax, and consists of the following options.
|
|
</p>
|
|
<p>
|
|
There are example configuration files in the <code>contrib</code> folder of
|
|
every source tarball, and in the CVS repository.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code><b>listen</b> [hostname] [port]</code>
|
|
<p>
|
|
The address to listen on. It is recommended to only listen on
|
|
<code>localhost</code>, and then configure a reverse proxy such as
|
|
<code>relayd(8)</code> in front of it, because <b>Telodendria</b> does
|
|
not implement TLS. Note that <b>Telodendria</b> doesn't provide multiple
|
|
ports for the various services it offers. All APIs are made available over
|
|
the same port.
|
|
</p>
|
|
<p>
|
|
<code>[hostname]</code> should be a host name, an IPv4 address, or
|
|
an IPv6 address, if your operating system supports IPv6. <code>[port]</code>
|
|
should be a decimal port number or a service name. Refer to your system's
|
|
<code>getaddrinfo()</code> manual page for acceptable values for both of
|
|
these parameters.
|
|
</p>
|
|
<p>
|
|
The <code>listen</code> directive is entirely optional; if it is omitted,
|
|
then <b>Telodendria</b> will listen on <code>localhost</code>, port
|
|
<code>8008</code> by default.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>server-name</b> [name]</code>
|
|
<p>
|
|
Configure the domain name of your homeserver. Note that Matrix servers
|
|
cannot be migrated to other domains, so once this is set, it should never
|
|
change, unless you want unexpected things to happen, or you want to start
|
|
over.
|
|
</p>
|
|
<p>
|
|
<code>[name]</code> should be a DNS name that everyone on the network
|
|
can resolve. This directive is required.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>chroot</b> [directory]</code>
|
|
<p>
|
|
Change the root to the specified directory as soon as possible. Note that
|
|
all other paths and files specified in the configuration file must be
|
|
accessible from this directory. This only works if <b>Telodendria</b> is
|
|
running as <code>root</code>. If it isn't, then a warning is printed to the
|
|
log, and no <code>chroot</code> call is made. In that case, <b>Telodendria</b>
|
|
will still change into the specified directory, so that other paths can be
|
|
made relative to this one.
|
|
</p>
|
|
<p>
|
|
This directive is required. It is expected that the server data and logs
|
|
will live here.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>id</b> [uid] [gid]</code>
|
|
<p>
|
|
The effective UNIX user and group to drop to after binding to the socket and
|
|
changing the filesystem root. This only works if <b>Telodendria</b> is running as
|
|
<code>root</code>, and is used as a security mechanism. If <b>Telodendria</b> is
|
|
started as a non-privileged user, then a warning is printed to the log if that
|
|
user does not match what's specified here.
|
|
</p>
|
|
<p>
|
|
This directive is required, even if <b>Telodendria</b> is unable to switch to
|
|
this user. It can be used as a sanity check to make sure the permissions are
|
|
working properly.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>data-dir</b> [directory]</code>
|
|
<p>
|
|
The data directory in which <b>Telodendria</b> will write all user and event
|
|
information. <b>Telodendria</b> doesn't use a database like other Matrix
|
|
homeserver implementations; it uses a flat-file directory structure, similar to
|
|
how an SMTP server uses Maildirs to deliver email.
|
|
</p>
|
|
<p>
|
|
This directive is required. <code>[directory]</code> should be a path relative
|
|
to the <code>chroot</code> directory. Don't depend on the <code>chroot</code>
|
|
option working, because there are many legitimate cases when <b>Telodendria</b>
|
|
will not be started as <code>root</code>, thus causing the chroot to fail.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>federation</b> [true|false]</code>
|
|
<p>
|
|
Whether to enable federation with other Matrix homeservers or not. Matrix by
|
|
its very nature is a federated protocol, but if you just want your own internal
|
|
chat server with no contact with the outside, then you can use this option to
|
|
disable federation. It is highly recommended to set this to <code>true</code>,
|
|
however, if you wish to be able to communicate with users on other Matrix
|
|
servers.
|
|
</p>
|
|
<p>
|
|
This directive is required, though it may be made optional at some point in
|
|
the future.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>registration</b> [true|false]</code>
|
|
<p>
|
|
Whether or not to enable new user registration or not. For security and anti-spam
|
|
reasons, you can set this to <code>false</code>. If you do, you can still add users
|
|
via the administrator API.
|
|
</p>
|
|
<p>
|
|
In an ideal world, everyone would run their own homeserver, so no public
|
|
registration would ever be required. But unfortunately, not everyone has the means
|
|
to run their own homeserver, especially because of the fact that public IPv4 addresses
|
|
are becoming increasingly harder to come by. If you would like to provide a service
|
|
for those that are unable to run their own homeserver, you can set this to <code>true</code>,
|
|
which will allow anyone to create an account.
|
|
</p>
|
|
<p>
|
|
<b>Telodendria</b> should be capable of handling a large amount of users without
|
|
difficulty or security issues. This directive is required.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>log</b> [file|stdout]</code>
|
|
<p>
|
|
The log configuration. <b>Telodendria</b> uses its own logging facility, which can
|
|
output to either standard output or a file. A number of child directives can be
|
|
added to this directive to customize the log output:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code><b>level</b> [error|warning|task|message|debug]</code>
|
|
<p>
|
|
The level of messages to log at. Each level shows all the levels above it. For
|
|
example, setting the level to <code>error</code> will show only errors, while
|
|
setting the level to <code>warning</code> will show warnings <i>and</i> errors.
|
|
<code>task</code> shows tasks, warnings, and errors, and so on.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<code><b>timestampFormat</b> [format|none|default]</code>
|
|
<p>
|
|
If you want to custom ize the timestamp format shown in the log, or disable
|
|
the timestamp functionality altogether, you do so via this option. Acceptable
|
|
values are <code>none</code>, <code>default</code>, or a formatter string as
|
|
described by your system's <code>strftime()</code> manual.
|
|
</li>
|
|
<li>
|
|
<code><b>color</b> [true|false]</code>
|
|
<p>
|
|
Whether or not to enable colored output on TTYs. Note that ANSI color sequences
|
|
will <i>not</i> be written to a log file, only a real terminal, so this option
|
|
only applies if the log is being written to a standard output which is connected
|
|
to a terminal.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<code><b>threads</b> [count]</code>
|
|
<p>
|
|
How many worker threads to sping up to handle requests. This should generally be
|
|
less than the total CPU core count, to prevent overloading the system. The most
|
|
efficient number of threads ultimately depends on the configuration of the machine
|
|
running <b>Telodendria</b>, so you may just have to play around with different
|
|
values here to see which gives the best performance.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<h2 id="project-status">Project Status</h2>
|
|
<p>
|
|
<b>Telodendria</b> is a very ambitious project. There's a lot that needs
|
|
to happen yet before it is usable. At the moment, there's nothing that
|
|
even remotely ressembles a Matrix homeserver here; I'm still
|
|
getting off the ground and building a foundation.
|
|
</p>
|
|
<p>
|
|
But just because there's nothing here yet doesn't mean you should go away!
|
|
I could always use help, so you are more than welcome to help
|
|
out if you want things to go quicker. Please see the
|
|
<a href="#contributing">Contributing</a> section for details on how you
|
|
can get involved.
|
|
</p>
|
|
<h3 id="phase-1">Phase 1: Getting Off The Ground</h3>
|
|
<ul>
|
|
<li><s>Name this project</s></li>
|
|
<li><s>Set up a CVS repository</s></li>
|
|
<li><s>Make CVS repository public</s></li>
|
|
<li><s>Write a coding style guide</s></li>
|
|
<li><s>Write a build script</s></li>
|
|
<li><s>Add a license</s></li>
|
|
<li><s>Add support and issue reporting guide</s></li>
|
|
<li><s>Add table of contents to this document</s></li>
|
|
</ul>
|
|
<h3 id="phase-2">Phase 2: Building A Foundation</h3>
|
|
<ul>
|
|
<li><s>Implement an array</s></li>
|
|
<li><s>Implement a logging facility</s></li>
|
|
<li><s>Implement argument parsing (<code>-c file -Vh</code>)</s></li>
|
|
<li><s>Implement a hash map</s></li>
|
|
<li><s>Combine library code files</s></li>
|
|
<li><s>Implement configuration file parsing using the hash map</s></li>
|
|
<li><s>Base64 encoding/decoding with padded/unpadded support</s></li>
|
|
<li><s>Write a release script</s></li>
|
|
<li><s>UTF-8 encoder</s></li>
|
|
<li>
|
|
<s>Implement a JSON library using the hash map and array</s>
|
|
<ul>
|
|
<li><s>Basic encoding from HashMap/Array/strings, etc.</s></li>
|
|
<li><s>Basic decoding to HashMap/Array/strings, etc.</s></li>
|
|
<li><s>Proper string encoding</s></li>
|
|
<li><s>Proper string decoding</s></li>
|
|
<li>
|
|
<s><q>Canonical JSON</q></s>
|
|
<ul>
|
|
<li><s>Keys are sorted lexicographically</s></li>
|
|
<li><s>Floats are not allowed (ignore any float values)</s></li>
|
|
<li><s>Encode as UTF-8 instead of using <code>\u</code> escapes</s></li>
|
|
<li><s>Decode encoded strings to UTF-8</s></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><s>Write a function that gets the current Unix timestamp in milliseconds.</s></code>
|
|
<li><s>Figure out how to w</s>Write unit tests for array/hashmap/etc</li>
|
|
<li><s>Parse the <b>Telodendria</b> config file</s></li>
|
|
<li>Add <s>license/</s>documentation comments to all source files</li>
|
|
<li>Implement a simple HTTP server</li>
|
|
<li>
|
|
Design the server architecture
|
|
<ul>
|
|
<li>Route requests</li>
|
|
<li>Handle requests</li>
|
|
<li>Data abstraction layer</li>
|
|
<li>Error generation</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<h3 id="phase-3">Phase 3: Welcome To Matrix</h3>
|
|
<ul>
|
|
<li>
|
|
Client-Server API
|
|
</li>
|
|
<li>
|
|
Server-Server API
|
|
</li>
|
|
<li>
|
|
Application Service API
|
|
</li>
|
|
<li>
|
|
Identity Service API
|
|
</li>
|
|
<li>
|
|
Push Gateway API
|
|
</li>
|
|
<li>
|
|
Room Versions
|
|
</li>
|
|
</ul>
|
|
<h3 id="phase-4">Phase 4: A Real Homeserver</h3>
|
|
<ul>
|
|
<li>
|
|
Create an OpenBSD package and get it submitted to ports
|
|
</li>
|
|
<li>
|
|
Create a command line tool to manage Telodendria
|
|
<ul>
|
|
<li>Configuration file generation</li>
|
|
<li>User management</li>
|
|
<li>Room management</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
Migrate from Synapse. I run a Synapse homeserver right now, so somehow
|
|
I have to get all my data into the Telodendria format.
|
|
</li>
|
|
</ul>
|
|
<h2 id="documentation-status">Documentation Status</h2>
|
|
<p>
|
|
This documentation needs just a little work. Here's the things
|
|
on my list for that:
|
|
</p>
|
|
<ul>
|
|
<li><s>Update Rationale section</s></li>
|
|
<li><s>Update Project description (no longer a CGI binary)</s></li>
|
|
<li><s>Update project code requirements (ANSI C, POSIX.1c)</s></li>
|
|
<li><s>Clean up dark mode colors (tables, background, code snippets)</s></li>
|
|
<li><s>Add logo (possibly center title?)</s></li>
|
|
<li><s>Update Code Style to not include indent or line rules, but to use
|
|
<code>indent(1)</code> instead.</s></li>
|
|
<li><s>Fix typo "Subitting Patches" in Table of Contents</s></li>
|
|
<li><s>Make a note in Getting The Code that the password for the
|
|
<code>anoncvs</code> account is just <code>anoncvs</code>.</s></li>
|
|
<li><s>Add Contributors list</s></li>
|
|
<li><s>Add list of <code>make.sh</code> recipes, and what they do</s></li>
|
|
<li>Improve Google Lighthouse score
|
|
<ul>
|
|
<li>Image elements do not have explicit width and height</li>
|
|
<li>Background and foreground colors do not have a sufficient contrast ratio. (<code>msg-error</code> div)</li>
|
|
<li><s>Lists do not contain only <code>li</code> elements.</s></li>
|
|
</ul>
|
|
</li>
|
|
<li>Add other message <code>div</code>s for notes and warnings.</li>
|
|
</ul>
|
|
<h2 id="rationale">Rationale</h2>
|
|
<p>
|
|
I want a lightweight Matrix homeserver designed specifically for
|
|
OpenBSD and other Unix-like operating systems. I want a homeserver
|
|
that can be developed in <code>vi(1)</code> and compiled with the
|
|
built-in C compiler. I want it to function entirely on a base OS
|
|
install without having to install any extra packages whatsoever.
|
|
I've found that as far as these priorities are concerned, the
|
|
existing homeserver implementations fall tremendously short. This
|
|
project aims to point out that existing homeserver implementations
|
|
are way over-engineered and written in such a way that many programs
|
|
and libraries have to be pulled in to use them.
|
|
</p>
|
|
<p>
|
|
I also want to learn how Matrix works, and I want to understand the
|
|
code I'm running on my server, which is why I'm writing every
|
|
component from scratch, even the HTTP server.
|
|
</p>
|
|
Telodendria is written entirely in portable ANSI C. It depends on
|
|
no third-party C libraries other than the standard POSIX C library.
|
|
The only thing you need to run it is a reverse proxy with HTTPS support,
|
|
such as <code>relayd(8)</code>, and a directory that data can be
|
|
written to. Everything Telodendria needs to run itself is compiled
|
|
into a single static binary, and the source code can be built
|
|
anywhere, right out of the box. This makes it suitable for running
|
|
in a <code>chroot(8)</code> environment.
|
|
</p>
|
|
<p>
|
|
Telodendria doesn't use a database like all the other homeservers.
|
|
Instead, it operates more like email: it uses a flat-file data
|
|
structure similar to Maildir to store data. The advantage of this is
|
|
that it saves server maintainers from also having to maintain a
|
|
database. It greatly simplifies the process of getting a Matrix
|
|
homeserver up and running, and it makes it highly portable. It also is
|
|
extremely easy to back up and restore with base tools; just
|
|
<code>tar(1)</code> up the directory, and you're good to go.
|
|
</p>
|
|
<p>
|
|
Telodendria is developed and tested on OpenBSD, but you'll find that it
|
|
should just run on any POSIX operating system without modification.
|
|
</p>
|
|
<h2 id="project-goals">Project Goals</h2>
|
|
<p>
|
|
The goals of this project are generally divided into <i>user goals</i>,
|
|
and <i>developer goals</i>, depending on who they impact the most. This
|
|
isn't an exhaustive list, but it is a list of things that I want to
|
|
prioritize, <i>because other server implementations lack them</i>.
|
|
</p>
|
|
<p>
|
|
The user goals are as follows:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
To be a production-ready Matrix server capable of handling a lot of
|
|
users. Telodendria should have good performance in many diverse
|
|
environments. It should scale up well for large instances, and yet also
|
|
be able to scale down to a peer-to-peer device.
|
|
</li>
|
|
<li>
|
|
To be easier to configure than any of the other Matrix homeserver
|
|
implementations. The configuration file should be flexible,
|
|
well-documented, and easy to understand and modify. An intuitive
|
|
command-line tool for administrative tasks should also be available.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
The developer goals are as follows:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
To have as few external build and run dependencies as possible. It
|
|
should be possible to compile Telodendria on any POSIX operating
|
|
system right out of the box, and have it be totally statically linked,
|
|
ready to run under a <code>chroot(8)</code>. You'll even notice that
|
|
the documentation is written in HTML directly, not Markdown, to remove
|
|
the dependency on a Markdown parser and renderer.
|
|
</li>
|
|
<li>
|
|
To have a simple yet elegant workflow, and not depend on any large
|
|
or complex development tools, such as code forges. The entire
|
|
development workflow should be able to be successfully and efficiently
|
|
completed on a base OpenBSD install. Of course you don't have to use
|
|
OpenBSD for development by any means, but the point is, the workflow
|
|
should not require a lot of tools.
|
|
<li>
|
|
To be written in clean, elegant, and well-documented code. The goal is
|
|
to build a Matrix homeserver from the ground up, not just because I
|
|
don't like the way existing homeservers are implemented, but also so I can
|
|
learn how Matrix really works, and maybe even teach others along the
|
|
way.
|
|
</li>
|
|
</ul>
|
|
<h2 id="getting-support">Getting Support</h2>
|
|
<p>
|
|
<b>Telodendria</b> is designed to be fairly straightforward, but that
|
|
doesn't mean there won't be hiccups along the way. If you are struggling
|
|
to get <b>Telodendria</b> up and running, you're more than welcome to
|
|
reach out for support. Just join the
|
|
<code>#telodendria-general:bancino.net</code> Matrix channel. Before
|
|
you do though, make sure you're running the latest version of
|
|
<b>Telodendria</b> and you've thoroughly read through all the
|
|
relevant documentation.
|
|
</p>
|
|
<h2 id="contributing">Contributing</h2>
|
|
<p>
|
|
<b>Telodendria</b> is an open source project. As such, it welcomes
|
|
contributions. There are many ways you can contribute, and any way you
|
|
can is greatly appreciated.
|
|
</p>
|
|
<h3 id="reporting-issues">Reporting Issues</h3>
|
|
<p>
|
|
If—after you've reached out to
|
|
<code>#telodendria-general:bancino.net</code>—it has been
|
|
determined that there is a problem with <b>Telodendria</b>, it should
|
|
be reported to <code>#telodendria-issues:bancino.net</code>. There it
|
|
can be discussed further. The issues room serves as the official
|
|
issue tracker of <b>Telodendria</b>; although severe issues may be copied
|
|
into a <code>TODO</code> file in the CVS repository just so they
|
|
don't get lost.
|
|
</p>
|
|
<h3 id="developing">Developing</h3>
|
|
<p>
|
|
The primary language used to write <b>Telodendria</b> code is ANSI C.
|
|
Yes, that's the original C standard from 1989. The reason this standard
|
|
is chosen, and the reason that it will not be changed, is because the
|
|
original C is the most portable. Other languages you'll find in the
|
|
<b>Telodendria</b> repository are shell scripts and HTML. If you have
|
|
any experience at all with any of these languages, your contributions
|
|
are valuable. Please follow the guidelines in this section to ensure
|
|
the contribution workflow goes as smoothly as possible.
|
|
</p>
|
|
<h4 id="getting-the-code">Getting The Code</h4>
|
|
<p>
|
|
If you'd like to hack on <b>Telodendria</b>, you'll need the following
|
|
tools in addition to the tools required to
|
|
<a href="#building-the-source">build the source</a>:
|
|
</p>
|
|
<ul>
|
|
<li><code>cvs</code> for checking out and updating a local copy
|
|
of the source code.</li>
|
|
<li><code>indent</code> for formatting your code before generating
|
|
patches</li>
|
|
<li><code>patch</code> for applying patches to your local copy of the
|
|
source code.</li>
|
|
</ul>
|
|
<p>
|
|
Note that all of these tools are built into OpenBSD. While you of course
|
|
don't have to use OpenBSD to develop <b>Telodendria</b>, it may make
|
|
the process a little easier. In fact, these tools were chosen
|
|
precisely <i>because</i> they were built into OpenBSD, the operating
|
|
system I use.
|
|
</p>
|
|
<p>
|
|
You can download an official release tarball if you would really like,
|
|
but the preferred way is to check out the source code from CVS. This
|
|
makes generating patches a lot easier.
|
|
</p>
|
|
<div class="code">
|
|
$ cvs -d anoncvs@bancino.net:/cvs checkout -P Telodendria
|
|
$ cd Telodendria
|
|
</div>
|
|
<p>
|
|
If you already checkout out the code previously, make sure you update your
|
|
local copy before you start developing:
|
|
</p>
|
|
<div class="code">
|
|
$ cvs -q update -dP
|
|
</div>
|
|
<p>
|
|
You should now have the latest <b>Telodendria</b> source code. Follow
|
|
the <a href="#code-style">Code Style</a> as you make your changes.
|
|
</p>
|
|
<h4 id="code-style">Code Style</h4>
|
|
<p>
|
|
In general, these are the conventions used by the code base. This
|
|
guide may be slightly outdated or subject to change, however. The
|
|
source code itself is the absolute source of truth, so as long as
|
|
you make your code look like the code surrounding it, you should
|
|
be fine.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
All function, enumeration, structure, and header names are
|
|
<code>CamelCase</code>. This is preferred to <code>snake_case</code>
|
|
because it is more compact.
|
|
</li>
|
|
<li>
|
|
All variable names are <code>lowerCamelCase</code>. This is preferred
|
|
to <code>snake_case</code> because it is more compact.
|
|
</li>
|
|
<li>
|
|
<code>enum</code>s and <code>struct</code>s are always
|
|
<code>typedef</code>-ed to their same name. The <code>typedef</code>
|
|
occurs in the public API header, and the actual declaration occurs in
|
|
the implementation file.
|
|
</li>
|
|
<li>
|
|
A feature of the code base lives in a single <code>.c</code> file that
|
|
has a matching header file. The header file should only export public
|
|
symbols, everything else in the <code>.c</code> file should be
|
|
<code>static</code>.
|
|
</li>
|
|
<li>
|
|
Anywhere curly braces are optional, there must still be curly braces.
|
|
This makes it easy to add on to the code later, and just makes things
|
|
less ambiguous.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
As far as actually formatting the code goes, such as where to put
|
|
brackets and whether you use tabs or spaces, use <code>indent(1)</code>
|
|
to take care of all of that. The root of the repository has a
|
|
<code>.indent.pro</code> file that should automatically be loaded by
|
|
<code>indent(1)</code> to set the correct rules. If you don't have
|
|
access to a working <code>indent(1)</code>, just indicate in your patch
|
|
that I should run <code>indent(1)</code> on the code after applying it.
|
|
I'll likely run my <code>indent(1)</code> on the code anyway though,
|
|
just to make sure the spacing is consistent, if nothing else.
|
|
</p>
|
|
<h4 id="the-build-script">The Build Script</h4>
|
|
<p>
|
|
<b>Telodendria</b> uses a custom build script called <code>td</code>,
|
|
for <i>Telodendria developer</i>. The <code>td</code> script is not only
|
|
a build script, however. It does all kinds of cool things like
|
|
format the source code, and generate patch files. <code>td</code> is
|
|
the only supported way to develop <b>Telodendria</b>.
|
|
</p>
|
|
<p>
|
|
I opted to write a custom build script instead of just using
|
|
<code>make</code>, because I felt that there is really no way to make
|
|
a truly portable <code>Makefile</code> that could do everything I
|
|
need. I was doing a lot of research on the differences between the
|
|
GNU and BSD versions of <code>make</code>, and I felt it just wasn't
|
|
worth it when I could write a small POSIX script that would run on
|
|
both GNU systems and BSD systems without a fuss. I also wanted a way
|
|
to automate more than just building code. I wanted a system
|
|
versatile enough that I could define arbitrary recipes to do whatever
|
|
I want. I didn't want to be limited by the <code>Makefile</code>
|
|
syntax.
|
|
</p>
|
|
<p>
|
|
The <code>td</code> script is fairly intuitive. It operates somewhat
|
|
like <code>make</code>, in that it has recipes that you specify
|
|
on the command line. To start using it, just run the following
|
|
command in your <b>Telodendria</b> directory:
|
|
</p>
|
|
<div class="code">
|
|
$ . tools/env.sh
|
|
</div>
|
|
<p>
|
|
<b>Note:</b> You will have to run the above command every time you
|
|
start a new terminal session, as nothing is persisted to your system.
|
|
I believe in non-invasive, fully self-contained tooling, so it is up to
|
|
you to hook the Telodendria tools into your environment if you want them
|
|
to persist.
|
|
</p>
|
|
<p>
|
|
If you're going to be submitting patches, you should also configure
|
|
a <code>.env</code> file in the project directory root, which
|
|
<code>td</code> will include automatically for you. For the best
|
|
experience, you'll want at least these values:
|
|
</p>
|
|
<div class="code">
|
|
MXID=@your:matrix-id.net
|
|
DISPLAY_NAME="Your Display Name"
|
|
EDITOR=gedit # Or whatever your preferred editor is.
|
|
</div>
|
|
<p>
|
|
If you don't provide these values, <code>td</code> will deduce them
|
|
from your environment. It uses your system username and hostname to
|
|
create the <code>MXID</code>, and reads the password database to
|
|
get your configured display name. It also uses <code>vi</code> as
|
|
the default editor, which may not be suitable for all developers.
|
|
</p>
|
|
<p>
|
|
You can invoke <code>td</code> recipes with the following syntax:
|
|
</p>
|
|
<div class="code">
|
|
$ td <recipe> ...
|
|
</div>
|
|
<p>
|
|
Multiple recipes can be invoked in a single run of <code>td</code>.
|
|
At the moment, recipes are run unconditionally; that is, even if parts
|
|
of a recipe fail, all following recipes still run.
|
|
</p>
|
|
<p>
|
|
Here is a complete list of recipes currently supported by
|
|
<code>td</code>, and a description of what they do. Some recipes can
|
|
alter their behavior based on certain environment variables. Those
|
|
variables are also documented here.
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<code>build</code>: Build the source code, and generate the
|
|
<code>build/telodendria</code> binary. This is the <i>default</i>
|
|
recipe; that is, it runs if no recipes are given as arguments to
|
|
<code>td</code>. The build recipe is incremental; it only rebuilds
|
|
sources that have been modified since the last build, which makes
|
|
builds faster. This recipe makes use of many environment variables:
|
|
<ul>
|
|
<li><code>CFLAGS</code>: Compiler flags to generate object files.</li>
|
|
<li><code>LDFLAGS</code>: Compiler flags to link the output binary</li>
|
|
<li><code>CC</code>: The compiler to use.</li>
|
|
<li><code>PROG</code>: The name of the output binary</li>
|
|
<li><code>DEFINES</code>: Global preprocessor definitions</li>
|
|
<li><code>INCLUDES</code>: Header directories to make available</li>
|
|
<li><code>DEBUG</code>: If set to "1", append some debug flags to
|
|
<code>CFLAGS</code>, and wipe out any <code>LDFLAGS</code> that
|
|
would cause the output binary to be optimized. Also appends "-debug"
|
|
to <code>PROG</code>.</li>
|
|
</ul>
|
|
<code>TELODENDRIA_VERSION</code> also makes its way into the output
|
|
binary, but it is primarily used for generating releases.
|
|
</li>
|
|
<li>
|
|
<code>clean</code>: Remove the <code>build/</code> directory, which
|
|
effectively cleans the source tree. Note that <code>build</code> does
|
|
not place anything outside of <code>build/</code>, so this is
|
|
functionally equivalent to running <code>rm -r build</code>.
|
|
</li>
|
|
<li>
|
|
<code>format</code>: Make sure the source code copyright headers are
|
|
up to date, and format the source code using the system's
|
|
<code>indent(1)</code> command. This should be run before generating
|
|
patch files, to ensure that the code follows the project conventions.
|
|
Note that the provided <code>.indent.pro</code> assumes an OpenBSD
|
|
<code>indent</code>, which may cause the GNU implementation to choke.
|
|
</li>
|
|
<li>
|
|
<code>test</code>: Run all of the unit tests, and report the results.
|
|
It is highly recommended to ensure that the tests all pass before
|
|
submitting a patch, because patches that break the tests are likely
|
|
to be rejected.
|
|
</li>
|
|
<li>
|
|
<code>site</code>: Deploy the <b>Telodendria</b> website by copying the
|
|
required files to a web root. The web root is defined by the
|
|
<code>TELODENDRIA_PUB</code> environment variable. This is mainly
|
|
used to deploy the official website, but it can be used to set up a
|
|
local development site if absolutely neccessary.
|
|
</li>
|
|
<li>
|
|
<code>release</code>: Generate a release tarball, checksum and sign it,
|
|
and push it into the web root. The web root is defined by the
|
|
<code>TELODENDRIA_PUB</code> environment variable. You may also have
|
|
to set <code>CVSROOT</code> to the official CVS repository of
|
|
<b>Telodendria</b>. If you want to create a release tarball for an
|
|
older version, set <code>TELODENDRIA_VERSION</code>. If you want to
|
|
generate a release tarball for the latest code, set
|
|
<code>CVS_TAG</code> to <code>HEAD</code>. If you want to sign the
|
|
generated tarball, set <code>TELODENDRIA_SIGNIFY_SECRET</code> to a
|
|
<code>signify</code> private key file. This is mainly used to deploy
|
|
releases to the official website, but it can be used to independently
|
|
mirror <b>Telodendria</b> releases from the official CVS repository.
|
|
</li>
|
|
<li>
|
|
<code>patch</code>: Generate a formatted patch file. The
|
|
<b>Telodendria</b> project isn't super picky about how patches look
|
|
as long as they apply cleanly, but this recipe generates patches in
|
|
the format we like them. It makes them easy to read. This recipe will
|
|
use the <code>EDITOR</code> variable to open your formatted patch in
|
|
your preferred editor. If no <code>EDITOR</code> is specified, then
|
|
<code>vi</code> is used. For more details on how this recipe works,
|
|
read <a href="#submitting-patches">Submitting Patches</a>. This
|
|
recipe also makes use of <code>PATCHSET</code>, <code>MXID</code>,
|
|
and <code>DISPLAY_NAME</code>.
|
|
</li>
|
|
<li>
|
|
<code>diff</code>: Generate a temporary preview patch that is
|
|
opened in the default pager. This recipe uses the <code>PAGER</code>
|
|
variable to preview patches. If no <code>PAGER</code> is set, then
|
|
<code>less -F</code> is used as the default. This can be used for
|
|
quickly previewing patches. Setting <code>PATCHSET</code> allows you
|
|
to only preview certain changes; see
|
|
<a href="#submitting-patches">Submitting Patches</a> for more
|
|
information on how <code>PATCHSET</code> works.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Any environment variables noted above that <code>td</code> recipes
|
|
use can be specified in a <code>.env</code> file in the root of the
|
|
<code>Telodendria</code> directory. This saves you from constantly
|
|
having to set the environment variables in your shell, as well as
|
|
from having to pollute your user environment with <b>Telodendria</b>
|
|
variables. <code>td</code> will automatically include the
|
|
<code>.env</code> file on every run.
|
|
</p>
|
|
<div class="msg-err">
|
|
<code>td</code> will source the <code>.env</code> file, which means
|
|
it executes it like a shell script. Any shell code inside of
|
|
<code>.env</code> will be executed every time <code>td</code> is
|
|
run.
|
|
</div>
|
|
<h4 id="submitting-patches">Submitting Patches</h4>
|
|
<p>
|
|
<b>Telodendria</b> aims at remaining as minimal as possible. This doesn't
|
|
just mean minimal code, it also means a minimal development process, which
|
|
is why <b>Telodendria</b> doesn't use GitHub, GitLab, or even SourceHut.
|
|
Instead, the contribution workflow operates on submitting patch files to
|
|
a public Matrix room, sort of like the OpenBSD project operates on patch
|
|
files sent to a public mailing list.
|
|
</p>
|
|
<p>
|
|
If you're not used to manually creating and submitting patches instead of
|
|
opening a "pull request," you should be pleased to hear that submitting
|
|
patches is fairly easy to do if you've got the CVS sources checked out.
|
|
In fact, I find it easier than having to make a GitHub account, forking
|
|
a project repository, and then making a pull request for it. Once you
|
|
have made your changes in your local copy of the code, and you've
|
|
configured your environment using the instructions in
|
|
<a href="#the-build-script">The Build Script</a>, just run the
|
|
<code>patch</code> recipe:
|
|
</p>
|
|
<div class="code">
|
|
$ td patch
|
|
</div>
|
|
<p>
|
|
This will automatically generate a patch file for all your changes,
|
|
and then open it in your preferred editor.
|
|
You can also generate a patch for only certain files and directories.
|
|
To do that, set <code>PATCHSET</code>, like this:
|
|
</p>
|
|
<div class="code">
|
|
# Only write a patch for README.txt and the files in site/
|
|
$ PATCHSET="README.txt site/" td patch
|
|
</div>
|
|
<p>
|
|
As you'll notice, the top of the patch file should have some email-style
|
|
headers that look like this:
|
|
</p>
|
|
<div class="code">
|
|
From: Jordan Bancino <@jordan:bancino.net>
|
|
Date: Fri Jul 29 03:21:21 PM EDT 2022
|
|
Subject: Document Patch Procedure
|
|
</div>
|
|
<p>
|
|
As much information as possible should be filled out for you, such as
|
|
the date. An attempt to fill out the <code>From</code> header was also
|
|
made, but the information there can be made more accurate by setting
|
|
<code>MXID</code> to your Matrix ID, and <code>DISPLAY_NAME</code> to
|
|
your real name in your environment, or the <code>.env</code> file.
|
|
The <code>Subject</code> should very briefly describe what the patch
|
|
is about. Below these headers, write a more in-depth description of
|
|
the patch.
|
|
</p>
|
|
<p>
|
|
Then, send the resulting patch file to
|
|
<code>#telodendria-patches:bancino.net</code>, so it can be
|
|
discussed and reviewed by the community. If you don't have a Matrix
|
|
account, and you <i>really</i> don't want to create one—ignoring
|
|
how odd it is that you are trying to contribute to a <i>Matrix</i>
|
|
homeserver project—you can email your patches to
|
|
<a href="mailto:jordan@bancino.net">jordan@bancino.net</a>. However,
|
|
the preferred way of submitting patches is to the official Matrix room,
|
|
so I will upload your patch there along with your email address. If you
|
|
are going to send patches via email, <b>they must be plain text</b> emails,
|
|
and the patch must be in the main body of the email. No MIME, base64, or
|
|
printed-quotable garbage. I will silently reject emails that are not
|
|
purely plain text. I should be able to write a raw copy of your message to
|
|
an <code>mbox</code> file, and then apply it onto my code right from
|
|
there, with no further processing. If you're going to be a regular contributor,
|
|
it would just be easier to create a Matrix account. It doesn't have to be
|
|
on my public homeserver, but it certainly can be. Note that the discussion and
|
|
ultimately the decision on what to do with your patch will all happen in
|
|
the Matrix room, so if you submit patches using email, you'll miss out on
|
|
any feedback.
|
|
</p>
|
|
<p>
|
|
Try to keep your patches on topic—make one patch file per feature
|
|
or bug fix being implemented. It is okay if your patches depend on previous
|
|
patches, just indicate that in the patch. Note that it may take a while
|
|
for patches to be committed, and some patches may not be committed at
|
|
all. In either case, all sent patches are queued from the Matrix room into the
|
|
<a href="/patches">public patch directory</a>, so they can be referenced easier
|
|
in the future. If you want to reference a submitted patch in a Matrix message
|
|
or email, it might be a good idea to link to it in the public patch directory.
|
|
</p>
|
|
<p>
|
|
The public patch directory works as follows: when you send your patch to the
|
|
Matrix room, it is downloaded by the <b>Telodendria</b> Bot and placed in the
|
|
<code>ingress/</code> directory, named as the message ID. Then, it is
|
|
assigned a <b>Telodendria</b> patch ID and copied to the <code>p/</code>
|
|
directory as just <code>${id}.patch</code>. This is a permanent link that will
|
|
always reference your patch. Then, your patch is symlinked to the
|
|
<code>queue/</code> directory. I have a script that automatically ingresses
|
|
patches and queues them for me, and I'll use this to review patches.
|
|
If your patch is accepted, the queue symlink will be moved to the
|
|
<code>accepted/</code> directory and the patch is committed to the official
|
|
CVS repository. If you patch is rejected for some reason, its symlink will
|
|
be moved to the <code>rejected/</code> directory. Regardless of the state
|
|
of your patch, it will always remain permalinked in the <code>p/</code>
|
|
directory, and when it is accepted or rejected, <b>Telodendria</b> Bot will
|
|
send a message.
|
|
</p>
|
|
<p>
|
|
You're always welcome to inquire about rejected patches, and request they be
|
|
reviewed again, or you can use them as a starting point for future patches.
|
|
</p>
|
|
<h2 id="license">License</h2>
|
|
<p>
|
|
All of the code for <b>Telodendria</b> is licensed under a modified
|
|
MIT license. Please consult the <code>src/header.txt</code> file for
|
|
the actual license text. The <b>Telodendria</b> license text differs
|
|
from the MIT license in the following ways:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
Where the MIT license states that the copyright notice and permission
|
|
notice shall be included in all copies or <i>substantial</i> portions
|
|
of the software, the <b>Telodendria</b> license requires the copyright
|
|
notice and permission notice be included in <i>all</i>
|
|
portions—regardless of size—of the software by omitting
|
|
the word <i>substantial</i>.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
The documentation for <b>Telodendria</b> is also licensed under the
|
|
modified MIT license that lives in <code>src/header.txt</code>. Whether
|
|
you obtain the documentation by printing, or otherwise downloading
|
|
this page, or by checking it out from the CVS source, it is licensed
|
|
the same as the code.
|
|
<p>
|
|
The <b>Telodendria</b> logo, however, belongs solely to the
|
|
<b>Telodendria</b> project. It must only be used to represent the
|
|
official <b>Telodendria</b> project, and may only appear in official
|
|
<b>Telodendria</b> media. If <b>Telodendria</b> is forked, the logo
|
|
must be removed from the project and optionally replaced by a different
|
|
one. The logo may not be modified in any way or for any purpose.
|
|
</p>
|
|
<h2 id="contributors">Contributors</h2>
|
|
<p>
|
|
<b>Telodendria</b> would not be possible without the support of the
|
|
following people:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<b>Project Manager:</b>
|
|
Jordan Bancino <@jordan:bancino.net>
|
|
</li>
|
|
<li>
|
|
<b>Logo/site design:</b>
|
|
Jonah
|
|
</li>
|
|
</ul>
|
|
<h2 id="change-log">Change Log</h2>
|
|
<p>
|
|
At this time, Telodendria does not have any tagged releases because it
|
|
is not yet functional as a Matrix homeserver. Please check out the <a
|
|
href="#project-status">Project Status</a> to see where things are
|
|
currently at.
|
|
</p>
|
|
<h2 id="resources">Resources</h2>
|
|
<ul>
|
|
<li><a target="_blank" href="/pub">Old <b>Telodendria</b> Versions</a></li>
|
|
<li><a target="_blank" href="/spec.matrix.org">Matrix Spec Mirror</a>
|
|
(<a href="/matrix-spec-v1.3.tar.gz">Download matrix-spec-v1.3.tar.gz</a>)
|
|
</li>
|
|
<li><a target="_blank" href="/patches">Public Patch Directory</a></li>
|
|
</ul>
|
|
<hr>
|
|
© 2022 Jordan Bancino <@jordan:bancino.net>
|
|
</body>
|
|
</html>
|