telodendria.confConfiguration file for Telodendria.

telodendria.conf is the configuration file for the Telodendria homeserver, telodendria(8). Telodendria is designed to be extremely configurable. As such, it has a fairly extensive configuration file. The configuration file can be passed to the Telodendria binary with the option, and is typically located at /etc/telodendria.conf

telodendria.conf uses JSON for its configuration file syntax, which should be familiar. Very early versions of telodendria.conf used a custom OpenBSD-style configuration file, but this was not as versatile or familiar as JSON.

Here are the top-level directives:

The port to listen on. Telodendria will bind to all interfaces, but it is recommended to configure your firewall so that it only listens on localhost, and then configure a reverse proxy such as relayd(8) in front of it, because Telodendria does not implement TLS. Note that Telodendria doesn't provide multiple ports for the various services it offers. ALl APIs are made available over the same port, so care should be taken in relayd.conf(5) to ensure that only the public Matrix API paths are made available over the internet. port should be a decimal port number. This directive is entirely optional. If it is omitted, then Telodendria will listen on port 8008 by default.
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. name should be a DNS name that can be publically resolved. This directive is required.
Set the server's base URL. url should be a valid URL, complete with the protocol. It does not need to be the same as the server name; in fact, it is common for a subdomain of the server name to be the base URL for the Matrix homeserver.

This URL is the URL at which Matrix clients will connect to the server, and is thus served as a part of the .well-known manifest.

This directive is optional. If it is not specified, it is automatically deduced from the server name.

The identity server that clients should use to perform identity lookups.

url follows the same rules as baseUrl.

This directive is optional. If it is not specified, it is automatically set to be the same as the base URL.

The effective UNIX user and group to drop to after binding to the socket and changing the filesystem root for the process. This only works if Telodendria is running as the root user, and is used as a security mechanism. If this option is set and Telodendria is started as a non-priviledged user, then a warning is printed to the log if that user does not match what's specified here. This directive is optional, but should be used as a sanity check, if nothing more, to make sure the permissions are working properly.

This directive takes an object with the following directives:

The UNIX username to drop to. If runAs is specified, this directive is required.
The UNIX group to drop to. This directive is optional; if it is not specified, then the value of uid is copied.
The data directory into which Telodendria will write all user and event information. Telodendria 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. This directive is required.

Telodendria will chroot(2) into this directory as soon as possible for security reasons. If the log directive is configured to write to a file, the log file will be written in the data directory. directory should be an absolute path, under which all Telodendria data will live.

Whether to enable federation with other Matrix homeservers or not. Matrix is by its very nature a federated protocol, but if you just want to run 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 true, however, if you wish to be able to communicate with users on other Matrix servers. This directive is required.
Whether or not to enable new user registration or not. For security and anti-spam reasons, you can set this to false. If you do, you can still add users via the administrator API. In an ideal world, everyone would run their own homeserver, so no public registration would ever be required. 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 to those that are unable to run their own homeserver, you can aset this to true, which will allow anyone to create an account. Telodendria should be capable of handling a large amount of users without difficulty or security issues. This directive is required.
The log file configuration. Telodendria uses its own logging facility, which can output logs to standard output, a file, or the syslog. This directive is required, and it takes an object with the following directives:
The lot output destination. If set to file, Telodendria will log to telodendria.log inside the dataDir.
The level of messages to log at. Each level shows all the levels above it. For example, setting the level to error will show only errors, while setting the level to warning will show warnings and errors. notice shows notices, warnings, and errors, and so on. The debug level shows all messages.
If you want to customize the timestamp format shown in the log, or disable it altogether, you can do so via this option. Acceptable values are none, default, or a formatter string as described by your system's strftime(3). This option only applies if log is "stdout" or "file".
Whether or not to enable colored output on TTYs. Note that ANSI color sequences will not 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.

This option only applies if log is "stdout".

How many worker threads to spin 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 Telodendria, so you may just have to play around with different values here to see which gives the best performance.
The maximum number of simultanious connections to allow to the daemon. This option prevents the daemon from allocating large amounts of memory in the even that it undergoes a denial of service attack. It typically does not need to be adjusted.
The maximum size of the cache. Telodendria relies heavily on caching to speed things up. The cache grows as data is loaded from the data directory. All cache is stored in memory. This option limits the size of the memory cache. If you have a system that has a lot of memory, you'll get better performance if this option is set higher. Otherwise, this value should be lowered on systems that have minimal memory available.

The default telodendria(8) configuration file.
The recommended data directory.

Please consult the default telodendria.conf that ships with Telodendria for a complete example. If you installed Telodendria as a package, then the example should be located at the default location. If you are building from source, you can find the default config in the contrib/ directory.


February 15, 2023 Telodendria Project