pleroma-meta issueshttps://git.pleroma.social/pleroma/pleroma-meta/-/issues2023-09-30T09:32:22Zhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/70Libreplanet 2024 session submission2023-09-30T09:32:22ZtusooaLibreplanet 2024 session submissionhttps://annuel2.framapad.org/p/8t1u7l9h9z-a3iq?lang=enhttps://annuel2.framapad.org/p/8t1u7l9h9z-a3iq?lang=enhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/69Read-only/Restricted users2023-05-10T02:21:58ZtusooaRead-only/Restricted usersIt would be helpful to have read-only or restricted users.
- If I set up manual approval on my instance, it would be useful to let them login right away so they do not try to create duplicate accounts.
- If the instance requires email c...It would be helpful to have read-only or restricted users.
- If I set up manual approval on my instance, it would be useful to let them login right away so they do not try to create duplicate accounts.
- If the instance requires email confirmation, it would be useful to let users login and try resend or change email address.
- If a user is banned, they should be able to login, appeal, and export their data.
A restricted user should behave as a guest most of the time (no posting, no shoutbox, no changing of personal info, don't show up in searches, no access to local-only posts, etc.).
The only thing they are able to do should be:
- change email/password
- change registration reason
- appeal
- export their datahttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/68Translations: avoid mandarin hegemony2023-02-04T04:01:36ZtusooaTranslations: avoid mandarin hegemonyLanguage codes for Mandarin are currently `zh`. This is, rather, intended to represent Chinese languages as a whole. This Mandarin-default assumption is problematic. We should instead use `cmn` to represent Mandarin.
Also, the language ...Language codes for Mandarin are currently `zh`. This is, rather, intended to represent Chinese languages as a whole. This Mandarin-default assumption is problematic. We should instead use `cmn` to represent Mandarin.
Also, the language names are currently written as "Simplified Chinese" and "Traditional Chinese," which **are not languages, but writing systems**. This should be changed too.tusooatusooahttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/66GitLab issues with keeping sessions persistent2022-08-01T04:09:43ZSean KingGitLab issues with keeping sessions persistentI notice a lot of issues with keeping sessions persistent on Pleroma's GitLab. In one case, I will be logged out on one device/browser if I log in on another device/browser. And in another case if I close and reopen the last browser/devi...I notice a lot of issues with keeping sessions persistent on Pleroma's GitLab. In one case, I will be logged out on one device/browser if I log in on another device/browser. And in another case if I close and reopen the last browser/device I logged in with, I will suddenly have duplicate sessions.
I double checked all my browsers and none of them have removing cookies and site data after closing the browser enabled.
**Steps to reproduce the first case:**
1. Log in to Pleroma's GitLab on one browser.
2. Log in to Pleroma's GitLab on another browser.
3. Close out the first browser.
4. Reopen the first browser logged into.
5. Try going to Pleroma's GitLab from the first browser.
**Steps to reproduce the second case:**
1. Clear all sessions and log out.
2. Log in to Pleroma's GitLab.
3. Close out current browser.
4. Reopen current browser.
5. Go to Pleroma's GitLab.
6. Visit https://git.pleroma.social/-/profile/active_sessions and you'll see two sessions instead of only one session for the same device.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/62Dependency auditing2022-03-05T19:46:51ZtusooaDependency auditingThere is currently no routine for updating dependencies regularly, which could lead to security vulnerabilities.
For frontend, hj recommended https://docs.renovatebot.com/ which could be integrated with gitlab.
For backend, https://git...There is currently no routine for updating dependencies regularly, which could lead to security vulnerabilities.
For frontend, hj recommended https://docs.renovatebot.com/ which could be integrated with gitlab.
For backend, https://github.com/mirego/mix_audit or `mix hex.outdated` is suggested.
Both should be run on a regular basis.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/61Feature set inconsistency and Feature Discoverability2022-08-22T18:48:06ZIljaFeature set inconsistency and Feature Discoverability## The Sales pitch
Different platforms on the fediverse have a different feature set, which can lead to problems. For example, when someone from mastodon makes a post, I can emoji-react to it, but they wont see it. This is one example, b...## The Sales pitch
Different platforms on the fediverse have a different feature set, which can lead to problems. For example, when someone from mastodon makes a post, I can emoji-react to it, but they wont see it. This is one example, but there are many. This leads to a bad UX because people can't easily be sure whether their actions will me noticed by the relevant people. This problem also leads to an incentive for implementations to implement an ever growing feature set, which is not sustainable in the long run.
One solution I see to this, is feature discoverability. Let's take the Emoji-react example again; We could imagine instances somehow advertising what features they do or don't support. That way Pleroma could let their clients know about what features are supported and the clients could present that information in a user-friendly way. (E.g. by giving the emoji-react icon a "dissabled" state when the target doesn't support this feature.)
## Known ways in the wild
There are two examples of how features are advertised that I know of
* On the individual object (both examples are actors)
* Pleroma has this for `capabilities.acceptsChatMessages` (but we don't actually use it)
* Smithereen has this for `FriendRequests`
* Instance wide we have Nodeinfo's `metadata.features`
I added some examples below[1]. See also <https://socialhub.activitypub.rocks/t/service-capability-discovery/630>.
## Practical
For Object specific things, advertising should be done by adding the relevant info as part of the object. Maybe the feature set should be a collection? (Y'know, since it's AP and all.)
A first idea if we want to keep track of instance wide features: We already have a table `instances`. We could add a new json column there with relevant nodeinfo. To keep it up to date we could fetch the Nodeinfo from newly discovered instances and then at regular intervals.
When a front-end fetches a post or account, we could make the supported feature list part of the json-object we return. This list is first loaded from the list on the instance level and then overloaded with the list of the object.
Maybe there are cases where a certain feature is relevant to e.g. a Note, but should be defined on the Actor level? In that case the overloading of the features list could be instance-actor-object.
We could wonder if such a layered way is needed. A Note whose instance can't handle emoji reactions now, may be able to handle them in the future. If we only pass the list in objects over AP and ignore the whole Nodeinfo part, then the older objects will show an outdated feature list. This may lead to some unexpected cases when someone interacts with an older object, but may be worth the trade-off to reduce complexity?
If a certain feature isn't advertised, we have to make our own assumptions. We can also let the front-end decide how to deal with missing information.
When doing this, we should share it in <https://socialhub.activitypub.rocks/t/service-capability-discovery/630> so that other implementers know about it and can provide feedback.
## Beyond
Even though this solves the problem of knowing what interactions can be done with other people, there is still a problem of how you want people to be able to interact with you. For example, they may want to invite you to a party, and you may want them to have that ability, but your instances software doesn't understand events. A work-around is to make an account on a different instance and tell people to invite that account, but that's not really a good UX either. This problem also leads to an incentive for implementations to implement an ever growing feature set (which is a problem we wanted to address here as well).
A solution to that problem could be [nomadic identities](https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101), where one person can have multiple actors spread over multiple instances. The actor(s) who does have the needed feature, will receive the invitation. That problem is somewhat related, but otherwise completely out of scope for this feature/discussion.
## References
[1]
```
# Pleroma
curl -s 'https://ilja.space/users/ilja' -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' | python3 -m json.tool
{
"capabilities": {
"acceptsChatMessages": true
},
...
}
# Smithereen
curl -s 'https://friends.grishka.me/grishka' -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' | python3 -m json.tool
{
"supportsFriendRequests": true,
...
}
# Nodeinfo
curl -s 'https://ilja.space/nodeinfo/2.1.json' | python3 -m json.tool
{
"metadata": {
"features": [
"pleroma_api",
"mastodon_api",
"mastodon_api_streaming",
"polls",
"pleroma_explicit_addressing",
"shareable_emoji_packs",
"multifetch",
"pleroma:api/v1/notifications:include_types_filter",
"chat",
"shout",
"relay",
"pleroma_emoji_reactions",
"pleroma_chat_messages"
],
...
},
...
}
```https://git.pleroma.social/pleroma/pleroma-meta/-/issues/60Backend translations2022-03-24T18:32:29ZtusooaBackend translationsProblem: backend-rendered pages are currently not translated. (For example:
https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/templates/twitter_api/remote_follow/follow.html.eex
https://git.pleroma.social/pleroma...Problem: backend-rendered pages are currently not translated. (For example:
https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/templates/twitter_api/remote_follow/follow.html.eex
https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/templates/o_auth/mfa/totp.html.eex
)
~~First, I think the current implementation in https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/web/gettext.ex is wrong, as Gettext is only aware of the locale set on the server machine, not what is requested by the user.~~ set_locale_plug.ex seems to do the job.
If we stick to gettext, we should use [with_locale/3](https://hexdocs.pm/gettext/Gettext.html#with_locale/3) and analyse the language from the http request.
- Frontend should set cookies whenever the user manually chooses a language. Then backend can read that cookie to detect language. Frontend and backend should use the same set of language codes.
> Locales are expressed as strings (like "en" or "fr"); they can be arbitrary strings as long as they match a directory name.
- If there is no corresponding cookie, read from the Accept-Language header, which should be the counterpart of `navigator.languages`.
- If there is no such header, fallback to the default locale set in the config file.
- If there is no such config entry, fallback to library default ("en").
Something else to consider:
- with_locale/3:
> This function just sets the Gettext locale for backend to locale before running fun and sets it back to its previous value afterwards.
Any concurrency issues with this?
- As far as I know, gettext does not have a fallback sequence for desired languages. However, both `navigator.languages` and `Accept-Language` allow choosing multiple languages. This problem arises because, for example, a user who chooses "Simplified Chinese" (zh-Hans) as their first preferred language may prefer "Traditional Chinese" (zh-Hant) over "English" (en). But in gettext if there is no translation in zh-Hans it will just fallback to the untranslated `msgid`.
As an alternative to gettext, I think [fluent](https://github.com/projectfluent/fluent) is a more satisfying solution, as it (at least the js implementation) solves the sequence problem.
There are a couple of elixir implementations in the wild:
- https://github.com/Virviil/libfluent (still does not support language sequences... and it seems to use rust)
- https://hex.pm/packages/fluent (unmaintained for years)
- gettext uses *untranslated string* as the identifiers. fluent and vue-i18n uses opaque codes as identifiers. Benefits of the former may be ease of testing (but this can be bypassed by not testing rendered strings). Benefits of the latter is you get finer control of what needs to be re-translated (if you fix a typo in the reference string, it apparently does not need retranslation, whereas if you use some text for different purposes, it may need retranslation even if the reference text is the same.)
- fluent (syntax) is also able to resolves some numerical cases. For example, if there are multiple numbers in a sentence (e.g. "1 out of 3"), the translated text may need to agree with both numbers. gettext and vue-i18n cannot do this without separating it into multiple entries.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/59Allow users to bring their own ActivityPub IDs, independent of server domain?2021-09-23T16:22:48ZRaphael LullisAllow users to bring their own ActivityPub IDs, independent of server domain?This question is the flip-side of #58. Would it be possible for users to bring their own identifiers (initially, let's talk about ENS but it can extend eventually to W3C DIDs) when signing up to a new pleroma server?
I am thinking of a ...This question is the flip-side of #58. Would it be possible for users to bring their own identifiers (initially, let's talk about ENS but it can extend eventually to W3C DIDs) when signing up to a new pleroma server?
I am thinking of a scenario where we could have larger servers that are less focused on the federation but more on generalized hosting for individual users who want to (a) own their identity and (b) be able to port to different providers. Think of it as "ActivityPub-As-A-Service".
I'm not an expert on ActivityPub, but it seems that the main challenge for this to work would be that servers would have to update their Webfinger/Salmon services in order to find the correct inbox URL for each user? What other challenges do you see?
I have almost zero experience with Elixir, but I'd more than willing to learn it to develop a working implementation for Pleroma.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/58Run Pleroma over ENS2021-09-23T13:15:11ZAlex GleasonRun Pleroma over ENSDomain names are integral to the design of the Fediverse, but DNS is also its existential threat due to being centrally controlled by the IANA.
[ENS](https://ens.domains/) is a blockchain domain system built from the ground-up in Ethere...Domain names are integral to the design of the Fediverse, but DNS is also its existential threat due to being centrally controlled by the IANA.
[ENS](https://ens.domains/) is a blockchain domain system built from the ground-up in Ethereum to potentially replace DNS in a censorship-resistant way.
So far, no ENS clients support traditional DNS records like A or CNAME. However, [ENS over Tor](https://medium.com/the-ethereum-name-service/ens-now-supports-tor-onion-address-resolution-9bb3bdff6217) is now possible. Pleroma [supports Tor](https://docs.pleroma.social/backend/configuration/onion_federation/).
The endgoal would be .eth ActivityPub IDs, but first I think it would be good to experiment with running an existing site over ENS while leaving its clearnet version alone.
### Running Pleroma over ENS
1. Register a name on [ENS](https://ens.domains/).
2. Enable [Tor on Pleroma](https://docs.pleroma.social/backend/configuration/onion_federation/).
3. Point your [ENS at Pleroma's onion address](https://medium.com/the-ethereum-name-service/ens-now-supports-tor-onion-address-resolution-9bb3bdff6217).
4. ??? does it work?
If this works, maybe federation over ENS is also possible.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/57Per-user upload limit / quota and media management2021-06-16T14:37:58ZHJPer-user upload limit / quota and media managementPeertube doesn't seem to have a limit on upload size, but it does have a per-user quota. This would be cool to implement in pleroma for instances that don't mind huge filesizes but don't want users to abuse the huge upload limit and give...Peertube doesn't seem to have a limit on upload size, but it does have a per-user quota. This would be cool to implement in pleroma for instances that don't mind huge filesizes but don't want users to abuse the huge upload limit and give admins more control on upload folder growth rate. However users should be able to manage their uploads, i.e. have ability to delete some old media in order to upload new.
What needs to be done is two parts, basically:
- API and UI (in PleromaFE) for managing user uploads and display the permitted quota
- User upload quota in BE
- Error to client when quota would be exceeded
- Option to set different quotas for specific users
- Option to set automatic quota increase for users
- I.e. do not allow huge uploads for new users, increase quota every month if usage is > N%https://git.pleroma.social/pleroma/pleroma-meta/-/issues/55Set up project donations2022-05-25T22:12:44Zrinpatchrin+pleroma@patch.cxSet up project donationsWith no more corporate sponsorhip starting next month now is the best time to set up donations to the Pleroma project. The money collected could be used to pay to active contributors (and incentivise quality contributions that way), pay ...With no more corporate sponsorhip starting next month now is the best time to set up donations to the Pleroma project. The money collected could be used to pay to active contributors (and incentivise quality contributions that way), pay for project infrastructure (which is now provided for free by MFC, but who knows what will happen to that) and for setting up a bug bountry programme to make Pleroma more secure.
I think the best platform to use for this purpose is [OpenCollective](https://opencollective.com). It is [open source](https://github.com/opencollective), designed for transparency and multi-contributor usage and has no lock-in (all data is [exportable](https://docs.opencollective.com/help/collectives/data-export) and we can [switch between different fiscal hosts](https://docs.opencollective.com/help/collectives/change-fiscal-host)/[create our own](https://docs.opencollective.com/help/fiscal-hosts/become-a-fiscal-host) if the fees or rules no longer are acceptable for us). I suggest reading [the documentation](https://docs.opencollective.com/help/) to understand how it works and if everyone agrees with using OpenCollective, we can proceed to choosing a fiscal host (Open Source collective vs Open Collective Europe).
cc @lambadalambda @lanodan @feld @hj @shpuldhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/54Combatting gitlab spam vs being approachable2022-05-15T08:49:08ZIljaCombatting gitlab spam vs being approachableSpam on the gitlab has been a problem for a while. Different things have been tried in the past to combat it, but combatting spam may have the effect of making pleroma less easy to approach for new people who want to contribute.
We've a...Spam on the gitlab has been a problem for a while. Different things have been tried in the past to combat it, but combatting spam may have the effect of making pleroma less easy to approach for new people who want to contribute.
We've already tried a honeypot, which didn't seem to have any effect[1]. I remember reCaptcha was turned on at some point. Now we ask people to ask an account on a dedicated chatroom. There's a link and a web interface, so I think this is about as easy as we can make it, but sometimes people don't get a response[2].
I don't really have an answer for this problem myself, but at least wanted to make sure this is known.
[1] <https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548#note_244919214>
[2]
![image](/uploads/2962cb0ecbac9f2b98d571d3cbf953e4/image.png)https://git.pleroma.social/pleroma/pleroma-meta/-/issues/52Setup a tool to verify consistency between streaming and non-streaming2021-01-22T09:45:33ZHJSetup a tool to verify consistency between streaming and non-streamingOne of the bugs that keeps on reappearing is when something is present in polling endpoints but doesn't arrive in streaming, making streaming mode unreliable. Biggest issue however that this very hard to detect because you can't see what...One of the bugs that keeps on reappearing is when something is present in polling endpoints but doesn't arrive in streaming, making streaming mode unreliable. Biggest issue however that this very hard to detect because you can't see what you're missing until you switch the client and actually notice the discrepancy (i.e. i noticed lack of muted users' posts in streaming only when i realized that gondola bot posts (whom i muted due to spam that one time) appear in husky but not in pleromafe).
We could make a minimal FE/Client that would monitor both streaming and polling APIs at the same time and notify the user when polled TL has data that wasn't present in streaming API and what missing status/notification is. We could also direct users to said tool if they notice the dropouts so that we can investigate easier.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/51Permanent Current Release Plan2021-01-20T19:06:53ZlainPermanent Current Release PlanThis issue is meant for constant planning of the current state of the next release. Looking it at should always give you the overview of what's happening and when the release is expected.
## General Rules
These rules are meant to ensure...This issue is meant for constant planning of the current state of the next release. Looking it at should always give you the overview of what's happening and when the release is expected.
## General Rules
These rules are meant to ensure a continuous stream of releases and to prevent dropping a lot of new features and changes on users. This will make debugging user issues easier and will prevent a too great divergence between our stable and development branches.
1. Patch releases are done as needed.
2. Feature releases are done every 8 weeks. A 'feature freeze' in the development branch for one or two weeks before release is suggested.
3. Delays in the feature release process don't delay the next release. That is, if a release is late by 2 weeks, the time to the next release will be 6 weeks.
4. Currently, @rinpatch and @lambadalambda are responsible for the release process.
## Upcoming release dates:
- 2.3 (2021-03-01) [Milestone MRs](https://git.pleroma.social/pleroma/pleroma/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=2.3.0), [Milestone Issues](https://git.pleroma.social/pleroma/pleroma/-/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=2.3.0)
- 2.4 (2021-04-26)
- 2.5 (2021-06-21)https://git.pleroma.social/pleroma/pleroma-meta/-/issues/50Fediverse Search2021-01-10T21:10:13ZAlex GleasonFediverse SearchI've been talking with @GORF about doing some contract work to improve search in Pleroma. Below are my thoughts on search, and some proposals for actions to take. I decided to share this publicly since it's an open-source project, and if...I've been talking with @GORF about doing some contract work to improve search in Pleroma. Below are my thoughts on search, and some proposals for actions to take. I decided to share this publicly since it's an open-source project, and if we take one of these paths we'll eventually want our changes merged upstreamed.
---
# Fediverse Search
Users join social media sites to blog, network, and fulfill the basic human need to socialize. For newcomers it can be difficult to find friends and discover content that pertains to their interests. Search is one way to improve discoverability. Search isn't just useful to new users, but also to veterans who are trying to find "that one post from 2 weeks ago" or look up current discussion around a particular topic.
The current search implementation has 2 major areas for improvement:
1. Content from outside your instance cannot be searched unless it has been federated.
2. Search is slow, limited to 20 results, and cannot be filtered.
Note: artificial intelligence is out of scope for now. Maybe in the future we can search for "cat pics" to show actual cat pictures, but for now we'll accept that results are literal.
## 1. Content from outside your instance cannot be searched unless it has been federated
The Fediverse is expansive, but your instance only knows part of it. Usually your instance only knows about people your users follow, and people those users boost. This impacts search, because users of an instance can only search for content known to the instance.
### Proposed solution: search providers
A search provider would be a separate piece of software whose job is to scrape the Fediverse and accumulate as much content as possible. The search provider could be self-hosted like any other free software. Pleroma could be configured to use an external search provider instead of its own database for search results.
It's important to keep the search provider a separate piece of software to not bloat the main Pleroma database, and so multiple servers could share the same search provider. It would implement a documented API so anyone could implement a search provider in any programming language, and other Fediverse backends could add support for search providers, too.
## 2. Search is slow, limited to 20 results, and cannot be filtered
Ignoring the pains of federation, once there *is* a lot of searchable content on an instance, the user experience is not very good. Search feels needlessly restrictive, limiting the results to a single page with no way to view more results. It's slow, and it's almost impossible to find "that one post from 2 weeks ago," much less follow a discussion.
### Proposed solution: a new search API
We'll design a new search interface that allows endless scrolling. We will support filtering posts by user, hashtag, date range, and instance domain. To support this interface we'll code new API endpoints into Pleroma BE.
## Proposals
So where do we go from here? Here are some possible plans.
### 120 hrs: Federated search
I'll implement search providers to allow searching the broader Fediverse.
- Develop (or adapt) a search provider implementation.
- Expose a documented API.
- Adapt Pleroma to incorporate search providers.
### 50 hrs: Basic endless scrolling search
I will design a new search UI with endless scrolling.
- Design a new interface.
- Develop an API endpoint for it in Pleroma.
- Adapt Soapbox FE to work with the new API.
### 60 hrs: Endless scrolling search with advanced filters
I will design a new search UI with endless scrolling and advanced filtering.
- Design a new interface.
- Develop an API endpoint for it in Pleroma.
- Add the ability to filter by username, hashtag, date range, and instance domain.
- Adapt Soapbox FE to work with the new API.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/49API fork2022-07-25T09:59:14ZHJAPI forkAs it was discussed in the IRC, we most likely want to fork MastoAPI into our own.
## Reasons:
- We would gain control over our own API and can change it the way **we** want, not just follow whatever Mastodon is doing.
- Adding more ex...As it was discussed in the IRC, we most likely want to fork MastoAPI into our own.
## Reasons:
- We would gain control over our own API and can change it the way **we** want, not just follow whatever Mastodon is doing.
- Adding more extensions will be much easier, since we won't claim compatibility with clients not explicitly supporting Pleroma
- We will still support vanilla MastoAPI (+ extensions) for mastodon and legacy clients
- Maintaining compatibility with older/newer versions of clients/FEs will be easier since we would be able to version our API
## How to do it (proposal):
Currently we have `/api/v1/` and `/api/v2/`, as well as `/api/pleroma/`. We should either make `/api/pleroma/v1` or start using version-requesting headers - see https://restfulapi.net/versioning/ . All mastoapi and pleroma endpoints should be copied there, like so:
* `/api/v1/search` -> `/api/pleroma/v1/search`
* `/api/v2/search` -> `/api/pleroma/v1/search-v2` - all v2 or newer endpoints should have a suffix instead of becoming v2 - remember, it is **our** version.
* `/api/pleroma/frontend_configurations` -> `/api/pleroma/v1/frontend_configurations`
* `/api/v1/streaming` -> `/api/pleroma/v1/streaming`
The point is - all existing API should remain more-or-less untouched. Adding new features or breaking behavior means we need to create v2 endpoint.
We don't have create `/pleroma/v1` immediately but instead create it when we want to make some change into existing API, i.e. consider existing API a "v0"
It doesn't necessary have to be `/pleroma/v1`, we can use `/pleroma-v1`, `/pv1` or anything else. To avoid confusion we should settle on one versioning method only, i.e. not mixing prefixing `/vN` and `accept-version: 1` header or such.
## Examples of application and profits:
Say we want to add *Deletes* into non-streaming API so that clients not supporting websockets (mobile) and PleromaFE in poll mode (either disabled by user or recovering from WS connection failure) can still receive deletes.
we copy `/api/v1/timelines/home` (and possibly others) into `/api/pleroma/v1/timelines/home`:
* New clients can switch to use new API and support deletes that way.
* Old clients are unaffected
* We don't have to test each and every client software in existence to see if it breaks because of it.
* We don't have to devise a way to extend existing API to make it compatible with everything.
## Additional thoughts
Supporting new API is cool, but it also means client software targeting it loses compatibility with older servers, and some developer would prefer to avoid that and would try to figure out if given server supports certain endpoints or not, we should provide an easy way of knowing which endpoints are available, i.e. additional field in `/api/v1/instance` or similar.
### Versioning entire API or just endpoints? Synchronize versions? Semver?
In general there doesn't seem to be much profit in versioning entire API - a lot of endpoints will be identical across versions anyway, versioning endpoints separately also doesn't always make sense since some endpoints are meant to be used together. I would suggest versioning endpoints separately but endpoints meant to be used together should all have matching versions, even if it means skipping a version (i.e. going v1 -> v3), it would sorta be a "version of a feature". I don't see much need for semver either since any number change already implies incompatibility, and i would just prefer using single number.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/48Set flat colour as background2021-01-19T15:01:13ZThorSet flat colour as backgroundInstance admins who want a flat colour instead of a background image in the UI are currently working around the issue by creating a 1x1 pixel image with the background colour they want, because clearing the background image in admin-fe s...Instance admins who want a flat colour instead of a background image in the UI are currently working around the issue by creating a 1x1 pixel image with the background colour they want, because clearing the background image in admin-fe simply replaces it with the bundled default background image. There needs to be an option to pick a flat colour instead. Posting to meta because it likely involves changes to the backend, frontend and admin system.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/47Feature request: archive posts2020-08-15T18:58:43Zpoopoo doodooFeature request: archive postsAbility to archive user's profile through the settings' data import/export page.Ability to archive user's profile through the settings' data import/export page.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/46Postgres extended statistics2020-09-10T22:28:43ZfeldPostgres extended statisticsI don't think this is actionable right now but from an architectural point of view we should consider the possibility of leveraging Postgres extended statistics on specific tables/columns. Maybe after the activity/object reunion this wou...I don't think this is actionable right now but from an architectural point of view we should consider the possibility of leveraging Postgres extended statistics on specific tables/columns. Maybe after the activity/object reunion this would make sense.
https://build.affinity.co/how-we-used-postgres-extended-statistics-to-achieve-a-3000x-speedup-ea93d3dcdc61https://git.pleroma.social/pleroma/pleroma-meta/-/issues/45Allow RSS following2020-10-05T16:11:38ZafAllow RSS followingI think this will be super useful. I suggest RSS to be treated as an account (that never performs any actions except posting), so that users can see how many followers it has, etc. So no or little effort would be required from the FE/cli...I think this will be super useful. I suggest RSS to be treated as an account (that never performs any actions except posting), so that users can see how many followers it has, etc. So no or little effort would be required from the FE/client side. Friendica supports this. Also with services like https://rsshub.app/ (not affiliated in any way) literally any service can be followed (bird site, youtube, scientific journal, you name it).
I don't know how much effort this can take, but I would be willing to give 50$ if this is implemented in pleroma.
Thanks.