lemmy
lemmy copied to clipboard
LemmyNet
prototype / proof of concept - do not send comment/post upvotes/likes…
… to peer servers due to performance crisis
DRAFT: add Linux environment variable or site settings to allow instances with large numbers of servers wanting comment/post copies to skip vote replication.
~~sorry for typos in comments, it is not "lemmy.ee" and "environment" is wrong. Even for a draft, bad ;) Also, I forgot to have an else clause on the 1 == 1 if the feature is disabled, leading to pre-modified code path.~~ (Fixed) But... I swear I did check that this is the ideal point to non-federate outbound like/vote on post/comment.
FYI you can use env::var("MY_VAR").is_ok() to check if an env var was set.
https://doc.rust-lang.org/std/env/fn.var.html
a temporary solution to a bigger problem
I think the bigger solution is Lemmy to Lemmy replication via a bulk pull request using the front-door API, with some extra API calls to get more into the raw database tables. Fetch 300 or more comments at a time. Would also provide a backfill solution for new servers.
Thank you. added environment variable LEMMY_SKIP_FEDERATE_VOTES. I encourage you to rush this into 0.18.1, votes are the most frequent outbound activity, cutting down volume significantly.
I’d be vehemently against this PR. Part of what makes Lemmy (and other voting based link aggregators) work is the votes that determine content quality. Without it, we’re further forcing users to consolidate into these mega instances, and eventually recreating Reddit where one or two instances houses all the curated (voted) content.
Before this gets pushed through, there must be a pull based approach where votes can be batch requested by federated instances, such that federated instances can have parity on vote status. This pull batches also must not be pre-aggregated, such that federated instances can (theoretically in the long term) perform own heuristic analysis for their own manipulation detection.
This PR can be useful for testing how votes impact performance. I have no intention to merge it.
There has also been public discussion about privacy https://lemmy.world/post/1033769 and how federated peers can get precise details of a user's downvotes and upvotes. So having it up for reference can serve that purpose too.
Privacy of votes needs its own issue for discussion: no federated platform has the concept of "private / anonymous likes". Mastodon (and twitter) even show favorites in their UIs.
Like reddit we don't display them through the UI, but they are accessible to instance admins who know how to query the DB directly.
@RocketDerp > The expectation of privacy is a separate discussion. Perhaps there could be more intelligent ways to federate out votes without explicitly connecting the action to specific user's user ID, but the information must not be abstracted away into aggregated totals, or rouge instances can easily poison the entire network/game the system by emitting fake aggregated information.
That is, to be abundantly clear, the out-bound federation doesn't have to explicitly say activity came from [email protected], but it should at least say something like [email protected] where [email protected] consistently translates to [email protected], such that purge requests can be issued and data purged accordingly. Additionally, it should never be something akin to post 1 has 35 upvotes and 23 down votes but we're not telling you who did the votes, such that 1: Actions could be reverted in a ban+purge, and 2: if one instance is gaming the system, it could still be identified.
However, having said that, it is a separate and much larger discussion that should be more thought out as opposed to an arguably panic reaction PR.
arguably panic reaction PR
the words "proof of concept" are about as far away from "panic" as a human can communicate.
Gonna close this as it doesnt clearly solve a problem and instead completely breaks all ranking.