refactor: 🚚 Begin rebranding to Versia Server

docs/api/emojis.md

@@ -1,6 +1,6 @@
 # Emoji API
 
-An Emoji API is made available to users to manage custom emoji on the instance. We recommend using Lysand's CLI to manage emoji, but this API is available for those who prefer to use it (both admin and non-admin users).
+An Emoji API is made available to users to manage custom emoji on the instance. We recommend using Versia Server's CLI to manage emoji, but this API is available for those who prefer to use it (both admin and non-admin users).
 
 ## Create Emoji
 

docs/api/federation.md

@@ -1,6 +1,6 @@
 # Federation API
 
-The Federation API contains a variety of endpoints for interacting with the Lysand remote network.
+The Federation API contains a variety of endpoints for interacting with the Versia Server remote network.
 
 ## Refetch User
 

docs/api/frontend.md

@@ -1,10 +1,10 @@
 # Frontend API
 
-The frontend API contains endpoints that are useful for frontend developers. These endpoints are not part of the Mastodon API, but are specific to Lysand.
+The frontend API contains endpoints that are useful for frontend developers. These endpoints are not part of the Mastodon API, but are specific to Versia Server.
 
 ## Routes that the Frontend must implement
 
-These routes can be set to a different URL in the Lysand configuration, at `frontend.routes`. The frontend must implement these routes for the instance to function correctly.
+These routes can be set to a different URL in the Versia Server configuration, at `frontend.routes`. The frontend must implement these routes for the instance to function correctly.
 
 - `GET /oauth/authorize`: (NOT `POST`): Identifier/password login form, submits to [`POST /api/auth/login`](#sign-in) or OpenID Connect flow.
 - `GET /oauth/consent`: Consent form, submits to [`POST /api/auth/redirect`](#consent)
@@ -15,7 +15,7 @@ These routes can be set to a different URL in the Lysand configuration, at `fron
 GET /api/v1/frontend/config
 ```
 
-Retrieves the frontend configuration for the instance. This returns whatever the `frontend.settings` object is set to in the Lysand configuration.
+Retrieves the frontend configuration for the instance. This returns whatever the `frontend.settings` object is set to in the Versia Server configuration.
 
 This behaves like the `/api/v1/preferences` endpoint in the Mastodon API, but is specific to the frontend. These values are arbitrary and can be used for anything.
 
@@ -23,8 +23,8 @@ For example, the frontend configuration could contain the following:
 
 ```json
 {
-    "org.lysand.fe:theme": "dark",
-    "org.lysand.fe:custom_css": "body { background-color: black; }",
+    "pub.versia.fe:theme": "dark",
+    "pub.versia.fe:custom_css": "body { background-color: black; }",
     // Googly is an imaginary frontend that uses the `net.googly.frontend` namespace
     "net.googly.frontend:spoiler_image": "https://example.com/spoiler.png"
 }

docs/api/index.md

@@ -1,6 +1,6 @@
-# Lysand API Documentation
+# Versia Server API Documentation
 
-The Lysand API strictly follows the latest available Mastodon API version (Glitch-Soc version). This means that the Lysand API is a superset of the Mastodon API, with additional endpoints and features.
+The Versia Server API strictly follows the latest available Mastodon API version (Glitch-Soc version). This means that the Versia Server API is a superset of the Mastodon API, with additional endpoints and features.
 
 Some more information about the Mastodon API can be found in the [Mastodon API documentation](https://docs.joinmastodon.org/api/).
 

docs/api/mastodon.md

@@ -10,7 +10,7 @@ Three extra attributes have been added to the `/api/v1/instance` endpoint:
 {
     // ...
     banner: string | null;
-    lysand_version: string;
+    versia_version: string;
     sso: {
         forced: boolean;
         providers: {
@@ -26,9 +26,9 @@ Three extra attributes have been added to the `/api/v1/instance` endpoint:
 
 The URL of the instance's banner image. `null` if there is no banner set.
 
-### `lysand_version`
+### `versia_version`
 
-The version of the Lysand instance.
+The version of the Versia Server instance.
 
 The normal `version` field is always set to `"4.3.0+glitch"` or similar, to not confuse clients that expect a Mastodon instance.
 
@@ -55,18 +55,18 @@ Two extra attributes has been adding to all returned account objects:
 ```ts
 {
     // ...
-    roles: LysandRoles[];
+    roles: VersiaRoles[];
     uri: string;
 }
 ```
 
 ### `roles`
 
-An array of roles from [Lysand Roles](./roles.md).
+An array of roles from [Versia Server Roles](./roles.md).
 
 ### `uri`
 
-The URI of the account's Lysand object (for federation). Similar to Mastodon's `uri` field on notes.
+The URI of the account's Versia object (for federation). Similar to Mastodon's `uri` field on notes.
 
 ## `/api/v1/accounts/update_credentials`
 

docs/api/moderation.md

@@ -3,11 +3,11 @@
 > [!WARNING]
 > **NOT IMPLEMENTED**
 
-The Lysand project uses the Mastodon API to interact with clients. However, the moderation API is custom-made for Lysand Server, as it allows for more fine-grained control over the server's behavior.
+The Versia Server project uses the Mastodon API to interact with clients. However, the moderation API is custom-made for Versia Server Server, as it allows for more fine-grained control over the server's behavior.
 
 ## Flags, ModTags and ModNotes
 
-Flags are used by Lysand Server to automatically attribute tags to a status or account based on rules. ModTags and ModNotes are used by moderators to manually tag and take notes on statuses and accounts.
+Flags are used by Versia Server Server to automatically attribute tags to a status or account based on rules. ModTags and ModNotes are used by moderators to manually tag and take notes on statuses and accounts.
 
 The difference between flags and modtags is that flags are automatically attributed by the server, while modtags are manually attributed by moderators.
 
@@ -22,7 +22,7 @@ The difference between flags and modtags is that flags are automatically attribu
 
 ### ModTag Types
 
-ModTag do not have set types and can be anything. Lysand Server autosuggest previously used tags when a moderator is adding a new tag to avoid duplicates.
+ModTag do not have set types and can be anything. Versia Server Server autosuggest previously used tags when a moderator is adding a new tag to avoid duplicates.
 
 ### Data Format
 

docs/cli.md

@@ -1,10 +1,10 @@
-# Lysand CLI
+# Versia Server CLI
 
-Lysand includes a built-in, scripting-compatible CLI that can be used to manage the server. This CLI can be used to create and delete users, manage the database and more. It can also output data in JSON or CSV format, making it easy to use in scripts.
+Versia Server includes a built-in, scripting-compatible CLI that can be used to manage the server. This CLI can be used to create and delete users, manage the database and more. It can also output data in JSON or CSV format, making it easy to use in scripts.
 
 ## Using the CLI
 
-Lysand includes a built-in CLI for managing the server. To use it, simply run the following command:
+Versia Server includes a built-in CLI for managing the server. To use it, simply run the following command:
 
 ```bash
 # Development
@@ -12,7 +12,7 @@ bun cli help
 # Source installs
 bun run dist/cli.js help
 # Docker
-docker compose exec -it lysand /bin/sh /app/entrypoint.sh cli help
+docker compose exec -it versia /bin/sh /app/entrypoint.sh cli help
 ```
 
 You can use the `help` command to see a list of available commands. These include creating users, deleting users and more. Each command also has a `--help,-h` flag that you can use to see more information about the command.

docs/database.md

@@ -1,7 +1,7 @@
 # Installing the database
 
-Lysand uses a special PostgreSQL extension called `pg_uuidv7` to generate UUIDs. This extension is required for Lysand to work properly. To install it, you can either use the pre-made Docker image or install it manually.
+Versia Server uses a special PostgreSQL extension called `pg_uuidv7` to generate UUIDs. This extension is required for Versia Server to work properly. To install it, you can either use the pre-made Docker image or install it manually.
 
 ## Using the Docker image
 
-Lysand offers a pre-made Docker image for PostgreSQL with the extension already installed. Use `ghcr.io/lysand-org/postgres:main` as your Docker image name to use it.
+Versia Server offers a pre-made Docker image for PostgreSQL with the extension already installed. Use `ghcr.io/lysand-org/postgres:main` as your Docker image name to use it.

docs/glitch-soc.md

@@ -1,8 +1,8 @@
 # Enabling Glitch-Soc
 
-Lysand supports the use of the Glitch-Soc fork of Mastodon's frontend. Here's how to do it:
+Versia Server supports the use of the Glitch-Soc fork of Mastodon's frontend. Here's how to do it:
 
-1. Download the latest Glitch FE package from [the releases page](https://github.com/lysand-org/lysand/releases) (it should be named `glitch.tar.gz` and be inside the assets of a normal Lysand release).
+1. Download the latest Glitch FE package from [the releases page](https://github.com/lysand-org/lysand/releases) (it should be named `glitch.tar.gz` and be inside the assets of a normal Versia Server release).
 2. Extract the contents of the package into a folder, which you can name `glitch` for simplicity. (if using Docker, now is the time to mount that folder into the container, for example with `-v /path/to/glitch:/app/dist/glitch`)
 3. Change the config to enable Glitch-FE:
     ```toml
@@ -22,7 +22,7 @@ Lysand supports the use of the Glitch-Soc fork of Mastodon's frontend. Here's ho
     server = ["https://tech.lgbt"]
     ```
     The `server` option can be left as-is, unless you have downloaded your own `index.html` file from a different Glitch instance.
-4. Start Lysand and navigate to `/` to see the Glitch frontend in action.
+4. Start Versia Server and navigate to `/` to see the Glitch frontend in action.
 
 ## How is this package created?
 
@@ -32,6 +32,6 @@ The package static files were taken from a build of Glitch-Soc, while the index.
 
 Then, the paths in the `index.html` file were replaced with the correct paths for the static files (as they have different hashes in their names from the ones in the Glitch-Soc build).
 
-At runtime, Lysand dynamically edits the index.html file to replace the content with correct data, as well as disabling `integrity` checks on the script/link tags.
+At runtime, Versia Server dynamically edits the index.html file to replace the content with correct data, as well as disabling `integrity` checks on the script/link tags.
 
 In the future, I'll find a way to make this less hacky and more user-friendly, but for now, this is the best I can do.

docs/installation.md

@@ -3,19 +3,19 @@
 ## Requirements
 
 - The [Bun Runtime](https://bun.sh), version 1.1.24 or later (usage of the latest version is recommended)
-  - Lysand will work on lower versions than 1.1.24, but only the latest version is supported
+  - Versia Server will work on lower versions than 1.1.24, but only the latest version is supported
 - A PostgreSQL database
 - (Optional but recommended) A Linux-based operating system
 - (Optional if you want search) A working [Sonic](https://github.com/valeriansaliou/sonic) instance
 
 > [!WARNING]
-> Lysand has not been tested on Windows or macOS. It is recommended to use a Linux-based operating system to run Lysand.
+> Versia Server has not been tested on Windows or macOS. It is recommended to use a Linux-based operating system to run LysVersia Serverand.
 > 
-> We will not be offering support to Windows or macOS users. If you are using one of these operating systems, please use a virtual machine or container to run Lysand.
+> We will not be offering support to Windows or macOS users. If you are using one of these operating systems, please use a virtual machine or container to run Versia Server.
 
 ## With Docker/Podman
 
-Docker is the recommended way to run Lysand (Podman also works). To run Lysand with Docker, follow these steps:
+Docker is the recommended way to run Versia Server (Podman also works). To run Versia Server with Docker, follow these steps:
 
 1. Download the `docker-compose.yml` file from the repository