Extend the "hesitated" instance functionality.

[db0]

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.
• Do you agree to follow the rules in our Code of Conduct?

Is your proposal related to a problem?

Note: I am using "hesitated" here as a keyword to describe the behavior such as rejecting votes form specific instance (#5038). In effect I consider stopping votes as a signal of wariness towards that instance. So I feel the word fits. But if you prefer another word like "untrusted", it's also fine. I will just continue using for this request.

Currently the solution in #5038 is good, but it's a blunt instrument. I would like to extend the solution to instance admins have more fine control on how to interact with mistrusted instances.

Describe the solution you'd like.

I want to suggest extending the hesitated functionality with optional switches. I want to suggest 2 approaches, and you can choose whichever one you feel more feasible.

First of all, I would like to list the extra functionality that could be potentially enabled along with "vote blocking". My hope is that I would be able to choose not only whom I hesitate against, but also how.

• Minimize comments: Comments from a hesitated instance, start minimized. While this could potentially be a feature on the frontend itself, the instance admin in that case won't easily have the option to enable it for everyone, so that should have some backend switch as well, like default sorting does.
• Prevent/Discourage DMs: DMs from hesitated instances can either be blocked, or appear in a separate tab without notifications.
• Hide posts: Automatically hide posts from people in hesitated instances from view. There should instead be a boolean switch somewhere which reveals them. Again this could also just be a frontend switch, but I would at least like a backend setting somewhere for the instance admin to set a default.
• Hide communities from all: Automatically hide communities from hesitated instances from the All tab. Once again, bool switch to reveal like Hide posts.
• Split block upvote from block downvote: Sometimes, I might be OK with some instances upvoting our posts, but I don't want them mass down-voting.

These 5 new functionalities could help admins who want to retain more access to their user to the larger threadiverse, while also providing a reasonable protection towards new and more vulnerable members to avoid potentially triggering or shocking content.

Now, we ultimately have 6 feature switches on the hesitated list. I don't want to maintain 6 different instance lists. Instead I want to suggest having each of these as a boolean. The question is how to apply them.

• Solution 1. Apply them for the whole hesitated list. This should probably be the simpler option to add to the backend. Create a DB table listing which feature switches apply to all the hesitated serves. So I can flip "no downvotes", "hide DMs" and "minimize comment" and it would apply to all the instances I have in my hesitated list.
• Solution 2. Apply them per instance. This would require extending the hesitated list table with a boolean switch for each instance. So instance A can have blocked votes, while instance B, can have also hidden posts and comments.

Describe alternatives you've considered.

As I mentioned in the suggestion, some of these can be handled by the frontends, parsing the blocked vote instances list (is it public btw?) and then applying extra filtering such as hiding comments or DMs, but I want to have a way for the instance admin to make default decisions for everyone as this is a protective mechanism.

Nevertheless, even if you delegate this only on frontends, it would make sense to rename the "block votes" list to something more generic like "hesitated" or any other adjective.

Additional context

No response

[Nutomic]

FYI the option to block federated votes in #5038 does not apply to specific "hesitated" instances. Instead you can choose which votes to allow for posts/comments and upvotes/downvotes. Either all (including federated), local votes only or no votes at all. If you reject federated votes, that applies to all instances.

[db0]

ACK. So currently you cannot specify which ones you reject. It's a blanket thing. Then this issue would be to extend this functionality to be able to provide a list of instances. Having a secondary layer before "defederated" has a lot of benefits for moderation and good interactivity with the larger fediverse.

[Nutomic]

It would be possible to add fields to the instance table for disable_votes, minimize_comments, and other things you suggest. Then each of these would have to be checked in the relevant place(s) in federation code, and we would need an api endpoint and ui to modify them. Doable but will take some effort to implement.

[db0]

It would be possible to add fields to the instance table for disable_votes, minimize_comments, and other things you suggest.

Hm, if you add them to the instance table I guess it would make a sense for block to be a boolean as well (instead of the de-only facto effect) unless it is already (haven't checked lately :D). I kind feel that it might be a bit confusing since "blocked" would effectively "trounce" all the other booleans, but I can see why that might be a simpler solution DB-wise.

And ye I understand about the effort, ofc. I don't expect this soon, but good to have it in mind and might even be a straightforward enough task for a newcomer.

[Nutomic]

There is a separate table federation_blocklist, but that could probably be converted to a boolean column on the instance table.