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.
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.
Is this where that happens? I am having a hard time untangling all the AP stuff in the codebase.
For what it’s worth, I don’t think this is the case any longer. I have been spinning up new dev instances a ton with docker and the trusted instances list is empty. The one place that piefed.social is listed in the admin panels I found is in the “Warn if new account banned from these instances” box:
I have been on a bit of a mission to try to make a lot of the more opinionated moderation tools in piefed optional at an admin level or remove them (so far rimu has been receptive). So, if this is in the code, I would want to make a PR to remove it.
Yeah. That function is for adding instances as they are encountered. Your dev server won’t initially know about any other instances (‘trusted’ or not), but as soon as it engages with anything from ‘piefed.social’, then it will get added to the instance list and the ‘trusted’ flag will be set to True
Is the post_read table 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_read marks 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.
piefed.social is hard-coded in the source as a ‘trusted instance’,
That’s probably inherited from the past, from a time where Piefed.social was the only active instance around. Quite a few of those settings are being made customizable in the last few days, so that every instance can configure it as they wish.
Please get rid of the trusted instance concept for private voting. Or at least let me lick which instances I trust.
You heard me.
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.
Is this where that happens? I am having a hard time untangling all the AP stuff in the codebase.
For what it’s worth, I don’t think this is the case any longer. I have been spinning up new dev instances a ton with docker and the trusted instances list is empty. The one place that piefed.social is listed in the admin panels I found is in the “Warn if new account banned from these instances” box:
I have been on a bit of a mission to try to make a lot of the more opinionated moderation tools in piefed optional at an admin level or remove them (so far rimu has been receptive). So, if this is in the code, I would want to make a PR to remove it.
Yeah. That function is for adding instances as they are encountered. Your dev server won’t initially know about any other instances (‘trusted’ or not), but as soon as it engages with anything from ‘piefed.social’, then it will get added to the instance list and the ‘trusted’ flag will be set to True
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_read
table 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_read
marks 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.That’s probably inherited from the past, from a time where Piefed.social was the only active instance around. Quite a few of those settings are being made customizable in the last few days, so that every instance can configure it as they wish.
…diligently taking notes…
I am going to take a closer look at this.
Thank you!