pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-05-08T04:09:00Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/207PleromaFE notice HTML should include a AP json and Atom XML <link>2023-05-08T04:09:00ZKane YorkPleromaFE notice HTML should include a AP json and Atom XML <link>HTML pages should include a `application/activity+json` and `application/atom+xml` `<link rel=alternate>`, and the frontend JS should keep this element up to date when moving to other pages.
For example, the page returned by https://cat...HTML pages should include a `application/activity+json` and `application/atom+xml` `<link rel=alternate>`, and the frontend JS should keep this element up to date when moving to other pages.
For example, the page returned by https://cathoderay.tube/notice/45021 should include this HTML element:
(option A, if #206 is implemented)
<link href='https://cathoderay.tube/notice/45021' rel='alternate' type='application/atom+xml'>
<link href='https://cathoderay.tube/notice/45021' rel='alternate' type='application/activity+json'>
(option B)
<link href='https://cathoderay.tube/objects/f2feb28f-56d9-4000-a719-561831dfa487' rel='alternate' type='application/atom+xml'>
<link href='https://cathoderay.tube/objects/f2feb28f-56d9-4000-a719-561831dfa487' rel='alternate' type='application/activity+json'>
Upon navigation away from the status, the link should be removed. Upon navigation to a status page, the link should be updated to point to the currently viewed status.
Purpose: I want to create a browser extension that will be able to recognize that you are on a AP/OStatus-enabled page, and let you reply nearly-inline.lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/237add apache examples to pleroma guides2021-02-09T06:35:27ZDebbieadd apache examples to pleroma guidesas a Apache user, not familar with Nginx at all, this is something I would like. this guide for example https://git.pleroma.social/pleroma/pleroma/wikis/Easy-Onion-Federation-(Tor) has a Nginx example, but not a Apache one.
thanksas a Apache user, not familar with Nginx at all, this is something I would like. this guide for example https://git.pleroma.social/pleroma/pleroma/wikis/Easy-Onion-Federation-(Tor) has a Nginx example, but not a Apache one.
thankshttps://git.pleroma.social/pleroma/pleroma/-/issues/244rekey account when it deletes something2023-05-08T03:36:21Zkaniinirekey account when it deletes somethingthis is necessary to enable plausible deniabilitythis is necessary to enable plausible deniabilityHaelwennHaelwennhttps://git.pleroma.social/pleroma/pleroma/-/issues/384Optionally support Troy Hunt’s Pwned Password API2023-05-08T07:58:00ZshibayashiOptionally support Troy Hunt’s Pwned Password APIOne way to ensure peoples’ safety is to prevent them from setting unsafe passwords, specifically that they do not set a password that is already part of a known data breach. Checking against a black list is also part of the new NIST pass...One way to ensure peoples’ safety is to prevent them from setting unsafe passwords, specifically that they do not set a password that is already part of a known data breach. Checking against a black list is also part of the new NIST password guidance [1]. One way to do this is to use Troy Hunt’s Pwned Passwords API [2].
Troy Hunt maintains a huge list of publicly known data breaches and provides ways to check for leaked email addresses and passwords.
## How the API works
* Take the user password
* Generate the SHA1 hash of it
* Send the first 5 characters of it to the API endpoint (either a self-hosted one or Troy Hunt’s one)
* The API will return a list with the remainders of all hashes which start with the characters, additionally a counter is appended to each entry, in how many leaks this password was part of
* The client checks locally, which one of these hashes is the right one
* If the counter is `> 0` then the password is compromised
Because the returned list contains a lot of hash suffixes, anonymity is guaranteed by the k-anonymity model [3]. The list of passwords can either be downloaded and served locally or be accessed with `https://api.pwnedpasswords.com/range/{hashPrefix}`. According to Troy, almost all requests are in the Cloudflare cache and very few requests actually hit his server.
## Who uses this?
Some examples are:
* 1Password
* Eve Online
* Nextcloud
* Bitwarden
* Firefox Monitor
## How could we implement this?
* Provide config options, similar to the suggestions API:
```exs
config :pleroma, :pwned_passwords_check,
enabled: false,
check_always: false,
third_party_engine:
"https://api.pwnedpasswords.com/range/"
```
* Integrate the check in the password reset controller
* Do not reset the password, if the password was leaked
If `check_always` is true, the check happens always for everyone. If it is false, a small icon should be displayed in the password change dialog, similar to 1Password and Bitwarden, and the check happens if the user decides to click on that icon. Maybe include this in the list of features in PleromaFE to help people avoid registering on instances, which offer this service.
I am aware that this can be seen as a controversial feature, that’s why I would make this very configurable and entirely optional, yet I do see this as an useful feature to offer.
1. [NIST Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html)
2. [Pwned Password API](https://haveibeenpwned.com/Passwords)
3. [k-anonymity](https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/)
4. [API description](https://haveibeenpwned.com/API/v2)https://git.pleroma.social/pleroma/pleroma/-/issues/386[OAuth] return HTTP 401 if things go wrong2023-05-08T08:32:04ZRoy Tam[OAuth] return HTTP 401 if things go wrong`/oauth/token` should return HTTP `401` with error code instead of HTTP `500` if parameters are invalid (testcase: old version Cuckoo+ redirect users to OAuth authorize page without properly encoding `client_id`, resulting padding charac...`/oauth/token` should return HTTP `401` with error code instead of HTTP `500` if parameters are invalid (testcase: old version Cuckoo+ redirect users to OAuth authorize page without properly encoding `client_id`, resulting padding characters missed in `client_id`, and after authorized it `POST` to `/oauth/token` with complete `client_id` that is not being authorized [and also improperly processed `code`], and pleroma returns HTTP `500` instead of HTTP `401` with `error` code `unauthorized_client` or `server_error`)lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/400Implement OpenID Connect2019-05-31T10:11:50ZsuccfemboiImplement OpenID ConnectHaving support for OpenID would enable pleroma to act as an identity-server, which could be used for a "sign-in-as" option.
Last I'm aware of is that GNUsocial already has support for it.
There already are implementation of it OpenID in...Having support for OpenID would enable pleroma to act as an identity-server, which could be used for a "sign-in-as" option.
Last I'm aware of is that GNUsocial already has support for it.
There already are implementation of it OpenID in [Erlang](https://github.com/indigo-dc/oidcc) and in [Elixir](https://github.com/mustafaturan/shield/tree/ui). The Elixir variant does seem to be built on the same webframework that pleroma uses, but it has been archived for some reason.
This has been referenced [here](https://git.pleroma.social/pleroma/pleroma/issues/235#note_4217) as a possibility for a sign-in option, but I don't think it's a good Idea to close an issue when it hasn't been veritably resolved yet.
https://git.pleroma.social/pleroma/pleroma/-/issues/416Streaming API doesn't use chunked encoding (breaks bitlbee-mastodon)2020-04-24T14:41:53ZrjpStreaming API doesn't use chunked encoding (breaks bitlbee-mastodon)[bitlbee-mastodon](https://alexschroeder.ch/software/Bitlbee_Mastodon) tries to use the streaming API (`/api/v1/streaming/user`) but gets confused due to the connection being a "normal" HTTP connection (`Content-Length`, `keep-alive`) ra...[bitlbee-mastodon](https://alexschroeder.ch/software/Bitlbee_Mastodon) tries to use the streaming API (`/api/v1/streaming/user`) but gets confused due to the connection being a "normal" HTTP connection (`Content-Length`, `keep-alive`) rather than being chunked (no `Content-Length`, `Transfer-Encoding: chunked`). The underlying HTTP code in bitlbee records a closed stream when `req->body_size >= req->content_length` which causes bitlbee-mastodon to consider login failed (`Login error: Stream closed (200 OK)`).
[Mastodon Streaming API docs](https://docs.joinmastodon.org/api/streaming/) says that the streaming endpoints work as "chunked-encoding transfer" (or, alternately, a websocket).
(bitlbee-mastodon is A-OK talking to a Mastodon instance; it's just Pleroma that confuses it.)hrefhref@random.shhrefhref@random.shhttps://git.pleroma.social/pleroma/pleroma/-/issues/432Don't show multiple notifications if multiple tabs are open.2020-05-18T14:48:58ZpieDon't show multiple notifications if multiple tabs are open.When pleroma is open in multiple tabs, every notification is received once per tab rather than only once.When pleroma is open in multiple tabs, every notification is received once per tab rather than only once.https://git.pleroma.social/pleroma/pleroma/-/issues/434Remote Follow rework2019-01-20T15:42:40ZfeldRemote Follow rework1. Remote follow should not work at all if Pleroma is configured not to federate
2. If Pleroma is configured to limit federation to specific instances, the remote follow page should indicate this and suggest to the user that they can fo...1. Remote follow should not work at all if Pleroma is configured not to federate
2. If Pleroma is configured to limit federation to specific instances, the remote follow page should indicate this and suggest to the user that they can follow by signing up for an account on this instance or one of the instances that are allowed to federatehttps://git.pleroma.social/pleroma/pleroma/-/issues/463Testing push notification mix task2023-05-08T00:48:16ZHJTesting push notification mix taskThere should be a mix task for testing sending push notificationsThere should be a mix task for testing sending push notificationshttps://git.pleroma.social/pleroma/pleroma/-/issues/484Visibility that only shows to Mutuals2023-05-08T04:15:21ZpieVisibility that only shows to MutualsIt would be really great to have a visibility option that only shows the post to people who both follow and are followed by you.It would be really great to have a visibility option that only shows the post to people who both follow and are followed by you.https://git.pleroma.social/pleroma/pleroma/-/issues/493Insecure mode2023-05-08T03:47:13ZkaniiniInsecure modeTo facilitate migration from other fediverse software, we would like to be able to replay AP activities into Pleroma. This will of course be problematic because of the anti-spoofing protection and signature requirements. Thusly, it wou...To facilitate migration from other fediverse software, we would like to be able to replay AP activities into Pleroma. This will of course be problematic because of the anti-spoofing protection and signature requirements. Thusly, it would be nice to have a mode which turns these security features off.
Insecure mode should be a special invocation of the Pleroma server instead of a config setting. Something like an environment variable should trigger it.
That would allow us to import data through replaying it. We should also have very noticeable warnings when the server is operating in Insecure mode and it should not attempt to federate in Insecure mode.
(in other words the only functionality that should be live is only the functionality needed to import the data. nothing more.)https://git.pleroma.social/pleroma/pleroma/-/issues/516Safe Mode2020-05-23T14:57:55ZkaniiniSafe ModeThis would be an optional account setting which forces the sensitive flag to true on all media. This is helpful for browsing fedi in public places, like school, work breaks, etc.This would be an optional account setting which forces the sensitive flag to true on all media. This is helpful for browsing fedi in public places, like school, work breaks, etc.https://git.pleroma.social/pleroma/pleroma/-/issues/522MRF Simple alternative: Federation queue2023-05-08T04:15:31ZniaMRF Simple alternative: Federation queueRecently some admins have expressed a distaste for "forced federation".
Pleroma already has MRF Simple's "accept" for more limited federation, but this has some downsides:
* It requires interested admins to do research into existing se...Recently some admins have expressed a distaste for "forced federation".
Pleroma already has MRF Simple's "accept" for more limited federation, but this has some downsides:
* It requires interested admins to do research into existing servers and regular re-review to add anything new that is wanted.
* It requires filling out a form or writing an email if you want to federate with a server that uses it.
* It is heavy — it does not allow "default federated timeline removal", or even "default block", just "always reject".
A "federation approval queue" would have these features:
* Expose discovered servers and servers that wish to exchange activities, via an admin API.
* Allow reviewing queued activities.
* Allow setting default behavior - federated timeline removal, default block, reject, etc.
* Allow admins several options to deal with unapproved servers: approve, approve with federated timeline removal / media NSFW, reject, default block, and possibly more.
* Remove the server from the queue (and possibly allow through activities) once an admin has selected an option.
and provide these advantages:
* Allow more options than just reject-by-default.
* Not require filling out forms to get approved.
* Allow admins to focus on reviewing content that their server actually consumes rather than bothering with shared blocklists to deal with theoretical problems.
* Reduced workload for admins interested in limited federation.
* Reduced workload for admins interested in federating with servers that use limited federation.
Regardless of your opinions of admins that use limited federation or shared blocklists, they are using them, and I think this would provide an option that is better for the fediverse as a whole than the available solutions.https://git.pleroma.social/pleroma/pleroma/-/issues/542RFC7686 Compliance / Don't contact onion domains without proxy.2023-05-08T03:36:34ZirlRFC7686 Compliance / Don't contact onion domains without proxy.Where a .onion domain name is found, this should never be contacted unless a SOCKS proxy has been specified to avoid instances becoming leaks for .onion names via DNS lookups that are going to fail anyway.Where a .onion domain name is found, this should never be contacted unless a SOCKS proxy has been specified to avoid instances becoming leaks for .onion names via DNS lookups that are going to fail anyway.https://git.pleroma.social/pleroma/pleroma/-/issues/574Implement sentry for error reporting2023-05-09T19:10:57ZsuccfemboiImplement sentry for error reportingThis might be controversial but maybe one could implement sentry to log errors on the server. The admin can configure to run the error logger if desired but by default it should be off. The admin might also want to decide if an error rep...This might be controversial but maybe one could implement sentry to log errors on the server. The admin can configure to run the error logger if desired but by default it should be off. The admin might also want to decide if an error report should be sent or nothttps://git.pleroma.social/pleroma/pleroma/-/issues/577Feature Request: Temporary account 'ban' / 'probation'2023-05-08T04:09:11ZThndrFeature Request: Temporary account 'ban' / 'probation'Add in a feature that allows certain moderator levels and the admin of an instance to be able to temporary 'ban' ('probate') an account for X minutes/hours/days/weeks.
When these accounts are temporarily prevented from posting it should...Add in a feature that allows certain moderator levels and the admin of an instance to be able to temporary 'ban' ('probate') an account for X minutes/hours/days/weeks.
When these accounts are temporarily prevented from posting it should alert them with a custom message set by the admin letting them know that they can't post for X amount of time.
Optionally allow a custom default avatar when the account is restricted in this manner to let people know on the local instance that the user is temporarily restricted
*(potential issue: could cause problem with avatar caching, but such an option is mostly for the benefit of local instance users and not the rest of the fediverse)*https://git.pleroma.social/pleroma/pleroma/-/issues/617Implement captcha option for visually impaired people2023-05-08T01:24:02ZIljaImplement captcha option for visually impaired peopleOften captcha's have an audio-option in case with certain disabilities (e.g. people who are blind) need to solve them. The current implementation doesn't have an option like that, which means using captcha blocks certain people from regi...Often captcha's have an audio-option in case with certain disabilities (e.g. people who are blind) need to solve them. The current implementation doesn't have an option like that, which means using captcha blocks certain people from registering.https://git.pleroma.social/pleroma/pleroma/-/issues/656Groups support2023-11-05T23:17:38ZfeldGroups supportSupport for groups. This feature needs input from @lambadalambda as it has been discussed at a high level but needs some details about exactly what we're aiming to achieve.Support for groups. This feature needs input from @lambadalambda as it has been discussed at a high level but needs some details about exactly what we're aiming to achieve.lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/679Email notifications2020-09-03T13:25:23ZlainEmail notificationsOptionally, subscribe to email notifications.Optionally, subscribe to email notifications.https://git.pleroma.social/pleroma/pleroma/-/issues/680Email subscriptions to posts of certain friends2019-05-30T21:40:43ZlainEmail subscriptions to posts of certain friendsWhen you follow someone who does not post too much, you might want to get an email notifiation for posts of that person. Related to https://git.pleroma.social/pleroma/pleroma/issues/679 but not the same.When you follow someone who does not post too much, you might want to get an email notifiation for posts of that person. Related to https://git.pleroma.social/pleroma/pleroma/issues/679 but not the same.https://git.pleroma.social/pleroma/pleroma/-/issues/692Remove files older than X2023-05-08T04:15:11ZnepfagRemove files older than XI'd like to be able to replace all attachments that are older than a certain amount of time (say, half a year) with a symlink to a placeholder image to save disk space. Right now if I try to do that with a shell script then it also overw...I'd like to be able to replace all attachments that are older than a certain amount of time (say, half a year) with a symlink to a placeholder image to save disk space. Right now if I try to do that with a shell script then it also overwrites avatars, which should be preserved.
Could you please add a mix command that does this properly?https://git.pleroma.social/pleroma/pleroma/-/issues/3115Allow user to resend activation email.2023-04-17T12:45:28ZGhost UserAllow user to resend activation email.Activation emails can get lost, resulting in a user not having access to their account and a good username being taken needlessly.
I propose the following improvements:
* [ ] Ability on Pleroma-FE for a user to have their activation e...Activation emails can get lost, resulting in a user not having access to their account and a good username being taken needlessly.
I propose the following improvements:
* [ ] Ability on Pleroma-FE for a user to have their activation email re-sent.https://git.pleroma.social/pleroma/pleroma/-/issues/776Add ability to set up `Accept-Language: ` for rich media requests2023-05-08T04:15:05ZHJAdd ability to set up `Accept-Language: ` for rich media requestsfollowup to #775followup to #775https://git.pleroma.social/pleroma/pleroma/-/issues/808Moderator Mode API for Front Ends2022-07-07T19:30:01ZNotZemichiModerator Mode API for Front EndsFollowing this lovely discussion:
https://shitposter.club/notice/9hhecwQbICDFH4Shmq
An optional mode at compile time to allow an admin grant moderator privileges to moderators to be able to see all/some user actions like unlisted, follo...Following this lovely discussion:
https://shitposter.club/notice/9hhecwQbICDFH4Shmq
An optional mode at compile time to allow an admin grant moderator privileges to moderators to be able to see all/some user actions like unlisted, follower only, direct messages, likes, etc.
That way an admin can sysadmin, moderators moderate.https://git.pleroma.social/pleroma/pleroma/-/issues/829Feature Request: SMTP email/inbox support2020-06-18T13:31:32ZThndrFeature Request: SMTP email/inbox supportI would like to suggest implementing SMTP support into Pleroma to allow users to message other users that have an account on the federated SMTP network and receive messages sent back to them by those users, as if they were two ActivityPu...I would like to suggest implementing SMTP support into Pleroma to allow users to message other users that have an account on the federated SMTP network and receive messages sent back to them by those users, as if they were two ActivityPub users sending private messages to each other.
Since the history of email server software is long and full of strife I assume any SMTP support would come through as a plugin that extends Pleroma by connecting to a local mail server that already has all of that work done, and just translates the protocols.
*I was going to include MUA support in this suggestion but that deserves it's own issue since it could be supported without full SMTP support.*https://git.pleroma.social/pleroma/pleroma/-/issues/830Feature Request: MUA client support2020-06-18T13:32:26ZThndrFeature Request: MUA client supportIt could be possible to allow email clients to connect to a Pleroma server to read and send private messages to other ActivityPub users (and other SMTP users if SMTP is supported by the server)
This would allow users to use not only nor...It could be possible to allow email clients to connect to a Pleroma server to read and send private messages to other ActivityPub users (and other SMTP users if SMTP is supported by the server)
This would allow users to use not only normal email clients, but also would allow specific use clients like DeltaChat(an encrypted messaging platform using email) to be used
Standards DeltaChat uses https://github.com/deltachat/deltachat-android/blob/master/standards.md#standards-used-in-delta-chat
I assume any MUA support without SMTP server support would come as a translation layer between the user and server to allow any standard compliant client to connecthttps://git.pleroma.social/pleroma/pleroma/-/issues/835Stickers2020-09-07T15:11:21ZkaniiniStickersIt is frequently discussed to add support for stickers. So lets actually do it!
Importantly, stickers are *different* than custom emoji. A sticker is an image response that is chosen from a library of images. Ideally, the end user wo...It is frequently discussed to add support for stickers. So lets actually do it!
Importantly, stickers are *different* than custom emoji. A sticker is an image response that is chosen from a library of images. Ideally, the end user would be able to upload her own images and curate them into sticker packs that could be shared with other users.
The question is how do we actually implement it?https://git.pleroma.social/pleroma/pleroma/-/issues/848Simulating groups? subscribing to hashtags2023-05-08T04:08:26ZxxSimulating groups? subscribing to hashtagsLet's pretend there are several hashtags that I care about -- maybe they are for news topics or sex workers on Switter, chat about certain programmers, whatever.
When I am logged in as an end user I can do this :
1. goto //site/tag/wh...Let's pretend there are several hashtags that I care about -- maybe they are for news topics or sex workers on Switter, chat about certain programmers, whatever.
When I am logged in as an end user I can do this :
1. goto //site/tag/whateverthehashtag
2. click "load older statuses"
3. pull up a list of posts tagged with "whateverthehashtag" through Pleroma magic
In the same way I can switch between "timeline", "public", and "known network", or switch between "mentions" and "private messages", having some easy access to my "favorite" hashtags in some way would be very useful .
In Mastodon-FE perhaps a "topics" item could be inserted between "direct messages" and "public timeline"
attaching some array of user-specified hashtags to a user somehow seems like it would be fairly simple to program ; going from a given hashtag to a feed for that hashtag is already a solved problem. (given tag x, change to url //site/tag/x) ....https://git.pleroma.social/pleroma/pleroma/-/issues/852Move avatars and banners out of the uploads folder.2023-05-08T04:09:37ZnepfagMove avatars and banners out of the uploads folder.I really, really want to delete old attachments, but there's stuff in the uploads foldder that's still being used, namely avatars and banners. Can you please move them somewhere else?I really, really want to delete old attachments, but there's stuff in the uploads foldder that's still being used, namely avatars and banners. Can you please move them somewhere else?https://git.pleroma.social/pleroma/pleroma/-/issues/859"right to vanish" -- profile scrubbing tools2023-05-08T12:24:41Zxx"right to vanish" -- profile scrubbing toolsMore tools for the following would be useful:
- mass tweet deletion
- mass unliking
- mass unfavoriting
- mass unRTing
- mass unfollow
You might ask "why not just export your following, delete your account, open a new account, an...More tools for the following would be useful:
- mass tweet deletion
- mass unliking
- mass unfavoriting
- mass unRTing
- mass unfollow
You might ask "why not just export your following, delete your account, open a new account, and refollow your pals" -- well, that'd work, but we can see on Twitter that 3rd party apps that provide this information are very popular -- and they're also how a lot of user data is given to creepy 3rd parties
Perhaps in the future these could be expanded, eg
- delete posts older than a month
- delete posts made between 2016 and 2017
- unfollow all users on a given domain
- unlike all posts from a specific user
etchttps://git.pleroma.social/pleroma/pleroma/-/issues/872Rework S3 bucket storage hierarchy / strategy?2020-07-02T13:49:14ZfeldRework S3 bucket storage hierarchy / strategy?After discussing the Pleroma S3 usage at work, we have some criticisms for long term archival of these objects especially around backup/restore. We have experience with S3 buckets that have millions of objects and many operations are pai...After discussing the Pleroma S3 usage at work, we have some criticisms for long term archival of these objects especially around backup/restore. We have experience with S3 buckets that have millions of objects and many operations are painfully slow at that size.
Example of a good hierarchy:
```
"idx": "t/t/w/ttwi3eda/poster/4.jpg",
"idx": "t/t/z/ttz6qsiu/small.jpg",
"idx": "t/u/3/tu3zixdp/large.jpg",
"idx": "t/u/6/tu68dlz3/large.jpg",
"idx": "t/u/7/tu7j1i32/large.jpg",
"idx": "t/u/c/tucz706h/medium.jpg",
"idx": "t/u/j/tuj95zf9/thumb.jpg",
"idx": "t/u/m/tumujmfo/poster/5.jpg",
```
Also suggested condensing our filenames from sha hashes to something denser. "base58 instead of base16" is a recommendation as well.lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/3080[SUGGESTION] Improved Moderation Tools2023-04-03T22:10:51ZGhost User[SUGGESTION] Improved Moderation Tools**Improved permissions for Moderators**
- [x] Allow moderators access to the reports.
- [x] Allow moderators to deactivate accounts.
**Improved abuse handling**
- [ ] Implement a system to block email domains, similar to Mastodon, check...**Improved permissions for Moderators**
- [x] Allow moderators access to the reports.
- [x] Allow moderators to deactivate accounts.
**Improved abuse handling**
- [ ] Implement a system to block email domains, similar to Mastodon, check MX (useful for disposable blocking)
- [ ] Implement IP address blocking for account creation, optionally log IP addresses with a conf switch. Blocks should be configurable in the Admin-FE.
- [ ] Make chat messages reportable.https://git.pleroma.social/pleroma/pleroma/-/issues/969Mastodon API: Context pagination2023-05-08T03:55:24ZlainMastodon API: Context paginationSister issue: https://github.com/tootsuite/mastodon/issues/11029
Contexts should have some form of pagination. Anytime descendants or ancestors get over ~ 20, there should be link headers set to fetch the rest.
Some threads can get ...Sister issue: https://github.com/tootsuite/mastodon/issues/11029
Contexts should have some form of pagination. Anytime descendants or ancestors get over ~ 20, there should be link headers set to fetch the rest.
Some threads can get rather long and can even make the request time out if long enough. Even if they don't, waiting 5 seconds for a thread to load seems like a bad idea. As this would be a breaking change for contexts (suddenly clients will get less information returned) I'd suggest either doing that under the /v2 endpoints or adding a parameter ?paginated=true to enable this paginated mode.https://git.pleroma.social/pleroma/pleroma/-/issues/981Polls: Check if remote user can validly cast a given vote2023-05-08T04:05:06ZlainPolls: Check if remote user can validly cast a given voteDouble voting etc.
essentially, the checking logic in CommonApi.vote has to be moved somewhere else (ActivityPub.create? should probably become ActivityPub.create_answer or something specific) / reused / refactored so that it runs in bo...Double voting etc.
essentially, the checking logic in CommonApi.vote has to be moved somewhere else (ActivityPub.create? should probably become ActivityPub.create_answer or something specific) / reused / refactored so that it runs in both local and incoming context.
@rinpatch comments appreciatedhttps://git.pleroma.social/pleroma/pleroma/-/issues/997Add mechanisms for federating poll results (especially private polls)2023-05-08T04:08:09ZClaireAdd mechanisms for federating poll results (especially private polls)Unless I'm mistaken, there is currently no mechanism in Pleroma to send poll results over the federation.
This is an issue in particular for private polls, as only the authoring instance will be able to see the results.
Mastodon uses an...Unless I'm mistaken, there is currently no mechanism in Pleroma to send poll results over the federation.
This is an issue in particular for private polls, as only the authoring instance will be able to see the results.
Mastodon uses an `Update` activity to send updates to the `Question` activity to followers/voters when it gets new votes / when the poll expires. The use of such an `Update` activity alleviates the need for user-authenticated fetching of the `Question` object.lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/1012Figure out a way to merge some config parameters with defaults instead of ove...2019-06-23T07:10:48Zrinpatchrin+pleroma@patch.cxFigure out a way to merge some config parameters with defaults instead of overwritingSome parameters are really annoying to copy and keep track of, for example: frontend configs, restricted nicknames, poll limits (not really annoying but can break if defaults are overriden with only some parts of the map). We should figu...Some parameters are really annoying to copy and keep track of, for example: frontend configs, restricted nicknames, poll limits (not really annoying but can break if defaults are overriden with only some parts of the map). We should figure out a way to mark parameters as mergeable instead of overridable, but let the admins change it to override if they want tohttps://git.pleroma.social/pleroma/pleroma/-/issues/1018Figure out a way to test that releases actually run on the target platfrom2023-05-08T03:58:35Zrinpatchrin+pleroma@patch.cxFigure out a way to test that releases actually run on the target platfromCurrently I have to manually test this on 6 VMs after every elixir image rebuild/native dependency change. Would be nice if this could be automatedCurrently I have to manually test this on 6 VMs after every elixir image rebuild/native dependency change. Would be nice if this could be automatedhttps://git.pleroma.social/pleroma/pleroma/-/issues/1024Make it possible to anonymize reports2023-05-09T20:59:31Zrinpatchrin+pleroma@patch.cxMake it possible to anonymize reportsPeople argue that sending unanonymized reports can lead to harassment by hostile admins. Would be nice if we had an option to anonymize them by having a "System" account and sending reports using it as an actorPeople argue that sending unanonymized reports can lead to harassment by hostile admins. Would be nice if we had an option to anonymize them by having a "System" account and sending reports using it as an actorhttps://git.pleroma.social/pleroma/pleroma/-/issues/1137Add a pleroma_ctl task for generating web push keys2023-05-08T04:11:12Zrinpatchrin+pleroma@patch.cxAdd a pleroma_ctl task for generating web push keysSince OTP release users don't have `mix web_push.gen.keypair`, they now can only generate web push keys by re-running the config generator. We should add a separate task for thatSince OTP release users don't have `mix web_push.gen.keypair`, they now can only generate web push keys by re-running the config generator. We should add a separate task for thathttps://git.pleroma.social/pleroma/pleroma/-/issues/1147Official Docker support2023-05-08T02:05:15ZAshlynn AndersonOfficial Docker supportStarted talking with lain about making an official Docker image (and possibly docker-compose.yml) with OTP Releases being a thing now a little bit back.
I've started work on this in my fork, thinking of splitting it into a couple of sep...Started talking with lain about making an official Docker image (and possibly docker-compose.yml) with OTP Releases being a thing now a little bit back.
I've started work on this in my fork, thinking of splitting it into a couple of separate MRs, one each for the:
- [x] Dockerfile (!1523)
- [ ] Gitlab CI integration
- [ ] and docker-compose.yml (possibly a couple different ones of these for different configurations? docker-compose.traefik.yml, etc)
If anyone would prefer this to be batched differently let me know, but I'm currently starting with just the Dockerfile.https://git.pleroma.social/pleroma/pleroma/-/issues/1160Expose `limit_to_local_content` setting in nodeinfo (previously "User search ...2023-05-08T03:57:28ZnikExpose `limit_to_local_content` setting in nodeinfo (previously "User search does not work unless logged in")If this is intended behavior, the button should not be available unless logged in, rather than just showing no results found.If this is intended behavior, the button should not be available unless logged in, rather than just showing no results found.lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/1205Add ability to upload multiple avatars w/ different ratings?2023-05-08T04:14:40ZFrinkeldoodleAdd ability to upload multiple avatars w/ different ratings?This was an idea brought up by @kaniini in this post: https://pleroma.site/notice/9m4ISIBiGedWJFUVxQ
> imagine if people could upload more than one avatar, and set ratings on each one, like gravatar allows.
This would be a feature that...This was an idea brought up by @kaniini in this post: https://pleroma.site/notice/9m4ISIBiGedWJFUVxQ
> imagine if people could upload more than one avatar, and set ratings on each one, like gravatar allows.
This would be a feature that would allow you to upload multiple avatars, and assign each avatar a content rating. Then, instances and perhaps even individual users could set what avatar they see based on the content rating. This would allow a user to upload, say, a "safe for all audiences" avatar and a lewd avatar, while only showing the lewd avatar to those who specify "i want to see lewd avatars".
This is what the feature kinda looks like on Gravatar when you're uploading an avatar, and it honestly probably describes it better than my oddly-worded description:
![selectrating](/uploads/6dbca868f835897e5ff47730784d629a/selectrating.png)https://git.pleroma.social/pleroma/pleroma/-/issues/1228Media optimisation server-side2023-05-08T01:39:10ZMaxím V. SivokóňMedia optimisation server-sidedisclaimer: my first git* issue ever so pls be patient.
It’s a *feature request*.
Users don’t usually care about uploading optimised content, and not every admin is savvy enough to set it up themself. Optimising media would help saving...disclaimer: my first git* issue ever so pls be patient.
It’s a *feature request*.
Users don’t usually care about uploading optimised content, and not every admin is savvy enough to set it up themself. Optimising media would help saving both admins’ drive space (especially for instances with lots of users) and users’ traffic and downloading time (especially for users with lots of follows). If it is possible to implement something like optipng and mozjpeg without compromizing on RAM/CPU load (so Pleroma can keep the “Raspberry Pi” promise), then I belive all uploaded media should be optimised server-side.
I think it would be good idea to keep lossy compression by default, with probably the option for lossless (either set up by user or only an admin).
(alternative: lossy only, no configuration — it’s a social media software, not image gallery after all).
It seems Mastodon not only optimises all the media, but also scales images and video down to some maximum sizes and converts adio and video to lossy formats: [media_attachment.rb](https://github.com/tootsuite/mastodon/blob/cd660d374adc9394aaeea22d5d41b29535d8a4c2/app/models/media_attachment.rb)https://git.pleroma.social/pleroma/pleroma/-/issues/1235Web-based config generator2023-05-08T03:50:50ZfeldWeb-based config generatorPleroma would be infinitely more approachable if the config generator fired up a webserver on port 4000 and the user could navigate there and set things up (even provisioning an admin account???). I had a chat with @lambadalambda and thi...Pleroma would be infinitely more approachable if the config generator fired up a webserver on port 4000 and the user could navigate there and set things up (even provisioning an admin account???). I had a chat with @lambadalambda and this seems like a straightforward thing to do. Once we have the basic functionality sorted out we can throw some effort into CSS and clean design.minibikiniminibikinihttps://git.pleroma.social/pleroma/pleroma/-/issues/1242Follow a relay for a limited time2023-05-08T04:14:23ZfeldFollow a relay for a limited timeIf we add the ability to follow a relay and automatically unfollow after a period of time this gives us a better foundation to build an auto-bootstrapping option for new instances so they can populate their view of the network and remove...If we add the ability to follow a relay and automatically unfollow after a period of time this gives us a better foundation to build an auto-bootstrapping option for new instances so they can populate their view of the network and remove themselves from the relay after one day, one week, etc.https://git.pleroma.social/pleroma/pleroma/-/issues/1244Preload thread mutes/bookmarks in notification queries2023-05-08T04:07:49Zrinpatchrin+pleroma@patch.cxPreload thread mutes/bookmarks in notification queriesrinpatchrin+pleroma@patch.cxrinpatchrin+pleroma@patch.cxhttps://git.pleroma.social/pleroma/pleroma/-/issues/1253Resolve objects addressed in to/cc2023-05-08T04:14:12Zrinpatchrin+pleroma@patch.cxResolve objects addressed in to/ccThis is kinda what we should do per AP spec and it will eliminate broken mentions in a post if the instance doesn't know about user mentioned and allow us to properly filter out follower collections that don't belong to the actor instead...This is kinda what we should do per AP spec and it will eliminate broken mentions in a post if the instance doesn't know about user mentioned and allow us to properly filter out follower collections that don't belong to the actor instead of stripping everything that ends with '/followers'https://git.pleroma.social/pleroma/pleroma/-/issues/1279Signing release assets2023-05-08T04:03:37ZHaelwennSigning release assetsI think we should sign the release assets of pleroma, with at least a regular checksum(like SHA256) and probably minisign/signify for verifying the authority (let's avoid OpenPGP).I think we should sign the release assets of pleroma, with at least a regular checksum(like SHA256) and probably minisign/signify for verifying the authority (let's avoid OpenPGP).https://git.pleroma.social/pleroma/pleroma/-/issues/1295[TRACKER?] Friendica AP vocabulary support2023-05-08T04:06:02ZHaelwenn[TRACKER?] Friendica AP vocabulary supportFriendica has support for creating activities of currently unsupported AP vocabulary, we might not have to support all of them but I think we should at least note it in our ticket tracker.
This list is based on the code at <https://gith...Friendica has support for creating activities of currently unsupported AP vocabulary, we might not have to support all of them but I think we should at least note it in our ticket tracker.
This list is based on the code at <https://github.com/friendica/friendica/blob/develop/src/Protocol/ActivityPub/Transmitter.php>
- [ ] actor suggestion(`sendContactSuggestion`), `Announce`
- [ ] actor relocation(`sendProfileRelocation`), `dfrn:relocate`
- [x] actor deletion(`sendProfileDeletion`), `Delete`
- [x] actor update(`sendProfileUpdate`), `Update`
- [x] actor follow(`sendFollowObject`), `Follow`
- [x] actor accept follow (`sendContactAccept`), `Accept`
- [x] actor reject follow (`sendContactReject`), `Reject`
- [x] actor undo follow (`sendContactUndo`), `Undo`
- [x] activity like
- [ ] activity dislike → we could transform it to a emoji reaction
- [ ] activity add ?
This list is based on the code at <https://github.com/friendica/friendica/blob/develop/src/Protocol/ActivityPub/Processor.php>
- [ ] event creation (`createEvent`), `Event`
- [ ] direct messages (`postMail`), unknown typing, but should work
- [x] actor type=Grouphttps://git.pleroma.social/pleroma/pleroma/-/issues/1301Report emails need a nice template2023-05-08T04:06:46ZfeldReport emails need a nice templateWe have a pretty good template for the digest emails, let's start with that.We have a pretty good template for the digest emails, let's start with that.https://git.pleroma.social/pleroma/pleroma/-/issues/1331optionally use ElasticSearch for searches2023-05-08T02:55:23ZMew Mewoptionally use ElasticSearch for searchesElasticSearch is a much better indexer and algorithm than doing a query in SQL. It would be useful to have an option to use ElasticSearch as a backend for searching statuses.ElasticSearch is a much better indexer and algorithm than doing a query in SQL. It would be useful to have an option to use ElasticSearch as a backend for searching statuses.https://git.pleroma.social/pleroma/pleroma/-/issues/1333abstract SQL extension usage2023-05-08T04:14:01Zkaniiniabstract SQL extension usageIt would be nice to abstract the cases where we use Ecto fragments. If we can do so, it makes it easier to support other JSON-capable databases like recent MySQL and recent SQLite (with the `json1` extension).It would be nice to abstract the cases where we use Ecto fragments. If we can do so, it makes it easier to support other JSON-capable databases like recent MySQL and recent SQLite (with the `json1` extension).https://git.pleroma.social/pleroma/pleroma/-/issues/1381ATOM feeds from public timeline2023-05-08T04:13:47ZGhost UserATOM feeds from public timelineCurrently, it's possible to have ATOM feeds on a per-user basis.
There is no way, however, to have ATOM feeds on an instance-wide basis (public timeline.
foss.technology is meant to be similar to a newsfeed, and an ATOM feed (of just th...Currently, it's possible to have ATOM feeds on a per-user basis.
There is no way, however, to have ATOM feeds on an instance-wide basis (public timeline.
foss.technology is meant to be similar to a newsfeed, and an ATOM feed (of just the posts (vs boosts/replies), though being configurable (or having multiple) is ideal) would be very useful for that goal.
I'm sure it's possible to imagine similar use-cases in themed instances.https://git.pleroma.social/pleroma/pleroma/-/issues/1389Enforce access control in Object/Activity get functions2023-05-08T03:27:32Zrinpatchrin+pleroma@patch.cxEnforce access control in Object/Activity get functionsI propose refactoring `Object.get_by_ap_id` and the like to check for visibility (unless `skip_visibility_check: true` is passed) and only serve public objects unless `for_user` is passed. I think that by enforcing access control when ge...I propose refactoring `Object.get_by_ap_id` and the like to check for visibility (unless `skip_visibility_check: true` is passed) and only serve public objects unless `for_user` is passed. I think that by enforcing access control when getting the objects we can eliminate the possibility of having bugs like !1667 and !635
@lambadalambda @kaniini what do you think?HaelwennHaelwennhttps://git.pleroma.social/pleroma/pleroma/-/issues/1390Tracking issue for FE bundle removal2023-05-08T03:29:00ZkaniiniTracking issue for FE bundle removalOver the past few months, we have been talking about a way to remove the FE bundles from Pleroma, having them managed in the instance folder instead.
Here is roughly how it should work.
The installation script should prompt asking what...Over the past few months, we have been talking about a way to remove the FE bundles from Pleroma, having them managed in the instance folder instead.
Here is roughly how it should work.
The installation script should prompt asking what FEs should be installed:
- Primary frontend: Pleroma FE, Kenoma, None
- Whether MastoFE should be installed
- Whether AdminFE should be installed
The installation script should fetch either the release or nightly version of all of these and install them in the appropriate place under instance/
It should also prompt if StaticFE (!1917) should be enabled.
Also, ideally the settings would be remembered and a mix task would exist to update one or more frontends to latest release or nightly.2.3.0Roman ChvanikovRoman Chvanikovhttps://git.pleroma.social/pleroma/pleroma/-/issues/1393Splice new recipients into activities when re-delivering a pre-existing activity2023-05-08T04:13:36ZkaniiniSplice new recipients into activities when re-delivering a pre-existing activityThis is mostly needed for situations involving per-actor inboxes and multiboxes, where multiple copies of an activity addressed to different segments of the final audience are received. Right now we only splice the recipient in when pro...This is mostly needed for situations involving per-actor inboxes and multiboxes, where multiple copies of an activity addressed to different segments of the final audience are received. Right now we only splice the recipient in when processing the activity for the first time.https://git.pleroma.social/pleroma/pleroma/-/issues/1398Trending tags2023-05-08T03:11:56ZMew MewTrending tagsImplement trending hashtags. Currently the endpoint exists but returns nothing, trending hashtags would be a good feature for discoverability.Implement trending hashtags. Currently the endpoint exists but returns nothing, trending hashtags would be a good feature for discoverability.minibikiniminibikinihttps://git.pleroma.social/pleroma/pleroma/-/issues/1408Making benchmarks useful2023-05-08T04:01:09Zrinpatchrin+pleroma@patch.cxMaking benchmarks useful* [ ] Have a dedicated runner for them that is not too high-spec to not be able to notice a change
* [ ] Set up a [codespeed](https://github.com/tobami/codespeed) and report the benchmark results to it. See https://speed.pypy.org/ for ...* [ ] Have a dedicated runner for them that is not too high-spec to not be able to notice a change
* [ ] Set up a [codespeed](https://github.com/tobami/codespeed) and report the benchmark results to it. See https://speed.pypy.org/ for example of what this allows us to do
* [ ] Run them on a real database or at least cache the generated one. (no idea how to do that in gitlab ci, probably have an external db server and create protected variables for connecting to it?)
feld edit: marginally related to https://git.pleroma.social/pleroma/pleroma-meta/-/issues/20feldfeldhttps://git.pleroma.social/pleroma/pleroma/-/issues/1410Option to overwrite follows when importing?2023-05-08T03:57:06ZGhost UserOption to overwrite follows when importing?Mastodon allows you to optionally overwrite existing follows when importing, which really helps when cleaning out follows of old/dead accounts on one instance and worrying about unfollowing the same accounts on an alt instance.
Is it pos...Mastodon allows you to optionally overwrite existing follows when importing, which really helps when cleaning out follows of old/dead accounts on one instance and worrying about unfollowing the same accounts on an alt instance.
Is it possible to give Pleroma similar functionality? Could extend to blocks/mutes as wellhttps://git.pleroma.social/pleroma/pleroma/-/issues/1421Chat configurability2023-05-08T04:13:22ZMew MewChat configurabilityPeople use chat on my instance occasionally, and I'd like to be able to configure the number of messages stored, either by number (e.g. prune over 100) or by time (e.g. prune over two days).People use chat on my instance occasionally, and I'd like to be able to configure the number of messages stored, either by number (e.g. prune over 100) or by time (e.g. prune over two days).https://git.pleroma.social/pleroma/pleroma/-/issues/1423Purge Question object cache after new votes come in instead of setting a ttl2023-05-08T04:10:02Zrinpatchrin+pleroma@patch.cxPurge Question object cache after new votes come in instead of setting a ttlCurrently our AP object cache has an indefinite ttl on regular objects and 60 second ttl on Question objects. We should have indefinite ttl on Question objects as well and just update the cache after new votesCurrently our AP object cache has an indefinite ttl on regular objects and 60 second ttl on Question objects. We should have indefinite ttl on Question objects as well and just update the cache after new voteshttps://git.pleroma.social/pleroma/pleroma/-/issues/1428Option to show favorites in timelines2023-05-08T04:13:12ZMew MewOption to show favorites in timelinesIt would be useful to be able to view favorites of your followees in timelines, to get a similar view to that of a single-user instance federated timeline.
Example of how this would look in PleromaFE:
![image](/uploads/21860b9f2c41967...It would be useful to be able to view favorites of your followees in timelines, to get a similar view to that of a single-user instance federated timeline.
Example of how this would look in PleromaFE:
![image](/uploads/21860b9f2c419674d3899a1e2b25d525/image.png)https://git.pleroma.social/pleroma/pleroma/-/issues/1436Disclose followed relays in nodeinfo2023-05-08T04:13:02ZMew MewDisclose followed relays in nodeinfoRelays an instance follows should be disclosed in nodeinfo, as it's part of an instance's federation policy.Relays an instance follows should be disclosed in nodeinfo, as it's part of an instance's federation policy.https://git.pleroma.social/pleroma/pleroma/-/issues/1446Make non-OTP mix tasks use RPC as well2023-05-08T03:56:47Zrinpatchrin+pleroma@patch.cxMake non-OTP mix tasks use RPC as wellCurrently it will spin up a new Pleroma node, which was pretty bad, but ok when we used an in-memory queue. Now we use Oban, which means the node spun up by the mix task will actually process jobs, which could lead to race conditions sin...Currently it will spin up a new Pleroma node, which was pretty bad, but ok when we used an in-memory queue. Now we use Oban, which means the node spun up by the mix task will actually process jobs, which could lead to race conditions since our code is not yet adapted to multi-node setups.https://git.pleroma.social/pleroma/pleroma/-/issues/1517Notifications API: Have separate type for subscriptions2023-05-08T03:16:23Zrinpatchrin+pleroma@patch.cxNotifications API: Have separate type for subscriptionsCurrently subscription notifications are just `mention`s which prevents clients from having a separate feed for them (see pleroma-fe#746). We should give them a separate type, but rewrite it to `mention`s unless `with_subscriptions` is p...Currently subscription notifications are just `mention`s which prevents clients from having a separate feed for them (see pleroma-fe#746). We should give them a separate type, but rewrite it to `mention`s unless `with_subscriptions` is passed because I suspect clients will crash and burn if they encounter an unknown notifications type.lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/1556Make relay actors followable by users2023-07-01T21:43:34ZMew MewMake relay actors followable by usersPleroma instances, by default, have a relay at https://instance.tld/relay. However, this actor cannot be followed by users. Many users have expressed interest in following other instances entirely, and this provides an easy way to do t...Pleroma instances, by default, have a relay at https://instance.tld/relay. However, this actor cannot be followed by users. Many users have expressed interest in following other instances entirely, and this provides an easy way to do that.https://git.pleroma.social/pleroma/pleroma/-/issues/1571Improve full text search results by unaccent and concatenating fields2023-05-08T04:11:35ZfeldImprove full text search results by unaccent and concatenating fieldsUnsure if this will work, but notes from the FOSDEM talk leads me to believe we can do better, although not exactly what we want due to inability to sort some results based on an additional field. (@lambadalambda wrote a blog post about ...Unsure if this will work, but notes from the FOSDEM talk leads me to believe we can do better, although not exactly what we want due to inability to sort some results based on an additional field. (@lambadalambda wrote a blog post about this here: https://blog.soykaf.com/post/postgresl-front-report/)
1. Postgres has an unaccent module. This should help normalize our queries and results a bit.
2. Concatenating fields:
if a full text search query was built off of concatenating our fields such as `name`, `nickname`, and `post_body` (not verbatim field names) we could then have:
account `@feld@bikeshed.party` makes post "cheese is good"
and then if we search for "feld cheese" it should produce a match and give us this exact post as the first result because we hit on both the account and the post body.Sergey SuprunenkoSergey Suprunenkohttps://git.pleroma.social/pleroma/pleroma/-/issues/1580[Tracker] Better logging messages/reports2023-05-08T03:55:03ZHaelwenn[Tracker] Better logging messages/reportsCurrently we quite lack good messages into our logging. Went grep-fu on my logs a bit and this is what I found so far. Feel free to add some either directly or into comments.
- [ ] `[error] Couldn't fetch "https://kawen.space/objects/b...Currently we quite lack good messages into our logging. Went grep-fu on my logs a bit and this is what I found so far. Feel free to add some either directly or into comments.
- [ ] `[error] Couldn't fetch "https://kawen.space/objects/b8af0b75-6a22-44de-af0e-b97efe77943f", error: nil` → Probably got a 404 error
- [ ] `Follower/Following counter update for #{user.ap_id} failed.\n#{inspect(e)}` & `"Follower/Following counter update for #{data.ap_id} failed.\n" <> inspect(e)` → Maybe it should be on one line for better `grep`ability?
## HTTP Signatures
- [ ] `Could not validate against known public keys: {:error, :error}`
## MRF Rejects
Currently one reject when receiving on `/inbox` will tend to spew the following extraneous lines after some like a okay-ish `[error] Could not decode user at fetch <redacted actor ap_id>, {:error, {:reject, nil}}`:
- [ ] `[error] Internal server error: %MatchError{term: {:error, {:error, {:reject, nil}}}}`
- [ ] `[error] #PID<0.24881.27> running Pleroma.Web.Endpoint (connection #PID<0.23781.27>, stream id 1) terminated
Server: localhost:4000 (http)
Request: POST /inbox
** (exit) an exception was raised:
** (FunctionClauseError) no function clause matching in Plug.Conn.resp/3
(plug) lib/plug/conn.ex:577: Plug.Conn.resp(…)`https://git.pleroma.social/pleroma/pleroma/-/issues/1582Full text search should include subjects2023-05-08T01:13:57ZxenofemFull text search should include subjectsRight now it looks like only the body of a status is used for full text search, ideally the subject of the status should also be included.Right now it looks like only the body of a status is used for full text search, ideally the subject of the status should also be included.Sergey SuprunenkoSergey Suprunenkohttps://git.pleroma.social/pleroma/pleroma/-/issues/1609Implement an option to enable static-fe only when javascript is disabled and ...2023-05-08T03:28:32Zrinpatchrin+pleroma@patch.cxImplement an option to enable static-fe only when javascript is disabled and set it by defaultThis can be accomplished by making static-fe appear only when a param is set to true and then redirect to a page with this param by using `http-equiv` in a `meta` tag inside `noscript`This can be accomplished by making static-fe appear only when a param is set to true and then redirect to a page with this param by using `http-equiv` in a `meta` tag inside `noscript`2.3.0rinpatchrin+pleroma@patch.cxrinpatchrin+pleroma@patch.cxhttps://git.pleroma.social/pleroma/pleroma/-/issues/1622Instance muting should behave more like normal muting2023-05-08T03:28:47ZPipirupirupirupipirupiInstance muting should behave more like normal mutingCurrent behavior:
Instance muting completely removes notifications from users of that instance regardless of [Hide posts of muted users (default: no)] setting
What happens:
> * mastodon.social is muted by user @mono@shitposter.club
> *...Current behavior:
Instance muting completely removes notifications from users of that instance regardless of [Hide posts of muted users (default: no)] setting
What happens:
> * mastodon.social is muted by user @mono@shitposter.club
> * @gargon@mastodon.social makes a post addressing @mono@shitposter.club
> * @mono does not receive the notification of a reply even though [Hide posts of muted users (default: no)] in settings is off
What should happen:
If [Hide posts of muted users (default: no)] is yes
> * @gargon@mastodon.social makes a post addressing @mono@shitposter.club
> * @mono does not receive a notification
If [Hide posts of muted users (default: no)] is no
> * @gargon@mastodon.social makes a post addressing @mono@shitposter.club
> * @mono receives a collapsed muted notification
Also, people that a user follows should be exempt from instance muting. if one didn't want to see posts from a user from a muted instance, they wouldn't have followed that user in the first place.2.3.0minibikiniminibikinihttps://git.pleroma.social/pleroma/pleroma/-/issues/1645add ldap search filter support2023-05-08T04:12:30Zmeskioadd ldap search filter supportIn some ldap setups it's not enough to know the base and uid attribute and is needed also to be able to apply search filters. You might have users that you don't want to have access to the pleroma instance, or in our case we disable user...In some ldap setups it's not enough to know the base and uid attribute and is needed also to be able to apply search filters. You might have users that you don't want to have access to the pleroma instance, or in our case we disable users with an ldap attribute.
Can we get an extra configuration param `filter` in the ldap authentication?https://git.pleroma.social/pleroma/pleroma/-/issues/1657Improvement: allow filtering of timelines on used language of the post2023-05-08T00:44:48ZGhost UserImprovement: allow filtering of timelines on used language of the postMastodon allows a user to filter on languages (only show these languages switches). This is useful to reduce the number of posts in the timeline that you can't understand because of their language.
It seems that a lot of posts have a ta...Mastodon allows a user to filter on languages (only show these languages switches). This is useful to reduce the number of posts in the timeline that you can't understand because of their language.
It seems that a lot of posts have a tag for this because the filter works when I tested mastodon.
Seems to be linked to issue #697 though...https://git.pleroma.social/pleroma/pleroma/-/issues/1708Show users' IP address in logs or AdminFE2023-05-08T02:07:52Zopal hartgit.pleroma.social@wowana.meShow users' IP address in logs or AdminFEBefore Pleroma switched entirely to OAuth, usernames were tied to HTTP requests in access logs due to use of the HTTP Authenticate header. Therefore, an administrator could associate users with IP addresses and other information useful i...Before Pleroma switched entirely to OAuth, usernames were tied to HTTP requests in access logs due to use of the HTTP Authenticate header. Therefore, an administrator could associate users with IP addresses and other information useful in the combat of spam and maintenance of a server.
I understand the original behaviour was an unintended effect of the authentication method used, but @lambadalambda ended up passing the new behaviour off as a "feature" for GDPR compliance and then the concern went entirely dormant throughout 1.x phase of development. The rationale being, that "if I don't need to log this information, nobody else does," if I remember correctly. That rationale is clumsy and insensitive to the needs of other administrators who do *not* claim to treat browser or TCP/IP stack information as private or confidential, and who use this extra information to detect patterns e.g. with spambots or sockpuppeteers who undoubtedly have patterns in their registration behaviour.
Preferably I would like back the ability to view usernames in access logs, because that's just a matter of perhaps exposing a header to the reverse proxy (at administrator's request). Alternatively I would like to be able to view this information in AdminFE.https://git.pleroma.social/pleroma/pleroma/-/issues/1709Ability to change username2023-05-08T01:23:37ZMew MewAbility to change usernameSince there is now a way within ActivityPub (that both Mastodon and Pleroma support) to migrate between accounts, allowing username changes should be decently easy (although old posts would still be associated with the old username, foll...Since there is now a way within ActivityPub (that both Mastodon and Pleroma support) to migrate between accounts, allowing username changes should be decently easy (although old posts would still be associated with the old username, followers would migrate relatively painlessly).https://git.pleroma.social/pleroma/pleroma/-/issues/1756Alpine packaging2023-05-08T04:06:24ZHaelwennAlpine packagingHaelwennHaelwennhttps://git.pleroma.social/pleroma/pleroma/-/issues/1767Feature Request: Ability to hide all NSFW/sensitive posts and certain instanc...2023-05-08T04:03:06ZYour New SJW WaifuFeature Request: Ability to hide all NSFW/sensitive posts and certain instances for users who are not logged inBasically I'd like to not display any posts that are tagged as NSFW/sensitive to people who are not logged in but have them visible by default for accounts that are logged in. It would be nice to have a toggle in account/FE settings as w...Basically I'd like to not display any posts that are tagged as NSFW/sensitive to people who are not logged in but have them visible by default for accounts that are logged in. It would be nice to have a toggle in account/FE settings as well.
Just to be clear, I'm not talking about `nsfw_clickthrough`, I'm talking about not displaying the post entirely.
This would be especially helpful with laws about not giving minors easy access to pornography as it could be argued a clickthrough image isn't enough of a hindrance but requiring an account and requiring users to be 18+ to make an account would be enough of a hindrance.
Also, it'd have the added benefit of making your website look more presentable decreasing the amount of disappointment your parents have in you. I mean, they'll still be disappointed but less so because at least now your website isn't just covered in port.
As for the instances it'd be nice to be able to hide certain instances so it's not just full of a bunch of gab posts or whatnot but not actually hide it from authenticated users so if that's something they want to see it's not being hidden from them.
This is mostly about just making instances look more "presentable" to people who stumble upon them without actually hiding/censoring anything from actual users.https://git.pleroma.social/pleroma/pleroma/-/issues/1768Remove FE settings from description.exs2023-05-08T03:21:02ZfeldRemove FE settings from description.exsWe should let each FE control the available settings with a standardized configuration schema that the backend parses and exposes to AdminFE.
This will allow every FE to be configurable in AdminFE / the database without requiring any ch...We should let each FE control the available settings with a standardized configuration schema that the backend parses and exposes to AdminFE.
This will allow every FE to be configurable in AdminFE / the database without requiring any changes in the backend.Alexander StrizhakovAlexander Strizhakovhttps://git.pleroma.social/pleroma/pleroma/-/issues/1769Feature Request: Return presigned URLs for S3 storage2023-05-08T04:03:17ZYour New SJW WaifuFeature Request: Return presigned URLs for S3 storageReturning a 302 with a [presigned url](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html) instead of an anonymous request would enable us to include headers to set in the get request such as `Content-Dispositio...Returning a 302 with a [presigned url](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html) instead of an anonymous request would enable us to include headers to set in the get request such as `Content-Disposition` when `config :pleroma, Pleroma.Upload, link_name:` is set to `true` as well as set `Cache-Control` headers saving bandwidth. For whatever reason [Amazon decided that you have to provide authentication](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html) to set those headers.
One of the downsides is that presigned urls can only be valid for up to 7 days but that's not really too big of an issue since we're returning 302s anyway. Requests shouldn't be too resource intensive to sign. It is just HMAC-SHA256 after all. However, it'd be best to cache them. Especially for initial post federation when it'd be getting hundreds of requests at once which would greatly increase the CPU needed to sign the requests if no caching is used.
Initially, I was thinking of the best way to do the caching in Pleroma but I see no reason we couldn't just sign them for 7 days and then and then just use Nginx (or whatever reverse proxy is being used) to just cache the responses.hrefhref@random.shhrefhref@random.shhttps://git.pleroma.social/pleroma/pleroma/-/issues/1826feature -- Ability to set prefered frontend2023-05-08T03:59:16Zxxfeature -- Ability to set prefered frontendLet's say I am a dork and really love MastoFE. I should be able to set that as my "default" view
Inverted: my dorky admin enabled StaticFE and I hate StaticFE. I should be able to turn it off.Let's say I am a dork and really love MastoFE. I should be able to set that as my "default" view
Inverted: my dorky admin enabled StaticFE and I hate StaticFE. I should be able to turn it off.https://git.pleroma.social/pleroma/pleroma/-/issues/1828Support media meta when available2023-05-08T02:06:08ZAlex GleasonSupport media meta when availableRelated: !2607
Mastodon has two extra fields on media attachments:
- `meta`
- `blurhash`
On the frontend side, the lack of `meta` info makes it challenging to display images and videos in an accessible way. It's mainly due to lack of...Related: !2607
Mastodon has two extra fields on media attachments:
- `meta`
- `blurhash`
On the frontend side, the lack of `meta` info makes it challenging to display images and videos in an accessible way. It's mainly due to lack of image dimensions and aspect ratio. Pleroma doesn't support the focal point feature either.
Here's an example of a video shown in legacy Mastodon+Soapbox:
![Screen_Shot_2020-05-28_at_16.20.42](/uploads/70893be3ab12f0be8f2b9c4d75957865/Screen_Shot_2020-05-28_at_16.20.42.png)
The same video in Pleroma FE:
![Screen_Shot_2020-05-28_at_16.22.13](/uploads/7329f1bd99781c730b92d8ac79bb6c08/Screen_Shot_2020-05-28_at_16.22.13.png)
Here are some examples with multiple images. First, 3 images shown in legacy Mastodon+Soapbox:
![Screen_Shot_2020-05-28_at_16.47.10](/uploads/cbeff96cd32a91baa5e8c8119cb07c58/Screen_Shot_2020-05-28_at_16.47.10.png)
The same 3 images in new soapbox-fe, where aspect ratios aren't available:
![Screen_Shot_2020-05-28_at_16.47.24](/uploads/daf75f35e3a615f2de5126d967696e74/Screen_Shot_2020-05-28_at_16.47.24.png)
I believe the `meta` param adds significant value to the display of images in the frontend. It's true there are some ways we can work around it in the frontend, but after some experimentation I think we really want to know the image dimensions **before** we load them (that is, at the same time the **status** is loaded), or we have to face all sorts of issues with the timeline jumping around while re-rendering things after the image loads.
I understand why Pleroma doesn't have these attachment fields. I think it's extremely worth the trade-off to not store/process thousands of remote images. However I think there are some things we can maybe do to provide these fields anyway:
- Mastodon sends `meta` and `blurhash` data over ActivityPub, and Pleroma doesn't strip it. I think it's reasonable to provide this data in API endpoints if its available.
- Pleroma processes local images, giving the opportunity to attach this data (and federate it over ActivityPub, too).
- Pleroma can support adding focal points in PUT `/api/v1/media`
- When the media proxy is enabled, it might be possible do some processing on remote images to store `meta` info if it's not already available. Just an idea.
cc @hjlainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/1829Don't use s3/CDN url for media attachments2023-05-08T03:53:27ZMew MewDon't use s3/CDN url for media attachmentsWhen you use s3, media links in new posts are made directly. For example, the media URL of this post: https://pl.busshi.moe/notice/9vWIy7854XDg7edBYm is https://blobcdn.busshi.moe/plbusshimoe/4ba00ed726a11321f3936ff780a19c32b1930f4ae77d8...When you use s3, media links in new posts are made directly. For example, the media URL of this post: https://pl.busshi.moe/notice/9vWIy7854XDg7edBYm is https://blobcdn.busshi.moe/plbusshimoe/4ba00ed726a11321f3936ff780a19c32b1930f4ae77d83ce0e4f2421cf793086.png
This means that if I wanted to migrate away from s3, or change my bucket URL, media URLs for all old posts would be broken.
Therefore, the media URL that should be used should always be https://pl.busshi.moe/media/4ba00ed726a11321f3936ff780a19c32b1930f4ae77d83ce0e4f2421cf793086.png (example), since that always redirects to where the media is currently hosted.Alexander StrizhakovAlexander Strizhakovhttps://git.pleroma.social/pleroma/pleroma/-/issues/1842Enhancement: Add end-to-end encryption API2023-05-08T04:02:21ZMelEnhancement: Add end-to-end encryption APII just stumbled upon the pull request on the Mastodon repo over E2EE implementation, I immediately got pretty interested, this seems like it could fix alot of the DM leaking issues
. https://github.com/tootsuite/mastodon/pull/13820
Thoug...I just stumbled upon the pull request on the Mastodon repo over E2EE implementation, I immediately got pretty interested, this seems like it could fix alot of the DM leaking issues
. https://github.com/tootsuite/mastodon/pull/13820
Though seeing how it uses specific libraries, not sure to what degree it's possible to use this on Elixer
Eitherway, personally I find this to be a really cool feature to accompany the DM systemhttps://git.pleroma.social/pleroma/pleroma/-/issues/1846Make attachment cleanup part of the delete transaction2023-05-08T04:01:27ZfeldMake attachment cleanup part of the delete transactionIt would be beneficial if the attempt to delete the attachment files (when cleanup enabled) is atomic / part of the delete transaction.It would be beneficial if the attempt to delete the attachment files (when cleanup enabled) is atomic / part of the delete transaction.rinpatchrin+pleroma@patch.cxrinpatchrin+pleroma@patch.cxhttps://git.pleroma.social/pleroma/pleroma/-/issues/1862Number of favorites/boosts on post changes if from blocked user2023-05-08T04:00:27ZkarolatNumber of favorites/boosts on post changes if from blocked userFavorites from blocked users will update the favorite count of a post but, if you click on the time of the post to see who favorited, the number will update to the number of favorites from users that aren't blocked. Is it possible to ne...Favorites from blocked users will update the favorite count of a post but, if you click on the time of the post to see who favorited, the number will update to the number of favorites from users that aren't blocked. Is it possible to never include blocked users in the count?https://git.pleroma.social/pleroma/pleroma/-/issues/1897Function request: Allow users backup their data and move it to another instance2023-05-08T03:09:09ZSnowFunction request: Allow users backup their data and move it to another instanceThis is the reason that many people choose Mastodon but not Pleroma...It allows people easy to moving around and avoid the problem of the owner stopped running the instance and no other place to go.
I moved to Pleroma from Mastodon now,...This is the reason that many people choose Mastodon but not Pleroma...It allows people easy to moving around and avoid the problem of the owner stopped running the instance and no other place to go.
I moved to Pleroma from Mastodon now, I still want this...https://git.pleroma.social/pleroma/pleroma/-/issues/1899Make status previewing ignore the rate limiting2023-05-08T03:54:25ZlainMake status previewing ignore the rate limitingSee https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1159. Status previews should not count towards actual posting.See https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1159. Status previews should not count towards actual posting.https://git.pleroma.social/pleroma/pleroma/-/issues/1902Add API extension and setting for providing filename to post attachments2023-05-08T03:51:49ZfeldAdd API extension and setting for providing filename to post attachmentsTo restore some lost functionality, I propose an API extension to solve the issue of filenames being lost and not displayed, nor user configurable. Some people use filenames when sharing media as part of the joke/punchline and cannot do ...To restore some lost functionality, I propose an API extension to solve the issue of filenames being lost and not displayed, nor user configurable. Some people use filenames when sharing media as part of the joke/punchline and cannot do this anymore.
1. Add a new field to post attachments similar to the `description` field. Apps/FEs will be able to populate it as they wish.
```
"media_attachments": [
{
"description": "pumpedupkicks.mp4",
"id": "879900874",
"pleroma": {
"mime_type": "video/mp4",
"filename": "new filename metadata goes here.png" ⬅️⬅️⬅️⬅️
},
"preview_url": "https://lain.com/media/cb75de0200dd5c7d2dff673cacb632649694daf83aff269363e135121fc4d26e.mp4",
"remote_url": "https://lain.com/media/cb75de0200dd5c7d2dff673cacb632649694daf83aff269363e135121fc4d26e.mp4",
"text_url": "https://lain.com/media/cb75de0200dd5c7d2dff673cacb632649694daf83aff269363e135121fc4d26e.mp4",
"type": "video",
"url": "https://lain.com/media/cb75de0200dd5c7d2dff673cacb632649694daf83aff269363e135121fc4d26e.mp4"
}
```
2. Federate and ingest this data on posts
3. Add new user account setting to enable this functionality which will allow an app or FE to display the custom field when authoring posts with attachments and render the attachment filename links (if metadata available) in the timeline.
cc @hj for additional comments or requirements.Sergey SuprunenkoSergey Suprunenkohttps://git.pleroma.social/pleroma/pleroma/-/issues/1906Extend reply filtering to streaming api2023-05-07T21:59:49ZlainExtend reply filtering to streaming apiRight now, the streaming API will return all the posts that address you in any way, and thus using the 'reply_visiblity' option used in the timeline api won't work. We need to have some way for the client to distinguish these posts easil...Right now, the streaming API will return all the posts that address you in any way, and thus using the 'reply_visiblity' option used in the timeline api won't work. We need to have some way for the client to distinguish these posts easily, to keep the filtering even when using the streaming api.https://git.pleroma.social/pleroma/pleroma/-/issues/1921Auth with cookies2023-05-08T03:53:59ZAlex GleasonAuth with cookiesThey say the best game mechanics solve more than one problem. If we save the user_id in a session cookie, the following could be possible:
- The OAuth form remembers you #1909
- Users can stay logged in when switching frontends pleroma...They say the best game mechanics solve more than one problem. If we save the user_id in a session cookie, the following could be possible:
- The OAuth form remembers you #1909
- Users can stay logged in when switching frontends pleroma/pleroma-fe#871
- The backend could know which frontend to serve the user !2400
I think it makes sense to send this cookie back with a successful response to `POST /oauth/token`. It would open new possibilities for solving things on the frontend.https://git.pleroma.social/pleroma/pleroma/-/issues/1946"Read" event in streaming api2023-05-08T03:53:07ZHJ"Read" event in streaming apiWhen hitting "read" in PleromaFE it should generate relevant message in streaming API so that other sessions can update their read statusWhen hitting "read" in PleromaFE it should generate relevant message in streaming API so that other sessions can update their read statushttps://git.pleroma.social/pleroma/pleroma/-/issues/1951Extend API: adding filtering of statuses by time interval2023-05-08T03:47:24ZbirdExtend API: adding filtering of statuses by time intervalI think it would be useful to be able to receive statuses for a certain time interval, by adding support of, for example, parameters `min_ts` and `max_ts` to API.I think it would be useful to be able to receive statuses for a certain time interval, by adding support of, for example, parameters `min_ts` and `max_ts` to API.https://git.pleroma.social/pleroma/pleroma/-/issues/1955ChatMessages moderation2023-05-08T03:44:34ZAlex GleasonChatMessages moderationI think ChatMessages should have some moderation features, like the ability for users to report particular ChatMessages. An admin should have the ability to view Chats in AdminFE, as well as delete messages.I think ChatMessages should have some moderation features, like the ability for users to report particular ChatMessages. An admin should have the ability to view Chats in AdminFE, as well as delete messages.https://git.pleroma.social/pleroma/pleroma/-/issues/1963Remove Safe DM Mentions capability2023-05-08T03:50:16ZfeldRemove Safe DM Mentions capabilityNow that we have chats there's little use for this feature that doesn't always work reliably anyway. You can have 1:1 conversations now and not worry about accidentally tagging someone else and delivering a copy of the message to them.Now that we have chats there's little use for this feature that doesn't always work reliably anyway. You can have 1:1 conversations now and not worry about accidentally tagging someone else and delivering a copy of the message to them.https://git.pleroma.social/pleroma/pleroma/-/issues/1983Migrations test suite2023-05-08T03:38:28ZAlex GleasonMigrations test suiteJust a shower thought, but after adding some migration tests in !2792 I had some ideas about how we could create a test suite around migrations.
## Why?
First, **why?** I think in theory, a migration is supposed to be very straightforw...Just a shower thought, but after adding some migration tests in !2792 I had some ideas about how we could create a test suite around migrations.
## Why?
First, **why?** I think in theory, a migration is supposed to be very straightforward - it either succeeds or fails. However in Pleroma we're doing a lot of complex migrations, so sometimes a passing migration even with passing unit tests still results in a failure. If there's any way we can verify migrations with additional tests, that would be a big help.
I noticed this is a recurring issue in Pleroma. Since I've joined the mailing list, at least one other comes to mind: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1877#note_55889 And now I've made the mistake too.
## Example test
A ConfigDB migration is the perfect candidate for a migration test, since it doesn't require any schema changes and will continue to work in the future. Below is a migration I added to !2792 to fix a malformed config, and a test to accompany it.
##### priv/repo/migrations/20200722185515_fix_malformed_formatter_config.exs:
```elixir
# This migration will fix the config of Pleroma.Formatter when it's stored
# incorrectly. A previous migration incorrectly stored the config as a map,
# and this will convert it into a list (the correct format).
defmodule Pleroma.Repo.Migrations.FixMalformedFormatterConfig do
use Ecto.Migration
alias Pleroma.ConfigDB
@config_path %{group: :pleroma, key: Pleroma.Formatter}
def change do
# The with-statement only matches a map, so it will be skipped if the
# config is already a list
with %ConfigDB{value: %{} = opts} <- ConfigDB.get_by_params(@config_path),
fixed_opts <- Map.to_list(opts) do # Convert the config to a list
fix_config(fixed_opts)
else
# We return an atom so the test can check what happened
_ -> :skipped
end
end
defp fix_config(fixed_opts) when is_list(fixed_opts) do
{:ok, _} =
# Update ConfigDB with the fixed data
ConfigDB.update_or_create(%{
group: :pleroma,
key: Pleroma.Formatter,
value: fixed_opts
})
# Again, we return :ok so the test can check the result
:ok
end
end
```
Now for the test:
##### test/migrations/20200722185515_fix_malformed_formatter_config_test.exs:
```elixir
defmodule Pleroma.Repo.Migrations.FixMalformedFormatterConfigTest do
use Pleroma.DataCase
import Pleroma.Factory
import Pleroma.Tests.Helpers
alias Pleroma.ConfigDB
setup do: clear_config(Pleroma.Formatter)
# Import the migration module.
# It gets passed to each test as `%{migration: migration}`
setup_all do: require_migration("20200722185515_fix_malformed_formatter_config")
test "change/0 skips if Pleroma.Formatter is empty", %{migration: migration} do
# Here the migration gets run by calling change/0
# Since the database is in its default state, it won't have any malformed config,
# so we expect the migration logic to be skipped.
assert :skipped == migration.change()
end
test "change/0 skips if Pleroma.Formatter config is already a list", %{migration: migration} do
opts = [
class: false,
extra: true,
new_window: false,
rel: "ugc",
strip_prefix: false
]
# Here we test a correctly-formatted ConfigDB value.
# We insert it into ConfigDB.
insert(:config, group: :pleroma, key: Pleroma.Formatter, value: opts)
# Again, the migration gets run by calling change/0
# We expect it to return :skipped since the config isn't malformed
assert :skipped == migration.change()
# Sanity check that the data is in the database
%{value: new_opts} = ConfigDB.get_by_params(%{group: :pleroma, key: Pleroma.Formatter})
assert new_opts == opts
end
test "change/0 converts a map into a list", %{migration: migration} do
incorrect_opts = %{
class: false,
extra: true,
new_window: false,
rel: "F",
strip_prefix: false
}
# Finally, we insert a malformed config. This is what the migration should fix.
insert(:config, group: :pleroma, key: Pleroma.Formatter, value: incorrect_opts)
# Again, we run the migration.
# It should return :ok since the config was malformed, and it fixed it.
assert :ok == migration.change()
# Sanity check the updated config
%{value: new_opts} = ConfigDB.get_by_params(%{group: :pleroma, key: Pleroma.Formatter})
# Sanity check the updated config
assert new_opts == [
class: false,
extra: true,
new_window: false,
rel: "F",
strip_prefix: false
]
# Put the new config into Pleroma's environment for the next test.
# I couldn't figure out how to do this all in one step.
Pleroma.Config.put(Pleroma.Formatter, new_opts)
assert new_opts == Pleroma.Config.get(Pleroma.Formatter)
# Now we do an actual test on something that uses the config.
# This is just another sanity check to make sure our transformed config
# is in fact valid for its purpose now.
{text, _mentions, []} =
Pleroma.Formatter.linkify(
"https://www.businessinsider.com/walmart-will-close-stores-on-thanksgiving-ending-black-friday-tradition-2020-7\n\nOmg will COVID finally end Black Friday???"
)
assert text ==
"<a href=\"https://www.businessinsider.com/walmart-will-close-stores-on-thanksgiving-ending-black-friday-tradition-2020-7\" rel=\"F\">https://www.businessinsider.com/walmart-will-close-stores-on-thanksgiving-ending-black-friday-tradition-2020-7</a>\n\nOmg will COVID finally end Black Friday???"
end
end
```
## Building on this
Since a lot of people depend on Pleroma, and migrations are one of the few areas without regimented testing, I'd like to try improving the situation.
In general, I think tests like the one above should always be doable for migrations that don't require schema changes. I see no reason not to include tests for them.
For migrations which *do* make schema changes, I think we'd need a test runner that walks through the migrations one at a time, and runs a test if it exists. This seems pretty doable with a custom mix task. It could do something like this:
- `mix pleroma.testmigrations`
- It creates a fresh `pleroma_migrations_test` db
- It iterates through each migration, one at a time
- If a test called `priv/repo/test/"#{current_migration}_test.exs` exists, it runs it *before* the migration
- If the test passed, it keeps iterating. It recreates the database as needed.
- Could be a final pipeline in GitLab CI
To be clear, I don't think *all* migrations need tests. If it's *just* a schema migration, it doesn't need a test. Migrations only need tests if they have a bunch of logic that's difficult to verify, and if they have potential side-effects that can't be tested by unit tests alone.
The benefit of walking through each migration is that we could seed the test data at that stage of the database, then verify the result of the migration. We'd have to use raw SQL since we can't rely on Pleroma's API staying the same.
Just wanted to write these ideas down somewhere while they were still fresh in my mind.https://git.pleroma.social/pleroma/pleroma/-/issues/1984Send admin email notifications when the logger hits an error2023-05-08T03:50:39ZAlex GleasonSend admin email notifications when the logger hits an errorWhen I used to develop in Django, there was a convenient `AdminEmailHandler` module for the logger, that would notify the site admins via email whenever the server hit a 500 error. This was really helpful for tracking errors.
In Django ...When I used to develop in Django, there was a convenient `AdminEmailHandler` module for the logger, that would notify the site admins via email whenever the server hit a 500 error. This was really helpful for tracking errors.
In Django it looked something like this:
```py
ADMIN_EMAILS = ["alex@alexgleason.me"]
LOGGING = {
'handlers': {
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler'
}
}
}
```
Someone has already figured out how to do pretty much the same thing in Elixir: http://reganmian.net/blog/2015/08/26/email-notifications-about-errors-in-elixir/
I think it would be useful for Pleroma to add this, and include a simple boolean setting for admins to toggle it. I think it would help demystify some issues.https://git.pleroma.social/pleroma/pleroma/-/issues/1989Whitelist frontend config values in description.exs2023-05-08T03:50:29ZAlex GleasonWhitelist frontend config values in description.exsLately I've been thinking about the AdminAPI, and the wild goose chase of adding BE config values into `/api/v1/instance` (eg #1954)
I've been brainstorming better ways, and one idea is to whitelist values in description.exs. Eg:
![Scr...Lately I've been thinking about the AdminAPI, and the wild goose chase of adding BE config values into `/api/v1/instance` (eg #1954)
I've been brainstorming better ways, and one idea is to whitelist values in description.exs. Eg:
![Screenshot_from_2020-07-25_13-11-04](/uploads/d3187f1857de11486c09844420ddeeaf/Screenshot_from_2020-07-25_13-11-04.png)
This way an endpoint could do essentially the same logic as GET `/api/pleroma/admin/config` except it filters only `exposed_in_api` values and skips the OAuth check.
It could still be returned in `/api/v1/instance`, maybe under `["pleroma", "config"]`.https://git.pleroma.social/pleroma/pleroma/-/issues/1999Prompt to use ConfigDB by default during installation2023-05-08T03:42:53ZAlex GleasonPrompt to use ConfigDB by default during installationI've installed Pleroma a few times lately and it says "Do you want to manage the configuration in the database? [y/N]" and I've been thinking that "yes" should be the default for 2.1. I think ConfigDB has improved a lot since 2.0 and com...I've installed Pleroma a few times lately and it says "Do you want to manage the configuration in the database? [y/N]" and I've been thinking that "yes" should be the default for 2.1. I think ConfigDB has improved a lot since 2.0 and comes with many advantages, we should encourage users to enable it.
It hints that you should run `mix pleroma.config migrate_to_db` afterwards, but should probably be a bit more explicit about that, or maybe even make it part of the installer process.Alexander StrizhakovAlexander Strizhakovhttps://git.pleroma.social/pleroma/pleroma/-/issues/2013Feature Request: Config options to whitelist html classes/tags2023-05-08T03:48:07ZceseseFeature Request: Config options to whitelist html classes/tagsHello,
I heard that pleroma strips classes except those from a whitelist because people used to abuse them.
I think adding the possibility to easily edit this whitelist would allow us to easily add features like latex, furigana, code b...Hello,
I heard that pleroma strips classes except those from a whitelist because people used to abuse them.
I think adding the possibility to easily edit this whitelist would allow us to easily add features like latex, furigana, code blocks, and other things without needing to file an issue every time (example : https://git.pleroma.social/pleroma/pleroma/-/issues/2002 )
From my understanding it wouldn't cause problems because if one instance abuses it, other instances would still strip those "bad classes" (like spinning text).
Also, since technically people can already alter the whitelist by editing the code, it's not like what I'm asking would change the fact that abusers can abuse the system if it's already the case.
(also I'm getting confused about if the issue is just for classes or also for tags in general, since I don't know how the whitelist works)