pleroma-meta issueshttps://git.pleroma.social/pleroma/pleroma-meta/-/issues2022-07-17T17:34:22Zhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/65Make config descriptions translatable2022-07-17T17:34:22ZtusooaMake config descriptions translatableWell, as title. There should not be any inherent language barrier to manage an instance.Well, as title. There should not be any inherent language barrier to manage an instance.tusooatusooahttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/64Weblate: future?2022-08-19T00:44:10ZtusooaWeblate: future?Set up BE translations on weblate. Required by https://git.pleroma.social/pleroma/pleroma-meta/-/issues/60 .Set up BE translations on weblate. Required by https://git.pleroma.social/pleroma/pleroma-meta/-/issues/60 .https://git.pleroma.social/pleroma/pleroma-meta/-/issues/63Weblate: email not working2022-08-19T00:44:13ZtusooaWeblate: email not workingWe are not able to receive emails from weblate, and thus not able to sign up.We are not able to receive emails from weblate, and thus not able to sign up.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/56Freenode → Libera.chat2022-02-27T17:30:48ZHaelwennFreenode → Libera.chatI think we got some rough consensus that staying on Freenode isn't a good idea and that Libera.Chat is the one that will work out for us.
- I've asked for registration of the #pleroma-* namespace on Libera.Chat, kline confirmed it
- Whe...I think we got some rough consensus that staying on Freenode isn't a good idea and that Libera.Chat is the one that will work out for us.
- I've asked for registration of the #pleroma-* namespace on Libera.Chat, kline confirmed it
- When should we do the move, do we wait for the matrix bridge ( https://github.com/matrix-org/matrix-appservice-irc/issues/1324 ) or something like unmanageable spam to happen?
- Do we put in the announcement/blog post about it? What do we put in it? Here is some material:
- A quite complete explaination: https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
- Gentoo Summary email: https://archives.gentoo.org/gentoo-project/message/dc11efe2affb81c3dacd74e4f1ecf8b9
- Alpine announce: https://alpinelinux.org/posts/Switching-to-OFTC.html
- Example from SourceHut: https://sourcehut.org/blog/2021-05-19-liberachat/
Actionnable parts:
- [x] irc.pleroma.social ping @feld ?
- [x] https://git.pleroma.social/pleroma/pleroma.social: https://git.pleroma.social/pleroma/pleroma.social/-/merge_requests/45
- [x] https://git.pleroma.social/pleroma/pleroma: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3415
- [x] https://git.pleroma.social/pleroma/docs: https://git.pleroma.social/pleroma/docs/-/merge_requests/6https://git.pleroma.social/pleroma/pleroma-meta/-/issues/53Login page2021-02-12T19:58:01ZfeldLogin pageUpdating the login page. Can't figure out how to have a permanently uploaded image file, so I guess attaching to an issue is the only sane way?
![pleroma-fox-tan](/uploads/9fff51d57b46276df74985ea8fca88f5/pleroma-fox-tan.png)Updating the login page. Can't figure out how to have a permanently uploaded image file, so I guess attaching to an issue is the only sane way?
![pleroma-fox-tan](/uploads/9fff51d57b46276df74985ea8fca88f5/pleroma-fox-tan.png)https://git.pleroma.social/pleroma/pleroma-meta/-/issues/35Pleroma 2.0.3 tracking bug2020-05-02T19:22:50ZfeldPleroma 2.0.3 tracking bugFE:
* [ ] Register without email https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1072FE:
* [ ] Register without email https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/10722.0.3https://git.pleroma.social/pleroma/pleroma-meta/-/issues/31Pleroma 2.0.2 tracking bug2020-04-09T17:28:08ZfeldPleroma 2.0.2 tracking bugBE:
* [x] Push notifications don't obey blocks/mutes https://git.pleroma.social/pleroma/pleroma/issues/1364
* [x] Respect non-searchable settings of users (pleroma#1601)
* [x] Hackney bug breaking link preview sometimes https://git.pler...BE:
* [x] Push notifications don't obey blocks/mutes https://git.pleroma.social/pleroma/pleroma/issues/1364
* [x] Respect non-searchable settings of users (pleroma#1601)
* [x] Hackney bug breaking link preview sometimes https://git.pleroma.social/pleroma/pleroma/issues/1612
* [x] bio not respecting newlines https://git.pleroma.social/pleroma/pleroma/issues/1643
* [x] Deleting user posts via mix task fails https://git.pleroma.social/pleroma/pleroma/issues/1640
FE:
* [x] Fix missing authorization header for favorited_by and reblogged_by endpoints https://git.pleroma.social/pleroma/pleroma-fe/issues/795
AdminFE:
* [x] Email invites via AdminFE don't support the plus symbol https://git.pleroma.social/pleroma/admin-fe/-/issues/92
* [x] Submit button drawn off screen https://git.pleroma.social/pleroma/admin-fe/-/issues/89
* [x] Add option to set a new password for a user https://git.pleroma.social/pleroma/admin-fe/-/issues/69
* [x] Display status counts by scope https://git.pleroma.social/pleroma/admin-fe/-/issues/54
Docs:
* [x] Improve `mrf_object_age` documentation https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2305
Other:
* [x] Ensure latest PleromaFE bundle merged if needed
* [x] Ensure latest AdminFE bundle merged if needed
* [x] Docker isn't including ImageMagick https://git.pleroma.social/pleroma/pleroma/issues/1644
* [x] Make blog post/announcement and update latest version on pleroma.social landing page2.0.2https://git.pleroma.social/pleroma/pleroma-meta/-/issues/30Pleroma 2.1 tracking bug2020-08-31T07:02:26ZfeldPleroma 2.1 tracking bugNext milestone:
BE:
* [x] Global status expiration (pleroma!2208)
* [ ] Improve context boundaries (pleroma!2165)
* [ ] Frontend bundles removal (pleroma#1390)
* [x] Remove the remaining twitterapi endpoints https://git.pleroma.social...Next milestone:
BE:
* [x] Global status expiration (pleroma!2208)
* [ ] Improve context boundaries (pleroma!2165)
* [ ] Frontend bundles removal (pleroma#1390)
* [x] Remove the remaining twitterapi endpoints https://git.pleroma.social/pleroma/pleroma/issues/1633
* [x] Support filtering on the backend for mastoapi filters (pleroma#1392)
* [x] Fix group reports performance (pleroma!2220) *requires complete refactor of the API endpoint*
* [x] Merge GUN adapter support (pleroma!1861)
* [ ] Make pinned posts federate (pleroma#521)
* [x] Interacting with the admin emoji API can lead to broken emoji (pleroma#1604)
* [x] Support Irreversible Filters (pleroma!2186)
* [x] Support Follower Request notification type https://git.pleroma.social/pleroma/pleroma/issues/1559
* [x] Remove with_move parameter https://git.pleroma.social/pleroma/pleroma/issues/1530
* [x] Websocket streaming for hashtag timelines https://git.pleroma.social/pleroma/pleroma/issues/1593
* [ ] Local-only status support https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2289
* [x] Per-Client captcha options https://git.pleroma.social/pleroma/pleroma/issues/1584
FE:
* [ ] MastoAPI lists (pleroma-fe#229)
* [ ] MastoAPI filters (pleroma-fe#677)
* [ ] Separate behaviour controls for user/thread mutes (pleroma-fe#658)
* [x] Remove the remaining twitterapi endpoints https://git.pleroma.social/pleroma/pleroma-fe/issues/805
StaticFE:
* [x] Emoji support in StaticFE (pleroma#1453)
* [ ] Implement an option to enable static-fe only when javascript is disabled and set it by default (pleroma#1609)
AdminFE:
* [ ] Resolve remaining issues with emoji API so we can enable the emoji section
Docs:
* [ ] Version toggle (docs#1)2.1https://git.pleroma.social/pleroma/pleroma-meta/-/issues/29Pleroma 2.0.1 tracking bug2020-03-16T17:37:05ZfeldPleroma 2.0.1 tracking bugFor things we didn't get into 2.0 release
BE:
* [x] Add admin scope to MastoFE (pleroma!2256)
* [x] Formatting: Do not use `\n` and prefer `<br>` instead (pleroma!2204)
* [x] Cache control improvements https://git.pleroma.social/plerom...For things we didn't get into 2.0 release
BE:
* [x] Add admin scope to MastoFE (pleroma!2256)
* [x] Formatting: Do not use `\n` and prefer `<br>` instead (pleroma!2204)
* [x] Cache control improvements https://git.pleroma.social/pleroma/pleroma/issues/1613
* [x] Relay list showing relays that didn't accept https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2240
* [x] Static dir didn't migrate to database properly https://git.pleroma.social/pleroma/pleroma/issues/1610
* [x] Fix enforcement of character limits https://git.pleroma.social/pleroma/pleroma/issues/1618
* [x] Register without email https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2246
* [x] Fix admin api returning private statuses when it shouldn't https://git.pleroma.social/pleroma/pleroma/issues/1599
* [x] Fix cache-control headers for local and mediaproxy https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2295
* [x] Improve conversations error reporting (pleroma!2264)
* [x] Fix hashtag streaming timeline https://git.pleroma.social/pleroma/pleroma/issues/1593
FE:
* [x] Disable autocomplete/correct on captcha https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1071
**None**
StaticFE:
* [x] Missing Accept header https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2260
* [x] Possibly needs sanitization https://git.pleroma.social/pleroma/pleroma/issues/1614 https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2299
AdminFE:
* [x] Something broken for some users who migrated to database config https://git.pleroma.social/pleroma/pleroma/issues/1615
Docs:
* [x] pleroma_api.md: direct_conversation_id vs. conversation_id https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2263
* [x] fix docs for some commands https://git.pleroma.social/pleroma/pleroma/-/merge_requests/22862.0.1https://git.pleroma.social/pleroma/pleroma-meta/-/issues/21Conversations Improvements2021-01-20T12:18:27ZShpuld ShpludsonConversations ImprovementsWe've had a first taste of utilizing the conversations api in applications now. Pleroma FE has a MR for it and Kenoma is almost in the same boat. There's some UX worries that have to be sorted out that aren't just frontend or backend pro...We've had a first taste of utilizing the conversations api in applications now. Pleroma FE has a MR for it and Kenoma is almost in the same boat. There's some UX worries that have to be sorted out that aren't just frontend or backend problems I think.
- Conversations timeline: It gets very confusing when there's more than 1 'conversations' with the same person, most chat applications don't allow this sort of behavior and instead all messages with a single person are in one continuous timeline. Should we just deal with it or figure out a solution?
- Participants being dropped or added during conversation: tagging users makes no sense in chat context, addressing should be done purely by members list in the current conversation. There might be some other solutions for this as well but we can't do the conversations list in a sensible way if the addressing can change per message.
- Public threads turning into dms: this is the big one, you can end up with completely nonsensical "conversations" where most of the messages were never addressed to you, but it's still your conversations because someone sent a dm reply to you in that thread. I think in these cases the conversation should only return the dms that have been addressed to you and nothing else. Some context could be added on top saying that "this conversation started as a reply to some public post" or something.
Without addressing these problems I think the conversations is a worse experience in pretty much every single way compared to current DMs. I do want to see this feature done well so that pleroma and fediverse in general can closer to competing as a good free chat platform.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/16Pleroma 2.0 tracking bug2020-03-11T15:18:49Zrinpatchrin+pleroma@patch.cxPleroma 2.0 tracking bugThis a tracking bug for Pleroma 2.0. The scheduled date is to be discussed in this issue, but I think it should be early February.
Things needed:
BE:
* [x] Integrated captcha, on by default (pleroma#1405 and pleroma#1017)
* [x] ~~Front...This a tracking bug for Pleroma 2.0. The scheduled date is to be discussed in this issue, but I think it should be early February.
Things needed:
BE:
* [x] Integrated captcha, on by default (pleroma#1405 and pleroma#1017)
* [x] ~~Frontend bundles removal (pleroma#1390)~~
* [x] Ratelimiter on by default again (pleroma#1380)
* [x] Move activity (pleroma#1316)
* [x] ~~Remove the remaining twitterapi endpoints (only register_user and password_reset remain)~~
* [x] <s> Groups (would be **very nice** to have, though I am not sure there will be something allowing us to give capabilities to use a follower collection by the time we need to release) (#14) </s> dropped
* [x] ~~Support filtering on the backend for mastoapi filters (pleroma#1392)~~ next release
* [x] Figure out whether we should proceed with pleroma!1865
* [x] Emoji reactions (pleroma!1662)
* [x] Turn blocks & mutes into proper relations (pleroma#1335)
* [x] ~~Fix group reports performance (https://git.pleroma.social/pleroma/pleroma/merge_requests/2220)~~ requires complete refactor of the API endpoint
* [x] ~~Merge GUN adapter support (https://git.pleroma.social/pleroma/pleroma/merge_requests/1861)~~ next release
* [x] Improve Postgres performance (https://git.pleroma.social/pleroma/pleroma/merge_requests/2238)
FE:
* [x] <s> MastoAPI lists (pleroma-fe#229) </s> dropped
* [x] ~~MastoAPI filters (pleroma-fe#677)~~ next release
* [x] MastoAPI streaming (pleroma-fe#708)
* [x] ~~Separate behaviour controls for user/thread mutes (pleroma-fe#658)~~ next release
* [x] Emoji reactions (pleroma-fe#709)
* [x] Status rendering performance (pleroma-fe!1066)
* [x] Fix broken user cards (pleroma-fe#777)
* [x] Bundle new FE with PleromaBE (pleroma!2255)
(I am well aware that there isn't much development workforce behind pleroma-fe, so feel free to drop items from this list)
AdminFE:
* [x] Working in-database config we can enable by default
* [x] Final AdminFE build for 2.0
Feel free to add items to the list if you think I missed something.
cc: @kaniini @lambadalambda @lanodan @shpuld @hjhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/13Exclude internal.fetch actors from search results2019-10-23T20:43:09ZMew MewExclude internal.fetch actors from search resultsedit: oops, opened this in the wrong repo, feel free to deleteedit: oops, opened this in the wrong repo, feel free to deletehttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/12Getting security-critical updates or major releases via Pleroma feed2019-10-19T08:49:05ZxxGetting security-critical updates or major releases via Pleroma feedThis is not so much of an issue as much as a feature suggestion.
I have tried subscribing to this git via RSS feed but getting every commit as an update is a pain in the ass and I'm too lazy to filter out minor revisions. Is there a wa...This is not so much of an issue as much as a feature suggestion.
I have tried subscribing to this git via RSS feed but getting every commit as an update is a pain in the ass and I'm too lazy to filter out minor revisions. Is there a way we can have a Pleroma account post major updates / security releases / new features / whatever? This makes a lot of sense for people who already use Pleroma quite a bit and has the bonus feature of providing its own RSS feed.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/10Setup an way to publish announcements2020-02-29T13:26:38ZHaelwennSetup an way to publish announcementsA changelog is great but you can't put everything into it, stuff like the move from `master` to `stable` would have to be put into it.
I think a mailing-list would quite suck for this as there is often a lack of public archives and they...A changelog is great but you can't put everything into it, stuff like the move from `master` to `stable` would have to be put into it.
I think a mailing-list would quite suck for this as there is often a lack of public archives and they often seriously lack accessibility/features, a blog and/or a planet of pleroma maintainers blogs (limited to a category/tag) would be better. Something like the in-between forum and mailing-list that is discourse could be considered but it probably quite heavy to host&maintain (we already have gitlab for the pain).https://git.pleroma.social/pleroma/pleroma-meta/-/issues/9Set up weblate2020-05-12T08:32:14ZkaniiniSet up weblateIn IRC, we decided to set up Weblate for managing Pleroma-FE and Pleroma-BE translations.
Can somebody set this up on a pleroma.social machine?
Assigning to @feld for now, he can reassign to whoever else.In IRC, we decided to set up Weblate for managing Pleroma-FE and Pleroma-BE translations.
Can somebody set this up on a pleroma.social machine?
Assigning to @feld for now, he can reassign to whoever else.feldfeldhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/7Actually marketing the 1.1 release2020-03-11T15:19:28ZkaniiniActually marketing the 1.1 releaseWhen we cut the 1.0 release, it was pretty clear that we weren't *quite* ready to start marketing the project to the general public. So we had a couple of blog posts about it and that was it.
But 1.1 is a different story. In my opinio...When we cut the 1.0 release, it was pretty clear that we weren't *quite* ready to start marketing the project to the general public. So we had a couple of blog posts about it and that was it.
But 1.1 is a different story. In my opinion, 1.1 is actually going to be a fairly solid release in terms of general public using and adopting Pleroma. At least, solid enough that we should start talking about outreach.
There are two domains that exist: pleroma.social and pleroma.com (the latter of which is being used for the "roma" apps that were supposed to be optimized clients for Pleroma instances -- how that initiative is playing out isn't really on topic for this issue, we'll discuss it later).
I believe there is value in having a website for the organization itself, but I also believe that we need to build a proper landing page like Mastodon have.
Most of the friction we have right now in terms of onboarding have to do with the fact that it's not really so easy to just jump in and get started. Instead, you are presented with some links to some software, and while we would ideally like everyone to operate their own node, in practice most people just want to pick a pre-existing node and run with it.
And so, I think that we need a landing page that helps people find not just the software, but instances to join as well. If we have a landing page, then it's much easier to do the *other* outreach tasks we need to do, like dealing with the press.
We are roughly 2 weeks out from shipping, so I think we have plenty of time to bang this together.
My proposal would be to leverage pleroma.com for this -- the combination of a good lander and the "roma" apps initiative can mesh well together. It's an easy enough story to sell.
cc @feld @lambadalambda @rinpatch @href (bringing @href into the loop because we could probably use fediverse.network as a source of data for the onboarding process)https://git.pleroma.social/pleroma/pleroma-meta/-/issues/6Choosing a new documentation generator2019-10-04T22:46:10Zrinpatchrin+pleroma@patch.cxChoosing a new documentation generatorLooking into bundling fe and be docs together it seems like the least hacky way to do that is to create a separate project that has a pipeline for fetching fe and be docs and trigger it on commits to be and fe repos. Which means that we ...Looking into bundling fe and be docs together it seems like the least hacky way to do that is to create a separate project that has a pipeline for fetching fe and be docs and trigger it on commits to be and fe repos. Which means that we no longer have to use `ex_doc` for our documentation. I think that while ex_doc is great for inline code docs, it was never intended and not really suited for using it exclusively for extra docs, like we do.
Thus I think we should choose a new documentation generator, the following section describes some of the most popular ones, I am currently leaning towards MkDocs, but if you want to propose a different one or add more advantages/disadvantages to existing ones, please do.
## ExDoc
Example: https://docs-develop.pleroma.social/alpine_linux_en.html
### Advantages
- Inline documentation, I guess? We don't really use it though
### Disadvantages
- Navigation sucks (The menu has a very low max width and titles of some of the pages often occupy 3 lines as a result, also navigation panel shows only `h2` sections, making it useless on most of the docs)
- No i18 support
- No theme support
- Links to Google fonts without an ability to disable it
- Impossible to navigate without JS
- No versioning support
## MkDocs
Example: https://docs.loki.network/Lokinet/Guides/ExitNode/
### Advantages
- Theme support
- Navigation doesn't suck
- Almost everything works without JS
- A bunch of plugins for both MkDocs and Python Markdown
### Disadvantages
- No versioning support
- No i18 support
## Docusaurus
Example: https://docusaurus.io/docs/en/site-creation
### Advantages
- Navigation doesn't suck
- Versioning support
- i18 support
- Theme support
### Disadvantages
- Search requires a proprietary APIhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/4Emoji Reactions Final Steps2020-08-27T11:35:03ZlainEmoji Reactions Final Steps# NEW THOUGHTS SINCE ~06/02/2020
By now we have a working Emoji reaction system. There are a few things to wrap up.
## Backend
As pointed out by misskey people at https://github.com/syuilo/misskey/issues/5425, the choice of `EmojiReac...# NEW THOUGHTS SINCE ~06/02/2020
By now we have a working Emoji reaction system. There are a few things to wrap up.
## Backend
As pointed out by misskey people at https://github.com/syuilo/misskey/issues/5425, the choice of `EmojiReaction` seems weird, as noun types usually get created by a `Create` activity, while verbs usually act on nouns, which `EmojiReaction` does. Of course, in english many nouns are verbs and vice versa. Either way, I'll create an MR that changes `EmojiReaction` to `EmojiReact` to make it clearer.
## Frontend
Mastodon implemented local reaction system for their admin announcements. The endpoints there are as follows:
> ### Adding a reaction
>
> `PUT /api/v1/announcements/:id/reactions/:emoji`
>
> ### Removing a reaction
>
> `DELETE /api/v1/announcements/:id/reactions/:emoji`
>
> ### JSON representation
>
> ```javascript
> {
> // ...
> reactions: [
> { name: '👍', count: 123, me: false },
> { name: 'coolCat', count: 456, me: false, url: 'https://example.com/coolcat.png', static_url: 'https://example.com/coolcat.png' }, },
> ],
> // ...
> }
> ```
> The attribute `me` is true when the authenticated user has added that reaction. The attributes `url` and `static_url` are present for custom emojis.
I'll align our own api with this format to make it easier for clients to support this in the future.
# OLD INFORMATION, DEPRECATED
Backend issue: https://git.pleroma.social/pleroma/pleroma/merge_requests/1662
This makes it possible to 'react' to a post with a single character unicode emoji. This adds a new object type called `EmojiReaction`. It looks pretty much like a `Like`, except it also has a `content` property.
'Single characters' in this context means anything that will be displayed as a single glyph. Combined sequences like 👩👩👧 are valid.
NOTE: The current implementation in Pleroma will not accept sequences.
I decided against overloading `Likes` because they really are semantically different. Just as one aspect, there are a lot of 'negative' Emoji that should not be treated as a like.
A frontend could still decide to display the reaction and like count in a combined way and only differentiate on expanding a post.
No frontend issue yet.
The full type is `litepub:EmojiReaction`
An example reaction activity:
```json
{
"@context": [
{
"litepub": "http://litepub.social/ns#",
"EmojiReaction": "litepub:EmojiReaction"
}
],
"type": "EmojiReaction",
"id": "https://example.com/activities/1",
"object": "https://example.com/posts/1",
"actor": "https://example.com/users/1",
"content": "😀"
}
```https://git.pleroma.social/pleroma/pleroma-meta/-/issues/3Rename master branches to stable2020-03-11T15:19:40ZkaniiniRename master branches to stableI think renaming the `master` branches to `stable` is a good idea, primarily because `stable` is more self-explanatory than `master` to the average person.
Also `master` term has multiple meanings in computer science, such as being a sy...I think renaming the `master` branches to `stable` is a good idea, primarily because `stable` is more self-explanatory than `master` to the average person.
Also `master` term has multiple meanings in computer science, such as being a synonym for the primary system in a cluster, or in our case reference to the "golden master" (in terms of mastering releases, the plate used to press vinyl records would be referred to as the "golden master"). This ambiguity can lead to confusion.
If we do this, then `stable` branch will refer to the newest maintained stable branch. Other maintained branches will be on `release/$version`, such as `release/1.0` with the individual branches used to compose the release branch being `release/1.0.6` and so on.
And so with Pleroma 1.1 going out the door, we would have three branches in play:
- `stable` (presently equivalent to `release/1.1`)
- `release/1.1`
- `release/1.0` (I intend to provide security updates for another 6 month period on 1.0)