forked from Telodendria/Telodendria
Compare commits
No commits in common. "f4cb10804a4baba8d6c59390a7ece66a1f8ea43c" and "5ad199353b909800a245eb61bbbfd88bad7f59f6" have entirely different histories.
f4cb10804a
...
5ad199353b
27 changed files with 1574 additions and 838 deletions
|
@ -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.
|
|
@ -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.
|
|
@ -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
|
|
@ -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—including all
|
||||
personal information I submit with it—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.
|
||||
|
|
@ -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));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
@ -147,6 +147,7 @@ StrSubstr(const char *inStr, size_t start, size_t end)
|
|||
}
|
||||
|
||||
len = end - start;
|
||||
|
||||
outStr = Malloc(len + 1);
|
||||
if (!outStr)
|
||||
{
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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) →
|
||||
[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—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 & 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.
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.|
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.|
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.|
|
|
@ -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 → 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—or path relative to the data
|
||||
directory—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.
|
||||
|
|
@ -48,13 +48,4 @@ binaries.
|
|||
|
||||
## From Source
|
||||
|
||||
If you would like to build Telodendria from source, you can download
|
||||
the latest release code from the
|
||||
[Releases](/Telodendria/telodendria/releases) page. After extracting
|
||||
the tarball, read
|
||||
[Contributing → Developing → Building & 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.
|
||||
**TODO:** Update this section before #19 is closed.
|
||||
|
|
|
@ -26,7 +26,7 @@ source, execute the binary directly. If needed, consult the
|
|||
initialize its database directly with a simple—and, importantly,
|
||||
safe—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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
57
man/man1/send-patch.1
Normal file
57
man/man1/send-patch.1
Normal file
|
@ -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
|
||||
|
63
man/man1/tp.1
Normal file
63
man/man1/tp.1
Normal file
|
@ -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
|
421
man/man7/telodendria-admin.7
Normal file
421
man/man7/telodendria-admin.7
Normal file
|
@ -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
|
218
man/man7/telodendria-config.7
Normal file
218
man/man7/telodendria-config.7
Normal file
|
@ -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
|
268
man/man7/telodendria-contributing.7
Normal file
268
man/man7/telodendria-contributing.7
Normal file
|
@ -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.
|
221
man/man7/telodendria.7
Normal file
221
man/man7/telodendria.7
Normal file
|
@ -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.
|
|
@ -172,10 +172,7 @@ ROUTE_IMPL(RouteUserProfile, path, argp)
|
|||
}
|
||||
finish:
|
||||
ConfigUnlock(config);
|
||||
|
||||
/* 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(username);
|
||||
Free(entry);
|
||||
UserIdFree(userId);
|
||||
UserUnlock(user);
|
||||
|
|
167
tools/bin/send-patch
Executable file
167
tools/bin/send-patch
Executable file
|
@ -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
|
148
tools/bin/tp
Executable file
148
tools/bin/tp
Executable file
|
@ -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>—$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
|
Loading…
Reference in a new issue