Moderation #10
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Moderation is already a challenge on large Gitea instances like Codeberg and will become even more difficult once Gitea starts federating. @dachary suggested we investigate the Discourse moderation system and see what we can learn from it. I have a few concrete suggestions here on how we could implement moderation features.
Rate limiting: There should be configurable settings for rate-limiting user signups, new issue creation, commenting, etc to prevent spam.
Blocking an instance: One proposal to do this is to add each instance as login source, and then you can disable login sources in the admin UI to block an instance. To block all instances by default and have an allowlist, we could have a setting called LIMITED_FEDERATION which requires the instance admin to manually add an instance as a login source to federate with them. Alternatively, we could add a setting that lists all blocked instances, but this would require creating a UI for managing it.
Blocking users: There should be a way to block a user from interacting with a repo. This requires adding a block user button to the dropdown menu when you click the three dots in the top right corner of a comment, as well as a menu in the repository settings to manage blocked users. Also, it might be beneficial to block a user from all repositories that you own, which would be similar but require a menu in your user settings instead to manage blocked users.
Reporting content: Users should also be able to report a comment or issue. We will need a database table for storing reports and a menu in the admin UI to handle these reports.
Any other suggestions or ideas?
@6543 what does Codeberg currently do for moderation? I saw that Codeberg has a moderation repo.
Relevant Gitea issues:
Other relevant discussions:
I would advocate for implementing a trust level system first. It can be just a few levels: the most important is that
Level 0 is for users who just created an account and has very limited spam capabilities. For instance it is not possible to post more than one URL. Can only post three comments per day...
Level 1 is acquired after reading / writing a number of issues / pull requests and/or returning to the forge, existing for more than X days with at least X interactions etc.
Level 2 is only needed for the most active users and not really anyone else.
Level 3 is for moderators.
You get the idea ?
This would definitely be very beneficial, and is independent of federation, so it might be a good idea to submit an issue on upstream Gitea so that others can discuss and implement this.
I'm not exactly sure how this would work in a federated system though, since we could either have the trust system not apply to remote users (opening up the potential for spam) or each instance will have its own trust of a remote user (which can be confusing). Another idea is to do the trust system per user per repository, so users, including remote users, won't initially be able to flood a repo with spam.
It would make sense to me that there is a very basic moderation system for forge instances as a whole. It could be a whitelist or a blacklist, depending on how confident the forge admin is with regard to being targeted by malicious forge instance owners.
My intuition is that spammers/bots won't go into the trouble of faking to be a forge instance. At least not for the foreseeable future.
So once you have established trust with a set of instances, you can trust that what they declare the trust level of their user to be is genuine. Remote and local users would be treated equally with regard to trust levels.
It's actually surprisingly easy to create a fake forge instance, since the spammer doesn't need to actually deploy Gitea but can just set up a static WebFinger endpoint, a Person actor endpoint, and then send as many JSON-LD payloads as they want. (Basically just go through the steps of https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/) It's not trivial, so I would be a bit surprised if spammers or bots start doing this, but it's possible. However, I think this is a good case where blocking the entire instance would be highly effective.
I think I can drop in a few words about moderation on Codeberg, hope this is still relevant.
We're building a tool to faciliate moderation using the Gitea API, and eventually also build an option to directly connect to filesystem and database (because the API is quite limited, and certain features are definitely very specific and probably not worth implementing in Gitea + changing Gitea isn't very flexible for dealing with spam and all kinds of weird content).
The idea, however, is to extend the moderation features of Gitea, which are (as of today) basically non-existent. That means, Gitea should provide some easy means of collecting reports and displaying them. Admins of small instances should be able to list and react (e.g. have a button per reported item to drop it). Larger instance admins can connect our tool, that is going to allow to grant people some permissions without making them instance admin as well as advanced search / filter tools (probably only useful if your explore view has many many pages).
We tried contacting the Gitea team about this topic https://github.com/go-gitea/gitea/issues/19283, but haven't received feedback other than thumbs-up (and I don't know what I should make out of it). The issue description is also briefly touching the topic of federation.
If you need feedback, I'm very open to discussing this together. Other than that, I think that Gitea can just implement some basic features and API routes itself, but keep the code small and maintainable. Admins of larger instances should be able to connect their own ("our") moderation tool, we're trying to keep it somewhat generic to use.
Is there a reason why this is a separate tool and you believe that it's "not worth implementing in Gitea"? I see a lot of benefits of having moderation features directly in Gitea instead of in a third-party tool, especially since as you said, Gitea has basically zero moderation features right now. You also mentioned that having a separate tool would keep the moderation code inside Gitea small and maintainable, but overall it's still the same amount of code to maintain, just some of it is now in another tool.
Good idea, user reports are definitely something that should be implemented in Gitea.
From my own experience of working with the Gitea team on federation, they're almost always too busy with working on other Gitea issues and PRs, so you're really on your own when it comes to implementing big new features.
Sure, if you have other ideas, I'm also open to discussing this further. However, I'm currently busy with PR #20391, so I won't have much time to work on moderation. Fortunately, moderation is somewhat independent of federation, so anyone wants to start implementing these moderation features, go ahead! (User reporting doesn't require federation, for instance. Blocking users and instances by admins is related to federation, but those are relatively easy to implement and I'll probably include it in #20391)
Yes, many probably. I'll name some that come into my mind: