- Mix task for sending confirmation emails to all unconfirmed users (`mix pleroma.email send_confirmation_mails`)
- Mix task option for force-unfollowing relays
- Media preview proxy (requires `ffmpeg` and `ImageMagick` to be installed and media proxy to be enabled; see `:media_preview_proxy` config for more details).
+- Reports now generate notifications for admins and mods.
- Pleroma API: Importing the mutes users from CSV files.
- Experimental websocket-based federation between Pleroma instances.
- Support pagination of blocks and mutes
ENV MIX_ENV=prod
-RUN apk add git gcc g++ musl-dev make cmake &&\
+RUN apk add git gcc g++ musl-dev make cmake file-dev &&\
echo "import Mix.Config" > config/prod.secret.exs &&\
mix local.hex --force &&\
mix local.rebar --force &&\
- `account`: The account of the user who reacted
- `status`: The status that was reacted on
+### ChatMention Notification (not default)
+
+This notification has to be requested explicitly.
+
+The `type` value is `pleroma:chat_mention`
+
+- `account`: The account who sent the message
+- `chat_message`: The chat message
+
+### Report Notification (not default)
+
+This notification has to be requested explicitly.
+
+The `type` value is `pleroma:report`
+
+- `account`: The account who reported
+- `report`: The report
+
## 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`.
-- `include_types`: will include the notifications for activities with the given types. The parameter accepts an array of types (`mention`, `follow`, `reblog`, `favourite`, `move`, `pleroma:emoji_reaction`). Usage example: `GET /api/v1/notifications?include_types[]=mention&include_types[]=reblog`.
+- `include_types`: will include the notifications for activities with the given types. The parameter accepts an array of types (`mention`, `follow`, `reblog`, `favourite`, `move`, `pleroma:emoji_reaction`, `pleroma:chat_mention`, `pleroma:report`). Usage example: `GET /api/v1/notifications?include_types[]=mention&include_types[]=reblog`.
## DELETE `/api/v1/notifications/destroy_multiple`
--- /dev/null
+# Optimizing the BEAM
+
+Pleroma is built upon the Erlang/OTP VM known as BEAM. The BEAM VM is highly optimized for latency, but this has drawbacks in environments without dedicated hardware. One of the tricks used by the BEAM VM is [busy waiting](https://en.wikipedia.org/wiki/Busy_waiting). This allows the application to pretend to be busy working so the OS kernel does not pause the application process and switch to another process waiting for the CPU to execute its workload. It does this by spinning for a period of time which inflates the apparent CPU usage of the application so it is immediately ready to execute another task. This can be observed with utilities like **top(1)** which will show consistently high CPU usage for the process. Switching between procesess is a rather expensive operation and also clears CPU caches further affecting latency and performance. The goal of busy waiting is to avoid this penalty.
+
+This strategy is very successful in making a performant and responsive application, but is not desirable on Virtual Machines or hardware with few CPU cores. Pleroma instances are often deployed on the same server as the required PostgreSQL database which can lead to situations where the Pleroma application is holding the CPU in a busy-wait loop and as a result the database cannot process requests in a timely manner. The fewer CPUs available, the more this problem is exacerbated. The latency is further amplified by the OS being installed on a Virtual Machine as the Hypervisor uses CPU time-slicing to pause the entire OS and switch between other tasks.
+
+More adventurous admins can be creative with CPU affinity (e.g., *taskset* for Linux and *cpuset* on FreeBSD) to pin processes to specific CPUs and eliminate much of this contention. The most important advice is to run as few processes as possible on your server to achieve the best performance. Even idle background processes can occasionally create [software interrupts](https://en.wikipedia.org/wiki/Interrupt) and take attention away from the executing process creating latency spikes and invalidation of the CPU caches as they must be cleared when switching between processes for security.
+
+Please only change these settings if you are experiencing issues or really know what you are doing. In general, there's no need to change these settings.
+
+## VPS Provider Recommendations
+
+### Good
+
+* Hetzner Cloud
+
+### Bad
+
+* AWS (known to use burst scheduling)
+
+
+## Example configurations
+
+Tuning the BEAM requires you provide a config file normally called [vm.args](http://erlang.org/doc/man/erl.html#emulator-flags). If you are using systemd to manage the service you can modify the unit file as such:
+
+`ExecStart=/usr/bin/elixir --erl '-args_file /opt/pleroma/config/vm.args' -S /usr/bin/mix phx.server`
+
+Check your OS documentation to adopt a similar strategy on other platforms.
+
+### Virtual Machine and/or few CPU cores
+
+Disable the busy-waiting. This should generally only be done if you're on a platform that does burst scheduling, like AWS.
+
+**vm.args:**
+
+```
++sbwt none
++sbwtdcpu none
++sbwtdio none
+```
+
+### Dedicated Hardware
+
+Enable more busy waiting, increase the internal maximum limit of BEAM processes and ports. You can use this if you run on dedicated hardware, but it is not necessary.
+
+**vm.args:**
+
+```
++P 16777216
++Q 16777216
++K true
++A 128
++sbt db
++sbwt very_long
++swt very_low
++sub true
++Mulmbcs 32767
++Mumbcgs 1
++Musmbcs 2047
+```
+
+## Additional Reading
+
+* [WhatsApp: Scaling to Millions of Simultaneous Connections](https://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf)
+* [Preemptive Scheduling and Spinlocks](https://www.uio.no/studier/emner/matnat/ifi/nedlagte-emner/INF3150/h03/annet/slides/preemptive.pdf)
+* [The Curious Case of BEAM CPU Usage](https://stressgrid.com/blog/beam_cpu_usage/)
move
pleroma:chat_mention
pleroma:emoji_reaction
+ pleroma:report
reblog
}
end
def create_notifications(%Activity{data: %{"type" => type}} = activity, options)
- when type in ["Follow", "Like", "Announce", "Move", "EmojiReact"] do
+ when type in ["Follow", "Like", "Announce", "Move", "EmojiReact", "Flag"] do
do_create_notifications(activity, options)
end
"EmojiReact" ->
"pleroma:emoji_reaction"
+ "Flag" ->
+ "pleroma:report"
+
# Compatibility with old reactions
"EmojiReaction" ->
"pleroma:emoji_reaction"
def get_notified_from_activity(activity, local_only \\ true)
def get_notified_from_activity(%Activity{data: %{"type" => type}} = activity, local_only)
- when type in ["Create", "Like", "Announce", "Follow", "Move", "EmojiReact"] do
+ when type in ["Create", "Like", "Announce", "Follow", "Move", "EmojiReact", "Flag"] do
potential_receiver_ap_ids = get_potential_receiver_ap_ids(activity)
potential_receivers =
[object_id]
end
+ def get_potential_receiver_ap_ids(%{data: %{"type" => "Flag"}}) do
+ User.all_superusers() |> Enum.map(fn user -> user.ap_id end)
+ end
+
def get_potential_receiver_ap_ids(activity) do
[]
|> Utils.maybe_notify_to_recipients(activity)
"mention",
"pleroma:emoji_reaction",
"pleroma:chat_mention",
+ "pleroma:report",
"move",
"follow_request"
],
- `poll` - A poll you have voted in or created has ended
- `move` - Someone moved their account
- `pleroma:emoji_reaction` - Someone reacted with emoji to your status
+ - `pleroma:chat_mention` - Someone mentioned you in a chat message
+ - `pleroma:report` - Someone was reported
"""
}
end
alias Pleroma.Object
alias Pleroma.User
alias Pleroma.UserRelationship
+ alias Pleroma.Web.AdminAPI.Report
+ alias Pleroma.Web.AdminAPI.ReportView
alias Pleroma.Web.CommonAPI
alias Pleroma.Web.MastodonAPI.AccountView
alias Pleroma.Web.MastodonAPI.NotificationView
"pleroma:chat_mention" ->
put_chat_message(response, activity, reading_user, status_render_opts)
+ "pleroma:report" ->
+ put_report(response, activity)
+
type when type in ["follow", "follow_request"] ->
response
end
end
+ defp put_report(response, activity) do
+ report_render = ReportView.render("show.json", Report.extract_report_info(activity))
+
+ Map.put(response, :report, report_render)
+ end
+
defp put_emoji(response, activity) do
Map.put(response, :emoji, activity.data["content"])
end
--- /dev/null
+defmodule Pleroma.Repo.Migrations.AddPleromaReportTypeToEnumForNotifications do
+ use Ecto.Migration
+
+ @disable_ddl_transaction true
+
+ def up do
+ """
+ alter type notification_type add value 'pleroma:report'
+ """
+ |> execute()
+ end
+
+ def down do
+ alter table(:notifications) do
+ modify(:type, :string)
+ end
+
+ """
+ delete from notifications where type = 'pleroma:report'
+ """
+ |> execute()
+
+ """
+ drop type if exists notification_type
+ """
+ |> execute()
+
+ """
+ create type notification_type as enum (
+ 'follow',
+ 'follow_request',
+ 'mention',
+ 'move',
+ 'pleroma:emoji_reaction',
+ 'pleroma:chat_mention',
+ 'reblog',
+ 'favourite'
+ )
+ """
+ |> execute()
+
+ """
+ alter table notifications
+ alter column type type notification_type using (type::notification_type)
+ """
+ |> execute()
+ end
+end
--- /dev/null
+defmodule Pleroma.Repo.Migrations.RemovePurgeExpiredActivityWorkerFromObanConfig do
+ use Ecto.Migration
+
+ def change do
+ with %Pleroma.ConfigDB{} = config <-
+ Pleroma.ConfigDB.get_by_params(%{group: :pleroma, key: Oban}),
+ crontab when is_list(crontab) <- config.value[:crontab],
+ index when is_integer(index) <-
+ Enum.find_index(crontab, fn {_, worker} ->
+ worker == Pleroma.Workers.Cron.PurgeExpiredActivitiesWorker
+ end) do
+ updated_value = Keyword.put(config.value, :crontab, List.delete_at(crontab, index))
+
+ config
+ |> Ecto.Changeset.change(value: updated_value)
+ |> Pleroma.Repo.update()
+ end
+ end
+end
refute {:ok, [nil]} == Notification.create_notifications(activity)
end
+ test "creates a notification for a report" do
+ reporting_user = insert(:user)
+ reported_user = insert(:user)
+ {:ok, moderator_user} = insert(:user) |> User.admin_api_update(%{is_moderator: true})
+
+ {:ok, activity} = CommonAPI.report(reporting_user, %{account_id: reported_user.id})
+
+ {:ok, [notification]} = Notification.create_notifications(activity)
+
+ assert notification.user_id == moderator_user.id
+ assert notification.type == "pleroma:report"
+ end
+
test "creates a notification for an emoji reaction" do
user = insert(:user)
other_user = insert(:user)
assert [_] = result
end
+ test "by default, does not contain pleroma:report" do
+ %{user: user, conn: conn} = oauth_access(["read:notifications"])
+ other_user = insert(:user)
+ third_user = insert(:user)
+
+ user
+ |> User.admin_api_update(%{is_moderator: true})
+
+ {:ok, activity} = CommonAPI.post(other_user, %{status: "hey"})
+
+ {:ok, _report} =
+ CommonAPI.report(third_user, %{account_id: other_user.id, status_ids: [activity.id]})
+
+ result =
+ conn
+ |> get("/api/v1/notifications")
+ |> json_response_and_validate_schema(200)
+
+ assert [] == result
+
+ result =
+ conn
+ |> get("/api/v1/notifications?include_types[]=pleroma:report")
+ |> json_response_and_validate_schema(200)
+
+ assert [_] = result
+ end
+
test "getting a single notification" do
%{user: user, conn: conn} = oauth_access(["read:notifications"])
other_user = insert(:user)
alias Pleroma.Object
alias Pleroma.Repo
alias Pleroma.User
+ alias Pleroma.Web.AdminAPI.Report
+ alias Pleroma.Web.AdminAPI.ReportView
alias Pleroma.Web.CommonAPI
alias Pleroma.Web.CommonAPI.Utils
alias Pleroma.Web.MastodonAPI.AccountView
test_notifications_rendering([notification], user, [expected])
end
+ test "Report notification" do
+ reporting_user = insert(:user)
+ reported_user = insert(:user)
+ {:ok, moderator_user} = insert(:user) |> User.admin_api_update(%{is_moderator: true})
+
+ {:ok, activity} = CommonAPI.report(reporting_user, %{account_id: reported_user.id})
+ {:ok, [notification]} = Notification.create_notifications(activity)
+
+ expected = %{
+ id: to_string(notification.id),
+ pleroma: %{is_seen: false, is_muted: false},
+ type: "pleroma:report",
+ account: AccountView.render("show.json", %{user: reporting_user, for: moderator_user}),
+ created_at: Utils.to_masto_date(notification.inserted_at),
+ report: ReportView.render("show.json", Report.extract_report_info(activity))
+ }
+
+ test_notifications_rendering([notification], moderator_user, [expected])
+ end
+
test "muted notification" do
user = insert(:user)
another_user = insert(:user)
projects / akkoma / commitdiff