pleroma issues
https://git.pleroma.social/pleroma/pleroma/-/issues
2024-03-25T19:58:26Z
https://git.pleroma.social/pleroma/pleroma/-/issues/3261
Markers API `updated_at` property does not include timezone
2024-03-25T19:58:26Z
Nik Clayton
Markers API `updated_at` property does not include timezone
<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...
<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Discovered in rebelbase.site which reports the version as "2.7.2 (compatible; Pleroma 2.6.0)"
### Bug description
The markers API response from a Pleroma 2.6 server returns the `updated_at` property as an ISO8601 date/time (per the code in https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/mastodon_api/views/marker_view.ex) without a timezone.
E.g.,
```json
{
"notifications": {
"last_read_id": "",
"pleroma": {
"unread_count": 1
},
"updated_at": "2024-03-24T14:01:35",
"version": 0
}
}
```
I suspect (but have not verified) that changing this line:
```
updated_at: NaiveDateTime.to_iso8601(m.updated_at),
```
in the code to:
```
updated_at: Utils.to_masto_date(m.updated_at),
```
will fix this.
Reported via gvansanden who discovered this in https://github.com/pachli/pachli-android/issues/562
https://git.pleroma.social/pleroma/pleroma/-/issues/3260
Subway tooter can't upload media because it won't fall back to application/oc...
2024-03-19T16:50:37Z
Your New SJW Waifu
Subway tooter can't upload media because it won't fall back to application/octet-stream
<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...
<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 0e4e20315b
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Erlang/OTP 25 [erts-13.0.4] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [jit:ns]
Elixir 1.13.4 (compiled with Erlang/OTP 25)
* Operating system: Ubuntu 22.04
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 16.2 (Ubuntu 16.2-1.pgdg22.04+1)
### Bug description
Due to !4081 subway tooter can no longer upload media because. In #3249 the idea was proposed to just set it to `application/octet-stream` which seemed like a good idea but apparently applications like subway tooter expected `image/jpeg` and if `image/jpeg` isn't explicitly named you're not allowed to upload media.
Yeah, bad app design, but I feel like this is something that should be fixed because this probably won't be the last time that a tool built for mastodon won't work on pleroma because of this.
This should also plug into the Pleroma.Upload.Filter.OnlyMedia or maybe the answer is to build a more comprehensive mime upload filter and pull from there for the API endpoint.
![screenshot by zonk](https://bae.st/media/024cbcbb69e0e843ed2fecfa65f6942f80402861f529ae91f354709903dd6528.png?name=Screenshot_20240309-235048.png)
https://git.pleroma.social/pleroma/pleroma/-/issues/3258
Add "indexable" user profile parameter to make posts searchable on Mastodon
2024-03-17T20:08:48Z
lamp
lamp@owo69.me
Add "indexable" user profile parameter to make posts searchable on Mastodon
Mastodon now allows searching posts, but users have to opt-in with `"indexable":true` in their user profile data. Pleroma and Pleroma-FE needs to add this option so that Pleroma users can make themselves searchable on Mastodon.
Mastodon now allows searching posts, but users have to opt-in with `"indexable":true` in their user profile data. Pleroma and Pleroma-FE needs to add this option so that Pleroma users can make themselves searchable on Mastodon.
https://git.pleroma.social/pleroma/pleroma/-/issues/3256
Copyright headers
2024-03-12T16:51:36Z
Sean King
Copyright headers
About a year or so ago, we stopped updating the copyright headers after Lain reverted the 2023 update.
Since then, lanodan brought up the possibility of just having `Copyright © 2017 Pleroma Authors <https://pleroma.social/>`, with 2017...
About a year or so ago, we stopped updating the copyright headers after Lain reverted the 2023 update.
Since then, lanodan brought up the possibility of just having `Copyright © 2017 Pleroma Authors <https://pleroma.social/>`, with 2017 being the first year of the Pleroma project, in the headers.
Feld also mentioned an [article about curl having copyright headers without the year](https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/) in them.
I wanted to continue this discussion here so that we can figure out what we want to do regarding copyright headers in the future.
https://git.pleroma.social/pleroma/pleroma/-/issues/3255
MRF_keyword replace should not change usernames or domains.
2024-03-06T21:17:01Z
Mr. Twizzay
MRF_keyword replace should not change usernames or domains.
### Environment
* Installation type OTP on Yunohost:
* Pleroma version 2.5.5:
* Operating system: Debian
* PostgreSQL version: 13.14
### Bug description
The current `mrf_keyword, replace:` policy causes federation issues because it re...
### Environment
* Installation type OTP on Yunohost:
* Pleroma version 2.5.5:
* Operating system: Debian
* PostgreSQL version: 13.14
### Bug description
The current `mrf_keyword, replace:` policy causes federation issues because it rewrites usernames and domains.
This forbids local users from interacting with remote users or instances that contain words which would match in this policy. It does not stop the remote users from being able to post to these local users. So, it basically shadowbans local users from certain remote instances. This would almost never be desired. If domains and/or usernames want to be rejected, that should be left to other policies.
One solution might be to superimpose an additional regex over the admin-provided regex in the mrf policy.
```js
/((.*)(@)(.*))?dog((.*)(@)(.*))?/
```
`dog` would be replaced with whatever regex is given in the policy. Then some additional logic would need to check whether groups 3 or 7 contained `@`.
[Here is the obligatory regex101 for testing](https://regex101.com/r/tdcnGL/2)
Notice that my suggestion would continue to overwrite URL's. I think this would be wise. Admins may want to use this policy to redirect certain url's to other sites. For example redirecting youtube or twitter to other more private front-ends like invidious or nitter.
# Consider the following
I think this deserves a priority because content moderation is one of pleroma's greatest strengths. By moderating content over users/instances we help keep the fediverse healthy while enabling admins to control the content that is pulled into their instance. No other project that I know of is prioritizing this currently.
As always, TIA and long live pleroma-tan. :fist:
https://git.pleroma.social/pleroma/pleroma/-/issues/3254
WebFinger endpoint responds with XRD instead of JRD in browser
2024-03-09T18:01:39Z
a
WebFinger endpoint responds with XRD instead of JRD in browser
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.51-650-g0b9bc4a0-develop as observed on lain.com
### Bug description
Actual behavior:
- WebFinger when requested in a browser is re...
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.51-650-g0b9bc4a0-develop as observed on lain.com
### Bug description
Actual behavior:
- WebFinger when requested in a browser is responding with an XRD that gets downloaded -- likely because browsers by default specify an Accept header that includes application/xml
Expected behavior:
- WebFinger responds with a JRD in-browser -- this is the expected response of the .well-known/webfinger endpoint and also the response that pretty much every other implementation seems to express
In searching I found #2579 which may or may not be related.
https://git.pleroma.social/pleroma/pleroma/-/issues/3253
Object is ignored if `url` property value is an array
2024-03-02T22:43:48Z
silverpill silverpill
Object is ignored if `url` property value is an array
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.2
### Bug description
Incoming objects where `url` property is an array are not accepted by Pleroma. Array values might be necessar...
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.2
### Bug description
Incoming objects where `url` property is an array are not accepted by Pleroma. Array values might be necessary for implementing some FEPs such as [FEP-fffd](https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md). Among existing AP implementations, PeerTube uses `url` arrays in its `Video` objects.
(Disclaimer: I haven't verified this myself, the issue was discovered by an automated testing tool: https://data.funfedi.dev/0.1.1/pleroma__v2.6.2/url/)
https://git.pleroma.social/pleroma/pleroma/-/issues/3252
How can I revert split user data resulting from a switch between HTTP and HTT...
2024-03-02T13:45:41Z
Yasaka
How can I revert split user data resulting from a switch between HTTP and HTTPS communication?
### Bug description
I encountered a situation where user data split due to a switch between HTTP and HTTPS communication protocols, and I need to address it safely.
A federated server, initially configured with HTTPS, inadvertently swi...
### Bug description
I encountered a situation where user data split due to a switch between HTTP and HTTPS communication protocols, and I need to address it safely.
A federated server, initially configured with HTTPS, inadvertently switched to HTTP communication and then returned to HTTPS. Subsequently, user data in the database became split, with accounts having and lacking prefixes. In such cases, post delivery may become irregular depending on previous follow relationships, although I lack detailed insights due to being unable to confirm symptoms across multiple servers.
Example:
ATw2gPkaQEOPHE0pkG.magi@minazukey.uk
magi@minazukey.uk
Given that these are the same users on the same server, I need a safe method to rectify this state. Unfortunately, on one server, after account data with prefixes was deleted to fix this situation, rendering users on that server unable to follow.
**The split of IDs appears to occur under the following conditions:**
1.There is a user "alice" on a Pleroma (or Akkoma) server X. There is a user "bob" on a Misskey (or Firefish) server Y. The URL in Y's .config/default.yml is set to HTTPS.
2.At this stage, normal communication is established. At this point, "bob" is known to X (e.g., through follow relationships or boosts). The URL in Y is changed to HTTP.
3.Upon delivery from "bob" to X, a new user ID is assigned internally within X under HTTP settings, while the existing "bob" associated with HTTPS is renamed with an internal ID as a prefix. The URL in Y is changed back to HTTPS.
4.Posts from "bob" are associated with the old ID (with prefix) in X. In this state, there may be irregularities in delivery for new follows or regular posts from previously followed users.
Refreshing follows in state 4 sometimes improves delivery. As the administrator of server Y, I lack access to the internal data of Pleroma servers and face challenges in addressing the same issue across multiple federated servers due to my mistake. Please, I need advice on how to fix it.
https://git.pleroma.social/pleroma/pleroma/-/issues/3251
Missing `configuration.accounts` property in Pleroma servers
2024-02-27T05:45:22Z
Nik Clayton
Missing `configuration.accounts` property in Pleroma servers
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g 0b9bc4a0-develop)" (at least, but see below)
### Bug description
Some Pleroma servers are not ...
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g 0b9bc4a0-develop)" (at least, but see below)
### Bug description
Some Pleroma servers are not returning a `configuration.accounts` property at `/api/v2/instance`. This is a non-nullable non-optional property, so it should be present.
Affected servers (incomplete): activitypub.agates.io, apontaeclica.com, bassam.social, bearvideo.win, c.wtf, clew.lol, fediverse.spearman.xyz, foygl.com, gleasonator.com, hidamari.apartments, iddqd.social, idolheaven.org, jacksonhomestead.me, killyour.dad, leafposter.club, lm.kazv.moe, neenster.org, orwell.fun, p.sugar-free-jazz.com,
parcero.bond, pl.eragon.re, pl.fediverse.pl, pl.kotobank.ch, pleroma.dark-alexandr.net, pleroma.pibvt.net, pleroma.woodynet.net, rabbithou.se, rebased.social, rebased.taihou.website, redsnake.io, seal.cafe, shinkai.party, shitposting.on.incorrigible.moe, social.dansonline.space, social.linuxine.net, social.luizpicolo.com.br, social.protectors.moe, social.rucksfuchs.de, social.teci.world, socialgoblins.club, sosial.agdersam.no, svltan.at, twhtv.club, updog.no, vnil.de, vocalfry.social
https://git.pleroma.social/pleroma/pleroma/-/issues/3250
`configuration.statuses.characters_reserved_per_url` missing from some Plerom...
2024-02-27T05:45:03Z
Nik Clayton
`configuration.statuses.characters_reserved_per_url` missing from some Pleroma servers
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (at least, but see below)
### Bug description
I see a number of Plerorma ser...
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (at least, but see below)
### Bug description
I see a number of Plerorma servers that have somehow been configured such that `characters_reserved_per_url` is missing from the `/api/v2/instance` response.
That's a non-optional, non-nullable property according to https://docs.joinmastodon.org/entities/Instance/#characters_reserved_per_url, so should be present.
Affected servers include: activitypub.agates.io, apontaeclica.com, bassam.social, bearvideo.win, c.wtf, clew.lol, fediverse.spearman.xyz, foygl.com, gleasonator.com, hidamari.apartments, iddqd.social, idolheaven.org, jacksonhomestead.me, killyour.dad, leafposter.club, lm.kazv.moe, neenster.org, orwell.fun, p.sugar-free-jazz.com, parcero.bond, pl.eragon.re, pl.fediverse.pl, pl.kotobank.ch, pleroma.dark-alexandr.net, pleroma.pibvt.net, pleroma.woodynet.net, rabbithou.se, rebased.social, rebased.taihou.website, redsnake.io, seal.cafe, shinkai.party, shitposting.on.incorrigible.moe, social.dansonline.space, social.linuxine.net, social.luizpicolo.com.br, social.protectors.moe, social.rucksfuchs.de, social.teci.world, socialgoblins.club, sosial.agdersam.no, svltan.at, twhtv.club, updog.no, vnil.de, vocalfry.social
Many of those servers are in the list in 3249 as well, which is why I've linked the issues in case there's something in common between them.
https://git.pleroma.social/pleroma/pleroma/-/issues/3249
Missing `configuration.media_attachments` child properties in Pleroma servers
2024-03-23T13:30:16Z
Nik Clayton
Missing `configuration.media_attachments` child properties in Pleroma servers
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (one server example, but see below)
### Bug description
It seems to be possi...
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.6.51-650-g0b9bc4a0-develop)" (one server example, but see below)
### Bug description
It seems to be possible for users to configure Pleroma servers so that important properties are missing from the `configuration.media_attachments` property in the value returned from `/api/v2/instance`.
I've observed missing:
- `supported_mime_types`
- `image_matrix_limit`
- `video_frame_rate_limit`
- `video_matrix_limit`
properties. None of these are allowed to be missing (or null), per https://docs.joinmastodon.org/entities/Instance/#media_attachments.
I did think that maybe this was the result of the admin disabling media attachments, but it's not. For example, https://gleasonator.com/api/v1/instance shows all of these problems, but also reports `configuration.statuses.max_media_attachments` as 20.
Servers I've seen this on include: activitypub.agates.io, apontaeclica.com, bassam.social, bearvideo.win, c.wtf, clew.lol, fediverse.spearman.xyz, foygl.com, gleasonator.com, iddqd.social, idolheaven.org, jacksonhomestead.me, killyour.dad, leafposter.club, lm.kazv.moe, neenster.org, orwell.fun, p.sugar-free-jazz.com, parcero.bond, pl.kotobank.ch, pleroma.dark-alexandr.net, pleroma.pibvt.net, pleroma.woodynet.net, rabbithou.se, rebased.social, rebased.taihou.website, redsnake.io, seal.cafe, shinkai.party, shitposting.on.incorrigible.moe, social.dansonline.space, social.linuxine.net, social.luizpicolo.com.br, social.protectors.moe, social.rucksfuchs.de, social.teci.world, socialgoblins.club, sosial.agdersam.no, svltan.at, twhtv.club, updog.no, vocalfry.social
Some of these are servers running soapbox (reporting `+soapbox`), but some aren't -- for example, https://idolheaven.org/api/v2/instance
https://git.pleroma.social/pleroma/pleroma/-/issues/3248
Pleroma can be configured to return numbers that are too large
2024-02-26T19:30:14Z
Nik Clayton
Pleroma can be configured to return numbers that are too large
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.5.54-325-gb729a8b1-develop)"
### Bug description
JSON is Javascript, and Javascript cannot safely represe...
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): "2.7.2 (compatible; Pleroma 2.5.54-325-gb729a8b1-develop)"
### Bug description
JSON is Javascript, and Javascript cannot safely represent integers larger than 2^54 -1 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER).
Users can configure Pleroma servers with values that are too large, causing problems for interoperability between clients and servers.
For example, https://hkgk.nishi.boats is currently reporting that `max_toot_chars` property value as `5000000000000000000000000000`.
If you try `parseInt(5000000000000000000000000000)` in a Javascript console you'll see that's `5`.
This is a bit of an extreme example, but users should probably be prevented from shooting themselves in the foot like this, and Pleroma should refuse to start (with a clear explanation as to why) if it is misconfigured in this way.
https://git.pleroma.social/pleroma/pleroma/-/issues/3247
Separate accounts from actors?
2024-02-26T19:20:24Z
marcin mikołajczak
Separate accounts from actors?
I wonder if it makes sense for Pleroma upstream to separate user accounts from actors and (if enabled) allow the account to own more than one actor. This would allow to eg. create `Group`s without need for an account for each one of them...
I wonder if it makes sense for Pleroma upstream to separate user accounts from actors and (if enabled) allow the account to own more than one actor. This would allow to eg. create `Group`s without need for an account for each one of them. This could also allow multiple users to manage a single actor. And there would be no unnecessary columns like email address for remote/internal actors
There are existing ActivityPub implementations with this feature, like [Takahē](https://docs.jointakahe.org/en/latest/moderation/#identities).
https://git.pleroma.social/pleroma/pleroma/-/issues/3246
Account moving is impossible even with webfinger lookup listing alias on remo...
2024-02-26T19:20:07Z
thomas nuker
Account moving is impossible even with webfinger lookup listing alias on remote account
<!--
### 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.2
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Elixir 1.14.0 (compiled with Erlang/OTP 24)
* Operating system: Debian
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 15.5 (Debian 15.5-0+deb12u1)
### Bug description
The account moving feature appears to be entirely non-functional even with an account alias set up on the account you want to move to, simply displaying the message "Error moving account: Target account not found.". This issue occurs on several instances of Pleroma on completely different setups hardware wise. A webfinger query Pleroma attempts to make to the remote instance appears to display correct results, and trying the query again using curl returns the expected aliases.
[chris@mashtodon.alterracloud.com attempting to move to kirby@lab.nyanide.com](https://imgur.com/a/IPVwBbH)
[kirby@lab.nyanide.com's aliases](https://imgur.com/a/ZDfHjN5)
[Trying to make webfinger query from mashtodon.alterracloud.com to lab.nyanide.com](https://imgur.com/a/1jm5iX6)
https://git.pleroma.social/pleroma/pleroma/-/issues/3243
home timeline is non deterministic, due to wrong volatility on pgplsql functi...
2024-02-17T03:33:56Z
pleb
home timeline is non deterministic, due to wrong volatility on pgplsql functions?
with the same query and data, the home timeline sql query is annoyingly non deterministic
is anyone willing to figure out which pgplsql functions need to have their volatility downgraded?
i've tried alter'ing them to STABLE, but it hasn...
with the same query and data, the home timeline sql query is annoyingly non deterministic
is anyone willing to figure out which pgplsql functions need to have their volatility downgraded?
i've tried alter'ing them to STABLE, but it hasn't helped
https://git.pleroma.social/pleroma/pleroma/-/issues/3242
Match/check the return value of the Supervisor in application.ex to make cert...
2024-02-17T03:33:08Z
pleb
Match/check the return value of the Supervisor in application.ex to make certain misconfiguration errors more clear
This is a really small change, result should be matched to {:ok, pid} at https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/application.ex?ref_type=heads#L122
in case of an :error, the result is swallowed up instead o...
This is a really small change, result should be matched to {:ok, pid} at https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/application.ex?ref_type=heads#L122
in case of an :error, the result is swallowed up instead of printed, and the user is likely to see a generic Ecto failure instead of why the tree failed to start
https://git.pleroma.social/pleroma/pleroma/-/issues/3240
Investigate Mogrify downgrade
2024-02-17T03:31:48Z
feld
Investigate Mogrify downgrade
Mogrify was downgraded in 03db495e which is due to rinpatch_blurhash depending on `{:mogrify, "~> 0.8.0"}`. Can we fix this and get Mogrify updated again?
Mogrify was downgraded in 03db495e which is due to rinpatch_blurhash depending on `{:mogrify, "~> 0.8.0"}`. Can we fix this and get Mogrify updated again?
2.6.3
https://git.pleroma.social/pleroma/pleroma/-/issues/3238
Preview card returned without mandatory `author_name` property
2024-02-17T03:31:14Z
Nik Clayton
Preview card returned without mandatory `author_name` property
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Backend 2.5.5 / Frontend eec27700
### Bug description
Hi, Pachli (https://pachli.app) dev. here. A user's just reported a crash when P...
### Environment
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): Backend 2.5.5 / Frontend eec27700
### Bug description
Hi, Pachli (https://pachli.app) dev. here. A user's just reported a crash when Pachli processes Pleroma PreviewCard JSON in a status. The crash indicates that the `author_name` propertyis missing from the JSON.
```
com.squareup.moshi.JsonDataException: Required value 'authorName' (JSON name 'author_name') missing at $
at com.squareup.moshi.internal.Util.e(SourceFile:44)
at app.pachli.core.network.model.CardJsonAdapter.fromJson(SourceFile:54)
at app.pachli.core.network.model.CardJsonAdapter.fromJson(SourceFile:1)
...
```
This property is mandatory and non-null, per https://docs.joinmastodon.org/entities/PreviewCard/#author_name.
I checked https://docs-develop.pleroma.social/backend/development/API/differences_in_mastoapi_responses/ and didn't see this listed as a difference between Pleroma and the Mastodon API, so I assume this is a bug.
https://git.pleroma.social/pleroma/pleroma/-/issues/3237
Pleroma Debian install doesn't listen on any port
2024-02-17T03:29:51Z
tinfoil hat
Pleroma Debian install doesn't listen on any port
Hi,
I installed Pleroma on a LXC Container inside a Proxmox VPS. I installed it on Debian using these instructions:
https://docs-develop.pleroma.social/backend/installation/debian_based_en/
I want to run it inside the LXC and connec...
Hi,
I installed Pleroma on a LXC Container inside a Proxmox VPS. I installed it on Debian using these instructions:
https://docs-develop.pleroma.social/backend/installation/debian_based_en/
I want to run it inside the LXC and connect to it via nginx reverse proxy on Proxmox host, which is public. That's the reason I want it to listen on 0.0.0.0
As you can see, it's running
```
root@pleroma:/opt/pleroma# systemctl status pleroma
● pleroma.service - Pleroma social network
Loaded: loaded (/etc/systemd/system/pleroma.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-02-09 01:57:31 UTC; 1s ago
Main PID: 14403 (beam.smp)
Tasks: 29 (limit: 19112)
Memory: 60.8M
CPU: 1.500s
CGroup: /system.slice/pleroma.service
├─14403 /usr/lib/erlang/erts-13.1.5/bin/beam.smp -- -root /usr/lib/erlang -bindir /usr/lib/erlang/erts-13.1.5/bin -progname erl -- -home /var/lib/pleroma -- -pa /usr/lib/elixir/bin/../lib/eex/ebin /usr/lib/elixir/bin/../lib/elixir/ebin /usr/lib/elixir/bin/../>
└─14418 erl_child_setup 1024
Feb 09 01:57:31 pleroma systemd[1]: Started pleroma.service - Pleroma social network.
```
I also made sure, I used
`sudo -Hu pleroma mv config/{generated_config.exs,prod.secret.exs}`
like it says in the Documentation
It should be listening on 0.0.0.0 port 4000
`less config/prod.secret.exs`
```
# Pleroma instance configuration
# NOTE: This file should not be committed to a repo or otherwise made public
# without removing sensitive information.
import Config
config :pleroma, Pleroma.Web.Endpoint,
url: [host: "domain.tld", scheme: "https", port: 443],
http: [ip: {0, 0, 0, 0}, port: 4000],
...
```
There is no pleroma listening on any port ... strange
```
root@pleroma:/opt/pleroma# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 103 4074776 143/postgres
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 4075966 296/master
tcp6 0 0 :::22 :::* LISTEN 0 4071416 1/init
tcp6 0 0 ::1:25 :::* LISTEN 0 4075967 296/master
tcp6 0 0 ::1:5432 :::* LISTEN 103 4074775 143/postgres
tcp6 0 0 :::4369 :::* LISTEN 0 4071415 1/init
root@pleroma:/opt/pleroma#
```
https://git.pleroma.social/pleroma/pleroma/-/issues/3236
Replies from minds potentially don't generate notifications
2024-02-06T05:36:23Z
lain
Replies from minds potentially don't generate notifications
I noticed that this message did not create a notification for me:
https://lain.com/notice/AeXtVCGmCocmwhDXlI
I noticed that this message did not create a notification for me:
https://lain.com/notice/AeXtVCGmCocmwhDXlI