Reject downvotes from specific instances, or have an allowlist / blocklist for votes

[dessalines]

Requirements

• Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
• Did you check to see if this issue already exists?
• Is this only a feature request? Do not put multiple feature requests in one issue.
• Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Is your proposal related to a problem?

When federating with larger instances, your local feeds can be influenced by their anonymous voting patterns. It should be possible to reject votes from instances that you choose, without fully blocking them.

Describe the solution you'd like.

It might be useful to have an allowlist_votes, where you can keep open federation, but only allow downvotes from select instances. Should reduce bot spamming downvotes.

Or a blocklist_votes, where you allow all downvotes, except from specific instances.

Describe alternatives you've considered.

TODO

Additional context

No response

[lullis]

+1, but I proposed something similar on #3895 and it got closed.

[DraconicNEO]

I think this is a good idea but probably shouldn't be limited just to downvotes since upvotes can be fraudulent and manipulated as well, so being able to also block them from other instances would be very useful.

[DraconicNEO]

+1, but I proposed something similar on #3895 and it got closed.

I'd say this is more similar to #3662 and #4037 since it's less about implementing anti-cheat for Downvotes (what Reddit does) and more about providing more granular federation options such as being able to block Instances from downvoting, rather than setting specific critera for users to vote which can be seen in many ways as hostile towards users.

[Nutomic]

This is not a real solution because there is no effective way to find out which instances are manipulating votes. #4088 would be much more effective. Also #1487 (comment) would help.

[dessalines]

Good point, this shouldn't be limited to downvotes only, but all votes.

I agree that this doesn't help you find which are the vote-manipulating instances. For that, there are several options while still keeping votes private, such as

• Showing votes by person only to admins (and maybe mods)
• Serving up a public aggregate of vote count by instance, for a given item.

Once you have that info tho, you can either

• block the instance entirely or
• add that instance to a blocklist_votes or have an allowlist_votes for explicitly defined instances you allow votes from (what this issue is about)

[Nutomic]

The instances you shared as examples for bot voting (social.venith.net and x69.org) have almost no posts. Why not simply put them on the normal blocklist? I dont see why it requires a separate blocklist.

[dessalines]

Oh yes, for bot / Open instances I'd recommend the full block.

But there's also the case where you might want to stay federated with a larger instance, but still reject anonymous votes from them. Very useful if they have a lot of users that can influence your local feeds / sorts in a way you don't want.

I edited the issue to reflect that.

[ThisIsMissEm]

Something I'd probably recommend is changing how you look at the federation management features. Rather than just having many discreet lists of domains in a big settings table, actually have a instance_moderation_filters table which specifies whether to allow, reject or filter activities from the instance (this is what I propose in the FIRES proposal I'm working on getting published)

That way you can have a federation management UI that clearly lists each instance & the filters being applied.

[Nutomic]

Another option would be a plugin system which looks at incoming activities and decides whether to accept or reject them based on different criteria. That could be used to implement more granular blocklists among other things.

[db0]

Generally designing lemmy in such a way as to allow plug-ins would be much preferable, as it would allow everyone to help improve things without having to go through the main PR process. Do we have an issue for such a feature?

[ThisIsMissEm]

You'll still need somewhere to store the filtering state/rules, and having those all in one place can be very beneficial

[Nutomic]

#3562

[DraconicNEO]

The instances you shared as examples for bot voting (social.venith.net and x69.org) have almost no posts. Why not simply put them on the normal blocklist? I dont see why it requires a separate blocklist.

There may be other instances that one might want to block votes from which have many communities and a larger user base or large integral communities and banning them from voting is a better compromise than banning them entirely.

[db0]

btw, since my OP was closed as duplicate, I'm crossposting my original reasoning here

---

Is your proposal related to a problem?

This is a another tool in the moderation toolset to be used instead of outright de-federation. It could be used against instances which are not problematic enough to be blocked, but ideologically different enough where the parent instance does not wish to record their voting patterns.

This would be similar to mastodon's silencing features in strength.

Describe the solution you'd like.

Allow the lemmy admins to provide another list of "Vote silenced" instances (another name for this list is also fine). Votes from those instances on posts or comments would be silently dropped.

[ismailkarsli]

This proposal could kill small/self-hosted instances and direct users to large ones.

[dessalines]

I think another possibility, that'd be much simpler: a simple ON/OFF switch to reject federated downvotes. Then we wouldn't need to define specific lists of servers.

Possibly another one for reject federated upvotes also.

[dessalines]

@Nutomic what do you think about this. Adding two federation settings (bools):

• Reject federated upvotes
• Reject federated downvotes

Then we wouldn't have to add yet more lists, and this seems like it would fix a lot of the downvote spam issues.

[ThisIsMissEm]

@Nutomic or @dessalines I'd love to grab you for 30 minutes to go over the federation management that Lemmy currently has, if you want? https://calendly.com/thisismissem — I might be able to help guide you towards a solution.

I'd also be great to collaborate through the newly formed ActivityPub Trust and Safety Taskforce for SWICG.

[dessalines]

We work in different timezones so would rather just use async comms platforms. I'll watch that repo and would be glad to be involved in those conversations.

[ThisIsMissEm]

Okay, I'm usually available in east coast US time. Happy to meet you in your timezone if I can. (Though not available for a week)EmeliaOn 19. Sep 2024, at 23:03, Dessalines ***@***.***> wrote: We work in different timezones so would rather just use async comms platforms. I'll watch that repo and would be glad to be involved in those conversations. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[Nutomic]

@dessalines Wouldnt the existing "disable downvotes" feature be enough then? I suppose we can try that on lemmy.ml and polish it a bit more. Rejecting all federated votes would make for much worse post ranking for small instances so thats a bad idea.

@ThisIsMissEm Just open an issue here or use our matrix chats.

[ismailkarsli]

How about hiding federated downvotes? Instances can choose to hide federated downvotes locally (and calculate rankings according to that) while others can choose to not. This wouldn’t affect federation.

[dessalines]

@Nutomic no because it'd still be good to allow local downvotes, just not federated downvote spammers. So this setting applies only to federated votes.

But having 2 separate settings, reject federated upvotes, and reject federated downvotes, would be flexible enough.

How about hiding federated downvotes?

No this would be too complicated to keep multiple vote aggregates.

[Nutomic]

Or only reject_federated_downvotes. Without federated upvotes, the ranking algorithms would stop working on smaller instances.

[dessalines]

True, but it would be optional also, and I recall seeing a few people wanting reject_federated_upvotes too (whether for DB reasons or something else). Both of these options would be default off of course.