pleroma-meta issueshttps://git.pleroma.social/pleroma/pleroma-meta/-/issues2020-07-29T18:53:13Zhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/44Postgres fill factor2020-07-29T18:53:13ZfeldPostgres fill factorLooks like we can get some performance wins by reducing random IOPS if we change the fillfactor on tables that will get UPDATEs. Basically, a fillfactor of 90 means that the table is only filled up 90% with INSERTs and leaves a 10% unuse...Looks like we can get some performance wins by reducing random IOPS if we change the fillfactor on tables that will get UPDATEs. Basically, a fillfactor of 90 means that the table is only filled up 90% with INSERTs and leaves a 10% unused gap for any modifications to the data so operations can stay sequential and changes don't spillover into new database files.
> This parameter cannot be set for TOAST tables
https://www.cybertec-postgresql.com/en/what-is-fillfactor-and-how-does-it-affect-postgresql-performance/https://git.pleroma.social/pleroma/pleroma-meta/-/issues/43Hosting hundreds of Pleroma servers for customers2020-07-24T03:29:24ZAlex GleasonHosting hundreds of Pleroma servers for customersHey all! This is a big post about my idea to launch a Pleroma hosting service. I have some strong big-picture ideas about marketing, and I genuinely believe this project can make a big difference. **What I'm missing is the infrastructure...Hey all! This is a big post about my idea to launch a Pleroma hosting service. I have some strong big-picture ideas about marketing, and I genuinely believe this project can make a big difference. **What I'm missing is the infrastructure.** I was hoping the community could help with ideas about the best way to approach this.
## How I got here
I've been working towards creating a fediverse hosting service for a while now. In fact, pretty much all the work I've been doing on Pleroma has been leading up to this. I started out working on Mastodon, but it quickly became clear that Pleroma would be a much more viable option for hosting thousands of small servers, due to its efficiency and scalability (ie it's WAY cheaper!)
So I've been working on [bringing over](https://gitlab.com/soapbox-pub/migrator) my existing Mastodon servers to Pleroma, including the [custom frontend](https://gitlab.com/soapbox-pub/soapbox-fe) and [donations platform](https://gitlab.com/soapbox-pub/patron). Now it's time to start implementing the actual hosting service.
## Why a hosting service
First off, I want to share some thoughts on why I think a hosting service would be valuable to Pleroma and the fediverse at large:
- **It will make it easier for people to join the fediverse.** This includes nontechnical people, but also technical people who are short on time.
- **A growth in users will result in people investing in the fediverse.** More time, more effort, more love and energy, more money.
- **It could create jobs.** It will bring money into a space that's sorely lacking it.
- **It's a new frontier.** I believe there's a demand for it, but it's been mostly unexplored.
**About the market:** [Masto.host](https://masto.host/) is already doing this. They manage 500+ fediverse servers and make up more than 10% of the entire fediverse. I think this demonstrates the clear demand for hosting, but I believe we can reach an even wider audience, and do it cheaper by using Pleroma.
## My idea: Tribes
![Screen_record_from_2020-07-12_14.16.15](/uploads/a0aec643675a7ae6ffe0186b0b6ae499/Screen_record_from_2020-07-12_14.16.15.gif)
My idea for a hosting service is called **Tribes**. I have a tiny demo with some marketing pages here: https://tribes-demo-1.surge.sh/
**Note:** The pricing is an estimate, and the content is subject to change. It's an AGPL-licensed Elixir/Phoenix app being developed in the open here: https://gitlab.com/tribes-host/tribes
Tribes is a way I think I can sell the fediverse to casual users. I am trying to present the fediverse using concepts people already understand. I will argue that people are naturally tribal, and it's better for social media to embrace that aspect of humanity than to try to force us all into one big box. I think this is more palatable than "it's a bunch of servers in a network sharing a protocol blah blah blah," and will give us the opportunity to bill this as a new social platform based on its own merits.
I want to go big with this project. I want to present a real challenge to Facebook and Twitter, but also to other social platforms like Gab and Parler, who are doomed to fail by repeating the same mistakes as centralized platforms. I want people to say: "Do you have a Tribe?" "Join my Tribe from the link in the description!" I have huge faith in the fediverse's potential and want to push it to its fullest.
## The challenge: how to deploy the servers
My vision for the Elixir app above is that it offers a dashboard to "one-click" deploy a Pleroma server. Under the hood I would need Elixir to invoke the creation of a new server, probably through an API or command line tool.
I can build the dashboard. That's not the problem. The issue is what goes on at the other end of it.
I looked into [Hetzner Cloud API](https://docs.hetzner.cloud/#servers). It looks very viable and easy to use. There's even already an Elixir library for it, [elixir-hcloud](https://github.com/Ahamtech/elixir-hcloud). The big concern I have with Hetzner is **deplatforming.** From their [TOS](https://www.hetzner.com/rechtliches/agb):
> 6.2 The client undertakes not to publish content that may violate the rights of third parties or otherwise violate the law. The placement of erotic, pornographic, extremist material **or material not deemed in good taste** is not permitted. We are entitled to block access to the account of any customer who violates this.
>
> The same applies in the event that the customer publishes content which is capable of violating the rights of individuals or groups of people, or that **insults or denigrates these people.** This applies even without an actual legal claim. We are not obligated to review our customers' content.
These terms are highly subjective. Being that **the fediverse is a social network, these terms will be nearly impossible to enforce** (nor would I want to enforce them). The main appeal of Hetzner is how crazy cheap it is, but if I invested a lot of effort into building a system around their Cloud API only to get deplatformed, that would be extremely difficult to come back from.
Most other hosting services have similar terms. DigitalOcean, for example, admits they'll deplatform based on a high number of complaints alone. The only "free speech" hosting out there (eg [1776hosting](https://1776hosting.com/) or [EPIK](https://www.epik.com/)) is **prohibitively expensive**. Like, WAY too expensive.
I have also thought about **purchasing my own servers** and setting them up in a datacenter. I would likely need to obtain large startup funds to achieve this, maybe through **crowdfunding**. I believe that crowdfunding is worth trying, but assuming it works out, I still need to answer some questions first: how would I invoke the creation of Pleroma servers? Would I install something like [OpenStack](https://www.openstack.org/software/)?
I'm willing to do whatever it takes to get this off the ground. I believe in my vision, but I have a lot of unanswered questions. I'm hoping the community can help guide me on the best path forward.
I was reluctant to share Tribes until I was further along, but it seems the advantages of sharing now outweigh the disadvantages. I could really use your feedback. That's the spirit of Pleroma and free software anyway, and as they say, "It takes a village to raise a child." Oh, also, "A dream you dream alone is only a dream. A dream you dream together is reality." - John Lennon. Okay, that's enough quotes for today. Please let me know what you think.
Thank you!https://git.pleroma.social/pleroma/pleroma-meta/-/issues/42Investigate MicroPub2020-07-02T15:37:49ZfeldInvestigate MicroPubI don't know anything about this but it sounds like something we could provide the metadata for so people can link posts/threads and have them embed nicely in a blog or other website.
https://boffosocko.com/2020/05/28/threadreaderapp-m...I don't know anything about this but it sounds like something we could provide the metadata for so people can link posts/threads and have them embed nicely in a blog or other website.
https://boffosocko.com/2020/05/28/threadreaderapp-micropub-to-blog/https://git.pleroma.social/pleroma/pleroma-meta/-/issues/41Future Chat improvements2022-08-05T06:06:33ZlainFuture Chat improvementsA general idea collection issue about the future of the chat system.
- [ ] Group chat: Depends on Groups
- [ ] E2EE chat: Can probably use the same CS api as mastodon. For thoughts on the UX, please read https://blog.soykaf.com/post/enc...A general idea collection issue about the future of the chat system.
- [ ] Group chat: Depends on Groups
- [ ] E2EE chat: Can probably use the same CS api as mastodon. For thoughts on the UX, please read https://blog.soykaf.com/post/encryption/
- [ ] Deleting chats: User might want to delete a whole chat, without having to delete each single post by hand
- [ ] Only-mutuals-mode: Allow chat only between people who are following each other. Might a server-wide or user-level setting
- [ ] Being able to see if a user can chat or not: This can be done by adding a property to the user, so once we refetch them, we know that they can receive chat messages. Thus we can only display the chat option with users where it is possible [https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2716]
- [ ] Polls in Chats (useful for groups)
- [ ] NSFW in Chatshttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/39A community voting system2020-05-23T17:15:03ZHécateA community voting system## Background
With the augmentation of Pleroma "casual" users (not power users, not admins),
the ratio of people being involved in the development to Pleroma users is
slowly but steadily decreasing, which is pretty normal.
However, we d...## Background
With the augmentation of Pleroma "casual" users (not power users, not admins),
the ratio of people being involved in the development to Pleroma users is
slowly but steadily decreasing, which is pretty normal.
However, we do not have an efficient way to gather demands and other suggestions
from the wider community, outside of Gitlab issues and IRC rants.
## Suggestion
My suggestion is to implement a model (loosely) based on the Swiss voting system:
Four dates per year during which the user base is asked to vote on features that
are not part of the roadmap. This would enable us to receive feedback on
those from people who use Pleroma while not being actively involved in its
development (which is bound to become the majority of the users).
## Discussion
I would like to discuss some adjacent points regarding this suggestion, especially
the means we have to advertise and regulate a vote
Indeed, the Pleroma user base seems more fragmented than the Mastodon one.
In the Mastodon community, the [#MastoAdmin](https://search.social/?q=%23MastoAdmin)
hashtag exists to discuss adminstration-related topics with their fellow admins.
I do not know of such a thing amongst Pleroma administrators, since many of them
use IRC to speak of such things.
My point here is that we should start creating privileged information feeds for
Pleroma administrators and users who care about their instance.
Please let me know if I forgot something.
Cheers!https://git.pleroma.social/pleroma/pleroma-meta/-/issues/38Making emoji fonts more accessible.2020-05-23T16:36:59ZHJMaking emoji fonts more accessible.# Steps
Step 1: fix bb-code and markdown
Step 2: fix emoji management and packs. Add emoji-font emoji pack support (see below)
Step 3: Add BB-code tag `[emoji font="..."]...[/emoji]`:
Tag should render `[emoji font="mario64"]lol[/emoji]...# Steps
Step 1: fix bb-code and markdown
Step 2: fix emoji management and packs. Add emoji-font emoji pack support (see below)
Step 3: Add BB-code tag `[emoji font="..."]...[/emoji]`:
Tag should render `[emoji font="mario64"]lol[/emoji]` into `<span data-type="emoji-font" role="figure" aria-label="lol">:mario64-l::mario64-o::mario64-l:</span>` and into `pleroma.content['text/plain']` as `lol`
Step 4: add similar thing `pleroma.content['text/plain']` to users and do same for user titles.
# Definition, implementation details
Emoji-font emoji pack specifies how emoji fonts should work:
* which characters are supported
* case sensitivity
* which case to use for plaintext version
* symbol conversion (i.e. translating cyrillic symbols)
* how emoji are formed, i.e. prefix
* future features?
Emoji-font pack should be just a special case of a regular emoji pack.
Error messages when emoji-font tag has illegal (unsupported) symbols to prevent mistakes, possibly with "override" function.
# Benefits:
* `arial-label` will make screen readers read the label "lol" instead of "colon mario sixty four dash ehl colon colon mario..."
* `text/plain` will allow FE to display notifications with proper text instead colon-colon-garbage. I'm looking at you, dielan.
* possibility for FE to strip emoji-font images and format them otherwise
* possibility to implement non-square emoji fonts or using spritesheets for emoji-fonts
* users who love to use emoji fonts will have an easier way of using them while not being obnoxious to everyone else
# Further ideas:
* parse existing statuses for emoji-font clusters and figure out their patterns to present them better?
* actually check how `aria-label` and `aria-description` work and what would be a better choice
* better attribute instead of `data-type`?
* separate emoji in emoji-fonts with ZWNBSP to prevent unnatural word-breaks?https://git.pleroma.social/pleroma/pleroma-meta/-/issues/37Tracking features of Federated instances2020-05-16T08:15:33ZfeldTracking features of Federated instancesWe may need to start tracking features of federated instances :sick:
Chat is going to land in Pleroma soon and clients will need a way to search for users that you can send a Chat message to otherwise people will not want to use a feat...We may need to start tracking features of federated instances :sick:
Chat is going to land in Pleroma soon and clients will need a way to search for users that you can send a Chat message to otherwise people will not want to use a feature where you cannot know if the other end is able to receive the message. This is just one example of many things that are probably coming down the pipe in the future, like knowing if you can do a voice/video call with a user (if we ever integrate that).https://git.pleroma.social/pleroma/pleroma-meta/-/issues/36JSON representation of emoji packs is inconsistent2020-04-14T15:18:44ZHaelwennJSON representation of emoji packs is inconsistentWhile writing a spec for the emoji pack format I found two representation for basically the same data.
Stuff like what we have at https://git.pleroma.social/pleroma/emoji-index/ will give it in this kind of format:
```json
{
"finmoj...While writing a spec for the emoji pack format I found two representation for basically the same data.
Stuff like what we have at https://git.pleroma.social/pleroma/emoji-index/ will give it in this kind of format:
```json
{
"finmoji": {
"license": "CC BY-NC-ND 4.0",
"homepage": "https://finland.fi/emoji/",
"description": "Finland is the first country in the world to publish its own set of country themed emojis. The Finland emoji collection contains 56 tongue-in-cheek emotions, which were created to explain some hard-to-describe Finnish emotions, Finnish words and customs.",
"src": "https://finland.fi/wp-content/uploads/2017/06/finland-emojis.zip",
"src_sha256": "2C1374795AA23C032B2E9ED68C695A0452BCBB13F77DB90E883E1233ACAD2DA5",
"files": "finmoji.json"
},
…
}
```
While `/api/pleroma/emoji/packs` will give it in this kind of format:
```json
{
"chronemotes_4": {
"files": {
"bpwant": "bpwant.png",
"sopmodjam": "sopmodjam.gif",
"kazumapft": "kazumapft.png",
"meguminpensive": "meguminpensive.png",
"sopmodexcite": "sopmodexcite.gif",
"aquadrunk": "aquadrunk.png",
…
},
"pack": {
"can-download": true,
"description": "Emojis from Discord server Chronemotes 4",
"download-sha256": "628ECF4EBE116F68D2DF3408A133928BC7509EAAE01CD0CA53821A6FE40220AF",
"homepage": "https://example.org",
"license": "Unknown",
"share-files": true
}
},
…
}
```
Main difference being that the API puts the metadata fields other than files in the `"pack"` field and key names are dash-joined (kebab casing?) while the `index.json` puts the metadata fields directly and key names are in snake_case.https://git.pleroma.social/pleroma/pleroma-meta/-/issues/34Design API for storing FE settings2022-07-17T04:00:49ZfeldDesign API for storing FE settingsWhat would an ideal API look like for storing FE settings in the database?
I'm thinking we want to achieve the following:
* PATCH for partial updates. New FE settings would be lost when using older FE if every save replaced all data
* ...What would an ideal API look like for storing FE settings in the database?
I'm thinking we want to achieve the following:
* PATCH for partial updates. New FE settings would be lost when using older FE if every save replaced all data
* JSON, keyed on software name so various FEs can utilize it and obtain consistency
* subkeyed for profiles? This would allow the power users to create named profiles so they could keep their desired settings. Also allows you to easily switch to maybe a "public" mode where you add more keyword filters, enable NSFW cover, etc.
Would love to hear your thoughts @hj @shpuldhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/33Performance Improvements2020-06-26T13:27:01ZlainPerformance ImprovementsThis issue is meant to contain general discussions relating to performance, and then to track performance issues and planned improvements.
- [x] Improving performance of the timelines by fetching all user relations at once (https://git....This issue is meant to contain general discussions relating to performance, and then to track performance issues and planned improvements.
- [x] Improving performance of the timelines by fetching all user relations at once (https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2323)
- [x] BE: control over user relationship extensions in statuses (https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2342)
- [x] FE: remove the need for the user relation extensions in statuses. These are only used by PleromaFE and slow things down a lot (https://git.pleroma.social/pleroma/pleroma-fe/-/issues/819)
- [ ] Speed up fetching of posts in PleromaFE. Currently, it seems to wait for some unrelated endpoints to return first. Might even be possible to do it right at the start without waiting for the config.json to return. (No issue yet) https://git.pleroma.social/pleroma/pleroma-fe/-/issues/817
- [ ] Pre-fill index.html with relevant json for user timelines so the first call to the account and the account statuses can be skipped. https://git.pleroma.social/pleroma/pleroma-fe/-/issues/818https://git.pleroma.social/pleroma/pleroma-meta/-/issues/32TeX in posts2020-03-23T06:17:32ZabsturztaubeTeX in postsI played around with MathJAX and KaTeX the last couple of days to see if i can get some sort of TeX support mainly for displaying formulas (haven't looked at anything else).
I have kinda implemented a working (but somewhat hacky) versio...I played around with MathJAX and KaTeX the last couple of days to see if i can get some sort of TeX support mainly for displaying formulas (haven't looked at anything else).
I have kinda implemented a working (but somewhat hacky) version with https://katex.org/ for [pleroma-fe](https://git.pleroma.social/absturztaube/pleroma-fe/-/tree/feature/formulas). Tested it with chromium, qutebrowser and firefox and it seems to work on all three of them.
it turns posts like this
![Screenshot_from_2020-03-22_22-33-38](/uploads/41b02c29476c823c6c4d6a749a9d0c85/Screenshot_from_2020-03-22_22-33-38.png)
into this
![Screenshot_from_2020-03-22_22-02-45](/uploads/8a2f709374c7f21d9b9fe503528e383c/Screenshot_from_2020-03-22_22-02-45.png)
What are your thoughts on this?https://git.pleroma.social/pleroma/pleroma-meta/-/issues/28Add the /me functionality similar to the IRC/XMPP one2020-03-11T15:17:29ZEchedey López RomeroAdd the /me functionality similar to the IRC/XMPP oneAs suggested by the title, the idea is to add the /me command like in IRC/XMPP, which references to the same person in a post. This is that its just exchanged by the alias (or the public name better) of the person who write it.
If I put...As suggested by the title, the idea is to add the /me command like in IRC/XMPP, which references to the same person in a post. This is that its just exchanged by the alias (or the public name better) of the person who write it.
If I put /me on a post and my public name is Echedenyan, when I send the post, it could be great that /me is exchanged by Echedenyan.
I don't know how this thing could federate itself but I thought on being made at client side.
If its exchanged just in the moment that the post is processed before being sent to the Fedi I think it should appear as any other post. If its not possible, just that the front-end exchange /me from the beginning of a post by the public name with a link (maybe) to the user reference in that instance.
When I say "user reference" I mean the cached (or whatever) version of a profile that is given to an user from an external instance. Here I am fedi.absturztau.be/ELR and in other could be whatever.hi/users/wjqiuwhduwhdiuqhiudh.
An example of the idea on a post could be:
1. /me writes this post.
2. [Echedenyan](https://fedi.absturztau.be/ELR) writes this post (or) [@ELR](https://fedi.absturztau.be/ELR) writes this post. (This is for the current instance)
3. [Echedenyan](https://kitsune.cafe/users/9mUk0RibSZMZ0xmO2q) writes this post (or) [@ELR](https://kitsune.cafe/users/9mUk0RibSZMZ0xmO2q) writes this post. (This is for other instance. In this case, kitsune.cafe)https://git.pleroma.social/pleroma/pleroma-meta/-/issues/27Events rendering2020-02-29T11:40:01ZHaelwennEvents renderingCurrently we end up dropping at least the Event start time and location in the API. (at least it is better than Mastodon which literally just puts the URL, which doesn't makes me very hopeful for a good MastoAPI)
I guess we could:
- jus...Currently we end up dropping at least the Event start time and location in the API. (at least it is better than Mastodon which literally just puts the URL, which doesn't makes me very hopeful for a good MastoAPI)
I guess we could:
- just append `Time: #{startTime}-#{endTime}` and `Location: <a href=geo:#{coordinates}>#{name}</a>` into the status's text
- Add `startTime`, `endTime`, and `location` into `pleroma` namespace and hope most clients will support it.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/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/24[FR] forward/repeat to specified user(s).2020-01-13T00:30:31ZITwrx[FR] forward/repeat to specified user(s).it would be nice if we could repeat, but only to specified users.
I created https://git.pleroma.social/pleroma/pleroma-fe/issues/752 too.
thanksit would be nice if we could repeat, but only to specified users.
I created https://git.pleroma.social/pleroma/pleroma-fe/issues/752 too.
thankshttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/23Quote Posts2021-11-13T10:40:36ZGhost UserQuote PostsSo I'm not sure where to ask but I want to get involved somewhat with Pleroma and see where I'm comfortable contributing. I asked on Mastodon's GitHub about quoting posts (https://github.com/tootsuite/mastodon/issues/12753) although peop...So I'm not sure where to ask but I want to get involved somewhat with Pleroma and see where I'm comfortable contributing. I asked on Mastodon's GitHub about quoting posts (https://github.com/tootsuite/mastodon/issues/12753) although people seem pretty adverse to adding official support despite it being easy to do already (link previews make it merely a formality). Not sure how Pleroma developers feel about adding such a change to the project and wanted to start the discussion here.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/20Get benchmark database on its own hardware2020-05-26T22:07:51ZfeldGet benchmark database on its own hardwareWorking on getting benchmark database onto its own hardware. Problem is that default postgresql.conf settings such as that in the Docker container will have the following:
```
shared_buffers = 128MB
work_mem = 4MB
maintenance_work_mem =...Working on getting benchmark database onto its own hardware. Problem is that default postgresql.conf settings such as that in the Docker container will have the following:
```
shared_buffers = 128MB
work_mem = 4MB
maintenance_work_mem = 64MB
```
There are other settings worth considering, but these are most likely to cause us pain during the benchmark runs. Without a large enough `shared_buffers` we are going to be punished by excessive I/O to handle the benchmark data, and the small `work_mem` means our queries with any kind of ordering or sorting are probably going to fail to fit within that size constraint so we will once again be doing excessive I/O via temp tables on disk.
tables sorted by size captured during a benchmark run:
```
relation | total_size
----------------------------------------------------------+------------
public.oban_jobs | 909 MB
public.activities | 234 MB
public.objects | 218 MB
public.users | 36 MB
public.notifications | 23 MB
public.conversations | 2728 kB
public.oban_beats | 1024 kB
public.conversation_participation_recipient_ships | 904 kB
public.conversation_participations | 744 kB
public.instances | 56 kB
public.config | 56 kB
public.following_relationships | 56 kB
public.oauth_tokens | 48 kB
public.apps | 48 kB
public.lists | 40 kB
public.moderation_log | 40 kB
public.scheduled_activities | 32 kB
public.user_invite_tokens | 32 kB
public.registrations | 32 kB
public.filters | 32 kB
public.deliveries | 24 kB
public.push_subscriptions | 24 kB
public.schema_migrations | 24 kB
public.markers | 24 kB
public.oauth_authorizations | 16 kB
public.bookmarks | 16 kB
public.thread_mutes | 16 kB
public.user_relationships | 16 kB
public.markers_id_seq | 8192 bytes
public.user_relationships_id_seq | 8192 bytes
public.password_reset_tokens_id_seq | 8192 bytes
public.password_reset_tokens | 8192 bytes
public.lists_id_seq | 8192 bytes
public.user_invite_tokens_id_seq | 8192 bytes
public.filters_id_seq | 8192 bytes
public.push_subscriptions_id_seq | 8192 bytes
public.users_id_seq | 8192 bytes
public.activities_id_seq | 8192 bytes
public.objects_id_seq | 8192 bytes
public.apps_id_seq | 8192 bytes
public.oauth_authorizations_id_seq | 8192 bytes
public.oauth_tokens_id_seq | 8192 bytes
public.notifications_id_seq | 8192 bytes
public.instances_id_seq | 8192 bytes
public.thread_mutes_id_seq | 8192 bytes
public.scheduled_activities_id_seq | 8192 bytes
public.activity_expirations | 8192 bytes
public.conversations_id_seq | 8192 bytes
public.conversation_participations_id_seq | 8192 bytes
public.bookmarks_id_seq | 8192 bytes
public.config_id_seq | 8192 bytes
public.activity_expirations_id_seq | 8192 bytes
public.oban_jobs_id_seq | 8192 bytes
public.deliveries_id_seq | 8192 bytes
public.conversation_participation_recipient_ships_id_seq | 8192 bytes
public.moderation_log_id_seq | 8192 bytes
public.following_relationships_id_seq | 8192 bytes
(57 rows)
```
Sure, we could change these for the docker container we prop up for the job but there's still other stuff running on that server which can interfere with the test results: backup jobs, orchestration tool kicking in occasionally to make sure the server is configured as expected, tons of additional processes that will wake up. Not to mention that the results of our different CI servers cannot be compared directly for query performance.
So this is why we will be moving benchmarks to a dedicated database server where we can compare results with confidence.feldfeldhttps://git.pleroma.social/pleroma/pleroma-meta/-/issues/19OpenAPI / Swagger2020-04-16T11:07:40ZGhost UserOpenAPI / Swaggerjust wanted to bump this general theme, and connect some extra dots across other AP-software, since any other projects will have to keep compatibility with at least those three:
pleroma: https://git.pleroma.social/pleroma/pleroma/issue...just wanted to bump this general theme, and connect some extra dots across other AP-software, since any other projects will have to keep compatibility with at least those three:
pleroma: https://git.pleroma.social/pleroma/pleroma/issues/559
mastodon: https://github.com/tootsuite/mastodon/issues/1404
misskey: https://github.com/syuilo/misskey/pull/4351minibikiniminibikini