pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2024-03-25T19:58:26Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/3261Markers API `updated_at` property does not include timezone2024-03-25T19:58:26ZNik ClaytonMarkers API `updated_at` property does not include timezone<!--
### 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
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Discovered in rebelbase.site which reports the version as "2.7.2 (compatible; Pleroma 2.6.0)"
### Bug description
The markers API response from a Pleroma 2.6 server returns the `updated_at` property as an ISO8601 date/time (per the code in https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/mastodon_api/views/marker_view.ex) without a timezone.
E.g.,
```json
{
"notifications": {
"last_read_id": "",
"pleroma": {
"unread_count": 1
},
"updated_at": "2024-03-24T14:01:35",
"version": 0
}
}
```
I suspect (but have not verified) that changing this line:
```
updated_at: NaiveDateTime.to_iso8601(m.updated_at),
```
in the code to:
```
updated_at: Utils.to_masto_date(m.updated_at),
```
will fix this.
Reported via gvansanden who discovered this in https://github.com/pachli/pachli-android/issues/562https://git.pleroma.social/pleroma/pleroma/-/issues/3260Subway tooter can't upload media because it won't fall back to application/oc...2024-03-19T16:50:37ZYour New SJW WaifuSubway tooter can't upload media because it won't fall back to application/octet-stream<!--
### 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): 0e4e20315b
* 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 22.04
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 16.2 (Ubuntu 16.2-1.pgdg22.04+1)
### Bug description
Due to !4081 subway tooter can no longer upload media because. In #3249 the idea was proposed to just set it to `application/octet-stream` which seemed like a good idea but apparently applications like subway tooter expected `image/jpeg` and if `image/jpeg` isn't explicitly named you're not allowed to upload media.
Yeah, bad app design, but I feel like this is something that should be fixed because this probably won't be the last time that a tool built for mastodon won't work on pleroma because of this.
This should also plug into the Pleroma.Upload.Filter.OnlyMedia or maybe the answer is to build a more comprehensive mime upload filter and pull from there for the API endpoint.
![screenshot by zonk](https://bae.st/media/024cbcbb69e0e843ed2fecfa65f6942f80402861f529ae91f354709903dd6528.png?name=Screenshot_20240309-235048.png)https://git.pleroma.social/pleroma/pleroma/-/issues/3255MRF_keyword replace should not change usernames or domains.2024-03-06T21:17:01ZMr. TwizzayMRF_keyword replace should not change usernames or domains.### Environment
* Installation type OTP on Yunohost:
* Pleroma version 2.5.5:
* Operating system: Debian
* PostgreSQL version: 13.14
### Bug description
The current `mrf_keyword, replace:` policy causes federation issues because it re...### Environment
* Installation type OTP on Yunohost:
* Pleroma version 2.5.5:
* Operating system: Debian
* PostgreSQL version: 13.14
### Bug description
The current `mrf_keyword, replace:` policy causes federation issues because it rewrites usernames and domains.
This forbids local users from interacting with remote users or instances that contain words which would match in this policy. It does not stop the remote users from being able to post to these local users. So, it basically shadowbans local users from certain remote instances. This would almost never be desired. If domains and/or usernames want to be rejected, that should be left to other policies.
One solution might be to superimpose an additional regex over the admin-provided regex in the mrf policy.
```js
/((.*)(@)(.*))?dog((.*)(@)(.*))?/
```
`dog` would be replaced with whatever regex is given in the policy. Then some additional logic would need to check whether groups 3 or 7 contained `@`.
[Here is the obligatory regex101 for testing](https://regex101.com/r/tdcnGL/2)
Notice that my suggestion would continue to overwrite URL's. I think this would be wise. Admins may want to use this policy to redirect certain url's to other sites. For example redirecting youtube or twitter to other more private front-ends like invidious or nitter.
# Consider the following
I think this deserves a priority because content moderation is one of pleroma's greatest strengths. By moderating content over users/instances we help keep the fediverse healthy while enabling admins to control the content that is pulled into their instance. No other project that I know of is prioritizing this currently.
As always, TIA and long live pleroma-tan. :fist:https://git.pleroma.social/pleroma/pleroma/-/issues/3254WebFinger endpoint responds with XRD instead of JRD in browser2024-03-09T18:01:39ZaWebFinger endpoint responds with XRD instead of JRD in browser### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.51-650-g0b9bc4a0-develop as observed on lain.com
### Bug description
Actual behavior:
- WebFinger when requested in a browser is re...### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.51-650-g0b9bc4a0-develop as observed on lain.com
### Bug description
Actual behavior:
- WebFinger when requested in a browser is responding with an XRD that gets downloaded -- likely because browsers by default specify an Accept header that includes application/xml
Expected behavior:
- WebFinger responds with a JRD in-browser -- this is the expected response of the .well-known/webfinger endpoint and also the response that pretty much every other implementation seems to express
In searching I found #2579 which may or may not be related.https://git.pleroma.social/pleroma/pleroma/-/issues/3253Object is ignored if `url` property value is an array2024-03-02T22:43:48Zsilverpill silverpillObject is ignored if `url` property value is an array### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.2
### Bug description
Incoming objects where `url` property is an array are not accepted by Pleroma. Array values might be necessar...### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.2
### Bug description
Incoming objects where `url` property is an array are not accepted by Pleroma. Array values might be necessary for implementing some FEPs such as [FEP-fffd](https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md). Among existing AP implementations, PeerTube uses `url` arrays in its `Video` objects.
(Disclaimer: I haven't verified this myself, the issue was discovered by an automated testing tool: https://data.funfedi.dev/0.1.1/pleroma__v2.6.2/url/)https://git.pleroma.social/pleroma/pleroma/-/issues/3252How can I revert split user data resulting from a switch between HTTP and HTT...2024-03-02T13:45:41ZYasakaHow can I revert split user data resulting from a switch between HTTP and HTTPS communication?### Bug description
I encountered a situation where user data split due to a switch between HTTP and HTTPS communication protocols, and I need to address it safely.
A federated server, initially configured with HTTPS, inadvertently swi...### Bug description
I encountered a situation where user data split due to a switch between HTTP and HTTPS communication protocols, and I need to address it safely.
A federated server, initially configured with HTTPS, inadvertently switched to HTTP communication and then returned to HTTPS. Subsequently, user data in the database became split, with accounts having and lacking prefixes. In such cases, post delivery may become irregular depending on previous follow relationships, although I lack detailed insights due to being unable to confirm symptoms across multiple servers.
Example:
ATw2gPkaQEOPHE0pkG.magi@minazukey.uk
magi@minazukey.uk
Given that these are the same users on the same server, I need a safe method to rectify this state. Unfortunately, on one server, after account data with prefixes was deleted to fix this situation, rendering users on that server unable to follow.
**The split of IDs appears to occur under the following conditions:**
1.There is a user "alice" on a Pleroma (or Akkoma) server X. There is a user "bob" on a Misskey (or Firefish) server Y. The URL in Y's .config/default.yml is set to HTTPS.
2.At this stage, normal communication is established. At this point, "bob" is known to X (e.g., through follow relationships or boosts). The URL in Y is changed to HTTP.
3.Upon delivery from "bob" to X, a new user ID is assigned internally within X under HTTP settings, while the existing "bob" associated with HTTPS is renamed with an internal ID as a prefix. The URL in Y is changed back to HTTPS.
4.Posts from "bob" are associated with the old ID (with prefix) in X. In this state, there may be irregularities in delivery for new follows or regular posts from previously followed users.
Refreshing follows in state 4 sometimes improves delivery. As the administrator of server Y, I lack access to the internal data of Pleroma servers and face challenges in addressing the same issue across multiple federated servers due to my mistake. Please, I need advice on how to fix it.https://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/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/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/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/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