You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up to #5087 and and extension of #5038
Currently we have a way to specify "hesitated" instances in which to apply vote blocks, but we cannot do the reverse, which is to block all votes except from specific instances.
This would work the same principle of the current allow-list and block-lists work now. Instead of specifying who you mistrust, you specify who you trust and assume to mistrust everyone else
Describe the solution you'd like.
Some instances might want to provide a list of instances I trust, and add some extra protection against everyone else. This could be used by instances admins who are the frequent targets of harassment by the larger fediverse to provide some measure of protection, without completely walling themselves off.
As it's a follow-up of #5087 the instances not in the trusted-list would have the following active.
Upvotes disabled
Downvotes disabled
Comments start minimized
Posts hidden unless revealed manually
Communities hidden unless revealed manually
DMs hidden and revealed though specific tab/switch
All of these settings except the votes, could be disabled permanently by any member of that instance who can tolerate them.
The instance admin can add any instance to the trusted list and then enable some or all of these features. This can happen in either of two ways
Solution 1. Apply them for the whole trusted 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 trusted serves. So I can flip "allow downvotes", "allow DMs" and "reveal comments" and it would apply to all the instances I have in my trusted list.
Solution 2. Apply them per instance. This would require creating the trusted list table with a boolean switch for each instance. So instance A can have allowed votes, while instance B, can have also visible posts and comments.
Through this approach instances can start creating affinity groups, where they prevent harassment and bad actors from the general fediverse, while still allowing their members who can handle it interact, and also specify which instances are known good actors with more privileges.
Describe alternatives you've considered.
There's no alternatives since there's no way to specify a list of trusted instances instance-wide without external tools.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Requirements
Is your proposal related to a problem?
This is a follow-up to #5087 and and extension of #5038
Currently we have a way to specify "hesitated" instances in which to apply vote blocks, but we cannot do the reverse, which is to block all votes except from specific instances.
This would work the same principle of the current allow-list and block-lists work now. Instead of specifying who you mistrust, you specify who you trust and assume to mistrust everyone else
Describe the solution you'd like.
Some instances might want to provide a list of instances I trust, and add some extra protection against everyone else. This could be used by instances admins who are the frequent targets of harassment by the larger fediverse to provide some measure of protection, without completely walling themselves off.
As it's a follow-up of #5087 the instances not in the trusted-list would have the following active.
All of these settings except the votes, could be disabled permanently by any member of that instance who can tolerate them.
The instance admin can add any instance to the trusted list and then enable some or all of these features. This can happen in either of two ways
Through this approach instances can start creating affinity groups, where they prevent harassment and bad actors from the general fediverse, while still allowing their members who can handle it interact, and also specify which instances are known good actors with more privileges.
Describe alternatives you've considered.
There's no alternatives since there's no way to specify a list of trusted instances instance-wide without external tools.
Additional context
No response
The text was updated successfully, but these errors were encountered: