27 changed files with 1574 additions and 838 deletions
--- a/.gitea/issue_template/bug_report.yaml
+++ b/.gitea/issue_template/bug_report.yaml
@ -1,49 +0,0 @@
 name: Bug Report
 about: File a bug report regarding Telodendria, its website, or its documentation.
 body:
  - type: markdown
    attributes:
      value: |
        You are submitting a bug report. Please be sure to fill out the
        title with a brief description of the bug.
  - type: dropdown
    attributes:
      label: Type
      description: Select the type of issue.
      options:
        - Memory Leak
        - Crash
        - Unexpected Error Message
        - Documentation
        - Website
        - Other
    validations:
      required: true
  - type: textarea
    attributes:
      label: Description
      description: |
        Please give a thorough and detailed description of the bug you
        are reporting. Provide all the information you have, and do
        some investigating to ensure you are providing a legitimate
        issue report that is well thought out. **Include details on
        how to reproduce the issue, or explicitly state that you were
        unable to reproduce it.**
    validations:
      required: true
  - type: textarea
    attributes:
      label: Log Output
      description: |
        Please copy and paste the relevant sections of the log output,
        or the entire log if it is not unreasonably large. The logs
        will be automatically formatted, no code block is necessary.
      render: shell
    validations:
      required: true
  - type: markdown
    attributes:
      value: |
        Please attach any additional files that may aid in our
        investigation of this issue, including screenshots, debugging
        session stack traces and dumps, etc.
--- a/.gitea/issue_template/config.yaml
+++ b/.gitea/issue_template/config.yaml
@ -1,7 +0,0 @@
 blank_issues_enabled: false
 contact_links:
  - name: General Matrix Room
    url: "https://matrix.to/#/#telodendria-general:bancino.net"
    about: |
      General discussion on Telodendria happens in this Matrix room. You
      may get quicker feedback from there.
--- a/.gitea/issue_template/feature_request.yaml
+++ b/.gitea/issue_template/feature_request.yaml
@ -1,18 +0,0 @@
 name: Feature Request
 about: Request a new feature or enhancement be added to Telodendria.
 title: "[Feature] "
 body:
  - type: markdown
    attributes:
      value: |
        You are submitting a feature request. Please be sure to fill
        out the title with a brief description of the feature you are
        requesting.
  - type: textarea
    attributes:
      label: Description
      description: |
        Please give a thorough and detailed description of the feature
        you are requesting.
    validations:
      required: true
--- a/.gitea/pull_request_template.md
+++ b/.gitea/pull_request_template.md
@ -1,25 +0,0 @@
 ---
 Please review the developer certificate of origin:
 1. The contribution was created in whole or in part by me, and I have
 the right to submit it under the open source licenses of the
 Telodendria project; or
 1. The contribution is based upon a previous work that, to the best of
 my knowledge, is covered under an appropriate open source license and
 I have the right under that license to submit that work with
 modifications, whether created in whole or in part by me, under the
 Telodendria project license; or
 1. The contribution was provided directly to me by some other person
 who certified (1), (2), or (3), and I have not modified it.
 1. I understand and agree that this project and the contribution are
 made public and that a record of the contribution&mdash;including all
 personal information I submit with it&mdash;is maintained indefinitely
 and may be redistributed consistent with this project or the open
 source licenses involved.
 - [ ] I have read the Telodendria Project development certificate of
 origin, and I certify that I have permission to submit this patch
 under the conditions specified in it.
--- a/Cytoplasm/src/HttpRouter.c
+++ b/Cytoplasm/src/HttpRouter.c
@ -196,7 +196,7 @@ HttpRouterRoute(HttpRouter * router, char *path, void *args, void **ret)
    char *pathPart;
    char *tmp;
    HttpRouteFunc *exec = NULL;
-    Array *matches = NULL;
+    Array *matches;
    size_t i;
    int retval;
@ -254,18 +254,14 @@ HttpRouterRoute(HttpRouter * router, char *path, void *args, void **ret)
            {
                /* pmatch[0] is the whole string, not the first
                 * subexpression */
                char * substr;
                regmatch_t cpmatch;
                for (i = 1; i < REG_MAX_SUB; i++)
                {
                    cpmatch = pmatch[i];
                    substr = StrSubstr(pathPart, cpmatch.rm_so, cpmatch.rm_eo);
                    if (pmatch[i].rm_so == -1)
                    {
                        break;
                    }
-                    ArrayAdd(matches, substr);
+                    ArrayAdd(matches, StrSubstr(pathPart, pmatch[i].rm_so, pmatch[i].rm_eo));
                }
            }
        }
