Proposal for a Node/Aggregator Moderation System

[Ipstenu]

Related to #11

TL;DR - Moderation as Infrastructure

The docs (and this post) are long out of necessity. There are a lot of moving parts involved. But to summarize, the goal of moderation is to provide a shared infrastructure that:

• Flags known malicious or harmful content
• Label products and distributors with meaningful trust signals (e.g., “verified”, “deprecated”, “security-risk”)
• Enable directories to apply transparent, consistent filtering based on community-defined criteria
• Offer users control over the moderation standards they subscribe to and follow

There's a link at the bottom, be aware this is a first draft and needs work! Normally I'd share this next week, but given the discussions are running so fast, it seems sensible to do it now.

Intro

I’ve spent nearly two decades deeply involved in the WordPress ecosystem, including serving as the team representative for the WordPress.org Plugin Review team. That experience has given me a unique, front-line perspective on how the current centralized system works. I know its strengths, its limitations, and the real impact it has on developers, users, and the broader community. I’ve seen what happens when the burden of trust, safety, and scale falls on too few people, and I understand why things have evolved the way they have.

This proposal comes from that experience and my belief that we can build something better.

I want to create a federated plugin ecosystem where anyone can host and share code, with FAIR providing shared rules and transparent moderation to keep the system open, safe, and accountable.

Proposal: A Safer, Fairer Future for WordPress Plugins and Themes

The WordPress ecosystem thrives on openness and collaboration. The current system for managing plugins and themes depends on a small group of volunteers reviewing an overwhelming number of submissions. As the ecosystem grows, this model has become increasingly unsustainable.

Furthermore, the guidelines of the WordPress.org directories are prohibitive and limited by necessity. Guidelines like that are essential for legal protection and consistency at scale. By defining and enforcing their own clear participation rules, an Aggregator ensures that Developers and users alike benefit. All participants will know what standards are in place, what behaviour is expected, and how decisions are made.

We don't need a replacement for these policies, but a framework that allows multiple sets of guidelines to coexist. Each community or directory can define its own values while still participating in a shared, accountable ecosystem.
FAIR Protocol introduces a new, decentralized model: a federated network where anyone can operate a repository (called a Node) to host and share plugins or themes. This approach supports innovation, resilience, and community ownership. However, with that openness comes the need for shared standards and accountability.

FAIR would take on the role of an advisor not a regular. Instead of being the gatekeeper, a FAIR Working Group can act as a coordinating body that maintains technical guidelines, community norms, and tools for trust and transparency.

By using a decentralized moderation platform (I picked Ozone because it already works with AT Proto) we can apply clear, public labels such as “verified,” “deprecated,” or “security risk” to plugins, themes, and Nodes. Those labels won’t block access to content, but will allow users, Nodes, and Aggregators to make informed decisions based on shared trust signals.

We can also implement a threshold-based reporting system, where plugins or Nodes flagged by a large portion of their users will trigger reviews by their hosts (plugins alert Nodes, Nodes alert Aggregators, and so on). Anyone affected by these actions will have access to an appeals process, and all moderation actions will be logged transparently.

In this future model:

• Node operators will be responsible for the content they serve
• Aggregators will be responsible for how they present and rank listings
• FAIR will provide shared rules, technical guidance, and federation-wide trust infrastructure

This system will preserve the freedom and diversity of the WordPress community while establishing practical tools to manage abuse, misinformation, and harmful code. It will give us all the tools we need to build a plugin ecosystem that is open and also safe, fair, and future-ready.

Call to Action

I’m asking you to read through the document I linked to below, question the assumptions, spot what’s missing, and share your perspective.

• Does this proposal sound sane?
• Does the concept of the proposed systems look feasible?
• Do the guidelines look reasonable?
• Does the data privacy section cover the right issues?
• Does the appeal process sound sustainable?
• Are there risks I’ve missed?

https://docs.google.com/document/d/1-cy26-XViofGlYaWcZ8NRS7vonJlM5boqnq8DtKOC-I/edit?usp=sharing

(Everyone should be able to suggest changes and comment, if not, tell me as a reply here!)

Leave comments in the docs, ask questions here. Let’s do this!

PR: #14

Leave comments and questions here, critique the PR. Let's do this thing!

[afragen]

@Ipstenu this is absolutely brilliant. I just finished reading through the doc.

[timnashcouk]

One aspect of such moderation that always concerns me is how to handle a individual node going rogue, if the node not the aggregator are solely responsible for moderation then the only tool an aggregator would have is to defederate from the node. This makes sense where there is obvious abuse but how would the aggregator know?

I'm wondering if at the same time as standardising a moderation layer at the node, if building moderation for nodes themselves and a way beyond simply binary federated/not federated. This might be outside of scope of the current thinking, its also one with no simple answers. But until we have a way to trust the nodes, the nodes policing themselves is open opportunity for abuse.

[Ipstenu]

That’s why the moderation system is multi fold. Nodes and Aggregators are automatically monitored, so if a node gets reports and does nothing, the aggregator would know. There’s also the threshold reporting.

[WPBarista]

Automatically monitored by who? At the end of the day, doesn't some entity need to be responsible for labelling insecure packages? Labeling (fair system) is better, I suppose, than preventing inclusion in the node(current system). Better for distributors, but not users. I can see why the current system errs on the side of caution.

[Ipstenu]

There's a whole "FAIR Oversight" section :)

• Packages are monitored by their Nodes
• Nodes are monitored by the Aggregators they're included on.
• Aggregators are monitored by the 'parent' group (an Aggregator of Aggregators).

In the case of the 'official' (default) FAIR managed Aggregator of Nodes and Aggregators, it would be a Working Group assigned to handling reports. And in fact, the labelling system has thresholds built in (proposed to build in...) that would auto-remove a package or Node if it reaches a set amount.

Let's say you've added Default Aggregator (the one run by FAIR), Company Aggregator (by a specific company), and Shady Aggregator (a seemingly good but really evil Aggregator) to your WP site. Obviously the Default Aggregator is monitored by FAIR, and if a Node is bad they'd label it.

But what about Shady? Who monitors them? (see the "Integrity" section)

Reports submitted from the WordPress admin interface must be sent both to the Aggregator, Node, and a designated federation monitor (e.g., FAIR). This ensures that reports cannot be quietly discarded or undercounted by a single Node or Aggregator.

If you're connected to the Default (FAIR) Aggregator, you get their Monitor. You could also add in Monitors from other companies. That's where having this open API comes into play. Someone like PatchStack or WordFence could make a plugin/service that collects those or just uses the mentioned Public Metric Feed to flag a Node/Aggregator as dangerous.

[joehoyle]

Thanks, this looks great! Second time writing a comment as I think I misunderstood in the first instance! As I understand it now, the moderation system is an independent platform to the aggregator, so this proposal doesn't address the obligation / policies of an aggregator to what degree it may action the moderation labels (e.g. outright block a package that is malware).

I do have questions about how a FAIR aggregator might handle cases such as malware and phishing / name squatting, but I think this isn't the place for I guess!

[rmccue]

this proposal doesn't address the obligation / policies of an aggregator to what degree it may action the moderation labels (e.g. outright block a package that is malware).

There's also a question of whether an aggregator does or a client does. In the Bluesky/AT Proto model, infrastructure generally stays neutral (except for explicitly illegal material) and leaves the choice to the client:

In our case, if our aggregator is also a public listing (ala .org/plugins/ or AspireExplore), we might want to combine those.

[joehoyle]

Mmm yes, I can imagine in the cases of outright malware or legal that the Aggregator would need some way to remove content. I don't know if that needs to be part of the protocol though, perhaps more a question of features for the open source aggregator.

I can see there being a rush of malicious fake plugins masquerading as official plugins at launch if this is not ready from the start though, and having things already in place to handle that seems important. Initial impressions count for a lot and all that.

[rmccue]

We might also want to stage the process of federation; for example, Bluesky started with only federating with members who were in their Discord, then opened later - we could do the same.

[joehoyle]

Ah nice, like that idea!

[Ipstenu]

As I understand it now, the moderation system is an independent platform to the aggregator, so this proposal doesn't address the obligation / policies of an aggregator to what degree it may action the moderation labels (e.g. outright block a package that is malware).

The moderation system is but... All Aggregators have to meet the minimum expectations:

• Contact and privacy requirements
• Integration with federation-wide moderation systems like Ozone
• Compliance with data protection laws (e.g., GDPR)

Meaning if they're not integrated with a moderation system, then the FAIR plugin can auto-flag all Packages found via that Aggregator as 'untrusted' or at least 'uncertified by FAIR'

We could even take that a step further with a list of 'known naughty Nodes/Aggregators' and have a big warning "USE AT YOUR OWN RISK."

[WPBarista]

This is brilliant - THANK YOU!! I studied this as best as my poor brain can... I'm having a hard time understanding 3 things. If these should be obvious, I may not be the right audience for this. Non-coder here!

"Each community or directory can define its own values while still participating in a shared, accountable ecosystem.

A 'shared accountable ecosystem' sounds like what we have. It depends on who we're accountable to. :) accountability to the node's community doesn't help a regular user who searches in Agreggator, unaware of the node's community.

Label products and distributors with meaningful trust signals (e.g., “verified”, “deprecated”, “security-risk”)

As a user, I need to trust the labels- do they come from one source? If I accidentally find a plugin on a node that does not align with my values/standards, how would I know that?

FAIR would take on the role of an advisor

Advisors can be ignored.

Node operators will be responsible for the content they serve. Aggregators will be responsible for how they present and rank listings

Responsible to who? That needs to be some entity with enough power to serve up repercussions. Without a real and perceived downside, node's will equal malware.

[Ipstenu]

A 'shared accountable ecosystem' sounds like what we have. It depends on who we're accountable to. :) accountability to the node's community doesn't help a regular user who searches in Agreggator, unaware of the node's community.

Currently we have a Closed System.

We are accountable to one group, and if we're unable to be hosted there for whatever reason (keep in mind, premium plugins cannot be hosted on .org if they have license checks) then we're building out our own systems which you're trusting and are accountable to themselves. Because each plugin has to have the code to update/manage individually, each plugin is accountable to itself.

So really this isn't a change it's just clarifying "Hey, if you download from X, they're accountable."

You're trusting the source of the plugins you find today on the Single Authorized Distributor (WP's current model). And while that distributor can de-list, but that doesn't flag anything on your end nor does it remove a plugin. The FAIR system would automatically label a plugin.

Instead of having to know about the community, you the user would be able to flag/report packages from inside WP-Admin and those reports are sent to:

• The Node (who hosts the package)
• The Aggregators (who list the node)
• The Moderation Services attached to the Aggregator

(See more in my reply to your next sections)

As a user, I need to trust the labels- do they come from one source? If I accidentally find a plugin on a node that does not align with my values/standards, how would I know that?

How do you know that today?

So let's say you're using Default Aggregator (the FAIR provided one), and a Node is removed. Because the Node is removed, all Packages (plugins) that are installed via that node are automatically flagged as 'not available because of Node removal'

What if another Aggregator you have connected to (Shady Aggregator) also includes that Node? The top-level Aggregator (the Default one) would still be flagging the Bad Node in your WP Admin. "Flagged by Default Aggregator"

Responsible to who? That needs to be some entity with enough power to serve up repercussions. Without a real and perceived downside, node's will equal malware.

First of all, that's an existing problem. There's nothing to stop someone from downloading individual plugins and themes today and using them, Nulled or not.

The biggest penalty is defederation (meaning an aggregator or node is blocked from being discovered/used by the FAIR system).

Now, who watches the watchers? Monitors.

Like I said in another reply, if you're connected to the Default (FAIR) Aggregator, you get their Monitor. You could also add in Monitors from other companies. That's where having this open API comes into play. Someone like PatchStack or WordFence could make a plugin/service that collects those or just uses the mentioned Public Metric Feed to flag a Node/Aggregator as dangerous.

Now we're handing more power to scanning services, who can also flag packages and nodes and aggregators.

What happens if an Aggregator isn't listed on any Monitors?

We can build in a check for that :) "Warning: This Aggregator has not listed any monitors, meaning it cannot be verified and confirmed as following FAIR guidelines, Use at your own risk."

[WPBarista]

Seriously, it never occurred to me that all the premium plugins I download are accountable to themselves! I preach relentlessly to know and trust plugin authors.

Somehow theory-brain doesn't communicate with day-to-day brain.🤯🙄 Thank you for your insight and gentleness, even if you're eye-rolling silently. 😋

[Ipstenu]

I'm not eyeballing at all! In fact, it's helpful to me to see how your brain works, since I can explain it better in our docs :)

But yeah, it's wild when we think about accountability today for premium plugins. Making this defederated but monitored will help you out there. Also it means .org can have a repo they run which is monitored and publicly accountable so you could get the best of both worlds!

[Ipstenu]

Update - I took comments (from here, the doc, social media) and made #14 so there's a grown up PR.

You can still comment here :) I'm watching!