this post was submitted on 12 Jun 2025
92 points (100.0% liked)
PieFed Meta
1189 readers
24 users here now
Discuss PieFed project direction, provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics.
Wiki
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I've complained about the 'trusted instance concept' too ... I've a horrible feeling that it exists to protect piefed.social from the DB bloat it inflicts on everyone else, lol.
how does that affect db bloat? or rather, how does it protect from that?
piefed.social is hard-coded in the source as a 'trusted instance', so other PieFed instances won't ever send votes to it using alternative profiles. Untrusted instances that receive traffic from PieFed instances will end up generating one row for the main user, and one row for the alt user. It's typically only one extra row (per user), but I think that unticking and ticking 'Vote privately' in settings generates a new random username for the alt everytime, so it could end up being more.
at least in lemmy's db structure, it wouldn't make that much of a difference compared to other tables that use significantly more space:
The scale of LW is impressive as always.
Is the
post_readtable where info on what a user has or has not read is stored? I am wondering now if a huge db like that is the cost of implementing features like marking unread comments or posts....not that I have a great idea of how to do that since I don't know js at all, but db size is something to keep in mind when the intention is to have federated instances, each with their own infrastructure.
yes,
post_readmarks which posts a user has marked as read. it links post ids with user ids and adds a timestamp on top to allow for sorting.edit:
for comments, lemmy only stores the number of read comments per post, which is what goes into
person_post_aggregates. this is a tradeoff, it has some limitations, e.g. when comments are deleted or removed, which affects the total count. as there is also a timestamp attached it might be possible to use that in combination with comment creation times, though this would likely impact query performance quite a bit more.