pleroma-meta issueshttps://git.pleroma.social/pleroma/pleroma-meta/-/issues2022-05-25T22:12:44Zhttps://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/1Fediverse protocol for browsers to handle to enable seemless reply / follow /...2020-03-21T14:36:25ZlainFediverse protocol for browsers to handle to enable seemless reply / follow / fav etc.Currently, reacting to posts on other sites is rather annoyingly hard. Following somebody on a remote instance is very involved as well.
One solution to this is to add a protocol and corresponding protocol handler, so that an app can re...Currently, reacting to posts on other sites is rather annoyingly hard. Following somebody on a remote instance is very involved as well.
One solution to this is to add a protocol and corresponding protocol handler, so that an app can register to handle certain links and actions. Mastodon implemented something like this before, so this could be used as a starting point.
Things this could / should handle:
- Following
- Favouriting
- Announcing (Repeating)
- Replying
- Voting
Documentation of the mechanism:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
Mastodon's previous work on this, using a 'web+mastodon' protocol name. Supports following and posting (called 'sharing'). An example URL: `web+mastodon://follow?uri=acct:gargron@mastodon.social`
https://github.com/tootsuite/mastodon/pull/4511https://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/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/25Hashtag Federation2020-02-14T16:29:49ZfeldHashtag FederationAt FOSDEM we had a good conversation about hashtag federation. Here's a dump of my notes regarding centralized service and DHT based approach
**Centralized:**
* Treat hashtag federation like subscribing to a relay
* Relays send all A...At FOSDEM we had a good conversation about hashtag federation. Here's a dump of my notes regarding centralized service and DHT based approach
**Centralized:**
* Treat hashtag federation like subscribing to a relay
* Relays send all AP messages right now
* New posts are always created with a Note
* We could support subscribing to an actor just like a relay, `https://aggregator.com/tags/hashtag`
* We could also use localhost service to do a relay proxy(?) for us, and then be able to plug in DHT later when that's fleshed out
**Decentralized:**
* Localhost service would provide DHT capabilities
* Actor would be `https://localhost/tags/hashtagname`
* Announce DHT capability with `nodeinfo`https://git.pleroma.social/pleroma/pleroma-meta/-/issues/22Stop accepting nicknames or ids in /api/v1/accounts/:id2021-12-31T19:50:37Zrinpatchrin+pleroma@patch.cxStop accepting nicknames or ids in /api/v1/accounts/:idAlthough this is less of a problem on instances with flake ids, older instances have cases where there is both a user with nickname being equal to the requested string and an id being equal to the requested string, resulting in a wrong a...Although this is less of a problem on instances with flake ids, older instances have cases where there is both a user with nickname being equal to the requested string and an id being equal to the requested string, resulting in a wrong account being displayed at the url (For example you would expect https://kawen.space/314 to display `@314@kawen.space`, but it displays `@TheKinrar@mastodon.xyz` instead). I propose fixing this by stopping to accept nicknames in `/api/v1/accounts/:id` and making a separate endpoint for requesting a user by their nickname `/api/v1/accounts_by_nickname/:nickname`.
Things needed:
* [ ] Implement `/api/v1/accounts_by_nickname/:nickname`
* [ ] Advertise `https://instance.social/:nickname` in the `url` property of actors, this will make the external links lead to it.
* [ ] Make the FE use **only** `/api/v1/accounts_by_nickname/:nickname` when resolving a user at `/:nickname`
* [ ] Make the FE use a different route for remote users that are addressed by id (i.e `/accounts/`) . The problem with changing `/users/` to be id-only is that our AP ids are `/users/:nickname`, so visiting an AP id in-browser will not work, which is undesirable because some implementations don't honor `url`.
* [ ] Remove nickname support from `/api/v1/accounts/:id`
cc @lambadalambda @lanodan @hj @shpuldhttps://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/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/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/40Future UI/UX2020-06-04T13:18:24ZlainFuture UI/UXThis is more of discussion forum than an issue.
The current UI/UX of Pleroma has evolved over time from a simplified clone of the Qvitter UI to a complexified clone of the Qvitter UI. Lots of idiosyncrasies stem from this history, beca...This is more of discussion forum than an issue.
The current UI/UX of Pleroma has evolved over time from a simplified clone of the Qvitter UI to a complexified clone of the Qvitter UI. Lots of idiosyncrasies stem from this history, because features were implemented either because Qvitter did it like that or 'it was the easiest' at time.
Things that come to mind:
- Visiting a thread page by clicking on the time, expanding the thread by clicking on +
- Clicking on a user avatar in a post expands the user card, but clicking on it in the card goes to the user page. Clicking on the user name always goes to the user page and never opens the card.
- Settings, settings, settings. Split between two different pages.
- Posting is 'silent': Except for the new post appearing, there's no visual feedback that something really happened.
- and so on... (feel free to add more examples)
All of these were created for good reasons. For example, the card allows you to quickly follow / unfollow a user without leaving the current context. The settings are split between profile editing and the rest. Still, these are often interactions that no other software than pleroma has, and many new users struggle with them because there's no way to find out how to use Pleroma without clicking around everywhere. I've seen people close to giving up on the 'unusable' frontend until someone pointed them to some of the basic features like thread expansion. I wonder how many people we are losing immediately because they just can't figure anything out.
Attached is the UI/UX sketch that @sheueyen / ida on IRC has done, as an example of a different look and feel. I think it's a good look at the system from an outsider / new user who is familiar with UX questions. Not all interactions are sketched here, just a general look-and-feel.
![Pleroma-Preview_AllArtboards](/uploads/09e674408b5b78479480bb2064c34909/Pleroma-Preview_AllArtboards.png)https://git.pleroma.social/pleroma/pleroma-meta/-/issues/26List of unicode emojis2022-11-29T03:00:16ZHaelwennList of unicode emojisBeen thinking about it a bit, I think we should have something like this as a format:
```json
{
"smug": "😏",
"smirk": "😏",
…
}
```
Originally thought about using the unicode representation as a key but I guess this would be hard f...Been thinking about it a bit, I think we should have something like this as a format:
```json
{
"smug": "😏",
"smirk": "😏",
…
}
```
Originally thought about using the unicode representation as a key but I guess this would be hard for clients to traverse for text-entry suggestions. What do you think? @shpuld @hj @lambadalambda @feld @rinpatch https://git.pleroma.social/pleroma/pleroma-meta/-/issues/17Sign release tags and OTP releases2019-11-26T15:30:29ZewafSign release tags and OTP releasesI think it's a good idea to sign release tags and OTP releases. There is no reason not to do it, it just makes Pleroma more secure, because users can verify themselves that the source code they are using has not been tampered with. I'm a...I think it's a good idea to sign release tags and OTP releases. There is no reason not to do it, it just makes Pleroma more secure, because users can verify themselves that the source code they are using has not been tampered with. I'm a bit disappointed that you are not doing this yet.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/11Official Pleroma account, both on Pleroma and Twitter2019-11-06T00:45:32ZMew MewOfficial Pleroma account, both on Pleroma and TwitterMastodon has an official Twitter account which has had significant success dispelling misinformation about the project and generating hype around releases.
Pleroma having a similar account could achieve the same purposes and we could ev...Mastodon has an official Twitter account which has had significant success dispelling misinformation about the project and generating hype around releases.
Pleroma having a similar account could achieve the same purposes and we could even possibly work together with Mastodon to counter misinformation about the Fediverse on Twitter that keeps people from joining.
A Pleroma account on Pleroma (maybe ins.pleroma.social with closed registrations) would be good for generating hype around Pleroma releases while avoiding endorsing an official instance as has happened previously (with people conflating pleroma.site and pleroma.soykaf.com with Pleroma).https://git.pleroma.social/pleroma/pleroma-meta/-/issues/5Stories - Highlighted ephemeral posts2022-07-31T12:58:55ZlainStories - Highlighted ephemeral posts"Stories" are a way to post highlighted ephemeral posts, usually with a picture or more, or a video. These are often used to post about something interesting that happened that day, that you want to highlight to your followers.
The most..."Stories" are a way to post highlighted ephemeral posts, usually with a picture or more, or a video. These are often used to post about something interesting that happened that day, that you want to highlight to your followers.
The most important implementation is in Instagram, but many other social media platforms implement the same feature and usually also call it "Story". The feature originated in Snapchat.
General behavior:
- Ephemeral, deletes after 24 hours.
- Attachments are the most important part of the post.
- Stories are displayed similarly to pinned posts, in a preferred way, so that followers are more likely to see them.
- Generally, when displaying them, the photos that are part of a story are displayed like an automatic slideshow, so that you can 'watch' a story.
Backend considerations:
- Should use a new Story:litepub type. While it can be somewhat emulated with pinned posts, unlisted + expiration, it really is a different usecase than normal posts and should be treated as such.
- Pleroma-Api should be extended to support creating Stories and to get the Stories of your friends, possibly together with Mastodon to coordinate changes.
- Stories should keep track if a user has viewed them or not.
Frontend considerations:
- Maybe out of scope for PleromaFE altogether?
- Stories work best in a mobile context.
- Otherwise see 'general behavior' above.
cc @dansup @shpuld @hjhttps://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/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/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.