Spam and abuse reporting #424

fnetX commented 2021年04月07日 13:04:35 +02:00

With Codeberg growing every day, we surely want to have a better spam-reporting (flagging) workflow for issues, their comments as well as repositories and allow users to report it + have a dashboard for admins to manage the reports. (discussed this in praesidium recently)

Amount of dashboards should also be exposed via API so we can extend stats and management on Codebergs side.

I did not yet find a feature request in the Gitea tracker, please extend (or let's nicely ask there).

With Codeberg growing every day, we surely want to have a better spam-reporting (flagging) workflow for issues, their comments as well as repositories and allow users to report it + have a dashboard for admins to manage the reports. (discussed this in praesidium recently) Amount of dashboards should also be exposed via API so we can extend stats and management on Codebergs side. I did not yet find a feature request in the Gitea tracker, please extend (or let's nicely ask there).

fnetX commented 2021年04月07日 13:18:36 +02:00

https://github.com/go-gitea/gitea/issues/5262 (local in Codeberg/gitea#6) is a feauture request to hide comments, this could be combined (like hiding as offtopic just hides + hiding as spam triggers a warning to admins)

We might also want to automatically limit users who are repeatedly reported as spammers until manual review, to prevent larger damage to the community ... just thinking aloud.

https://github.com/go-gitea/gitea/issues/5262 (local in Codeberg/gitea#6) is a feauture request to hide comments, this could be combined (like hiding as offtopic just hides + hiding as spam triggers a warning to admins) We might also want to automatically limit users who are repeatedly reported as spammers until manual review, to prevent larger damage to the community ... just thinking aloud.

6543 commented 2021年05月08日 21:50:25 +02:00

we should add ...

1. more moderation for organisations -> organisations should be able to block users
2. users should be able to ignore other users
3. an site(gitea)-admin report dashboard & report options, to report issues, comments, repos

maby add some report pannel for orgs to ...

we should add ... 1. more moderation for organisations -> organisations should be able to block users 2. users should be able to ignore other users 3. an site(gitea)-admin report dashboard & report options, to report issues, comments, repos maby add some report pannel for orgs to ...

fnetX commented 2021年05月08日 22:11:32 +02:00

#373 is also relevant for 1) & 2)

#373 is also relevant for 1) & 2)

davidak commented 2021年07月07日 06:54:59 +02:00

Here is an example why this is needed:

people from 4chan harassing maintainers of an audacity fork

https://github.com/tenacityteam/tenacity/issues/99

and now create spam and hateful issues

https://github.com/tenacityteam/tenacity/issues/109
https://github.com/tenacityteam/tenacity/issues/110
https://github.com/tenacityteam/tenacity/issues/115

(open at own risk)

It should be possible to report such posts and a project as well as platform admins (codeberg in our case) should be able to remove it.

It should also be possible to mute or block users.

Here is an example why this is needed: people from 4chan harassing maintainers of an audacity fork https://github.com/tenacityteam/tenacity/issues/99 and now create spam and hateful issues https://github.com/tenacityteam/tenacity/issues/109 https://github.com/tenacityteam/tenacity/issues/110 https://github.com/tenacityteam/tenacity/issues/115 (open at own risk) It should be possible to report such posts and a project as well as platform admins (codeberg in our case) should be able to remove it. It should also be possible to mute or block users.

circlebuilder commented 2021年10月11日 09:48:09 +02:00

This is just a FYI and idea that may inspire alternative ways to implement based on the upcoming federation support (#14186) of Gitea (bootstrapped via @dachary and the FedeProxy community, and with Gitea seeking NGI funding (#16518)). Moderation is a social activity and extending its support on the Fediverse via W3C ActivityPub / W3C ActivityStreams an ongoing effort with which Gitea may align.

This is just a FYI and idea that may inspire alternative ways to implement based on the upcoming [federation support (#14186)](https://github.com/go-gitea/gitea/issues/14186) of Gitea (bootstrapped via @dachary and the [FedeProxy](https://fedeproxy.eu) community, and with Gitea seeking [NGI funding (#16518)](https://github.com/go-gitea/gitea/issues/16518)). Moderation is a social activity and extending its support on the Fediverse via [W3C ActivityPub](https://www.w3.org/TR/activitypub/) / [W3C ActivityStreams](https://www.w3.org/TR/activitystreams-vocabulary/) an ongoing effort with which Gitea may align.

algernon commented 2024年01月03日 19:46:33 +01:00

I've been recently working on something that has a lot of overlap with reporting spam repos (or spam, in general), and I think I have an idea how to tackle the problem. It may not work well with Federation in mind, but for now, my focus is handling spam ASAP.

There are two aspects to it: one is reporting, and the other is acting on the report, and these two need to be treated separately, because who can act on them, may change with context. Let me explain and illustrate!

Ideally, we would like to be able to report any kind of thing: a user/org, a repo, an issue/pull request, a comment. A user/org or repo report needs an instance administrator to act upon. A report about an issue/PR, or a comment - the owner of the repo might be enough to handle it, but may also need intervention from an admin, possibly by reporting the user who made the issue/PR or the comment.

Yet, underneath, they share many things in common: each thing can be reported by multiple users, each of them have an ID of some sort, and we want to record when the report was made, and whether the report has been handled or not. There are also multiple levels of handling, too: for example, you may want to hide comments (because they're offtopic, but worth keeping), or you may wish to delete them (because they're spam, or problematic otherwise). I think that repo admins should be able to both hide and delete comments, issues, and PRs. However, that places the moderation burden on repo owners - so it might make sense to make this configurable: reporting things under a repository could either be sent to the repo owner, or instance admins. If it is sent to instance admins, then repo owners probably shouldn't have permission to delete them (but hiding should still work, imo).

Under the hood, things that can be hidden (issues, prs, and comments) would have a field added to the respective model. Something like - for example - Issue.Visibility. This .Visibility would default to "Visible", but it could be "Collapsed" (shown, but collapsed, requiring a click to view), or "Hidden" (completely hidden from the UI, but shown as collapsed (+ different border or something) to people with permission to change the visibility). Things that cannot be collapsed or hidden (users/orgs & repos) would not have such a field... though, perhaps they should, I can imagine scenarios where that would be useful too.

This is for controlling the visibility of things, as a reaction to reports. Reports themselves would be stored in a single table, because they all share almost everything in common:

typeReportstruct{IDint64ObjectTypeReportObjectObjectIDint64CreatedByint64CreatedUnixtimeutils.TimeStampReasonReportReasonCommentstringClosedbool}

...where ReportObject would be an enum over users/orgs/issues/prs/etc, ReportReason a built-in enum of report reasons (spam, harassment, custom, etc), with comment being free-form text.

Forgejo would then provide an interface to view reports one is responsible for. While it would be quite expensive to render all reports on a large instance, paging them should keep the load in check, I think.

I will probably do a proof of concept in the next few days, to gauge how viable the above strategy would be.

I've been recently working on something that has a lot of overlap with reporting spam repos (or spam, in general), and I think I have an idea how to tackle the problem. It may not work well with Federation in mind, but for now, my focus is handling spam ASAP. There are two aspects to it: one is reporting, and the other is acting on the report, and these two need to be treated separately, because who can act on them, may change with context. Let me explain and illustrate! Ideally, we would like to be able to report any kind of *thing*: a user/org, a repo, an issue/pull request, a comment. A user/org or repo report needs an instance administrator to act upon. A report about an issue/PR, or a comment - the owner of the repo might be enough to handle it, but may also need intervention from an admin, possibly by reporting the user who made the issue/PR or the comment. Yet, underneath, they share many things in common: each *thing* can be reported by multiple users, each of them have an ID of some sort, and we want to record when the report was made, and whether the report has been handled or not. There are also multiple levels of handling, too: for example, you may want to hide comments (because they're offtopic, but worth keeping), or you may wish to delete them (because they're spam, or problematic otherwise). I think that repo admins should be able to both hide and delete comments, issues, and PRs. However, that places the moderation burden on repo owners - so it might make sense to make this configurable: reporting things *under* a repository could either be sent to the repo owner, or instance admins. If it is sent to instance admins, then repo owners probably shouldn't have permission to delete them (but hiding should still work, imo). Under the hood, things that can be hidden (issues, prs, and comments) would have a field added to the respective model. Something like - for example - `Issue.Visibility`. This `.Visibility` would default to "Visible", but it could be "Collapsed" (shown, but collapsed, requiring a click to view), or "Hidden" (completely hidden from the UI, but shown as collapsed (+ different border or something) to people with permission to change the visibility). Things that cannot be collapsed or hidden (users/orgs & repos) would not have such a field... though, perhaps they should, I can imagine scenarios where that would be useful too. This is for controlling the visibility of things, as a reaction to reports. Reports themselves would be stored in a single table, because they all share almost everything in common: ```go type Report struct { ID int64 ObjectType ReportObject ObjectID int64 CreatedBy int64 CreatedUnix timeutils.TimeStamp Reason ReportReason Comment string Closed bool } ``` ...where `ReportObject` would be an enum over users/orgs/issues/prs/etc, ReportReason a built-in enum of report reasons (spam, harassment, custom, etc), with comment being free-form text. Forgejo would then provide an interface to view reports one is responsible for. While it would be quite expensive to render all reports on a large instance, paging them should keep the load in check, I think. I will probably do a proof of concept in the next few days, to gauge how viable the above strategy would be.

Gusted commented 2024年01月03日 20:01:30 +01:00

It seems you're trying to tackle multiple features at once and that's generally okay, but it's too big for reviewers or general 'bug testing' to be done all at once for Forgejo. For example with reporting, one of the major roadblocks I had in my very outdated draft of this feature is when users delete things. It's a scenario that I defined (which I faced with Github support, that they still saw original conversation as-is when it was reported even if it by then was deleted) for a more casual moderation ticket, essentially a issue or comment should be copied when it's being reported so the report still exists even if its deleted by the OP or repository admin. The actions that can be done with a report should likely be limited to existing features, as such features can stand on their own and don't necessary have a connection to reporting capabilities. Also old reports should eventually be deleted, so adding a ClosedUnix field is also a good idea.

If you want we can take a call/meeting for this, as I've quite some implementation details on this specific feature. I additionally can dust off my implementation (if I'm able to find it) and work together from there as it lays some good fundamental groundwork for it. It's quite an undertaking.

It seems you're trying to tackle multiple features at once and that's generally okay, but it's too big for reviewers or general 'bug testing' to be done all at once for Forgejo. For example with reporting, one of the major roadblocks I had in my very outdated draft of this feature is when users delete things. It's a scenario that I defined (which I faced with Github support, that they still saw original conversation as-is when it was reported even if it by then was deleted) for a more casual moderation ticket, essentially a issue or comment should be copied when it's being reported so the report still exists even if its deleted by the OP or repository admin. The actions that can be done with a report should likely be limited to existing features, as such features can stand on their own and don't necessary have a connection to reporting capabilities. Also old reports should eventually be deleted, so adding a ClosedUnix field is also a good idea. If you want we can take a call/meeting for this, as I've quite some implementation details on this specific feature. I additionally can dust off my implementation (if I'm able to find it) and work together from there as it lays some good fundamental groundwork for it. It's quite an undertaking.

algernon commented 2024年01月03日 21:09:19 +01:00

I agree with what you said, and I too listed the visibility features as separate - they can be implemented independently of reports, they share no data, the only connection is that the visibility of certain items can be changed in response to reports. But if there are no reports, the visibility stuff is still valid, and stands on its own.

Lets discuss the call/meeting details privately!

I agree with what you said, and I too listed the visibility features as separate - they can be implemented independently of reports, they share no data, the only connection is that the visibility of certain items can be changed in response to reports. But if there are no reports, the visibility stuff is still valid, and stands on its own. Lets discuss the call/meeting details privately!

Undercut0150 commented 2025年04月24日 04:33:48 +02:00

Just found this issue after doing a search on StartPage. This is needed badly as I am noticing accounts being run by LLM spam opening issues. They need to be dealt with ASAP lest developers abandon the platform for another with actual spam blocking.
https://codeberg.org/imminentspace?tab=activity
https://codeberg.org/floralgrandeur?tab=activity
https://codeberg.org/discerningpram552?tab=activity
https://codeberg.org/sparegarnet10?tab=activity
https://codeberg.org/afraidtraveller74?tab=activity

Just found this issue after doing a search on StartPage. This is needed badly as I am noticing accounts being run by LLM spam opening issues. They need to be dealt with ASAP lest developers abandon the platform for another with actual spam blocking. https://codeberg.org/imminentspace?tab=activity https://codeberg.org/floralgrandeur?tab=activity https://codeberg.org/discerningpram552?tab=activity https://codeberg.org/sparegarnet10?tab=activity https://codeberg.org/afraidtraveller74?tab=activity

antlers commented 2025年04月24日 05:33:59 +02:00

Ditto!
https://codeberg.org/correctmane417?tab=activity
https://codeberg.org/untenablebettor57?tab=activity

Ditto! https://codeberg.org/correctmane417?tab=activity https://codeberg.org/untenablebettor57?tab=activity

buildacubesat commented 2025年11月19日 18:46:52 +01:00

Ditto. I have a spam bot or deranged individual sporadically opening bogus issues, some times with offensive content. Ideally, there would be better filtering for that. Alternatively, a way to approve new issues before they go public would be great too.

Ditto. I have a spam bot or deranged individual sporadically opening bogus issues, some times with offensive content. Ideally, there would be better filtering for that. Alternatively, a way to approve new issues before they go public would be great too.

fnetX commented 2025年11月19日 21:34:30 +01:00

Spam and abuse reporting exists and is enabled on Codeberg. I forgot to close this issue.

Spam and abuse reporting exists and is enabled on Codeberg. I forgot to close this issue.