pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-05-08T00:58:52Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/2967Pleroma does not respect http proxy proxy settings when sending emails2023-05-08T00:58:52ZYour New SJW WaifuPleroma does not respect http proxy proxy settings when sending emails<!--
### 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): 705ba6d6
* 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) 15.0 (Ubuntu 15.0-1.pgdg22.04+1)`
### Bug description
Set
```
config :pleroma, :http,
proxy_url: "$host:$port"
```
#### Expected behaviour
All connections are sent through the proxy **including SMTP**
#### Actual behaviour
Everything except SMTP connections are passed through the proxy
#### Better approach
Seperate proxy settings for email and federation (like Misskey offers)https://git.pleroma.social/pleroma/pleroma/-/issues/2966beam.smp eating cpu and ram2023-05-08T00:29:46Ztwlbeam.smp eating cpu and ram<!--
### 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: Source
* Pleroma version: 2.4.3
* Elixir version: Erlang/OTP 23 [erts-11.1.8] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1]; Elixir 1.10.3 (compiled with Erlang/OTP 22)
* Operating system: Debian 11.5
* PostgreSQL version: 13.8
### Bug description
I'm on a vps with one dedicated core (AMD Ryzen 9 3900X) and 4GB of ram, pleroma-fe has become practically unusable, loading profiles, threads and other things cause the beam.smp process to consume up to 3GB of memory and 100% of cpu. Making a post (with or without attachments) or loading a large thread causes it to run out of memory and crash unless i use swap space.
What I've tried so far to troubleshoot is [disabling elixir's busy waiting](https://docs-develop.pleroma.social/backend/configuration/optimizing_beam/#virtual-machine-andor-few-cpu-cores), changed postgresql's settings to not use as much ram, but i haven't seen any improvements.
It was suggested to me to check the oban queue, so here is the output from that:
```
pleroma=# select count((state,args->'params'->'type')), (state,args->'params'->'type') from oban_jobs where state not in ('completed') group by (state,args->'params'->'type') order by count((state,args->'params'->'type'));
count | row
-------+------------------------------
1 | (executing,"""Undo""")
1 | (executing,"""View""")
6 | (executing,"""EmojiReact""")
17 | (discarded,"""Delete""")
18 | (retryable,"""Delete""")
25 | (executing,"""Like""")
42 | (executing,"""Create""")
49 | (executing,"""Delete""")
82 | (available,)
104 | (executing,"""Announce""")
221 | (executing,)
(11 rows)
pleroma=# select worker, count(worker) from oban_jobs where state not in ('completed') group by worker order by count(worker);
worker | count
------------------------------------------+-------
Pleroma.Workers.WebPusherWorker | 3
Pleroma.Workers.PublisherWorker | 54
Pleroma.Workers.Cron.DigestEmailsWorker | 82
Pleroma.Workers.AttachmentsCleanupWorker | 164
Pleroma.Workers.ReceiverWorker | 259
(5 rows)
```
I moved pleroma to this server about 12 days ago, but these issues started only a week ago, I'm not sure if it's relevant but I was not able to restore the database with ``pg_restore`` because it got stuck at ``create INDEX "public.activities_recipients_index"`` letting the CPU run at 100% but nothing was really happening, what i did instead was just rsync the postgres data directory from the old server to the new one and that seemed to work but I'm not sure if that caused any side-effects that's related to this issue.https://git.pleroma.social/pleroma/pleroma/-/issues/2957weird remote user issue2023-05-08T00:55:18ZMoon Manweird remote user issuehttps://cum.camp/notice/AOX30ELD2BA9YwvGzY
https://shitposter.club/notice/AOX324jn2pvoe42XHk
user shows up on my side as $undefined and the reply name is internal.fetch@cum.camp
![2022-10-13_13-59](/uploads/ecc920b913878a2c575e54159d94...https://cum.camp/notice/AOX30ELD2BA9YwvGzY
https://shitposter.club/notice/AOX324jn2pvoe42XHk
user shows up on my side as $undefined and the reply name is internal.fetch@cum.camp
![2022-10-13_13-59](/uploads/ecc920b913878a2c575e54159d94a1ef/2022-10-13_13-59.png)
![2022-10-13_14-02](/uploads/7d58e4ecd6a40b4968881d393eec7354/2022-10-13_14-02.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2956url preview requesting off-site resource2023-05-08T00:59:57ZMoon Manurl preview requesting off-site resourcehttps://shitposter.club/notice/AOOdLpYiCqe8JydQxc
the preview is making a an http call to amazon.comhttps://shitposter.club/notice/AOOdLpYiCqe8JydQxc
the preview is making a an http call to amazon.comhttps://git.pleroma.social/pleroma/pleroma/-/issues/2951Emoji rendering in markdown code block?2023-05-08T01:00:37ZfeldEmoji rendering in markdown code block?I'm pretty sure this isn't right, but it's hilarious!
![image](/uploads/881d126f28368cd3b43133da01853875/image.png)I'm pretty sure this isn't right, but it's hilarious!
![image](/uploads/881d126f28368cd3b43133da01853875/image.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2950** (UndefinedFunctionError) function :crypto.strong_rand_bytes/1 is undefined...2023-08-02T22:03:33ZStéphane Bortzmeyer** (UndefinedFunctionError) function :crypto.strong_rand_bytes/1 is undefined (module :crypto is not available)When running `sudo -u pleroma /usr/local/pleroma/bin/pleroma_ctl instance gen`, I get:
```
What is the hostname of your database? [localhost]
What is the name of your database? [pleroma]
What is the user used to connect to your dat...When running `sudo -u pleroma /usr/local/pleroma/bin/pleroma_ctl instance gen`, I get:
```
What is the hostname of your database? [localhost]
What is the name of your database? [pleroma]
What is the user used to connect to your database? [pleroma]
** (UndefinedFunctionError) function :crypto.strong_rand_bytes/1 is undefined (module :crypto is not available)
:crypto.strong_rand_bytes(64)
(pleroma 2.4.3) lib/mix/tasks/pleroma/instance.ex:118: Mix.Tasks.Pleroma.Instance.run/1
(stdlib 3.12.1.2) erl_eval.erl:680: :erl_eval.do_apply/6
(elixir 1.10.4) lib/code.ex:341: Code.eval_string_with_error_handling/3
```
Pleroma installed from release `https://git.pleroma.social/api/v4/projects/2/jobs/artifacts/stable/download?job=arm-musl to /tmp/pleroma.zip` . (Cannot get a more detailed version, `pleroma_ctl` does not seem able to display a version.)
```
% elixir -v
Erlang/OTP 25 [erts-13.0.3] [source] [32-bit] [smp:2:2] [ds:2:2:10] [async-threads:1]
Elixir 1.14.0 (compiled with Erlang/OTP 25)
```
Running on Alpine Linux:
```
% cat /etc/alpine-release
3.17_alpha20220809
```
```
% openssl version
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
```
```
% psql -V
psql (PostgreSQL) 14.5
```
(probably irrelevant)
I'm aware of the various bugs producing a similar error message when there is a wrong version of OpenSSL compiled in (for instance #1124). But, here, Elixir seems fine:
```
% iex
Erlang/OTP 25 [erts-13.0.3] [source] [32-bit] [smp:2:2] [ds:2:2:10] [async-threads:1]
Interactive Elixir (1.14.0) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> :crypto.strong_rand_bytes(10)
<<84, 17, 126, 227, 194, 96, 241, 26, 149, 174>>
```
Is it possible that the Pleroma release was compiled with an old version of OpenSSL? And therefore I have to compile from sources?https://git.pleroma.social/pleroma/pleroma/-/issues/2949Crashes after 24 hours2023-05-08T00:58:58ZJoYoCrashes after 24 hours### Precheck
I've commented on a few issues I thought was relevant but it either wasn't applicable or the issue was closed without resolution.
### Environment
* Docker image
* Backend version: 2.4.52-665-ga022b9d7
* Frontend version: ...### Precheck
I've commented on a few issues I thought was relevant but it either wasn't applicable or the issue was closed without resolution.
### Environment
* Docker image
* Backend version: 2.4.52-665-ga022b9d7
* Frontend version: b13d8f7e
* Elixir image
* PostgreSQL 14
### Bug description
I've had to restart the server every 24 hours to resume operation.
Before restarting I've noted that resource usage is normal, the server is not out of memory or storage.
I was having this issue before I updated postgres to 14 from 12.
I restarted with a fresh database when I updated postgres.
```
pleroma | 06:39:11.405 [error] GenServer {Oban.Registry, {Oban, {:producer, "remote_fetcher"}}} terminating
pleroma | ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 1406ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
pleroma |
pleroma | 1. Ensuring your database is available and that you can connect to it
pleroma | 2. Tracking down slow queries and making sure they are running fast enough
pleroma | 3. Increasing the pool_size (albeit it increases resource consumption)
pleroma | 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
pleroma |
pleroma | See DBConnection.start_link/2 for more information
pleroma |
pleroma | (db_connection) lib/db_connection.ex:784: DBConnection.run/3
pleroma | (stdlib) gen_server.erl:637: :gen_server.try_dispatch/4
pleroma | (stdlib) gen_server.erl:711: :gen_server.handle_msg/6
pleroma | (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
pleroma | Last message: :poll
pleroma | State: %Oban.Queue.Producer.State{circuit: :enabled, conf: %Oban.Config{circuit_backoff: 30000, crontab: [{%Oban.Crontab.Cron{days: [:*], hours: [0], minutes: [0], months: [:*], reboot: false, weekdays: [0]}, Pleroma.Workers.Cron.DigestEmailsWorker, []}, {%Oban.Crontab.Cron{days: [:*], hours: [0], minutes: [0], months: [:*], reboot: false, weekdays: [:*]}, Pleroma.Workers.Cron.NewUsersDigestWorker, []}], dispatch_cooldown: 5, get_dynamic_repo: nil, log: false, name: Oban, node: "pleroma@127.0.0.1", plugins: [Oban.Plugins.Pruner], poll_interval: 1000, prefix: "public", queues: [activity_expiration: [limit: 10], token_expiration: [limit: 5], filter_expiration: [limit: 1], backup: [limit: 1], ingestion_queue: [limit: 50], web_push: [limit: 50], mailer: [limit: 10], transmogrifier: [limit: 20], scheduled_activities: [limit: 10], poll_notifications: [limit: 10], background: [limit: 5], remote_fetcher: [limit: 2], attachments_cleanup: [limit: 1], new_users_digest: [limit: 1], mute_expire: [limit: 5], federator_incoming: [limit: 5], federator_outgoing: [limit: 5]], repo: Pleroma.Repo, shutdown_grace_period: 15000, timezone: "Etc/UTC"}, cooldown_ref: nil, dispatch_cooldown: 5, dispatched_at: nil, foreman: {:via, Registry, {Oban.Registry, {Oban, {:foreman, "remote_fetcher"}}}}, limit: 2, name: {:via, Registry, {Oban.Registry, {Oban, {:producer, "remote_fetcher"}}}}, nonce: "a4434vm4", paused: false, poll_interval: 1000, queue: "remote_fetcher", reset_timer: nil, running: %{}, started_at: ~U[2022-09-21 06:39:08.797511Z], timer: #Reference<0.582941313.985137153.190663>}
pleroma |
pleroma | 06:39:11.727 [info] Application pleroma exited: shutdown
```
```
postgres_1 | 2022-09-21 06:38:53.891 UTC [3511] LOG: could not send data to client: Broken pipe
postgres_1 | 2022-09-21 06:38:54.503 UTC [3180] ERROR: canceling statement due to user request
postgres_1 | 2022-09-21 06:38:54.503 UTC [3180] STATEMENT: UPDATE "public"."oban_jobs" AS o0 SET "state" = $1 WHERE (o0."id" IN (SELECT so0."id" FROM "public"."oban_jobs" AS so0 WHERE (so0."state" IN ('scheduled','retryable')) AND (so0."queue" = $2) AND (so0."scheduled_at" <= $3) FOR UPDATE SKIP LOCKED))
postgres_1 | 2022-09-21 06:38:54.090 UTC [3511] FATAL: connection to client lost
postgres_1 | 2022-09-21 06:38:54.554 UTC [56] LOG: could not send data to client: Broken pipe
postgres_1 | 2022-09-21 06:38:54.550 UTC [2732] LOG: could not send data to client: Broken pipe
postgres_1 | 2022-09-21 06:38:56.084 UTC [56] FATAL: connection to client lost
postgres_1 | 2022-09-21 06:38:57.359 UTC [2732] FATAL: connection to client lost
postgres_1 | 2022-09-21 06:38:57.323 UTC [2734] LOG: could not send data to client: Broken pipe
postgres_1 | 2022-09-21 06:39:01.301 UTC [2733] ERROR: canceling statement due to user request
postgres_1 | 2022-09-21 06:39:01.301 UTC [2733] STATEMENT: UPDATE "public"."oban_jobs" AS o0 SET "state" = $1 WHERE (o0."id" IN (SELECT so0."id" FROM "public"."oban_jobs" AS so0 WHERE (so0."state" IN ('scheduled','retryable')) AND (so0."queue" = $2) AND (so0."scheduled_at" <= $3) FOR UPDATE SKIP LOCKED))
postgres_1 | 2022-09-21 06:38:58.512 UTC [2734] FATAL: connection to client lost
postgres_1 | 2022-09-21 06:39:04.599 UTC [3180] LOG: could not send data to client: Broken pipe
postgres_1 | 2022-09-21 06:39:07.557 UTC [3180] FATAL: connection to client lost
postgres_1 | 2022-09-21 06:39:07.630 UTC [2733] LOG: could not send data to client: Broken pipe
postgres_1 | 2022-09-21 06:39:08.148 UTC [2733] FATAL: connection to client lost
postgres_1 | 2022-09-21 06:39:08.200 UTC [3512] ERROR: canceling statement due to user request
postgres_1 | 2022-09-21 06:39:08.200 UTC [3512] STATEMENT: UPDATE "public"."oban_jobs" AS o0 SET "state" = $1 WHERE (o0."id" IN (SELECT so0."id" FROM "public"."oban_jobs" AS so0 WHERE (so0."state" IN ('scheduled','retryable')) AND (so0."queue" = $2) AND (so0."scheduled_at" <= $3) FOR UPDATE SKIP LOCKED))
postgres_1 | 2022-09-21 06:39:09.050 UTC [3181] ERROR: canceling statement due to user request
postgres_1 | 2022-09-21 06:39:09.050 UTC [3181] STATEMENT: DELETE FROM "public"."oban_jobs" AS o0 USING (SELECT so0."id" AS "id" FROM "public"."oban_jobs" AS so0 WHERE (so0."state" IN ('completed','cancelled','discarded')) AND (so0."attempted_at" < $1) LIMIT $2) AS s1 WHERE (o0."id" = s1."id")
postgres_1 | 2022-09-21 06:39:09.837 UTC [3512] LOG: could not send data to client: Broken pipe
postgres_1 | 2022-09-21 06:39:09.865 UTC [3512] FATAL: connection to client lost
postgres_1 | 2022-09-21 06:39:10.123 UTC [3179] ERROR: canceling statement due to user request
postgres_1 | 2022-09-21 06:39:10.123 UTC [3179] STATEMENT: UPDATE "public"."oban_jobs" AS o0 SET "state" = $1, "attempted_at" = $2, "attempted_by" = $3, "attempt" = o0."attempt" + $4 WHERE (o0."id" IN (SELECT so0."id" FROM "public"."oban_jobs" AS so0 WHERE (so0."state" = 'available') AND (so0."queue" = $5) ORDER BY so0."priority", so0."scheduled_at", so0."id" LIMIT $6 FOR UPDATE SKIP LOCKED)) RETURNING o0."id", o0."state", o0."queue", o0."worker", o0."args", o0."errors", o0."tags", o0."attempt", o0."attempted_by", o0."max_attempts", o0."meta", o0."priority", o0."attempted_at", o0."completed_at", o0."discarded_at", o0."cancelled_at", o0."inserted_at", o0."scheduled_at"
postgres_1 | 2022-09-21 06:39:11.189 UTC [3568] LOG: PID 3558 in cancel request did not match any process
```https://git.pleroma.social/pleroma/pleroma/-/issues/2939Federation with Lemmy not working due to HTTP Signature problems2023-05-08T00:54:16ZnutomicFederation with Lemmy not working due to HTTP Signature problemsFederation between Lemmy and Pleroma is currently not working correctly. It seems that activities sent from Lemmy are rejected due to problems with HTTP signatures (we are sending with [draft 11](https://datatracker.ietf.org/doc/html/dra...Federation between Lemmy and Pleroma is currently not working correctly. It seems that activities sent from Lemmy are rejected due to problems with HTTP signatures (we are sending with [draft 11](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-11)). I reproduced this between voyager.lemmy.ml and queer.hacktivis.me.
[Here is an issue on our tracker which includes error log from Pleroma](https://github.com/LemmyNet/lemmy/issues/1984#issuecomment-1245990154)
It would be great if you could add support for the mentioned draft of http signature standard, as it is already supported by most other projects. For testing you can use voyager.lemmy.ml, just tell me when you create an account so I can approve it.https://git.pleroma.social/pleroma/pleroma/-/issues/2938Pleroma.Web.RichMedia.Parser.parse timing out makes the whole connection timeout2023-05-08T01:00:27ZtusooaPleroma.Web.RichMedia.Parser.parse timing out makes the whole connection timeout
`Pleroma.Web.RichMedia.Parser.parse("https://news.yahoo.co.jp/articles/4d41e1f940a340daf30824003d637468ed336b28")`
this statement timed out forever making it impossible to render an activity containing it.
`Pleroma.Web.RichMedia.Parser.parse("https://news.yahoo.co.jp/articles/4d41e1f940a340daf30824003d637468ed336b28")`
this statement timed out forever making it impossible to render an activity containing it.https://git.pleroma.social/pleroma/pleroma/-/issues/2937DOCS: Maybe document using c2s-API somewhere2022-09-11T09:06:58ZIljaDOCS: Maybe document using c2s-API somewhereWe have c2s api. It's not that difficult, but I also don't think we really have documentation for it. Would be nice to have. I'm not exactly sure where or how it's best to document, though.
This is a working example to post an event (ch...We have c2s api. It's not that difficult, but I also don't think we really have documentation for it. Would be nice to have. I'm not exactly sure where or how it's best to document, though.
This is a working example to post an event (change url and bearer token)
```sh
curl 'https://<instance.tld>/users/<username>/outbox' -X POST -H 'Content-Type:application/ld+json; profile="https://www.w3.org/ns/activitystreams"' -H 'Authorization: Bearer qsfqsdfqshudfqsdhufqusdhf' -d '{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Create", "object": {"type": "Event", "content": "minimal AP C2S Event", "to": "https://www.w3.org/ns/activitystreams#Public", "cc": [] } }'
```https://git.pleroma.social/pleroma/pleroma/-/issues/2936Could not compile dependency :syslog2023-05-08T00:58:04ZMoon ManCould not compile dependency :syslogfresh installation attempt, happens on both stable and develop
```
:/opt/churro# sudo -Hu churro MIX_ENV=prod mix pleroma.instance gen
warning: `config/prod.secret.exs` not found. You may want to create one by running `mix pleroma.insta...fresh installation attempt, happens on both stable and develop
```
:/opt/churro# sudo -Hu churro MIX_ENV=prod mix pleroma.instance gen
warning: `config/prod.secret.exs` not found. You may want to create one by running `mix pleroma.instance gen`
Could not find "rebar3", which is needed to build dependency :syslog
I can install a local copy which is just used by Mix
Shall I install rebar3? (if running non-interactively, use "mix local.rebar --force") [Yn]
* creating /var/lib/churro/.mix/rebar
* creating /var/lib/churro/.mix/rebar3
===> Compiling syslog
===> Linking /opt/churro/_build/prod/lib/syslog/priv/syslog_drv.so
===> Missing artifact priv/syslog_drv.so
** (Mix) Could not compile dependency :syslog, "/var/lib/churro/.mix/rebar3 bare compile --paths /opt/churro/_build/prod/lib/*/ebin" command failed. You can recompile this dependency with "mix deps.compile syslog", update it with "mix deps.update syslog" or clean it with "mix deps.clean syslog"
```
output of dumpfile:
```
:/opt/churro# cat rebar3.crashdump
Error: {badmatch,[]}
[]
```
ubuntu 20.04
erlang 1:23.3.1-1
elixir 1.11.2-1https://git.pleroma.social/pleroma/pleroma/-/issues/2933MastoAPI: status attachment's 'remote_url' value is always the same as 'url'2023-05-08T00:59:19ZCEO of FediverseMastoAPI: status attachment's 'remote_url' value is always the same as 'url'MastoAPI always returns the same MediaProxy value for both 'url' and 'remote_url':
https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/mastodon_api/views/status_view.ex#L577
Shouldn't it be like this instead?
```...MastoAPI always returns the same MediaProxy value for both 'url' and 'remote_url':
https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/mastodon_api/views/status_view.ex#L577
Shouldn't it be like this instead?
```
href = attachment_url["href"] |> MediaProxy.url()
...
url: href,
remote_url: attachment_url["href"],
```https://git.pleroma.social/pleroma/pleroma/-/issues/2932Actor without preferredUsername gives error2022-09-05T15:07:26ZIljaActor without preferredUsername gives errorWhen you have an actor without `preferredUsername`, Pleroma will store it in the DB, but have a `NULL` value for `nickname`. When viewing it through Mastodon API (e.g. by searching it), we add a field `fqn` which calls `Pleroma.user.full...When you have an actor without `preferredUsername`, Pleroma will store it in the DB, but have a `NULL` value for `nickname`. When viewing it through Mastodon API (e.g. by searching it), we add a field `fqn` which calls `Pleroma.user.full_nickname(%User{} = user)`. This assumes `user.nickname` to be a string and it throws an error[1].
I encountered this while playing around, so I'm not sure if there's currently examples in the wild, but should prob be fixed regardless.
[1]
```
[error] Elixir.Pleroma.Web.MastodonAPI.StatusView failed to render {Pleroma.Web.MastodonAPI.StatusView, "show.json"}
** (FunctionClauseError) no function clause matching in String.contains?/2
(elixir 1.13.4) lib/string.ex:2372: String.contains?(nil, "@")
(pleroma 2.4.52-589-gb53cf7d4-fine-grained-moderation-privileges+dev) lib/pleroma/user.ex:2225: Pleroma.User.full_nickname/1
(pleroma 2.4.52-589-gb53cf7d4-fine-grained-moderation-privileges+dev) lib/pleroma/web/mastodon_api/views/account_view.ex:284: Pleroma.Web.MastodonAPI.AccountView.do_render/2
(pleroma 2.4.52-589-gb53cf7d4-fine-grained-moderation-privileges+dev) lib/pleroma/web/mastodon_api/views/status_view.ex:338: Pleroma.Web.MastodonAPI.StatusView.render/2
(pleroma 2.4.52-589-gb53cf7d4-fine-grained-moderation-privileges+dev) lib/pleroma/web/mastodon_api/views/status_view.ex:6: Pleroma.Web.MastodonAPI.StatusView.safe_render/3
(elixir 1.13.4) lib/enum.ex:1593: Enum."-map/2-lists^map/1-0-"/2
(pleroma 2.4.52-589-gb53cf7d4-fine-grained-moderation-privileges+dev) lib/pleroma/web/mastodon_api/views/status_view.ex:6: Pleroma.Web.MastodonAPI.StatusView.safe_render_many/4
(pleroma 2.4.52-589-gb53cf7d4-fine-grained-moderation-privileges+dev) lib/pleroma/web/mastodon_api/controllers/search_controller.ex:182: Pleroma.Web.MastodonAPI.SearchController.with_fallback/2
(pleroma 2.4.52-589-gb53cf7d4-fine-grained-moderation-privileges+dev) lib/pleroma/web/mastodon_api/controllers/search_controller.ex:63: anonymous fn/1 in Pleroma.Web.MastodonAPI.SearchController.do_search/3
(elixir 1.13.4) lib/task/supervised.ex:89: Task.Supervised.invoke_mfa/2
(elixir 1.13.4) lib/task/supervised.ex:34: Task.Supervised.reply/4
(stdlib 4.0.1) proc_lib.erl:240: :proc_lib.init_p_do_apply/3
```https://git.pleroma.social/pleroma/pleroma/-/issues/2929Unexpected behaviour in admin api when user chooses "invites" as nickname2022-09-04T02:27:02ZIljaUnexpected behaviour in admin api when user chooses "invites" as nicknameIn the admin api `/api/v1/pleroma/admin` we have `GET users/:nickname`. But before that we have `GET users/invites`.
So if someone would take the name `invites`, I believe admin api's `users/:nickname` won't work for that user. At first...In the admin api `/api/v1/pleroma/admin` we have `GET users/:nickname`. But before that we have `GET users/invites`.
So if someone would take the name `invites`, I believe admin api's `users/:nickname` won't work for that user. At first glance, this is the only one I see, but there may be others, idk.
The easiest work-around is probably to add it to `restricted_nicknames`. But really we should probably design our api's a bit better so such collisions don't accidentally happen. This isn't something I really have experience in, though, so may be easier said than done.https://git.pleroma.social/pleroma/pleroma/-/issues/2928Support extended types2022-12-31T06:53:46ZIljaSupport extended typesWe read in https://www.w3.org/TR/activitystreams-core/#object
> When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type.
The example given i...We read in https://www.w3.org/TR/activitystreams-core/#object
> When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type.
The example given is
```json
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"gr": "http://purl.org/goodrelations/v1#"
}
],
"type": ["Place", "gr:Location"],
"name": "Sally's Restaurant",
"longitude": 12.34,
"latitude": 56.78,
"gr:category": "restaurants/french_restaurants"
}
```
The idea is if you don't support `["Place", "gr:Location"]`, you should still process the object as `Place`. AFAIK we don't have implementations like this in the wild yet, but this would partly solve the problem of having to implement an increasing number of custom objects. Having a server with support for this could make it more attractive for people to use extensions of core types like this, rather than just creating new ones.https://git.pleroma.social/pleroma/pleroma/-/issues/2927Unauthenticated access options for local / remote statuses are broken2023-08-30T01:12:33ZLady GagaUnauthenticated access options for local / remote statuses are brokenIn admin-fe you have options that disable unauthenticated access for local and remote statuses. I dont think there's anything wrong with the admin-fe option, I think it's a frontend bug -- but if you "disallow access" to the statuses, th...In admin-fe you have options that disable unauthenticated access for local and remote statuses. I dont think there's anything wrong with the admin-fe option, I think it's a frontend bug -- but if you "disallow access" to the statuses, the frontend doesn't respect that and will display the local statuses and remote repeats anyway, although replies to remote statuses will be broken links as expected.
This can be problematic for those that would like to, say, show their statuses but disallow people seeing remote posts
Confirmed in develop branch.
Edit: Backend bug *https://git.pleroma.social/pleroma/pleroma/-/issues/2926Don't allow Announces of statuses of banned users2023-05-08T01:01:18ZtusooaDon't allow Announces of statuses of banned userssomeone repeated a status of a banned user, and there's such thing on my timeline
![image](/uploads/0502ac1de8d16b4f97346362fb78f050/image.png)someone repeated a status of a banned user, and there's such thing on my timeline
![image](/uploads/0502ac1de8d16b4f97346362fb78f050/image.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2925Support running multi-node2023-05-08T01:01:24ZtusooaSupport running multi-nodePart of https://git.pleroma.social/pleroma/pleroma/-/issues/798
- [x] libcluster: automatically discover and connect to nodes
- [ ] Cachex: *does not support changing num of nodes on the fly*, available substitutions:
- [Nebulex](http...Part of https://git.pleroma.social/pleroma/pleroma/-/issues/798
- [x] libcluster: automatically discover and connect to nodes
- [ ] Cachex: *does not support changing num of nodes on the fly*, available substitutions:
- [Nebulex](https://hexdocs.pm/nebulex): an existing solution, supports distributed cache/partitioning, requires wrapping to match Cachex api
- cache replication, manually: https://github.com/whitfin/cachex/issues/219
- redis
- [ ] shoutbox:
- [ ] should just work (tm/mc) with Phoenix.Channel (see https://github.com/poeticoding/phoenix_chat_example )
- [ ] messages does not propagate if a new node joins later
- [ ] Config/Emoji/...: need to propagate from and to nodes (we can do Phoenix.PubSub )
- [ ] Endpoint: should just work - how to determine load balancing heuristics?
- [ ] Oban: ?
- [ ] Streamer: need to broadcast to all nodes (mastodon uses redis to push statuses to streamer services, we can use pubsub too)
- more?https://git.pleroma.social/pleroma/pleroma/-/issues/2924Refactor: Make sure uploaders are fully modular2022-08-27T09:08:27ZIljaRefactor: Make sure uploaders are fully modularUploaders are modular. Ideally you should be able to write a module, drop it in the code somewhere, and it should be able to run without extra changes.
In https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3654 I noticed that s...Uploaders are modular. Ideally you should be able to write a module, drop it in the code somewhere, and it should be able to run without extra changes.
In https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3654 I noticed that some stuff leaks out in `lib/pleroma/upload.ex` (more specifically `base_url/0`, but check for others as well).
We may also want to check if we want to make the `description` part of the modules, similar like how is done for MRF.
Once https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3654 is merged, we should probably fix that up.https://git.pleroma.social/pleroma/pleroma/-/issues/2923Occasionally failing to retrieve CI base image2023-05-08T01:03:31ZSean KingOccasionally failing to retrieve CI base image### Bug description
Occasionally, I happen to notice the CI base will fail to be retrieved (ie in the analysis stage) causing that CI stage to fail. See log from this job: https://git.pleroma.social/pleroma/pleroma/-/jobs/217816### Bug description
Occasionally, I happen to notice the CI base will fail to be retrieved (ie in the analysis stage) causing that CI stage to fail. See log from this job: https://git.pleroma.social/pleroma/pleroma/-/jobs/217816