@lain - AkkoFE is serviceable, but especially on mobile quite difficult to use due to small buttons. a new mobile-first FE would be neat! - when mentioning users with @ I want the people I interact with most mentioned first. when I enter (at)la, I don't want Latinix@randominstance. I want the current account to be first, not the account the person used last century. - I'd like some indication when I cannot contact a user, when the message transfer fails. could there be delivered marks for direct messages like Signal?
@lain the database is sad to think about, the backend is a mess no one wants to touch, federation and transparency/discovery is out of vogue, and the network still reeks of mastodon
@lain When Pleroma hit the scene, one of its main selling points was how lightweight it was. I feel that with subsequent major releases it has gotten heavier and more unwieldly.
Perhaps it's time Pleroma shed some weight. Remove unfinished code paths or simplify existing ones. I have expressed interest in improving the front-end, specifically the admin dashboard, but it's too convoluted for me to get started.
I refrain from mentioning the limitations of the AP protocol, such as the lack of groups facilitation, as it's a meta meme at this point.
@lain FE is a bit too heavy on old phone so I'm reliant on Husky as only performant phone app for it, and Husky has no good emoji react support. (This is probably not something you can do anything about.)
I've regularly heard complaints about the admin side of stuff and how hard it is to do things (specifically acting on and dealing with individual reports).
Something going viral and notifications is a sad combination.
@lain@lain.com it let's you "listen" to posts. you can specify how and what to filter for, and you then get a separate antenna timeline. for instance i have an antenna for yew that includes terms related to yew and then gives me all posts mentioning it, from users i follow or not alike.
@lain Lack of Release Candidates for testing before release. There's basically no public communication when a release is going to happen besides maybe a post from one of the maintainers that's easy to miss. Currently those who run develop to catch bugs have no idea when to merge upstream besides checking the commit history every few weeks and guessing.
The whole 2.7.0 Oban blowing up and follows refusing to work 90% of the time debacle could have been prevented by it, if enough instances admins actually knew when to test stuff.
@i@lain@dwaltiz@jra Elastic isn't even merged as far as I know. I've fixed meili but didn't account for updating indexes on post edits, and it pinned cores at 100% and raped my SSD lifespan anyway.
@dwaltiz@lain@jra the postgresql implementation is definitely trash no matter if it's rum'd or not, and doing four different searches in one query is weird, but at least search is the only thing you can run a different backend for, as expensive as meili/elastic search are
@lain The regressions introduced in new releases which do something weird like use some more ram for some reason. Having run Pleroma alongside other fedi software on another persons machine they complain my Pleroma uses the most ram on their system. It's weird to see.
@scathach@lain I think they go completely against the original point of the network as a microblogging network for people to find stuff and talk with random people, and has further fragmented everything into little niches and broken timelines and "you need to follow 6000 people with penis cage symbol accounts or you can't see half the timeline"
@lain I use the RIA on my phone and sometimes I have to close and relaunch it to get my notifs and timelines to refresh but I could probably just be using husky or whatever I guess
@lain@scathach On the new implementation (which pleroma uses) yes, in the original implementation (statusnet) they were separate from regular posts, they didn't work across instances but they were more secure within the same instance.
@lain I'm mostly quite happy with Pleroma, I only have a few things I wish were different:
- Search function is basically useless, no way to search my own posts - No good way to browse historical posts, something like a by month/year calendar view like wordpress and livejournal blogs have would be really sweet - /bookmarks endpoint is very slow and tends to time out for some reason, though this might be more of a stereophonic issue - Account archive is missing quite a lot of information
@feld@thatbrickster that was one of the reasons I posted this question, my instances run hands-off on small systems without any issues, so I wanted to see if hat other people’s experience is
@thatbrickster@lain man I don't get it. I run it on the slowest "server" and it is still so capable and fast. Subscribed to tons of relays, tens of gigabytes for the database, millions of posts, only 4GB of ram and 4 basically celeron cores
@hj@lain@yew@lebronjames75 we just need to rewrite the query to use search ranking: friends highest, next best matches weighted by most recent activity date maybe (it's already tracked in the users table)
@dwaltiz@lain searching from an app gives you better results than in PleromaFE. I don't know why, it's something to do with the query parameters PleromaFE uses by default
@lain@feld@thatbrickster It's because you aren't running them on a $5 shitbox from $insert_cheap_host. 4 cores and 4 GB of RAM is probably more resources than half of the instances.
You can run on those garbage tier VMs, but it needs a little bit of hand holding every few weeks after the first few months. And it doesn't help that these configurations are in the Postgres docs.
@lain@feld@thatbrickster I would say that 1 core and 2GB RAM (with ~2GB swap) is the minimum that is still usable and not in the absolute jank territory. I used to run this instance on that for two years and it did mostly hold up, but I spent probably a few hours configuring Postgres, and opening two different threads in different tabs at the same time would kill it in the end.
@feld@lain@thatbrickster netusphäre used to be really slow because we ran off of shitty networked storage and i think that's common when using hetzner. Maybe the install.instructions should have a big fat disclaimer for that like goto social
@lain@feld@thatbrickster I would remove the 1GB example, put a note on the 2GB one that it is the minimum requirement for single-user instances only and may need additional optimizations in the future, and add a 1 core 4GB, or 2 core 4GB example.
@phnt@feld@lain@thatbrickster biggest concern and should be mentioned to NOT to use database on Rpi at all cost. People be like "Pleroma is lightweight" and then proceed to install PostgreSQL on same shit hardware.
@hj@lain@Cocoa Probably better than most hacks considered neat by current frontend people. It's just somewhat out of fashion to pull frames in instead of a megabyte of JS to do the same thing and fail to free up ressources.
@lanodan@lain@Cocoa@hj time to su🇧mit some <div>'s and some quirky and unreadable calc() css pseudo-scripts. i hope hj from shiggy sue gooboo club likes them. 😇
@feld My comments were more to do with the front-end as I have more experience using it. I have also run local instances of it. The longer it runs, the jankier it gets in a browser.
The only things I could say about the back-end is database bloat and the self-resolving(?) errors I see every now and then, whether it's network related or '<!DOCTYPE isn't valid HTML' or 'invalid token/char' or something else.
@i@phnt@lain my complaint is I feel like for a while, or maybe the entire time lain discounts what I say because of poast. Feld ran a secondary instance that federated with poast but decided to defederate us on that instance too. the discussion i had with him was productive but i feel like nobody upstream wants to deal with us.
in any event:
we are in the middle of a security audit for current dev branch (62993871). periodically poast pays or has third parties audit the code we're using since the 0day in may 2023 and there is one we will submit issues or fixes for if they arise in the next couple weeks
@phnt@lain would have helped if security issues weren't the only reason those releases were made in the first place, usually it's not enough to report them either way until someone like misskey says to fix it or get bent
@hj@phnt@feld@lain@thatbrickster a fio baseline would probably help too, even high spec vps tend to come with poor iops, and that has people reinventing optane on top of even slower slab volumes once a vacuum would put them over their allotment
a couple of real ssd's in raid on a physical machine will obviously run fine for much longer
@lain 0. 💚 :lainBear: 💚, so please don't take anything personally.
Not being able to separately load the different kinds of notifications. If I mark many accounts for notifications, in order to load all posts directed at me and/or likes I got and/or other sorts of reactions or whatever from other people, I have to load many general posts from accounts I had subscribed to, which takes a bunch of time.
Another thing is not being able to subscribe to specific tags. I love reading the #books stuff, for example, which I did on the https://emacs.ch/† Mastodon instance. I could just look that up in the search, but that is different from subscribing to tags on Mastodon in some important way, but I don't remember how.
Another another thing is the limitedness of the search. Being able to search within specific people's timelines, specifying time ranges, specific type of posts, existence and maybe kinds of attachments, stuff like that, would be very useful.
@hj@lain@lebronjames75@yew hey, turns out we already have 99% of this in place already! I'm looking at it right now, but the problem is that there's clearly a bug somewhere with the ranking...
> The whole 2.7.0 Oban blowing up and follows refusing to work 90% of the time debacle could have been prevented by it, if enough instances admins actually knew when to test stuff.
I'm going to push back on this again, for like the millionth time.
Follow bug -- this existed in the code for YEARS. It was not a single release that caused it.
Oban bug -- very few people experienced this. Nobody on the team was able to reproduce it. People who had the issue were refusing to give us root to go and look deeper at what was happening. Turns out, it wasn't even an Oban bug in the first place! While hunting for the issue we did find another problem in Oban, but all along it was a Postgrex bug which exposed another Oban bug. We didn't even upgrade or change Postgrex. It was just lurking there, waiting for someone to hit the edge case.
That edge case: server was too overloaded, too poorly configured, etc causing the Postgres connection to fail and Postgrex was not reconnecting. So the connection Oban was using for NOTIFY would just stop working.
Personally I'd rather see us have a "release early, release often" approach than some kind of long QA process, because QA releases would not have helped here.
@feld@lain >Personally I'd rather see us have a "release early, release often" approach than some kind of long QA process, because QA releases would not have helped here.
While I do agree that faster releases would definitely be better than the current pace, but you also have to take into account that there are still instances running 2.5.X and 2.6.X managed by people that are hesitant to upgrade because of previous bugs. There aren't many of those people, but the overall feeling is still "I'll wait for a few months and let others test it for me before I upgrade."
I'm not saying do an RC and wait a month or two for it to cook probably with barely any activity in the tracker. Pleroma isn't Mastodon. I'm talking about doing an RC, waiting a week or two to see if something bad happens and then sending it to stable. And since an RC would be a release, people wanting to test can subscribe to new release notifications on GitLab and get them in their inboxes. And if some issue arises after it was formally released as stable, don't wait months to ship a release with 20 other changes. Release a hotfix release with the fixes and those fixes only after some very quick testing and be done with it.
Currently as it stands from my point of view, Pleroma suffers from long release gaps while QA isn't good enough to justify the wait. And in my opinion it should try to improve on both fronts. QA done by ~5 maintainers communicating in some probably private channel who know the codebase well and how to properly configure everything can't bump into the same bugs as regular users.
>Follow bug -- this existed in the code for YEARS. It was not a single release that caused it.
It did exist, yes, I remember it happening way before 2.7.0. But somehow something made it much more prevalent (my best guess is the activity handling rework). 2.6.3 wasn't riddled with follows basically never working unless you try 6 times. 2.7.0 was and it took months for the fix to be released in a new version and the version that looked like it solved the problem (2.7.1) actually didn't solve it. It fixed the inconsistency between accounts appearing as followed but not getting posts in your timelines/delivered to you, because the state was inconsistent when something crashed. The actual proper fix to the follow bug I'm describing arrived in 2.8.0.
To give you a reference, I helped at least 3 people apply the patches on top of stable to fix the bugs.
>Oban bug -- very few people experienced this...
I'm aware of that. I tried experiencing it on the cheapest OVH VM with stock Postgres config on the most esoteric OS I could think of (OpenBSD). I did see it crash due to the load, but only 3 months after the issue was resolved. I'm also aware of at least two instances (lab.nyanide.com and clubcyberia.co) reverting back to 2.6.3 because of the follow bug and/or fear of Oban randomly falling apart.
>That edge case: server was too overloaded, too poorly configured, etc causing the Postgres connection to fail and Postgrex was not reconnecting. So the connection Oban was using for NOTIFY would just stop working.
This is way more likely than you think especially when the default query timeouts (15s is the default I think) are to fast for cheap VMs. I see 5-10 random timeouts every day. Mostly when autovacuum gets triggered on one of the large tables. It's not that unusual and I've set the query timeout to 30s, which is around the maximum time (20-25s) queries can take when loading FE (notifs, home timeline and maybe a thread load at the same time). Yes it's high, but the other solution is query->timeout->do same query again->probably timeout->query again->get actual data.
And @mint consistently triggered the Oban bugs on an older desktop with an nvme drive hosting 3 instances. A bit too much, but something an nvme can handle. The 2.7.0 release also inexplicably to me came with higher disk usage from Postgres for whatever reason.
@lain Some half-baked features that aren’t usually exposed by frontends like the ability to post to a list of users (which has been broken for like 2 years)
@ewen@lain thanks. I'll try to address some of the concerns:
>The UI is very busy and makes me anxious having that much jammed into a screen. It's trying to do a lot all at once. I'd like to be able to just rearrange what is on screen, or scale back sections to an icon instead for example.
As of current Develop branch, you can: 1) Collapse navigation section into a bar and adjust what icons are there (pic 1). Do you want to be able to collapse notifications column, too? 2) You can reverse the order of columns and adjust the size of them (pic 2)
>Tight fonts and lots of icons. 1) being able to adjust margins to be more relaxed is on my to-do list, right now you can only scale the UI in general. 2) you can adjust which icons show up on posts (pic 3)
>Overall, the PleromaFE UI feels very dated. 90s dated.
Apart from tight margins, I wonder if it's a theme problem. PleromaFE has an outstanding theme support (pic4), perhaps Mammal (Mastodon-inspired theme) looks better? I do want to make a material-like theme.
Yeah I didn't want to throw out too many specifics to my reply. Happy to elaborate more.
The UI is very busy and makes me anxious having that much jammed into a screen. It's trying to do a lot all at once. I'd like to be able to just rearrange what is on screen, or scale back sections to an icon instead for example.
The main section with the feed in PleromaFE is especially intense. Tight fonts and lots of icons. Clicking on a post expands that thread, but I'd much prefer to have a break-out section where highlighted or expended content can be viewed instead. A second column for example, like the advanced web UI on Mastodon.
Indeed that UI is a very effective and useful way to setup a screen, in my opinion.
Overall, the PleromaFE UI feels very dated. 90s dated. At the other end of the spectrum is Soapbox – very clean, and somewhat lacking in features. But it's a calm space and the UI is nicely responsive. It's very smooth. Maybe some inspiration to be found there.
[ I've just spent the evening trying to switch back to Pleroma-FE and spend more time with it. I grabbed an updated Soapbox a week ago and it's blatted my static folder... so I'm trying work out how to get back to Pleroma-FE. It's ignoring my admin settings! ]
Anyway, I will figure it out. Then I'll look more closely again at your suggestions.
One more thing that was a big issue for me, which I forgot about, was having a larger box to write my posts in. One reason I started exploring self-hosting an instance was to give myself freedom for very long posts. Is there flexibility on the Pleroma-FE interface to create a nice big space for typing long posts?
Am attaching a screenshot of this post by way of example.
I should add, I'm a 55 year old ex-geek with bad eyesight. My feedback is probably not going to reflect what a lot of younger audiences are thinking. I might be boring :)
@ewen@lain >Is there flexibility on the Pleroma-FE interface to create a nice big space for typing long posts?
PleromaFE automatically scales input form with length of your post (pic1), not sure if you want fixed adjustable height or minimum height or something else? You can also adjust column width. (pic 2 and 3)
>I should add, I'm a 55 year old ex-geek with bad eyesight. My feedback is probably not going to reflect what a lot of younger audiences are thinking. I might be boring :)
Okeys I got my instance back under control and have PleromaFE back online.
- I had no idea that the boxes expanded on the fly as the post is typed. That is good to know. I can see that works well.
- One of the big pluses with PleromaFE is that you can more quickly move through a timeline compared to Soapbox. When my brain is moving fast, this is a bonus. And I can see that being able to respond to a post without leaving the timeline can be helpful to keep your train of thought.
- It's a fine line between quick access to things, versus crowding the screen.
- I'm a very visual person and so little things like chunky icons or mis-aligned icons tends to distract me. Even the shading on buttons can impart a design signal.
I'll spend the next few days just with PleromaFE and see if my brain finds any specific friction.
@lain super late but also I do think it'd be nice to be able to send stuff to the drafts instead of out right posting it, but usually I just go "fuck it" and post it anyway