Merge remote-tracking branch 'upstream/develop' into registration-workflow

7 files changed, 193 insertions, 62 deletions

diff --git a/docs/API/differences_in_mastoapi_responses.md b/docs/API/differences_in_mastoapi_responses.md
index 6b0ad85d1..1b197e073 100644
--- a/docs/API/differences_in_mastoapi_responses.md
+++ b/docs/API/differences_in_mastoapi_responses.md
@@ -4,7 +4,7 @@ A Pleroma instance can be identified by "<Mastodon version> (compatible; Pleroma
 
 ## Flake IDs
 
-Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However just like Mastodon's ids they are lexically sortable strings
+Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However, just like Mastodon's ids, they are lexically sortable strings
 
 ## Timelines
 
@@ -26,8 +26,8 @@ Has these additional fields under the `pleroma` object:
 - `conversation_id`: the ID of the AP context the status is associated with (if any)
 - `direct_conversation_id`: the ID of the Mastodon direct message conversation the status is associated with (if any)
 - `in_reply_to_account_acct`: the `acct` property of User entity for replied user (if any)
-- `content`: a map consisting of alternate representations of the `content` property with the key being it's mimetype. Currently the only alternate representation supported is `text/plain`
-- `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`
+- `content`: a map consisting of alternate representations of the `content` property with the key being its mimetype. Currently, the only alternate representation supported is `text/plain`
+- `spoiler_text`: a map consisting of alternate representations of the `spoiler_text` property with the key being its 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 `{name: "☕", count: 1, me: true}`. Contains no information about the reacting users, for that use the `/statuses/:id/reactions` endpoint.
@@ -170,9 +170,9 @@ Returns on success: 200 OK `{}`
 
 Additional parameters can be added to the JSON body/Form data:
 
-- `preview`: boolean, if set to `true` the post won't be actually posted, but the status entitiy would still be rendered back. This could be useful for previewing rich text/custom emoji, for example.
+- `preview`: boolean, if set to `true` the post won't be actually posted, but the status entity would still be rendered back. This could be useful for previewing rich text/custom emoji, for example.
 - `content_type`: string, contain the MIME type of the status, it is transformed into HTML by the backend. You can get the list of the supported MIME types with the nodeinfo endpoint.
-- `to`: A list of nicknames (like `lain@soykaf.club` or `lain` on the local server) that will be used to determine who is going to be addressed by this post. Using this will disable the implicit addressing by mentioned names in the `status` body, only the people in the `to` list will be addressed. The normal rules for for post visibility are not affected by this and will still apply.
+- `to`: A list of nicknames (like `lain@soykaf.club` or `lain` on the local server) that will be used to determine who is going to be addressed by this post. Using this will disable the implicit addressing by mentioned names in the `status` body, only the people in the `to` list will be addressed. The normal rules for post visibility are not affected by this and will still apply.
 - `visibility`: string, besides standard MastoAPI values (`direct`, `private`, `unlisted`, `local` or `public`) it can be used to address a List by setting it to `list:LIST_ID`.
 - `expires_in`: The number of seconds the posted activity should expire in. When a posted activity expires it will be deleted from the server, and a delete request for it will be federated. This needs to be longer than an hour.
 - `in_reply_to_conversation_id`: Will reply to a given conversation, addressing only the people who are part of the recipient set of that conversation. Sets the visibility to `direct`.
@@ -279,10 +279,27 @@ Has these additional fields under the `pleroma` object:
 
 ## Streaming
 
+### Chats
+
 There is an additional `user:pleroma_chat` stream. Incoming chat messages will make the current chat be sent to this `user` stream. The `event` of an incoming chat message is `pleroma:chat_update`. The payload is the updated chat with the incoming chat message in the `last_message` field.
 
+### Remote timelines
+
 For viewing remote server timelines, there are `public:remote` and `public:remote:media` streams. Each of these accept a parameter like `?instance=lain.com`.
 
+### Follow relationships updates
+
+Pleroma streams follow relationships updates as `pleroma:follow_relationships_update` events to the `user` stream.
+
+The message payload consist of:
+
+- `state`: a relationship state, one of `follow_pending`, `follow_accept` or `follow_reject`.
+
+- `follower` and `following` maps with following fields:
+  - `id`: user ID
+  - `follower_count`: follower count
+  - `following_count`: following count
+
 ## User muting and thread muting
 
 Both user muting and thread muting can be done for only a certain time by adding an `expires_in` parameter to the API calls and giving the expiration time in seconds.
