pleroma issues
https://git.pleroma.social/pleroma/pleroma/-/issues
2024-02-17T03:31:48Z
https://git.pleroma.social/pleroma/pleroma/-/issues/3240
Investigate Mogrify downgrade
2024-02-17T03:31:48Z
feld
Investigate Mogrify downgrade
Mogrify was downgraded in 03db495e which is due to rinpatch_blurhash depending on `{:mogrify, "~> 0.8.0"}`. Can we fix this and get Mogrify updated again?
Mogrify was downgraded in 03db495e which is due to rinpatch_blurhash depending on `{:mogrify, "~> 0.8.0"}`. Can we fix this and get Mogrify updated again?
2.6.3
https://git.pleroma.social/pleroma/pleroma/-/issues/2852
Moderator privileges using tags instead of general role
2023-05-08T01:19:34Z
Ilja
Moderator privileges using tags instead of general role
*As discussed in the IRC meeting 13/03/2022*
Currently Pleroma has two roles to give elevated privileges, "Admin" and "Moderator". While Admin is a general superuser-role, it's less clear what moderators should be able to do. Some want ...
*As discussed in the IRC meeting 13/03/2022*
Currently Pleroma has two roles to give elevated privileges, "Admin" and "Moderator". While Admin is a general superuser-role, it's less clear what moderators should be able to do. Some want moderators to be able to do more, while others may not want that. In https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3480 extra privileges have been given to moderators, but this may cause current admins to have to revoke some of their moderators privileges. During the last meeting it was concluded that making shifts in expectations like that should not be done as it will undermine the trust people have in Pleroma as a project.
In an attempt to alleviate the immediate concerns a second MR was made to limit some of the extra privileges, https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3578. The problem is that this is a band-aid and adds more complexity without really fixing the problem. In it's current form it also only addressed part of what is now considered a bigger problem.
A proposed sollution is to work with tags instead. We already have the concept of user tags, so this could be used to provide ellevated rights as well. The idea is to have "buckets" of functionality and assign a tag to each. Examples are
* Report triage
* Restrictive tags (ie. post as NSFW, remove media, …)
* Post deletion
* Account deactivation
* Account deletion (Which is in reality deleting all info and deactivating the account)
* Adding restrictions on one post (ie. mark as NSFW; unlisted / followers-only; …)
* ...
Current roles can still be used. E.g. getting the moderator role could give a basic set of tags. Meanwhile, whether someone gets a moderator badge can depend on whether they have one or more of the possible moderator tags. We could even easily make it a setting to determine what default tags a moderator has.
For the admin role it doesn't seem that a switch to tags is needed at the moment, but it could probably also be done if that's ever needed.
In a later stage we could consider adding custom roles if there's demand for that. Each custom role could provide it's own set of tags.
This will also make things easier for front-ends who want to add extra's for admins/mods, because these tags should be more stable than a general "moderator" role is. That means these tags should be provided to the FE as well.
2.5.0
Ilja
Ilja
https://git.pleroma.social/pleroma/pleroma/-/issues/2464
nodeinfo doesn't return granular private properties
2023-05-08T02:56:48Z
Shpuld Shpludson
nodeinfo doesn't return granular private properties
we get `private: true` which doesn't match the granularity of the different privacy settings, so we can't make the FE disable views correctly to match the exact privacy levels
we get `private: true` which doesn't match the granularity of the different privacy settings, so we can't make the FE disable views correctly to match the exact privacy levels
2.4.0
https://git.pleroma.social/pleroma/pleroma/-/issues/2431
Do not generate `rel=next` in the Link header when there are no more records
2023-05-08T02:57:10Z
rinpatch
rin+pleroma@patch.cx
Do not generate `rel=next` in the Link header when there are no more records
The issue was originally described in https://patch.cx/notice/A3InRXBfh6SMFMuZsW .
Currently Pleroma just generates `rel=next` header regardless of whether there are any records after the current page, so the frontend can't know whether...
The issue was originally described in https://patch.cx/notice/A3InRXBfh6SMFMuZsW .
Currently Pleroma just generates `rel=next` header regardless of whether there are any records after the current page, so the frontend can't know whether it should fetch the next page or not. Of course the frontend can compare if the number of posts is equal to the limit, and if not, assume the end of the timeline. However, this creates a false-positive when a user has limit*n posts and a false-negative when rendering one of the posts fails (because safe_render_many will just skip it and return the rest).
There are several ways I've thought of to determine if there are records after the current page:
- The easiest, but hacky ux-wise: Do what some frontends and mastodon backend currently do: compare the number of records returned by the database to the limit we specified and do not render `rel=next` only when the two are not equal. This however still retains the false-positive described above.
- The most correct, but least performant: Do an additional query when `number of records == limit` to determine if there any records left.
- Performant and correct ux-wise, but hacky code-wise: query minimal ids for timelines on first request to them and cache the results in ets
@lambadalambda @lanodan thoughts?
2.4.0
https://git.pleroma.social/pleroma/pleroma/-/issues/2151
Error on streaming a conversation event when sending a dm to oneself
2023-05-08T02:56:56Z
rinpatch
rin+pleroma@patch.cx
Error on streaming a conversation event when sending a dm to oneself
```
[error] Process #PID<0.25877.15> on node :"pleroma@127.0.0.1" raised an exception ** (UndefinedFunctionError) function nil.ap_id/0 is undefined nil.ap_id() (pleroma 2.1.50-200-g712accef-feat-connection-worker-monitor-flush) l...
```
[error] Process #PID<0.25877.15> on node :"pleroma@127.0.0.1" raised an exception ** (UndefinedFunctionError) function nil.ap_id/0 is undefined nil.ap_id() (pleroma 2.1.50-200-g712accef-feat-connection-worker-monitor-flush) lib/pleroma/web/mastodon_api/views/conversation_view.ex:27: Pleroma.Web.MastodonAPI.ConversationView.render/2 (pleroma 2.1.50-200-g712accef-feat-connection-worker-monitor-flush) lib/pleroma/web/views/streamer_view.ex:81: Pleroma.Web.StreamerView.render/2 (pleroma 2.1.50-200-g712accef-feat-connection-worker-monitor-flush) lib/pleroma/web/streamer/streamer.ex:227: Pleroma.Web.Streamer.push_to_socket/2
```
2.4.0
https://git.pleroma.social/pleroma/pleroma/-/issues/1994
Frontend bundle planning
2023-05-08T03:19:05Z
lain
Frontend bundle planning
The frontend bundle MR at !2400 got a bit large, so this issue is about splitting it up to make the review more manageable.
A first step got merged in !2801, which only allows installation of multiple primary frontends which can then be...
The frontend bundle MR at !2400 got a bit large, so this issue is about splitting it up to make the review more manageable.
A first step got merged in !2801, which only allows installation of multiple primary frontends which can then be switched via configuration.
2.3.0
minibikini
minibikini
https://git.pleroma.social/pleroma/pleroma/-/issues/1661
Improve documentation for Pleroma Settings Store API
2023-05-08T04:11:26Z
feld
Improve documentation for Pleroma Settings Store API
From discussion in https://git.pleroma.social/pleroma/pleroma-meta/-/issues/34
We should improve these docs and then review the existing API implementation with the FE team so we can start utilizing it.
https://docs-develop.pleroma.soc...
From discussion in https://git.pleroma.social/pleroma/pleroma-meta/-/issues/34
We should improve these docs and then review the existing API implementation with the FE team so we can start utilizing it.
https://docs-develop.pleroma.social/backend/API/differences_in_mastoapi_responses/#pleroma-settings-store
Technical debt, polish, quality
minibikini
minibikini
https://git.pleroma.social/pleroma/pleroma/-/issues/1622
Instance muting should behave more like normal muting
2023-05-08T03:28:47Z
Pipirupirupirupipirupi
Instance muting should behave more like normal muting
Current behavior:
Instance muting completely removes notifications from users of that instance regardless of [Hide posts of muted users (default: no)] setting
What happens:
> * mastodon.social is muted by user @mono@shitposter.club
> *...
Current behavior:
Instance muting completely removes notifications from users of that instance regardless of [Hide posts of muted users (default: no)] setting
What happens:
> * mastodon.social is muted by user @mono@shitposter.club
> * @gargon@mastodon.social makes a post addressing @mono@shitposter.club
> * @mono does not receive the notification of a reply even though [Hide posts of muted users (default: no)] in settings is off
What should happen:
If [Hide posts of muted users (default: no)] is yes
> * @gargon@mastodon.social makes a post addressing @mono@shitposter.club
> * @mono does not receive a notification
If [Hide posts of muted users (default: no)] is no
> * @gargon@mastodon.social makes a post addressing @mono@shitposter.club
> * @mono receives a collapsed muted notification
Also, people that a user follows should be exempt from instance muting. if one didn't want to see posts from a user from a muted instance, they wouldn't have followed that user in the first place.
2.3.0
minibikini
minibikini
https://git.pleroma.social/pleroma/pleroma/-/issues/1609
Implement an option to enable static-fe only when javascript is disabled and ...
2023-05-08T03:28:32Z
rinpatch
rin+pleroma@patch.cx
Implement an option to enable static-fe only when javascript is disabled and set it by default
This can be accomplished by making static-fe appear only when a param is set to true and then redirect to a page with this param by using `http-equiv` in a `meta` tag inside `noscript`
This can be accomplished by making static-fe appear only when a param is set to true and then redirect to a page with this param by using `http-equiv` in a `meta` tag inside `noscript`
2.3.0
rinpatch
rin+pleroma@patch.cx
rinpatch
rin+pleroma@patch.cx
https://git.pleroma.social/pleroma/pleroma/-/issues/1390
Tracking issue for FE bundle removal
2023-05-08T03:29:00Z
kaniini
Tracking issue for FE bundle removal
Over the past few months, we have been talking about a way to remove the FE bundles from Pleroma, having them managed in the instance folder instead.
Here is roughly how it should work.
The installation script should prompt asking what...
Over the past few months, we have been talking about a way to remove the FE bundles from Pleroma, having them managed in the instance folder instead.
Here is roughly how it should work.
The installation script should prompt asking what FEs should be installed:
- Primary frontend: Pleroma FE, Kenoma, None
- Whether MastoFE should be installed
- Whether AdminFE should be installed
The installation script should fetch either the release or nightly version of all of these and install them in the appropriate place under instance/
It should also prompt if StaticFE (!1917) should be enabled.
Also, ideally the settings would be remembered and a mix task would exist to update one or more frontends to latest release or nightly.
2.3.0
Roman Chvanikov
Roman Chvanikov
https://git.pleroma.social/pleroma/pleroma/-/issues/1052
Unify activities and objects
2021-04-21T08:01:01Z
feld
Unify activities and objects
This closes the activity/object divide that's causing us much performance pain
This closes the activity/object divide that's causing us much performance pain
2.0
https://git.pleroma.social/pleroma/pleroma/-/issues/750
Get documentation in a better state
2023-05-08T04:07:59Z
rinpatch
rin+pleroma@patch.cx
Get documentation in a better state
* [x] Move documentation from the wiki to the repo because it does not support different content for different branches, people can't MR into it, etc.
* [x] Set up auto deploy of repo docs on docs.pleroma.social (!965)
* [ ] Document ...
* [x] Move documentation from the wiki to the repo because it does not support different content for different branches, people can't MR into it, etc.
* [x] Set up auto deploy of repo docs on docs.pleroma.social (!965)
* [ ] Document common troubleshooting steps (updating to the latest master/develop, rebuilding pleroma and deps, etc.)
* [ ] Document the process of filing an issue (describe to which repositories (pleroma, pleroma-fe, auto_linker, mastofe) certain types of problems most likely belong, instruct to collect as much info as possible (we've had many issues with 'Error fetching updates' or '502 error' titles lately, which isn't too helpful)
* [ ] Refactor How-tos to be either in one file, or maybe even integrated with config.md
1.0
https://git.pleroma.social/pleroma/pleroma/-/issues/3261
Markers API `updated_at` property does not include timezone
2024-03-25T19:58:26Z
Nik Clayton
Markers 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/562
https://git.pleroma.social/pleroma/pleroma/-/issues/3260
Subway tooter can't upload media because it won't fall back to application/oc...
2024-03-19T16:50:37Z
Your New SJW Waifu
Subway 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/3258
Add "indexable" user profile parameter to make posts searchable on Mastodon
2024-03-17T20:08:48Z
lamp
lamp@owo69.me
Add "indexable" user profile parameter to make posts searchable on Mastodon
Mastodon now allows searching posts, but users have to opt-in with `"indexable":true` in their user profile data. Pleroma and Pleroma-FE needs to add this option so that Pleroma users can make themselves searchable on Mastodon.
Mastodon now allows searching posts, but users have to opt-in with `"indexable":true` in their user profile data. Pleroma and Pleroma-FE needs to add this option so that Pleroma users can make themselves searchable on Mastodon.
https://git.pleroma.social/pleroma/pleroma/-/issues/3256
Copyright headers
2024-03-12T16:51:36Z
Sean King
Copyright headers
About a year or so ago, we stopped updating the copyright headers after Lain reverted the 2023 update.
Since then, lanodan brought up the possibility of just having `Copyright © 2017 Pleroma Authors <https://pleroma.social/>`, with 2017...
About a year or so ago, we stopped updating the copyright headers after Lain reverted the 2023 update.
Since then, lanodan brought up the possibility of just having `Copyright © 2017 Pleroma Authors <https://pleroma.social/>`, with 2017 being the first year of the Pleroma project, in the headers.
Feld also mentioned an [article about curl having copyright headers without the year](https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/) in them.
I wanted to continue this discussion here so that we can figure out what we want to do regarding copyright headers in the future.
https://git.pleroma.social/pleroma/pleroma/-/issues/3255
MRF_keyword replace should not change usernames or domains.
2024-03-06T21:17:01Z
Mr. Twizzay
MRF_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/3254
WebFinger endpoint responds with XRD instead of JRD in browser
2024-03-09T18:01:39Z
a
WebFinger 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/3253
Object is ignored if `url` property value is an array
2024-03-02T22:43:48Z
silverpill silverpill
Object 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/3252
How can I revert split user data resulting from a switch between HTTP and HTT...
2024-03-02T13:45:41Z
Yasaka
How 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.