pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2019-07-11T14:51:34Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/114Activation + Reset token emails2019-07-11T14:51:34ZlainActivation + Reset token emailsThere's already a reset token mechanism available by mix task. This needs to be exposed in an API.
Things to do
- [x] add an SMTP library
- [x] Add an option for users to invite other users (configurable in the config)
- Add the fronte...There's already a reset token mechanism available by mix task. This needs to be exposed in an API.
Things to do
- [x] add an SMTP library
- [x] Add an option for users to invite other users (configurable in the config)
- Add the frontend part for this to PleromaFE (for Admins and Users) — to be implemented in https://git.pleroma.social/pleroma/pleroma-fe/issues/213
It would also be nice to have an option to require an 'activation' email before a user can start using the site.1.0Ivan TashkinovIvan Tashkinovhttps://git.pleroma.social/pleroma/pleroma/-/issues/113MastoAPI: /api/web/settings endpoint2018-04-21T16:25:20ZMorgan Bazalgettethe@howl.moeMastoAPI: /api/web/settings endpointIdeally should only serve the purpose of storing the data and giving it back on the initial-state when a user loads /web. See: https://git.pleroma.social/tyge/mastofe/issues/6#note_1442Ideally should only serve the purpose of storing the data and giving it back on the initial-state when a user loads /web. See: https://git.pleroma.social/tyge/mastofe/issues/6#note_14421.0https://git.pleroma.social/pleroma/pleroma/-/issues/112Search results should be sorted in reverse chronological order2018-06-18T03:42:49ZMorgan Bazalgettethe@howl.moeSearch results should be sorted in reverse chronological order1.0kaniinikaniinihttps://git.pleroma.social/pleroma/pleroma/-/issues/111Masto API: on statuses/:id/context, display posts like Mastodon gives them2018-06-17T22:16:46ZMorgan Bazalgettethe@howl.moeMasto API: on statuses/:id/context, display posts like Mastodon gives themAt the moment, the entire conversation of posts that are in some way related to the root post are given, but this should not be the case.
```
A
|
B
| \
C D
| \ \
E F G
```
* Getting the ancestors of `E` should not return `F`, `G`, `D...At the moment, the entire conversation of posts that are in some way related to the root post are given, but this should not be the case.
```
A
|
B
| \
C D
| \ \
E F G
```
* Getting the ancestors of `E` should not return `F`, `G`, `D` (even if they were made before `E` and they belong to the conversation, they are on another "branch" of it and do not serve to link `E` directly with `A`).
* Getting the descendants of `C` should not return `D` or `G` (again, different branch of the conversation, we should only return the descendants of `C`, and not those of `B` as well)
Aside: this is solved in pleroma-fe by having `Replies:` placed under the username, and the arrow next to it (in a imageboard kind of style)
![image](/uploads/1e91c8e8d9733003d130ba724222c5da/image.png)
But it's important to add this nonetheless because Mastodon apps expect ancestors to be those directly linked to the post, and descendants only those of the post itself, as I explained.1.0https://git.pleroma.social/pleroma/pleroma/-/issues/109Masto API: support exclude_replies2018-06-19T05:15:13ZMorgan Bazalgettethe@howl.moeMasto API: support exclude_replies`exclude_replies`: when set to true, only shows posts which are not replies to another post, or if they are every ascendant is created by the owner (= many posts by author which replies to previous posts so that users can click and see w...`exclude_replies`: when set to true, only shows posts which are not replies to another post, or if they are every ascendant is created by the owner (= many posts by author which replies to previous posts so that users can click and see what he previously said).1.0kaniinikaniinihttps://git.pleroma.social/pleroma/pleroma/-/issues/108Invite system2019-01-31T16:04:32ZnormandyInvite systemIt would be nice to easily add users to an instance that has closed registrations.It would be nice to easily add users to an instance that has closed registrations.1.0HJHJhttps://git.pleroma.social/pleroma/pleroma/-/issues/103Unfollow from and to Friendica and GNU Social doesn't work2018-05-25T03:40:14ZMichaelUnfollow from and to Friendica and GNU Social doesn't workFollowing a Pleroma account from Friendica or GNU Social does work great. The opposite does work as well.
The unfollow doesn't work in any direction, neither with GNU Social nor Friendica on the other side.
I haven't yet checked if the...Following a Pleroma account from Friendica or GNU Social does work great. The opposite does work as well.
The unfollow doesn't work in any direction, neither with GNU Social nor Friendica on the other side.
I haven't yet checked if the unfollow from Pleroma to Friendica sends a message at all. I will update the issue with more information if available.1.0https://git.pleroma.social/pleroma/pleroma/-/issues/101Can't login from tootstream2018-04-21T16:25:20ZnormandyCan't login from tootstreamConsole output:
```zsh
(tootstream) ζ tootstream -P shig
Which instance would you like to connect to? eg: 'mastodon.social'
Instance: shigusegubu.club
Error authorizing app. Did you...Console output:
```zsh
(tootstream) ζ tootstream -P shig
Which instance would you like to connect to? eg: 'mastodon.social'
Instance: shigusegubu.club
Error authorizing app. Did you enter the code correctly?
Error authorizing app. Did you enter the code correctly?
Error authorizing app. Did you enter the code correctly?
Giving up after 3 failed login attempts
Could not log you in. Please try again later.
```
Tootstream authenticates by having a user login through the browser and pasting an auth code into the terminal.1.0https://git.pleroma.social/pleroma/pleroma/-/issues/100hubzilla follow (activitypub) returns 500 from inbox, following pleroma to hu...2018-12-21T09:22:28ZMike Macgirvinhubzilla follow (activitypub) returns 500 from inbox, following pleroma to hubzilla only attempts ostatusTesting activitypub. Sent a follow activity from hubzilla. Pleroma responded with error 500 from the inbox. Activity was signed with both httpsignature and json-ld signature and follows:
````
{
"@context":[
"https://www.w3.org/...Testing activitypub. Sent a follow activity from hubzilla. Pleroma responded with error 500 from the inbox. Activity was signed with both httpsignature and json-ld signature and follows:
````
{
"@context":[
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
"https://hz.macgirvin.com/apschema/v1.2"
],
"id":"https://hz.macgirvin.com/follow/274",
"type":"Follow",
"actor":{
"type":"Person",
"id":"https://hz.macgirvin.com/channel/ziggy",
"preferredUsername":"ziggy",
"name":"ziggy",
"icon":{
"type":"Image",
"mediaType":"image/png",
"url":"https://hz.macgirvin.com/photo/profile/l/8",
"height":300,
"width":300
},
"url":{
"type":"Link",
"mediaType":"text/html",
"href":"https://hz.macgirvin.com/channel/ziggy"
},
"inbox":"https://hz.macgirvin.com/inbox/ziggy",
"outbox":"https://hz.macgirvin.com/outbox/ziggy",
"followers":"https://hz.macgirvin.com/followers/ziggy",
"following":"https://hz.macgirvin.com/following/ziggy",
"endpoints":{
"sharedInbox":"https://hz.macgirvin.com/inbox"
},
"publicKey":{
"id":"https://hz.macgirvin.com/channel/ziggy/public_key_pem",
"owner":"https://hz.macgirvin.com/channel/ziggy",
"publicKeyPem":"-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAs+/jJyGbcVyWHa5ZRrJz\nfbXoc1Ws43RHbdd3zVLuUyJl0zGzgtuzvqLCrxYkJKiDwKWL+cLv7NLYV6Iw0sJk\non1lRqugrUAPyPSkqUNEstVO/Bxy01Lp80aUKF+wNB721qvdd8xP64VEsovehCfv\n94m64GkDca+EEZqybQHH+sFq2tjV/yo/RlCfnc2ezE/Nv/EWAH0q13zK9cGYmb4z\nCkexJHbHKD59SsWFBmOWs+qJp5Hzettb5ZGaNPDYi9xThXM/93kpUKF9mC/RAIm3\n2J3Ec9F2lMJGG8gGkQhSsnogJIzg0mYUINWnHe1wNHt7FfsHv+hgfixoldwvWtON\nP38OpjB3X/DZHAfeh+wKxIjJrN6PcyahUPwCni6Cw0PEQrKVoWddL6GNb9FZmWAw\nJTbWYaUEUc98Uue2aD02Yo7jqcxEG3Empmw3dyL9a58HO3TvdfplHwar1U0566ot\niop5W4OyWzci9quIhaen1C+zKmhziHIC1VykWIeFFyNQF9vg2D2qB/ALs1RKTX1M\n91Ld1qO1TGyFR9L8jES8T38kYbT0EvO5LkkFbfl3XHnGHTfX1kipmkkkoE1NtWNc\nm3frIqRJpYKGTOj1/UvPO5+7V4bvw1LbFBlNNbtAH83yvqIUfooaUhoUDLIzaC8T\nBZbGXMm2Ksrr/2y2yYx6eS0CAwEAAQ==\n-----END PUBLIC KEY-----\n"
},
"nomadicLocations":[
{
"id":"https://hz.macgirvin.com/locs/ziggy",
"type":"nomadicLocation",
"locationAddress":"acct:ziggy@hz.macgirvin.com",
"locationPrimary":true,
"locationDeleted":false
},
{
"id":"https://z2.macgirvin.com/locs/ziggy",
"type":"nomadicLocation",
"locationAddress":"acct:ziggy@z2.macgirvin.com",
"locationPrimary":false,
"locationDeleted":false
}
]
},
"object":"https://testing.pleroma.lol/users/ratbag",
"to":[
"https://testing.pleroma.lol/users/ratbag"
],
"signature":{
"@context":[
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1"
],
"type":"RsaSignature2017",
"nonce":"8de3001d1f04644b7e16c344dd33c37e59cbf3bb749869a0d6abba675c9b886a",
"creator":"https://hz.macgirvin.com/channel/ziggy/public_key_pem",
"created":"2018-03-12T03:13:49Z",
"signatureValue":"IE5ABlSYcuHkP3vnrOXkBzpAvvvpZAwXqrJPX2oYOn/ODSfZuZns5ktjeFLU3Rw4msr4uQHMSpwg9pAQNoxkX9gPp5Bv3Rv43N7afS6bBa6lq97JntdwkHqc5Huq5ELS+sS8DKQYG4CX1CNhDKoe8iZor+CYIf6FwPep3Zq5hy8FXKbnYXVKsp8pICI3Ii+Of5lWLjfUqOv0RNNgEZBiyE+en410uQCR+EHQ2h9e7VgvWHoy0YNgLgwmLEjaZlOGDVCzAmdaxvAcBXTqHcGCskmSIAQA/kyHSPTjpXB+kYKyb/dZQApLPlDlKbCcUyRYK9bCpnH/u/yTKPt9q311Tzhg5Mktr5Pc5z+i+fSd0Cdco6oZuGy6K3ctm7P17+uGAbI3XORudaeoGURk5sllubJiHOs7NKvmdR0E3FfYx0BdR0VXE4fjGjNeg+NhSljIwTDZXYpUKa2Z63KpMBGpE+Ct70egNPCXBcrU5p5wrzxpfnUUKOULu/4U0U/ZCJXv/1OUKWRdx3k6t5v632dNsCKDJWF98/s+o89TBNUXHygICndgp35NzUXx1PkHQZkNHSmirCMs16iaJvfsyQXQy7WmJWVEuxUnou/DV06lHjHLpMdH2+WCSgPElnLMewRn0jpWx7ew7kjOhifnXpGz8OJysxtjkUrh88e1wKcOEE0="
}
}
````1.0https://git.pleroma.social/pleroma/pleroma/-/issues/98remote message filtering2018-05-19T05:55:30Zkaniiniremote message filteringIt would be nice to be able to filter remote messages in various ways.
I propose we use a set of capabilities that are granted to servers by hostmask (e.g. `*.example.com`).
The rights could be something like:
accept-messages: accept ...It would be nice to be able to filter remote messages in various ways.
I propose we use a set of capabilities that are granted to servers by hostmask (e.g. `*.example.com`).
The rights could be something like:
accept-messages: accept messages at all from these servers
include-on-ftl: include messages from these servers on federated timeline
accept-unsolicited: accept unsolicited messages and salmon slaps from the remote server (accept the activity even if the target is not following the source)
There might be some other capabilities we want to grant though.
A normal federation setup would likely grant all permissions to `*`, and then have tighter permissions for specific servers. The use of masks is interesting as it provides convenient configuration of the policy.1.0https://git.pleroma.social/pleroma/pleroma/-/issues/69Add Unrepeats2018-05-13T09:32:33ZlainAdd UnrepeatsLike unlikes, only for repeats.Like unlikes, only for repeats.1.0https://git.pleroma.social/pleroma/pleroma/-/issues/68TwitterAPI: Missing in_reply_to_screen_name in the status object.2018-10-25T03:11:24ZlainTwitterAPI: Missing in_reply_to_screen_name in the status object.We only have `in_reply_to_status_id` right now.
Relevant files are twitter_api/view/activity_view.ex and the relevant test.We only have `in_reply_to_status_id` right now.
Relevant files are twitter_api/view/activity_view.ex and the relevant test.1.0https://git.pleroma.social/pleroma/pleroma/-/issues/3244Malformed subdomain regex prevents local users from posting2024-02-17T12:52:30ZVD-15Malformed subdomain regex prevents local users from posting<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): From source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.1
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Elixir 1.13.4 (compiled with Erlang/OTP 25)
* Operating system: Ubuntu 20.04.4 LTS
* PostgreSQL version (`psql -V`): 12.17
### Bug description
Entering a malformed subdomain regex into the 'reject' list of MRF simple causes the classic "error: e.text is undefined" when making a post, though this error doesn't to go away after a bit like it normally does. Making replies to existing remote posts seem to be unaffected.
```
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: 09:11:26.995 request_id=F7SbdVirHdQbkTkAABtB [error] Internal server error: %Regex.CompileError{message: "nothing to repeat at position 1"}
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: 09:11:26.996 [error] #PID<0.2752.0> running Pleroma.Web.Endpoint (connection #PID<0.2751.0>, stream id 1) terminated
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: Server: pl.valkyrie.world:80 (http)
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: Request: POST /api/v1/statuses
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: ** (exit) an exception was raised:
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: ** (Regex.CompileError) nothing to repeat at position 1
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (elixir 1.13.4) lib/regex.ex:220: Regex.compile!/2
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf.ex:140: anonymous fn/2 in Pleroma.Web.ActivityPub.MRF.subdomains_regex/1
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (elixir 1.13.4) lib/enum.ex:2396: Enum."-reduce/3-lists^foldl/2-0-"/3
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf.ex:140: Pleroma.Web.ActivityPub.MRF.subdomains_regex/1
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:32: Pleroma.Web.ActivityPub.MRF.SimplePolicy.check_reject/2
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:214: Pleroma.Web.ActivityPub.MRF.SimplePolicy.filter/1
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (elixir 1.13.4) lib/enum.ex:2396: Enum."-reduce/3-lists^foldl/2-0-"/3
Feb 17 09:11:26 pl-vm-app-00 mix[1486949]: (pleroma 2.6.1) lib/pleroma/web/activity_pub/activity_pub.ex:130: Pleroma.Web.ActivityPub.ActivityPub.insert/4
```
I had this occur when forgetting to enter a '.' after a '\*' character in the MRF's reject list. For example: `*spam.me` instead of `*.spam.me`. Thankfully, correcting the regex resolved the bug. I don't know if the current implementation of MRF would allow validation of these regex when submitting in the admin FE, but it would certainly go a long way to preventing this bug.https://git.pleroma.social/pleroma/pleroma/-/issues/3241"Followers only" does not send a note to other instances.2024-03-17T13:39:00ZKaede Fujisaki"Followers only" does not send a note to other instances.### Environment
* Installation type (OTP or From Source):
Using docker & docker-compose
[fairy-rockets/sabbat-compose: docker-compose scripts for Pleroma instance](https://code.ledyba.org/fairy-rockets/sabbat-compose)
Here is my insta...### Environment
* Installation type (OTP or From Source):
Using docker & docker-compose
[fairy-rockets/sabbat-compose: docker-compose scripts for Pleroma instance](https://code.ledyba.org/fairy-rockets/sabbat-compose)
Here is my instance:
- https://sabbat.hexe.net/
- Source: [fairy-rockets/sabbat](https://code.ledyba.org/fairy-rockets/sabbat)
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE):
2.6.1
* Elixir version (`elixir -v` for from source installations, N/A for OTP):
docker.io/library/elixir:1.13-alpine
* Operating system:
Using Ubuntu 20.04 as a docker host.
`1.13-alpine` image is based on `alpine:3.17` image.
- [docker-elixir/1.13/alpine/Dockerfile at 328f4c09d39b06502a90fa0c5bb30d6972593fac · erlef/docker-elixir](https://github.com/erlef/docker-elixir/blob/328f4c09d39b06502a90fa0c5bb30d6972593fac/1.13/alpine/Dockerfile)
- [docker-erlang-otp/24/alpine/Dockerfile at c1005d634453849462622c34cea9208ab3c63a2e · erlang/docker-erlang-otp](https://github.com/erlang/docker-erlang-otp/blob/c1005d634453849462622c34cea9208ab3c63a2e/24/alpine/Dockerfile)
* PostgreSQL version (`psql -V`):
14.10
### Bug description
When I send "follower-only" note, followers in the same instance can see that message, but followers in other instances can't.
To debug, I enabled
```elixir
config :logger, :console, level: :debug
```
Then, I send a new "follower-only" note, and observe the log, but I can't see the debug message like that:
```
pleroma_web | 07:59:10.361 [debug] Federating https://sabbat.hexe.net/activities/...... to https://mstdn.jp/inbox
```
Maybe this affects this decision, but I'm not sure.
https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/common_api.ex#L370-372
```elixir
def public_announce?(_, %{visibility: visibility})
when visibility in ~w{public unlisted private direct},
do: visibility in ~w(public unlisted)
def public_announce?(object, _) do
Visibility.public?(object)
end
```https://git.pleroma.social/pleroma/pleroma/-/issues/3234Cannot fetch posts on Concurrent2024-02-15T01:30:23ZSyoBoNCannot fetch posts on Concurrent<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.1
* Elixir version (`elixir -v` for from source installations, N/A for OTP): 1.14.5
* Operating system: FreeBSD 14.0-RELEASE-p3
* PostgreSQL version (`psql -V`): 16.1
### Bug description
Pleroma cannot fetch posts which are on [Concurrent](https://github.com/totegamma/concurrent) (via [ccworld-ap-bridge](https://github.com/totegamma/ccworld-ap-bridge)).
The following is the some messages left in the log file when I tried to fetch https://cc.mkdir.uk/ap/note/e5d1d0a1-1ab3-4498-9949-588e3fdea286:
```
pleroma[2945]: [error] Elixir.Pleroma.Web.MastodonAPI.SearchController search error: %Protocol.UndefinedError{protocol: Enumerable, value: nil, description: ""}
pleroma[2945]: [error] Error while fetching : {:error, "Unsupported URI scheme"}
pleroma[2945]: [warn] Couldn't fetch "", error: nil
pleroma[2945]: [error] Error while fetching : {:error, "Unsupported URI scheme"}
pleroma[2945]: [warn] Couldn't fetch "", error: nil
pleroma[2945]: [error] Error while fetching : {:error, "Unsupported URI scheme"}
pleroma[2945]: [warn] Couldn't fetch "", error: nil
pleroma[2945]: [error] Error while fetching : {:error, "Unsupported URI scheme"}
pleroma[2945]: [warn] Couldn't fetch "", error: nil
pleroma[2945]: [error] Elixir.Pleroma.Web.MastodonAPI.SearchController search error: %FunctionClauseError{module: Pleroma.Web.ActivityPub.ObjectValidators.CreateGenericValidator, function: :validate_context_match, arity: 2, kind: nil, args: nil, clauses: nil}
```
I couldn't judge if this is a problem on the Pleroma side or on the Concurrent side, but since I can fetch them on Misskey, I decided to create an issue here.https://git.pleroma.social/pleroma/pleroma/-/issues/3232Federation with @threads.net instance not possible2024-01-17T10:11:43ZGeorg PagenstedtFederation with @threads.net instance not possibleThreads user accounts like @mosseri@threads.net can be followed from mastodon. However, this is not possible from pleroma. I did read in [r/Pleroma](https://www.reddit.com/r/Pleroma/comments/18mqe05/comment/kf0nh7f/), this could be "some...Threads user accounts like @mosseri@threads.net can be followed from mastodon. However, this is not possible from pleroma. I did read in [r/Pleroma](https://www.reddit.com/r/Pleroma/comments/18mqe05/comment/kf0nh7f/), this could be "some kind of authfetch issue".https://git.pleroma.social/pleroma/pleroma/-/issues/3231Can't import a comment from Firefish2024-01-13T22:23:22Za1batrossa1ba.omarov@gmail.comCan't import a comment from Firefish<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): From Sauce
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): https://git.pleroma.social/pleroma/pleroma/commit/6722b7f3
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Erlang/OTP 25, elixir 1.14.3
* Operating system: Ubuntu 22.04
* PostgreSQL version (`psql -V`): 15.4
### Bug description
Pasted this link https://fireshark.social/notes/9o7nm4wqulv1a8wm into a search box and pressed Enter. Post doesn't get imported.
Log:
```
янв 10 20:55:04 UwU mix[3709642]: 20:55:04.050 [info] GET /api/v2/search
янв 10 20:55:04 UwU mix[3709642]: 20:55:04.207 [error] Elixir.Pleroma.Web.MastodonAPI.SearchController search error: %BadMapError{term: nil}
```
Object seems to be valid as it gets imported on both Mastodon and Akkoma.https://git.pleroma.social/pleroma/pleroma/-/issues/3226500 error: "(Regex.CompileError) nothing to repeat at position 1", timeline n...2024-01-02T16:23:31ZNyx Land500 error: "(Regex.CompileError) nothing to repeat at position 1", timeline not loading, can't post anything, it's so over<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.1
* Elixir version (`elixir -v` for from source installations, N/A for OTP): 1.14.3, Erlang/OTP 25
* Operating system: FreeBSD 13.2-RELEASE
* PostgreSQL version (`psql -V`): 12.14
### Bug description
My instance has been experiencing a very weird bug since earlier today that, as far as I can tell, has happened completely randomly possibly from an activity on another instance and that I haven't seen anyone else report. I had upgraded from an older release of Pleroma like a week ago to the most recent release, but it was running fine until suddenly shit broke earlier today and I don't think this is because of an upgrade getting screwed up.
At the moment any recent timeline posts (i.e. since this error started happening) will not load in either Pleroma FE or Husky, so this seems to be a backend issue, and trying to make a post on the FE side will give the "e.text is undefined" error. Here's an example of what shows up in the Pleroma logs:
```
22:46:19.045 [error] #PID<0.14402.0> running Pleroma.Web.Endpoint (connection #PID<0.14401.0>, stream id 1) terminated
Server: social.xenofem.me:80 (http)
Request: POST /inbox
** (exit) an exception was raised:
** (Regex.CompileError) nothing to repeat at position 1
(elixir 1.14.3) lib/regex.ex:231: Regex.compile!/2
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf.ex:140: anonymous fn/2 in Pleroma.Web.ActivityPub.MRF.subdomains_regex/1
(elixir 1.14.3) lib/enum.ex:2468: Enum."-reduce/3-lists^foldl/2-0-"/3
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf.ex:140: Pleroma.Web.ActivityPub.MRF.subdomains_regex/1
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:32: Pleroma.Web.ActivityPub.MRF.SimplePolicy.check_reject/2
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:234: Pleroma.Web.ActivityPub.MRF.SimplePolicy.filter/1
(elixir 1.14.3) lib/enum.ex:2468: Enum."-reduce/3-lists^foldl/2-0-"/3
(pleroma 2.6.1) lib/pleroma/web/activity_pub/activity_pub.ex:1685: Pleroma.Web.ActivityPub.ActivityPub.user_data_from_user_object/2
```
Similar errors will be reported trying to fetch the timeline:
```
22:47:48.603 [error] #PID<0.16133.0> running Pleroma.Web.Endpoint (connection #PID<0.16132.0>, stream id 1) terminated
Server: social.xenofem.me:80 (http)
Request: GET /objects/84de057f-52af-4c71-b42c-506d70839fdd
** (exit) an exception was raised:
** (Regex.CompileError) nothing to repeat at position 1
(elixir 1.14.3) lib/regex.ex:231: Regex.compile!/2
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf.ex:140: anonymous fn/2 in Pleroma.Web.ActivityPub.MRF.subdomains_regex/1
(elixir 1.14.3) lib/enum.ex:2468: Enum."-reduce/3-lists^foldl/2-0-"/3
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf.ex:140: Pleroma.Web.ActivityPub.MRF.subdomains_regex/1
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:32: Pleroma.Web.ActivityPub.MRF.SimplePolicy.check_reject/2
(pleroma 2.6.1) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:234: Pleroma.Web.ActivityPub.MRF.SimplePolicy.filter/1
(elixir 1.14.3) lib/enum.ex:2468: Enum."-reduce/3-lists^foldl/2-0-"/3
(pleroma 2.6.1) lib/pleroma/web/activity_pub/activity_pub.ex:1685: Pleroma.Web.ActivityPub.ActivityPub.user_data_from_user_object/2
```
An example of the sorts of errors that accompany these (the `request_id` seems to always change):
```
01:31:12.520 request_id=F6Z91za8Ru31gegAACEh [error] Internal server error: %Regex.CompileError{message: "nothing to repeat at position 1"}
```
And on the frontend in the console the following error shows up when the page loads along with a bunch of JS garbage whenever I try to type anything into the status box:
```
XHRGET
https://social.xenofem.me/api/v1/accounts/40@den.raccoon.quest@den.raccoon.quest
[HTTP/2 404 Not Found 130ms]
GET
https://social.xenofem.me/api/v1/accounts/40@den.raccoon.quest@den.raccoon.quest
Status
404
Not Found
VersionHTTP/2
Transferred1.38 kB (27 B size)
Referrer Policysame-origin
```
My guess is that Pleroma somehow has an incorrectly formatted username for the user `40` in its database since the instance in the error is `@den.raccoon.quest@den.raccoon.quest`, and maybe that's the source of the regex error, but I have no idea how to actually fix that or how it happened. It may also not even be related. I do know that instance is running some fork of Misskey (Foundkey I think).
Anyways, at the moment my instance is basically unusable and broken so any suggestions would be greatly appreciated.https://git.pleroma.social/pleroma/pleroma/-/issues/3224ChatMessage: `attachment` Validation is too strict2023-12-29T08:12:29ZCalorie ZeroChatMessage: `attachment` Validation is too strict<!--
### 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
ask @tusooa
* Installation type (OTP or From Source):
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.0-0-g2c7e0b20
* Elixir version (`elixir -v` for from source installations, N/A for OTP):
* Operating system:
* PostgreSQL version (`psql -V`):
### Bug description
I'm implementing federation from Firefish Chat to Pleroma Chat . Then I realized I'd been stumbling on a trap for too long.
Pleroma strictly checks `ChatMessage.attachment`, requiring that it either does not exist or is not empty. In fact, better compatibility would be achieved if empty arrays were allowed.
```
iex(pleroma@127.0.0.1)9> Pleroma.Web.ActivityPub.ObjectValidator.validate(c, local: false)
{:error,
#Ecto.Changeset<
action: :insert,
changes: %{
actor: "....(hidden)",
attachment: #Ecto.Changeset<
action: :insert,
changes: %{},
errors: [
type: {"can't be blank", [validation: :required]},
url: {"can't be blank", [validation: :required]}
],
data: #Pleroma.Web.ActivityPub.ObjectValidators.AttachmentValidator<>,
valid?: false
>,
content: "<p><span>ChatMessage test?</span></p>",
id: "....(hidden)",
published: "2023-12-25T17:33:42.742Z",
to: [""....(hidden)""],
type: "ChatMessage"
},
errors: [],
data: #Pleroma.Web.ActivityPub.ObjectValidators.ChatMessageValidator<>,
valid?: false
>}
```tusooatusooahttps://git.pleroma.social/pleroma/pleroma/-/issues/3220Possible thumbnailing issues2023-12-20T05:36:01ZlainPossible thumbnailing issuesThe images in these posts were reported to be thumbnailing in black and white:
```
https://press.coop/@WIRED/111584803008403307
https://mastodon.art/@your_raccoon/111584590732274347
```The images in these posts were reported to be thumbnailing in black and white:
```
https://press.coop/@WIRED/111584803008403307
https://mastodon.art/@your_raccoon/111584590732274347
```