Telodendria is distributed as source tarballs, in true Unix @@ -227,180 +181,6 @@ for convenience:
-Telodendria is designed to be extremely configurable. As such, it has
-a fairly extensive configuration file. The configuration file is passed to
-the Telodendria binary with the -c option, and is
-typically called /etc/telodendria.conf. It uses OpenBSD-style
-syntax, and consists of the following options.
-
-There are example configuration files in the contrib folder of
-every source tarball, and in the CVS repository.
-
listen [port]
-
-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.
-
-[port] should be a decimal port number or a service name.
-
-The listen directive is entirely optional; if it is omitted,
-then Telodendria will listen on localhost, port
-8008 by default.
-
server-name [name]
--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 everyone on the network
-can resolve. This directive is required.
-
chroot [directory]
-
-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 Telodendria is
-running as root. If it isn't, then a warning is printed to the
-log, and no chroot call is made. In that case, Telodendria
-will still change into the specified directory, so that other paths can be
-made relative to this one.
-
-This directive is required. It is expected that the server data and logs -will live here. -
-id [uid] [gid]
-
-The effective UNIX user and group to drop to after binding to the socket and
-changing the filesystem root. This only works if Telodendria is running as
-root, and is used as a security mechanism. If Telodendria 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.
-
-This directive is required, even if Telodendria is unable to switch to -this user. It can be used as a sanity check to make sure the permissions are -working properly. -
-data-dir [directory]
--The data directory in 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. [directory] should be a path relative
-to the chroot directory. Don't depend on the chroot
-option working, because there are many legitimate cases when Telodendria
-will not be started as root, thus causing the chroot to fail.
-
federation [true|false]
-
-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 true,
-however, if you wish to be able to communicate with users on other Matrix
-servers.
-
-This directive is required, though it may be made optional at some point in -the future. -
-registration [true|false]
-
-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. 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 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. -
-log [file|stdout]
--The log configuration. Telodendria 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: -
-level [error|warning|task|message|debug]
-
-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.
-task shows tasks, warnings, and errors, and so on.
-
timestampFormat [format|none|default]
-
-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 none, default, or a formatter string as
-described by your system's strftime() manual.
-
color [true|false]
--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. -
-threads [count]
--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 Telodendria, so you may just have to play around with different -values here to see which gives the best performance. -
-Telodendria is a very ambitious project. There's a lot that needs