diff --git a/docs/API/pleroma_api.md b/docs/API/pleroma_api.md
index 7a0a80dad..d8790ca32 100644
--- a/docs/API/pleroma_api.md
+++ b/docs/API/pleroma_api.md
@@ -579,14 +579,14 @@ Emoji reactions work a lot like favourites do. They make it possible to react to
 ### React to a post with a unicode emoji
 * Method: `PUT`
 * Authentication: required
-* Params: `emoji`: A single character unicode emoji
+* Params: `emoji`: A unicode RGI emoji or a regional indicator
 * Response: JSON, the status.
 
 ## `DELETE /api/v1/pleroma/statuses/:id/reactions/:emoji`
 ### Remove a reaction to a post with a unicode emoji
 * Method: `DELETE`
 * Authentication: required
-* Params: `emoji`: A single character unicode emoji
+* Params: `emoji`: A unicode RGI emoji or a regional indicator
 * Response: JSON, the status.
 
 ## `GET /api/v1/pleroma/statuses/:id/reactions`
diff --git a/docs/administration/CLI_tasks/config.md b/docs/administration/CLI_tasks/config.md
index 0923004b5..000ed4d98 100644
--- a/docs/administration/CLI_tasks/config.md
+++ b/docs/administration/CLI_tasks/config.md
@@ -32,7 +32,7 @@
     config :pleroma, configurable_from_database: false
     ```
 
-To delete transfered settings from database optional flag `-d` can be used. `<env>` is `prod` by default.
+To delete transferred settings from database optional flag `-d` can be used. `<env>` is `prod` by default.
 
 === "OTP"
     ```sh
@@ -43,3 +43,111 @@ To delete transfered settings from database optional flag `-d` can be used. `<en
     ```sh
     mix pleroma.config migrate_from_db [--env=<env>] [-d]
     ```
+
+## Dump all of the config settings defined in the database
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl config dump
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config dump
+    ```
+
+## List individual configuration groups in the database
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl config groups
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config groups
+    ```
+
+## Dump the saved configuration values for a specific group or key
+
+e.g., this shows all the settings under `config :pleroma`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config dump pleroma
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config dump pleroma
+    ```
+
+To get values under a specific key:
+
+e.g., this shows all the settings under `config :pleroma, :instance`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config dump pleroma instance
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config dump pleroma instance
+    ```
+
+## Delete the saved configuration values for a specific group or key
+
+e.g., this deletes all the settings under `config :tesla`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config delete [--force] tesla
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config delete [--force] tesla
+    ```
+
+To delete values under a specific key:
+
+e.g., this deletes all the settings under `config :phoenix, :stacktrace_depth`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config delete [--force] phoenix stacktrace_depth
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config delete [--force] phoenix stacktrace_depth
+    ```
+
+## Remove all settings from the database
+
+This forcibly removes all saved values in the database.
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config [--force] reset
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config [--force] reset
+    ```
diff --git a/docs/administration/CLI_tasks/email.md b/docs/administration/CLI_tasks/email.md
index d9aa0e71b..2bb57bea4 100644
--- a/docs/administration/CLI_tasks/email.md
+++ b/docs/administration/CLI_tasks/email.md
@@ -16,8 +16,7 @@
     mix pleroma.email test [--to <destination email address>]
     ```
 
-
-Example: 
+Example:
 
 === "OTP"
 
@@ -36,11 +35,11 @@ Example:
 === "OTP"
 
     ```sh
-     ./bin/pleroma_ctl email send_confirmation_mails
+     ./bin/pleroma_ctl email resend_confirmation_emails
     ```
 
 === "From Source"
 
     ```sh
-    mix pleroma.email send_confirmation_mails
+    mix pleroma.email resend_confirmation_emails
     ```
diff --git a/docs/configuration/howto_database_config.md b/docs/configuration/howto_database_config.md
index 9ed4d6cdd..ae1462f9b 100644
--- a/docs/configuration/howto_database_config.md
+++ b/docs/configuration/howto_database_config.md
@@ -5,50 +5,37 @@ The configuration of Pleroma has traditionally been managed with a config file,
 
 ## Migration to database config
 
-1. Run the mix task to migrate to the database. You'll receive some debugging output and a few messages informing you of what happened.
+1. Run the mix task to migrate to the database.
 
   **Source:**
-  
+
   ```
   $ mix pleroma.config migrate_to_db
   ```
-  
+
   or
-  
+
   **OTP:**
-  
+
   *Note: OTP users need Pleroma to be running for `pleroma_ctl` commands to work*
-  
+
   ```
   $ ./bin/pleroma_ctl config migrate_to_db
   ```
 
   ```
