6 files changed, 94 insertions, 19 deletions
diff --git a/docs/administration/CLI_tasks/frontend.md b/docs/administration/CLI_tasks/frontend.md
index d4a48cb56..4e9d9eecb 100644
--- a/docs/administration/CLI_tasks/frontend.md
+++ b/docs/administration/CLI_tasks/frontend.md
@@ -22,7 +22,7 @@ Currently, known `<frontend>` values are:
 - [kenoma](http://git.pleroma.social/lambadalambda/kenoma)
 - [pleroma-fe](http://git.pleroma.social/pleroma/pleroma-fe)
 - [fedi-fe](https://git.pleroma.social/pleroma/fedi-fe)
-- [soapbox-fe](https://gitlab.com/soapbox-pub/soapbox-fe)
+- [soapbox](https://gitlab.com/soapbox-pub/soapbox)
 
 You can still install frontends that are not configured, see below.
 
diff --git a/docs/administration/updating.md b/docs/administration/updating.md
index 01d3b9b0e..00eca36a0 100644
--- a/docs/administration/updating.md
+++ b/docs/administration/updating.md
@@ -17,7 +17,7 @@ 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` [^1]. This pulls the latest changes from upstream.
+2. Run `git checkout <tagged release>` [^1]. e.g. `git checkout v2.4.5` This pulls the [tagged release](https://git.pleroma.social/pleroma/pleroma/-/releases) from upstream.
 3. Run `mix deps.get` [^1]. This pulls in any new dependencies.
 4. Stop the Pleroma service.
 5. Run `mix ecto.migrate` [^1] [^2]. This task performs database migrations, if there were any.
diff --git a/docs/configuration/cheatsheet.md b/docs/configuration/cheatsheet.md
index 6e13b9622..314fdbbab 100644
--- a/docs/configuration/cheatsheet.md
+++ b/docs/configuration/cheatsheet.md
@@ -49,6 +49,7 @@ To add configuration to your config file, you can copy it from the base config.
 * `autofollowing_nicknames`: Set to nicknames of (local) users that automatically follows every newly registered user.
 * `attachment_links`: Set to true to enable automatically adding attachment link text to statuses.
 * `max_report_comment_size`: The maximum size of the report comment (Default: `1000`).
+* `report_strip_status`: Strip associated statuses in reports to ids when closed/resolved, otherwise keep a copy.
 * `safe_dm_mentions`: If set to true, only mentions at the beginning of a post will be used to address people in direct messages. This is to prevent accidental mentioning of people when talking about them (e.g. "@friend hey i really don't like @enemy"). Default: `false`.
 * `healthcheck`: If set to true, system data will be shown on ``/api/v1/pleroma/healthcheck``.
 * `remote_post_retention_days`: The default amount of days to retain remote posts when pruning the database.
@@ -204,7 +205,7 @@ config :pleroma, :mrf_user_allowlist, %{
   e.g., A value of 900 results in any post with a timestamp older than 15 minutes will be acted upon.
 * `actions`: A list of actions to apply to the post:
   * `:delist` removes the post from public timelines
-  * `:strip_followers` removes followers from the ActivityPub recipient list, ensuring they won't be delivered to home timelines
+  * `:strip_followers` removes followers from the ActivityPub recipient list, ensuring they won't be delivered to home timelines, additionally for followers-only it degrades to a direct message
   * `:reject` rejects the message entirely
 
 #### :mrf_steal_emoji
@@ -777,7 +778,7 @@ Web Push Notifications configuration. You can use the mix task `mix web_push.gen
 * ``private_key``: VAPID private key
 
 ## :logger
-* `backends`: `:console` is used to send logs to stdout, `{ExSyslogger, :ex_syslogger}` to log to syslog, and `Quack.Logger` to log to Slack
+* `backends`: `:console` is used to send logs to stdout, `{ExSyslogger, :ex_syslogger}` to log to syslog
 
 An example to enable ONLY ExSyslogger (f/ex in ``prod.secret.exs``) with info and debug suppressed:
 ```elixir
@@ -800,10 +801,10 @@ config :logger, :ex_syslogger,
 
 See: [logger’s documentation](https://hexdocs.pm/logger/Logger.html) and [ex_syslogger’s documentation](https://hexdocs.pm/ex_syslogger/)
 
-An example of logging info to local syslog, but warn to a Slack channel:
+An example of logging info to local syslog, but debug to console:
 ```elixir
 config :logger,
-  backends: [ {ExSyslogger, :ex_syslogger}, Quack.Logger ],
+  backends: [ {ExSyslogger, :ex_syslogger}, :console ],
   level: :info
 
 config :logger, :ex_syslogger,
@@ -811,14 +812,12 @@ config :logger, :ex_syslogger,
   ident: "pleroma",
   format: "$metadata[$level] $message"
 
-config :quack,
-  level: :warn,
-  meta: [:all],
-  webhook_url: "https://hooks.slack.com/services/YOUR-API-KEY-HERE"
+config :logger, :console,
+  level: :debug,
+  format: "\n$time $metadata[$level] $message\n",
+  metadata: [:request_id]
 ```
 
-See the [Quack Github](https://github.com/azohra/quack) for more details
-
 
 
 ## Database options
diff --git a/docs/configuration/how_to_serve_another_domain_for_webfinger.md b/docs/configuration/how_to_serve_another_domain_for_webfinger.md
new file mode 100644
index 000000000..5ae3e7943
--- /dev/null
+++ b/docs/configuration/how_to_serve_another_domain_for_webfinger.md
@@ -0,0 +1,62 @@
+# How to use a different domain name for Pleroma and the users it serves
+
+Pleroma users are primarily identified by a `user@example.org` handle, and you might want this identifier to be the same as your email or jabber account, for instance.
+However, in this case, you are almost certainly serving some web content on `https://example.org` already, and you might want to use another domain (say `pleroma.example.org`) for Pleroma itself.
+
+Pleroma supports that, but it might be tricky to set up, and any error might prevent you from federating with other instances.
+
+*If you are already running Pleroma on `example.org`, it is no longer possible to move it to `pleroma.example.org`.*
+
+## Account identifiers
+
+It is important to understand that for federation purposes, a user in Pleroma has two unique identifiers associated:
+
+- A webfinger `acct:` URI, used for discovery and as a verifiable global name for the user across Pleroma instances. In our example, our account's acct: URI is `acct:user@example.org`
+- An author/actor URI, used in every other aspect of federation. This is the way in which users are identified in ActivityPub, the underlying protocol used for federation with other Pleroma instances.
+In our case, it is `https://pleroma.example.org/users/user`.
+
+Both account identifiers are unique and required for Pleroma. An important risk if you set up your Pleroma instance incorrectly is to create two users (with different acct: URIs) with conflicting author/actor URIs.
+
+## WebFinger
+
+As said earlier, each Pleroma user has an `acct`: URI, which is used for discovery and authentication. When you add @user@example.org, a webfinger query is performed. This is done in two steps:
+
+1. Querying `https://example.org/.well-known/host-meta` (where the domain of the URL matches the domain part of the `acct`: URI) to get information on how to perform the query.
+This file will indeed contain a URL template of the form `https://example.org/.well-known/webfinger?resource={uri}` that will be used in the second step.
+2. Fill the returned template with the `acct`: URI to be queried and perform the query: `https://example.org/.well-known/webfinger?resource=acct:user@example.org`
+
+## Configuring your Pleroma instance
+
+**_DO NOT ATTEMPT TO CONFIGURE YOUR INSTANCE THIS WAY IF YOU DID NOT UNDERSTAND THE ABOVE_**
+
+### Configuring Pleroma
+
+Pleroma has a two configuration settings to enable using different domains for your users and Pleroma itself. `host` in `Pleroma.Web.Endpoint` and `domain` in `Pleroma.Web.WebFinger`. When the latter is not set, it defaults to the value of `host`.
+
+*Be extra careful when configuring your Pleroma instance, as changing `host` may cause remote instances to register different accounts with the same author/actor URI, which will result in federation issues!*
+
+```elixir
+config :pleroma, Pleroma.Web.Endpoint,
+  url: [host: "pleroma.example.org"]
+
+config :pleroma, Pleroma.Web.WebFinger, domain: "example.org"
+```
+
+- `domain` - is the domain for which your Pleroma instance has authority, it's the domain used in `acct:` URI. In our example, `domain` would be set to `example.org`. This is used in WebFinger account ids, which are the canonical account identifier in some other fediverse software like Mastodon. **If you change `domain`, the accounts on your server will be shown as different accounts in those software**.
+- `host` - is the domain used for any URL generated for your instance, including the author/actor URL's. In our case, that would be `pleroma.example.org`. This is used in AP ids, which are the canonical account identifier in Pleroma and some other fediverse software. **You should not change this after you have set up the instance**.
+
+### Configuring WebFinger domain
+
+Now, you have Pleroma running at `https://pleroma.example.org` as well as a website at `https://example.org`. If you recall how webfinger queries work, the first step is to query `https://example.org/.well-known/host-meta`, which will contain an URL template.
+
+Therefore, the easiest way to configure `example.org` is to redirect `/.well-known/host-meta` to `pleroma.example.org`.
+
+With nginx, it would be as simple as adding:
+
+```nginx
+location = /.well-known/host-meta {
+       return 301 https://pleroma.example.org$request_uri;
+}
+```
+
+in example.org's server block.
diff --git a/docs/development/API/admin_api.md b/docs/development/API/admin_api.md
index c46f83839..f6e9f7d2a 100644
--- a/docs/development/API/admin_api.md
+++ b/docs/development/API/admin_api.md
@@ -1064,7 +1064,6 @@ List of settings which support only full update by key:
 ```elixir
 @full_key_update [
     {:pleroma, :ecto_repos},
-    {:quack, :meta},
     {:mime, :types},
     {:cors_plug, [:max_age, :methods, :expose, :headers]},
     {:auto_linker, :opts},
@@ -1084,18 +1083,18 @@ List of settings which support only full update by subkey:
   ]
 ```
 
-*Settings without explicit key must be sended in separate config object params.*
+*Settings without explicit key must be sent in separate config object params.*
 ```elixir
-config :quack,
-  level: :debug,
-  meta: [:all],
+config :foo,
+  bar: :baz,
+  meta: [:data],
   ...
 ```
 ```json
 {
   "configs": [
-    {"group": ":quack", "key": ":level", "value": ":debug"},
-    {"group": ":quack", "key": ":meta", "value": [":all"]},
+    {"group": ":foo", "key": ":bar", "value": ":baz"},
+    {"group": ":foo", "key": ":meta", "value": [":data"]},
     ...
   ]
 }
diff --git a/docs/installation/nixos_en.md b/docs/installation/nixos_en.md
new file mode 100644
index 000000000..f3c4988b1
--- /dev/null
+++ b/docs/installation/nixos_en.md
@@ -0,0 +1,15 @@
+# Installing on NixOS
+
+NixOS contains a source build package of pleroma and a NixOS module to install it.
+For installation add this to your configuration.nix and add a config.exs next to it:
+```nix
+  services.pleroma = {
+    enable = true;
+    configs = [ (lib.fileContents ./config.exs) ];
+    secretConfigFile = "/var/lib/pleroma/secret.exs";
+  };
+```
+
+## Questions
+The nix community uses matrix for communication: [#nix:nixos.org](https://matrix.to/#/#nix:nixos.org)
+