pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-05-08T01:12:31Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/2899Using something like ecto_psql_extras for figuring out Postgresql performance...2023-05-08T01:12:31ZIljaUsing something like ecto_psql_extras for figuring out Postgresql performance issuesSomething @feld brought up in the chat: https://github.com/pawurb/ecto_psql_extras
Could be useful for figuring out postgresql issues. Needs to be looked into further.Something @feld brought up in the chat: https://github.com/pawurb/ecto_psql_extras
Could be useful for figuring out postgresql issues. Needs to be looked into further.https://git.pleroma.social/pleroma/pleroma/-/issues/2898Support leaving conversations (aka unmentioning)2023-05-08T01:12:46ZSean KingSupport leaving conversations (aka unmentioning)It was some new feature I came across today while ~~doom~~scrolling Twitter today. And I thought it actually might be a good idea to have implemented in Pleroma as well. https://twitter.com/TwitterSafety/status/1546555047630159872
**Edi...It was some new feature I came across today while ~~doom~~scrolling Twitter today. And I thought it actually might be a good idea to have implemented in Pleroma as well. https://twitter.com/TwitterSafety/status/1546555047630159872
**Edit:** Basically, this means not just stopping notifications for a conversation, but also untagging your username and stopping future mentions in said conversation without needing to ask someone to do it. https://twitter.com/PopBase/status/1546555975242461184https://git.pleroma.social/pleroma/pleroma/-/issues/2897Warning about :slave.start/3 deprecated in Erlang 252023-06-26T22:18:45ZSean KingWarning about :slave.start/3 deprecated in Erlang 25I noticed this while working with Pleroma in an Elixir 1.13.0/Erlang 25 environment. They say it will be deprecated by OTP 27. I'm not sure what we would want to do regarding it. ![image](/uploads/040763fa41d1fd98009cf782a77da703/image.png)I noticed this while working with Pleroma in an Elixir 1.13.0/Erlang 25 environment. They say it will be deprecated by OTP 27. I'm not sure what we would want to do regarding it. ![image](/uploads/040763fa41d1fd98009cf782a77da703/image.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2896Don't allow replying to a deleted post2022-07-08T13:42:37ZIljaDon't allow replying to a deleted postSteps to reproduce
1. Someone makes a post
2. You see it on the TL
3. Person deletes the post
4. You still have the post on the TL because I don't use streaming or w/e
5. I reply to the post
Expected behaviour
* Pleroma sees I try to r...Steps to reproduce
1. Someone makes a post
2. You see it on the TL
3. Person deletes the post
4. You still have the post on the TL because I don't use streaming or w/e
5. I reply to the post
Expected behaviour
* Pleroma sees I try to reply to a deleted post and doesn't allow it
Current behaviour
* Pleroma doesn't care that the post is deleted and let's it through any howhttps://git.pleroma.social/pleroma/pleroma/-/issues/2895Unexpected behaviour when profiles are enabled for unauthenticated users but ...2023-05-08T01:13:28ZwebbUnexpected behaviour when profiles are enabled for unauthenticated users but activities are disabled
With profiles enabled for unauthenticated users, and activities disabled, the instance still shows the activities under a user's profile. Is this intended behaviour?
(On 2.4.3)
![](https://webber.rocks/f4d66b39.png)
![](https://webber...
With profiles enabled for unauthenticated users, and activities disabled, the instance still shows the activities under a user's profile. Is this intended behaviour?
(On 2.4.3)
![](https://webber.rocks/f4d66b39.png)
![](https://webber.rocks/f724106d.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2893[Feature Request] 2FA - WebAuthN Provider2023-05-08T01:14:04ZNaia Ōkami[Feature Request] 2FA - WebAuthN ProviderThis is a request to add WebAuthN support to two-factor authentication.
see: https://www.w3.org/TR/webauthn-2/
This is a must, given that most modern OSes and hardware will support being tokens... as well as to support hardware securi...This is a request to add WebAuthN support to two-factor authentication.
see: https://www.w3.org/TR/webauthn-2/
This is a must, given that most modern OSes and hardware will support being tokens... as well as to support hardware security keys.https://git.pleroma.social/pleroma/pleroma/-/issues/2891Allow users to delete backups manually2023-06-13T17:10:54ZtusooaAllow users to delete backups manuallyAs we do not have proper access control for backup archives, it is desirable to allow users to delete them manually, as they might contain sensitive information *and all backup archives are ~~accessible through `read:accounts`~~* (doesn'...As we do not have proper access control for backup archives, it is desirable to allow users to delete them manually, as they might contain sensitive information *and all backup archives are ~~accessible through `read:accounts`~~* (doesn't apply now, it's now `read:backups`).https://git.pleroma.social/pleroma/pleroma/-/issues/2890Local uploader: Make upload directory contain less direct children2023-05-08T01:14:50ZtusooaLocal uploader: Make upload directory contain less direct childrenCurrently the uploader uses a flat directory structure. This means, as more and more files are uploaded, the directory can have up to (number of all uploads) children.
This is not good for some filesystems, like glusterfs, which perform...Currently the uploader uses a flat directory structure. This means, as more and more files are uploaded, the directory can have up to (number of all uploads) children.
This is not good for some filesystems, like glusterfs, which performs pretty slow when I am trying to `ls` under the upload directory.
It turns out other software like mastodon and synapse uses a nested structure, where the files are stored like `a/ab/abc/(full file name)`. This largely reduces possible entries under the first level of the upload directory.https://git.pleroma.social/pleroma/pleroma/-/issues/2886Soapbox front-end should select a more modern version2023-05-08T01:00:50ZAndy JacksonSoapbox front-end should select a more modern versionRight now it's locked to v1.0.0 tag, yet "v2.0.0" tag would be better, and the newest "v(.*)" tag would be best.Right now it's locked to v1.0.0 tag, yet "v2.0.0" tag would be better, and the newest "v(.*)" tag would be best.https://git.pleroma.social/pleroma/pleroma/-/issues/2883Support for Data Integrity signatures in JSON-LD2023-06-28T10:29:24ZHélènepleroma-dev@helene.moeSupport for Data Integrity signatures in JSON-LD[Mastodon currently implements](https://docs.joinmastodon.org/spec/security/#ld) the [Linked Data Signatures 1.0](https://w3c-ccg.github.io/data-integrity-spec/#signatures) specification, to ensure that an activity can be relayed and ver...[Mastodon currently implements](https://docs.joinmastodon.org/spec/security/#ld) the [Linked Data Signatures 1.0](https://w3c-ccg.github.io/data-integrity-spec/#signatures) specification, to ensure that an activity can be relayed and verified without needing to request the activity on the original instance. Pleroma does not support this.
While this may not be considered useful for most cases, it may be necessary for implementing features such as #2882.https://git.pleroma.social/pleroma/pleroma/-/issues/2882Forwarding to followers collection from Inbox (fix followers-only broken thre...2023-05-08T00:46:31ZIljaForwarding to followers collection from Inbox (fix followers-only broken threads)One problem we have with followers-only posts is that we have broken threads for people who only follow some of the people in the conversation.
In the [AP-spec](https://www.w3.org/TR/activitypub/) there's section "7.1.2 Forwarding from ...One problem we have with followers-only posts is that we have broken threads for people who only follow some of the people in the conversation.
In the [AP-spec](https://www.w3.org/TR/activitypub/) there's section "7.1.2 Forwarding from Inbox" who addresses this issue. The idea is that you can specify someone else's followers collection (e.g. OP's) and that the server who owns the collection then forwards it.
Some stuff from fedi on this subject:
https://patch.cx/notice/ACRwASvblJuPEaPAn2
> it won’t work without changes in implementations because:
> 1. the ones I know will reject activities addressed to a follower collection one doesn’t own, which makes sense but will need to be modified to make an exception for follower only replies
> 2. there would have to be some kind of an activity forwarding mechanism on the op’s instance since it’s the only instance that knows how to deliver posts to op’s followers
https://patch.cx/notice/ACRwwoBW2AOl3nthAm
> also the forwarding part would be kinda hard. mastodon has been able to forward activities of other instances for a long time using ldsigs, but pleroma does not implement them
https://ilja.space/notice/AKBL2HKRIguQZRNQUy
> If someone implements it, sure. Other software will also need to handle it properly then, but I see no reason to not have it in one software and see who follows suite. (I mean, as long as people can still choose to have current behaviour since that's what they are used to)
https://toot.kartonrad.de/@konni/108425579558176586
> The compose-visibility form should show another option, perhaps a comment icon, with "Keep Conversation", that just shows up when the parent comment is follower-onlyhttps://git.pleroma.social/pleroma/pleroma/-/issues/2881Rework blocking behavior?2023-05-08T01:15:35ZSean KingRework blocking behavior?I know there's been discussions around the behavior of blocking (ie in #2430).
Currently, we have a thing called "outgoing blocks", which is enabled by default and federates Block activities to other instances. I don't know quite the hi...I know there's been discussions around the behavior of blocking (ie in #2430).
Currently, we have a thing called "outgoing blocks", which is enabled by default and federates Block activities to other instances. I don't know quite the history around it but it could've probably had good intentions (or maybe not). Regardless, as it currently is, we cannot ignore that it also allows for things like !3539.
According to [ActivityPub specifications](https://www.w3.org/TR/activitypub/#block-activity-outbox), the "Block" activity should be only used to indicate that an actor does not want another actor interacting with their posts. The server should use this to prevent a blocked actor from interacting with any posts by the actor blocking. However, the server should NOT deliver Block activities to their object.
This could mean something different, but from my interpretation (and presumably others), we probably not be delivering any sort of notification about being blocked in the first place. And if that's the case, we absolutely should discuss reworking what occurs when one user blocks another.https://git.pleroma.social/pleroma/pleroma/-/issues/2880Support Regex types with database-based configuration2023-05-08T01:17:21ZHélènepleroma-dev@helene.moeSupport Regex types with database-based configurationCurrently, some settings (e.g. for KeywordMRF or StealEmojiMRF) can handle both strings and Regex types via file-based configuration, which supports full Elixir code, and as such, Regex literals.
Issues arise when database-based configu...Currently, some settings (e.g. for KeywordMRF or StealEmojiMRF) can handle both strings and Regex types via file-based configuration, which supports full Elixir code, and as such, Regex literals.
Issues arise when database-based configuration is involved, however: Regex types are not supported by this system. To workaround those issues, some settings accept strings instead, which are then either treated differently or compiled into Regex by the MRF. This causes two issues:
* for the former (strings are treated differently), this causes consequent behavioral differences between file-based configuration and database-based configuration, which can result in the impossibility to fully use some Pleroma features;
* and, for the latter (strings are compiled into Regex), this can cause heavier CPU load onto the system due to lack of caching, as well as needless code complexity increases.
As suggested by @lambadalambda on !3673, a type to wrap around the Regex type to target database-based configuration would be ideal, allowing them to be cached, serialized and de-serialized properly if needed.https://git.pleroma.social/pleroma/pleroma/-/issues/2879Decide what to do with certain features that have problems2023-05-08T00:29:03ZSean KingDecide what to do with certain features that have problemsAs mentioned by @a1batross in pleroma-meta!3, Pleroma currently has certain features that have concerning issues (whether from lack of maintenance or merging things before fixing them later). Some of these include:
- [X] SSH/BBS access ...As mentioned by @a1batross in pleroma-meta!3, Pleroma currently has certain features that have concerning issues (whether from lack of maintenance or merging things before fixing them later). Some of these include:
- [X] SSH/BBS access mode (removed and replaced with [Sshocial](https://git.pleroma.social/Duponin/sshocial) in !3872)
- [ ] Gopher server\
**Options:**
- Remove features (!3674, admin-fe!207)
- Keep features optional and improve functionality (starting with !3675)
- [ ] Dead scrobble**
- [ ] Dead Admin API***
- [ ] Two HTTP clients that are nearly broken***
- [ ] OTP builds that are causing more problems than just being easily installable***
- [ ] Unreliable Static-FE
- [ ] Overengineered solutions like emoji packs management
- [ ] Chat messages that doesn't even have the ability to delete a chat
**Key:**\
** - May need some further research\
*** - May need further clarification
There is probably others that I'm missing. Feel free to mention if that's the case and I'll add to this list when I can.https://git.pleroma.social/pleroma/pleroma/-/issues/2878Feature Request: Convert media proxy previews to WebP format2023-05-08T01:19:46ZlewdthewidesFeature Request: Convert media proxy previews to WebP formatBrowsing the timeline can be an absolute bandwidth hog if people are posting alot of high-quality artwork. The media proxy can generate resized and quality-reduced previews/thumbnails to lower bandwidth usage for end users, however, curr...Browsing the timeline can be an absolute bandwidth hog if people are posting alot of high-quality artwork. The media proxy can generate resized and quality-reduced previews/thumbnails to lower bandwidth usage for end users, however, current implementation does very little to reduce the size of PNG thumbnails due to its lossless nature. You would need to convert to a lossy format in order to reduce the size of PNG thumbnails by any meaningful amount.
I propose that we give admins the ability to save media proxy thumbnails in WebP format:
- Should be supported well by major browsers and apps by now
- Preserves alpha channel of PNG images
- Able to create lossy and animated thumbnails for GIF imageshttps://git.pleroma.social/pleroma/pleroma/-/issues/2875WriteFreely profile update failing2023-05-08T01:19:55ZMatt BaerWriteFreely profile update failingWhen sending out an `Update` activity with an updated `Person` / blog object, we get a `200 OK` response, but then the profile no longer loads in Pleroma.
Here's the request going out -- is there anything that looks wrong with it?
```
...When sending out an `Update` activity with an updated `Person` / blog object, we get a `200 OK` response, but then the profile no longer loads in Pleroma.
Here's the request going out -- is there anything that looks wrong with it?
```
2022/05/11 21:54:42 POST https://blob.cat/inbox
2022/05/11 21:54:42 POST /inbox HTTP/1.1
Host: blob.cat
User-Agent: Go (WriteFreely/0.13.1; +https://write.as)
Content-Length: 1479
Content-Type: application/activity+json
Date: Wed, 11 May 2022 21:54:42 GMT
Digest: SHA-256=eg69oMV7+3M/uK5h9rY+/gnBjJfFsMvi01owWe/lgzA=
Signature: keyId="https://development.write.as/api/collections/secondy#main-key",algorithm="rsa-sha256",headers="(request-target) date host digest",signature="ZyzpUqh43u6isimfN9cPVBu8cnGTQxFFQABQahy+Oa1YcQqugov01kfICoZNWtJeDPFR+AlbGBz7EW6Le89FVlGb8MJTDON/ymIeFia3NM+7MiGxy5i8hsntM4Cfiyv+DjYQU9z6t5asnoIKHm/tjynwyhMpDdrknEHOGmhWrUYm1RhDEcQJK4D0PN7pDcehr4cxcO7IHiFO1/wceVIhT/l9U608LTbIfXNp4VZOpE2GDFjMX0H9m18rV8b7dUc5zBM8Li3wu5b2lgLSIgU0BTgJadphnIt3AK9OuDVeDyWlPjnu20iq0tfJhR8WegnRwbMsYXKCeDXKcrqVBSwk2Q=="
Accept-Encoding: gzip
{"@context":["https://www.w3.org/ns/activitystreams",{}],"type":"Update","id":"https://development.write.as/api/collections/secondy#updates/yPU9Nrbd","actor":"https://development.write.as/api/collections/secondy","published":"0001-01-01T00:00:00Z","object":{"type":"Person","id":"https://development.write.as/api/collections/secondy","published":"0001-01-01T00:00:00Z","summary":"This is what I think","url":"https://development.write.as/secondy/","name":"Secondarily","inbox":"https://development.write.as/api/collections/secondy/inbox","outbox":"https://development.write.as/api/collections/secondy/outbox","following":"https://development.write.as/api/collections/secondy/following","followers":"https://development.write.as/api/collections/secondy/followers","icon":{"type":"Image","mediaType":"image/png","url":"https://write.as/img/avatars/s.png"},"publicKey":{"id":"https://development.write.as/api/collections/secondy#main-key","owner":"https://development.write.as/api/collections/secondy","publicKeyPem":"-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAknR9LPsPm9+X3KvcmRlb\nAR65kmDawf4ACyVRT538aLJH9VJlesr1bsjOtjh6LFvHekwTErtixkshelNmRQ/F\n42qWsRzq/uQhrB5FUj7JMzuAETRbf2x58OAmXYejNsyj0BK0TgiVignel/WnnjKf\nIXGIn+R2GNYq2jy2uqyvhf9TFb0Qvd0yZDcR9WnDEmcP/4YNLnT3ECChnZf8MOaS\nNCEhb+Dx6qE7QMRR7/o/Z9Mp7IUhJBK/9CB6BHqKanpqztoGZcQJgXR6TKUHc3co\nXkfSoS5J8UsIBV0NUkQeVHFw35UEJFKANJXFtx4tUjfiTAQq/unsKy+TNsoYNyYu\nsQIDAQAB\n-----END PUBLIC KEY-----\n"}}}
2022/05/11 21:54:42 Status : 200 OK
2022/05/11 21:54:42 Response: "ok"
```https://git.pleroma.social/pleroma/pleroma/-/issues/2873broken SMTP authenticated mailing transport, and SendInBlue Adapter request2023-05-08T01:17:29ZTassoman Pigibroken SMTP authenticated mailing transport, and SendInBlue Adapter request### Environment
* Installation type (OTP or From Source): SOURCE
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Soapbox FE 2.0.0
Pleroma 2.4.51-1245-g5ae5072c.develop+soapbox
* Elixir version ...### Environment
* Installation type (OTP or From Source): SOURCE
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Soapbox FE 2.0.0
Pleroma 2.4.51-1245-g5ae5072c.develop+soapbox
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Elixir 1.13.4 (compiled with Erlang/OTP 22)
* Operating system: UBUNTU
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 12.10 (Ubuntu 12.10-0ubuntu0.20.04.1)
### Bug description
Hello there, I can't send mails by SMTP SendInBlue configuration but I've just discovered [Swoosh 1.6.6 has SendInBlue Adapter](https://hexdocs.pm/swoosh/Swoosh.Adapters.Sendinblue.html#content), ready.
How Do I can add it to my mix compiled by sources?
This is the SMTP error:
```sh
pleroma@hostname:/opt/pleroma$ MIX_ENV=prod mix pleroma.email test
** (UndefinedFunctionError) function :crypto.hmac/3 is undefined or private, use crypto:mac/4 instead
(crypto 5.0.4) :crypto.hmac(:md5, "PASSWORD", "<NUMERIC-ID@smtp-relay.sendinblue.com>")
(gen_smtp 0.15.0) /opt/pleroma/deps/gen_smtp/src/smtp_util.erl:73: :smtp_util.compute_cram_digest/2
(gen_smtp 0.15.0) /opt/pleroma/deps/gen_smtp/src/gen_smtp_client.erl:489: :gen_smtp_client.do_AUTH_each/5
(gen_smtp 0.15.0) /opt/pleroma/deps/gen_smtp/src/gen_smtp_client.erl:452: :gen_smtp_client.try_AUTH/3
(gen_smtp 0.15.0) /opt/pleroma/deps/gen_smtp/src/gen_smtp_client.erl:335: :gen_smtp_client.open_smtp_session/2
(gen_smtp 0.15.0) /opt/pleroma/deps/gen_smtp/src/gen_smtp_client.erl:271: :gen_smtp_client.try_smtp_sessions/3
(gen_smtp 0.15.0) /opt/pleroma/deps/gen_smtp/src/gen_smtp_client.erl:258: :gen_smtp_client.send_it/2
(swoosh 1.3.11) lib/swoosh/adapters/smtp.ex:48: Swoosh.Adapters.SMTP.deliver/2
```
My Pleroma installation is made by sources. Inside `deps.exs` I have this: `{:swoosh, "~> 1.0"},`https://git.pleroma.social/pleroma/pleroma/-/issues/28680 followers and following, disabled buttons2023-05-08T01:21:10ZWillowcontact@willowbarraco.fr0 followers and following, disabled buttonsHere what I see on my own profile page :
![2022-04-26-19-34-34](/uploads/4fecc4dbfd8eb63844b4d19974723238/2022-04-26-19-34-34.png)
As you can see, I see 0 as both following and followers. Of course I got way more than that !
As the ap...Here what I see on my own profile page :
![2022-04-26-19-34-34](/uploads/4fecc4dbfd8eb63844b4d19974723238/2022-04-26-19-34-34.png)
As you can see, I see 0 as both following and followers. Of course I got way more than that !
As the api on /status give 0 for those values, pleroma-fe disable the two buttons:
![2022-04-26-19-36-08](/uploads/dee1a013f920ccfd8ea95dfe3b7c1f8c/2022-04-26-19-36-08.png)
This bug seems related to the two profile options to hide those counts. Unchecking them make the count to display correctly.
![2022-04-26-19-37-03](/uploads/f70b87c7ebde5a65f7d2fd53d7475b0d/2022-04-26-19-37-03.png)
```
Backend version
2.4.51-468-gd7c53da7-develop
Frontend version
b13d8f7e
```
I tried to run both backend and frontend locally to debug.
- With both origin/develop, I cannot reproduce the issue.
- If I run -fe and connect it to my instance, I got the issue
So the issue really rely on the backend and it has been solved ? I'd like to figure out what patch fixed ithttps://git.pleroma.social/pleroma/pleroma/-/issues/2866Follow relationship inconsistency caused by rollback2023-05-08T01:21:18ZdebulaFollow relationship inconsistency caused by rollbackA few days ago, my server was terminated and deleted by Oracle Cloud without any reason. Oracle Customer Service did not respond to my questions about data backup. I can only restart my server on another machine with a backup from months...A few days ago, my server was terminated and deleted by Oracle Cloud without any reason. Oracle Customer Service did not respond to my questions about data backup. I can only restart my server on another machine with a backup from months ago.
Since it it not the first time I encountered follow relationship inconsistency on Pleroma, I try to be as detailed as possible.
### Following
Supposed you sent someone a follow request and passed after the date of backup, now you want to follow this person again. Mastodon will pass your follow request immediately. But when it comes to Pleroma, the follow status is "awaiting approval" on my server, while on the other side pleroma will send a notification to the user that "xxx is following you".
Now if you cancel your follow request and send a follow request again, this problem can be fixed. But if this process was interrupted due to some problems(network, unavailability, ...), you may have to repeat it multiple times.
### Followers
It's the most confusing part. No matter the new follower is from Mastodon or Pleroma, if it unfollows you and send a follow request again, you will get a notification that "xxx has sent you a follow request". But when you check for it, the count of your follow requests is still 0.
To fix this inconsistency, you have to ask it to cancel and resend follow request again. Still, if this process was interrupted, you should repeat it again and again.
I don't know if ActivityPub has a federated "follow state" record, but this process is tedious and confusing. Is it possible to improve it?https://git.pleroma.social/pleroma/pleroma/-/issues/2863User unable to post new status2023-07-14T18:11:02ZMichael Collinsmichael.collins@bofhllc.netUser unable to post new status<!--
### 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.4.2
* Elixir version (`elixir -v` for from source installations, N/A for OTP): NA
* Operating system: Debian 11
* PostgreSQL version (`psql -V`): 13
### Bug description
Users are unable to post new statuses.
This is what's getting recorded in the syslog:
```
Apr 17 14:12:07 liewrap01 pleroma: request_id=Fua0dK_e8n__fVoAACQx [error] Internal server error: %Cachex.ExecutionError{message: "nil given for :nickname. Comparison with nil is forbidden as it is unsafe. Instead write a query with is_nil/1, for example: is_nil(s.nickname)"}
Apr 17 14:12:49 liewrap01 pleroma: request_id=Fua0fq6VIMeDVr8AACdx [error] Internal server error: %Ecto.ConstraintError{constraint: "push_subscriptions_user_id_token_id_index", message: "constraint error when attempting to insert struct:\n\n * push_subscriptions_user_id_token_id_index (unique_constraint)\n\nIf you would like to stop this constraint violation from raising an\nexception and instead add it as an error to your changeset, please\ncall `unique_constraint/3` on your changeset with the constraint\n`:name` as an option.\n\nThe changeset has not defined any constraint.\n", type: :unique}
Apr 17 14:12:59 liewrap01 pleroma: request_id=Fua0gQtMi--GeZcAACgx [error] Internal server error: %Cachex.ExecutionError{message: "nil given for :nickname. Comparison with nil is forbidden as it is unsafe. Instead write a query with is_nil/1, for example: is_nil(s.nickname)"}
Apr 17 14:14:12 liewrap01 pleroma: request_id=Fua0kfMcMKfGUv0AACtx [error] Internal server error: %Cachex.ExecutionError{message: "nil given for :nickname. Comparison with nil is forbidden as it is unsafe. Instead write a query with is_nil/1, for example: is_nil(s.nickname)"}
Apr 17 14:14:19 liewrap01 pleroma: request_id=Fua0k5SFO4K5IxYAACuh [error] Internal server error: %Cachex.ExecutionError{message: "nil given for :nickname. Comparison with nil is forbidden as it is unsafe. Instead write a query with is_nil/1, for example: is_nil(s.nickname)"}
Apr 17 14:14:22 liewrap01 pleroma: request_id=Fua0lElf_5ic9K8AACwR [error] Internal server error: %Cachex.ExecutionError{message: "nil given for :nickname. Comparison with nil is forbidden as it is unsafe. Instead write a query with is_nil/1, for example: is_nil(s.nickname)"}
```
This is what's shown on the FE: `Error: Cannot read properties of undefined (reading 'match') `
![image](/uploads/d38c2ce41f6752ee62d6502c3e401a4f/image.png)