11 files changed, 169 insertions, 153 deletions

diff --git a/docs/API/admin_api.md b/docs/API/admin_api.md
index 07aa7ec3f..47acd240e 100644
--- a/docs/API/admin_api.md
+++ b/docs/API/admin_api.md
@@ -665,11 +665,9 @@ Note: Available `:permission_group` is currently moderator and admin. 404 is ret
     - 404 Not Found `"Not found"`
   - On success: 200 OK `{}`
 
-## `GET /api/pleroma/admin/config/migrate_from_db`
+## `GET /api/pleroma/admin/restart`
 
-### Run mix task pleroma.config migrate_from_db
-
-Copies all settings from database to `config/{env}.exported_from_db.secret.exs` with deletion from the table. Where `{env}` is the environment in which `pleroma` is running.
+### Restarts pleroma application
 
 - Params: none
 - Response:
@@ -684,6 +682,8 @@ Copies all settings from database to `config/{env}.exported_from_db.secret.exs`
 
 ### Get list of merged default settings with saved in database.
 
+*If `need_reboot` flag exists in response, instance must be restarted, so reboot time settings can take effect.*
+
 **Only works when configuration from database is enabled.**
 
 - Params:
@@ -691,24 +691,27 @@ Copies all settings from database to `config/{env}.exported_from_db.secret.exs`
 - Response:
   - On failure:
     - 400 Bad Request `"To use this endpoint you need to enable configuration from database."`
-    - 400 Bad Request `"To use configuration from database migrate your settings to database."`
 
 ```json
 {
-  configs: [
+  "configs": [
     {
       "group": ":pleroma",
       "key": "Pleroma.Upload",
       "value": []
      }
-  ]
+  ],
+  "need_reboot": true
 }
 ```
+ need_reboot - *optional*, if were changed reboot time settings.
 
 ## `POST /api/pleroma/admin/config`
 
 ### Update config settings
 
+*If `need_reboot` flag exists in response, instance must be restarted, so reboot time settings can take effect.*
+
 **Only works when configuration from database is enabled.**
 
 Some modifications are necessary to save the config settings correctly:
