aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/API/admin_api.md347
-rw-r--r--docs/API/differences_in_mastoapi_responses.md21
-rw-r--r--docs/API/pleroma_api.md90
-rw-r--r--docs/administration/CLI_tasks/config.md39
-rw-r--r--docs/administration/CLI_tasks/database.md46
-rw-r--r--docs/administration/CLI_tasks/digest.md22
-rw-r--r--docs/administration/CLI_tasks/email.md24
-rw-r--r--docs/administration/CLI_tasks/emoji.md30
-rw-r--r--docs/administration/CLI_tasks/general_cli_task_info.include5
-rw-r--r--docs/administration/CLI_tasks/instance.md11
-rw-r--r--docs/administration/CLI_tasks/relay.md29
-rw-r--r--docs/administration/CLI_tasks/uploads.md11
-rw-r--r--docs/administration/CLI_tasks/user.md147
-rw-r--r--docs/administration/backup.md35
-rw-r--r--docs/administration/updating.md17
-rw-r--r--docs/clients.md7
-rw-r--r--docs/configuration/cheatsheet.md100
-rw-r--r--docs/configuration/howto_theming_your_instance.md74
-rw-r--r--docs/configuration/howto_user_recomendation.md31
-rw-r--r--docs/configuration/i2p.md2
-rw-r--r--docs/configuration/mrf.md45
-rw-r--r--docs/configuration/onion_federation.md2
-rw-r--r--docs/installation/centos7_en.md274
-rw-r--r--docs/installation/migrating_from_source_otp_en.md53
-rw-r--r--docs/installation/openbsd_en.md22
-rw-r--r--docs/installation/otp_en.md176
-rw-r--r--docs/introduction.md70
27 files changed, 937 insertions, 793 deletions
diff --git a/docs/API/admin_api.md b/docs/API/admin_api.md
index 2cac317de..47afdfba5 100644
--- a/docs/API/admin_api.md
+++ b/docs/API/admin_api.md
@@ -2,6 +2,13 @@
Authentication is required and the user must be an admin.
+Configuration options:
+
+* `[:auth, :enforce_oauth_admin_scope_usage]` — OAuth admin scope requirement toggle.
+ If `true`, admin actions explicitly demand admin OAuth scope(s) presence in OAuth token (client app must support admin scopes).
+ If `false` and token doesn't have admin scope(s), `is_admin` user flag grants access to admin-specific actions.
+ Note that client app needs to explicitly support admin scopes and request them when obtaining auth token.
+
## `GET /api/pleroma/admin/users`
### List users
@@ -253,6 +260,33 @@ Note: Available `:permission_group` is currently moderator and admin. 404 is ret
- `nickname` or `id`
- *optional* `page_size`: number of statuses to return (default is `20`)
- *optional* `godmode`: `true`/`false` – allows to see private statuses
+ - *optional* `with_reblogs`: `true`/`false` – allows to see reblogs (default is false)
+- Response:
+ - On failure: `Not found`
+ - On success: JSON array of user's latest statuses
+
+## `GET /api/pleroma/admin/instances/:instance/statuses`
+
+### Retrive instance's latest statuses
+
+- Params:
+ - `instance`: instance name
+ - *optional* `page_size`: number of statuses to return (default is `20`)
+ - *optional* `godmode`: `true`/`false` – allows to see private statuses
+ - *optional* `with_reblogs`: `true`/`false` – allows to see reblogs (default is false)
+- Response:
+ - On failure: `Not found`
+ - On success: JSON array of instance's latest statuses
+
+## `GET /api/pleroma/admin/statuses`
+
+### Retrives all latest statuses
+
+- Params:
+ - *optional* `page_size`: number of statuses to return (default is `20`)
+ - *optional* `local_only`: excludes remote statuses
+ - *optional* `godmode`: `true`/`false` – allows to see private statuses
+ - *optional* `with_reblogs`: `true`/`false` – allows to see reblogs (default is false)
- Response:
- On failure: `Not found`
- On success: JSON array of user's latest statuses
@@ -607,78 +641,29 @@ Note: Available `:permission_group` is currently moderator and admin. 404 is ret
- On success: `204`, empty response
-## `POST /api/pleroma/admin/reports/:id/respond`
+## `POST /api/pleroma/admin/reports/:id/notes`
-### Respond to a report
+### Create report note
- Params:
- - `id`
- - `status`: required, the message
+ - `id`: required, report id
+ - `content`: required, the message
- Response:
- On failure:
- 400 Bad Request `"Invalid parameters"` when `status` is missing
- - 403 Forbidden `{"error": "error_msg"}`
- - 404 Not Found `"Not found"`
- - On success: JSON, created Mastodon Status entity
+ - On success: `204`, empty response
-```json
-{
- "account": { ... },
- "application": {
- "name": "Web",
- "website": null
- },
- "bookmarked": false,
- "card": null,
- "content": "Your claim is going to be closed",
- "created_at": "2019-05-11T17:13:03.000Z",
- "emojis": [],
- "favourited": false,
- "favourites_count": 0,
- "id": "9ihuiSL1405I65TmEq",
- "in_reply_to_account_id": null,
- "in_reply_to_id": null,
- "language": null,
- "media_attachments": [],
- "mentions": [
- {
- "acct": "user",
- "id": "9i6dAJqSGSKMzLG2Lo",
- "url": "https://pleroma.example.org/users/user",
- "username": "user"
- },
- {
- "acct": "admin",
- "id": "9hEkA5JsvAdlSrocam",
- "url": "https://pleroma.example.org/users/admin",
- "username": "admin"
- }
- ],
- "muted": false,
- "pinned": false,
- "pleroma": {
- "content": {
- "text/plain": "Your claim is going to be closed"
- },
- "conversation_id": 35,
- "in_reply_to_account_acct": null,
- "local": true,
- "spoiler_text": {
- "text/plain": ""
- }
- },
- "reblog": null,
- "reblogged": false,
- "reblogs_count": 0,
- "replies_count": 0,
- "sensitive": false,
- "spoiler_text": "",
- "tags": [],
- "uri": "https://pleroma.example.org/objects/cab0836d-9814-46cd-a0ea-529da9db5fcb",
- "url": "https://pleroma.example.org/notice/9ihuiSL1405I65TmEq",
- "visibility": "direct"
-}
-```
+## `POST /api/pleroma/admin/reports/:report_id/notes/:id`
+
+### Delete report note
+
+- Params:
+ - `report_id`: required, report id
+ - `id`: required, note id
+- Response:
+ - On failure:
+ - 400 Bad Request `"Invalid parameters"` when `status` is missing
+ - On success: `204`, empty response
## `PUT /api/pleroma/admin/statuses/:id`
@@ -707,27 +692,14 @@ 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_to_db`
-
-### Run mix task pleroma.config migrate_to_db
-
-Copy settings on key `:pleroma` to DB.
+## `GET /api/pleroma/admin/restart`
-- Params: none
-- Response:
-
-```json
-{}
-```
-
-## `GET /api/pleroma/admin/config/migrate_from_db`
-
-### Run mix task pleroma.config migrate_from_db
-
-Copy all settings from DB to `config/prod.exported_from_db.secret.exs` with deletion from DB.
+### Restarts pleroma application
- Params: none
- Response:
+ - On failure:
+ - 400 Bad Request `"To use this endpoint you need to enable configuration from database."`
```json
{}
@@ -735,67 +707,139 @@ Copy all settings from DB to `config/prod.exported_from_db.secret.exs` with dele
## `GET /api/pleroma/admin/config`
-### List config settings
+### Get list of merged default settings with saved in database.
-List config settings only works with `:pleroma => :instance => :dynamic_configuration` setting to `true`.
+*If `need_reboot` flag exists in response, instance must be restarted, so reboot time settings can take effect.*
-- Params: none
+**Only works when configuration from database is enabled.**
+
+- Params:
+ - `only_db`: true (*optional*, get only saved in database settings)
- Response:
+ - On failure:
+ - 400 Bad Request `"To use this endpoint you need to enable configuration from database."`
```json
{
- configs: [
+ "configs": [
{
- "group": string,
- "key": string or string with leading `:` for atoms,
- "value": string or {} or [] or {"tuple": []}
+ "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
-Updating config settings only works with `:pleroma => :instance => :dynamic_configuration` setting to `true`.
-Module name can be passed as string, which starts with `Pleroma`, e.g. `"Pleroma.Upload"`.
-Atom keys and values can be passed with `:` in the beginning, e.g. `":upload"`.
-Tuples can be passed as `{"tuple": ["first_val", Pleroma.Module, []]}`.
-`{"tuple": ["some_string", "Pleroma.Some.Module", []]}` will be converted to `{"some_string", Pleroma.Some.Module, []}`.
-Keywords can be passed as lists with 2 child tuples, e.g.
-`[{"tuple": ["first_val", Pleroma.Module]}, {"tuple": ["second_val", true]}]`.
+*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.**
-If value contains list of settings `[subkey: val1, subkey2: val2, subkey3: val3]`, it's possible to remove only subkeys instead of all settings passing `subkeys` parameter. E.g.:
-{"group": "pleroma", "key": "some_key", "delete": "true", "subkeys": [":subkey", ":subkey3"]}.
+Some modifications are necessary to save the config settings correctly:
-Compile time settings (need instance reboot):
-- all settings by this keys:
+- strings which start with `Pleroma.`, `Phoenix.`, `Tesla.` or strings like `Oban`, `Ueberauth` will be converted to modules;
+```
+"Pleroma.Upload" -> Pleroma.Upload
+"Oban" -> Oban
+```
+- strings starting with `:` will be converted to atoms;
+```
+":pleroma" -> :pleroma
+```
+- objects with `tuple` key and array value will be converted to tuples;
+```
+{"tuple": ["string", "Pleroma.Upload", []]} -> {"string", Pleroma.Upload, []}
+```
+- arrays with *tuple objects* will be converted to keywords;
+```
+[{"tuple": [":key1", "value"]}, {"tuple": [":key2", "value"]}] -> [key1: "value", key2: "value"]
+```
+
+Most of the settings will be applied in `runtime`, this means that you don't need to restart the instance. But some settings are applied in `compile time` and require a reboot of the instance, such as:
+- all settings inside these keys:
- `:hackney_pools`
- `:chat`
- - `Pleroma.Web.Endpoint`
- - `Pleroma.Repo`
-- part settings:
- - `Pleroma.Captcha` -> `:seconds_valid`
- - `Pleroma.Upload` -> `:proxy_remote`
- - `:instance` -> `:upload_limit`
-
-- Params:
- - `configs` => [
- - `group` (string)
- - `key` (string or string with leading `:` for atoms)
- - `value` (string, [], {} or {"tuple": []})
- - `delete` = true (optional, if parameter must be deleted)
- - `subkeys` [(string with leading `:` for atoms)] (optional, works only if `delete=true` parameter is passed, otherwise will be ignored)
+- partially settings inside these keys:
+ - `:seconds_valid` in `Pleroma.Captcha`
+ - `:proxy_remote` in `Pleroma.Upload`
+ - `:upload_limit` in `:instance`
+
+- Params:
+ - `configs` - array of config objects
+ - config object params:
+ - `group` - string (**required**)
+ - `key` - string (**required**)
+ - `value` - string, [], {} or {"tuple": []} (**required**)
+ - `delete` - true (*optional*, if setting must be deleted)
+ - `subkeys` - array of strings (*optional*, only works when `delete=true` parameter is passed, otherwise will be ignored)
+
+*When a value have several nested settings, you can delete only some nested settings by passing a parameter `subkeys`, without deleting all settings by key.*
+```
+[subkey: val1, subkey2: val2, subkey3: val3] \\ initial value
+{"group": ":pleroma", "key": "some_key", "delete": true, "subkeys": [":subkey", ":subkey3"]} \\ passing json for deletion
+[subkey2: val2] \\ value after deletion
+```
+
+*Most of the settings can be partially updated through merge old values with new values, except settings value of which is list or is not keyword.*
+
+Example of setting without keyword in value:
+```elixir
+config :tesla, :adapter, Tesla.Adapter.Hackney
+```
+
+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},
+ {:swarm, :node_blacklist},
+ {:logger, :backends}
]
+```
-- Request (example):
+List of settings which support only full update by subkey:
+```elixir
+@full_subkey_update [
+ {:pleroma, :assets, :mascots},
+ {:pleroma, :emoji, :groups},
+ {:pleroma, :workers, :retries},
+ {:pleroma, :mrf_subchain, :match_actor},
+ {:pleroma, :mrf_keyword, :replace}
+ ]
+```
+*Settings without explicit key must be sended in separate config object params.*
+```elixir
+config :quack,
+ level: :debug,
+ meta: [:all],
+ ...
+```
```json
{
- configs: [
+ "configs": [
+ {"group": ":quack", "key": ":level", "value": ":debug"},
+ {"group": ":quack", "key": ":meta", "value": [":all"]},
+ ...
+ ]
+}
+```
+- Request:
+
+```json
+{
+ "configs": [
{
- "group": "pleroma",
+ "group": ":pleroma",
"key": "Pleroma.Upload",
"value": [
{"tuple": [":uploader", "Pleroma.Uploaders.Local"]},
@@ -805,7 +849,7 @@ Compile time settings (need instance reboot):
{"tuple": [":proxy_opts", [
{"tuple": [":redirect_on_failure", false]},
{"tuple": [":max_body_length", 1048576]},
- {"tuple": [":http": [
+ {"tuple": [":http", [
{"tuple": [":follow_redirect", true]},
{"tuple": [":pool", ":upload"]},
]]}
@@ -821,18 +865,54 @@ Compile time settings (need instance reboot):
```
- Response:
-
+ - On failure:
+ - 400 Bad Request `"To use this endpoint you need to enable configuration from database."`
```json
{
- configs: [
+ "configs": [
{
- "group": string,
- "key": string or string with leading `:` for atoms,
- "value": string or {} or [] or {"tuple": []}
+ "group": ":pleroma",
+ "key": "Pleroma.Upload",
+ "value": [...]
}
- ]
+ ],
+ "need_reboot": true
}
```
+need_reboot - *optional*, if were changed reboot time settings.
+
+## ` GET /api/pleroma/admin/config/descriptions`
+
+### Get JSON with config descriptions.
+Loads json generated from `config/descriptions.exs`.
+
+- Params: none
+- Response:
+
+```json
+[{
+ "group": ":pleroma", // string
+ "key": "ModuleName", // string
+ "type": "group", // string or list with possible values,
+ "description": "Upload general settings", // string
+ "children": [
+ {
+ "key": ":uploader", // string or module name `Pleroma.Upload`
+ "type": "module",
+ "description": "Module which will be used for uploads",
+ "suggestions": ["module1", "module2"]
+ },
+ {
+ "key": ":filters",
+ "type": ["list", "module"],
+ "description": "List of filter modules for uploads",
+ "suggestions": [
+ "module1", "module2", "module3"
+ ]
+ }
+ ]
+}]
+```
## `GET /api/pleroma/admin/moderation_log`
@@ -886,3 +966,20 @@ Compile time settings (need instance reboot):
- Params:
- `nicknames`
- Response: Array of user nicknames
+
+## `GET /api/pleroma/admin/stats`
+
+### Stats
+
+- Response:
+
+```json
+{
+ "status_visibility": {
+ "direct": 739,
+ "private": 9,
+ "public": 17,
+ "unlisted": 14
+ }
+}
+```
diff --git a/docs/API/differences_in_mastoapi_responses.md b/docs/API/differences_in_mastoapi_responses.md
index 006d17c1b..476a4a2bf 100644
--- a/docs/API/differences_in_mastoapi_responses.md
+++ b/docs/API/differences_in_mastoapi_responses.md
@@ -29,6 +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 `{name: "☕", count: 1, me: true}`. Contains no information about the reacting users, for that use the `/statuses/:id/reactions` endpoint.
## Attachments
@@ -46,7 +47,7 @@ The `id` parameter can also be the `nickname` of the user. This only works in th
Has these additional fields under the `pleroma` object:
- `tags`: Lists an array of tags for the user
-- `relationship{}`: Includes fields as documented for Mastodon API https://docs.joinmastodon.org/api/entities/#relationship
+- `relationship{}`: Includes fields as documented for Mastodon API https://docs.joinmastodon.org/entities/relationship/
- `is_moderator`: boolean, nullable, true if user is a moderator
- `is_admin`: boolean, nullable, true if user is an admin
- `confirmation_pending`: boolean, true if a new user account is waiting on email confirmation to be activated
@@ -66,6 +67,8 @@ Has these additional fields under the `pleroma` object:
- `show_role`: boolean, nullable, true when the user wants his role (e.g admin, moderator) to be shown
- `no_rich_text` - boolean, nullable, true when html tags are stripped from all statuses requested from the API
+- `discoverable`: boolean, true when the user allows discovery of the account in search results and other services.
+- `actor_type`: string, the type of this account.
## Conversations
@@ -85,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
@@ -98,11 +104,20 @@ The `type` value is `move`. Has an additional field:
- `target`: new account
+### EmojiReact Notification
+
+The `type` value is `pleroma:emoji_reaction`. Has these fields:
+
+- `emoji`: The used emoji
+- `account`: The account of the user who reacted
+- `status`: The status that was reacted on
+
## GET `/api/v1/notifications`
Accepts additional parameters:
- `exclude_visibilities`: will exclude the notifications for activities with the given visibilities. The parameter accepts an array of visibility types (`public`, `unlisted`, `private`, `direct`). Usage example: `GET /api/v1/notifications?exclude_visibilities[]=direct&exclude_visibilities[]=private`.
+- `with_move`: boolean, when set to `true` will include Move notifications. `false` by default.
## POST `/api/v1/statuses`
@@ -145,6 +160,8 @@ Additional parameters can be added to the JSON body/Form data:
- `skip_thread_containment` - if true, skip filtering out broken threads
- `allow_following_move` - if true, allows automatically follow moved following accounts
- `pleroma_background_image` - sets the background image of the user.
+- `discoverable` - if true, discovery of this account in search results and other services is allowed.
+- `actor_type` - the type of this account.
### Pleroma Settings Store
Pleroma has mechanism that allows frontends to save blobs of json for each user on the backend. This can be used to save frontend-specific settings for a user that the backend does not need to know about.
@@ -163,7 +180,7 @@ Post here request with grant_type=refresh_token to obtain new access token. Retu
## Account Registration
`POST /api/v1/accounts`
-Has theses additionnal parameters (which are the same as in Pleroma-API):
+Has theses additional parameters (which are the same as in Pleroma-API):
* `fullname`: optional
* `bio`: optional
* `captcha_solution`: optional, contains provider-specific captcha solution,
diff --git a/docs/API/pleroma_api.md b/docs/API/pleroma_api.md
index ad16d027e..12e63ef9f 100644
--- a/docs/API/pleroma_api.md
+++ b/docs/API/pleroma_api.md
@@ -70,59 +70,6 @@ Request parameters can be passed via [query strings](https://en.wikipedia.org/wi
* Response: JSON. Returns `{"status": "success"}` if the account was successfully disabled, `{"error": "[error message]"}` otherwise
* Example response: `{"error": "Invalid password."}`
-## `/api/account/register`
-### Register a new user
-* Method `POST`
-* Authentication: not required
-* Params:
- * `nickname`
- * `fullname`
- * `bio`
- * `email`
- * `password`
- * `confirm`
- * `captcha_solution`: optional, contains provider-specific captcha solution,
- * `captcha_token`: optional, contains provider-specific captcha token
- * `token`: invite token required when the registrations aren't public.
-* Response: JSON. Returns a user object on success, otherwise returns `{"error": "error_msg"}`
-* Example response:
-```json
-{
- "background_image": null,
- "cover_photo": "https://pleroma.soykaf.com/images/banner.png",
- "created_at": "Tue Dec 18 16:55:56 +0000 2018",
- "default_scope": "public",
- "description": "blushy-crushy fediverse idol + pleroma dev\nlet's be friends \nぷれろまの生徒会長。謎の外人。日本語OK. \n公主病.",
- "description_html": "blushy-crushy fediverse idol + pleroma dev.<br />let's be friends <br />ぷれろまの生徒会長。謎の外人。日本語OK. <br />公主病.",
- "favourites_count": 0,
- "fields": [],
- "followers_count": 0,
- "following": false,
- "follows_you": false,
- "friends_count": 0,
- "id": 6,
- "is_local": true,
- "locked": false,
- "name": "lain",
- "name_html": "lain",
- "no_rich_text": false,
- "pleroma": {
- "tags": []
- },
- "profile_image_url": "https://pleroma.soykaf.com/images/avi.png",
- "profile_image_url_https": "https://pleroma.soykaf.com/images/avi.png",
- "profile_image_url_original": "https://pleroma.soykaf.com/images/avi.png",
- "profile_image_url_profile_size": "https://pleroma.soykaf.com/images/avi.png",
- "rights": {
- "delete_others_notice": false
- },
- "screen_name": "lain",
- "statuses_count": 0,
- "statusnet_blocking": false,
- "statusnet_profile_url": "https://pleroma.soykaf.com/users/lain"
-}
-```
-
## `/api/pleroma/admin/`…
See [Admin-API](admin_api.md)
@@ -302,6 +249,7 @@ See [Admin-API](admin_api.md)
* `follows`: BOOLEAN field, receives notifications from people the user follows
* `remote`: BOOLEAN field, receives notifications from people on remote instances
* `local`: BOOLEAN field, receives notifications from people on the local instance
+ * `privacy_option`: BOOLEAN field. When set to true, it removes the contents of a message from the push notification.
* Response: JSON. Returns `{"status": "success"}` if the update was successful, otherwise returns `{"error": "error_msg"}`
## `/api/pleroma/healthcheck`
@@ -340,10 +288,11 @@ Pleroma Conversations have the same general structure that Mastodon Conversation
2. Pleroma Conversations statuses can be requested by Conversation id.
3. Pleroma Conversations can be replied to.
-Conversations have the additional field "recipients" under the "pleroma" key. This holds a list of all the accounts that will receive a message in this conversation.
+Conversations have the additional field `recipients` under the `pleroma` key. This holds a list of all the accounts that will receive a message in this conversation.
The status posting endpoint takes an additional parameter, `in_reply_to_conversation_id`, which, when set, will set the visiblity to direct and address only the people who are the recipients of that Conversation.
+⚠ Conversation IDs can be found in direct messages with the `pleroma.direct_conversation_id` key, do not confuse it with `pleroma.conversation_id`.
## `GET /api/v1/pleroma/conversations/:id/statuses`
### Timeline for a given conversation
@@ -484,30 +433,43 @@ 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
* Params: None
-* Response: JSON, a map of emoji to account list mappings.
+* Response: JSON, a list of emoji/account list tuples, sorted by emoji insertion date, in ascending order, e.g, the first emoji in the list is the oldest.
* Example Response:
```json
-{
- "😀" => [{"id" => "xyz.."...}, {"id" => "zyx..."}],
- "🗡" => [{"id" => "abc..."}]
-}
+[
+ {"name": "😀", "count": 2, "me": true, "accounts": [{"id" => "xyz.."...}, {"id" => "zyx..."}]},
+ {"name": "☕", "count": 1, "me": false, "accounts": [{"id" => "abc..."}]}
+]
+```
+
+## `GET /api/v1/pleroma/statuses/:id/reactions/:emoji`
+### Get an object of emoji to account mappings with accounts that reacted to the post for a specific emoji`
+* Method: `GET`
+* Authentication: optional
+* Params: None
+* Response: JSON, a list of emoji/account list tuples
+* Example Response:
+```json
+[
+ {"name": "😀", "count": 2, "me": true, "accounts": [{"id" => "xyz.."...}, {"id" => "zyx..."}]}
+]
```
diff --git a/docs/administration/CLI_tasks/config.md b/docs/administration/CLI_tasks/config.md
index ce19e2402..cc32bf859 100644
--- a/docs/administration/CLI_tasks/config.md
+++ b/docs/administration/CLI_tasks/config.md
@@ -1,19 +1,40 @@
# Transfering the config to/from the database
-!!! danger
- This is a Work In Progress, not usable just yet.
-
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl config` and in case of source installs it's
-`mix pleroma.config`.
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
## Transfer config from file to DB.
-```sh
-$PREFIX migrate_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
```
+```sh tab="From Source"
+mix pleroma.config migrate_to_db
+```
+
+
## Transfer config from DB to `config/env.exported_from_db.secret.exs`
-```sh
-$PREFIX migrate_from_db <env>
+!!! 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]
+```
+
+```sh tab="From Source"
+mix pleroma.config migrate_from_db [--env=<env>] [-d]
```
diff --git a/docs/administration/CLI_tasks/database.md b/docs/administration/CLI_tasks/database.md
index 3011646c8..ff400c8ed 100644
--- a/docs/administration/CLI_tasks/database.md
+++ b/docs/administration/CLI_tasks/database.md
@@ -1,6 +1,6 @@
# Database maintenance tasks
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl database` and in case of source installs it's `mix pleroma.database`.
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
!!! danger
These mix tasks can take a long time to complete. Many of them were written to address specific database issues that happened because of bugs in migrations or other specific scenarios. Do not run these tasks "just in case" if everything is fine your instance.
@@ -9,8 +9,12 @@ Every command should be ran with a prefix, in case of OTP releases it is `./bin/
Replaces embedded objects with references to them in the `objects` table. Only needs to be ran once if the instance was created before Pleroma 1.0.5. The reason why this is not a migration is because it could significantly increase the database size after being ran, however after this `VACUUM FULL` will be able to reclaim about 20% (really depends on what is in the database, your mileage may vary) of the db size before the migration.
-```sh
-$PREFIX remove_embedded_objects [<options>]
+```sh tab="OTP"
+./bin/pleroma_ctl database remove_embedded_objects [option ...]
+```
+
+```sh tab="From Source"
+mix pleroma.database remove_embedded_objects [option ...]
```
### Options
@@ -20,11 +24,15 @@ $PREFIX remove_embedded_objects [<options>]
This will prune remote posts older than 90 days (configurable with [`config :pleroma, :instance, remote_post_retention_days`](../../configuration/cheatsheet.md#instance)) from the database, they will be refetched from source when accessed.
-!!! note
- The disk space will only be reclaimed after `VACUUM FULL`
+!!! danger
+ The disk space will only be reclaimed after `VACUUM FULL`. You may run out of disk space during the execution of the task or vacuuming if you don't have about 1/3rds of the database size free.
+
+```sh tab="OTP"
+./bin/pleroma_ctl database prune_objects [option ...]
+```
-```sh
-$PREFIX pleroma.database prune_objects [<options>]
+```sh tab="From Source"
+mix pleroma.database prune_objects [option ...]
```
### Options
@@ -34,18 +42,30 @@ $PREFIX pleroma.database prune_objects [<options>]
Can be safely re-run
-```sh
-$PREFIX bump_all_conversations
+```sh tab="OTP"
+./bin/pleroma_ctl database bump_all_conversations
+```
+
+```sh tab="From Source"
+mix pleroma.database bump_all_conversations
```
## Remove duplicated items from following and update followers count for all users
-```sh
-$PREFIX update_users_following_followers_counts
+```sh tab="OTP"
+./bin/pleroma_ctl database update_users_following_followers_counts
+```
+
+```sh tab="From Source"
+mix pleroma.database update_users_following_followers_counts
```
## Fix the pre-existing "likes" collections for all objects
-```sh
-$PREFIX fix_likes_collections
+```sh tab="OTP"
+./bin/pleroma_ctl database fix_likes_collections
+```
+
+```sh tab="From Source"
+mix pleroma.database fix_likes_collections
```
diff --git a/docs/administration/CLI_tasks/digest.md b/docs/administration/CLI_tasks/digest.md
index 547702031..2eb31379e 100644
--- a/docs/administration/CLI_tasks/digest.md
+++ b/docs/administration/CLI_tasks/digest.md
@@ -1,13 +1,25 @@
# Managing digest emails
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl digest` and in case of source installs it's `mix pleroma.digest`.
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
## Send digest email since given date (user registration date by default) ignoring user activity status.
-```sh
-$PREFIX test <nickname> [<since_date>]
+```sh tab="OTP"
+ ./bin/pleroma_ctl digest test <nickname> [since_date]
+```
+
+```sh tab="From Source"
+mix pleroma.digest test <nickname> [since_date]
```
+
Example:
-```sh
-$PREFIX test donaldtheduck 2019-05-20
+
+```sh tab="OTP"
+./bin/pleroma_ctl digest test donaldtheduck 2019-05-20
+```
+
+```sh tab="From Source"
+mix pleroma.digest test donaldtheduck 2019-05-20
```
+
diff --git a/docs/administration/CLI_tasks/email.md b/docs/administration/CLI_tasks/email.md
new file mode 100644
index 000000000..7b7a8457a
--- /dev/null
+++ b/docs/administration/CLI_tasks/email.md
@@ -0,0 +1,24 @@
+# Managing emails
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Send test email (instance email by default)
+
+```sh tab="OTP"
+ ./bin/pleroma_ctl email test [--to <destination email address>]
+```
+
+```sh tab="From Source"
+mix pleroma.email test [--to <destination email address>]
+```
+
+
+Example:
+
+```sh tab="OTP"
+./bin/pleroma_ctl email test --to root@example.org
+```
+
+```sh tab="From Source"
+mix pleroma.email test --to root@example.org
+```
diff --git a/docs/administration/CLI_tasks/emoji.md b/docs/administration/CLI_tasks/emoji.md
index eee02f2ef..efec8222c 100644
--- a/docs/administration/CLI_tasks/emoji.md
+++ b/docs/administration/CLI_tasks/emoji.md
@@ -1,28 +1,44 @@
# Managing emoji packs
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl emoji` and in case of source installs it's `mix pleroma.emoji`.
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
## Lists emoji packs and metadata specified in the manifest
-```sh
-$PREFIX ls-packs [<options>]
+```sh tab="OTP"
+./bin/pleroma_ctl emoji ls-packs [option ...]
```
+```sh tab="From Source"
+mix pleroma.emoji ls-packs [option ...]
+```
+
+
### Options
- `-m, --manifest PATH/URL` - path to a custom manifest, it can either be an URL starting with `http`, in that case the manifest will be fetched from that address, or a local path
## Fetch, verify and install the specified packs from the manifest into `STATIC-DIR/emoji/PACK-NAME`
-```sh
-$PREFIX get-packs [<options>] <packs>
+
+```sh tab="OTP"
+./bin/pleroma_ctl emoji get-packs [option ...] <pack ...>
+```
+
+```sh tab="From Source"
+mix pleroma.emoji get-packs [option ...] <pack ...>
```
### Options
- `-m, --manifest PATH/URL` - same as [`ls-packs`](#ls-packs)
## Create a new manifest entry and a file list from the specified remote pack file
-```sh
-$PREFIX gen-pack PACK-URL
+
+```sh tab="OTP"
+./bin/pleroma_ctl emoji gen-pack PACK-URL
```
+
+```sh tab="From Source"
+mix pleroma.emoji gen-pack PACK-URL
+```
+
Currently, only .zip archives are recognized as remote pack files and packs are therefore assumed to be zip archives. This command is intended to run interactively and will first ask you some basic questions about the pack, then download the remote file and generate an SHA256 checksum for it, then generate an emoji file list for you.
The manifest entry will either be written to a newly created `index.json` file or appended to the existing one, *replacing* the old pack with the same name if it was in the file previously.
diff --git a/docs/administration/CLI_tasks/general_cli_task_info.include b/docs/administration/CLI_tasks/general_cli_task_info.include
new file mode 100644
index 000000000..a1ff1da12
--- /dev/null
+++ b/docs/administration/CLI_tasks/general_cli_task_info.include
@@ -0,0 +1,5 @@
+Every command should be ran as the `pleroma` user from it's home directory. For example if you are superuser, you would have to wrap the command in `su pleroma -s $SHELL -lc "$COMMAND"`.
+
+??? note "From source note about `MIX_ENV`"
+
+ The `mix` command should be prefixed with the name of environment your Pleroma server is running in, usually it's `MIX_ENV=prod`
diff --git a/docs/administration/CLI_tasks/instance.md b/docs/administration/CLI_tasks/instance.md
index ab0b68ad0..52e264bb1 100644
--- a/docs/administration/CLI_tasks/instance.md
+++ b/docs/administration/CLI_tasks/instance.md
@@ -1,12 +1,17 @@
# Managing instance configuration
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl instance` and in case of source installs it's `mix pleroma.instance`.
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
## Generate a new configuration file
-```sh
-$PREFIX gen [<options>]
+```sh tab="OTP"
+ ./bin/pleroma_ctl instance gen [option ...]
```
+```sh tab="From Source"
+mix pleroma.instance gen [option ...]
+```
+
+
If any of the options are left unspecified, you will be prompted interactively.
### Options
diff --git a/docs/administration/CLI_tasks/relay.md b/docs/administration/CLI_tasks/relay.md
index aa44617df..c4f078f4d 100644
--- a/docs/administration/CLI_tasks/relay.md
+++ b/docs/administration/CLI_tasks/relay.md
@@ -1,30 +1,33 @@
# Managing relays
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl relay` and in case of source installs it's `mix pleroma.relay`.
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
## Follow a relay
-```sh
-$PREFIX follow <relay_url>
+
+```sh tab="OTP"
+./bin/pleroma_ctl relay follow <relay_url>
```
-Example:
-```sh
-$PREFIX follow https://example.org/relay
+```sh tab="From Source"
+mix pleroma.relay follow <relay_url>
```
## Unfollow a remote relay
-```sh
-$PREFIX unfollow <relay_url>
+```sh tab="OTP"
+./bin/pleroma_ctl relay unfollow <relay_url>
```
-Example:
-```sh
-$PREFIX unfollow https://example.org/relay
+```sh tab="From Source"
+mix pleroma.relay unfollow <relay_url>
```
## List relay subscriptions
-```sh
-$PREFIX list
+```sh tab="OTP"
+./bin/pleroma_ctl relay list
+```
+
+```sh tab="From Source"
+mix pleroma.relay list
```
diff --git a/docs/administration/CLI_tasks/uploads.md b/docs/administration/CLI_tasks/uploads.md
index 71800e341..6a15d22f6 100644
--- a/docs/administration/CLI_tasks/uploads.md
+++ b/docs/administration/CLI_tasks/uploads.md
@@ -1,11 +1,16 @@
# Managing uploads
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl uploads` and in case of source installs it's `mix pleroma.uploads`.
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
## Migrate uploads from local to remote storage
-```sh
-$PREFIX migrate_local <target_uploader> [<options>]
+```sh tab="OTP"
+ ./bin/pleroma_ctl uploads migrate_local <target_uploader> [option ...]
```
+
+```sh tab="From Source"
+mix pleroma.uploads migrate_local <target_uploader> [option ...]
+```
+
### Options
- `--delete` - delete local uploads after migrating them to the target uploader
diff --git a/docs/administration/CLI_tasks/user.md b/docs/administration/CLI_tasks/user.md
index 96b2d9e6a..f535dad82 100644
--- a/docs/administration/CLI_tasks/user.md
+++ b/docs/administration/CLI_tasks/user.md
@@ -1,12 +1,18 @@
# Managing users
-Every command should be ran with a prefix, in case of OTP releases it is `./bin/pleroma_ctl user` and in case of source installs it's `mix pleroma.user`.
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
## Create a user
-```sh
-$PREFIX new <nickname> <email> [<options>]
+
+```sh tab="OTP"
+./bin/pleroma_ctl user new <nickname> <email> [option ...]
+```
+
+```sh tab="From Source"
+mix pleroma.user new <nickname> <email> [option ...]
```
+
### Options
- `--name <name>` - the user's display name
- `--bio <bio>` - the user's bio
@@ -16,84 +22,159 @@ $PREFIX new <nickname> <email> [<options>]
- `-y`, `--assume-yes`/`--no-assume-yes` - whether to assume yes to all questions
## List local users
-```sh
-$PREFIX list
+```sh tab="OTP"
+ ./bin/pleroma_ctl user list
```
+```sh tab="From Source"
+mix pleroma.user list
+```
+
+
## Generate an invite link
-```sh
-$PREFIX invite [<options>]
+```sh tab="OTP"
+ ./bin/pleroma_ctl user invite [option ...]
```
+```sh tab="From Source"
+mix pleroma.user invite [option ...]
+```
+
+
### Options
- `--expires-at DATE` - last day on which token is active (e.g. "2019-04-05")
- `--max-use NUMBER` - maximum numbers of token uses
## List generated invites
-```sh
-$PREFIX invites
+```sh tab="OTP"
+ ./bin/pleroma_ctl user invites
```
+```sh tab="From Source"
+mix pleroma.user invites
+```
+
+
## Revoke invite
-```sh
-$PREFIX revoke_invite <token_or_id>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user revoke_invite <token_or_id>
```
+```sh tab="From Source"
+mix pleroma.user revoke_invite <token_or_id>
+```
+
+
## Delete a user
-```sh
-$PREFIX rm <nickname>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user rm <nickname>
```
+```sh tab="From Source"
+mix pleroma.user rm <nickname>
+```
+
+
## Delete user's posts and interactions
-```sh
-$PREFIX delete_activities <nickname>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user delete_activities <nickname>
```
+```sh tab="From Source"
+mix pleroma.user delete_activities <nickname>
+```
+
+
## Sign user out from all applications (delete user's OAuth tokens and authorizations)
-```sh
-$PREFIX sign_out <nickname>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user sign_out <nickname>
```
+```sh tab="From Source"
+mix pleroma.user sign_out <nickname>
+```
+
+
## Deactivate or activate a user
-```sh
-$PREFIX toggle_activated <nickname>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user toggle_activated <nickname>
```
+```sh tab="From Source"
+mix pleroma.user toggle_activated <nickname>
+```
+
+
## Unsubscribe local users from a user and deactivate the user
-```sh
-$PREFIX unsubscribe NICKNAME
+```sh tab="OTP"
+ ./bin/pleroma_ctl user unsubscribe NICKNAME
```
+```sh tab="From Source"
+mix pleroma.user unsubscribe NICKNAME
+```
+
+
## Unsubscribe local users from an instance and deactivate all accounts on it
-```sh
-$PREFIX unsubscribe_all_from_instance <instance>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user unsubscribe_all_from_instance <instance>
```
+```sh tab="From Source"
+mix pleroma.user unsubscribe_all_from_instance <instance>
+```
+
+
## Create a password reset link for user
-```sh
-$PREFIX reset_password <nickname>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user reset_password <nickname>
```
+```sh tab="From Source"
+mix pleroma.user reset_password <nickname>
+```
+
+
## Set the value of the given user's settings
-```sh
-$PREFIX set <nickname> [<options>]
+```sh tab="OTP"
+ ./bin/pleroma_ctl user set <nickname> [option ...]
```
+
+```sh tab="From Source"
+mix pleroma.user set <nickname> [option ...]
+```
+
### Options
- `--locked`/`--no-locked` - whether the user should be locked
- `--moderator`/`--no-moderator` - whether the user should be a moderator
- `--admin`/`--no-admin` - whether the user should be an admin
## Add tags to a user
-```sh
-$PREFIX tag <nickname> <tags>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user tag <nickname> <tags>
```
+```sh tab="From Source"
+mix pleroma.user tag <nickname> <tags>
+```
+
+
## Delete tags from a user
-```sh
-$PREFIX untag <nickname> <tags>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user untag <nickname> <tags>
```
+```sh tab="From Source"
+mix pleroma.user untag <nickname> <tags>
+```
+
+
## Toggle confirmation status of the user
-```sh
-$PREFIX toggle_confirmed <nickname>
+```sh tab="OTP"
+ ./bin/pleroma_ctl user toggle_confirmed <nickname>
```
+
+```sh tab="From Source"
+mix pleroma.user toggle_confirmed <nickname>
+```
+
diff --git a/docs/administration/backup.md b/docs/administration/backup.md
index 2c70e7bf8..be57bf74a 100644
--- a/docs/administration/backup.md
+++ b/docs/administration/backup.md
@@ -1,17 +1,36 @@
-# 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.
+9. Run `sudo -Hu postgres vacuumdb --all --analyze-in-stages`. This will quickly generate the statistics so that postgres can properly plan queries.
+
+[^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..1eae0f0c6 100644
--- a/docs/clients.md
+++ b/docs/clients.md
@@ -1,5 +1,5 @@
# Pleroma Clients
-Note: Additionnal clients may be working but theses are officially supporting Pleroma.
+Note: Additional clients may be working but theses are officially supporting Pleroma.
Feel free to contact us to be added to this list!
## Desktop
@@ -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 dc2f55229..2629385da 100644
--- a/docs/configuration/cheatsheet.md
+++ b/docs/configuration/cheatsheet.md
@@ -2,9 +2,11 @@
This is a cheat sheet for Pleroma configuration file, any setting possible to configure should be listed here.
-Pleroma configuration works by first importing the base config (`config/config.exs` on source installs, compiled-in on OTP releases), then overriding it by the environment config (`config/$MIX_ENV.exs` on source installs, N/A to OTP releases) and then overriding it by user config (`config/$MIX_ENV.secret.exs` on source installs, typically `/etc/pleroma/config.exs` on OTP releases).
+For OTP installations the configuration is typically stored in `/etc/pleroma/config.exs`.
-You shouldn't edit the base config directly to avoid breakages and merge conflicts, but it can be used as a reference if you don't understand how an option is supposed to be formatted, the latest version of it can be viewed [here](https://git.pleroma.social/pleroma/pleroma/blob/develop/config/config.exs).
+For from source installations Pleroma configuration works by first importing the base config `config/config.exs`, then overriding it by the environment config `config/$MIX_ENV.exs` and then overriding it by user config `config/$MIX_ENV.secret.exs`. In from source installations you should always make the changes to the user config and NEVER to the base config to avoid breakages and merge conflicts. So for production you change/add configuration to `config/prod.secret.exs`.
+
+To add configuration to your config file, you can copy it from the base config. The latest version of it can be viewed [here](https://git.pleroma.social/pleroma/pleroma/blob/develop/config/config.exs). You can also use this file if you don't know how an option is supposed to be formatted.
## :instance
* `name`: The instance’s name.
@@ -12,6 +14,7 @@ You shouldn't edit the base config directly to avoid breakages and merge conflic
* `notify_email`: Email used for notifications.
* `description`: The instance’s description, can be seen in nodeinfo and ``/api/v1/instance``.
* `limit`: Posts character limit (CW/Subject included in the counter).
+* `chat_limit`: Character limit of the instance chat messages.
* `remote_limit`: Hard character limit beyond which remote posts will be dropped.
* `upload_limit`: File size limit of uploads (except for avatar, background, banner).
* `avatar_upload_limit`: File size limit of user’s profile avatars.
@@ -68,11 +71,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.
-
-!!! danger
- This is a Work In Progress, not usable just yet
-
-* `dynamic_configuration`: Allow transferring configuration to DB with the subsequent customization from Admin api.
+* `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
@@ -146,14 +145,11 @@ config :pleroma, :mrf_user_allowlist,
* `:reject` rejects the message entirely
### :activitypub
-* ``unfollow_blocked``: Whether blocks result in people getting unfollowed
-* ``outgoing_blocks``: Whether to federate blocks to other instances
-* ``deny_follow_blocked``: Whether to disallow following an account that has blocked the user in question
-* ``sign_object_fetches``: Sign object fetches with HTTP signatures
-
-### :fetch_initial_posts
-* `enabled`: if enabled, when a new user is federated with, fetch some of their latest posts
-* `pages`: the amount of pages to fetch
+* `unfollow_blocked`: Whether blocks result in people getting unfollowed
+* `outgoing_blocks`: Whether to federate blocks to other instances
+* `deny_follow_blocked`: Whether to disallow following an account that has blocked the user in question
+* `sign_object_fetches`: Sign object fetches with HTTP signatures
+* `authorized_fetch_mode`: Require HTTP signatures for AP fetches
## Pleroma.ScheduledActivity
@@ -312,16 +308,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:
@@ -330,14 +325,32 @@ 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.
+* `:timeline` - Timeline requests (each timeline has it's own limiter).
+* `: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
@@ -354,7 +367,7 @@ Available caches:
* `proxy_url`: an upstream proxy to fetch posts and/or media with, (default: `nil`)
* `send_user_agent`: should we include a user agent with HTTP requests? (default: `true`)
-* `user_agent`: what user agent should we use? (default: `:default`), must be string or `:default`
+* `user_agent`: what user agent should we use? (default: `:default`), must be string or `:default`
* `adapter`: array of hackney options
@@ -378,13 +391,19 @@ For each pool, the options are:
## Captcha
### Pleroma.Captcha
+
* `enabled`: Whether the captcha should be shown on registration.
* `method`: The method/service to use for captcha.
* `seconds_valid`: The time in seconds for which the captcha is valid.
### Captcha providers
+#### Pleroma.Captcha.Native
+
+A built-in captcha provider. Enabled by default.
+
#### Pleroma.Captcha.Kocaptcha
+
Kocaptcha is a very simple captcha service with a single API endpoint,
the source code is here: https://github.com/koto-bank/kocaptcha. The default endpoint
`https://captcha.kotobank.ch` is hosted by the developer.
@@ -446,6 +465,7 @@ An example for Sendgrid adapter:
```elixir
config :pleroma, Pleroma.Emails.Mailer,
+ enabled: true,
adapter: Swoosh.Adapters.Sendgrid,
api_key: "YOUR_API_KEY"
```
@@ -454,13 +474,13 @@ An example for SMTP adapter:
```elixir
config :pleroma, Pleroma.Emails.Mailer,
+ enabled: true,
adapter: Swoosh.Adapters.SMTP,
relay: "smtp.gmail.com",
username: "YOUR_USERNAME@gmail.com",
password: "YOUR_SMTP_PASSWORD",
port: 465,
ssl: true,
- tls: :always,
auth: :always
```
@@ -481,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
@@ -493,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:
@@ -504,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
@@ -514,6 +545,9 @@ config :pleroma, Oban,
queues: [
federator_incoming: 50,
federator_outgoing: 50
+ ],
+ crontab: [
+ {"0 0 * * *", Pleroma.Workers.Cron.ClearOauthTokenWorker}
]
```
@@ -796,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
@@ -829,3 +862,12 @@ config :auto_linker,
rel: "ugc"
]
```
+
+## Custom Runtime Modules (`:modules`)
+
+* `runtime_dir`: A path to custom Elixir modules (such as MRF policies).
+
+
+## :configurable_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/howto_theming_your_instance.md b/docs/configuration/howto_theming_your_instance.md
new file mode 100644
index 000000000..d0daf5b25
--- /dev/null
+++ b/docs/configuration/howto_theming_your_instance.md
@@ -0,0 +1,74 @@
+# Theming your instance
+
+To add a custom theme to your instance, you'll first need to get a custom theme, upload it to the server, make it available to the instance and eventually you can set it as default.
+
+## Getting a custom theme
+
+### Create your own theme
+
+* You can create your own theme using the Pleroma FE by going to settings (gear on the top right) and choose the Theme tab. Here you have the options to create a personal theme.
+* To download your theme, you can do Save preset
+* If you want to upload a theme to customise it further, you can upload it using Load preset
+
+This will only save the theme for you personally. To make it available to the whole instance, you'll need to upload it to the server.
+
+### Get an existing theme
+
+* You can download a theme from another instance by going to that instance, go to settings and make sure you have the theme selected that you want. Then you can do Save preset to download it.
+* You can also find and download custom themes at <https://plthemes.vulpes.one/>
+
+## Adding the custom theme to the instance
+
+### Upload the theme to the server
+
+Themes can be found in the [static directory](static_dir.md). Create `STATIC-DIR/static/themes/` if needed and copy your theme there. Next you need to add an entry for your theme to `STATIC-DIR/static/styles.json`. If you use a from source installation, you'll first need to copy the file from `priv/static/static/styles.json`.
+
+Example of `styles.json` where we add our own `my-awesome-theme.json`
+```json
+{
+ "pleroma-dark": [ "Pleroma Dark", "#121a24", "#182230", "#b9b9ba", "#d8a070", "#d31014", "#0fa00f", "#0095ff", "#ffa500" ],
+ "pleroma-light": [ "Pleroma Light", "#f2f4f6", "#dbe0e8", "#304055", "#f86f0f", "#d31014", "#0fa00f", "#0095ff", "#ffa500" ],
+ "classic-dark": [ "Classic Dark", "#161c20", "#282e32", "#b9b9b9", "#baaa9c", "#d31014", "#0fa00f", "#0095ff", "#ffa500" ],
+ "bird": [ "Bird", "#f8fafd", "#e6ecf0", "#14171a", "#0084b8", "#e0245e", "#17bf63", "#1b95e0", "#fab81e"],
+ "ir-black": [ "Ir Black", "#000000", "#242422", "#b5b3aa", "#ff6c60", "#FF6C60", "#A8FF60", "#96CBFE", "#FFFFB6" ],
+ "monokai": [ "Monokai", "#272822", "#383830", "#f8f8f2", "#f92672", "#F92672", "#a6e22e", "#66d9ef", "#f4bf75" ],
+
+ "redmond-xx": "/static/themes/redmond-xx.json",
+ "redmond-xx-se": "/static/themes/redmond-xx-se.json",
+ "redmond-xxi": "/static/themes/redmond-xxi.json",
+ "breezy-dark": "/static/themes/breezy-dark.json",
+ "breezy-light": "/static/themes/breezy-light.json",
+ "mammal": "/static/themes/mammal.json",
+ "my-awesome-theme": "/static/themes/my-awesome-theme.json"
+}
+```
+
+Now you'll already be able to select the theme in Pleroma FE from the drop-down. You don't need to restart Pleroma because we only changed static served files. You may need to refresh the page in your browser. You'll notice however that the theme doesn't have a name, it's just an empty entry in the drop-down.
+
+### Give the theme a name
+
+When you open one of the themes that ship with Pleroma, you'll notice that the json has a `"name"` key. Add a key-value pair to your theme where the key name is `"name"` and the value the name you want to give your theme. After this you can refresh te page in your browser and the name should be visible in the drop-down.
+
+Example of `my-awesome-theme.json` where we add the name "My Awesome Theme"
+```json
+{
+ "_pleroma_theme_version": 2,
+ "name": "My Awesome Theme",
+ "theme": {}
+}
+```
+
+### Set as default theme
+
+Now we can set the new theme as default in the [Pleroma FE configuration](General-tips-for-customizing-Pleroma-FE.md).
+
+Example of adding the new theme in the back-end config files
+```elixir
+config :pleroma, :frontend_configurations,
+ pleroma_fe: %{
+ theme: "my-awesome-theme"
+ }
+```
+
+If you added it in the back-end configuration file, you'll need to restart your instance for the changes to take effect. If you don't see the changes, it's probably because the browser has cached the previous theme. In that case you'll want to clear browser caches. Alternatively you can use a private/incognito window just to see the changes.
+
diff --git a/docs/configuration/howto_user_recomendation.md b/docs/configuration/howto_user_recomendation.md
deleted file mode 100644
index c4d749d0c..000000000
--- a/docs/configuration/howto_user_recomendation.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# How to activate user recommendation (Who to follow panel)
-![who-to-follow-panel-small](/uploads/9de1b1300436c32461d272945f1bc23e/who-to-follow-panel-small.png)
-
-To show the *who to follow* panel, edit `config/prod.secret.exs` in the Pleroma backend. Following code activates the *who to follow* panel:
-
-```elixir
-config :pleroma, :suggestions,
- enabled: true,
- third_party_engine:
- "http://vinayaka.distsn.org/cgi-bin/vinayaka-user-match-suggestions-api.cgi?{{host}}+{{user}}",
- timeout: 300_000,
- limit: 40,
- web: "https://vinayaka.distsn.org"
-
-```
-
-`config/config.exs` already includes this code, but `enabled:` is `false`.
-
-`/api/v1/suggestions` is also provided when *who to follow* panel is enabled.
-
-For advanced customization, following code shows the newcomers of the fediverse at the *who to follow* panel:
-
-```elixir
-config :pleroma, :suggestions,
- enabled: true,
- third_party_engine:
- "http://vinayaka.distsn.org/cgi-bin/vinayaka-user-new-suggestions-api.cgi?{{host}}+{{user}}",
- timeout: 60_000,
- limit: 40,
- web: "https://vinayaka.distsn.org/user-new.html"
-```
diff --git a/docs/configuration/i2p.md b/docs/configuration/i2p.md
index 62ced8b7a..8c5207d67 100644
--- a/docs/configuration/i2p.md
+++ b/docs/configuration/i2p.md
@@ -123,7 +123,7 @@ In addition to that, replace the existing nginx config's contents with the examp
If not an I2P-only instance, add the nginx config below to your existing config at `/etc/nginx/sites-enabled/pleroma.nginx`.
-And for both cases, disable CSP in Pleroma's config (STS is disabled by default) so you can define those yourself seperately from the clearnet (if your instance is also on the clearnet).
+And for both cases, disable CSP in Pleroma's config (STS is disabled by default) so you can define those yourself separately from the clearnet (if your instance is also on the clearnet).
Copy the following into the `config/prod.secret.exs` in your Pleroma folder (/home/pleroma/pleroma/):
```
config :pleroma, :http_security,
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/configuration/onion_federation.md b/docs/configuration/onion_federation.md
index 99f104995..37673211a 100644
--- a/docs/configuration/onion_federation.md
+++ b/docs/configuration/onion_federation.md
@@ -75,7 +75,7 @@ If not a Tor-only instance,
add the nginx config below to your existing config at `/etc/nginx/sites-enabled/pleroma.nginx`.
---
-For both cases, disable CSP in Pleroma's config (STS is disabled by default) so you can define those yourself seperately from the clearnet (if your instance is also on the clearnet).
+For both cases, disable CSP in Pleroma's config (STS is disabled by default) so you can define those yourself separately from the clearnet (if your instance is also on the clearnet).
Copy the following into the `config/prod.secret.exs` in your Pleroma folder (/home/pleroma/pleroma/):
```
config :pleroma, :http_security,
diff --git a/docs/installation/centos7_en.md b/docs/installation/centos7_en.md
deleted file mode 100644
index ad4f58dc1..000000000
--- a/docs/installation/centos7_en.md
+++ /dev/null
@@ -1,274 +0,0 @@
-# Installing on CentOS 7
-## Installation
-
-This guide is a step-by-step installation guide for CentOS 7. It also assumes that you have administrative rights, either as root or a user with [sudo permissions](https://www.digitalocean.com/community/tutorials/how-to-create-a-sudo-user-on-centos-quickstart). If you want to run this guide with root, ignore the `sudo` at the beginning of the lines, unless it calls a user like `sudo -Hu pleroma`; in this case, use `su <username> -s $SHELL -c 'command'` instead.
-
-### Required packages
-
-* `postgresql` (9,6+, CentOS 7 comes with 9.2, we will install version 11 in this guide)
-* `elixir` (1.5+)
-* `erlang`
-* `erlang-parsetools`
-* `erlang-xmerl`
-* `git`
-* Development Tools
-
-#### Optional packages used in this guide
-
-* `nginx` (preferred, example configs for other reverse proxies can be found in the repo)
-* `certbot` (or any other ACME client for Let’s Encrypt certificates)
-
-### Prepare the system
-
-* First update the system, if not already done:
-
-```shell
-sudo yum update
-```
-
-* Install some of the above mentioned programs:
-
-```shell
-sudo yum install wget git unzip
-```
-
-* Install development tools:
-
-```shell
-sudo yum group install "Development Tools"
-```
-
-### Install Elixir and Erlang
-
-* Add the EPEL repo:
-
-```shell
-sudo yum install epel-release
-sudo yum -y update
-```
-
-* Install Erlang repository:
-
-```shell
-wget -P /tmp/ https://packages.erlang-solutions.com/erlang-solutions-1.0-1.noarch.rpm
-sudo rpm -Uvh erlang-solutions-1.0-1.noarch.rpm
-```
-
-* Install Erlang:
-
-```shell
-sudo yum install erlang erlang-parsetools erlang-xmerl
-```
-
-* Download [latest Elixir release from Github](https://github.com/elixir-lang/elixir/releases/tag/v1.8.1) (Example for the newest version at the time when this manual was written)
-
-```shell
-wget -P /tmp/ https://github.com/elixir-lang/elixir/releases/download/v1.8.1/Precompiled.zip
-```
-
-* Create folder where you want to install Elixir, we’ll use:
-
-```shell
-sudo mkdir -p /opt/elixir
-```
-
-* Unzip downloaded file there:
-
-```shell
-sudo unzip /tmp/Precompiled.zip -d /opt/elixir
-```
-
-* Create symlinks for the pre-compiled binaries:
-
-```shell
-for e in elixir elixirc iex mix; do sudo ln -s /opt/elixir/bin/${e} /usr/local/bin/${e}; done
-```
-
-### Install PostgreSQL
-
-* Add the Postgresql repository:
-
-```shell
-sudo yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-centos11-11-2.noarch.rpm
-```
-
-* Install the Postgresql server:
-
-```shell
-sudo yum install postgresql11-server postgresql11-contrib
-```
-
-* Initialize database:
-
-```shell
-sudo /usr/pgsql-11/bin/postgresql-11-setup initdb
-```
-
-* Open configuration file `/var/lib/pgsql/11/data/pg_hba.conf` and change the following lines from:
-
-```plain
-# IPv4 local connections:
-host all all 127.0.0.1/32 ident
-# IPv6 local connections:
-host all all ::1/128 ident
-```
-
-to
-
-```plain
-# IPv4 local connections:
-host all all 127.0.0.1/32 md5
-# IPv6 local connections:
-host all all ::1/128 md5
-```
-
-* Enable and start postgresql server:
-
-```shell
-sudo systemctl enable --now postgresql-11.service
-```
-
-### Install PleromaBE
-
-* Add a new system user for the Pleroma service:
-
-```shell
-sudo useradd -r -s /bin/false -m -d /var/lib/pleroma -U pleroma
-```
-
-**Note**: To execute a single command as the Pleroma system user, use `sudo -Hu pleroma command`. You can also switch to a shell by using `sudo -Hu pleroma $SHELL`. If you don’t have and want `sudo` on your system, you can use `su` as root user (UID 0) for a single command by using `su -l pleroma -s $SHELL -c 'command'` and `su -l pleroma -s $SHELL` for starting a shell.
-
-* Git clone the PleromaBE repository and make the Pleroma user the owner of the directory:
-
-```shell
-sudo mkdir -p /opt/pleroma
-sudo chown -R pleroma:pleroma /opt/pleroma
-sudo -Hu pleroma git clone -b stable https://git.pleroma.social/pleroma/pleroma /opt/pleroma
-```
-
-* Change to the new directory:
-
-```shell
-cd /opt/pleroma
-```
-
-* Install the dependencies for Pleroma and answer with `yes` if it asks you to install `Hex`:
-
-```shell
-sudo -Hu pleroma mix deps.get
-```
-
-* Generate the configuration: `sudo -Hu pleroma mix pleroma.instance gen`
- * Answer with `yes` if it asks you to install `rebar3`.
- * This may take some time, because parts of pleroma get compiled first.
- * After that it will ask you a few questions about your instance and generates a configuration file in `config/generated_config.exs`.
-
-* Check the configuration and if all looks right, rename it, so Pleroma will load it (`prod.secret.exs` for productive instance, `dev.secret.exs` for development instances):
-
-```shell
-mv config/{generated_config.exs,prod.secret.exs}
-```
-
-* The previous command creates also the file `config/setup_db.psql`, with which you can create the database:
-
-```shell
-sudo -Hu postgres psql -f config/setup_db.psql
-```
-
-* Now run the database migration:
-
-```shell
-sudo -Hu pleroma MIX_ENV=prod mix ecto.migrate
-```
-
-* Now you can start Pleroma already
-
-```shell
-sudo -Hu pleroma MIX_ENV=prod mix phx.server
-```
-
-### Finalize installation
-
-If you want to open your newly installed instance to the world, you should run nginx or some other webserver/proxy in front of Pleroma and you should consider to create a systemd service file for Pleroma.
-
-#### Nginx
-
-* Install nginx, if not already done:
-
-```shell
-sudo yum install nginx
-```
-
-* Setup your SSL cert, using your method of choice or certbot. If using certbot, first install it:
-
-```shell
-sudo yum install certbot-nginx
-```
-
-and then set it up:
-
-```shell
-sudo mkdir -p /var/lib/letsencrypt/
-sudo certbot certonly --email <your@emailaddress> -d <yourdomain> --standalone
-```
-
-If that doesn’t work, make sure, that nginx is not already running. If it still doesn’t work, try setting up nginx first (change ssl “on” to “off” and try again).
-
----
-
-* Copy the example nginx configuration to the nginx folder
-
-```shell
-sudo cp /opt/pleroma/installation/pleroma.nginx /etc/nginx/conf.d/pleroma.conf
-```
-
-* Before starting nginx edit the configuration and change it to your needs (e.g. change servername, change cert paths)
-* Enable and start nginx:
-
-```shell
-sudo systemctl enable --now nginx
-```
-
-If you need to renew the certificate in the future, uncomment the relevant location block in the nginx config and run:
-
-```shell
-sudo certbot certonly --email <your@emailaddress> -d <yourdomain> --webroot -w /var/lib/letsencrypt/
-```
-
-#### Other webserver/proxies
-
-You can find example configurations for them in `/opt/pleroma/installation/`.
-
-#### Systemd service
-
-* Copy example service file
-
-```shell
-sudo cp /opt/pleroma/installation/pleroma.service /etc/systemd/system/pleroma.service
-```
-
-* Edit the service file and make sure that all paths fit your installation
-* Enable and start `pleroma.service`:
-
-```shell
-sudo systemctl enable --now pleroma.service
-```
-
-#### Create your first user
-
-If your instance is up and running, you can create your first user with administrative rights with the following task:
-
-```shell
-sudo -Hu pleroma MIX_ENV=prod mix pleroma.user new <username> <your@emailaddress> --admin
-```
-
-#### 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**.
diff --git a/docs/installation/migrating_from_source_otp_en.md b/docs/installation/migrating_from_source_otp_en.md
index 87568faad..31c2f1294 100644
--- a/docs/installation/migrating_from_source_otp_en.md
+++ b/docs/installation/migrating_from_source_otp_en.md
@@ -1,42 +1,28 @@
# Switching a from-source install to OTP releases
+
## What are OTP releases?
OTP releases are as close as you can get to binary releases with Erlang/Elixir. The release is self-contained, and provides everything needed to boot it, it is easily administered via the provided shell script to open up a remote console, start/stop/restart the release, start in the background, send remote commands, and more.
-### Can I still run the develop branch if I decide to use them?
-Yes, we produce builds for every commit in `develop`. However `develop` is considered unstable, please don't use it in production because of faster access to new features, unless you need them as an app developer.
-## Why would one want to switch?
-Benefits of OTP releases over from-source installs include:
-* **Less space used.** OTP releases come without source code, build tools, have docs and debug symbols stripped from the compiled bytecode and do not cointain tests, docs, revision history.
-* **Minimal system dependencies.** Excluding the database and reverse proxy, only `curl`, `unzip` and `ncurses` are needed to download and run the release. Because Erlang runtime and Elixir are shipped with Pleroma, one can use the latest BEAM optimizations and Pleroma features, without having to worry about outdated system repos or a missing `erlang-*` package.
-* **Potentially less bugs and better performance.** This extends on the previous point, because we have control over exactly what gets shipped, we can tweak the VM arguments and forget about weird bugs due to Erlang/Elixir version mismatches.
-* **Faster and less bug-prone mix tasks.** On a from-source install one has to wait untill a new Pleroma node is started for each mix task and they execute outside of the instance context (for example if a user was deleted via a mix task, the instance will have no knowledge of that and continue to display status count and follows before the cache expires). Mix tasks in OTP releases are executed by calling into a running instance via RPC, which solves both of these problems.
-
-### Sounds great, how do I switch?
-Currently we support Linux machines with GNU (e.g. Debian, Ubuntu) or musl (e.g. Alpine) libc and `x86_64`, `aarch64` or `armv7l` CPUs. If you are unsure, check the [Detecting flavour](otp_en.md#detecting-flavour) section in OTP install guide. If your platform is supported, proceed with the guide, if not check the [My platform is not supported](#my-platform-is-not-supported) section.
-### I don't think it is worth the effort, can I stay on a from-source install?
-Yes, currently there are no plans to deprecate them.
-
-### My platform is not supported
-If you think your platform is a popular choice for running Pleroma instances, or has the potential to become one, you can [file an issue on our Gitlab](https://git.pleroma.social/pleroma/pleroma/issues/new). If not, guides on how to build and update releases by yourself will be available soon.
+
## Pre-requisites
You will be running commands as root. If you aren't root already, please elevate your priviledges by executing `sudo su`/`su`.
The system needs to have `curl` and `unzip` installed for downloading and unpacking release builds.
-Debian/Ubuntu:
-```sh
-apt install curl unzip
-```
-Alpine:
-```
+```sh tab="Alpine"
apk add curl unzip
+```
+```sh tab="Debian/Ubuntu"
+apt install curl unzip
```
+
## Moving content out of the application directory
When using OTP releases the application directory changes with every version so it would be a bother to keep content there (and also dangerous unless `--no-rm` option is used when updating). Fortunately almost all paths in Pleroma are configurable, so it is possible to move them out of there.
Pleroma should be stopped before proceeding.
### Moving uploads/custom public files directory
+
```sh
# Create uploads directory and set proper permissions (skip if using a remote uploader)
# Note: It does not have to be `/var/lib/pleroma/uploads`, you can configure it to be something else later
@@ -92,8 +78,8 @@ Before proceeding, get the flavour from [Detecting flavour](otp_en.md#detecting-
rm -r ~pleroma/*
# Set the flavour environment variable to the string you got in Detecting flavour section.
-# For example if the flavour is `arm64-musl` the command will be
-export FLAVOUR="arm64-musl"
+# For example if the flavour is `amd64-musl` the command will be
+export FLAVOUR="amd64-musl"
# Clone the release build into a temporary directory and unpack it
# Replace `stable` with `unstable` if you want to run the unstable branch
@@ -124,8 +110,15 @@ OTP releases have different service files than from-source installs so they need
**Warning:** The service files assume pleroma user's home directory is `/opt/pleroma`, please make sure all paths fit your installation.
-Debian/Ubuntu:
-```sh
+```sh tab="Alpine"
+# Copy the service into a proper directory
+cp -f ~pleroma/installation/init.d/pleroma /etc/init.d/pleroma
+
+# Start pleroma
+rc-service pleroma start
+```
+
+```sh tab="Debian/Ubuntu"
# Copy the service into a proper directory
cp ~pleroma/installation/pleroma.service /etc/systemd/system/pleroma.service
@@ -139,14 +132,6 @@ systemctl reenable pleroma
systemctl start pleroma
```
-Alpine:
-```sh
-# Copy the service into a proper directory
-cp -f ~pleroma/installation/init.d/pleroma /etc/init.d/pleroma
-
-# Start pleroma
-rc-service pleroma start
-```
## Running mix tasks
Refer to [Running mix tasks](otp_en.md#running-mix-tasks) section from OTP release installation guide.
## Updating
diff --git a/docs/installation/openbsd_en.md b/docs/installation/openbsd_en.md
index 45602bd75..e8c5d844c 100644
--- a/docs/installation/openbsd_en.md
+++ b/docs/installation/openbsd_en.md
@@ -1,6 +1,6 @@
# Installing on OpenBSD
-This guide describes the installation and configuration of pleroma (and the required software to run it) on a single OpenBSD 6.4 server.
+This guide describes the installation and configuration of pleroma (and the required software to run it) on a single OpenBSD 6.6 server.
For any additional information regarding commands and configuration files mentioned here, check the man pages [online](https://man.openbsd.org/) or directly on your server with the man command.
@@ -40,7 +40,12 @@ Enter a shell as the \_pleroma user. As root, run `su _pleroma -;cd`. Then clone
#### PostgreSQL
Start a shell as the \_postgresql user (as root run `su _postgresql -` then run the `initdb` command to initialize postgresql:
-If you wish to not use the default location for postgresql's data (/var/postgresql/data), add the following switch at the end of the command: `-D <path>` and modify the `datadir` variable in the /etc/rc.d/postgresql script.
+You will need to specify pgdata directory to the default (/var/postgresql/data) with the `-D <path>` and set the user to postgres with the `-U <username>` flag. This can be done as follows:
+
+```
+initdb -D /var/postgresql/data -U postgres
+```
+If you are not using the default directory, you will have to update the `datadir` variable in the /etc/rc.d/postgresql script.
When this is done, enable postgresql so that it starts on boot and start it. As root, run:
```
@@ -81,7 +86,6 @@ server "default" {
}
types {
- include "/usr/share/misc/mime.types"
}
```
Do not forget to change *<IPv4/6 address\>* to your server's address(es). If httpd should only listen on one protocol family, comment one of the two first *listen* options.
@@ -103,7 +107,7 @@ Insert the following configuration in /etc/acme-client.conf:
authority letsencrypt-<domain name> {
#agreement url "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf"
- api url "https://acme-v01.api.letsencrypt.org/directory"
+ api url "https://acme-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-privkey-<domain name>.pem"
}
@@ -222,7 +226,7 @@ Then follow the main installation guide:
* run `mix deps.get`
* run `mix pleroma.instance gen` and enter your instance's information when asked
* copy config/generated\_config.exs to config/prod.secret.exs. The default values should be sufficient but you should edit it and check that everything seems OK.
- * exit your current shell back to a root one and run `psql -U postgres -f /home/_pleroma/config/setup_db.psql` to setup the database.
+ * exit your current shell back to a root one and run `psql -U postgres -f /home/_pleroma/pleroma/config/setup_db.psql` to setup the database.
* return to a \_pleroma shell into pleroma's installation directory (`su _pleroma -;cd ~/pleroma`) and run `MIX_ENV=prod mix ecto.migrate`
As \_pleroma in /home/\_pleroma/pleroma, you can now run `LC_ALL=en_US.UTF-8 MIX_ENV=prod mix phx.server` to start your instance.
@@ -230,3 +234,11 @@ In another SSH session/tmux window, check that it is working properly by running
##### Starting pleroma at boot
An rc script to automatically start pleroma at boot hasn't been written yet, it can be run in a tmux session (tmux is in base).
+
+
+#### Create administrative user
+
+If your instance is up and running, you can create your first user with administrative rights with the following command as the \_pleroma user.
+```
+LC_ALL=en_US.UTF-8 MIX_ENV=prod mix pleroma.user new <username> <your@emailaddress> --admin
+```
diff --git a/docs/installation/otp_en.md b/docs/installation/otp_en.md
index 965e30e2a..fb99af699 100644
--- a/docs/installation/otp_en.md
+++ b/docs/installation/otp_en.md
@@ -6,7 +6,7 @@
You will be running commands as root. If you aren't root already, please elevate your priviledges by executing `sudo su`/`su`.
-While in theory OTP releases are possbile to install on any compatible machine, for the sake of simplicity this guide focuses only on Debian/Ubuntu/Alpine.
+While in theory OTP releases are possbile to install on any compatible machine, for the sake of simplicity this guide focuses only on Debian/Ubuntu and Alpine.
### Detecting flavour
@@ -20,6 +20,7 @@ If your platform is supported the output will contain the flavour string, you wi
### Installing the required packages
Other than things bundled in the OTP release Pleroma depends on:
+
* curl (to download the release build)
* unzip (needed to unpack release builds)
* ncurses (ERTS won't run without it)
@@ -27,18 +28,16 @@ Other than things bundled in the OTP release Pleroma depends on:
* nginx (could be swapped with another reverse proxy but this guide covers only it)
* certbot (for Let's Encrypt certificates, could be swapped with another ACME client, but this guide covers only it)
-Debian/Ubuntu:
-```sh
-apt install curl unzip libncurses5 postgresql postgresql-contrib nginx certbot
-```
-Alpine:
-
-```sh
+```sh tab="Alpine"
echo "http://nl.alpinelinux.org/alpine/latest-stable/community" >> /etc/apk/repositories
apk update
apk add curl unzip ncurses postgresql postgresql-contrib nginx certbot
```
+```sh tab="Debian/Ubuntu"
+apt install curl unzip libncurses5 postgresql postgresql-contrib nginx certbot
+```
+
## Setup
### Configuring PostgreSQL
#### (Optional) Installing RUM indexes
@@ -48,12 +47,7 @@ apk add curl unzip ncurses postgresql postgresql-contrib nginx certbot
RUM indexes are an alternative indexing scheme that is not included in PostgreSQL by default. You can read more about them on the [Configuration page](../configuration/cheatsheet.md#rum-indexing-for-full-text-search). They are completely optional and most of the time are not worth it, especially if you are running a single user instance (unless you absolutely need ordered search results).
-Debian/Ubuntu (available only on Buster/19.04):
-```sh
-apt install postgresql-11-rum
-```
-Alpine:
-```sh
+```sh tab="Alpine"
apk add git build-base postgresql-dev
git clone https://github.com/postgrespro/rum /tmp/rum
cd /tmp/rum
@@ -62,25 +56,40 @@ make USE_PGXS=1 install
cd
rm -r /tmp/rum
```
+
+```sh tab="Debian/Ubuntu"
+# Available only on Buster/19.04
+apt install postgresql-11-rum
+```
+
#### (Optional) Performance configuration
For optimal performance, you may use [PGTune](https://pgtune.leopard.in.ua), don't forget to restart postgresql after editing the configuration
-Debian/Ubuntu:
-```sh
+```sh tab="Alpine"
+rc-service postgresql restart
+```
+
+```sh tab="Debian/Ubuntu"
systemctl restart postgresql
```
-Alpine:
-```sh
-rc-service postgresql restart
+
+If you are using PostgreSQL 12 or higher, add this to your Ecto database configuration
+
+```elixir
+prepare: :named,
+parameters: [
+ plan_cache_mode: "force_custom_plan"
+]
```
+
### Installing Pleroma
```sh
-# Create the Pleroma user
+# Create a Pleroma user
adduser --system --shell /bin/false --home /opt/pleroma pleroma
# Set the flavour environment variable to the string you got in Detecting flavour section.
-# For example if the flavour is `arm64-musl` the command will be
-export FLAVOUR="arm64-musl"
+# For example if the flavour is `amd64-musl` the command will be
+export FLAVOUR="amd64-musl"
# Clone the release build into a temporary directory and unpack it
su pleroma -s $SHELL -lc "
@@ -133,49 +142,52 @@ su pleroma -s $SHELL -lc "./bin/pleroma stop"
### Setting up nginx and getting Let's Encrypt SSL certificaties
+#### Get a Let's Encrypt certificate
```sh
-# Get a Let's Encrypt certificate
certbot certonly --standalone --preferred-challenges http -d yourinstance.tld
+```
-# Copy the Pleroma nginx configuration to the nginx folder
-# The location of nginx configs is dependent on the distro
+#### Copy Pleroma nginx configuration to the nginx folder
-# For Debian/Ubuntu:
-cp /opt/pleroma/installation/pleroma.nginx /etc/nginx/sites-available/pleroma.nginx
-ln -s /etc/nginx/sites-available/pleroma.nginx /etc/nginx/sites-enabled/pleroma.nginx
-# For Alpine:
+The location of nginx configs is dependent on the distro
+
+```sh tab="Alpine"
cp /opt/pleroma/installation/pleroma.nginx /etc/nginx/conf.d/pleroma.conf
-# If your distro does not have either of those you can append
-# `include /etc/nginx/pleroma.conf` to the end of the http section in /etc/nginx/nginx.conf and
+```
+
+```sh tab="Debian/Ubuntu"
+cp /opt/pleroma/installation/pleroma.nginx /etc/nginx/sites-available/pleroma.conf
+ln -s /etc/nginx/sites-available/pleroma.conf /etc/nginx/sites-enabled/pleroma.conf
+```
+
+If your distro does not have either of those you can append `include /etc/nginx/pleroma.conf` to the end of the http section in /etc/nginx/nginx.conf and
+```sh
cp /opt/pleroma/installation/pleroma.nginx /etc/nginx/pleroma.conf
+```
-# Edit the nginx config replacing example.tld with your (sub)domain
+#### Edit the nginx config
+```sh
+# Replace example.tld with your (sub)domain
$EDITOR path-to-nginx-config
# Verify that the config is valid
nginx -t
+```
+#### Start nginx
-# Start nginx
-# For Debian/Ubuntu:
-systemctl start nginx
-# For Alpine:
+```sh tab="Alpine"
rc-service nginx start
```
-At this point if you open your (sub)domain in a browser you should see a 502 error, that's because pleroma is not started yet.
+```sh tab="Debian/Ubuntu"
+systemctl start nginx
+```
+
+At this point if you open your (sub)domain in a browser you should see a 502 error, that's because Pleroma is not started yet.
### Setting up a system service
-Debian/Ubuntu:
-```sh
-# Copy the service into a proper directory
-cp /opt/pleroma/installation/pleroma.service /etc/systemd/system/pleroma.service
-# Start pleroma and enable it on boot
-systemctl start pleroma
-systemctl enable pleroma
-```
-Alpine:
-```sh
+```sh tab="Alpine"
# Copy the service into a proper directory
cp /opt/pleroma/installation/init.d/pleroma /etc/init.d/pleroma
@@ -184,13 +196,22 @@ rc-service pleroma start
rc-update add pleroma
```
+```sh tab="Debian/Ubuntu"
+# Copy the service into a proper directory
+cp /opt/pleroma/installation/pleroma.service /etc/systemd/system/pleroma.service
+
+# Start pleroma and enable it on boot
+systemctl start pleroma
+systemctl enable pleroma
+```
+
If everything worked, you should see Pleroma-FE when visiting your domain. If that didn't happen, try reviewing the installation steps, starting Pleroma in the foreground and seeing if there are any errrors.
-Still doesn't work? Feel free to contact us on [#pleroma on freenode](https://webchat.freenode.net/?channels=%23pleroma) or via matrix at <https://matrix.heldscal.la/#/room/#freenode_#pleroma:matrix.org>, you can also [file an issue on our Gitlab](https://git.pleroma.social/pleroma/pleroma/issues/new)
+Still doesn't work? Feel free to contact us on [#pleroma on freenode](https://irc.pleroma.social) or via matrix at <https://matrix.heldscal.la/#/room/#freenode_#pleroma:matrix.org>, you can also [file an issue on our Gitlab](https://git.pleroma.social/pleroma/pleroma-support/issues/new)
## Post installation
-### Setting up auto-renew Let's Encrypt certificate
+### Setting up auto-renew of the Let's Encrypt certificate
```sh
# Create the directory for webroot challenges
mkdir -p /var/lib/letsencrypt
@@ -201,25 +222,8 @@ $EDITOR path-to-nginx-config
# Verify that the config is valid
nginx -t
```
-Debian/Ubuntu:
-```sh
-# Restart nginx
-systemctl restart nginx
-# Ensure the webroot menthod and post hook is working
-certbot renew --cert-name yourinstance.tld --webroot -w /var/lib/letsencrypt/ --dry-run --post-hook 'systemctl nginx reload'
-
-# Add it to the daily cron
-echo '#!/bin/sh
-certbot renew --cert-name yourinstance.tld --webroot -w /var/lib/letsencrypt/ --post-hook "systemctl reload nginx"
-' > /etc/cron.daily/renew-pleroma-cert
-chmod +x /etc/cron.daily/renew-pleroma-cert
-
-# If everything worked the output should contain /etc/cron.daily/renew-pleroma-cert
-run-parts --test /etc/cron.daily
-```
-Alpine:
-```sh
+```sh tab="Alpine"
# Restart nginx
rc-service nginx restart
@@ -236,15 +240,25 @@ certbot renew --cert-name yourinstance.tld --webroot -w /var/lib/letsencrypt/ --
' > /etc/periodic/daily/renew-pleroma-cert
chmod +x /etc/periodic/daily/renew-pleroma-cert
-# If everything worked this should output /etc/periodic/daily/renew-pleroma-cert
+# If everything worked the output should contain /etc/cron.daily/renew-pleroma-cert
run-parts --test /etc/periodic/daily
```
-### Running mix tasks
-Throughout the wiki and guides there is a lot of references to mix tasks. Since `mix` is a build tool, you can't just call `mix pleroma.task`, instead you should call `pleroma_ctl` stripping pleroma/ecto namespace.
-So for example, if the task is `mix pleroma.user set admin --admin`, you should run it like this:
-```sh
-su pleroma -s $SHELL -lc "./bin/pleroma_ctl user set admin --admin"
+```sh tab="Debian/Ubuntu"
+# Restart nginx
+systemctl restart nginx
+
+# Ensure the webroot menthod and post hook is working
+certbot renew --cert-name yourinstance.tld --webroot -w /var/lib/letsencrypt/ --dry-run --post-hook 'systemctl reload nginx'
+
+# Add it to the daily cron
+echo '#!/bin/sh
+certbot renew --cert-name yourinstance.tld --webroot -w /var/lib/letsencrypt/ --post-hook "systemctl reload nginx"
+' > /etc/cron.daily/renew-pleroma-cert
+chmod +x /etc/cron.daily/renew-pleroma-cert
+
+# If everything worked the output should contain /etc/cron.daily/renew-pleroma-cert
+run-parts --test /etc/cron.daily
```
## Create your first user and set as admin
@@ -254,20 +268,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**.
+
diff --git a/docs/introduction.md b/docs/introduction.md
index 045dc7c05..a915c143c 100644
--- a/docs/introduction.md
+++ b/docs/introduction.md
@@ -3,53 +3,63 @@
Pleroma is a federated social networking platform, compatible with GNU social, Mastodon and other OStatus and ActivityPub implementations. It is free software licensed under the AGPLv3.
It actually consists of two components: a backend, named simply Pleroma, and a user-facing frontend, named Pleroma-FE. It also includes the Mastodon frontend, if that's your thing.
It's part of what we call the fediverse, a federated network of instances which speak common protocols and can communicate with each other.
-One account on a instance is enough to talk to the entire fediverse!
+One account on an instance is enough to talk to the entire fediverse!
## How can I use it?
-Pleroma instances are already widely deployed, a list can be found here:
-http://distsn.org/pleroma-instances.html
+Pleroma instances are already widely deployed, a list can be found at <http://distsn.org/pleroma-instances.html>. Information on all existing fediverse instances can be found at <https://fediverse.network/>.
If you don't feel like joining an existing instance, but instead prefer to deploy your own instance, that's easy too!
-Installation instructions can be found here:
-[main Pleroma wiki](/)
+Installation instructions can be found in the installation section of these docs.
## I got an account, now what?
-Great! Now you can explore the fediverse!
-- Open the login page for your Pleroma instance (for ex. https://pleroma.soykaf.com) and login with your username and password.
-(If you don't have one yet, click on Register) :slightly_smiling_face:
+Great! Now you can explore the fediverse! Open the login page for your Pleroma instance (e.g. <https://pleroma.soykaf.com>) and login with your username and password. (If you don't have an account yet, click on Register)
At this point you will have two columns in front of you.
### Left column
-- first block: here you can see your avatar, your nickname a bio, and statistics (Statuses, Following, Followers).
-Under that you have a text form which allows you to post new statuses. The icon on the left is for uploading media files and attach them to your post. The number under the text form is a character counter, every instance can have a different character limit (the default is 5000).
-If you want to mention someone, type @ + name of the person. A drop-down menu will help you in finding the right person. :slight_smile:
+
+- first block: here you can see your avatar, your nickname and statistics (Statuses, Following, Followers). Clicking your profile pic will open your profile.
+Under that you have a text form which allows you to post new statuses. The number on the bottom of the text form is a character counter, every instance can have a different character limit (the default is 5000).
+If you want to mention someone, type @ + name of the person. A drop-down menu will help you in finding the right person.
+Under the text form there are also several visibility options and there is the option to use rich text.
+Under that the icon on the left is for uploading media files and attach them to your post. There is also an emoji-picker and an option to post a poll.
To post your status, simply press Submit.
+On the top right you will also see a wrench icon. This opens your personal settings.
- second block: Here you can switch between the different timelines:
- - Timeline: all the people that you follow
- - Mentions: all the statutes where you are mentioned
- - Public Timeline: all the statutes from the local instance
- - The Whole Known Network: everything, local and remote!
-
-- third block: this is the Chat block, where you communicate with people on the same instance in realtime. It is local-only, for now, but we're planning to make it extendable to the entire fediverse! :sweat_smile:
-
+ - Timeline: all the people that you follow
+ - Interactions: here you can switch between different timelines where there was interaction with your account. There is Mentions, Repeats and Favorites, and New follows
+ - Direct Messages: these are the Direct Messages sent to you
+ - Public Timeline: all the statutes from the local instance
+ - The Whole Known Network: all public posts the instance knows about, both local and remote!
+ - About: This isn't a Timeline but shows relevant info about the instance. You can find a list of the moderators and admins, Terms of Service, MRF policies and enabled features.
+- Optional third block: This is the Instance panel that can be activated, but is deactivated by default. It's fully customisable and by default has links to the pleroma-fe and Mastodon-fe.
- fourth block: This is the Notifications block, here you will get notified whenever somebody mentions you, follows you, repeats or favorites one of your statuses.
### Right column
-This is where the interesting stuff happens! :slight_smile:
+This is where the interesting stuff happens!
Depending on the timeline you will see different statuses, but each status has a standard structure:
-- Icon + name + link to profile. An optional left-arrow if it's a reply to another status (hovering will reveal the replied-to status).
-- A + button on the right allows you to Expand/Collapse an entire discussion thread. It also updates in realtime!
-- A binocular icon allows you to open the status on the instance where it's originating from.
-- The text of the status, including mentions. If you click on a mention, it will automatically open the profile page of that person.
-- Four buttons (left to right): Reply, Repeat, Favorite, Delete.
-
-## Mastodon interface
-If the Pleroma interface isn't your thing, or you're just trying something new but you want to keep using the familiar Mastodon interface, we got that too! :smile:
-Just add a "/web" after your instance url (for ex. https://pleroma.soycaf.com/web) and you'll end on the Mastodon web interface, but with a Pleroma backend! MAGIC! :fireworks:
-For more information on the Mastodon interface, please look here:
-https://github.com/tootsuite/documentation/blob/master/Using-Mastodon/User-guide.md
+
+- Profile pic, name and link to profile. An optional left-arrow if it's a reply to another status (hovering will reveal the reply-to status). Clicking on the profile pic will uncollapse the user's profile.
+- A `+` button on the right allows you to Expand/Collapse an entire discussion thread. It also updates in realtime!
+- An arrow icon allows you to open the status on the instance where it's originating from.
+- The text of the status, including mentions and attachements. If you click on a mention, it will automatically open the profile page of that person.
+- Three buttons (left to right): Reply, Repeat, Favorite. There is also a forth button, this is a dropdown menu for simple moderation like muting the conversation or, if you have moderation rights, delete the status from the server.
+
+### Top right
+
+- The magnifier icon opens the search screen where you can search for statuses, people and hashtags. It's also possible to import statusses from remote servers by pasting the url to the post in the search field.
+- The gear icon gives you general settings
+- If you have admin rights, you'll see an icon that opens the admin interface
+- The last icon is to log out
+
+### Bottom right
+On the bottom right you have a chatbox. Here you can communicate with people on the same instance in realtime. It is local-only, for now, but there are plans to make it extendable to the entire fediverse!
+
+### Mastodon interface
+If the Pleroma interface isn't your thing, or you're just trying something new but you want to keep using the familiar Mastodon interface, we got that too!
+Just add a "/web" after your instance url (e.g. <https://pleroma.soycaf.com/web>) and you'll end on the Mastodon web interface, but with a Pleroma backend! MAGIC!
+The Mastodon interface is from the Glitch-soc fork. For more information on the Mastodon interface you can check the [Mastodon](https://docs.joinmastodon.org/) and [Glitch-soc](https://glitch-soc.github.io/docs/) documentation.
Remember, what you see is only the frontend part of Mastodon, the backend is still Pleroma.