we’re currently designing a commons moderation service at Eurosky. The idea is simple:
Developers can register their apps with Eurosky.
Eurosky acts as the endpoint where participating apps can send content reports.
Eurosky then provides moderation decisions that can be shared across apps using the same lexicon.
This raises a fundamental question about who should pay for moderation.
The problem
Producer apps create content. If a post is harmful, it originates here.
Consumer apps show that content to their users. If they don’t filter, their users experience the harm.
Eurosky only sees the reports that apps send in. We do not have access to developer APIs, so we cannot easily measure how “big” a consumer app is (e.g. DAUs, impressions).
Abuse risks
If only consumers pay → a producer could flood the ecosystem with cheap spam, shifting moderation costs onto others.
If only producers pay → large consumer apps could free-ride, showing moderated content without contributing.
If we try to split costs, we need a transparent, enforceable way to do it without centralizing control.
Possible models
Per-report billing: Apps pay for each moderation request they submit. Simple, usage-based. Risk: consumers may under-report to save money.
Flat tiers / subscriptions: Apps self-declare scale (indie / mid / large) and pay accordingly. Works with trustmarks and occasional audits, but relies on honesty.
Commons pool: Apps contribute to a shared fund proportional to their usage or user base. Moderation costs are shared, but requires agreement on metrics.
Proof-of-display (future idea): Apps cryptographically prove when they display a record, so moderation costs can be tied to exposure. Complex, but potentially fairer.
Ask
We’d like to open this up to the community:
How do you think costs should be split between producer and consumer apps?
What’s a practical first step we could implement now, given Eurosky only sees moderation reports?
Would developers be comfortable with a per-report model as a starting point?
Our goal is to make moderation sustainable without discouraging small apps or enabling abuse. Looking forward to your thoughts.
Are we gonna follow a subsidised or business venture model, or a mix?
Do we have a rough idea of the costs?
What happens with shared lexicons?
AFAIK, most tech leaders (CTO, VP, Head of) I know would prefer flat tiers whenever possible - it just avoids headaches in planning funding e.g. “500$/month is ok, let’s just pick the Enterprise plan” vs “oh s*** I need to figure out the volume of API calls my app will make to roughly understand costs?!?!?”
We are also prob not gonna start with thousands of clients (at admin level).
Do you think we can iterate? e.g.:
let’s put things in place and figure out costs from real data
monitor usage for heavy consumers/abuse
initially split costs between customers and backers
later we update pricing strategy in accordance with our partners
I’m a bit confused about how these two are different; won’t they typically be the same app?
I think both end-users as well as app/platform-makers should be paying their fair share. I can come back to the app-makers once I’ve understood your breakdown better.
As a regular end-user though I’d love to start paying $5/month in exchange for European PDS hosting coupled with moderation, provided by a Data Cooperative with an organizational structure similar to Northsky.
No, and this is the kicker. App 1 and App 2 could use the same app.commons.post lexicon - both featuring and displaying the same content. Much like most Bluesky-based apps do so today. But the content that gets moderated in App 1 does not have to be moderated again in App 2. that’s why they‘re interoperable and can share the moderation costs.
Let me chime in here from a developer standpoint (so I guess, in a way, a producer) and say that from a pricing perspective, it has to be affordable for the average Joe Schmoe one man show. And stay affordable.
I’ve had this experience with a few side projects where initially the costs were bearable, but then within a week things got popular somehow, and suddenly I’m looking at way higher bills. Luckily I could eat that, but I can imagine there’ll be cases where people can’t.
Whatever method is chosen, in my opinion it should not now, or ever, be a barrier to entry. Quickest way to kill off any sort of innovation is to tell people they’re too poor, basically.
Personally, I wouldn’t want to go near a per-report fee with a 20ft barge pole, because it only takes one asshat and some scripts to hammer through a bunch of fake reports and I’m left holding the “oh shit, I owe Eurosky a bunch of money I don’t have/didn’t want to spend right now”. Or if you do a tiered thing where it’s 1-5000 reports/month for $x, I don’t want to end up forgetting to put a rate limit or some other stuff on a report endpoint and blow through all my reports in a day.
To be honest, personally I think commons moderation should not be a profit center; I’m fine with signing up for it for a flat (affordable) fee, and the cost of the commons moderation will have to be covered by that, and potentially other sources of income.
@erikologic.bsky.social This is one of the components to CoCoMo. As an app developer I need to provide content moderation features in order to get access to App Store distribution. So CoCoMo shall be the recipient of these reports. Scanning the lexicons (proactively) and emitting labels is something CoCoMo should do, but it’s not mandatory. The same goes for the PDS shielding / remote controlling.
The most important part will be to provide an endpoint for moderation requests. And to @angrydutchman.peedee.es : ideally this should be a commons thing - Eurosky is planned as a non-profit, so this will not be your typical SaaS. This RFC is rather to feel the room for the case that funding is sparse and we need to be self-sustaining.
Understood, it’s just I wanted to sort of put it out there that even given the above, if you need to price it at a point where it’s out of reach for the average one-man shop, it’s going to either end up unsustainable, or not very commons
I’m not always as clear as I should be, I blame it on being on the spectrum and the pot of coffee I had when I wrote my post.
There might be ways to accomodate different needs/setups. Key is to make CoCoMo self sustaining in the medium term as grant funding will only go so far and for so long, so will need to cover costs + some extra to reinvest to improve the platform and service. It has to be substantially cheaper than a commercial alternative or an in-house solution (I am thinking 30% or lower of the in-house cost). It might be possible though to have different tiers, e.g.:
free or very low cost for community/non-profit projects up to a certain size/usage
low/subsidized cost for pre-funding startups
the first two cases maybe supported by grants
tiered depending on a combination of number of users and traffic volumes
perhaps additional cost for new lexigons?
We’d need some strong guardrails in the system too. E.g. participants could commit to ban PDSs that are regularly spamming
One long-term model is pools of funding for specific types of apps (eg, collection of lexicons), and apps would pay in to those pools proportionate to the profit them make, or perhaps funding they have raised. The pools would be a budget that funds moderation work relevant to that data. The budget would be proportional to the number of reports. I think it is important to not have different app types subsidize each other too much: some app types (like video or microblogging) cost a lot more than others (like blogging).
Measuring profit and which apps might be hard in theory, but I think in practice it can be sniffed out fairly effectively, and the other devs participating would be motivated to track that down.
Splitting out baseline stuff might help: basic abusive image scanning and some baseline anti-spam can be almost fully automated and app-agnostic.
Just to mention some of the things that can be measured in the network:
PDS operators can see use of specific apps by OAuth client_id
PDS operators could track which OAuth clients are submitting reports to which moderation services
PDS and AppView operators could see which labelers are being used (based on request headers)
Anybody can see total volume of data (records) being created
in a fuzzy sense, anybody can investigate the ecosystem and assess which clients exist and are popular (though this is subjective, not quantifiable numbers)
I think the pools make a lot of sense. It’s the metrics which would determine how much everyone would have to contribute to the pool that I’m most interested in.
Using number of reports could incentivize devs to underreport to keep their costs low. Any PDS metrics are out of scope since people may not be using the Eurosky PDSs. Same goes for AppViews.
IMHO we need some way to determine how often content was surfaced across apps. That way the app that has 1mio users pays more into the pool than the app with 10k users. Maybe an SDK that tracks view metrics anonymously and reports back to Eurosky?