-   10:04:34.155 [debug] QUERY OK source="config" db=1.6ms decode=2.0ms queue=33.5ms idle=0.0ms
-    SELECT c0."id", c0."key", c0."group", c0."value", c0."inserted_at", c0."updated_at" FROM "config" AS c0 []
     Migrating settings from file: /home/pleroma/config/dev.secret.exs
-    
-   10:04:34.240 [debug] QUERY OK db=4.5ms queue=0.3ms idle=92.2ms
-    TRUNCATE config; []
-  
-   10:04:34.244 [debug] QUERY OK db=2.8ms queue=0.3ms idle=97.2ms
-    ALTER SEQUENCE config_id_seq RESTART; []
-    
-   10:04:34.256 [debug] QUERY OK source="config" db=0.8ms queue=1.4ms idle=109.8ms
-   SELECT c0."id", c0."key", c0."group", c0."value", c0."inserted_at", c0."updated_at" FROM "config" AS c0 WHERE ((c0."group" = $1) AND (c0."key" = $2)) [":pleroma", ":instance"]
-    
-   10:04:34.292 [debug] QUERY OK db=2.6ms queue=1.7ms idle=137.7ms
-   INSERT INTO "config" ("group","key","value","inserted_at","updated_at") VALUES ($1,$2,$3,$4,$5) RETURNING "id" [":pleroma", ":instance", <<131, 108, 0, 0, 0, 1, 104, 2, 100, 0, 4, 110, 97, 109, 101, 109, 0, 0, 0, 7, 66, 108, 101, 114, 111, 109, 97, 106>>, ~N[2020-07-12 15:04:34], ~N[2020-07-12 15:04:34]]
+
    Settings for key instance migrated.
    Settings for group :pleroma migrated.
   ```
-  
+
 2. It is recommended to backup your config file now.
 
   ```
   cp config/dev.secret.exs config/dev.secret.exs.orig
   ```
-  
+
 3. Edit your Pleroma config to enable database configuration:
 
   ```
@@ -76,17 +63,17 @@ The configuration of Pleroma has traditionally been managed with a config file,
 
   config :pleroma, Pleroma.Web.Endpoint,
     url: [host: "cool.pleroma.site", scheme: "https", port: 443]
-  
+
   config :pleroma, Pleroma.Repo,
     adapter: Ecto.Adapters.Postgres,
     username: "pleroma",
     password: "MySecretPassword",
     database: "pleroma_prod",
     hostname: "localhost"
-  
+
   config :pleroma, configurable_from_database: true
   ```
- 
+
 5. Restart your instance and you can now access the Settings tab in AdminFE.
 
 
@@ -95,15 +82,15 @@ The configuration of Pleroma has traditionally been managed with a config file,
 1. Run the mix task to migrate back from the database. You'll receive some debugging output and a few messages informing you of what happened.
 
   **Source:**
-  
+
   ```
   $ mix pleroma.config migrate_from_db
   ```
-  
+
   or
-  
+
   **OTP:**
-  
+
   ```
   $ ./bin/pleroma_ctl config migrate_from_db
   ```
@@ -111,7 +98,7 @@ The configuration of Pleroma has traditionally been managed with a config file,
   ```
   10:26:30.593 [debug] QUERY OK source="config" db=9.8ms decode=1.2ms queue=26.0ms idle=0.0ms
   SELECT c0."id", c0."key", c0."group", c0."value", c0."inserted_at", c0."updated_at" FROM "config" AS c0 []
-  
+
   10:26:30.659 [debug] QUERY OK source="config" db=1.1ms idle=80.7ms
   SELECT c0."id", c0."key", c0."group", c0."value", c0."inserted_at", c0."updated_at" FROM "config" AS c0 []
   Database configuration settings have been saved to config/dev.exported_from_db.secret.exs
@@ -124,30 +111,45 @@ The configuration of Pleroma has traditionally been managed with a config file,
 ## Debugging
 
 ### Clearing database config
