pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2024-02-27T05:45:22Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/3251Missing `configuration.accounts` property in Pleroma servers2024-02-27T05:45:22ZNik ClaytonMissing `configuration.accounts` property in Pleroma servers### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g 0b9bc4a0-develop)" (at least, but see below)
### Bug description
Some Pleroma servers are not ...### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g 0b9bc4a0-develop)" (at least, but see below)
### Bug description
Some Pleroma servers are not returning a `configuration.accounts` property at `/api/v2/instance`. This is a non-nullable non-optional property, so it should be present.
Affected servers (incomplete): activitypub.agates.io, apontaeclica.com, bassam.social, bearvideo.win, c.wtf, clew.lol, fediverse.spearman.xyz, foygl.com, gleasonator.com, hidamari.apartments, iddqd.social, idolheaven.org, jacksonhomestead.me, killyour.dad, leafposter.club, lm.kazv.moe, neenster.org, orwell.fun, p.sugar-free-jazz.com,
parcero.bond, pl.eragon.re, pl.fediverse.pl, pl.kotobank.ch, pleroma.dark-alexandr.net, pleroma.pibvt.net, pleroma.woodynet.net, rabbithou.se, rebased.social, rebased.taihou.website, redsnake.io, seal.cafe, shinkai.party, shitposting.on.incorrigible.moe, social.dansonline.space, social.linuxine.net, social.luizpicolo.com.br, social.protectors.moe, social.rucksfuchs.de, social.teci.world, socialgoblins.club, sosial.agdersam.no, svltan.at, twhtv.club, updog.no, vnil.de, vocalfry.socialhttps://git.pleroma.social/pleroma/pleroma/-/issues/3250`configuration.statuses.characters_reserved_per_url` missing from some Plerom...2024-02-27T05:45:03ZNik Clayton`configuration.statuses.characters_reserved_per_url` missing from some Pleroma servers### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (at least, but see below)
### Bug description
I see a number of Plerorma ser...### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (at least, but see below)
### Bug description
I see a number of Plerorma servers that have somehow been configured such that `characters_reserved_per_url` is missing from the `/api/v2/instance` response.
That's a non-optional, non-nullable property according to https://docs.joinmastodon.org/entities/Instance/#characters_reserved_per_url, so should be present.
Affected servers include: activitypub.agates.io, apontaeclica.com, bassam.social, bearvideo.win, c.wtf, clew.lol, fediverse.spearman.xyz, foygl.com, gleasonator.com, hidamari.apartments, iddqd.social, idolheaven.org, jacksonhomestead.me, killyour.dad, leafposter.club, lm.kazv.moe, neenster.org, orwell.fun, p.sugar-free-jazz.com, parcero.bond, pl.eragon.re, pl.fediverse.pl, pl.kotobank.ch, pleroma.dark-alexandr.net, pleroma.pibvt.net, pleroma.woodynet.net, rabbithou.se, rebased.social, rebased.taihou.website, redsnake.io, seal.cafe, shinkai.party, shitposting.on.incorrigible.moe, social.dansonline.space, social.linuxine.net, social.luizpicolo.com.br, social.protectors.moe, social.rucksfuchs.de, social.teci.world, socialgoblins.club, sosial.agdersam.no, svltan.at, twhtv.club, updog.no, vnil.de, vocalfry.social
Many of those servers are in the list in 3249 as well, which is why I've linked the issues in case there's something in common between them.https://git.pleroma.social/pleroma/pleroma/-/issues/3249Missing `configuration.media_attachments` child properties in Pleroma servers2024-03-23T13:30:16ZNik ClaytonMissing `configuration.media_attachments` child properties in Pleroma servers### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (one server example, but see below)
### Bug description
It seems to be possi...### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (one server example, but see below)
### Bug description
It seems to be possible for users to configure Pleroma servers so that important properties are missing from the `configuration.media_attachments` property in the value returned from `/api/v2/instance`.
I've observed missing:
- `supported_mime_types`
- `image_matrix_limit`
- `video_frame_rate_limit`
- `video_matrix_limit`
properties. None of these are allowed to be missing (or null), per https://docs.joinmastodon.org/entities/Instance/#media_attachments.
I did think that maybe this was the result of the admin disabling media attachments, but it's not. For example, https://gleasonator.com/api/v1/instance shows all of these problems, but also reports `configuration.statuses.max_media_attachments` as 20.
Servers I've seen this on include: activitypub.agates.io, apontaeclica.com, bassam.social, bearvideo.win, c.wtf, clew.lol, fediverse.spearman.xyz, foygl.com, gleasonator.com, iddqd.social, idolheaven.org, jacksonhomestead.me, killyour.dad, leafposter.club, lm.kazv.moe, neenster.org, orwell.fun, p.sugar-free-jazz.com, parcero.bond, pl.kotobank.ch, pleroma.dark-alexandr.net, pleroma.pibvt.net, pleroma.woodynet.net, rabbithou.se, rebased.social, rebased.taihou.website, redsnake.io, seal.cafe, shinkai.party, shitposting.on.incorrigible.moe, social.dansonline.space, social.linuxine.net, social.luizpicolo.com.br, social.protectors.moe, social.rucksfuchs.de, social.teci.world, socialgoblins.club, sosial.agdersam.no, svltan.at, twhtv.club, updog.no, vocalfry.social
Some of these are servers running soapbox (reporting `+soapbox`), but some aren't -- for example, https://idolheaven.org/api/v2/instancehttps://git.pleroma.social/pleroma/pleroma/-/issues/3248Pleroma can be configured to return numbers that are too large2024-02-26T19:30:14ZNik ClaytonPleroma can be configured to return numbers that are too large### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.5.54-325-gb729a8b1-develop)"
### Bug description
JSON is Javascript, and Javascript cannot safely represe...### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.5.54-325-gb729a8b1-develop)"
### Bug description
JSON is Javascript, and Javascript cannot safely represent integers larger than 2^54 -1 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER).
Users can configure Pleroma servers with values that are too large, causing problems for interoperability between clients and servers.
For example, https://hkgk.nishi.boats is currently reporting that `max_toot_chars` property value as `5000000000000000000000000000`.
If you try `parseInt(5000000000000000000000000000)` in a Javascript console you'll see that's `5`.
This is a bit of an extreme example, but users should probably be prevented from shooting themselves in the foot like this, and Pleroma should refuse to start (with a clear explanation as to why) if it is misconfigured in this way.https://git.pleroma.social/pleroma/pleroma/-/issues/3247Separate accounts from actors?2024-02-26T19:20:24Zmarcin mikołajczakSeparate accounts from actors?I wonder if it makes sense for Pleroma upstream to separate user accounts from actors and (if enabled) allow the account to own more than one actor. This would allow to eg. create `Group`s without need for an account for each one of them...I wonder if it makes sense for Pleroma upstream to separate user accounts from actors and (if enabled) allow the account to own more than one actor. This would allow to eg. create `Group`s without need for an account for each one of them. This could also allow multiple users to manage a single actor. And there would be no unnecessary columns like email address for remote/internal actors
There are existing ActivityPub implementations with this feature, like [Takahē](https://docs.jointakahe.org/en/latest/moderation/#identities).https://git.pleroma.social/pleroma/pleroma/-/issues/3246Account moving is impossible even with webfinger lookup listing alias on remo...2024-02-26T19:20:07Zthomas nukerAccount moving is impossible even with webfinger lookup listing alias on remote account<!--
### 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.6.2
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Elixir 1.14.0 (compiled with Erlang/OTP 24)
* Operating system: Debian
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 15.5 (Debian 15.5-0+deb12u1)
### Bug description
The account moving feature appears to be entirely non-functional even with an account alias set up on the account you want to move to, simply displaying the message "Error moving account: Target account not found.". This issue occurs on several instances of Pleroma on completely different setups hardware wise. A webfinger query Pleroma attempts to make to the remote instance appears to display correct results, and trying the query again using curl returns the expected aliases.
[chris@mashtodon.alterracloud.com attempting to move to kirby@lab.nyanide.com](https://imgur.com/a/IPVwBbH)
[kirby@lab.nyanide.com's aliases](https://imgur.com/a/ZDfHjN5)
[Trying to make webfinger query from mashtodon.alterracloud.com to lab.nyanide.com](https://imgur.com/a/1jm5iX6)https://git.pleroma.social/pleroma/pleroma/-/issues/3243home timeline is non deterministic, due to wrong volatility on pgplsql functi...2024-02-17T03:33:56Zplebhome timeline is non deterministic, due to wrong volatility on pgplsql functions?with the same query and data, the home timeline sql query is annoyingly non deterministic
is anyone willing to figure out which pgplsql functions need to have their volatility downgraded?
i've tried alter'ing them to STABLE, but it hasn...with the same query and data, the home timeline sql query is annoyingly non deterministic
is anyone willing to figure out which pgplsql functions need to have their volatility downgraded?
i've tried alter'ing them to STABLE, but it hasn't helpedhttps://git.pleroma.social/pleroma/pleroma/-/issues/3242Match/check the return value of the Supervisor in application.ex to make cert...2024-02-17T03:33:08ZplebMatch/check the return value of the Supervisor in application.ex to make certain misconfiguration errors more clearThis is a really small change, result should be matched to {:ok, pid} at https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/application.ex?ref_type=heads#L122
in case of an :error, the result is swallowed up instead o...This is a really small change, result should be matched to {:ok, pid} at https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/application.ex?ref_type=heads#L122
in case of an :error, the result is swallowed up instead of printed, and the user is likely to see a generic Ecto failure instead of why the tree failed to starthttps://git.pleroma.social/pleroma/pleroma/-/issues/3238Preview card returned without mandatory `author_name` property2024-02-17T03:31:14ZNik ClaytonPreview card returned without mandatory `author_name` property### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Backend 2.5.5 / Frontend eec27700
### Bug description
Hi, Pachli (https://pachli.app) dev. here. A user's just reported a crash when P...### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Backend 2.5.5 / Frontend eec27700
### Bug description
Hi, Pachli (https://pachli.app) dev. here. A user's just reported a crash when Pachli processes Pleroma PreviewCard JSON in a status. The crash indicates that the `author_name` propertyis missing from the JSON.
```
com.squareup.moshi.JsonDataException: Required value 'authorName' (JSON name 'author_name') missing at $
at com.squareup.moshi.internal.Util.e(SourceFile:44)
at app.pachli.core.network.model.CardJsonAdapter.fromJson(SourceFile:54)
at app.pachli.core.network.model.CardJsonAdapter.fromJson(SourceFile:1)
...
```
This property is mandatory and non-null, per https://docs.joinmastodon.org/entities/PreviewCard/#author_name.
I checked https://docs-develop.pleroma.social/backend/development/API/differences_in_mastoapi_responses/ and didn't see this listed as a difference between Pleroma and the Mastodon API, so I assume this is a bug.https://git.pleroma.social/pleroma/pleroma/-/issues/3237Pleroma Debian install doesn't listen on any port2024-02-17T03:29:51Ztinfoil hatPleroma Debian install doesn't listen on any portHi,
I installed Pleroma on a LXC Container inside a Proxmox VPS. I installed it on Debian using these instructions:
https://docs-develop.pleroma.social/backend/installation/debian_based_en/
I want to run it inside the LXC and connec...Hi,
I installed Pleroma on a LXC Container inside a Proxmox VPS. I installed it on Debian using these instructions:
https://docs-develop.pleroma.social/backend/installation/debian_based_en/
I want to run it inside the LXC and connect to it via nginx reverse proxy on Proxmox host, which is public. That's the reason I want it to listen on 0.0.0.0
As you can see, it's running
```
root@pleroma:/opt/pleroma# systemctl status pleroma
● pleroma.service - Pleroma social network
Loaded: loaded (/etc/systemd/system/pleroma.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-02-09 01:57:31 UTC; 1s ago
Main PID: 14403 (beam.smp)
Tasks: 29 (limit: 19112)
Memory: 60.8M
CPU: 1.500s
CGroup: /system.slice/pleroma.service
├─14403 /usr/lib/erlang/erts-13.1.5/bin/beam.smp -- -root /usr/lib/erlang -bindir /usr/lib/erlang/erts-13.1.5/bin -progname erl -- -home /var/lib/pleroma -- -pa /usr/lib/elixir/bin/../lib/eex/ebin /usr/lib/elixir/bin/../lib/elixir/ebin /usr/lib/elixir/bin/../>
└─14418 erl_child_setup 1024
Feb 09 01:57:31 pleroma systemd[1]: Started pleroma.service - Pleroma social network.
```
I also made sure, I used
`sudo -Hu pleroma mv config/{generated_config.exs,prod.secret.exs}`
like it says in the Documentation
It should be listening on 0.0.0.0 port 4000
`less config/prod.secret.exs`
```
# Pleroma instance configuration
# NOTE: This file should not be committed to a repo or otherwise made public
# without removing sensitive information.
import Config
config :pleroma, Pleroma.Web.Endpoint,
url: [host: "domain.tld", scheme: "https", port: 443],
http: [ip: {0, 0, 0, 0}, port: 4000],
...
```
There is no pleroma listening on any port ... strange
```
root@pleroma:/opt/pleroma# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 103 4074776 143/postgres
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 4075966 296/master
tcp6 0 0 :::22 :::* LISTEN 0 4071416 1/init
tcp6 0 0 ::1:25 :::* LISTEN 0 4075967 296/master
tcp6 0 0 ::1:5432 :::* LISTEN 103 4074775 143/postgres
tcp6 0 0 :::4369 :::* LISTEN 0 4071415 1/init
root@pleroma:/opt/pleroma#
```https://git.pleroma.social/pleroma/pleroma/-/issues/3236Replies from minds potentially don't generate notifications2024-02-06T05:36:23ZlainReplies from minds potentially don't generate notificationsI noticed that this message did not create a notification for me:
https://lain.com/notice/AeXtVCGmCocmwhDXlII noticed that this message did not create a notification for me:
https://lain.com/notice/AeXtVCGmCocmwhDXlIhttps://git.pleroma.social/pleroma/pleroma/-/issues/3235E-mail sending fails with exception2024-02-06T05:38:59ZlewdthewidesE-mail sending fails with exception<!--
### 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): _Source_
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): _2.6.51-528-g251c455b-develop_
* Elixir version (`elixir -v` for from source installations, N/A for OTP): _1.14.0_
* Operating system: _Arch Linux_
* PostgreSQL version (`psql -V`): _16.1_
### Bug description
E-mails are not being sent out anymore for events such as receiving reports. An exception is thrown when I try to send a test e-mail:
```
[root@Wides-PL pleroma]# pleroma mix pleroma.email test --to "test-74224f@test.mailgenius.com"
** (EXIT from #PID<0.101.0>) shutdown: failed to start child: Pleroma.Config.TransferTask
** (EXIT) an exception was raised:
** (ArgumentError) errors were found at the given arguments:
* 1st argument: not an already existing atom
:erlang.binary_to_existing_atom("Elixir.Pleroma.Web.Endpoint.MetricsExporter", :utf8)
(pleroma 2.6.51-583-g3b9d9915-develop) lib/pleroma/config_db.ex:345: Pleroma.ConfigDB.string_to_elixir_types/1
(pleroma 2.6.51-583-g3b9d9915-develop) lib/pleroma/ecto_type/config/atom.ex:21: Pleroma.EctoType.Config.Atom.load/1
(ecto 3.11.1) lib/ecto/type.ex:935: Ecto.Type.process_loaders/3
(ecto 3.11.1) lib/ecto/repo/queryable.ex:423: Ecto.Repo.Queryable.struct_load!/6
(ecto 3.11.1) lib/ecto/repo/queryable.ex:246: anonymous fn/5 in Ecto.Repo.Queryable.preprocessor/3
(elixir 1.14.0) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
(elixir 1.14.0) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
```
This is almost the exact same error as https://git.pleroma.social/pleroma/pleroma/-/issues/3223, which I'm also affected byhttps://git.pleroma.social/pleroma/pleroma/-/issues/3233can't follow castopod podcast2024-02-06T05:39:54ZLuca Sironican't follow castopod podcastHello,
castopod accounts are discoverable from pleroma but, whenever you try to follow them, the request stay stucked in sent.
From mastodon it does work.
Can you investigate ?
You can pick whatever account@instance from
https://index....Hello,
castopod accounts are discoverable from pleroma but, whenever you try to follow them, the request stay stucked in sent.
From mastodon it does work.
Can you investigate ?
You can pick whatever account@instance from
https://index.castopod.org/https://git.pleroma.social/pleroma/pleroma/-/issues/3230No notification end of polls2024-03-26T18:34:08ZBen HikerNo notification end of pollsIn my configuration I have set "notification at end of polls" where I voted. But this notification never shows up in the column "notifications". The poll are made on a Firefish or Mastodon platform.In my configuration I have set "notification at end of polls" where I voted. But this notification never shows up in the column "notifications". The poll are made on a Firefish or Mastodon platform.https://git.pleroma.social/pleroma/pleroma/-/issues/3229Invalid hashtag causes the whole post to be dropped2024-02-07T16:31:32ZtusooaInvalid hashtag causes the whole post to be droppedhttps://stelpolva.moe/notes/9o548dtfkochwfox contains `test-hashtag`, causing the whole post to be dropped from pleroma. We should only drop the hashtag that does not pass our validation rules, not the whole post.https://stelpolva.moe/notes/9o548dtfkochwfox contains `test-hashtag`, causing the whole post to be dropped from pleroma. We should only drop the hashtag that does not pass our validation rules, not the whole post.https://git.pleroma.social/pleroma/pleroma/-/issues/3228Develop compilation failed2024-02-06T05:40:18ZBen HikerDevelop compilation failedRecent develop version fails in compilation
== Compilation error in file lib/vix/vips/enum.ex ==
** (UndefinedFunctionError) function Vix.Nif.nif_vips_enum_list/0 is undefined (module Vix.Nif is not available)
Vix.Nif.nif_vips_enum_...Recent develop version fails in compilation
== Compilation error in file lib/vix/vips/enum.ex ==
** (UndefinedFunctionError) function Vix.Nif.nif_vips_enum_list/0 is undefined (module Vix.Nif is not available)
Vix.Nif.nif_vips_enum_list()
lib/vix/vips/enum.ex:5: Vix.Vips.EnumHelper.__before_compile__/1
(stdlib 4.3.1.3) lists.erl:1350: :lists.foldl/3
(stdlib 4.3.1.3) lists.erl:1355: :lists.foldl_1/3https://git.pleroma.social/pleroma/pleroma/-/issues/3227Internal nickname format checking is ignored when remote clashing nicknames a...2024-02-06T05:40:38ZPhantasmInternal nickname format checking is ignored when remote clashing nicknames are handled<!--
### 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): Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): [2.6.0-fluffytail](https://git.fluffytail.org/phnt/pleroma/src/branch/fluffytail) and current develop commit f74f5e0a56277507e7bc3df7251ec58b6c8b41cb
* Elixir version (`elixir -v` for from source installations, N/A for OTP): 1.16.0
* Operating system: Arch Linux
* PostgreSQL version (`psql -V`): 16.1
### Bug description
When Pleroma backend encounters a remote clashing nickname with a different ap_id in function [`maybe_handle_clashing_nickname`](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/activity_pub.ex#L1737), it adds a dot to the nickname and renames it. This misses internal nickname format checking enforced by the [`local_nickname_regex`](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/user.ex#L57) and Pleroma doesn't expect this. The `local_nickname_regex` is only used for local users, but some parts of the backend probably rely on this behavior even for remote users thus creating this bug.
If I try to create a username with a dot inside it, as is done by Pleroma in the above function `maybe_handle_clashing_nickname`, it will fail with an Ecto.changeset error (in `validate_format` in ecto to be precise) as shown [here](https://upload.fluffytail.org/media/743212f2f661aa7ea3826d68f46fd0c6d884c4de989788d46721bf4d32e4eaa6.png?name=screenshot-20240104-001048-82.png). Adding a dot to the above regex is enough for Pleroma to create the account and the account mostly works (see my screenshots in the related thread).
As a result from this behavior, that user cannot be tagged in any posts and the handle isn't properly displayed in the frontend.
### Summary
* clashing nicknames with different ap_id miss internal nickname checking
* the affected user cannot be tagged in any posts
* handles are improperly displayed in the frontend
Related thread with screenshots: https://fluffytail.org/notice/AdTquInU8oJeZ9Qp9chttps://git.pleroma.social/pleroma/pleroma/-/issues/3225Certain pages keep showing up in fedi-fe even after I deleted fedi-fe2024-02-06T05:40:51ZJSCertain pages keep showing up in fedi-fe even after I deleted fedi-fe# Environment info
<!-- Everything is optional and where applicable but the more information the better. -->
* Client browser, version, OS, platform: Firefox 122, Windows
* Server OS, platform: Raspbian 12 (bookwork), Raspberry Pi 3B
* ...# Environment info
<!-- Everything is optional and where applicable but the more information the better. -->
* Client browser, version, OS, platform: Firefox 122, Windows
* Server OS, platform: Raspbian 12 (bookwork), Raspberry Pi 3B
* Frontend version (see settings -> about): latest as of 12/31/2023 (not shown in settings > about)
* Backend version (see settings -> about): latest as of 12/31/2023 (not shown in settings > about)
* Browser extensions (ublock, rikaichamp etc): ublock
* Known instance/user customizations (i.e. pleromafe mods/forks, instance styles etc)
# Bug description & reproduction steps
<!-- Type out here how to reproduce the bug, what goes wrong and what should go right -->
## Setup:
1. Set up a fresh Pleroma instance
2. Go to the admin panel
3. Install the latest version of the fedi-fe frontend
4. Set it as default frontend (not sure if this has anything to do with it)
5. Log into fedi-fe (not sure if this is part of the bug)
6. Log out of fedi-fe (not sure if this is part of the bug)
7. Revert the default frontend to `pleroma-fe`
8. Delete fedi-fe (`sudo -Hu pleroma rm -rf /opt/pleroma/instance/static/frontends/fedi-fe`)
9. Restart the Pleroma instance for good measure (`sudo service pleroma restart`)
## Repro 1:
1. Be logged into your instance. The active frontend should be pleroma-fe as expected.
2. Go to your timeline (`/main/friends`)
3. Click on a user's @handle (not the name, that doesn't work); it should point to `/users/$xxx`
![pleroma01](/uploads/68396c33ecf9180471084a74ad266bc4/pleroma01.jpg)
4. Your browser is now at `/users/$xxx` and the user's profile is shown as normal
5. Now reload the page
6. Result: now you're still at `/users/$xxx`, but the frontend has reverted to fedi-fe and the profile cannot be displayed
![pleroma02](/uploads/cbcabff17269281da4e925466f391beb/pleroma02.jpg)
## Repro 2:
1. Be logged into your instance. The active frontend should be pleroma-fe as expected.
2. Go to your timeline (`/main/friends`)
3. Right click on a user's @handle (not the name); it should point to `/users/$xxx`
4. Select "Open in new tab"
5.
![pleroma03](/uploads/420171510d9d7d93ce60f8e98847b6f3/pleroma03.jpg)
5. Result: `/users/$xxx` is open in a new tab, but this tab uses fedi-fe instead of pleroma-fe. The profile cannot be displayed.
![pleroma02](/uploads/789c0be00088ed9270841a9237ab5e04/pleroma02.jpg)
The only relevant console error is:
![image](/uploads/6a09680e55d4914e1e8b1d7b077556ab/image.png)
# Bug seriousness
<!-- Everything is optional and free-form -->
* How annoying it is: very
* How often does it happen: every time
* How many people does it affect: unknown
* Is there a workaround for it: I wish I knewhttps://git.pleroma.social/pleroma/pleroma/-/issues/3223Broken MRF section in Admin FE, can't dump config via cli2024-03-27T15:32:11ZDmytro PoltavchenkoBroken MRF section in Admin FE, can't dump config via cliHello,
Somewhere after commit 4c5b45ed7, a bug was introduced that breaks MRF Policies.
![image](/uploads/c73f2a85515305e644e18119dbea7f0d/image.png)
I tried to dump the config via CLI but received the following error:
```
# docker-co...Hello,
Somewhere after commit 4c5b45ed7, a bug was introduced that breaks MRF Policies.
![image](/uploads/c73f2a85515305e644e18119dbea7f0d/image.png)
I tried to dump the config via CLI but received the following error:
```
# docker-compose run --rm web mix pleroma.config dump pleroma
Creating pleroma_web_run ... done
** (EXIT from #PID<0.94.0>) shutdown: failed to start child: Pleroma.Config.TransferTask
** (EXIT) an exception was raised:
** (ArgumentError) errors were found at the given arguments:
* 1st argument: not an already existing atom
:erlang.binary_to_existing_atom("Elixir.Pleroma.Web.Endpoint.MetricsExporter", :utf8)
(pleroma 2.6.50-266-g7622a839) lib/pleroma/config_db.ex:345: Pleroma.ConfigDB.string_to_elixir_types/1
(pleroma 2.6.50-266-g7622a839) lib/pleroma/ecto_type/config/atom.ex:21: Pleroma.EctoType.Config.Atom.load/1
(ecto 3.10.3) lib/ecto/type.ex:911: Ecto.Type.process_loaders/3
(ecto 3.10.3) lib/ecto/repo/queryable.ex:411: Ecto.Repo.Queryable.struct_load!/6
(ecto 3.10.3) lib/ecto/repo/queryable.ex:243: anonymous fn/5 in Ecto.Repo.Queryable.preprocessor/3
(elixir 1.12.3) lib/enum.ex:1582: Enum."-map/2-lists^map/1-0-"/2
(elixir 1.12.3) lib/enum.ex:1582: Enum."-map/2-lists^map/1-0-"/2
ERROR: 1
```https://git.pleroma.social/pleroma/pleroma/-/issues/32224xx responses from a web push server instantly deletes the subscription2024-02-06T05:42:40Zfeld4xx responses from a web push server instantly deletes the subscriptionIf there's a configuration error or any other problem with the push server we just delete the subscription and the user has no feedback about it. There's no way to recover from it except to log out from the app and log back in.
How shou...If there's a configuration error or any other problem with the push server we just delete the subscription and the user has no feedback about it. There's no way to recover from it except to log out from the app and log back in.
How should we approach this?
Soft disable? Keep a count of failures? Ignore them completely?
```
def push_message(body, sub, api_key, subscription) do
case WebPushEncryption.send_web_push(body, sub, api_key) do
{:ok, %{status: code}} when code in 400..499 ->
Logger.debug("Removing subscription record")
Repo.delete!(subscription)
:ok
```lainlain