@@ -796,7 +799,7 @@ config :quack,
 ```
 ```json
 {
-  configs: [
+  "configs": [
     {"group": ":quack", "key": ":level", "value": ":debug"},
     {"group": ":quack", "key": ":meta", "value": [":all"]},
     ...
@@ -807,7 +810,7 @@ config :quack,
 
 ```json
 {
-  configs: [
+  "configs": [
     {
       "group": ":pleroma",
       "key": "Pleroma.Upload",
@@ -839,15 +842,17 @@ config :quack,
     - 400 Bad Request `"To use this endpoint you need to enable configuration from database."`
 ```json
 {
-  configs: [
+  "configs": [
     {
       "group": ":pleroma",
       "key": "Pleroma.Upload",
       "value": [...]
      }
-  ]
+  ],
+  "need_reboot": true
 }
 ```
+need_reboot - *optional*, if were changed reboot time settings.
 
 ## ` GET /api/pleroma/admin/config/descriptions`
 
diff --git a/docs/API/differences_in_mastoapi_responses.md b/docs/API/differences_in_mastoapi_responses.md
index 030660b34..06de90f71 100644
--- a/docs/API/differences_in_mastoapi_responses.md
+++ b/docs/API/differences_in_mastoapi_responses.md
@@ -29,7 +29,7 @@ Has these additional fields under the `pleroma` object:
 - `spoiler_text`: a map consisting of alternate representations of the `spoiler_text` property with the key being it's mimetype. Currently the only alternate representation supported is `text/plain`
 - `expires_at`: a datetime (iso8601) that states when the post will expire (be deleted automatically), or empty if the post won't expire
 - `thread_muted`: true if the thread the post belongs to is muted
-- `emoji_reactions`: A list with emoji / reaction maps. The format is {emoji: "☕", count: 1}. Contains no information about the reacting users, for that use the `emoji_reactions_by` endpoint.
+- `emoji_reactions`: A list with emoji / reaction maps. The format is `{name: "☕", count: 1, me: true}`. Contains no information about the reacting users, for that use the `/statuses/:id/reactions` endpoint.
 
 ## Attachments
 
@@ -88,6 +88,9 @@ Behavior has changed:
 
 - `/api/v1/accounts/search`: Does not require authentication
 
+## Search (global)
+
+Unlisted posts are available in search results, they are considered to be public posts that shouldn't be shown in local/federated timeline.
 
 ## Notifications
 
@@ -101,7 +104,7 @@ The `type` value is `move`. Has an additional field:
 
 - `target`: new account
 
-### EmojiReaction Notification
+### EmojiReact Notification
 
 The `type` value is `pleroma:emoji_reaction`. Has these fields:
 
diff --git a/docs/API/pleroma_api.md b/docs/API/pleroma_api.md
index 9f5cafe5a..07e0af5e5 100644
--- a/docs/API/pleroma_api.md
+++ b/docs/API/pleroma_api.md
@@ -432,21 +432,21 @@ The status posting endpoint takes an additional parameter, `in_reply_to_conversa
 
 Emoji reactions work a lot like favourites do. They make it possible to react to a post with a single emoji character.
 
-## `POST /api/v1/pleroma/statuses/:id/react_with_emoji`
+## `PUT /api/v1/pleroma/statuses/:id/reactions/:emoji`
 ### React to a post with a unicode emoji
-* Method: `POST`
+* Method: `PUT`
 * Authentication: required
 * Params: `emoji`: A single character unicode emoji
 * Response: JSON, the status.
 
-## `POST /api/v1/pleroma/statuses/:id/unreact_with_emoji`
+## `DELETE /api/v1/pleroma/statuses/:id/reactions/:emoji`
 ### Remove a reaction to a post with a unicode emoji
-* Method: `POST`
+* Method: `DELETE`
 * Authentication: required
 * Params: `emoji`: A single character unicode emoji
 * Response: JSON, the status.
 
-## `GET /api/v1/pleroma/statuses/:id/emoji_reactions_by`
+## `GET /api/v1/pleroma/statuses/:id/reactions`
 ### Get an object of emoji to account mappings with accounts that reacted to the post
 * Method: `GET`
 * Authentication: optional
@@ -455,7 +455,7 @@ Emoji reactions work a lot like favourites do. They make it possible to react to
 * Example Response:
 ```json
 [
-  {"emoji": "😀", "count": 2, "accounts": [{"id" => "xyz.."...}, {"id" => "zyx..."}]},
-  {"emoji": "☕", "count": 1, "accounts": [{"id" => "abc..."}]}
+  {"name": "😀", "count": 2, "me": true, "accounts": [{"id" => "xyz.."...}, {"id" => "zyx..."}]},
+  {"name": "☕", "count": 1, "me": false, "accounts": [{"id" => "abc..."}]}
 ]
 ```
diff --git a/docs/admin/config.md b/docs/admin/config.md
deleted file mode 100644
index 35e43b6a9..000000000
--- a/docs/admin/config.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# Configuring instance
-You can configure your instance from admin interface. You need account with admin rights and little change in config file, which will allow settings configuration from database.
-
-```elixir
-config :pleroma, configurable_from_database: true
-```
-
-## How it works
-Settings are stored in database and are applied in `runtime` after each change. Most of the settings take effect immediately, except some, which need instance reboot. These settings are needed in `compile time`, that's why settings are duplicated to the file.
-
-File with duplicated settings is located in `config/{env}.exported_from_db.exs` if pleroma is runned from source. For prod env it will be `config/prod.exported_from_db.exs`.
-
-For releases: `/etc/pleroma/prod.exported_from_db.secret.exs` or `PLEROMA_CONFIG_PATH/prod.exported_from_db.exs`.
-
-## How to set it up
-You need to migrate your existing settings to the database. This task will migrate only added by user settings.
-For example you add settings to `prod.secret.exs` file, only these settings will be migrated to database. For release it will be `/etc/pleroma/config.exs` or `PLEROMA_CONFIG_PATH`.
-You can do this with mix task (all config files will remain untouched):
-
-```sh tab="OTP"
- ./bin/pleroma_ctl config migrate_to_db
-```
-
-```sh tab="From Source"
-mix pleroma.config migrate_to_db
-```
-
-Now you can change settings in admin interface. After each save, settings from database are duplicated to the `config/{env}.exported_from_db.exs` file.
-
-<span style="color:red">**ATTENTION**</span>
-
-**<span style="color:red">Be careful while changing the settings. Every inaccurate configuration change can break the federation or the instance load.</span>**
-
-*Compile time settings, which require instance reboot and can break instance loading:*
-- all settings inside these keys:
-  - `:hackney_pools`
-  - `:chat`
-- partially settings inside these keys:
-  - `:seconds_valid` in `Pleroma.Captcha`
-  - `:proxy_remote` in `Pleroma.Upload`
-  - `:upload_limit` in `:instance`
-
-## How to dump settings from database to file
-
-*Adding `-d` flag will delete migrated settings from database table.*
-
-```sh tab="OTP"
- ./bin/pleroma_ctl config migrate_from_db [-d]
-```
-
-```sh tab="From Source"
-mix pleroma.config migrate_from_db [-d]
-```
-
-
-## How to completely remove it
-
-1. Truncate or delete all values from `config` table
-```sql
-TRUNCATE TABLE config;
-```
-2. Delete `config/{env}.exported_from_db.exs`.
-
-For `prod` env:
-```bash
-cd /opt/pleroma
-cp config/prod.exported_from_db.exs config/exported_from_db.back
-rm -rf config/prod.exported_from_db.exs
-```
-*If you don't want to backup settings, you can skip step with `cp` command.*
-
-3. Set configurable_from_database to `false`.
-```elixir
-config :pleroma, configurable_from_database: false
-```
-4. Restart pleroma instance
-```bash
-sudo service pleroma restart
-```
diff --git a/docs/administration/CLI_tasks/config.md b/docs/administration/CLI_tasks/config.md
index 2af51c247..cc32bf859 100644
--- a/docs/administration/CLI_tasks/config.md
+++ b/docs/administration/CLI_tasks/config.md
@@ -1,12 +1,16 @@
 # Transfering the config to/from the database
 
-!!! danger
-    This is a Work In Progress, not usable just yet.
-
 {! backend/administration/CLI_tasks/general_cli_task_info.include !}
 
 ## Transfer config from file to DB.
 
+!!! note
+    You need to add the following to your config before executing this command:
+
+    ```elixir
+    config :pleroma, configurable_from_database: true
+    ```
+
 ```sh tab="OTP"
  ./bin/pleroma_ctl config migrate_to_db
 ```
@@ -18,7 +22,15 @@ mix pleroma.config migrate_to_db
 
 ## Transfer config from DB to `config/env.exported_from_db.secret.exs`
 
-To delete transfered settings from database optional flag `-d` can be used. <env> is `prod` by default.
+!!! note
+    In-Database configuration will still be applied after executing this command unless you set the following in your config:
+
+    ```elixir
+    config :pleroma, configurable_from_database: false
+    ```
+
+To delete transfered settings from database optional flag `-d` can be used. `<env>` is `prod` by default.
+
 ```sh tab="OTP"
  ./bin/pleroma_ctl config migrate_from_db [--env=<env>] [-d]
 ```
diff --git a/docs/administration/backup.md b/docs/administration/backup.md
index 2c70e7bf8..685c45128 100644
--- a/docs/administration/backup.md
+++ b/docs/administration/backup.md
@@ -1,17 +1,35 @@
-# Backup/Restore your instance
+# Backup/Restore/Move/Remove your instance
 
 ## Backup
 
 1. Stop the Pleroma service.
 2. Go to the working directory of Pleroma (default is `/opt/pleroma`)
-3. Run `sudo -Hu postgres pg_dump -d <pleroma_db> --format=custom -f </path/to/backup_location/pleroma.pgdump>`
+3. Run `sudo -Hu postgres pg_dump -d <pleroma_db> --format=custom -f </path/to/backup_location/pleroma.pgdump>` (make sure the postgres user has write access to the destination file)
 4. Copy `pleroma.pgdump`, `config/prod.secret.exs` and the `uploads` folder to your backup destination. If you have other modifications, copy those changes too.
 5. Restart the Pleroma service.
 
-## Restore
+## Restore/Move
 
-1. Stop the Pleroma service.
-2. Go to the working directory of Pleroma (default is `/opt/pleroma`)
-3. Copy the above mentioned files back to their original position.
-4. Run `sudo -Hu postgres pg_restore -d <pleroma_db> -v -1 </path/to/backup_location/pleroma.pgdump>`
-5. Restart the Pleroma service.
+1. Optionally reinstall Pleroma (either on the same server or on another server if you want to move servers). Try to use the same database name.
+2. Stop the Pleroma service.
+3. Go to the working directory of Pleroma (default is `/opt/pleroma`)
+4. Copy the above mentioned files back to their original position.
+5. Drop the existing database and recreate an empty one `sudo -Hu postgres psql -c 'DROP DATABASE <pleroma_db>;';` `sudo -Hu postgres psql -c 'CREATE DATABASE <pleroma_db>;';`
+6. Run `sudo -Hu postgres pg_restore -d <pleroma_db> -v -1 </path/to/backup_location/pleroma.pgdump>`
+7. If you installed a newer Pleroma version, you should run `mix ecto.migrate`[^1]. This task performs database migrations, if there were any.
+8. Restart the Pleroma service.
+
+[^1]: Prefix with `MIX_ENV=prod` to run it using the production config file.
+
+## Remove
+
+1. Optionally you can remove the users of your instance. This will trigger delete requests for their accounts and posts. Note that this is 'best effort' and doesn't mean that all traces of your instance will be gone from the fediverse.
+    * You can do this from the admin-FE where you can select all local users and delete the accounts using the *Moderate multiple users* dropdown.
+    * You can also list local users and delete them individualy using the CLI tasks for [Managing users](./CLI_tasks/user.md).
+2. Stop the Pleroma service `systemctl stop pleroma`
+3. Disable pleroma from systemd `systemctl disable pleroma`
+4. Remove the files and folders you created during installation (see installation guide). This includes the pleroma, nginx and systemd files and folders.
+5. Reload nginx now that the configuration is removed `systemctl reload nginx`
+6. Remove the database and database user `sudo -Hu postgres psql -c 'DROP DATABASE <pleroma_db>;';` `sudo -Hu postgres psql -c 'DROP USER <pleroma_db>;';`
+7. Remove the system user `userdel pleroma`
+8. Remove the dependencies that you don't need anymore (see installation guide). Make sure you don't remove packages that are still needed for other software that you have running!
diff --git a/docs/administration/updating.md b/docs/administration/updating.md
index 84e6ef18d..2a08dac1f 100644
--- a/docs/administration/updating.md
+++ b/docs/administration/updating.md
@@ -1,4 +1,21 @@
 # Updating your instance
+
+You should **always check the release notes/changelog** in case there are config deprecations, special update special update steps, etc.
+
+Besides that, doing the following is generally enough:
+
+## For OTP installations
+
+```sh
+# Download the new release
+su pleroma -s $SHELL -lc "./bin/pleroma_ctl update"
+
+# Migrate the database, you are advised to stop the instance before doing that
+su pleroma -s $SHELL -lc "./bin/pleroma_ctl migrate"
+```
+
+## For from source installations (using git)
+
 1. Go to the working directory of Pleroma (default is `/opt/pleroma`)
 2. Run `git pull`. This pulls the latest changes from upstream.
 3. Run `mix deps.get`. This pulls in any new dependencies.
diff --git a/docs/clients.md b/docs/clients.md
index 6c6180f7a..8ac9ad3de 100644
--- a/docs/clients.md
+++ b/docs/clients.md
@@ -37,6 +37,11 @@ Feel free to contact us to be added to this list!
 - Platforms: Android
 - Features: Streaming Ready, Moderation, Text Formatting 
 
+### Kyclos
+- Source Code: <https://git.pleroma.social/pleroma/harbour-kyclos>
+- Platforms: SailfishOS
+- Features: No Streaming
+
 ### Nekonium
 - Homepage: [F-Droid Repository](https://repo.gdgd.jp.net/), [Google Play](https://play.google.com/store/apps/details?id=com.apps.nekonium), [Amazon](https://www.amazon.co.jp/dp/B076FXPRBC/)
 - Source: <https://gogs.gdgd.jp.net/lin/nekonium>
diff --git a/docs/configuration/cheatsheet.md b/docs/configuration/cheatsheet.md
index 30d673eba..c9559fe85 100644
--- a/docs/configuration/cheatsheet.md
+++ b/docs/configuration/cheatsheet.md
@@ -69,6 +69,7 @@ You shouldn't edit the base config directly to avoid breakages and merge conflic
 * `account_field_name_length`: An account field name maximum length (default: `512`).
 * `account_field_value_length`: An account field value maximum length (default: `2048`).
 * `external_user_synchronization`: Enabling following/followers counters synchronization for external users.
+* `cleanup_attachments`: Remove attachments along with statuses. Does not affect duplicate files and attachments without status. Enabling this will increase load to database when deleting statuses on larger instances.
 
 ## Federation
 ### MRF policies
@@ -308,16 +309,15 @@ This will make Pleroma listen on `127.0.0.1` port `8080` and generate urls start
 Available options:
 
 * `enabled` - Enable/disable the plug. Defaults to `false`.
-* `headers` - A list of strings naming the `req_headers` to use when deriving the `remote_ip`. Order does not matter. Defaults to `~w[forwarded x-forwarded-for x-client-ip x-real-ip]`.
+* `headers` - A list of strings naming the `req_headers` to use when deriving the `remote_ip`. Order does not matter. Defaults to `["x-forwarded-for"]`.
 * `proxies` - A list of strings in [CIDR](https://en.wikipedia.org/wiki/CIDR) notation specifying the IPs of known proxies. Defaults to `[]`.
 * `reserved` - Defaults to [localhost](https://en.wikipedia.org/wiki/Localhost) and [private network](https://en.wikipedia.org/wiki/Private_network).
 
 
 ### :rate_limit
 
-This is an advanced feature and disabled by default.
-
-If your instance is behind a reverse proxy you must enable and configure [`Pleroma.Plugs.RemoteIp`](#pleroma-plugs-remoteip).
+!!! note
+   If your instance is behind a reverse proxy ensure [`Pleroma.Plugs.RemoteIp`](#pleroma-plugs-remoteip) is enabled (it is enabled by default).
 
 A keyword list of rate limiters where a key is a limiter name and value is the limiter configuration. The basic configuration is a tuple where:
 
@@ -326,14 +326,31 @@ A keyword list of rate limiters where a key is a limiter name and value is the l
 
 It is also possible to have different limits for unauthenticated and authenticated users: the keyword value must be a list of two tuples where the first one is a config for unauthenticated users and the second one is for authenticated.
 
+For example:
+
+```elixir
+config :pleroma, :rate_limit,
+  authentication: {60_000, 15},
+  search: [{1000, 10}, {1000, 30}]
+```
+
+Means that:
+
+1. In 60 seconds, 15 authentication attempts can be performed from the same IP address.
+2. In 1 second, 10 search requests can be performed from the same IP adress by unauthenticated users, while authenticated users can perform 30 search requests per second.
+
 Supported rate limiters:
 
-* `:search` for the search requests (account & status search etc.)
-* `:app_account_creation` for registering user accounts from the same IP address
-* `:relations_actions` for actions on relations with all users (follow, unfollow)
-* `:relation_id_action` for actions on relation with a specific user (follow, unfollow)
-* `:statuses_actions` for create / delete / fav / unfav / reblog / unreblog actions on any statuses
-* `:status_id_action` for fav / unfav or reblog / unreblog actions on the same status by the same user
+* `:search` - Account/Status search.
+* `:app_account_creation` - Account registration from the API.
+* `:relations_actions` - Following/Unfollowing in general.
+* `:relation_id_action` - Following/Unfollowing for a specific user.
+* `:statuses_actions` - Status actions such as: (un)repeating, (un)favouriting, creating, deleting.
+* `:status_id_action` - (un)Repeating/(un)Favouriting a particular status.
+* `:authentication` - Authentication actions, i.e getting an OAuth token.
+* `:password_reset` - Requesting password reset emails.
+* `:account_confirmation_resend` - Requesting resending account confirmation emails.
+* `:ap_routes` - Requesting statuses via ActivityPub.
 
 ### :web_cache_ttl
 
@@ -484,6 +501,10 @@ Email notifications settings.
 - `:logo` - a path to a custom logo. Set it to `nil` to use the default Pleroma logo.
 - `:styling` - a map with color settings for email templates.
 
+### Pleroma.Emails.NewUsersDigestEmail
+
+- `:enabled` - a boolean, enables new users admin digest email when `true`. Defaults to `false`.
+
 ## Background jobs
 
 ### Oban
@@ -496,6 +517,7 @@ Configuration options described in [Oban readme](https://github.com/sorentwo/oba
 * `verbose` - logs verbosity
 * `prune` - non-retryable jobs [pruning settings](https://github.com/sorentwo/oban#pruning) (`:disabled` / `{:maxlen, value}` / `{:maxage, value}`)
 * `queues` - job queues (see below)
+* `crontab` - periodic jobs, see [`Oban.Cron`](#obancron)
 
 Pleroma has the following queues:
 
@@ -507,6 +529,12 @@ Pleroma has the following queues:
 * `web_push` - Web push notifications
 * `scheduled_activities` - Scheduled activities, see [`Pleroma.ScheduledActivity`](#pleromascheduledactivity)
 
+#### Oban.Cron
+
+Pleroma has these periodic job workers:
+
+`Pleroma.Workers.Cron.ClearOauthTokenWorker` - a job worker to cleanup expired oauth tokens.
+
 Example:
 
 ```elixir
@@ -517,6 +545,9 @@ config :pleroma, Oban,
   queues: [
     federator_incoming: 50,
     federator_outgoing: 50
+  ],
+  crontab: [
+    {"0 0 * * *", Pleroma.Workers.Cron.ClearOauthTokenWorker}
   ]
 ```
 
@@ -799,8 +830,7 @@ Configure OAuth 2 provider capabilities:
 
 * `token_expires_in` - The lifetime in seconds of the access token.
 * `issue_new_refresh_token` - Keeps old refresh token or generate new refresh token when to obtain an access token.
-* `clean_expired_tokens` - Enable a background job to clean expired oauth tokens. Defaults to `false`.
-* `clean_expired_tokens_interval` - Interval to run the job to clean expired tokens. Defaults to `86_400_000` (24 hours).
+* `clean_expired_tokens` - Enable a background job to clean expired oauth tokens. Defaults to `false`. Interval settings sets in configuration periodic jobs [`Oban.Cron`](#obancron)
 
 ## Link parsing
 
@@ -839,4 +869,5 @@ config :auto_linker,
 
 
 ## :configurable_from_database
-Enable/disable configuration from database.
+
+Boolean, enables/disables in-database configuration. Read [Transfering the config to/from the database](../administration/CLI_tasks/config.md) for more information.
diff --git a/docs/configuration/mrf.md b/docs/configuration/mrf.md
index 45be18fc5..c3957c255 100644
--- a/docs/configuration/mrf.md
+++ b/docs/configuration/mrf.md
@@ -1,4 +1,5 @@
 # Message Rewrite Facility
+
 The Message Rewrite Facility (MRF) is a subsystem that is implemented as a series of hooks that allows the administrator to rewrite or discard messages.
 
 Possible uses include:
@@ -10,7 +11,8 @@ Possible uses include:
 * removing media from messages
 * sending only public messages to a specific instance
 
-The MRF provides user-configurable policies.  The default policy is `NoOpPolicy`, which disables the MRF functionality.  Pleroma also includes an easy to use policy called `SimplePolicy` which maps messages matching certain pre-defined criterion to actions built into the policy module.
+The MRF provides user-configurable policies. The default policy is `NoOpPolicy`, which disables the MRF functionality. Pleroma also includes an easy to use policy called `SimplePolicy` which maps messages matching certain pre-defined criterion to actions built into the policy module.
+
 It is possible to use multiple, active MRF policies at the same time.
 
 ## Quarantine Instances
@@ -18,7 +20,8 @@ It is possible to use multiple, active MRF policies at the same time.
 You have the ability to prevent from private / followers-only messages from federating with specific instances. Which means they will only get the public or unlisted messages from your instance.
 
 If, for example, you're using `MIX_ENV=prod` aka using production mode, you would open your configuration file located in `config/prod.secret.exs` and edit or add the option under your `:instance` config object. Then you would specify the instance within quotes.
-```
+
+```elixir
 config :pleroma, :instance,
   [...]
   quarantined_instances: ["instance.example", "other.example"]
@@ -28,15 +31,15 @@ config :pleroma, :instance,
 
 `SimplePolicy` is capable of handling most common admin tasks.
 
-To use `SimplePolicy`, you must enable it.  Do so by adding the following to your `:instance` config object, so that it looks like this:
+To use `SimplePolicy`, you must enable it. Do so by adding the following to your `:instance` config object, so that it looks like this:
 
-```
+```elixir
 config :pleroma, :instance,
   [...]
   rewrite_policy: Pleroma.Web.ActivityPub.MRF.SimplePolicy
 ```
 
-Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object.  These groups are:
+Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object. These groups are:
 
 * `media_removal`: Servers in this group will have media stripped from incoming messages.
 * `media_nsfw`: Servers in this group will have the #nsfw tag and sensitive setting injected into incoming messages which contain media.
@@ -50,7 +53,7 @@ Servers should be configured as lists.
 
 This example will enable `SimplePolicy`, block media from `illegalporn.biz`, mark media as NSFW from `porn.biz` and `porn.business`, reject messages from `spam.com`, remove messages from `spam.university` from the federated timeline and block reports (flags) from `whiny.whiner`:
 
-```
+```elixir
 config :pleroma, :instance,
   rewrite_policy: [Pleroma.Web.ActivityPub.MRF.SimplePolicy]
 
@@ -60,30 +63,31 @@ config :pleroma, :mrf_simple,
   reject: ["spam.com"],
   federated_timeline_removal: ["spam.university"],
   report_removal: ["whiny.whiner"]
-
 ```
 
 ### Use with Care
 
-The effects of MRF policies can be very drastic.  It is important to use this functionality carefully.  Always try to talk to an admin before writing an MRF policy concerning their instance.
+The effects of MRF policies can be very drastic. It is important to use this functionality carefully. Always try to talk to an admin before writing an MRF policy concerning their instance.
 
 ## Writing your own MRF Policy
 
-As discussed above, the MRF system is a modular system that supports pluggable policies.  This means that an admin may write a custom MRF policy in Elixir or any other language that runs on the Erlang VM, by specifying the module name in the `rewrite_policy` config setting.
+As discussed above, the MRF system is a modular system that supports pluggable policies. This means that an admin may write a custom MRF policy in Elixir or any other language that runs on the Erlang VM, by specifying the module name in the `rewrite_policy` config setting.
 
 For example, here is a sample policy module which rewrites all messages to "new message content":
 
 ```elixir
-# This is a sample MRF policy which rewrites all Notes to have "new message
-# content."
-defmodule Site.RewritePolicy do
-  @behavior Pleroma.Web.ActivityPub.MRF
+defmodule Pleroma.Web.ActivityPub.MRF.RewritePolicy do
+  @moduledoc "MRF policy which rewrites all Notes to have 'new message content'."
+  @behaviour Pleroma.Web.ActivityPub.MRF
 
   # Catch messages which contain Note objects with actual data to filter.
   # Capture the object as `object`, the message content as `content` and the
   # message itself as `message`.
   @impl true
-  def filter(%{"type" => Create", "object" => {"type" => "Note", "content" => content} = object} = message)
+  def filter(
+        %{"type" => "Create", "object" => %{"type" => "Note", "content" => content} = object} =
+          message
+      )
       when is_binary(content) do
     # Subject / CW is stored as summary instead of `name` like other AS2 objects
     # because of Mastodon doing it that way.
@@ -106,17 +110,22 @@ defmodule Site.RewritePolicy do
   # Let all other messages through without modifying them.
   @impl true
   def filter(message), do: {:ok, message}
+
+  @impl true
+  def describe do
+    {:ok, %{mrf_sample: %{content: "new message content"}}}`
+  end
 end
 ```
 
-If you save this file as `lib/site/mrf/rewrite_policy.ex`, it will be included when you next rebuild Pleroma.  You can enable it in the configuration like so:
+If you save this file as `lib/pleroma/web/activity_pub/mrf/rewrite_policy.ex`, it will be included when you next rebuild Pleroma.  You can enable it in the configuration like so:
 
-```
+```elixir
 config :pleroma, :instance,
   rewrite_policy: [
     Pleroma.Web.ActivityPub.MRF.SimplePolicy,
-    Site.RewritePolicy
+    Pleroma.Web.ActivityPub.MRF.RewritePolicy
   ]
 ```
 
-Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL.  As such, you are obligated to release the sources to your custom MRF policy modules upon request.
+Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL. As such, you are obligated to release the sources to your custom MRF policy modules upon request.
diff --git a/docs/installation/otp_en.md b/docs/installation/otp_en.md
index 93230806c..aab5197a2 100644
--- a/docs/installation/otp_en.md
+++ b/docs/installation/otp_en.md
@@ -259,19 +259,14 @@ su pleroma -s $SHELL -lc "./bin/pleroma_ctl user new joeuser joeuser@sld.tld --a
 ```
 This will create an account withe the username of 'joeuser' with the email address of joeuser@sld.tld, and set that user's account as an admin. This will result in a link that you can paste into the browser, which logs you in and enables you to set the password.
 
-### Updating
-Generally, doing the following is enough:
-```sh
-# Download the new release
-su pleroma -s $SHELL -lc "./bin/pleroma_ctl update"
-
-# Migrate the database, you are advised to stop the instance before doing that
-su pleroma -s $SHELL -lc "./bin/pleroma_ctl migrate"
-```
-But you should **always check the release notes/changelog** in case there are config deprecations, special update steps, etc.
-
 ## Further reading
 
 * [Backup your instance](../administration/backup.md)
 * [Hardening your instance](../configuration/hardening.md)
 * [How to activate mediaproxy](../configuration/howto_mediaproxy.md)
+* [Updating your instance](../administration/updating.md)
+
+## Questions
+
+Questions about the installation or didn’t it work as it should be, ask in [#pleroma:matrix.org](https://matrix.heldscal.la/#/room/#freenode_#pleroma:matrix.org) or IRC Channel **#pleroma** on **Freenode**.
+