pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-11-05T23:17:38Zhttps://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/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/2241[Feature Request] Bookmark categories2024-03-18T09:53:17ZDuponin[Feature Request] Bookmark categoriesBookmarking is a really cool feature I use frequently to note posts to see later (that's what it meant for).
It's big pro is to be synchronize on the instance and not on device, allowing to easily inspect bookmarked posts on the proper d...Bookmarking is a really cool feature I use frequently to note posts to see later (that's what it meant for).
It's big pro is to be synchronize on the instance and not on device, allowing to easily inspect bookmarked posts on the proper device.
A drawback I encounter is to only have one bookmark category, forcing me to merge different content (tech posts, cute image, todo list, etc.).
That could be solve if we can create bookmark categories.
Sure it will break compatibility with clients/frontends.
If no bookmark category is gave behavior would be the default bookmark category (it's a proposal, I don't know how it's managed).https://git.pleroma.social/pleroma/pleroma/-/issues/3057Supporting the Ivory app2023-05-08T00:37:24ZfeldSupporting the Ivory appStep 1: they're blocking Pleroma because they detect our user IDs are not integers
Step 2: figure out why the `/api/v1/statuses` response is not working for themStep 1: they're blocking Pleroma because they detect our user IDs are not integers
Step 2: figure out why the `/api/v1/statuses` response is not working for themhttps://git.pleroma.social/pleroma/pleroma/-/issues/2975Multi-language posting2023-05-08T00:41:00ZtusooaMulti-language postingIt would be beneficial to allow users specify the language of a post, and to use contentMap and such in ActivityStreams to mark the choice of language(s). A post can have multiple versions in different languages. The plan is as follows:
...It would be beneficial to allow users specify the language of a post, and to use contentMap and such in ActivityStreams to mark the choice of language(s). A post can have multiple versions in different languages. The plan is as follows:
- mastodon API
- `language` param when posting: Mastodon only allows it to be a string (enum). We should not enforce the enum requirement, meaning we should allow arbitrary strings in language codes. We could, however, parse the language code to decompose lang, extlang, writing system and region, in order to support language filtering per user or instance-default.
- We can also allow it to be a list of strings, so users can post in multiple languages.
- when `language` is a list, require `status_map`, `spoiler_text_map` and `poll["options_map"][*]` to be a map from language code to the text intended. Disregard `status`, `spoiler_text` and `poll["options"]`.
- When returning a status, use `status_map`, `spoiler_text_map` and `poll["options_map"]` to return the language-marked versions. Use the original attrs to return the text containing every language version (see below).
- AP representation
- contentMap contains `{"lang-code": "content"}`
- content contains a string that is composed of every language version, merged into a template (the default can be `[{lang-code}] {text}`) via a separator (could be `<br><br>---<br><br>`). Both the template and the separator must be configurable. If contentMap only contain one language, do not use the template. Instead, fill what is in `contentMap[lang]` into `content`.
- Note: as `content` means `content` with `@language=und` in our JSON-LD structure (specified by our header), we might want to disallow the value `und` in language.
- We could have a different template and separator for single-line content (e.g. subject, image desc, polls)
- If an incoming object has contentMap, disregard their content, and instead compute our own version.
- Use some AP attribute to indicate the preferred order of languages that appears in the merged content (specified by mastodon api `language` attribute). This is optional.
- language filtering
- We should support inclusive and exclusive filtering.
- When one language code is filtered, all subvariants of it should also be. For example, if a user chooses to include `en`, we should also include posts marked with `en-Latn`, `en-CA`, `en-Latn-US`, and so on.
- Don't make assumptions on the subtags. Use it as what the user specified.
- Misc/Implementation details
- If we want to implementation a language dropdown in frontend, I did this in Glitch-lily, that directly pulls the language codes from the iana registry. https://lily-is.land/infra/glitch-lily/-/commit/3cea07639462f9e9c892ed2c9a24a853fd9a7515
- In the frontend we should not enforce an enum. Give the user the option to choose a language, and optionally the variant subtags (writing system, region, etc.).
- We can, however make a list of "commonly used languages" and put them on the top of the list. This should at least include all the languages we have a translation for. `ja_easy` can be represented as `ja-Hrkt`.
- We need more cache entries to store different language versions of the same post.https://git.pleroma.social/pleroma/pleroma/-/issues/2751Feature: Cross-post Pleroma posts to Twitter2023-05-08T01:39:23ZRajasekhar PonakalaFeature: Cross-post Pleroma posts to TwitterWe need a feature to cross-post every status from Pleroma to Twitter, including Pleroma account address at the end of every status.
It's a great boost for people looking to migrate to Pleroma but didn't want to lose their followers list...We need a feature to cross-post every status from Pleroma to Twitter, including Pleroma account address at the end of every status.
It's a great boost for people looking to migrate to Pleroma but didn't want to lose their followers listening from them. At the end of every status posted to Twitter, we can include Pleroma account address, so followers on Twitter also might get motivation to join Pleroma.
## Solution
### In-built
It is hard to maintain a separate micro-service or [trust a 3rd party service](https://github.com/renatolond/mastodon-twitter-poster), so building this into the core is preferable.
### Plugin
If not in core, there should be a provision for adding it as a [plugin](https://git.pleroma.social/pleroma/pleroma/-/issues/2713)https://git.pleroma.social/pleroma/pleroma/-/issues/2051Advanced search operators2023-05-08T02:02:45ZfeldAdvanced search operatorsLet's start building out some advanced search capabilities so users can ask for more specific results.
* user:account@domain
* instance:domain.tld
Unsure which others are going to be useful, but these two seem obvious and easy enough ...Let's start building out some advanced search capabilities so users can ask for more specific results.
* user:account@domain
* instance:domain.tld
Unsure which others are going to be useful, but these two seem obvious and easy enough to implement.https://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/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/2781Feature request: mix task to migrate an instance to a new domain2023-05-08T01:33:47ZYour New SJW WaifuFeature request: mix task to migrate an instance to a new domainA mix task that will move followers, update the database, and send out update activities for everything to allow instances to change domains would be nice.A mix task that will move followers, update the database, and send out update activities for everything to allow instances to change domains would be nice.https://git.pleroma.social/pleroma/pleroma/-/issues/2697Request: Option for Quarantine to not send public posts to quarantined instances2023-05-08T01:43:37ZerisRequest: Option for Quarantine to not send public posts to quarantined instancesCurrently the behavior of Quarantine checks if the post is public and then, if not, applies the quarantine code: https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/publisher.ex#L107
In my experience t...Currently the behavior of Quarantine checks if the post is public and then, if not, applies the quarantine code: https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/activity_pub/publisher.ex#L107
In my experience this behavior is misleading for what the "Quarantine" option should actually be, and this is exploited by instances with large-scale harassment campaigns to invade and hellthread a post from an instance that blocks them. I assume I don't need to elaborate on that further as I'm sure the instances guilty of this will come to this thread to make themselves known anyway.
An option as to whether the Quarantine will still send out public posts or not would suffice to fix this.
This isn't meant to affect "muh open federation", but to prioritize safety and security when people have made it known that it's necessary and put that decision making in the hands of the admin.
Thank youhttps://git.pleroma.social/pleroma/pleroma/-/issues/2458Draft: Federate with blockchain domains like .bit and .crypto2023-05-08T01:20:23ZAlex GleasonDraft: Federate with blockchain domains like .bit and .cryptoI have not really thought this through, but I wanted to drop the idea here.
There's been a lot of talk about deplatforming on the DNS level lately. There are initiatives to replace DNS with something blockchain-based, like [Namecoin](ht...I have not really thought this through, but I wanted to drop the idea here.
There's been a lot of talk about deplatforming on the DNS level lately. There are initiatives to replace DNS with something blockchain-based, like [Namecoin](https://www.namecoin.org/) and [Unstoppable Domains](https://unstoppabledomains.com/) which use .bit and .crypto TLDs.
These TLDs are not supported by the ICANN at all and don't use traditional DNS. Usually, the end-user needs to install a browser extension to make those domains resolve. If Pleroma could do whatever the browser extension does, it should have the ability to federate with .bit and .crypto domains. This would help the Fediverse be more resistant to deplatforming on the DNS level.
Pleroma is already able to [federate with Tor instances](https://docs.pleroma.social/backend/configuration/onion_federation/), so I think supporting these domains should be possible.https://git.pleroma.social/pleroma/pleroma/-/issues/2317Don't allow old password reset tokens2023-05-08T03:21:36ZAlex GleasonDon't allow old password reset tokensCan't find any evidence that Pleroma checks or cleans up old password reset tokens. This is a problem, because email isn't secure, and if someone's email gets leaked these password reset URLs could be used to access the account months or...Can't find any evidence that Pleroma checks or cleans up old password reset tokens. This is a problem, because email isn't secure, and if someone's email gets leaked these password reset URLs could be used to access the account months or years after.
The password reset already has a timestamp attached to it. When used, it should just confirm that the token is, say, less than 7 days old (or some configurable value).https://git.pleroma.social/pleroma/pleroma/-/issues/2254Moderation notifications2023-05-08T03:24:28ZSean KingModeration notificationsRelated issue opened at Soapbox FE: https://gitlab.com/soapbox-pub/soapbox-fe/-/issues/501
The idea is that @mkfain wants auto-messages sent in regards to moderation actions and to make moderation workflow more efficient.
**1. Send use...Related issue opened at Soapbox FE: https://gitlab.com/soapbox-pub/soapbox-fe/-/issues/501
The idea is that @mkfain wants auto-messages sent in regards to moderation actions and to make moderation workflow more efficient.
**1. Send users a notification when a mod takes action on their status**
Users should receive a notification in their notifications when a mod takes an action on their account. Possibly there can be an Admin setting to determine what account the notification will appear to come from? It could be a chat or DM (personally, I'd prefer to take advantage of the chat feature). Maybe the content text should also be customizable, or a note can be attached to the notification? For example:
> Hi, [@accountname]. Your status was deleted by [Instance] moderators.
>
> Note: "Rule 4"
or
> Hi, [@accountname]. Your status[link] was marked as Sensitive by [Instance] moderators.
>
> Note: "NSFW media should be marked"
**2. Automatically send users an email when account-level action is taken.**
Ideally, this could also be customized in Admin settings. For example:
> Hi [@accountname],
>
> Your account has been deleted by [Instance] moderators.
>
> Note: "Multiple rule violations after warnings"
>
> You can find a new instance to join on the Fediverse here: [link]
>
> Sincerely,
>
> [Instance] Modshttps://git.pleroma.social/pleroma/pleroma/-/issues/2233Improve HTML email designs2023-05-08T01:05:26ZAlex GleasonImprove HTML email designsMastodon has a nice default email template with a lot of information:
![Screenshot_2020-10-11_box_alexgleason_me_Webmail_Welcome_to_Mastodon_1_](/uploads/860f350b03951eec2beb8f0e3bfe7ed3/Screenshot_2020-10-11_box_alexgleason_me_Webmail_...Mastodon has a nice default email template with a lot of information:
![Screenshot_2020-10-11_box_alexgleason_me_Webmail_Welcome_to_Mastodon_1_](/uploads/860f350b03951eec2beb8f0e3bfe7ed3/Screenshot_2020-10-11_box_alexgleason_me_Webmail_Welcome_to_Mastodon_1_.png)
---
I think it would be good to offer a base email template all emails can extend from, and to include a lot more info in the welcome email. The default welcome email currently just says `"Welcome to #{instance_name()}!"`https://git.pleroma.social/pleroma/pleroma/-/issues/2223support custom-emojis as reactions2023-05-08T03:31:02ZGhost Usersupport custom-emojis as reactionsas misskey already does, evidently:
![misskey_custom-reactions](/uploads/17b6437c627c71b8acfd03d05feeae5a/misskey_custom-reactions.jpg) \
( https://misskey.io/notes/8cy8yw6guj )
this will unify emoji and reaction components;
also poss...as misskey already does, evidently:
![misskey_custom-reactions](/uploads/17b6437c627c71b8acfd03d05feeae5a/misskey_custom-reactions.jpg) \
( https://misskey.io/notes/8cy8yw6guj )
this will unify emoji and reaction components;
also possible resolution against ui-clutter: \
convert single-emoji-replies (any kind of emoji) into reactions, with confirmation dialog \
and remove the "add reaction" buttonhttps://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/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/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/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).