pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-05-08T00:40:01Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/3047Relayed Creates rejected with "Invalid HTTP Signature"2023-05-08T00:40:01ZthefloweringashRelayed Creates rejected with "Invalid HTTP Signature"<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): from source(?) via nixpkgs
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): 1.13.4
* Operating system: NixOS 22.11
* PostgreSQL version (`psql -V`): 14.6
### Bug description
Relayed Create messages posted to /inbox are rejected with "Invalid HTTP Signature" after 23e91ec8ddb143353b5f685feec33c64370d13c6, which changed the fallback logic for invalid signatures.
The "valid_signature=false" assign has two meanings:
- signature was not valid
- signature key id does not match author (MappedSignatureToIdentityPlug, "payload actor mismatch")
The second meaning applies to relayed Create requests.
Prior to 23e91ec8ddb143353b5f685feec33c64370d13c6, requests with invalid signatures would hit the ActivityPubController inbox handler that (possibly) called `post_inbox_relayed_create`. After the change, they are rejected eagerly with the "Invalid HTTP Signature" error.https://git.pleroma.social/pleroma/pleroma/-/issues/3046[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:pin...2023-05-08T00:40:17Ztusooa[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}
log: `[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}`
code:
```
def websocket_handle(:ping, state), do: {:ok, state}
```
~~Maybe websockex is different from our original implementation?~~ that...
log: `[error] Elixir.Pleroma.Web.MastodonAPI.WebsocketHandler received frame: {:ping, "PING"}`
code:
```
def websocket_handle(:ping, state), do: {:ok, state}
```
~~Maybe websockex is different from our original implementation?~~ that's unrelevant, websockex is the client implementation, not serverhttps://git.pleroma.social/pleroma/pleroma/-/issues/3044Import following not working as expected on new instance2023-02-19T06:58:01ZVD-15Import following not working as expected on new instance<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): From Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Elixir 1.12.2 (compiled with Erlang/OTP 24)
* Operating system: Ubuntu 22.04 jammy
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 14.5 (Ubuntu 14.5-0ubuntu0.22.04.1)
### Bug description
I recently set up a new instance following the [instructions](https://docs-develop.pleroma.social/backend/installation/debian_based_en/) for my distribution in the Pleroma docs, but I've found myself unable to import my `friends.csv` from my main account.
I follow about 200 people on my main, but when importing the follows via pleroma-FE, the importing process only appeared to follow a single user from the list. I'm aware this process can take a while, so I left it overnight but no progress had been made the following morning. I tried importing the list a few more times, and each time I uploaded the file, it would follow exactly one more user from the list and stop. Eventually it stopped following users altogether and the new account currently sits following 15 people, a handful of which were followed manually.
This is odd to me, because I was able to import almost the exact same follow list on a new Akkoma instance the week prior. That account now follows 134 people. I assume this number is lower than my main because I follow a lot of usernames from dead instances.
I've restarted Pleroma and the server it's running on several times and even re-compiled pleroma and its dependencies just to be sure. I don't think it's a federation issue as I can see posts from the few users I do follow just fine and the import process follows some users from specific instances, but not others on those same instances. Perhaps worth mentioning is that I've configured the instance with an abnormally low upload limit of ~64kB and a character limit of ~1000 characters. I don't know if that would somehow affect the importing process. I can't see any relevant errors in pleroma's logs when running the import process. I did have one error in the logs relating to a user I had followed whose instance had since shut down. While removing that user's handle from `friends.csv` did remove the error, it did not fix the import process.https://git.pleroma.social/pleroma/pleroma/-/issues/3043Re-following bot accounts on non-Pleroma seems to be forbidden2023-05-08T00:35:42ZDohyeon JeonRe-following bot accounts on non-Pleroma seems to be forbidden<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): Not a Pleroma environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Not a Pleroma environment
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Not a Pleroma environment
* Operating system: Not a Pleroma environment
* PostgreSQL version (`psql -V`): Not a Pleroma environment
#### Remote Environment
> NOTE: This bug has arisen between Pleroma and remote (non-Pleroma environment), and I'm at the remote.
* Remote instance 1
* Instance Type: Misskey
* Instance version: [Misskey 13.0.0-beta.30+paring-b25ac66](https://github.com/pikokr/misskey/tree/master)
* Operating system: Alpine Linux v3.17 (Linux kernel 5.15.74-0-lts) on Backend, Data, and Media (Single system hosted)
* Remote instance 2
* Instance Type: Mastodon
* Instance version: [v4.0.2](https://github.com/mastodon/mastodon/releases/tag/v4.0.2)
* Operating System: Could not check
* Bug arisen on (1): [Udongein](https://udongein.xyz)
* Pleroma version: Backend 2.5.0; Frontend 3a507ba9b
* Installation type: Could not check
* Elixir version: Could not check
* Operating system: Could not check
* PostgreSQL version: Could not check
* Bug arisen on (2): [blobcat](https://blob.cat)
* Pleroma version: Backend 2.2.50-745-g0ad6ea20-develop; Frontend 39f85871
* Installation type: Could not check
* Elixir version: Could not check
* Operating system: Could not check
* PostgreSQL version: Could not check
### Bug description
When you followed a bot user and unfollowed, you can never re-follow again but it just says "Follow request pending".
#### Reproduce steps
1. Follow a bot user of Pleroma on non-Pleroma remote.
2. Unfollow them.
3. Try follow them again.https://git.pleroma.social/pleroma/pleroma/-/issues/3042Periodic job for pruning old content2023-09-17T21:42:51ZpiggoPeriodic job for pruning old contentI fixed my issues with incredibly slow timelines and query timeouts by deleting disabled users, old activities and objects (older than Jan 1 2021), then vacuum full. How about this were a built-in job that runs every X days or something,...I fixed my issues with incredibly slow timelines and query timeouts by deleting disabled users, old activities and objects (older than Jan 1 2021), then vacuum full. How about this were a built-in job that runs every X days or something, configurable of course?
It could also be limited to remote only and posts the local users never interacted with, but that makes the query more complicated.
Deleting old stuff also solves the issue of ever growing storage requirements. This almost halved my postgres folder in size.
In my case this deleted about 3 millions of activities and couple hundred thousand objects
This change was needed to delete objects - the constraint prevented anything being deleted:
```
ALTER TABLE deliveries DROP CONSTRAINT "deliveries_object_id_fkey", ADD CONSTRAINT "deliveries_object_id_fkey" FOREIGN KEY (object_id) REFERENCES objects(id) ON DELETE CASCADE;
```
Deleting users needed a new index, but I forgot what it was - it shows up when running explain (timing) when deleting a single user.https://git.pleroma.social/pleroma/pleroma/-/issues/3041Inconsistent inclusion of port in HTTP signatures2023-05-08T00:41:29ZGeoff TaylorInconsistent inclusion of port in HTTP signaturesI'm using a small, non-public installation of the docker container git.pleroma.social:5050/pleroma/pleroma:latest with backend version 2.4.53-863-g9f708037
(I'm not a real Pleroma user, I'm just using it to send some ActivityPub stuff t...I'm using a small, non-public installation of the docker container git.pleroma.social:5050/pleroma/pleroma:latest with backend version 2.4.53-863-g9f708037
(I'm not a real Pleroma user, I'm just using it to send some ActivityPub stuff to code I'm running.)
I've noticed that when Pleroma requests, for example, an Actor's data, it uses a `GET` request with the key `/internal/fetch#main-key`. When it signs the request, it uses the Host header *without* the port.
When it's sending data from a user, it uses a `POST` request with the person's key `/users/personname#main-key`. When it signs the request, it uses the Host header *with* the port.
In other words:
* When it gets http://localhost:8080/users/personname it generates the signature with `host: localhost`.
* When it sends to http://localhost:8080/users/personname/outbox it generates the signature with `host: localhost:8080`
The RFC for HTTP signatures doesn't seem to mention one way or the other whether to use the port so I don't know which one is 'right'. It does seem they should be consistent though.
This inconsistency only appears if the target (my code) is running on a non-default port, which means this likely applies to very few people (mainly developers?) so has very little impact.
I've got a workaround for it in my code so it's not a big deal. I just figured I should mention it here now that I've noticed it.https://git.pleroma.social/pleroma/pleroma/-/issues/3039MRF SimplePolicy: `check_ftl_removal` only supports tuples as configuration, ...2023-05-08T00:36:22ZpiggoMRF SimplePolicy: `check_ftl_removal` only supports tuples as configuration, no single string (legacy)```
pleroma | 10:32:21.655 [info] POST /api/v1/statuses
pleroma |
pleroma | 10:32:21.660 request_id=FzXaMT1xvIFX2yUAAD8h [error] Internal server error: %FunctionClauseError{args: nil, arity: 1, clauses: nil, functio...```
pleroma | 10:32:21.655 [info] POST /api/v1/statuses
pleroma |
pleroma | 10:32:21.660 request_id=FzXaMT1xvIFX2yUAAD8h [error] Internal server error: %FunctionClauseError{args: nil, arity: 1, clauses: nil, function: :"-instance_list_from_tuples/1-fun-0-", kind: nil, module: Pleroma.Web.ActivityPub.MRF}
pleroma |
pleroma | 10:32:21.661 request_id=FzXaMT1xvIFX2yUAAD8h [info] Sent 500 in 5ms
pleroma |
pleroma | 10:32:21.661 [error] #PID<0.4543.0> running Pleroma.Web.Endpoint (connection #PID<0.4135.0>, stream id 20) terminated
pleroma | Server: piggo.space:80 (http)
pleroma | Request: POST /api/v1/statuses
pleroma | ** (exit) an exception was raised:
pleroma | ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
pleroma | (pleroma 2.5.0) anonymous fn("botsin.space") in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
pleroma | (elixir 1.12.2) lib/enum.ex:1582: Enum."-map/2-lists^map/1-0-"/2
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:89: Pleroma.Web.ActivityPub.MRF.SimplePolicy.check_ftl_removal/2
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:217: Pleroma.Web.ActivityPub.MRF.SimplePolicy.filter/1
pleroma | (elixir 1.12.2) lib/enum.ex:2385: Enum."-reduce/3-lists^foldl/2-0-"/3
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/activity_pub.ex:130: Pleroma.Web.ActivityPub.ActivityPub.insert/4
pleroma | (pleroma 2.5.0) lib/pleroma/web/activity_pub/activity_pub.ex:299: Pleroma.Web.ActivityPub.ActivityPub.do_create/2
pleroma | (ecto_sql 3.9.0) lib/ecto/adapters/sql.ex:1190: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
pleroma |
pleroma | 10:32:21.697 [info] GET /api/v1/timelines/home
```https://git.pleroma.social/pleroma/pleroma/-/issues/3037Install v2.5.0 on debian 11 (bullseye) via source fails. Missing Elixir v1.112024-01-06T02:50:03ZMatthias StefanInstall v2.5.0 on debian 11 (bullseye) via source fails. Missing Elixir v1.11<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): From Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): v2.5.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): v1.10.3
* Operating system: Debian Bullseye 11
* PostgreSQL version (`psql -V`): 13.9
### Bug description
In the install documentation for pleroma there is a variant described for installing it on debian 11: [Pleroma Install Guide](https://docs-develop.pleroma.social/backend/installation/debian_based_en/)
> This guide will assume you are on Debian 11 (“bullseye”) or later.
This is no longer valid, since Debian 11 supports only v1.10.3 of Elixir: [Debian Package Elixir](https://packages.debian.org/bullseye/elixir)
When you try to compile pleroma, the following appears:
```
sudo -Hu pleroma MIX_ENV=prod mix compile
** (Mix) You're trying to run :pleroma on Elixir v1.10.3 but it has declared in its mix.exs file it supports only Elixir ~> 1.11
```https://git.pleroma.social/pleroma/pleroma/-/issues/3036Suggestion: add email_whitelist option to Pleroma.User config2023-05-08T00:42:01Zl mSuggestion: add email_whitelist option to Pleroma.User config- only allow users with allowed email domains to register
- has no effect when empty list, which is the default option
- if given domain is in both email_blacklist and email_whitelist, blacklist has priority- only allow users with allowed email domains to register
- has no effect when empty list, which is the default option
- if given domain is in both email_blacklist and email_whitelist, blacklist has priorityhttps://git.pleroma.social/pleroma/pleroma/-/issues/3034Emails not being sent2023-05-08T00:41:12ZWyatt ParkerEmails not being sentSo I have Pleroma with Soapbox and I'm trying to figure out how come no emails are being sent. I've check/tested 465/587 with telnet and can telnet just fine to my google workspace.
I've even tested with SendMail API/AmazonSES both API a...So I have Pleroma with Soapbox and I'm trying to figure out how come no emails are being sent. I've check/tested 465/587 with telnet and can telnet just fine to my google workspace.
I've even tested with SendMail API/AmazonSES both API and SMTP credentials on these ports through Pleroma and no emails, but again, Telnet is successful.
Port 25 is not an option as DigitalOcean is blocking it. I've tried to reach out to Pleroma through their IRC and no response for 2 days. Was hoping someone could shed some light on how come registration emails are not going through.
Thanks in advance.https://git.pleroma.social/pleroma/pleroma/-/issues/3032Non-breaking migration process2023-05-08T00:43:30ZtusooaNon-breaking migration processWe should set up a non-breaking migration process.
This means we should strive to minimize the downtime for the migrations.
Preferably, the process should behave as follows:
0. Run the migrations that will not break old code
1. Swap o...We should set up a non-breaking migration process.
This means we should strive to minimize the downtime for the migrations.
Preferably, the process should behave as follows:
0. Run the migrations that will not break old code
1. Swap old code with new code
2. Run migrations that will not break current code, while new code is runninghttps://git.pleroma.social/pleroma/pleroma/-/issues/3028search only finds users who start with the search term2023-05-08T00:45:35Zrobinsearch only finds users who start with the search termWhen you search for a user, it only finds results that start with your search term; it would be much more useful (at least to me) if it found results that contain the term.
The specific example that inspired me to open an issue was sear...When you search for a user, it only finds results that start with your search term; it would be much more useful (at least to me) if it found results that contain the term.
The specific example that inspired me to open an issue was searching for an account I'd just added to the instance I use to mirror Twitter accounts so they can be followed from the fediverse (https://twitter.oksocial.net); the account is "PlayARKMobile", but all I could remember was that it was related to Ark.
Searching for "ark" on that instance finds no users, but searching for "play" does find it.
(I had to look back at the the mirror config for the username. :-)https://git.pleroma.social/pleroma/pleroma/-/issues/3026Think about how to handle excessive deletes for the same object2023-05-08T00:35:10ZlainThink about how to handle excessive deletes for the same objectI've come across two misskey objects that I have over 2000 deletes for in my db. This isn't actively hurting anything, but it seems like a bug, although there could be legitimate reasons for sending multiple deletes for the same object. ...I've come across two misskey objects that I have over 2000 deletes for in my db. This isn't actively hurting anything, but it seems like a bug, although there could be legitimate reasons for sending multiple deletes for the same object. Maybe ignoring a delete if we have already deleted the object would be good.tusooatusooahttps://git.pleroma.social/pleroma/pleroma/-/issues/3025Not getting all emoji when downloading pack from remote instance2023-05-08T00:46:46ZHJNot getting all emoji when downloading pack from remote instanceImporting remote emoji pack seem to download first 30 of the pack and fails the rest, emoji are still created but have no files for them.Importing remote emoji pack seem to download first 30 of the pack and fails the rest, emoji are still created but have no files for them.https://git.pleroma.social/pleroma/pleroma/-/issues/3019Force unfollow a relay?2023-05-08T00:51:18ZWalter CoolForce unfollow a relay?Hi,
I been with two damn relays who been stuck for a year and there is no way to get rid of them.
No matter if using Admin FE or CLI to unfollow, they are not removed.
Any good way to workaround this issue? I have no idea where are re...Hi,
I been with two damn relays who been stuck for a year and there is no way to get rid of them.
No matter if using Admin FE or CLI to unfollow, they are not removed.
Any good way to workaround this issue? I have no idea where are relays stored at database.
Thanks!https://git.pleroma.social/pleroma/pleroma/-/issues/3016Infinite app registration2023-05-08T00:52:25ZRenat EskeninInfinite app registrationHi, all. I read Pleroma use Mastodon API contract. So, may be it be interested for developers
https://github.com/mastodon/mastodon/issues/21991
I can fill my instance postgres by unconfirmed accounts and spam by confirmation emails. An...Hi, all. I read Pleroma use Mastodon API contract. So, may be it be interested for developers
https://github.com/mastodon/mastodon/issues/21991
I can fill my instance postgres by unconfirmed accounts and spam by confirmation emails. And can fill postgres by creating registered applications (1.5kk apps on mastodon.social now). I didn't find methods to purge this spam from db for Mastodon or any retention policy, but this API has rate limit.https://git.pleroma.social/pleroma/pleroma/-/issues/3014Jsonrs issues2023-06-07T15:26:27ZZeroJsonrs issues### Environment
* Installation type: Source
* Pleroma version: 2.4.5 stable
* Elixir version: Elixir 1.13.0 (compiled with Erlang/OTP 24)
* Operating system: Ubuntu
* PostgreSQL version: 12.12
### Bug description
So I was looking for...### Environment
* Installation type: Source
* Pleroma version: 2.4.5 stable
* Elixir version: Elixir 1.13.0 (compiled with Erlang/OTP 24)
* Operating system: Ubuntu
* PostgreSQL version: 12.12
### Bug description
So I was looking for ways to speed up Pleroma, and I found [Jsonrs](https://hexdocs.pm/jsonrs/readme.html), the authors claim it to be much faster than Jason and even Jiffy, you can see the graphs in their page.
So anyway, I added it to mix.exs and used the following in my config:
```
config :phoenix, :format_encoders, json: Jsonrs, "activity+json": Jsonrs
config :phoenix, :json_library, Jsonrs
config :postgrex, :json_library, Jsonrs
```
To my surprise, everything seemed to work or so I thought, later I found out anything under the "Settings" menu for admin-fe doesn't seem to work properly when using Jsonrs.
I _think_ I traced the issue to Phoenix not being able to decode the JSON for the settings' descriptions Pleroma sends to it when using Jsonrs, but thats as far I was able to go on my own.
I managed to get a full log of the error by adding `config :logger, truncate: :infinity` to my config, as it was too long and got truncated otherwise.
The log file was upload [here](https://git.pleroma.social/-/snippets/7642/raw/main/jsonrs.log) as it would probably be too long to include in the post.
So what I'm asking is if someone knows how to solve or even work around this issue, because if this Json library is that much faster, it could benefit everyone using Pleroma.https://git.pleroma.social/pleroma/pleroma/-/issues/3013Support for when `type` is an array on remote actor objects2023-05-08T00:42:39ZMichael PuckettSupport for when `type` is an array on remote actor objectsI'm building an ActivityPub server and I am not able to see actor profiles generated by my server on any Pleroma instance.
This seems to be due to Pleroma not supporting when `type` is an array on a remote actor. I believe the spec allo...I'm building an ActivityPub server and I am not able to see actor profiles generated by my server on any Pleroma instance.
This seems to be due to Pleroma not supporting when `type` is an array on a remote actor. I believe the spec allows for this.
If I generate an actor and its `type` is NOT an array, then I can see the actor profile in Pleroma.https://git.pleroma.social/pleroma/pleroma/-/issues/3012Upgrade Swoosh dependency2022-12-31T06:04:26ZZhuoyun WeiUpgrade Swoosh dependencyNewer version of Swoosh ships a useful adapter [ExAwsAmazonSES](https://hexdocs.pm/swoosh/Swoosh.Adapters.ExAwsAmazonSES.html), which wraps AmazonSES to use dynamic credentials fetched from IAM role. This is particular useful if Pleroma ...Newer version of Swoosh ships a useful adapter [ExAwsAmazonSES](https://hexdocs.pm/swoosh/Swoosh.Adapters.ExAwsAmazonSES.html), which wraps AmazonSES to use dynamic credentials fetched from IAM role. This is particular useful if Pleroma is running in an AWS environment.
Currently the OTP release of Pleroma ships Swoosh 1.3.11, which does not include this adapter. Please consider upgrading Swoosh to a newer version.https://git.pleroma.social/pleroma/pleroma/-/issues/3011ForceMentionsInContent MRF mentions users on Misskey instances twice2023-05-08T00:47:34ZYour New SJW WaifuForceMentionsInContent MRF mentions users on Misskey instances twice<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source):
- [ ] The virgin OTP install
- [X] The chad source install
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 20790c1d
* Elixir version (`elixir -v` for from source installations, N/A for OTP):
```
Erlang/OTP 25 [erts-13.0.4] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [jit:ns]
Elixir 1.13.4 (compiled with Erlang/OTP 25)
```
* Operating system: ![Ubuntu](https://bae.st/emoji/custom/ubuntu.png) (22.04)
![it just werks](https://bae.st/media/96ca9fab7994bc4ac9c27a3f0d7d2a54917373128bca4dba9ba6544e1e9ff43b.jpg?name=ubuntu_vs_arch.jpg)
* PostgreSQL version (`psql -V`):
```
psql (PostgreSQL) 15.1 (Ubuntu 15.1-1.pgdg22.04+1)
```
**Actually it's 14. No idea what's going on here but that's the output**
Actually I do have an idea but it's a moot point. I have both 14 and 15 installed but I haven't migrated the database yet.
### Bug description
When the ForceMentionsInContent MRF is enabled users on Misskey instances are mentioned twice.
e.g.:
![screenshot of the issue](https://bae.st/media/a5448ab594a763ccccc1cc25baa0dbdc53f3634d0a6efe29ef6c419784567310.png?name=Screenshot_20221129-112753.png)
It seems to be limited exclusively to Misskey instances.