pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-05-08T01:54:34Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/2676Retry delete_user job if it fails2023-05-08T01:54:34ZAlex GleasonRetry delete_user job if it failsCalling `User.delete/1` triggers a background job to delete the user, but sometimes it's slow and/or doesn't seem to work. We're speculating that maybe it hits an error and stops. From what I can tell, it only tries once. We should consi...Calling `User.delete/1` triggers a background job to delete the user, but sometimes it's slow and/or doesn't seem to work. We're speculating that maybe it hits an error and stops. From what I can tell, it only tries once. We should consider letting it retry more. Ideally we'll find and fix the error.
https://gleasonator.com/@alex/posts/A8K4hwbb7iMtyVa0OWhttps://git.pleroma.social/pleroma/pleroma/-/issues/2673Search API returns 500 error2023-05-08T02:00:27ZFikran Mutasa'ilSearch API returns 500 errorHi all,
I am receiving 500 errors in rapid succession when I attempt to search for a user.
While using Soapbox
```
Jun 11 22:56:08 think pleroma[3443]: [info] GET /api/v1/accounts/search
Jun 11 22:56:08 think pleroma[3443]: request_id=...Hi all,
I am receiving 500 errors in rapid succession when I attempt to search for a user.
While using Soapbox
```
Jun 11 22:56:08 think pleroma[3443]: [info] GET /api/v1/accounts/search
Jun 11 22:56:08 think pleroma[3443]: request_id=FoepJWisOqPR0LIAACXi [info] Sent 500 in 6ms
```
While using Pleroma-FE
```
Jun 11 23:00:05 think pleroma[3443]: [info] GET /api/v2/search
Jun 11 23:00:05 think pleroma[3443]: request_id=FoepXHJtNwRA4oAAAEpB [info] Sent 500 in 8ms
```
Backend Version: 2.3.0-1-gb221d77a
Frontend Version: c3fcbbd9
I am using Erlang 22.
I recently switched this instance from FreeBSD to Linux. However, I had the same issue on FreeBSD.
Please help on how I can debug and resolve this issue :)https://git.pleroma.social/pleroma/pleroma/-/issues/2672Enable a frontend through the CLI2023-05-08T02:00:52ZAlex GleasonEnable a frontend through the CLIFor a while I've been avoiding using (and recommending) the switchable frontends feature. I tried it out once and was not sure it really worked.
Since maintaining my own fork, it turned out to be the perfect solution to shipping my own ...For a while I've been avoiding using (and recommending) the switchable frontends feature. I tried it out once and was not sure it really worked.
Since maintaining my own fork, it turned out to be the perfect solution to shipping my own FE without merge conflicts. I actually just dumped the FE into `instance/static/frontends/soapbox-fe/vendor` and checked it into git, then set it as the default for my fork:
```elixir
# Set Soapbox FE as the default frontend
config :pleroma, :frontends, primary: %{"name" => "soapbox-fe", "ref" => "vendor"}
```
However, my repo has already grown to an unwieldy size because of it:
![Screenshot_from_2021-06-11_12-32-02](/uploads/e3c0057524ffeb43d20dcf1887d6a89e/Screenshot_from_2021-06-11_12-32-02.png)
And I've accidentally messed up the static files in a release already, causing a white screen... https://gitlab.com/soapbox-pub/soapbox/-/issues/18#note_582296792
In order for me to continue doing releases, I think I need to make full use of switchable frontends so I don't have to check static files into the repo anymore.
The main barrier I see is the `mix pleroma.frontend install` command. We have to instruct users to install the frontend during install/upgrade, but this command doesn't actually do what I expect.
The reason I believed it didn't work before is because it doesn't *enable* the frontend. It only *downloads* the frontend. There is no way to enable a frontend through the CLI. I'm surprised it's not called `mix pleroma.frontend download`.
If `configurable_from_database` is enabled, it should set the frontend when you run this task. Otherwise it should instruct the user on how to update their config.
Apart from that, installing the frontend could become a one-liner in the install guide. And maybe it would make releases easier for you guys too.https://git.pleroma.social/pleroma/pleroma/-/issues/2671[Feature Request] Authenticated timeline rss feeds2023-05-08T02:02:01Zshibao[Feature Request] Authenticated timeline rss feedsSuggestion: Authenticated timeline RSS feeds using simple HTTP Authentication.
Would anyone else be interested in this feature? It might be necessary to allow the user to query a certain number of posts to avoid missing posts depending o...Suggestion: Authenticated timeline RSS feeds using simple HTTP Authentication.
Would anyone else be interested in this feature? It might be necessary to allow the user to query a certain number of posts to avoid missing posts depending on how fast their timeline is, with a server-wide configurable max value.https://git.pleroma.social/pleroma/pleroma/-/issues/2669Push notifications and link previews replace newlines with spaces2023-05-08T02:01:54ZfeldPush notifications and link previews replace newlines with spacesLast discussed here: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3456#note_85562Last discussed here: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3456#note_85562https://git.pleroma.social/pleroma/pleroma/-/issues/2666Posts from deactivated users are still visible2023-05-08T01:59:01ZSean KingPosts from deactivated users are still visibleAfter deactivating a remote user, I still could see their posts on my site despite being told this would make their posts not visible. This is a major problem if we're dealing with folks who posted something illegal (i.e. CSAM).After deactivating a remote user, I still could see their posts on my site despite being told this would make their posts not visible. This is a major problem if we're dealing with folks who posted something illegal (i.e. CSAM).https://git.pleroma.social/pleroma/pleroma/-/issues/2664Throttle report endpoint2023-05-08T02:03:14Zopal hartgit.pleroma.social@wowana.meThrottle report endpointRelated to #2663 but in the form of a feature request rather than a question.
This is a proposal to add a rate limiter to the report endpoint so that it cannot easily be used as a SPAM vector. I have had issues from one person who has s...Related to #2663 but in the form of a feature request rather than a question.
This is a proposal to add a rate limiter to the report endpoint so that it cannot easily be used as a SPAM vector. I have had issues from one person who has sent out dozens of reports in the timeframe of a few minutes, sending notifications to my E-mail and causing a lot of noise. For one actor, this is easy to deal with, since the account can be deactivated and all associated reports from that actor disappear.
For Mastodon anonymised reports, though, this is more difficult to deal with, because deactivating a service actor will prevent that instance from sending reports entirely.
pleroma/admin-fe#149 would also be useful for handling such reports en masse.https://git.pleroma.social/pleroma/pleroma/-/issues/2663How to remove all reports from every instances?2023-05-08T02:03:32ZSnowHow to remove all reports from every instances?There are tons for SPAM from Mastodon instances by the reporting function. I don't care about reports since I am a one-person instance.
Or how to remove all reports from every Mastodon instances?
![b5da0ab757](/uploads/42ad7a1d864813e...There are tons for SPAM from Mastodon instances by the reporting function. I don't care about reports since I am a one-person instance.
Or how to remove all reports from every Mastodon instances?
![b5da0ab757](/uploads/42ad7a1d864813e7e538108eb3490126/b5da0ab757.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2661Request: Allow instances to obscure individual reporter account when forwardi...2023-05-08T00:48:04ZerisRequest: Allow instances to obscure individual reporter account when forwarding reportsWhen a Mastodon instance forwards a report to another instance, it obscures the account of the individual reporter, and only shows the instance information instead to prevent harassment against the user as a result of that report.
As an...When a Mastodon instance forwards a report to another instance, it obscures the account of the individual reporter, and only shows the instance information instead to prevent harassment against the user as a result of that report.
As an example, here's a report on one of my users from random anonymous user @ godforsaken.website, who's info is appropriately protected when forwarded to my instance
![report_2](/uploads/ddda1391d420fefa4ce1b7c23fc6c926/report_2.png)
I believe Mastodon's code for doing so is here:
https://github.com/tootsuite/mastodon/blob/main/app/services/report_service.rb#L55
so it seems like something that should be possible on Pleroma.
I know the inevitable hesitation towards this option will be the potential for report abuse, but that's avoidable with a simple declining of reports from a specific instance, as I did in the case of the above report and never had any further issues, so I don't think the risk of that outweighs the reality of our instances bringing harassment onto individual users when they forward a report in good faith.
We could avoid having the pleroma project having to make that decision of which is the bigger risk by having instance admins configure it through admin-fe based on their personal beliefs.
Thank you!https://git.pleroma.social/pleroma/pleroma/-/issues/2659Pleroma fetching old posts of newly discovered users2023-05-08T02:04:54ZvaartisPleroma fetching old posts of newly discovered usersSince recently, pleroma started fetching a lot of posts of newly discovered users. It's almost always very old posts. Sometimes there's several tens of them.
It started recently after an update. According to reflog, 745375bdc is the on...Since recently, pleroma started fetching a lot of posts of newly discovered users. It's almost always very old posts. Sometimes there's several tens of them.
It started recently after an update. According to reflog, 745375bdc is the one that has it and a9bc652ab is probably the one that does not.
My theory is that it's something with the pinned post fetching: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3312
It lies in the aforementioned commit range and pinned posts are usually old. It would seem that it _may_ be fetching entire pages instead of single pinned posts.
The problem is that it happens for all newly discovered users and their year old posts come flooding the twkn, which is very annoying and makes it practically unusable.https://git.pleroma.social/pleroma/pleroma/-/issues/2658Reducing massive fetches(DDoS) with link previews2023-05-08T02:02:20ZHaelwennReducing massive fetches(DDoS) with link previewsThe load created by fetching previews has been an ongoing issue for a serious while, by default pleroma+mastodon is basically rendering some websites offline, enough that sometimes I avoid making some URLs an actual link.
I have these i...The load created by fetching previews has been an ongoing issue for a serious while, by default pleroma+mastodon is basically rendering some websites offline, enough that sometimes I avoid making some URLs an actual link.
I have these ideas:
- Shared proxies, maybe by reusing media proxies because technically you could put anything that you want as attachment URL, thus doing the same thing as previews but even worse, that said most users likely aren't going to use custom URLs so non-malicious use gets better.
- Embedding the preview data in the post, this means giving up on having reliable-enough data to show but with custom HTML + a false page you can confuse quite a lot of clients.
I put a false page on https://hacktivis.me/tmp/joinmastodon.org.html around 2020-02-14, it's just an HTML file with
```html
<meta property="og:image" content="https://hacktivis.me/datalove/img/meme/pleroma/mastodon%2C%20forbidden%20amuse%20yourself.jpeg" />
<meta property="og:title" content="Mastodon: Forbidden Amuse Yourself" />
<meta property="og:site_name" content="joinmastodon.org" />
<meta http-equiv="refresh" content="0; url=http://joinmastodon.org/">
```
And I'd *much* rather have link previews being disabled (by default?) until we figure out a better way.https://git.pleroma.social/pleroma/pleroma/-/issues/2655AdminAPI: return system information2023-05-08T02:05:06ZAlex GleasonAdminAPI: return system informationI'd like an endpoint like GET `/api/v1/pleroma/admin/system` to return data like:
- Pleroma version
- Postgres version
- Elixir version
- Erlang version<sup>[[1]]</sup>
[1]: https://stackoverflow.com/a/34326368
```json
{
"pleroma_ve...I'd like an endpoint like GET `/api/v1/pleroma/admin/system` to return data like:
- Pleroma version
- Postgres version
- Elixir version
- Erlang version<sup>[[1]]</sup>
[1]: https://stackoverflow.com/a/34326368
```json
{
"pleroma_version": "2.3.0",
"postgres_version": "12.7",
"elixir_version": "1.11",
"erlang_version": "23.3.4"
}
```
It could potentially be expanded to include more info like host OS, and so on.https://git.pleroma.social/pleroma/pleroma/-/issues/2653[function request] Import and export relay list2023-05-08T02:05:25ZSnow[function request] Import and export relay list![5b74fc3f59](/uploads/6f76ed6b8ffb6e133c45d481880828cb/5b74fc3f59.png)
It's tough as hell that adding 400 relays one by one here...![5b74fc3f59](/uploads/6f76ed6b8ffb6e133c45d481880828cb/5b74fc3f59.png)
It's tough as hell that adding 400 relays one by one here...https://git.pleroma.social/pleroma/pleroma/-/issues/2652It's plain as hell to delete all accounts from twitiverse.com2023-05-08T02:05:34ZSnowIt's plain as hell to delete all accounts from twitiverse.comAll accounts from there are bots, and there are over 5000 of them in the database.All accounts from there are bots, and there are over 5000 of them in the database.https://git.pleroma.social/pleroma/pleroma/-/issues/2650The last hashtag will be ignored when posting in markdown2023-05-08T01:38:38Zf2The last hashtag will be ignored when posting in markdown## đĄ Summary
The last hashtag will be ignored when posting in markdown or previewing.
## đ Expected Behavior
In the example below, I actually entered three hashtags, but only the first two are reflected.
![image](/uploads/a9a142a42fe...## đĄ Summary
The last hashtag will be ignored when posting in markdown or previewing.
## đ Expected Behavior
In the example below, I actually entered three hashtags, but only the first two are reflected.
![image](/uploads/a9a142a42fee85cbdba744bb184c47f2/image.png)
## âšī¸ Actual Behavior
The following example is in plain text, but the same interpretation should be applied to markdown.
![image](/uploads/c4132f4d9eb98567e56f0313f055dfec/image.png)
## đ Steps to Reproduce
Use two or more hashtags in a row. If you write a continuation sentence after it, this bug will not occur.
Translated with www.DeepL.com/Translator (free version)https://git.pleroma.social/pleroma/pleroma/-/issues/2645No authentication for healthcheck endpoint?2023-05-08T02:06:01ZFrinkeldoodleNo authentication for healthcheck endpoint?I was looking through my monitoring solutions and kinda thought about how much information is in the healthcheck endpoint, which doesn't appear to have any options to require authentication, and gives what feels like a fair bit of info. ...I was looking through my monitoring solutions and kinda thought about how much information is in the healthcheck endpoint, which doesn't appear to have any options to require authentication, and gives what feels like a fair bit of info. While I'm sure it's possible I'm just being a bit paranoid here, I do have to wonder if it's giving a bit too much without asking for any sort of authentication? I feel like it'd make more sense to just return a simple healthy true or false if unauthenticated, and only give more details if authenticated.https://git.pleroma.social/pleroma/pleroma/-/issues/2644Can't upload files anymore using S32023-05-08T02:07:33ZSasha EponaCan't upload files anymore using S3<!--
### 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): container image (https://github.com/innereq/containers/blob/master/pleroma/Dockerfile)
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.3.50-0-g745375b-develop
* Elixir version (`elixir -v` for from source installations, N/A for OTP): OTP
* Operating system: Fedora 32, Podman 2.2.1
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 12.6
### Bug description
Users of my server at https://sect.sunbutt.faith reported that uploading stopped working. It's true, uploading causes these cryptic errors:
```
19:35:58.433 [info] POST /api/v1/media
19:35:58.455 request_id=FnyRVJZtu_bRMUEAABIE [error] Internal server error: %CaseClauseError{term: {:EXIT, {:noproc, {:gen_server, :call, [#PID<0.6741.0>, {:checkout, {'s3.eu-central-1.wasabisys.com', 443, :hackney_ssl}, #PID<0.8030.0>, #Reference<0.1827926764.2013790210.6572>}, 5000]}}}}
19:35:58.455 request_id=FnyRVJZtu_bRMUEAABIE [info] Sent 500 in 22ms
19:35:58.456 [error] #PID<0.8030.0> running Pleroma.Web.Endpoint (connection #PID<0.8029.0>, stream id 1) terminated
Server: sect.sunbutt.faith:80 (http)
Request: POST /api/v1/media
** (exit) an exception was raised:
** (CaseClauseError) no case clause matching: {:EXIT, {:noproc, {:gen_server, :call, [#PID<0.6741.0>, {:checkout, {'s3.eu-central-1.wasabisys.com', 443, :hackney_ssl}, #PID<0.8030.0>, #Reference<0.1827926764.2013790210.6572>}, 5000]}}}
(hackney) /build/deps/hackney/src/hackney_pool.erl:72: :hackney_pool.checkout/4
(hackney) /build/deps/hackney/src/hackney_connect.erl:217: :hackney_connect.socket_from_pool/4
(hackney) /build/deps/hackney/src/hackney_connect.erl:47: :hackney_connect.connect/5
(hackney) /build/deps/hackney/src/hackney.erl:333: :hackney.request/5
(tesla) lib/tesla/adapter/hackney.ex:71: Tesla.Adapter.Hackney.request/5
(tesla) lib/tesla/adapter/hackney.ex:33: Tesla.Adapter.Hackney.call/2
(pleroma) lib/pleroma/http/ex_aws.ex:16: Pleroma.HTTP.ExAws.request/5
(ex_aws) lib/ex_aws/request.ex:42: ExAws.Request.request_and_retry/7
```
With enabled debug log level:
```
20:15:21.476 [info] POST /api/v1/media
20:15:21.476 request_id=FnyTesbHGfnkW48AACri [debug] POST /api/v1/media
20:15:21.484 request_id=FnyTesbHGfnkW48AACri [debug] Processing with Pleroma.Web.MastodonAPI.MediaController.create/2
Parameters: %{"file" => %Plug.Upload{content_type: "image/png", filename: "matrix-p2p.png", path: "/tmp/plug-1620/multipart-1620332121-106971859079583-3"}}
Pipelines: [:authenticated_api]
20:15:21.486 request_id=FnyTesbHGfnkW48AACri [debug] QUERY OK source="oauth_tokens" db=1.9ms idle=174.6ms
SELECT o0."id", o0."token", o0."refresh_token", o0."scopes", o0."valid_until", o0."user_id", o0."app_id", o0."inserted_at", o0."updated_at", u1."id", u1."bio", u1."raw_bio", u1."email", u1."name", u1."nickname", u1."password_hash", u1."keys", u1."public_key", u1."ap_id", u1."avatar", u1."local", u1."follower_address", u1."following_address", u1."featured_address", u1."tags", u1."last_refreshed_at", u1."last_digest_emailed_at", u1."banner", u1."background", u1."note_count", u1."follower_count", u1."following_count", u1."is_locked", u1."is_confirmed", u1."password_reset_pending", u1."is_approved", u1."registration_reason", u1."confirmation_token", u1."default_scope", u1."domain_blocks", u1."is_active", u1."no_rich_text", u1."ap_enabled", u1."is_moderator", u1."is_admin", u1."show_role", u1."mastofe_settings", u1."uri", u1."hide_followers_count", u1."hide_follows_count", u1."hide_followers", u1."hide_follows", u1."hide_favorites", u1."email_notifications", u1."mascot", u1."emoji", u1."pleroma_settings_store", u1."fields", u1."raw_fields", u1."is_discoverable", u1."invisible", u1."allow_following_move", u1."skip_thread_containment", u1."actor_type", u1."also_known_as", u1."inbox", u1."shared_inbox", u1."accepts_chat_messages", u1."last_active_at", u1."disclose_client", u1."pinned_objects", u1."notification_settings", u1."blocks", u1."mutes", u1."muted_reblogs", u1."muted_notifications", u1."subscribers", u1."multi_factor_authentication_settings", u1."inserted_at", u1."updated_at" FROM "oauth_tokens" AS o0 INNER JOIN "users" AS u1 ON u1."id" = o0."user_id" WHERE (o0."token" = $1) ["REDACTED JUST IN CASE"]
20:15:21.497 request_id=FnyTesbHGfnkW48AACri [error] Internal server error: %CaseClauseError{term: {:EXIT, {:noproc, {:gen_server, :call, [#PID<0.6741.0>, {:checkout, {'s3.eu-central-1.wasabisys.com', 443, :hackney_ssl}, #PID<0.8275.0>, #Reference<0.357438633.3093299203.8139>}, 5000]}}}}
20:15:21.497 request_id=FnyTesbHGfnkW48AACri [debug] Sent 500 in 21ms
20:15:21.497 request_id=FnyTesbHGfnkW48AACri [info] Sent 500 in 21ms
20:15:21.497 request_id=FnyTesbHGfnkW48AACri [debug] Converted error {:case_clause, {:EXIT, {:noproc, {:gen_server, :call, [#PID<0.6741.0>, {:checkout, {'s3.eu-central-1.wasabisys.com', 443, :hackney_ssl}, #PID<0.8275.0>, #Reference<0.357438633.3093299203.8139>}, 5000]}}}} to 500 response
20:15:21.499 [error] #PID<0.8275.0> running Pleroma.Web.Endpoint (connection #PID<0.8274.0>, stream id 1) terminated
Server: sect.sunbutt.faith:80 (http)
Request: POST /api/v1/media
** (exit) an exception was raised:
** (CaseClauseError) no case clause matching: {:EXIT, {:noproc, {:gen_server, :call, [#PID<0.6741.0>, {:checkout, {'s3.eu-central-1.wasabisys.com', 443, :hackney_ssl}, #PID<0.8275.0>, #Reference<0.357438633.3093299203.8139>}, 5000]}}}
(hackney) /build/deps/hackney/src/hackney_pool.erl:72: :hackney_pool.checkout/4
(hackney) /build/deps/hackney/src/hackney_connect.erl:217: :hackney_connect.socket_from_pool/4
(hackney) /build/deps/hackney/src/hackney_connect.erl:47: :hackney_connect.connect/5
(hackney) /build/deps/hackney/src/hackney.erl:333: :hackney.request/5
(tesla) lib/tesla/adapter/hackney.ex:71: Tesla.Adapter.Hackney.request/5
(tesla) lib/tesla/adapter/hackney.ex:33: Tesla.Adapter.Hackney.call/2
(pleroma) lib/pleroma/http/ex_aws.ex:16: Pleroma.HTTP.ExAws.request/5
(ex_aws) lib/ex_aws/request.ex:42: ExAws.Request.request_and_retry/7
```
But already uploaded attachments are reachable just fine. I use Wasabi S3 as main storage and BunnyCDN for caching. They are both working.
nginx log just in case:
```
10.88.0.1 - - [06/May/2021:20:12:38 +0000] "GET /api/v1/timelines/public?since_id=A6z17wykfpYONytcTw&local=true&only_media=false&with_muted=true&limit=20 HTTP/1.1" 200 2 "https://sect.sunbutt.faith/main/public" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0" "195.138.76.37"
2021/05/06 20:12:39 [warn] 31#31: *34 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000001, client: 10.88.0.1, server: sect.sunbutt.faith, request: "POST /api/v1/media HTTP/1.1", host: "sect.sunbutt.faith", referrer: "https://sect.sunbutt.faith/main/public"
10.88.0.1 - - [06/May/2021:20:12:39 +0000] "POST /api/v1/media HTTP/1.1" 500 45 "https://sect.sunbutt.faith/main/public" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0" "195.138.76.37"
```
Any ideas what can be wrong here?https://git.pleroma.social/pleroma/pleroma/-/issues/2641outbox min_id doesn't work2023-05-08T02:07:39Znormandyoutbox min_id doesn't work<!--
### 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): OTP
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.3.0-1-gb221d77a
* Elixir version (`elixir -v` for from source installations, N/A for OTP): N/A
* Operating system: Ubuntu 20.04 LTS
* PostgreSQL version (`psql -V`): 12.2
### Bug description
Making a GET request to /users/:user/outbox with the parameters page=true and min_id set results in an error:
```
$ curl -H 'Accept: application/json' 'https://biribiri.dev/users/normandy/outbox?page=true&min_id=02a632be-26d1-4b8e-9b8e-ec5ad52f49d9'
{"errors":{"detail":"Internal server error"}}
```https://git.pleroma.social/pleroma/pleroma/-/issues/26402.3.0 - Raw HTML entities are rendered in chat notifications instead of the a...2023-05-08T02:07:59ZMichael Collinsmichael.collins@bofhllc.net2.3.0 - Raw HTML entities are rendered in chat notifications instead of the actual symbols.Tested in Google Chrome (unknown version) and Microsoft Edge 90.x.x.x:
![image](/uploads/b2b36066e8eafa5e0a4b21e0b5ef8af9/image.png)
To reproduce:
Be in a chat with somebody else on your instance.
Alt+Tab away to a different window.
...Tested in Google Chrome (unknown version) and Microsoft Edge 90.x.x.x:
![image](/uploads/b2b36066e8eafa5e0a4b21e0b5ef8af9/image.png)
To reproduce:
Be in a chat with somebody else on your instance.
Alt+Tab away to a different window.
Have the person you're chatting with send you a chat message that has a one or more double-quotes.
The notification that actually gets rendered on your screen shows the HTML-entity for double-quotes (`"`) instead of the double-quotes themselves (`"..."`).https://git.pleroma.social/pleroma/pleroma/-/issues/2638[ActivityPub C2S] json+ld type vs. @type2023-05-08T02:04:14Znaturzukunft[ActivityPub C2S] json+ld type vs. @type### Bug description
Its possible to send the activity:
```
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Create",
"actor": "https://mustermann.xyusers/abcde",
"object": {
"type": "Note",
...### Bug description
Its possible to send the activity:
```
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Create",
"actor": "https://mustermann.xyusers/abcde",
"object": {
"type": "Note",
"content": "Test"
}
}
```
But if i use @type instead the POST breaks with "Unhandled activity type"
```
{
"@context": "https://www.w3.org/ns/activitystreams",
"@type": "Create",
"actor": "https://mustermann.xyusers/abcde",
"object": {
"type": "Note",
"content": "Test"
}
}
```
i think @type should be valid ! See: https://json-ld.org/spec/latest/json-ld/#specifying-the-type
I looks also like that it's not possible to send an array of types.
Best regards