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
Some of these types of bad content and bad behaviour can be captured on this service.. others are harder to capture.
My instance is dedicated to mostly people, but I generally delete accounts I consider SEO/SPAM
EXAMPLE:
A user called "123bcomstore" with "[email protected]" signed up and spammed... their IP was also associated with spammers from lots of other usernames/emails.
I should be able to easily mark this IP as a 'HIGH Spam risk'.... as a catch all instead of focusing on the single bad username/email (we can do both).
We need to ask where the line is.... The local record store down the street from me is not SEO spam to me... but any "business" activity might be SEO spam to others.
So the next question is escalation... If a business opens one pixelfed account on one instance.. that's not SEO spam... but if the same business opens one pixelfed account on 15 instances. That would be SEO SPAM.
NEXT
Risk scores should influence the response
90% of detection for low/medium risk reports should result in human involvement to manually approve accounts that are flagged incase of false alarm.
The HIGH risk reports could maybe shot first and ask questions later as required.
My goal for this project would be an "upvoting" system for admins/mods to collaborate and mark the reports as true/false to order to build trust in the reports
but also, allowing for instances to add additional information as notes.
Instance X can ask FediThreat about an IP.. and it can get back a report
IP 1.1.1.1 has 3 reports
IP suspended by pixelfed.au 2025 (Note: SEO spammer)
IP suspended by pixelfed.com 2024 (Note: SEO)
IP suspended by pixelfed.social 2023 (Note: SPAM)
STOPFORUMSPAM: This IP is connected to 59 other reports.
The text was updated successfully, but these errors were encountered:
If people have instances in weird places, but nobody reports them to the mods {they don't abuse the fediverse}, there will be no need for their IP to show up anywhere near the service.
This kind of service requires STRICT rules that must be follows with consensus for all instances using the service:
Reference: I am going to use https://connect.iftas.org/library/ vocabulary to not re-invent the wheel.
Bad Actors can be different kinds of risk:
https://connect.iftas.org/library-category/content/ has a nice list of different kinds of bad content.
https://connect.iftas.org/library-category/behaviours/ has a nice list of different kinds of bad behaviours.
Some of these types of bad content and bad behaviour can be captured on this service.. others are harder to capture.
My instance is dedicated to mostly people, but I generally delete accounts I consider SEO/SPAM
EXAMPLE:
A user called "123bcomstore" with "[email protected]" signed up and spammed... their IP was also associated with spammers from lots of other usernames/emails.
I should be able to easily mark this IP as a 'HIGH Spam risk'.... as a catch all instead of focusing on the single bad username/email (we can do both).
We need to ask where the line is.... The local record store down the street from me is not SEO spam to me... but any "business" activity might be SEO spam to others.
So the next question is escalation... If a business opens one pixelfed account on one instance.. that's not SEO spam... but if the same business opens one pixelfed account on 15 instances. That would be SEO SPAM.
NEXT
Risk scores should influence the response
90% of detection for low/medium risk reports should result in human involvement to manually approve accounts that are flagged incase of false alarm.
The HIGH risk reports could maybe shot first and ask questions later as required.
My goal for this project would be an "upvoting" system for admins/mods to collaborate and mark the reports as true/false to order to build trust in the reports
but also, allowing for instances to add additional information as notes.
Instance X can ask FediThreat about an IP.. and it can get back a report
IP 1.1.1.1 has 3 reports
The text was updated successfully, but these errors were encountered: