pleroma merge requestshttps://git.pleroma.social/pleroma/pleroma/-/merge_requests2024-03-18T12:50:38Zhttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3669Instance rules2024-03-18T12:50:38Zmarcin mikołajczakInstance ruleshttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3659Add "status" notification type2024-01-31T21:56:12Zmarcin mikołajczakAdd "status" notification typeThis adds a separate notification type for statuses from accounts you are subscribed to. This notification type is already used by Mastodon.This adds a separate notification type for statuses from accounts you are subscribed to. This notification type is already used by Mastodon.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3654feat: simple, but not stupid, uploader for IPFS2022-11-03T15:16:51ZClaudio Maradonnafeat: simple, but not stupid, uploader for IPFSThis is a simple but not stupid implementation of an upload system for attachments using IPFS.
This requires to have a PUSH Gateway configured in your localhost server, where Pleroma runs too, we will call this PUSH-G.
We will call the ...This is a simple but not stupid implementation of an upload system for attachments using IPFS.
This requires to have a PUSH Gateway configured in your localhost server, where Pleroma runs too, we will call this PUSH-G.
We will call the Public GET Gateway as GET-G.
Example config:
```elixir
config :pleroma, Pleroma.Uploaders.IPFS,
post_gateway_url: "http://localhost:5001/",
get_gateway_url: "https://ipfs.mydomain.com/{CID}"
```
The parameter `get_gateway_url` expects a `cid` placeholder to be replaced by the real Content ID. So you can try to adjust to your Gateway configuration. Other examples:
- "https://{CID}.ipfs.mydomain.com"
- "ipfs://{CID}"
To simplify the process, the uploader appends to the POST URL the `?cid-version=1` parameter. Why this choice? Because by using the cid version 1, we can allow more Gateway configurations. If we use the standard CID version, 0 to understand, only this one would work: `https://ipfs.mydomain.com/{CID}`
I'm looking forward to your feedback.
Happy Hacking.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3637Chats: pin/unpin chats2024-02-22T11:10:56Zmarcin mikołajczakChats: pin/unpin chatshttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3627Migration to fix Oban log param in database set to empty string "" instead of...2022-02-03T07:33:56ZmeowskiMigration to fix Oban log param in database set to empty string "" instead of falseMigration to fix Oban log param in database set to empty string "" instead of false, causing Pleroma to immediately exit on startup.
Compatibility with Oban 20. Required log values are false or a log level string. (there was a previous ...Migration to fix Oban log param in database set to empty string "" instead of false, causing Pleroma to immediately exit on startup.
Compatibility with Oban 20. Required log values are false or a log level string. (there was a previous migration to fix this)
Also some additions to .gitignore for people who (foolishly?) have pleroma's home set to /opt/pleroma (like me)
See issue #2827
ps this thing is getting hung up on the linting of mix format but I have no idea how to turn on verbose output to see what it's actual problem is. the formatting of the file looks fine to me and it works. thoughts?https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3615SimplePolicy reasons: handle legacy config2022-03-05T14:07:30ZAlex GleasonSimplePolicy reasons: handle legacy config@neetzsche was encountering this error:
```
Jan 22 20:09:46 iddqd mix[16703]: ** (exit) an exception was raised:
Jan 22 20:09:46 iddqd mix[16703]: ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Pleroma.We...@neetzsche was encountering this error:
```
Jan 22 20:09:46 iddqd mix[16703]: ** (exit) an exception was raised:
Jan 22 20:09:46 iddqd mix[16703]: ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
Jan 22 20:09:46 iddqd mix[16703]: (pleroma 2.4.51-594-g4ac36ad1-develop) lib/pleroma/web/activity_pub/mrf.ex:107: anonymous fn("baraag.net") in Pleroma.Web.ActivityPub.MRF.instance_list_from_tuples/1
Jan 22 20:09:46 iddqd mix[16703]: (elixir 1.13.2) lib/enum.ex:1593: Enum."-map/2-lists^map/1-0-"/2
Jan 22 20:09:46 iddqd mix[16703]: (pleroma 2.4.51-594-g4ac36ad1-develop) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:31: Pleroma.Web.ActivityPub.MRF.SimplePolicy.check_reject/2
Jan 22 20:09:46 iddqd mix[16703]: (pleroma 2.4.51-594-g4ac36ad1-develop) lib/pleroma/web/activity_pub/mrf/simple_policy.ex:233: Pleroma.Web.ActivityPub.MRF.SimplePolicy.filter/1
Jan 22 20:09:46 iddqd mix[16703]: (elixir 1.13.2) lib/enum.ex:2396: Enum."-reduce/3-lists^foldl/2-0-"/3
Jan 22 20:09:46 iddqd mix[16703]: (pleroma 2.4.51-594-g4ac36ad1-develop) lib/pleroma/web/activity_pub/activity_pub.ex:1615: Pleroma.Web.ActivityPub.ActivityPub.user_data_from_user_object/1
Jan 22 20:09:46 iddqd mix[16703]: (pleroma 2.4.51-594-g4ac36ad1-develop) lib/pleroma/web/activity_pub/activity_pub.ex:1624: Pleroma.Web.ActivityPub.ActivityPub.fetch_and_prepare_user_from_ap_id/1
Jan 22 20:09:46 iddqd mix[16703]: (pleroma 2.4.51-594-g4ac36ad1-develop) lib/pleroma/web/activity_pub/activity_pub.ex:1708: Pleroma.Web.ActivityPub.ActivityPub.make_user_from_ap_id/1
```
It seems to be caused by !3314, and is happening despite running the database migrations and having no legacy config on the filesystem.
We don't know why the config didn't get updated, but rather than failing so hard I see no reason why to not just handle the legacy config.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3571Combine Activities and Objects into one table2022-09-07T21:46:31ZAlex GleasonCombine Activities and Objects into one tableThis is the general theory:
1. Add missing fields and indexes to `objects` table
2. `INSERT INTO objects (SELECT * FROM activities);`
3. Edit activity.ex and change schema `"activities"` to schema `"objects"`
4. ???
This MR includes th...This is the general theory:
1. Add missing fields and indexes to `objects` table
2. `INSERT INTO objects (SELECT * FROM activities);`
3. Edit activity.ex and change schema `"activities"` to schema `"objects"`
4. ???
This MR includes the changes from !3570.
The server runs. Everything seems to be working. Some lazy tests fail because they are checking the results with `Repo.one()`, and now there are multiple things in the same table.
There are a few more small things to take care of.
By keeping the `Activity` module intact, it was not as hard as it seemed. Parts of that code could be rewritten in later MRs.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3542Irreversible filter works with user streaming.2024-02-16T12:56:11ZkPheroxkphrx@kpherox.devIrreversible filter works with user streaming.- `irreversible` only works for home and notification timelines in Mastodon.
- In pleroma, notifications are irreversible, but the home timeline is not. So currently, filtered with SQL when getting them with the Timeline API, but not the...- `irreversible` only works for home and notification timelines in Mastodon.
- In pleroma, notifications are irreversible, but the home timeline is not. So currently, filtered with SQL when getting them with the Timeline API, but not the Streaming API. It needs to be filtered before streaming.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3518CommonAPI: Allow URLs into media_ids2022-02-25T09:37:03ZHaelwennCommonAPI: Allow URLs into media_idshttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3516Draft: Transcode video upload filter2021-09-01T14:44:23ZIgor RogattyDraft: Transcode video upload filterUsers upload videos in various formats and sizes. With this new filter admins can decide to transcode all uploaded videos using [ffmpeg](https://ffmpeg.org/about.html) and params specified in config.
Ffmpeg is pretty slow and CPU-heavy...Users upload videos in various formats and sizes. With this new filter admins can decide to transcode all uploaded videos using [ffmpeg](https://ffmpeg.org/about.html) and params specified in config.
Ffmpeg is pretty slow and CPU-heavy, so I'm not sure if it's a good idea to run it synchronously on upload. There is no existing foundation to offload it to an async worker though, so maybe it's good enough as a first step. Actually, I'm not sure if it's even possible given the need for compatibility with various clients.
Code is heavily inspired by https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3331. It's the first time I touch Elixir so it's highly possible I made some rookie mistakes.
Fixes https://git.pleroma.social/pleroma/pleroma/-/issues/1228.
TODO:
- [x] Plugin skeleton
- [ ] Fix plugin being stuck in a loop
- [ ] Move output extension to config
- [ ] Allow additional args to be set in config
- [ ] Stop polluting logs with ffmpeg progress
- [ ] Add tests
- [ ] Update cheatsheethttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3487Draft: Ingestion Pipeline: Listen2024-03-19T16:18:36ZHaelwennDraft: Ingestion Pipeline: ListenYet another separated part of https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3036Yet another separated part of https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3036https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3486Draft: Ingestion Pipeline: Undo-Follow aka Unfollow2023-02-05T17:39:04ZHaelwennDraft: Ingestion Pipeline: Undo-Follow aka Unfollowhttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3471NSFW API Policy2021-11-15T15:11:47ZAlex GleasonNSFW API PolicyDownstream MR: https://gitlab.com/soapbox-pub/soapbox/-/merge_requests/35/
This adds a new MRF Policy: `NsfwApiPolicy`. It relies on an external FOSS service that can be easily self-hosted. During MRF filtering, it submits the attachmen...Downstream MR: https://gitlab.com/soapbox-pub/soapbox/-/merge_requests/35/
This adds a new MRF Policy: `NsfwApiPolicy`. It relies on an external FOSS service that can be easily self-hosted. During MRF filtering, it submits the attachments to the API service which uses artificial intelligence to rate it on a scale of 0-1, with 1 being most certainly NSFW.
Once you have the score, you can configure a threshold (default `0.7`) for which to take action. Then you can either reject, unlist, or mark sensitive any content above the threshold.
Under the hood this uses Yahoo's [open_nsfw](https://github.com/yahoo/open_nsfw) and it's pretty accurate.
If the API server fails or any reason, it will treat the attachment as SFW and pass it through. It only works on images.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3470Let users opt-in to email list2021-06-15T18:55:17ZAlex GleasonLet users opt-in to email listDownstream MR: https://gitlab.com/soapbox-pub/soapbox/-/merge_requests/33
During registration, this allows users to send an extra param, `accepts_email_list` (bool) opting in to receive admin emails. This is separate from the Terms of S...Downstream MR: https://gitlab.com/soapbox-pub/soapbox/-/merge_requests/33
During registration, this allows users to send an extra param, `accepts_email_list` (bool) opting in to receive admin emails. This is separate from the Terms of Service box and is intended for sending a newsletter to users.
Two new endpoints are introduced:
- GET `/api/v1/pleroma/admin/email_list/subscribers.csv`
- GET `/api/v1/pleroma/admin/email_list/unsubscribers.csv`
These export CSVs meant to be imported into a third-party service like Mailchimp, Constant Contact, or anything else that can take a CSV. `subscribers.csv` contains all local users who opted in while `unsubscribers.csv` contains all other local users. It's important to have both in order to patch the external list.
Users may opt-in or opt-out with PATCH `/api/v1/accounts/update_credentials`
`accepts_email_list` is false by default and not required.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3469Refactor Pleroma.Frontend, enable a frontend through the CLI, fixes #26722021-06-15T19:21:45ZAlex GleasonRefactor Pleroma.Frontend, enable a frontend through the CLI, fixes #2672Downstream MR: https://gitlab.com/soapbox-pub/soapbox/-/merge_requests/34
1. Refactors `Pleroma.Frontend` to use a `%Frontend{}` struct. Previously it passed in opts from the mix task, but using a struct makes it more modular.
2. Intro...Downstream MR: https://gitlab.com/soapbox-pub/soapbox/-/merge_requests/34
1. Refactors `Pleroma.Frontend` to use a `%Frontend{}` struct. Previously it passed in opts from the mix task, but using a struct makes it more modular.
2. Introduces `mix pleroma.frontend enable <name>`. If ConfigDB isn't enabled, it'll raise.
3. Adds `mix pleroma.frontend install <name> --primary` to install *and* enable a frontend with a single command. (`--primary` and `--admin` are supported).https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3468Draft: Newlines in push and link previews2021-06-24T21:49:25ZfeldDraft: Newlines in push and link previews#2669#2669https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3401Rich media embeds2021-12-28T01:17:43ZAlex GleasonRich media embedsThis is an entirely new version of !3366. This is my third (or fourth?) iteration trying to solve the problem of rich media embeds, and after a lot of thought I decided I needed to majorly redesign the code. I investigated some third-par...This is an entirely new version of !3366. This is my third (or fourth?) iteration trying to solve the problem of rich media embeds, and after a lot of thought I decided I needed to majorly redesign the code. I investigated some third-party solutions, but for one reason or another they were not a good fit for Pleroma, so this time I created a solution from the ground-up.
The goal is to limit the number of HTTP requests. Services like YouTube enforce oppressive rate limiting and will block even small Pleroma servers. The solution is to make the OEmbed request directly to the service's OEmbed endpoint rather than scraping the page first to discover it.
I created an Elixir library, [oembed_providers_elixir](https://gitlab.com/soapbox-pub/oembed_providers_elixir), which loads [JSON provider data](https://oembed.com/providers.json) that Pleroma now uses to skip unnecessary HTTP requests. If it can't produce the embed that way, it'll fall back to scraping the page.
There are two new structs:
- `%Embed{}` - inspired by [Furlex](https://github.com/claytongentry/furlex), this struct holds any and all embed data about a URL. The Parser now returns this type. Individual parsers build an Embed rather than a messy, undefined map.
Example:
```elixir
%Embed{
url: "http://example.com/ogp",
title: "The Rock (1996)",
meta: %{
"og:image" => "http://ia.media-imdb.com/images/rock.jpg",
"og:title" => "The Rock",
"og:description" => "Directed by Michael Bay. With Sean Connery, Nicolas Cage, Ed Harris, John Spencer.",
"og:type" => "video.movie",
"og:url" => "http://www.imdb.com/title/tt0117500/"
},
oembed: nil
}
```
- `%Card{}` - represents a [MastoAPI card](https://docs.joinmastodon.org/entities/card/), plus sanitation and validation. Embeds get turned into Cards, which ultimately get returned through the API.
Example:
```elixir
%Card{
type: "link",
title: "She Was Arrested at 14. Then Her Photo Went to a Facial Recognition Database.",
url: "https://www.nytimes.com/2019/08/01/nyregion/nypd-facial-recognition-children-teenagers.html",
description: "With little oversight, the N.Y.P.D. has been using powerful surveillance technology on photos of children and teenagers.",
image: "https://static01.nyt.com/images/2019/08/01/nyregion/01nypd-juveniles-promo/01nypd-juveniles-promo-videoSixteenByNineJumbo1600.jpg",
provider_name: "www.nytimes.com",
provider_url: "https://www.nytimes.com"
}
```
All of the code now centers around these two types, greatly simplifying it.
Some other design choices:
- Parser classes no longer stop when they find empty data. All available Parsers run and build out different parts of the Embed struct. Their order doesn't matter anymore.
- I ditched `MetaTagsParser` and replaced it with a completely new module, `MetaTags`. I think the old one was trying to do too much. The new one simply parses all `<meta>` tags on the page into a map.
Screenshots:
![Screenshot_from_2021-05-04_20.28.11](/uploads/83269eca0693da9aeb7440eb99192761/Screenshot_from_2021-05-04_20.28.11.png)
![Screenshot_from_2021-05-04_19-28-29](/uploads/2f5d1bccb0770f2a4ed90433701eb3fc/Screenshot_from_2021-05-04_19-28-29.png)
![Screenshot_from_2021-05-04_18-51-15](/uploads/4af33555ed2c71737de8e3d3fc685d99/Screenshot_from_2021-05-04_18-51-15.png)
![Screenshot_from_2021-05-04_20-27-08](/uploads/6fb8b2ad117438cd0a37c769aa9d6eb2/Screenshot_from_2021-05-04_20-27-08.png)https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3374Config versioning2023-03-02T02:14:24ZAlexander StrizhakovConfig versioning- added DynamicSupervisor, which starts Pleroma deps and restarts config dependent deps
- added versioning for in database config. A new version is created from
changes that are passed to the config update/delete endpoint. Every version
...- added DynamicSupervisor, which starts Pleroma deps and restarts config dependent deps
- added versioning for in database config. A new version is created from
changes that are passed to the config update/delete endpoint. Every version
contains a backup with all changes added through an update. Versioning
supports rollbacks with N steps. With a rollback, all versions that
come after the version on which the rollback was made are deleted.
#2145Alexander StrizhakovAlexander Strizhakovhttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3367Draft: Finalize OpenAPI everywhere with OAuth2024-02-15T14:41:07ZHaelwennDraft: Finalize OpenAPI everywhere with OAuthDepends on: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3324Depends on: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3324https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3348adding tab & tab_label fields to the descriptions2023-04-13T16:01:28ZAlexander Strizhakovadding tab & tab_label fields to the descriptionsCloses #2389Closes #2389Alexander StrizhakovAlexander Strizhakov