Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with User List abuse #1

Open
pfrazee opened this issue Jun 23, 2023 · 1 comment
Open

Dealing with User List abuse #1

pfrazee opened this issue Jun 23, 2023 · 1 comment

Comments

@pfrazee
Copy link
Contributor

pfrazee commented Jun 23, 2023

There's some pretty common abuse vectors with Lists

  • Lists with mean names
  • Lists being used to target harassment

There are some ideas worth looking at:

  1. Should lists be kept out of sight of users if they don't signal some trust first? Certainly this might make sense for notifications.
  2. Should it be possible for users to remove themselves from lists, or require approval before being added to lists?
  3. Any others?

It's hard to counteract some of these issues because some usecases are specifically about handling bad actors, and most people added are not going to be pleased by their inclusion.

We should also be mindful that lists will need to be reportable and moderatable.

@Juicysteak117
Copy link

I think declared membership is probably the way to go in terms of reducing the main abuse vectors. As noted in the proposal, trusted lists sounds like a very quick way to cattiness while also not giving the targeted user as much recourse (depending on if they are aware of their own addition to the list). While bad actors are still going to be bad actors, there are more hurdles in place if they're disallowed from easy tools that allow targeted harassment lists to be formed in the first place. Namely, it would be beneficial for a user to have consent over what public lists they're added to with an option to leave a list. An option to disallow list requests would be useful in the case of list request spam (either from a single user or from a group of users all sending bad requests), perhaps with a corresponding way of requesting to be added to a list or allowing specific lists so as to allow some granularity, although presumably blocking would also obviously block any relevant interactions

The primary setback of an option like this would be that list requests would naturally get more unwieldly for larger accounts if they are receiving a request for every single list. I'm not sure if there is a planned addition of private lists, but I think a distinction between private and public lists would do a lot for this. From what I can tell on Twitter for instance, most people who use lists just use them to sort out their follows or curate personal art feeds and things like that. I think if a list is private then it could probably be allowed more freedom without as much concerns over abuse which would also cut down on the burden of list requests. The decision of making a list public and thus under further scrutiny should be irreversible.

Membership APIs would be good in the future in terms of broadening lists' ability as a community building and social tool, but it would have to be in conjunction to other list moderation tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants