I've been reading over all the feedback provided by the community. This is an update on progress while also asking some questions to the community.
I'm currently working on the Detailed Design of the project. This is a document that serves two purposes:
Ensures what I plan to build is what is expected
It forces me to think through the project in detail to find any holes early on
While working on this document, I realized it would be great to separate additional contributions the community can make that cannot relate to this project.
I am going to define the following feature sets:
In the scope of this project
Which parts must be a core enhancement
Out of the scope of this project
Finally, the requests that require significant design decisions today
In-Scope Features
There is a clear set of features that will be included. These are must-haves for this project to be a success.
Roles & Responsibilities
The ability to create super admins, moderators of the entire site, single communities, and/or just application reviews.
Smart mod queue ranking
The ability to rank local or external posts higher.
The ability to use rank posts by how well the OP behaves (has moderation strides against them already, etc.)
Certain words, phrases, or domains will rank reports higher. These words can be used to also auto-report posts.
A way to resolve reports by sending and recording a warning to the user or suspension by time or permanently.
Private notes for local moderators on posts, accounts, comments, users, etc.
The ability to search & filter the mod log by the user, posts, comment, community, local or remote instance.
Statistics to help find:
Overactive users that like, comment, post
Retention
Report details
Open reports
Resolved
Response time
Totals on users, communities, comments, etc.
Likes of posts & comments over time
List of posts from users of your community to other communities. For general scanning of busy communities.
List of comments from users of your community to other communities. For general scanning of busy communities.
Must be core enhancements
Several requests are changes to the core of Lemmy and cannot be accomplished by an external tool.
Restricting content from federated instances from pulling locally. Federation is all or nothing. It would be a terrible user experience for a post to be on the main instance but never able to be pulled locally without some notification that the content broke local rules.
Restricting federation in any form.
Forcing federated communities and/or instances to moderate your instance rules.
Blocking federated users from local communities in any way.
Out of scope
Some features I just cannot fit within this project's scope or help push the need for them to be added to the core. If these are important to you, please, work with the core team to add them.
Customer service tasks
Password reset (site handles this)
Changing user account details
Federation tools
Most federation-related requests will require major changes to the core and should be done as core contributions.
Limiting which posts show or are hidden from the feed.
User tracking across instances.
This feature would require a single instance, a central database to track, and/or enhancements to the federation logic within Lemmy.
This includes preventing certain users from posting in a community.
Any bugs with Lemmy
Finally, a design decision
Some features will require some design decisions to be possible. Mostly, the ability for more joint moderation between instances. I'll list the features below:
Strike count across instances
Risk ranking of users across instances
Common SPAM detection
Instance frustration detection (lots of strikes against its users, lots of removal of communities, etc.)
Shared private notes on users/communities/posts, etc
These features will require some central moderation hub, which brings me back to one of the original questions. Do you want to self-host without central features, or do you want there to be a central site (like mods.socialcare.cloud) where you log in and interface with your instance?
Self-hosting brings additional costs. Some data will need to be stored for this moderation tool and scale depending on your site's traffic. So for site admins, here are the pros and cons of self-hosting versus cloud solution:
For cloud hosting
Pros
Simple setup and zero to low cost
Better communication between instance mods
Quicker development
4. No need to devote development hours to installation scripts, guides, community support, etc.
Cons
Admins cannot modify code directly
Potential subscription cost (no monetization has been figured out to run the servers/development)
For self-hosting
Pros
Admins can directly modify code rather than wait for updates or changes.
Cons
Slower to develop
Potentially complicated installation
Might be less adopted by users
What's next?
I'm working on the Design Doc for what is In-Scope. These features will be built regardless. This will be done by tomorrow's EOD (July 2nd, 2023).
After that, I will break ground on development. The plan is to split some of the development into microservices. This should allow for parallel development for whoever wishes to contribute.
"What can I do?"
Please help me figure out what to do with the core enhancements. Please let me know if anyone wants to take them on and own them. Let me know if you'd prefer I create GitHub issues for the core team. I need you to let me know what you want to do or can do.
Please help me add to this pro/cons list for self-hosted vs. cloud-hosted, and let's decide.
I didn't quite get the design doc complete. I'm considering doing this project alone and quickly in a simple framework like Laravel. I could probably do it in a week with something like that. I'll let you all know.
I've not heard much feedback regarding direction, so keeping it simple might be the best first step.
I've been digging into the lemmy source code, specifically how the federation works, the ui, the server, etc.
Currently there is no data collected on a report other than if it has been resolved, who resolved, and when. I am currently working on a PR that addresses this, however it is a non-trivial change. Currently I'm looking at adding a "resolution" which will be what action was taken, then also a "note" available to be added by the resolver. Depending on the action taken, the "strike" may be issued against a user, strikes will be displayed in pill-style next to the user name.
Addiotionally, I am planning on building a simple dashboard. So with that and the improved report action I hope modding will become easier. I think I will start a post soliciting input regarding report "actions"
Unfortunately reports are provided only to the instance, so tracking users who may have strikes in other communities may not come through unless we add it to the activitypub federation. I suppose in this way, "actioned" reports could send a notice to federated communities... I haven't gotten that far yet. My first goal is to improve the resolution action system. Strikes will come later. I see both of these as being core contributions rather than part of a separate system.
My only concern with federated strikes is each instance has different rules. If I post on my home instance and that post gets federated to another instance, my post might break a rule on the federated instance. I may not be aware of the rules on every instance that federated with my post.
For example, I have a community locally for jokes. I post an NSFW joke locally. The federated instance has a rule against NSFW content. They strike me for posting it. It syncs back to my home instance. Now I have a strike for a rule I didn't agree to.
I know you can hide & disable NSFW content but that's just simple example
It's a good point, but my main thought was that if an instance user is causing trouble somewhere else, I would want the instance owners to be aware. A "strike" doesn't necessarily reflect anything, but more of a mod tool way to see who are repeat offenders. At least, that was how I imagined it.