Merge branch 'main' into golangci-lint-upgrade

docs/advanced/builds/nowasm.md

@@ -0,0 +1,27 @@
+# Build without Wazero / WASM
+
+!!! Danger "This is unsupported"
+    We do not offer any kind of support for deployments of GoToSocial built with the `nowasm` tag described in this section. Such builds should be considered strictly experimental, and any issues that come when running them are none of our business! Please don't open issues on the repo looking for help debugging deployments of `nowasm` builds.
+
+On [supported platforms](../../getting_started/releases.md#supported-platforms), GoToSocial uses the WebAssembly runtime [Wazero](https://wazero.io/) to sandbox `ffmpeg`, `ffprobe`, and `sqlite3` WebAssembly binaries, allowing these applications to be packaged and run inside the GoToSocial binary, without requiring admins to install + manage any external dependencies.
+
+This has the advantage of making it easier for admins to maintain their GoToSocial instance, as their GtS binary is completely isolated from any changes to their system-installed `ffmpeg`, `ffprobe`, and `sqlite`. It's also a bit safer to run `ffmpeg` in this way, as GoToSocial wraps the `ffmpeg` binary in a very constrained file system that doesn't permit the `ffmpeg` binary to access any files other than the ones it's decoding + reencoding. In other words, GoToSocial on supported platforms offers most of the functionality of `ffmpeg` and so on, without some of the headaches.
+
+However, not all platforms are capable of running Wazero in the much-faster "compiler" mode, and have to fall back to the very slow (and resource-heavy) "interpreter" mode. See [this table](https://github.com/tetratelabs/wazero?tab=readme-ov-file#conformance) from Wazero for conformance.
+
+"Interpreter" mode runs so poorly for GoToSocial's use case that it's simply not feasible to run a GoToSocial instance in a stable manner on platforms that aren't 64-bit Linux or 64-bit FreeBSD, as all the memory and CPU get gobbled up by media processing.
+
+However! To enable folks to run **experimental, unsupported deployments of GoToSocial**, we expose the `nowasm` build tag, which can be used to compile a build of GoToSocial that does not use Wazero or WASM at all.
+
+A GoToSocial binary built with `nowasm` will use the [modernc version of SQLite](https://pkg.go.dev/modernc.org/sqlite) instead of the WASM one, and will use on-system `ffmpeg` and `ffprobe` binaries for media processing.
+
+To build GoToSocial with the `nowasm` tag, you can pass the tag into our convenience `build.sh` script like so:
+
+```bash
+GO_BUILDTAGS=nowasm ./scripts/build.sh
+```
+
+In order to run a version of GoToSocial built in this way, you must ensure that `ffmpeg` and `ffprobe` are installed on the host. This is usually as simple as running a command like `doas -u root pkg_add ffmpeg` (OpenBSD), or `sudo apt install ffmpeg` (Debian etc.). 
+
+!!! Danger "No really though, it's unsupported"
+    Again, if running builds of GoToSocial with `nowasm` works for your OS/Arch combination, that's great, but we do not support such builds and we won't be able to help debugging why something doesn't work.

docs/advanced/index.md

@@ -1,6 +1,6 @@
 # Advanced
 
-In this section we touch on a number of more advanced topics, primarily related around deploying, operating and tuning GoToSocial.
+In this section we touch on a number of more advanced topics, primarily related around building, deploying, operating and tuning GoToSocial.
 
 We consider these topics advanced because applying them incorrectly does have the possibility of causing client and federation issues. Applying any of these configuration changes may also make it harder for you to debug an issue with your GoToSocial instance if you don't understand the changes that you're making.
 

docs/configuration/index.md

@@ -126,3 +126,19 @@ This means in cases where you want to just try changing one thing, but don't wan
 Reasonable default values are provided for *most* of the configuration parameters, except in cases where a custom value is absolutely required.
 
 See the [example config file](https://github.com/superseriousbusiness/gotosocial/blob/main/example/config.yaml) for the default values, or run `gotosocial --help`.
+
+## `GTS_WAZERO_COMPILATION_CACHE`
+
+On startup, GoToSocial compiles embedded WebAssembly `ffmpeg` and `ffprobe` binaries into [Wazero](https://wazero.io/)-compatible modules, which are used for media processing without requiring any external dependencies.
+
+To speed up startup time of GoToSocial, you can cache the compiled modules between restarts so that GoToSocial doesn't have to compile them on every startup from scratch.
+
+You can instruct GoToSocial on where to store the Wazero artifacts by setting the environment variable `GTS_WAZERO_COMPILATION_CACHE` to a directory, which will be used by GtS to store two smallish artifacts of ~50MiB or so each (~100MiB total).
+
+For an example of this in action, see the [docker-compose.yaml](https://raw.githubusercontent.com/superseriousbusiness/gotosocial/main/example/docker-compose/docker-compose.yaml), and the [gotosocial.service](https://raw.githubusercontent.com/superseriousbusiness/gotosocial/main/example/gotosocial.service) example files.
+
+If you want to provide this value to GtS outside of systemd or Docker, you can do so in the following manner when starting up your GtS server:
+
+```bash
+GTS_WAZERO_COMPILATION_CACHE=~/gotosocial/.cache ./gotosocial --config-path ./config.yaml server start
+```

docs/federation/http_signatures.md

@@ -6,7 +6,7 @@ GoToSocial will also sign all outgoing `GET` and `POST` requests that it makes t
 
 This behavior is the equivalent of Mastodon's [AUTHORIZED_FETCH / "secure mode"](https://docs.joinmastodon.org/admin/config/#authorized_fetch).
 
-GoToSocial uses the [superseriousbusiness/httpsig](https://github.com/superseriousbusiness/httpsign) library (forked from go-fed) for signing outgoing requests, and for parsing and validating the signatures of incoming requests. This library strictly follows the [Cavage http signature RFC](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12), which is the same RFC used by other implementations like Mastodon, Pixelfed, Akkoma/Pleroma, etc. (This RFC has since been superceded by the [httpbis http signature RFC](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures), but this is not yet widely implemented.)
+GoToSocial uses the [superseriousbusiness/httpsig](https://github.com/superseriousbusiness/httpsig) library (forked from go-fed) for signing outgoing requests, and for parsing and validating the signatures of incoming requests. This library strictly follows the [Cavage http signature RFC](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12), which is the same RFC used by other implementations like Mastodon, Pixelfed, Akkoma/Pleroma, etc. (This RFC has since been superceded by the [httpbis http signature RFC](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures), but this is not yet widely implemented.)
 
 ## Query Parameters
 

docs/getting_started/installation/container.md

@@ -91,6 +91,32 @@ If you want to use [LetsEncrypt](../../configuration/tls.md) for TLS certificate
     
     For help translating variable names from the config.yaml file to environment variables, refer to the [configuration section](../../configuration/index.md#environment-variables).
 
+### Wazero Compilation Cache (optional)
+
+On startup, GoToSocial compiles embedded WebAssembly `ffmpeg` and `ffprobe` binaries into [Wazero](https://wazero.io/)-compatible modules, which are used for media processing without requiring any external dependencies.
+
+To speed up startup time of GoToSocial, you can cache the compiled modules between restarts so that GoToSocial doesn't have to compile them on every startup from scratch.
+
+If you'd like to do this in your Docker container, first create a `.cache` directory in your working folder to store the modules:
+
+```bash
+mkdir -p ~/gotosocial/.cache
+```
+
+Then, uncomment the second volume in the docker-compose.yaml file by removing the leading `#` symbol, so that instead of
+
+```yaml
+#- ~/gotosocial/.cache:/gotosocial/.cache
+```
+
+it reads
+
+```yaml
+- ~/gotosocial/.cache:/gotosocial/.cache
+```
+
+This will instruct Docker to mount the `~/gotosocial/.cache` directory at `/gotosocial/.cache` inside the Docker container.
+
 ## Start GoToSocial
 
 With those small changes out of the way, you can now start GoToSocial with the following command:

docs/getting_started/releases.md

@@ -1,47 +1,11 @@
 # Releases
 
-GoToSocial can be installed in a number of different ways. We publish official binary releases as well as container images. A number of third-party packages are maintained by different distributions and some people have created additional deployment tooling to make it easy to deploy GoToSocial yourself.
+GoToSocial can be installed in a number of different ways. We publish official binary releases as well as container images.
 
-## Binary releases
+A number of third-party packages are maintained by different distributions, and some people have created additional deployment tooling to make it easy to deploy GoToSocial yourself.
 
-We publish binary builds for Linux to [our GitHub project](https://github.com/superseriousbusiness/gotosocial/releases):
-
-* 32-bit Intel/AMD (i386/x86)
-* 64-bit Intel/AMD (amd64/x86_64)
-* 32-bit ARM (v6 and v7)
-* 64-bit ARM64
-
-For FreeBSD we publish:
-
-* 64-bit Intel/AMD (amd64/x86_64)
-
-## Containers
-
-We also publish container images [on the Docker Hub](https://hub.docker.com/r/superseriousbusiness/gotosocial).
-
-Containers are released for the same Linux platforms as our binary releases, with the exception of 32-bit Intel/AMD.
-
-## Snapshots
-
-We publish snapshot binary builds and Docker images of whatever is currently on main.
-
-We always recommend using a stable release instead, but if you want to live on the edge (at your own risk!) then see the [snapshots](https://github.com/superseriousbusiness/gotosocial#snapshots) section on our GitHub repo for more information.
-
-## Third-party
-
-Some folks have created distribution packages for GoToSocial or additional tooling to aid in installing GoToSocial.
-
-### Distribution packages
-
-These packages are not maintained by GoToSocial, so please direct questions and issues to the repository maintainers (and donate to them!).
-
-[![Packaging status](https://repology.org/badge/vertical-allrepos/gotosocial.svg)](https://repology.org/project/gotosocial/versions)
-
-### Deployment tools
-
-You can deploy your own instance of GoToSocial with the help of:
-
-- [YunoHost GoToSocial Packaging](https://github.com/YunoHost-Apps/gotosocial_ynh) by [OniriCorpe](https://github.com/OniriCorpe).
-- [Ansible Playbook (MASH)](https://github.com/mother-of-all-self-hosting/mash-playbook): The playbook supports a many services, including GoToSocial. [Documentation](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/services/gotosocial.md)
-- GoToSocial Helm Charts:
-  - [GoToSocial Helm Chart](https://github.com/fSocietySocial/charts/tree/main/charts/gotosocial) by [0hlov3](https://github.com/0hlov3).
+{%
+  include "../../README.md"
+  start='<!--releases-start-->'
+  end='<!--releases-end-->'
+%}