--- a/Cytoplasm/src/Str.c
+++ b/Cytoplasm/src/Str.c
@ -147,6 +147,7 @@ StrSubstr(const char *inStr, size_t start, size_t end)
    }
    len = end - start;
    outStr = Malloc(len + 1);
    if (!outStr)
    {
--- a/docs/CHANGELOG.md
+++ b/docs/CHANGELOG.md
@ -19,11 +19,6 @@ The following endpoints were added:
 - **POST** `/_matrix/client/v3/user/{userId}/filter`
 - **GET** `/_matrix/client/v3/user/{userId}/filter/{filterId}`
 ### Bug Fixes
 - Fixed a double-free in `RouteUserProfile()` that would cause errors with certain
 Matrix clients. (#35)
 ## v0.3.0
 **Saturday, June 10, 2023**
@ -75,7 +70,7 @@ to add support for.
 a TLS port and a non-TLS port, for example.
 - Moved all program configuration to the data directory and added an administrator
 API endpoint to manage it. It is now no longer recommended to manually update the
-configuration file. Consult the [Administrator API](user/admin/README.md) documentation
+configuration file. Consult the [Administrator API](user/admin.md) documentation
 and the [Configuration](user/config.md) documentation.
 - Added an administrator API endpoint for process control. Telodendria can now be
 restarted or shutdown via API endpoint.
--- a/docs/CONTRIBUTING.md
+++ b/docs/CONTRIBUTING.md
@ -1,163 +0,0 @@
 # Contributing
 Telodendria is a fully open source project. As such, it welcomes
 contributions. There are many ways you can contribute, and any way you
 can is greatly appreciated. This document details the ways you can
 contribute, and how to go about contributing.
 ## Sponsoring Telodendria
 If you would like to sponsor Telodendria, see the
 [Sponsorship](../README.md#sponsorship) section on the main project
 page. Donations of any size are greatly appreciated.
 ## Reporting Issues
 An important way to get involved is to just report issues you find with
 Telodendria during experimentation or normal use. To report an issue,
 go to [Issues](/Telodendria/telodendria/issues) &rightarrow;
 [New Issue](/Telodendria/telodendria/issues/new/choose) and follow the
 instructions.
 > **Note:** GitHub issues are not accepted. Issues may only be
 > submitted to the official [Gitea](https://git.telodendria.io)
 > instance.
 ### Feature Requests
 Feature requests are allowed, but note that they are low-priority in
 comparison to existing issues and features. That being said, don't
 hesitate to submit feature requests. Just select the "Feature Request"
 option when submitting an issue.
 ## Developing
 If you want to write code for Telodendria, either to fix an issue or
 add a new feature, you're in the right place. Please follow all the
 guidelines in this document to ensure the contribution workflow goes
 as smoothly as possible.
 ### Who can develop Telodendria?
 Everyone is welcome to contribute code to Telodendria, provided that
 they are willing to license their contributions under the same license
 as the project itself.
 The primary language used to write Telodendria code is ANSI C. Other
 languages you'll find in the Telodendria repository include shell
 scripts, `mdoc`, a little bit of HTML and CSS, and `Makefiles`.
 Experience with any of these is preferred, but if you want to use
 Telodendria to learn, that's okay too! Telodendria's code base should
 hopefully be a good learning tool, and if you are serious about
 submitting quality work, we'll guide you through the process and
 offer suggestions.
 ### What do I need?
 You'll need a couple of things to develop Telodendria:
 - A Unix-like operating system that provides standard POSIX behavior,
 or the Windows Subsystem for Linux (WSL), Cygwin, or Msys2 if you are
 running Windows.
 - A C compiler capable of compiling ANSI C89 code (pretty much all of
 them do&mdash;pick your favorite, and if you find it doesn't work,
 open an issue!).
 - `make` for building the project.
 - `git` for managing your changes.
 Optionally, you may also find these tools helpful:
 - `indent` for formatting code.
 - `valgrind` for debugging particularly nasty issues.
 ### Getting The Code
 Telodendria is developed using Git. The easiest way to contribute
 changes is to fork the main repository, and then creating a pull
 request to ask us to pull your changes into our repo.
 1. If you don't have an account on the
 [Gitea instance](https://git.telodendria.io), create one and sign in.
 1. Fork this repository.
 1. In your development environment, clone your fork:
   ```shell
   git clone https://git.telodendria.io/[YOUR_USERNAME]/telodendria.git
   cd telodendria
   ```
   Please base your changes on the `master` branch. If you need help
   getting started with Git, that is beyond the scope of this
   document, but you can find many good tutorials on the web.
 ### Building &amp; Running
 Telodendria uses the `make` build system.
 **TODO:** Update this section before #19 is closed. Provide quick
 make, run, and install directions (maybe just redirect to Porting for
 install directions), then list all the `make` recipes. Shouldn't be
 as many as were in `td`.
 ### Pull Requests
 > **Note:** Telodendria does not accept GitHub pull requests at this
 > time. Please submit your pull requests via Gitea.
 Telodendria follows the standard pull request procedures. Once you have
 made your changes, committed them, and pushed to your fork, you should
 be able to open a pull request on the main repository. When you do, you
 will be prompted to write a description. Be sure to include the
 related issue that you are closing in your description.
 ### Code Style
 In general, these are the conventions used by the code base. This
 guide may be slightly outdated or subject to change, but it should be
 a good start. The source code itself is always the absolute source of
 truth, so as long as you make your code look like the code surrounding
 it, you should be fine.
 - All function, enumeration, structure, and header names are
 `CamelCase`. This is preferred to `snake_case` because it is more
 compact.
 - All variable names are `lowerCamelCase`. This is preferred to
 `snake_case` because it is more compact. One exception to this rule is
 if a variable name, such as a member of a struct, directly represents
 a JSON key in an object specified by the Matrix specification, which
 may be in `snake_case`.
 - Enumerations and structures are always `typedef`-ed to their same
 name. The `typedef` should occur in the public API header, and the
 actual declaration should live in the implementation file, unless
 the enumeration or structure is intended to be made fully public.
 - A feature of the code base lives in a single C source file that has a
 matching header. The header file should only export public symbols;
 everything else in the C source should be static.
 - Except where absolutely necessary, global variables are forbidden
 to prevent problems with threads and whatnot. Every variable a
 function needs should be passed to it either through a structure, or
 as a separate argument.
 - Anywhere that C allows curly braces to be optional, there still must
 be curly braces. This makes it easier to read the code by making it
 less ambiguous, and it makes it easier to add on to the code later.
 As far as actually formatting the code goes, such as where to put
 brackets, and whether or not to use tabs or spaces, use `indent` to
 take care of that. The repository contains a `.indent.pro` that should
 automatically be loaded by `indent` to set the correct rules. If you
 don't have a working `indent`, then just indicate in your pull
 request that I should run my `indent` on the code.
 ### Documentation
 This project places a strong emphasis on documentation. Well-documented
 code is fundamental to a successful project, so when you are writing
 code, please also make sure that it is documented appropriately.
 - If you are adding a header, make sure you add the necessary comments
 detailing the header and the functions in it.
 - If you are adding a function, make sure you add the necessary
 comments to the appropriate header.
 If your pull request does not also include proper documentation, it
 will likely be rejected.
--- a/docs/README.md
+++ b/docs/README.md
@ -4,11 +4,6 @@ Here you will find all of the documentation for Telodendria. If you
 find that some documentation is missing or incorrect, please open an
 issue, and, even better, a pull request to fix the issue.
 You are also welcome to join the
 [`#telodendria-general:bancino.net`](https://matrix.to/#/#telodendria-general:bancino.net)
 matrix room, where you can discuss Telodnedria with others and ask
 questions.
 ## User Documentation
 - [System Requirements](user/requirements.md)
@ -16,7 +11,7 @@ questions.
 - [Usage & Running](user/usage.md)
 - [Initial Set Up](user/setup.md)
 - [Configuration Options](user/config.md)
- [Administrator API](user/admin/README.md)
+- [Administrator API](user/admin.md)
 ## Developer Documentation
--- a/docs/user/admin/README.md
+++ b/docs/user/admin/README.md
@ -1,36 +0,0 @@
 # Administrator API
 Telodendria provides an administrator API as an extension to the
 Matrix specification that allows for administrator control over the
 homeserver. This includes profiling and examining the state of
 running instances, as well as managing users and media.
 Like Synapse, Telodendria supports designating specific local users as
 administrators. However, unlike Synapse, Telodendria uses a more
 fine-grained privilege model that allows a server administrator to
 delegate specific administration tasks to other users while not
 compromising and granting them full administrative access to the server.
 To authenticate with the administrator API, simply use your login
 access token just like you would authenticate any other Matrix client
 request.
 - [Privileges](privileges.md)
 - [Configuration](config.md)
 - [Server Statistics](stats.md)
 - [Process Control](proc.md)
 ## API Conventions
 Unless otherwise indicated, HTTP response codes that are not `200 Ok`
 will be accompanied by a standard Matrix API error. Consult the Matrix
 specification for the format of these errors. The following error
 conditions are assumed to be possible for all API endpoints listed
 in the Administrator API documentation:
 | Response Code | Description |
 |---------------|-------------|
 | 400           | The user is not authenticated, did not provide a valid JSON object, or provided a JSON object with invalid or missing parameters.|
 | 403           | The user does not have the privileges necessary to carry out the requested action.|
 | 500           | A fatal server error occurred. Check the logs for more information.|
--- a/docs/user/admin/config.md
+++ b/docs/user/admin/config.md
@ -1,42 +0,0 @@
 # Administrator API: Configuration
 As mentioned in [Setup](../setup.md), Telodendria's configuration is
 intended to be managed via the configuration API. Consult the
 [Configuration](../config.md) document for a complete list of supported
 configuration options. This document simply describes the API used to
 update the configuration.
 ## API Endpoints
 ### **GET** `/_telodendria/admin/config`
 Retrieve the current configuration.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The current configuration was successfully retrieved.|
 ### **POST** `/_telodendria/admin/config`
 Installs a new configuration. This endpoint validates the request body,
 ensuring it is a proper configuration, then it replaces the existing
 configuration with the new one.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The new configuration was successfully installed.|
 #### 200 Response Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `restart_required` | `Boolean` | Whether or not the process needs to be restarted to finish applying the configuration. If this is `true`, then the restart endpoint should be used at a convenient time to apply the configuration.
--- a/docs/user/admin/privileges.md
+++ b/docs/user/admin/privileges.md
@ -1,141 +0,0 @@
 # Administrator API: Privileges
 This document describes the privilege model and the API endpoints that
 allow administrators to modify privileges for users.
 ## List Of Privileges
 A local user can have any of the following privileges. Unless otherwise
 indicated, these privileges only grant access to certain parts of the
 administrator API; the regular Matrix API is unaffected.
 - **DEACTIVATE:** Allows a user to deactivate any other local users.
 - **ISSUE_TOKENS:** Allows a user to create, modify, and delete
 registration tokens.
 - **CONFIG:** Allows a user to modify the Telodendria server daemon's
 configuration.
 - **GRANT_PRIVILEGES:** Allows a user to modify his or her own
 privileges or the privileges of other local users.
 - **ALIAS:** Allows a user to modify room aliases created by other
 users. By default, users can only manage their own room aliases, but
 an administrator may wish to take over an alias or remove an offensive
 alias.
 - **PROC_CONTROL:** Allows a user to get statistics on the running
 process, as well as shutdown and resetart the Telodendria daemon
 itself. Typically this will pair well with **CONFIG**, because there
 are certain configuration options that require the process to be
 restarted to take full effect.
 There is also a special "pseudo-privilege":
 - **ALL:** Grants a user all of the aforementioned privileges, as well
 as privileges that do not yet exist. That is, if an update to
 Telodendria adds more privileges, users with this privilege will
 automatically gain those new privileges in addition to having all the
 existing privileges. This privilege should only be used with
 fully-trusted users. It is typical for a server administrator to not
 fully trust anyone else, and be the only one that holds an account with
 this privilege level.
 ## API Endpoints
 The following API endpoints are implemented for managing privileges.
 ### **GET** `/_telodendria/admin/privileges/[localpart]`
 Retrieve the permissions for a user. If the localpart is omitted, then
 retrieve the privileges for the user that owns the access token being 
 used. Note that the owner of the access token must have the
 **GRANT_PRIVILEGES** privilege to use this endpoint.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The privileges were successfully retrieved.|
 #### 200 Response Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `privileges` | `Array` | An array of privileges, as described above. The privileges are encoded as JSON strings.|
 ### **POST** `/_telodendria/admin/privileges/[localpart]`
 Update the privileges of a local user by replacing the privileges array
 with the one specified in the request. Like the **GET** version of this
 endpoint, the localpart can be omitted to operate on the user that
 owns the access token.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The privileges were successfully replaced.|
 #### Request Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `privileges` | `Array` | An array of privileges, as described above. The privileges are encoded as JSON strings.|
 #### 200 Response Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `privileges` | `Array` | An array of privileges, as described above. The privileges are encoded as JSON strings.|
 ### **PUT** `/_telodendria/admin/privileges/[localpart]`
 Update the privileges of a local user by adding the privileges
 specified in the request to the users existing privileges.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The privileges were successfully added.|
 #### Request Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `privileges` | `Array` | An array of privileges, as described above. The privileges are encoded as JSON strings.|
 #### 200 Response Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `privileges` | `Array` | An array of privileges, as described above. The privileges are encoded as JSON strings.|
 ### **DELETE** `/_telodendria/admin/privileges/[localpart]`
 Update the privileges of a local user by removing the privileges
 specified in the request from the user's existing privileges.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The privileges were successfully removed.|
 #### Request Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `privileges` | `Array` | An array of privileges, as described above. The privileges are encoded as JSON strings.|
 #### 200 Response Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `privileges` | `Array` | An array of privileges, as described above. The privileges are encoded as JSON strings.|
--- a/docs/user/admin/proc.md
+++ b/docs/user/admin/proc.md
@ -1,49 +0,0 @@
 # Administrator API: Process Control
 This document describes the administrator APIs that allow a server
 administrator to manage the Telodendria process itself.
 ## API Endpoints
 ### **POST** `/_telodendria/admin/restart`
 Restart the Telodendria daemon cleanly. This endpoint will respond
 immediately after signaling to the daemon that it should be restarted
 as soon as possible. Note that the restart wmay not happen
 instantaneously, as Telodendria will finish processing all current
 requests before restarting. Also note that this is not a true restart;
 the process does not exit and restart, rather, Telodendria simply tears
 down all its state and then jumps back to the beginning of its code and
 starts over.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The restart request was successfully sent.|
 On success, this endpoint simply returns an empty JSON object.
 ### **POST** `/_telodendria/admin/shutdown`
 Shut down the Telodendria process cleanly. This endpoint will respond
 immediately after signalling to the daemon that it should be shut
 down as soon as possible. Note that the shutdown may not happen
 instantaneously, as Telodendria will finish processing all current
 requests before shutting down. Also note that once shut down, Telodendria
 may be automatically restarted by the system's service manager.
 Otherwise, it will have to be manually restarted. This is a true
 shutdown; the Telodendria process exits as soon as possible.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The shutdown request was successfully sent.|
 On success, this endpoint simply returns an empty JSON object.
--- a/docs/user/admin/stats.md
+++ b/docs/user/admin/stats.md
@ -1,26 +0,0 @@
 # Administrator API: Server Statistics
 The administrator API allows users with the proper privileges to get
 information about how the server process is performing.
 ## API Endpoints
 ### **GET** `/_telodendria/admin/stats`
 Retrieve basic statistics about the currently running Telodendria
 process.
 | Requires Token | Rate Limited |
 |----------------|--------------|
 | Yes            | Yes          |
 | Response Code | Description |
 |---------------|-------------|
 | 200           | The server statistics were successfully retrieved.|
 #### 200 Response Format
 | Field | Type | Description |
 |-------|------|-------------|
 | `memory_allocated` | `Integer` | The total amount of memory allocated, measured in bytes.|
 | `version` | `String` | The current version of Telodendria.|
--- a/docs/user/config.md
+++ b/docs/user/config.md
@ -1,246 +0,0 @@
 # Configuration
 Telodendria is designed to be configurable. It is configured using
 JSON, which is intended to be submitted to the [Administrator
 API](admin/README.md). This document details Telodendria's configuration
 JSON format, which is used in both the administrator API and on-disk
 in the database. The configuration file on the disk in the databsae
 is `config.json`, though that file should not be edited by hand.
 Use the API described in
 [Administrator API &rightarrow; Configuration](admin/config.md).
 ## JSON Format
 Telodendria's configuration is just a JSON object in the standard
 key-value form:
 ```json
 {
    "serverName": "telodendria.io",
    "listen": [
        {
            "port": 8008,
            "tls": false
        }
    ]
    /* ... */
 }
 ```
 Some keys, called *directives* in this document, have values that are
 objects themselves.
 ## Directives
 Here are the top-level directives:
 - **listen:** `Array`
  An array of listener description objects. Telodendria supports
  listening on multiple ports, and each port is configured
  independently of the others. A listener object looks like this:
  - **port:** `integer`
    The port to listen on. Telodendria will bind to all interfaces,
    so it is recommended to configure your firewall to only allow
    access on the desired interfaces. Note that Telodendria offers all
    APIs over each port, including the administrator APIs; there is no
    way to control which APIs are made available over which ports. If
    this is a concern, a reverse-proxy such as `relayd` can be placed
    in front of Telodendria to block access to undesired APIs.
  - **tls:** `Object|null|false`
    Telodendria can be compiled with TLS support. If it is, then a
    particular listener can be set to use TLS for connections. If
    **tls** is not `null` or `false`, then it can be an object with
    the following directives:
    - **cert:** `String`
      The full path&mdash;or path relative to the data
      directory&mdash;of the certificate file to load. The certificate
      file should be in the format expected by the platform's TLS
      library.
    - **key:** `String`
      Same as **cert**, but this should be the private key that matches
      the certificate being used.
  - **threads:** `Integer`
    How many worker threads to spin up to handle requests for this
    listener. 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.
    Note that this can be set as low as 0; in that case, the listener
    will never respond to requests. Each listener needs to have at
    least one thread to be useful. Also note that Telodendria may spin
    up additional threads for background work, so the actual total
    thread count at any given time may exceed the sum of threads
    specified in the configuration.
    This directive is optional. The default value is `4` in the upstream
    code, but your software distribution may have patched this to be
    different.
  - **maxConnections:** `Integer`
    The maximum number of simultanious connections to allow to the
    daemon. This option prevents the daemon from allocating large
    amounts of memory in the event that it undergoes a denial of
    service attack. It is optional, defaults to `32`, and typically
    does not need to be adjusted.
 - **serverName:** `String`
  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. **serverName** should be a DNS name that
  can be publicly resolved. This directive is required.
 - **baseUrl:** `String`
  Set the server's base URL. **baseUrl** 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 unspecified, it is automatically
  deduced from the server name.
 - **identityServer:** `String`
  The identity server that clients should use to perform identity
  lookups. **identityServer** folows the same rules as **baseUrl**.
  It also is optional, and is set to be the same as the **baseUrl**
  if left unspecified.
 - **runAs:** `Object`
  The effective Unix user and group to drop to after binding to the
  socket and completing any setup that may potentially require
  elevated privileges. This directive only takes effect if
  Telodendria is started as the root user, and is used as a security
  mechanism. If this option is set and Telodendria is started as a
  non-privileged user, then a warning is printed to the log if that
  user and group do not match what's specified here. This directive
  is optional, but should be used as a sanity check even if not
  running as `root`, just to make sure you have your permissions
  working properly.
  This directive takes an object with the following directives:
  - **uid:** `String`
    The Unix username to switch to. If **runAs** is specified, this
    directive is required.
  - **gid:** `String`
    The Unix group to switch to. This directive is optional; if left
    unspecified, then the value of **uid** is copied.
 - **federation:** `Boolean`
  Whether or not to enable federation with other Matrix homeservers.
  Matrix by its very nature is a federated protocol, but if you just
  want to rn 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.
 - **registration:** `Boolean`
  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 allow only certain users to be registered using
  registration tokens, which can be managed via the administrator API.
  This directive is required.
  In an ideal world, everyone would run their own Matrix 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 IPv4 addresses are becoming increasingly
  hard to come by. If you would like to provide a service to those
  that are unable to run their homeserver, then set this to `true`,
  thereby allowing anyone to create an account.
  Telodendria *should* be capable of handling a large amount of users
  without difficulty, but it is targetted at smaller deployments.
 - **log:** `Object`
  The logging 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:
  - **output:** `Enum`
    The log output destination. This can either be `stdout`, `file`,
    or `syslog`. If set to `file`, Telodendria will log to
    `telodendria.log` inside the data directory.
  - **level:** `Enum`
    The level of messages to log. Each level shows all the levels above
    it. The levels are as follows:
    - `error`
    - `warning`
    - `notice`
    - `message`
    - `debug`
    For example, setting the level to `error` will show only errors,
    while setting the level to `warning` will show both warnings
    *and* errors. The `debug` level shows all messages.
  - **timestampFormat:** `Enum`
    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()` documentation. This option only
    applies if **log** is `stdout` or `file`.
  - **color:** `Boolean`
    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.
 - **maxCache:** `Integer`
  The maximum size of the cache. Telodendria relies heavily on caching
  for performance reasons. 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 with a lot of memory
  to spare, you'll get better performance if this option is set higher.
  Otherwise, this value should be lowered on systems that have a
  minimal amount of memory available.
 ## Examples
 A number of example configuration files are shipped with Telodendria's
 source code. They can be found in the `contrib/` directory if you are
 viewing the source code directly. Otherwise, if you installed
 Telodendria from a package, it is possible that the example
 configurations were placed in the default locations for such files on
 your operating system.
--- a/docs/user/install.md
+++ b/docs/user/install.md
@ -48,13 +48,4 @@ binaries.
 ## From Source
-If you would like to build Telodendria from source, you can download
+**TODO:** Update this section before #19 is closed.
 the latest release code from the
 [Releases](/Telodendria/telodendria/releases) page. After extracting
 the tarball, read
 [Contributing &rightarrow; Developing &rightarrow; Building &amp; Running](../CONTRIBUTING#building-and-running)
 for details on how to build Telodendria.
 If all goes well, you will find the server binary in the `build/`
 directory. If an error occured, and you didn't modify the code,
 please open an issue.
--- a/docs/user/setup.md
+++ b/docs/user/setup.md
@ -26,7 +26,7 @@ source, execute the binary directly. If needed, consult the
 initialize its database directly with a simple&mdash;and, importantly,
 safe&mdash;default configuration, as well as a randomly generated,
 single-use registration token that grants a user all privileges
-documented in the [Administrator API](admin/README.md) documentation.
+documented in the [Administrator API](admin.md) documentation.
 Consult the log file for this administrator registration token. By
 default, the log file is located in the data directory, and is named
 `telodendria.log`.
@ -40,7 +40,7 @@ it also has all privileges granted to it, so it can make full use of
 the Administrator API.
 1. Using the access token granted for the administrator account via
 the login process, configure Telodendria as descibed in
-[Configuration](config.md). See the [Administrator API](admin/README.md)
+[Configuration](config.md). See the [Administrator API](admin.md)
 documentation for the configuration endpoint details.
 This is the recommended way to set up Telodendria. However, if you
--- a/docs/user/usage.md
+++ b/docs/user/usage.md
@ -9,7 +9,7 @@ testing or debugging purposes.
 ## Command Line Options
 Typically, Telodendria is controlled via the
-[Administrator API](admin/README.md), but the Telodendria binary does include
+[Administrator API](admin.md), but the Telodendria binary does include
 a few command line options, which can be used in init scripts or for
 debugging purposes.
--- a/man/man1/send-patch.1
+++ b/man/man1/send-patch.1
@ -0,0 +1,57 @@
 .Dd $Mdocdate: April 29 2023 $
 .Dt SEND-PATCH 1
 .Os Telodendria Project
 .Sh NAME
 .Nm send-patch
 .Nd Submit a patch file to the Telodendria Patches Matrix room
 .Sh SYNOPSIS
 .Nm
 .Op patch
 .Sh DESCRIPTION
 .Nm
 is a simple shell script for submitting patch files to Telodendria's patch
 room for review.
 .Pp
 .Nm
 takes a single argument, a patch file. It also reads a number of environment
 variables, as described in the following section. This script is designed to be
 simple; it only pushes files into a hard-coded Matrix room. Thus, as far as
 Matrix clients go, this one is a rather minimal one, and that is by design.
 .Pp
 This script exists so that users who are working on a machine that doesn't have
 a Matrix client installed can still submit work to the Telodendria project. The
 goal is to make development as accessible as possible.
 .Pp
 This script only supports password login, so if your homeserver does not
 support password login, it will not work.
 .Sh ENVIRONMENT
 .Pp
 .Nm
 utilizes the following environment variables:
 .Bl -tag -width Ds
 .It Ev MXID
 Your Matrix ID in the standard format. This is used to connect to your
 homeserver to send the message.
 .It Ev MXPW
 Your Matrix account's password. If not set, you will be prompted for your
 password by the script, unless
 .Ev ACCESS_TOKEN
 is set.
 .It Ev ACCESS_TOKEN
 If you already have an access token for your account, such as one from an
 existing session, then you can set this environment variable to bypass the
 password authentication flow.
 .El
 .Sh FILES
 .Pp
 .Nm
 does utilize the
 .Pa .env
 file, just like
 .Xr td 1 .
 Consult that page for the specifics of the
 .Pa .env
 file.
 .Sh SEE ALSO
 .Xr td 1
--- a/man/man1/tp.1
+++ b/man/man1/tp.1
@ -0,0 +1,63 @@
 .Dd $Mdocdate: April 29 2023 $
 .Dt TP 1
 .Os Telodendria Project
 .Sh NAME
 .Nm tp
 .Nd Manage the official patch queue.
 .Sh SYNOPSIS
 .Np
 .Op action
 .Op patch
 .Sh DESCRIPTION
 .Pp
 This script is probably not going to be very useful for anyone other
 than the official project managers, but for completeness, this page
 documents it.
 .Pp
 .Nm
 is a simple script that is used to manage the patch queue. It offers a
 simple way to fetch patches from the patch Matrix room and queue them
 in a patch directory, which is then updated as patches are handled.
 Contributions to Telodendria are entirely patch-based, so this script
 makes dealing with patch files much more convenient.
 .Pp
 .Nm
 doesn't implement a complex command line interface. It simply takes an
 action as the first argument, and a patch file ID as the second
 argument to some actions. The actions are as follows:
 .Bl -tag -width Ds
 .It ingress
 Download all new patches from the patches room. This action is intended
 to be called periodically from
 .Xr cron 8
 to fetch new patches.
 .It queue
 List all the patches in the queue, printing the first three lines of
 each one so they can be easily identified.
 .It view
 View the specified patch. Note that the specified patch must be in
 the queue. Once it is applied or rejected, this script offers no
 facility for viewing it.
 .It apply
 Apply the specified patch to the current working directory.
 .It reverse
 Reverse the specified patch on the current working directory.
 .It accept|reject
 Accept or reject the specified patch by moving it to the appropriate
 directory. These actions also prompt for a message, into which it is
 expected that an explanation for why the patch was accepted or rejected
 will be placed.
 .El
 .Sh ENVIRONMENT
 .Pp
 The following environment variables are read by the
 .Nm
 script:
 .Bl -tag -width Ds
 .It Ev TELODENDRIA_PUB
 The base directory inside which the patch directory relies.
 .It Ev HOMESERVER
 The Matrix homeserver to contact for receiving patches.
 .It Ev ACCESS_TOKEN
 The access token to use to authenticate with the Matrix homeserver.
 .El
--- a/man/man7/telodendria-admin.7
+++ b/man/man7/telodendria-admin.7
@ -0,0 +1,421 @@
 .Dd $Mdocdate: August 9 2023 $
 .Dt TELODENDRIA-ADMIN 7
 .Os Telodendria Project
 .Sh NAME
 .Nm telodendria-admin
 .Nd Administrator API documention.
 .Sh DESCRIPTION
 .Pp
 Telodendria provides an administrator API that allows for administrator control
 over the homeserver. This includes profiling and examining the state of Telodendria,
 as well as managing users and media.
 .Pp
 Like Synapse, Telodendria supports designating specific users as administrators.
 However, unlike Synapse, it uses a more finely-grained privilege model that allows
 a server administrator to designate specific administration tasks to other users
 while not compromising and granting them full administrative access to the server.
 .Pp
 To authenticate with the administrator API, simply use a regular
 access token.
 .Ss Privileges
 .Pp
 Here are all of the privileges a local user can have. Unless otherwise specified,
 these privileges only grant access to certain parts of the administrator API; the
 regular Matrix API is unaffected.
 .Bl -tag -width -Ds
 .It Dv DEACTIVATE
 Allows a user to deactivate any other local users.
 .It Dv ISSUE_TOKENS
 Allows a user to create, modify, and delete registration tokens.
 .It Dv CONFIG
 Allows a user to modify the Telodendria server daemon's configuration.
 .It Dv GRANT_PRIVILEGES
 Allows a user to modify his or her own privileges or the privileges of other
 local users.
 .It Dv ALIAS
 Allows a user to modify room aliases created by other users. By default, users
 can only manage their own room aliases, but an administrator may wish to take
 over an alias or remove an offensive alias.
 .It Dv PROC_CONTROL
 Allows a user to get statistics on the running process, as well as shutdown and
 restart the Telodendria daemon itself. Typically this will pair well with
 .Dv CONFIG ,
 because there are certain configuration options that require the process to be
 restarted.
 .El
 .Pp
 There is also a special ``pseudo-privilege'':
 .Bl -tag -width Ds
 .It Dv ALL
 Grants a user all of the aforementioned privileges, as well as privileges that
 do not yet exist. That is, if an update to Telodendria adds more privileges,
 users with this privilege will automatically gain those new privileges in
 addition to having all of the existing privileges.
 .Pp
 This privilege should only be used with fully-trusted users. It is typical for
 a server administrator to not fully trust anyone else, and be the only one that
 holds an account with this privilege level.
 .El
 .Sh API ENDPOINTS
 .Pp
 The following API endpoints are implemented for the installed version of
 Telodendria.
 .Pp
 Unless otherwise indicated, HTTP response codes that are not 200 Ok
 will be accompanied by a standard Matrix API error. Consult the Matrix specification
 for the format of these errors. The following error conditions are assumed to be
 possible for all of the endpoints listed here:
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 400;T{
 The user is not authenticated, did not provide a valid JSON object,
 or provided a JSON object with invalid parameters. 
 T}
 403;T{
 The user does not have the privileges necessary to carry out the
 specified action.
 T}
 500;T{
 A fatal server error occured. Check the logs for more information.
 T}
 .TE
 .Ss Sy GET No /_telodendria/admin/privileges/[localpart]
 .Pp
 Retrieve the permissions for a user. If the localpart is
 omitted, then retrieve the privileges for the user that owns
 the access token being used. Note that the owner of the
 access token must have the
 .Dv GRANT_PRIVILEGES
 privilege.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The privileges were successfully retrieved.
 T}
 .TE
 .Pp
 200 Response Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 privileges;Array;T{
 An array of privileges, as described above. The
 privileges are represented as strings in JSON.
 T}
 .TE
 .Ss Sy POST No /_telodendria/admin/privileges/[localpart]
 .Pp
 Update the privileges of a local user by replacing the
 privileges array with the one specified in the request.
 Like the
 .Sy GET
 version of this endpoint, the localpart can be omitted to
 operate on the user that owns the access token.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The privileges were successfully replaced.
 T}
 .TE
 .Pp
 Request Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 privileges;Array;T{
 An array of privileges, as described above. The
 privileges are represented as strings in JSON.
 T}
 .TE
 .Pp
 200 Response Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 privileges;Array;T{
 An array of privileges, as described above. The
 privileges are represented as strings in JSON.
 T}
 .TE
 .Ss Sy PUT No /_telodendria/admin/privileges/[localpart]
 .Pp
 Update the privileges of a local user by adding the privileges
 specified in the request to the user's existing privileges.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The requested privileges were successfully added.
 T}
 .TE
 .Pp
 Request Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 privileges;Array;T{
 An array of privileges, as described above. The
 privileges are represented as strings in JSON.
 T}
 .TE
 .Pp
 200 Response Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 privileges;Array;T{
 An array of privileges, as described above. The
 privileges are represented as strings in JSON.
 T}
 .TE
 .Ss Sy DELETE No /_telodendria/admin/privileges/[localpart]
 .Pp
 Update the privileges of a local user by removing the privileges
 specified in the request from the user's existing privileges.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The requested privileges were successfully removed.
 T}
 .TE
 .Pp
 Request Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 privileges;Array;T{
 An array of privileges, as described above. The
 privileges are represented as strings in JSON.
 T}
 .TE
 .Pp
 200 Response Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 privileges;Array;T{
 An array of privileges, as described above. The
 privileges are represented as strings in JSON.
 T}
 .TE
 .Ss Sy POST No /_telodendria/admin/config
 .Pp
 Installs a new configuration. It validates the request body, ensuring it is a
 proper configuration, then replaces the existing configuration with the new one.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token; Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The new configuration was successfully installed.
 T}
 .TE
 .Pp
 Consult the
 .Xr telodendria-config 7
 manual page for a full description of the configuration object that should
 be submitted. That page lists all the fields, and notes which ones are
 required.
 .Pp
 200 Response Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 restart_required;Boolean;T{
 Whether or not the process needs to be restarted to finish applying the
 configuration. If this is true, the restart endpoint may be used.
 T}
 .TE
 .Ss Sy GET No /_telodendria/admin/config
 .Pp
 Retrieve the current configuration.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The current configuration was successfully retrieved.
 T}
 .TE
 .Pp
 Consult the
 .Xr telodendria-config 7
 manual page for a full description of the configuration object that
 is returned. Note that this is the same object that was submitted
 using the
 .Sy POST
 version of this endpoint, otherwise it is the default configuration.
 .Ss Sy GET No /_telodendria/admin/stats
 .Pp
 Retrieve statistics about the currently running Telodendria process.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The server statistics were successfully retrieved.
 T}
 .TE
 .Pp
 200 Response Format:
 .TS
 tab(;) allbox expand;
 lfB lfB lfB
 l l l.
 Field;Type;Description
 memory_allocated;Integer;T{
 The total amount of memory allocated, measured in bytes.
 T}
 version;String;T{
 The current version of Telodendria.
 T}
 .TE
 .Ss Sy POST No /_telodendria/admin/restart
 .Pp
 Restart the Telodendria daemon cleanly. This endpoint will respond immediately
 after signaling to the daemon that it should be restarted as soon as possible.
 Note that the restart may not happen instantaneously, as Telodendria will finish
 processing all current requests before restarting. Also note that this is not a
 ``true'' restart; the process does not exit and restart, rather, Telodendria
 simply tears down its state, and then jumps back to the beginning of its code
 and starts over.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The restart request was successfully sent.
 T}
 .TE
 .Pp
 On success, this endpoint simply returns an empty JSON object.
 .Ss Sy POST No /_telodendria/admin/shutdown
 .Pp
 Shut down the Telodendria process cleanly. This endpoint will respond immediately
 after signaling to the daemon that it should be shut down as soon as possible.
 Note that the shutdown may not happen instantaneously, as Telodnedria will
 finish processing all current requests before shutting down. Also note that once
 shut down, Telodendria may be automatically restarted by the system's service
 manager, otherwise, it will have to be manually restarted. This is a ``true''
 shutdown, the Telodendria process exits as soon as possible.
 .Pp
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Requires Token;Rate Limited
 Yes;Yes
 .TE
 .TS
 tab(;) allbox expand;
 lfB lfB
 l l.
 Response Code;Description
 200;T{
 The shutdown request was successfully sent.
 T}
 .TE
 .Pp
 On success, this endpoint simply returns an empty JSON object.
 .Sh SEE ALSO
 .Xr telodendria-config 7 ,
 .Xr telodendria-setup 7
--- a/man/man7/telodendria-config.7
+++ b/man/man7/telodendria-config.7
@ -0,0 +1,218 @@
 .Dd $Mdocdate: April 20 2023 $
 .Dt TELODENDRIA-CONFIG 7
 .Os Telodendria Project
 .Sh NAME
 .Nm telodendria-config
 .Nd Telodendria configuration.
 .Sh DESCRIPTION
 .Pp
 Telodendria is designed to be configurable. It is configured using
 JSON, which is intended to be submitted via the administrator API.
 This page documents Telodendria's configuration JSON format, which
 is used both in the administrator API, and on the disk in the
 database. The configuration file on the disk in the database is
 .Pa config.json ,
 though that file should not be edited directly. Use the API described
 in
 .Xr telodendria-admin 7
 instead.
 .Sh DIRECTIVES
 Here are the top-level directives:
 .Bl -tag -width Ds
 .It Ic listen Ar listenArr
 An array of listener description objects. Telodendria supports
 listening on multiple ports, and each port is configured
 independently of the others. A listener description object looks
 like this:
 .Bl -tag -width Ds
 .It Ic port Ar port
 The port to listen on. Telodendria will bind to all interfaces, so it
 is recommended to configure your firewall so you can control what is
 allowed to access the Telodendria ports. Note that
 Telodendria offers all APIs over each port; there is no way to
 control which APIs are available over which ports, although all
 APIs should be safe against attacks, so this should not be a
 major concern.
 .Pp
 .Ar port
 should be a decimal port number. This directive is required. Common
 port numbers are 8008 for non-TLS, and 8448 for TLS.
 .It Ic tls Ar tlsObj|null|false
 Telodendria can be compiled with TLS support. If it is, then a
 particular listener can be set to use TLS for connections. If
 .Ic tls
 is not
 .Ar null
 or
 .Ar false ,
 then it can be an object with the following directives:
 .Bl -tag -width Ds
 .It Ic cert Ar file
 A certificate file in the format native to the platform's TLS
 library. This can be an absolute path, otherwise it is relative
 to the data directory.
 .It Ic key Ar file
 A key file in the format native to the platform's TLS library.
 It follows the same rules as the certificate file.
 .El
 .El
 .It Ic serverName Ar 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.
 .Ar name
 should be a DNS name that can be publically resolved. This directive
 is required.
 .It Ic baseUrl Ar url
 Set the server's base URL.
 .Ar 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.
 .Pp
 This URL is the URL at which Matrix clients will connect to the server,
 and is thus served as a part of the
 .Pa .well-known
 manifest.
 .Pp
 This directive is optional. If it is not specified, it is automatically
 deduced from the server name.
 .It Ic identityServer Ar url
 The identity server that clients should use to perform identity lookups.
 .Pp
 .Ar url
 follows the same rules as
 .Ic baseUrl .
 .Pp
 This directive is optional. If it is not specified, it is automatically
 set to be the same as the base URL.
 .It Ic runAs Ar uidObj
 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.
 .Pp
 This directive takes an object with the following directives:
 .Bl -tag -width Ds
 .It Ic uid Ar user
 The UNIX username to drop to. If
 .Ic runAs
 is specified, this directive is required.
 .It Ic gid Ar group
 The UNIX group to drop to. This directive is optional; if it is not
 specified, then the value of
 .Ic uid
 is copied.
 .El
 .Ic log
 directive is configured to write to a file, the log file will be written
 in the data directory.
 .Ar directory
 should be an absolute path, under which all Telodendria data will live.
 .It Ic federation Ar true|false
 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
 .Ar true ,
 however, if you wish to be able to communicate with users on other Matrix
 servers. This directive is required.
 .It Ic registration Ar true|false
 Whether or not to enable new user registration or not. For security and anti-spam
 reasons, you can set this to
 .Ar 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 set this to
 .Ar 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.
 .It Ic log Ar logObj
 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:
 .Bl -tag -width Ds
 .It Ic output Ar stdout|file|syslog
 The lot output destination. If set to
 .Ar file ,
 Telodendria will log to
 .Pa telodendria.log
 inside the data directory.
 .It Ic level Ar error|warning|notice|message|debug
 The level of messages to log at. Each level shows all the levels above it. For
 example, setting the level to
 .Ar error
 will show only errors, while setting the level to
 .Ar warning
 will show warnings and errors.
 .Ar notice
 shows notices, warnings, and errors, and so on. The
 .Ar debug
 level shows all messages.
 .It Ic timestampFormat Ar format|none|default
 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
 .Ar none ,
 .Ar default ,
 or a formatter string as described by your system's
 .Xr strftime 3 .
 This option only applies if
 .Ic log
 is "stdout" or "file".
 .It Ic color Ar 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.
 .Pp
 This option only applies if
 .Ic log
 is "stdout".
 .El
 .It Ic threads Ar count
 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.
 .It Ic maxConnections Ar count
 The maximum number of simultanious connections to allow to the daemon. This option
 prevents the daemon from allocating large amounts of memory in the event that it
 undergoes a denial of service attack. It typically does not need to be adjusted.
 .It Ic maxCache Ar bytes
 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.
 .El
 .Sh FILES
 .Bl -tag -width Ds
 .It Pa config.json
 The configuration file stored on the filesystem in the data
 directory. It is not recommended to edit this directly.
 .It Pa /var/telodendria
 The recommended data directory.
 .El
 .Sh EXAMPLES
 .Pp
 A number of example configuration files are shipped with
 Telodendria's source code. They can be found in the
 .Pa contrib/
 directory if you are viewing the source code directly. Otherwise,
 if you installed Telodendria as a package, it is possible that the
 example configurations were placed in the default locations for
 such files on your operating system.
 .Sh SEE ALSO
 .Xr telodendria-setup 7 ,
 .Xr telodendria-admin 7
 .Xr telodendria 8
--- a/man/man7/telodendria-contributing.7
+++ b/man/man7/telodendria-contributing.7
@ -0,0 +1,268 @@
 .Dd $Mdocdate: March 10 2023 $
 .Dt TELODENDRIA-CONTRIBUTING 7
 .Os Telodendria Project
 .Sh NAME
 .Nm telodendria-contributing
 .Nd Guide to contributing to the Telodendria project.
 .Sh DESCRIPTION
 Telodendria 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. This page contains some of
 the ways you can help out.
 .Sh REPORTING ISSUES
 Please reach out to the Matrix rooms mentioned at the top of
 .Xr telodendria 7 .
 All issue tracking takes place in those rooms. Start by reaching
 out to the general room, and if you think there's a legitimate
 problem with Telodendria itself, then stick the issue in the
 issues room, where it can be discussed further. Issues usually
 remain in the Matrix rooms, but severe enough issues may be put
 in a
 .Pa TODO
 file in the
 .Xr cvs 1
 repository so that they don't get lost.
 .Sh DEVELOPING
 The primary language used to write Telodendria code is ANSI C.
 Other languages you'll find in the Telodendria repository include
 shell scripts, 
 .Xr mdoc 7 ,
 and a little bit of HTML and CSS. If you have any experience with
 any of these languages, your contributions are valuable! Please follow
 the guidelines on this page to ensure the contribution workflow goes
 as smoothly as possible.
 .Ss Getting the Code
 If you'd like to hack on Telodendria, you'll need the following tools
 in addition to a C compiler and POSIX shell:
 .Bl -tag
 .It Xr cvs 1
 For checking out and updating your local copy of the source code.
 .It Xr indent 1
 For formatting your code before generating patches.
 .It Xr patch 1
 For applying patches to your local copy of the source code.
 .El
 .sp
 All of these tools are built into OpenBSD. While you don't have to
 use OpenBSD to develop Telodendria, it may make the process a bit
 easier. In fact, these tools where chosen precisely because they
 were built into my operating system of choice.
 .sp
 You can download an official release tarball from the website if
 you would really like, but the preferred way to get the source
 code for development is to check it out from CVS. This makes generating
 patches a lot easier.
 .Bd -literal -offset indent
 $ cvs -d anoncvs@bancino.net:/cvs checkout -P Telodendria
 $ cd Telodendria
 .Ed
 .sp
 If you already checked out the code previously, make sure you update
 your local copy before you start developing:
 .Bd -literal -offset indent
 $ cvs -q update -dP
 .Ed
 .sp
 You should now have the latest source code. Follow the
 .Sx CODE STYLE
 as you make your changes. If the
 .Xr cvs 1
 command fails with a "Connection refused" error message, try setting
 the
 .Ev CVS_RSH
 environment variable to "ssh", like this:
 .Bd -literal -offset indent
 $ export CVS_RSH=ssh
 .Ed
 .sp
 Then run the checkout command again. Some versions of CVS on some
 systems don't use SSH to checkout by default, so if yours doesn't,
 you might want to put the above line into your shell init script.
 .Ss Submitting Patches
 Telodendria aims at remaining as minimal as possible. This doesn't just
 mean minimal code, it also means a minimal development process, which is
 why Telodendria 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.
 .sp
 If you're not used to manually creating and submitting patches instead of
 just 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's 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 properly as noted in the manual for
 .Xr td 1 ,
 just run the patch recipe:
 .Bd -literal -offset indent
 $ td patch
 .Ed
 .sp
 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 file for only
 certain files and directories. To do that, set
 .Ev PATCHSET ,
 like this:
 .Bd -literal -offset indent
 # Only write a patch for README.txt and the files in docs/
 $ PATCHSET="README.txt docs/" td patch
 .Ed
 .sp
 As you'll notice, the top of the patch file should have some email-style
 headers that look like this:
 .Bd -literal -offset indent
 From: Jordan Bancino <@jordan:bancino.net>
 Date: Fri Jul 29 03:21:21 PM EDT 2022
 Subject: Document Patch Procedure
 .Ed
 .sp
 As much information should be filled out for you, such as the date. An
 attempt to fill out the From header was also made by
 .Xr td 1 ,
 but the information there can be modifed as necessary. Consult the manual
 for
 .Xr td 1 
 for more details. The Subject should very briefly describe what the patch
 is about.
 .sp
 You'll also notice these lines in the patch:
 .Bd -literal -offset indent
 [ ] I have read the Telodendria Project development certificate of
    origin, and certify that I have permission to submit this patch
    under the conditions specified in it.
 .Ed
 .sp
 This is a checkbox that tells me whether or not you actually have the
 rights to submit your patch, and that once you submit your patch, your
 code is bound by the Telodendria project license, which you can and
 should view in
 .Xr telodendria 7 .
 The full text of the developer certificate of origin is as follows:
 .Bl -enum
 .It
 The contribution was created in whole or in part by me, and I have the right
 to submit it under the open source licenses of the Telodendria project; or
 .It
 The contribution is based upon a previous work that, to the best of my knowledge,
 is covered under an appropriate open source license and I have the right under
 that license to submit that work with modifications, whether created in whole
 or in part by me, under the Telodendria project license; or
 .It
 The contribution whas provided directly to me by some other person who certified
 (1), (2), or (3), and I have not modifed it.
 .It
 I understand and agree that this project and the contribution are made public
 and that a record of the contribution\(emincluding all personal information
 I submit with it\(emis maintained indefinitely and may be redistributed
 consistent with this project or the open source licenses involved.
 .El
 .sp
 If you agree to the above, fill in the square brackets with an 'x', and then after
 the headers, but before the checkbox, write a more thorough description of the
 patch and why it was created. Then, send the resulting patch file to the public
 Matrix room using
 .Xr send-patch 1 .
 .sp
 Try to keep your patches on topic\(emmake 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 description. Note that it may take a while for
 patches to be committed, and some patches may not be comitted at all. In either
 case, all sent patches are queued from the Matrix room into the public patch
 directory, so they can be referenced easier in the future. If you want to
 reference a submitted patch in a Matrix message, email, or other digital medium,
 it might be a good idea to link to it in the public patch directory.
 .sp
 The public patch directory works as follows: when you send your patch to the
 Matrix room, it is downloaded by Telodendria Bot and placed in the
 .Pa ingress/
 directory, named as the message ID. Then, it is assigned a patch ID and
 copied to the
 .Pa p/
 directory as just "%d.patch", where "%d" is obviously the patch ID. This is
 a permanent link that will always reference your patch. Then, your patch will
 be symlinked into the 
 .Pa queue/
 directory. I have a script that automatically ingresses patches and queues them
 for me, and I use this to review patches. If your patch is accepted, the queue
 symlink will be moved to
 .Pa accepted/
 and the submitted patch will be committed to the official CVS repository.
 If your patch is rejected for some reason, its symlink will be moved to the
 .Pa rejected/
 directory. Regardless of the state of your patch, it will always remain
 permalinked in the
 .Pa p/
 directory, and when it is accepted or rejected, Telodendria Bot will send a
 message to the Matrix room.
 .sp
 You're always welcome to inquire about rejected patches, and request that they
 be reviewed again, or you can use them as a starting point for future patches.
 .sp
 The public patch directory is located at
 .Lk https://telodendria.io/patches/
 .Sh CODE STYLE
 In general, these are the conventions used by the code base. This guide
 may be slightly outdated or subject to change, but it should be a good
 start. The source code itself is always the absolute source of truth, so
 as long as you make your code look like the code surrounding it, you should
 be fine.
 .Bl -bullet
 .It
 All function, enumeration, structure, and header names are CamelCase. This
 is preferred to snake_case because it is more compact.
 .It
 All variable names are lowerCamelCase. This is preferred to snake_case
 because it is more compact.
 .It
 enumerations and structures are always typedef-ed to their same name. The
 typedef should occur in the public API header, and the actual declaration
 should live in the implementation file.
 .It
 A feature of the code base lives in a single C source file that has a
 matching header. The header file should only export public symbols;
 everything else in the C source should be static.
 .It
 Except where absolutely necessary, global variables are forbidden to
 prevent problems with threads and whatnot. Every variable a function
 needs should be passed to it either through a structure, or as a
 separate argument.
 .It
 Anywhere curly braces are optional, there still must be curly braces. This
 makes it easier to add on to the code later, and just makes things a bit
 less ambiguous.
 .El
 .sp
 As far as actually formatting the code goes, such as where to put brackets,
 and whether or not to use tabs or spaces, use
 .Xr indent 1
 to take care of all of that. The root of the CVS repository has a
 .Pa .indent.pro
 that should automatically be loaded by
 .Xr indent 1
 to set the correct rules. If you don't have a working
 .Xr indent 1 ,
 then just indicate in your patch that I should run my
 .Xr indent 1
 on the code after applying it. Although in reality, I'll likely
 run my own
 .Xr indent 1
 on the code anyway, just to make sure the spacing is consistent, if nothing
 else.
 .Pp
 This project places a strong emphasis on documentation. Well-documented
 code is fundamental to a successful project, so when you are writing code,
 please also make sure it is documented appropriately.
 .Bl -bullet
 .It
 If you are adding a header, make sure you add a man page that documents
 all the functions in the header.
 .It
 If you're adding a function, make sure you add documentation for it
 to the appropriate man page for the header that your function resides
 in. Do note that you do not have to document static functions, only
 public API functions.
 .El
 .Pp
 If your patch does not also include proper documentation, it will
 likely be rejected.
--- a/man/man7/telodendria.7
+++ b/man/man7/telodendria.7
@ -0,0 +1,221 @@
 .Dd $Mdocdate: March 10 2023 $
 .Dt TELODENDRIA 7
 .Os Telodendria Project
 .Sh NAME
 .Nm Telodendria
 .Nd Start here. This page contains the project introduction, and provides information about it, such as its status, how to contact the developers, and what the source code license is.
 .Sh DESCRIPTION
 .Nm
 is an open source Matrix homeserver written entirely from scratch in ANSI C and
 designed to be lightweight and simple, yet functional.
 .Pp
 .Nm
 differentiates itself from the other Matrix homeserver
 implementations because it:
 .Bl -bullet
 .It
 Is written in C, a stable, low-level programming language with a
 long history, low build and runtime overhead, and wide compatibility.
 .It
 Is written with minimalism as a primary design goal. Whenever possible
 and practical, no third-party libraries are pulled into the source code.
 Everything
 .Nm
 needs is custom written. As a result,
 .Nm
 depends only on a standard C compiler and a POSIX C library to be built,
 both of which should come with any good Unix-style operating system already,
 which means you shouldn't have to install anything extra.
 .It
 Uses a flat-file directory structure to store data instead of a database.
 This has a number of advantages:
 .Bl -bullet
 .It
 It makes setup and maintenance much easier.
 .It
 It allows
 .Nm
 to run on systems with fewer resources.
 .El
 .It
 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.
 .It
 Is permissively licensed.
 .Nm
 is licensed under a modified MIT license, which imposes very few restrictions
 on what you can do with it.
 .El
 .Pp
 .Nm
 is on Matrix! Check out the official Matrix rooms:
 .Pp
 .TS
 box tab(;);
 ll.
 #telodendria:bancino.net;The public "space" room.
 #telodendria-releases:bancino.net;Get notified of new releases.
 #telodendria-general:bancino.net;General discussion and support.
 #telodendria-newsletter:bancino.net;Periodic status updates.
 #telodendria-issues:bancino.net;Report bugs and issues.
 #telodendria-patches:bancino.net;Submit code patches to the project.
 #telodendria-ports:bancino.net;Discussion about porting and packaging.
 .TE
 .Pp
 .Nm
 is designed to be fairly straightforward, but that doesn't mean there
 won't be hiccups along the way. If you're struggling to get
 .Nm
 up and running, you're more than welcome to reach out for support. Just
 hop into the appropriate Matrix rooms and talk to me!
 .Sh RATIONALE
 I want a lightweight Matrix homeserver designed specifically for OpenBSD,
 and other Unix-like operating systems. I want a homeserver that can be
 developed and compiled with built-in tools. I want it to function entirely
 on a base OS install without having to install any packages whatsoever. I've
 found that as far as these goals are concerned, the existing homeserver
 implementations fall short. This project aims to prove that Matrix homeservers
 can be lightweight and written in such a way that very few, if any, third-party
 libraries need to be pulled in.
 .Pp
 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 and router.
 .Pp
 The advantage of using a flat-file database instead of a real database is that
 your data remains in a format that is incredibly easy to digest. Backups are
 incredibly easy as well\(emjust
 .Xr tar 1
 up the data directory and you're good to go.
 .Sh PROJECT GOALS
 The goals of this project are generally divided into user goals and developer
 goals, depending on who they impact the most. This isn't an exaustive list
 of the project's goals, but it is a list of things that I want to prioritize,
 because other server implementations lack them.
 .Pp
 The user goals are as follows:
 .Bl -bullet
 .It
 To implement the latest Matrix specification as fully and completely as possible.
 All features defined by the specification should eventually be present in
 .Nm .
 .It
 To be as privacy-friendly as possible.
 .Nm
 should not store any information it does not absolutely need to function as a
 Matrix homeserver. While
 .Nm
 strives to be feature-complete, it should not implement anything not explicitly
 defined in the Matrix specification.
 .It
 To be a production-ready Matrix server capable of working in constrained environments,
 such as embedded devices, cheap VPSs, or a peer-to-peer device.
 .Nm
 should also work on traditional setups as well, and be able to handle a decent
 amount of users. It should work well for personal Matrix homeservers that also
 host a few friends and/or family members.
 .It
 To be easier to get up and running, and yet also be more configurable than 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.
 .El
 .Pp
 The developer goals are as follows:
 .Bl -bullet
 .It
 To have as few build and runtime dependencies as possible. It should be possible
 to compile and run
 .Nm
 on any POSIX operating system right out of the box. 
 .Nm
 should be fully statically-linked, so it can run under a
 .Xr chroot 3 .
 Furthermore, it should be possible to read all the documentation offline, and
 without any overly complicated tools. You'll notice that this documentation is
 a collection of
 .Xr man 1
 pages, not HTML or Markdown, to remove the dependency on a browser or Markdown
 parser. Any Unix-like system has a manual page viewer, which makes the
 documentation more accessible, even on remote systems that have no graphical
 interface to read the documentation. This ensures that you can read the
 documentation for the installed version of
 .Nm
 without having to go online.
 .It
 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, but the point is that
 the workflow should require fairly standardized and simple tools.
 .It
 To write clean, elegant, well-tested, 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 because I want to learn how Matrix works,
 make it more accessible, and potentially teach others a little bit along the way.
 .It
 To foster a welcoming community. Many big communities such as Linux and OpenBSD
 have hostile leaders.
 .Nm
 shouldn't have a hostile leader. I want to be as understanding as I can, and talk
 through issues politely and in a civil manner. If I'm failing in this way, don't
 be afraid to call me out!
 .El
 .Sh SEE ALSO
 .Xr telodendria 8 ,
 .Xr telodendria.conf 5 ,
 .Xr td 1
 .Sh STANDARDS
 The installed version of
 .Nm
 conforms to the latest Matrix specification available at the time
 of its release.
 .Sh HISTORY
 .Pp
 .Nm
 was started in early July of 2022. For a change log of this
 project, see
 .Xr telodendria-changelog 7 .
 .Sh AUTHORS
 .Nm
 was started by and is almost exclusively developed by
 Jordan Bancino <@jordan:bancino.net>. Contributions to the code,
 website, documentation, or other components of this project have
 been made by various open source developers.
 .Sh LICENSE
 All of the code and documentation for
 .Nm
 is licensed under a modified MIT license. Please consult the
 .Pa LICENSE.txt
 file for the actual license text. The
 .Nm
 license text differs from the MIT license in the following ways:
 .Bl -bullet
 .It
 Where the MIT license states that the copyright notice and permission
 notice shall be included in all copies or
 .Pa substantial
 portions of the software, the
 .Nm
 license requires the copyright notice and permission notice be included
 with
 .Pa all
 portions, regardless of the size, of the software by omitting the word
 .Pa substantial .
 .El
 .Pp
 The
 .Nm
 logo in all forms, including the ASCII representation, belongs solely
 to the
 .Nm
 project. It must only be used to represent the official
 .Nm
 project, and may only appear in official
 .Nm
 media. If
 .Nm
 is forked, the logo must be removed completely from the project, and
 optionally replaced with a different one. The logo may not be modified
 in any way or for any purpose.
--- a/src/Routes/RouteUserProfile.c
+++ b/src/Routes/RouteUserProfile.c
@ -172,10 +172,7 @@ ROUTE_IMPL(RouteUserProfile, path, argp)
    }
 finish:
    ConfigUnlock(config);
-
+    Free(username);
    /* Username is handled by the router, freeing it *will* cause issues
     * (see #33). I honestly don't know how it didn't come to bite us sooner. 
    Free(username); */
    Free(entry);
    UserIdFree(userId);
    UserUnlock(user);
--- a/tools/bin/send-patch
+++ b/tools/bin/send-patch
@ -0,0 +1,167 @@
 #!/usr/bin/env sh
 #
 # send-patch: "The Telodendria Patch Sender"
 #
 # This is a simple script for posting patch files to
 # a single room(generally the Telodendria patch room.)
 . "$(pwd)/tools/lib/common.sh"
 # Path to the patch to send.
 PATCHFILE="$1"
 # Tries to decompose the name and the HS from an MXID using
 # sed.
 UR_NAME="$(echo "$MXID" | sed "s/\@\(.*\)\:\(.*\)/\1/")"
 HS_NAME="$(echo "$MXID" | sed "s/\@\(.*\)\:\(.*\)/\2/")"
 # Prompts the user for a password, while disabling echo-ing.
 readpwd() {
    printf "$1"
    stty -echo -ctlecho
    read -r "$2"
    echo
    stty echo ctlecho
 }
 # Makes an HTTP request, setting the RETURN variable for the
 # actual reply from the server and the ERROR_CODE variable
 # for a HTTP error code.
 request() {
    RETURN=$(http -i "$@" 2>/dev/null)
    ERROR_CODE=$(echo "$RETURN" | head -n1 | awk '{print $2}')
    RETURN=$(echo "$RETURN" | sed '1,/^[[:space:]]*$/d')
 }
 # Prompts user to login and gives out an access token to use
 # in the ACCESS_TOKEN variable
 matrix_login() {
    # Check authentication methods
    echo "Checking authentication methods..."
    request "$HS_BASE/_matrix/client/v3/login"
    AUTH_METHODS=$RETURN
    if [ $ERROR_CODE -ne 200 ]; then
        echo "Homeserver does not support login."
        exit 1
    fi
    if ! echo "$AUTH_METHODS" | grep "m.login.password" >/dev/null; then
        echo "Homeserver does not support password authentication."
        exit 1
    fi
    # Homeserver does support password authentication, so request
    # them one.
    if [ -z "$MXPW" ]; then
        readpwd "Enter your Matrix password: " MXPW
    fi
    # Tries to login using the "Telodendria Patch Script" device
    # name
    JSON=$(
        printf '{'
        printf '  "identifier": {'
        printf '    "type": "m.id.user",'
        printf '    "user": %s' "$(json -e $UR_NAME)"
        printf '  },'
        printf '  "initial_device_display_name": "Telodendria Patch Script",'
        printf '  "type": "m.login.password",'
        printf '  "password": %s' "$(json -e "$MXPW")"
        printf '}'
    )
    request -X POST -d "$JSON" $HS_BASE/_matrix/client/v3/login
    LOGIN="$RETURN"
    if [ $ERROR_CODE -ne 200 ]; then
        echo "Login failed."
        echo "$RETURN"
        exit 1
    fi
    ACCESS_TOKEN=$(echo "$LOGIN" | json -s "access_token->@decode")
 }
 # Logs out of Matrix using the ACFESS_TOKEN environment variable
 matrix_logout() {
    if [ -z "$ACCESS_TOKEN" ]; then
        echo "No access token"
        exit 1
    fi
    request -X POST -H "Authorization: Bearer $ACCESS_TOKEN" "$HS_BASE/_matrix/client/v3/logout"
    LOGOUT=$RETURN
    if [ $ERROR_CODE -ne 200 ]; then
        echo "Logout failed."
        echo "$RETURN"
        exit 1
    fi
    echo "Logged out."
 }
 send_patch() {
    if [ -z "$ACCESS_TOKEN" ]; then
        matrix_login
        DO_LOGOUT=1
    fi
    # We are sucessfully logged in as our user, now let's
    # try to upload and post our patch
    echo "$PATCHFILE"
    request -X POST \
        -H "Content-Type: text/x-patch" \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        -d "@$PATCHFILE" \
        "$HS_BASE/_matrix/media/v3/upload"
    MXCID=$RETURN
    if [ $ERROR_CODE -ne 200 ]; then
        echo "Upload failed."
        echo "$RETURN"
        matrix_logout
        exit 1
    fi
    MXCID=$(echo "$MXCID" | json -s "content_uri->@decode")
    echo "MXC ID: $MXCID"
    JSON=$(
        base=$(basename "$PATCHFILE")
        printf '{'
        printf '  "body": %s,' "$(json -e $base)"
        printf '  "filename": %s,' "$(json -e $base)"
        printf '  "info": {'
        printf '    "mimetype": "text/x-patch",'
        printf '    "size": %d' $(wc -c "$PATCHFILE" | awk '{print $1}')
        printf '  },'
        printf '  "msgtype": "m.file",'
        printf '  "url": %s' "$(json -e $MXCID)"
        printf '}'
    )
    http -X PUT -d "$JSON" -H "Authorization: Bearer $ACCESS_TOKEN" \
        "$HS_BASE/_matrix/client/v3/rooms/$PATCHES_ROOM/send/m.room.message/$(date +%s)" \
        2>/dev/null >/dev/null && echo "Patch sent."
    # Log out if we generated an access token
    if [ "$DO_LOGOUT" -eq "1" ]; then
        matrix_logout
    fi
 }
 # Check if the patch file is valid.
 if [ "$(basename "$PATCHFILE" .patch)" = "$PATCHFILE" ] || [ ! -f "$PATCHFILE" ]; then
    echo "Format: $0 file.patch"
    exit 1
 fi
 echo "Sending file '$PATCHFILE'"
 echo "Checking homeserver's real address using .well-known..."
 request "https://$HS_NAME/.well-known/matrix/client"
 case "$ERROR_CODE" in
    "200")
        WELL_KNOWN=$RETURN
        if [ -z "$WELL_KNOWN" ]; then
            echo "well-known test returned 200 but no correct input was given."
            exit 1
        fi
        # well-known entry is correct, we can now store our base endpoint
        HS_BASE=$(printf "$WELL_KNOWN" | json -s "m.homeserver->base_url->@decode") && send_patch
        ;;
    *)
        echo "$ERROR_CODE"
        echo "well-known test failed."
        printf "Please enter your homeserver base URL: "
        read -r HS_BASE
        echo
        send_patch
        ;;
 esac
--- a/tools/bin/tp
+++ b/tools/bin/tp
@ -0,0 +1,148 @@
 #!/usr/bin/env sh
 #
 # tp: "Telodendria Patch"
 #
 # This script is used to manage the patch queue.
 . "$(pwd)/tools/lib/common.sh"
 if [ -z "$TELODENDRIA_PUB" ]; then
    echo "TELODENDRIA_PUB not set."
    exit 1
 fi
 TP_DIR="$TELODENDRIA_PUB/patches"
 if [ ! -d "$TP_DIR" ]; then
    echo "$TP_DIR does not exist."
    exit 1
 fi
 matrix_send() {
    msg="$1"
    if [ ! -z "$msg" ]; then
        (
            printf '{'
            printf '"body":'
            json -e "$msg"
            printf ',"formatted_body":'
            json -e "$msg"
            printf ',"format":"org.matrix.custom.html",'
            printf '"msgtype":"m.text"'
            printf '}'
        ) > /tmp/tp-$$
        http -X PUT -d @/tmp/tp-$$ "$HOMESERVER/client/v3/rooms/$PATCHES_ROOM/send/m.room.message/$(date +%s)?access_token=$ACCESS_TOKEN"
        rm /tmp/tp-$$
    fi
 }
 case "$1" in
    "ingress")
        timeline="/tmp/timeline.json"
        http "$HOMESERVER/client/v3/sync?access_token=$ACCESS_TOKEN" |
            json -s "rooms->join->${PATCHES_ROOM}->timeline" >"$timeline"
        length=$(cat "$timeline" | json -s "events->@length")
        i=0
        while [ $i -lt $length ]; do
            content=$(cat "$timeline" | json -s "events[$i]->content->^body->^formatted_body")
            i=$((i + 1))
            type=$(echo "$content" | json -s "msgtype->@decode")
            if [ "$type" != "m.file" ]; then
                continue
            fi
            size=$(echo "$content" | json -s "info->size")
            if [ "$size" -gt "$MAX_SIZE" ]; then
                continue
            fi
            file=$(echo "$content" | json -s "filename->@decode")
            ext=$(echo "$file" | rev | cut -d '.' -f 1 | rev)
            if [ "$ext" != "patch" ]; then
                continue
            fi
            url=$(echo "$content" | json -s "url->@decode")
            id=$(echo "$url" | cut -d '/' -f 4)
            if [ -f "$TP_DIR/ingress/$id.patch" ]; then
                continue
            fi
            server=$(echo "$url" | cut -d '/' -f 3)
            if ! http "$HOMESERVER/media/v3/download/$server/$id" > "$TP_DIR/ingress/$id.patch"; then
                rm "$TP_DIR/ingress/$id.patch"
                echo "Failed to fetch mxc://$server/$id."
                echo "Will try again next time."
                continue
            fi
            count=$(cat "$TP_DIR/count.txt")
            count=$((count + 1))
            cp "$TP_DIR/ingress/$id.patch" "$TP_DIR/p/$count.patch"
            (
                cd "$TP_DIR/queued"
                ln -s "../p/$count.patch" "$count.patch"
            )
            echo "$count" >"$TP_DIR/count.txt"
            matrix_send "Queued <code>$file</code> as <a href=\"https://telodendria.io/patches/p/$count.patch\">#$count</a>" >/dev/null
        done
        ;;
    "queue")
        find "$TP_DIR/queued" -name '*.patch' | while IFS= read -r patch; do
            n=$(basename "$patch" .patch)
            echo "Patch #$n:"
            head -n3 "$patch"
            echo
        done
        ;;
    "view")
        if [ -f "$TP_DIR/queued/$2.patch" ]; then
            less "$TP_DIR/queued/$2.patch"
        else
            echo "Patch #$2 doesn't exist in the queue."
            exit 1
        fi
        ;;
    "apply")
        if [ -f "$TP_DIR/queued/$2.patch" ]; then
            patch <"$TP_DIR/queued/$2.patch"
        else
            echo "Patch #$2 doesn't exist in the queue."
            exit 1
        fi
        ;;
    "reverse")
        if [ -f "$TP_DIR/queued/$2.patch" ]; then
            patch -R <"$TP_DIR/queued/$2.patch"
        else
            echo "Patch #$2 doesn't exist in the queue."
            exit 1
        fi
        ;;
    "accept" | "reject")
        if [ -f "$TP_DIR/queued/$2.patch" ]; then
            mv "$TP_DIR/queued/$2.patch" "$TP_DIR/${1}ed/$2.patch"
            msg="Patch <a href=\"https://telodendria.io/patches/p/$2.patch\">#$2</a> was marked as ${1}ed."
            msgFile="/tmp/patchmsg-$(date +%s).txt"
            $EDITOR "$msgFile"
            if [ -f "$msgFile" ]; then
                msg="$msg<br><blockquote>$(cat $msgFile)<br>&mdash;$DISPLAY_NAME ($MXID)</blockquote>"
            fi
            matrix_send "$msg"
        else
            echo "Patch #$2 doesn't exist in the queue."
            exit 1
        fi
        ;;
    *)
        echo "No action specified."
        exit 1
        ;;
 esac