-You can clear the database config by truncating the `config` table in the database. e.g.,
+You can clear the database config with the following command:
+
+  **Source:**
 
-```
-psql -d pleroma_dev
-pleroma_dev=# TRUNCATE config;
-TRUNCATE TABLE
-```
+  ```
+  $ mix pleroma.config reset
+  ```
+
+  or
+
+  **OTP:**
+
+  ```
+  $ ./bin/pleroma_ctl config reset
+  ```
 
 Additionally, every time you migrate the configuration to the database the config table is automatically truncated to ensure a clean migration.
 
 ### Manually removing a setting
 If you encounter a situation where the server cannot run properly because of an invalid setting in the database and this is preventing you from accessing AdminFE, you can manually remove the offending setting if you know which one it is.
 
-e.g., here is an example showing a minimal configuration in the database. Only the `config :pleroma, :instance` settings are in the table:
-
-```
-psql -d pleroma_dev
-pleroma_dev=# select * from config;
- id |    key    |                           value                            |     inserted_at     |     updated_at      |  group
-----+-----------+------------------------------------------------------------+---------------------+---------------------+----------
-  1 | :instance | \x836c0000000168026400046e616d656d00000007426c65726f6d616a | 2020-07-12 15:33:29 | 2020-07-12 15:33:29 | :pleroma
-(1 row)
-pleroma_dev=# delete from config where key = ':instance' and group = ':pleroma';
-DELETE 1
-```
+e.g., here is an example showing a the removal of the `config :pleroma, :instance` settings:
+
+  **Source:**
+
+  ```
+  $ mix pleroma.config delete pleroma instance
+  Are you sure you want to continue? [n]  y
+  config :pleroma, :instance deleted from the ConfigDB.
+  ```
+
+  or
+
+  **OTP:**
+
+  ```
+  $ ./bin/pleroma_ctl config delete pleroma instance
+  Are you sure you want to continue? [n]  y
+  config :pleroma, :instance deleted from the ConfigDB.
+  ```
 
 Now the `config :pleroma, :instance` settings have been removed from the database.
diff --git a/docs/configuration/static_dir.md b/docs/configuration/static_dir.md
index 8ac07b725..a294bb604 100644
--- a/docs/configuration/static_dir.md
+++ b/docs/configuration/static_dir.md
@@ -88,3 +88,8 @@ config :pleroma, :frontend_configurations,
     Note the extra `static` folder for the terms-of-service.html
 
 Terms of Service will be shown to all users on the registration page. It's the best place where to write down the rules for your instance. You can modify the rules by adding and changing `$static_dir/static/terms-of-service.html`.
+
+ 	
+## Styling rendered pages
+
+To overwrite the CSS stylesheet of the OAuth form and other static pages, you can upload your own CSS file to `instance/static/static.css`. This will completely replace the CSS used by those pages, so it might be a good idea to copy the one from `priv/static/instance/static.css` and make your changes.
diff --git a/docs/dev.md b/docs/dev.md
index aa89a941f..765380a58 100644
--- a/docs/dev.md
+++ b/docs/dev.md
@@ -14,9 +14,9 @@ This document contains notes and guidelines for Pleroma developers.
 
   For `:api` pipeline routes, it'll be verified whether `OAuthScopesPlug` was called or explicitly skipped, and if it was not then auth information will be dropped for request. Then `EnsurePublicOrAuthenticatedPlug` will be called to ensure that either the instance is not private or user is authenticated (unless explicitly skipped). Such automated checks help to prevent human errors and result in higher security / privacy for users.
 
-## [HTTP Basic Authentication](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)
+## Non-OAuth authentication
 
-* With HTTP Basic Auth, OAuth scopes check is _not_ performed for any action (since password is provided during the auth, requester is able to obtain a token with full permissions anyways). `Pleroma.Web.Plugs.AuthenticationPlug` and `Pleroma.Web.Plugs.LegacyAuthenticationPlug` both call `Pleroma.Web.Plugs.OAuthScopesPlug.skip_plug(conn)` when password is provided.
+* With non-OAuth authentication ([HTTP Basic Authentication](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) or HTTP header- or params-provided auth), OAuth scopes check is _not_ performed for any action (since password is provided during the auth, requester is able to obtain a token with full permissions anyways); auth plugs invoke `Pleroma.Helpers.AuthHelper.skip_oauth(conn)` in this case.
 
 ## Auth-related configuration, OAuth consumer mode etc.