App creator pledges against enshittification

gui.do · May 3, 2026, 4:10pm

While researching business models that could work on atproto there are some obvious ones that won’t work on a technical/architectural level. Like you can’t really monetize the data in the PDS because it’s all completely open (as long as there’s no permissioned data, but probably not even after that).

That in itself already takes away a lot of room/incentive for enshittification (which is great), since when you do users can create or move to another app.

But still, I kept encountering models/tactics that I really didn’t like (not just for Sifa, but also in general): pay-to-rank, paywalled essentials, dark patterns at cancellation, “free for now, paywalled later.” The protocol can’t stop that. Only the people building can.

So I started writing these down as “pledges” that any monetization efforts should follow.

My question for other ATproto app builders: might this be a shared baseline across the Atmosphere? This is just a draft, but maybe something we could evolve to a shared thing?

This is the first product I’ve ever built. The first time I’ve ever priced anything. The first time I’ve ever written a pledge. I don’t know what I’m doing. Not in the helpless sense, but in the literal sense that I’ve never done this before, and I’m fairly sure I’m getting some of it wrong. I’d rather hear that from you now than apologize to a thousand subscribers later.

One thing that ís partially specific to what I’m building with Sifa is that the value IS the network that free users create and all of it depends on people who never pay anything. But of course there’s still costs associated to that and although I don’t aim to turn this into a big tech company, it’s nice to be able to pay for your mortgage and food

A paid plan is a way to pay rent on the infrastructure, but it’s not the reason Sifa exists. The pledge is a boundary that makes sure paid plans never starts cannibalizing the free thing it depends on. So maybe in that sense these pledges are mainly specific to apps int he same boat, but lets see:

The (draft) pledge, in full

# Monitization-Plan Pledge

## What the paid plan is:
An optional paid subscription that supports the App's development and unlocks things like cosmetics, analytics, and workflow perks for the subscriber's own profile and own (network) data.

## What the paid plan is NOT:
A verification, trust signal, credential, or rank.

## What we will never do:
- Pay-to-rank in search, directory, or feeds
- Paid messaging access (no InMail-style spam)
- Paywall who-viewed-me; private viewing free for all
- Gate essentials: data export, basic profile, follow, basic search, native mobile experience
- Sell verification (a paid plan is not a credential)
- Rank subscribers' content higher in feeds
- Lock data: cancel anytime, profile stays portable on your PDS

## PDS-data principle:
Anything in a users PDS is owned by them. A paid plan never gates display, access, or content of PDS data in the app. It could only gate App-controlled surfaces like themes, custom slug, accent colors, analytics computations, AI features, integrations with non-atproto apps and the membership badge itself.

## Price stability pledge:
Active subscribers are **grandfathered** at signup price forever. Price increases only ever apply to new subscribers. Cancellation breaks the grandfather, resubscribing later applies the current public price. Safety valves: payment-failure dunning protection, and a Pause Subscription option for life events.

# Feature pledges:
1. Grandfathered cohort gets new features. Anything added to the paid plan becomes available to all current subscribers at no extra charge.
2. No tier-creep below the paid plan. One consumer paid tier, ever. There migth be B2B / Enterprise plans.
3. Cancellation portability. All data stays on your PDS, a cancellation of a paid plan does not lead to removal of any PDS data and you will be downgraded to the regular free tier.
4. Currently free features stay available, but heavy usage may be capped. Caps before paywalls. Caps target the long tail (typical users should not notice). 90 days advance notice before any cap, with reasoning published in the public changelog. Subscribers get a higher (or no) cap. Existing data never held hostage; export remains free. Grandfathered subs get higher caps automatically.
5. Verification + trust labels stay free at the consumer layer.

Parts of the pledge are borrowed from people who’ve already had to make these decisions in the past that I used as inspiration:

Bluesky has a public business plan committing to services-led revenue and explicit refusal of attention-extraction ads.
Mastodon restructured as a European nonprofit and pledges no ads, no algorithmic feeds, no profile-pushing.
Ghost put their commitments in a legal foundation charter so the company can’t be sold or pivoted away from them.
Kagi Search runs as a Public Benefit Corporation with an explicit “you are the customer, not the product” stance. Pay-walled, not ad-walled.
Buttondown sells against bigger newsletter platforms with an anti-lock-in pledge that’s also the product: they let you leave with your data (take that Substack…)
Convert.com maintains a policy of respecting legacy/grandfathered pricing, meaning they do not force existing customers onto new, higher-priced plans.

BUT…

There are also cautionary tales. Cohost kept every pledge it made and shut down anyway because there was no revenue model under the pledges. Patreon’s grandfathered-billing trust got broken not by Patreon but by Apple’s in-app billing rules. Discord didn’t have a written pledge for “Nitro is cosmetic-only,” and it has quietly drifted into more functional gates (like HQ video). So yeah, reality or the partners you work with can still make you break you pledges…

How can atproto businesses survive? What’s still on the table?

So if Sifa or other apps won’t do what many other platforms normally do to make money, how do we survive?

Imho the pledge above is restrictive but not foreclosing. Several real categories of revenue do not conflict with it:

A consumer subscription with cosmetic and own-data perks. This is the bundle the pledge above is about: themes, custom URL slugs, analytics on your own profile or your network, services based on your own data. None of that changes anyone else’s experience of the app.
B2B / API access for compute and curated signals. Other ATproto apps and outside organisations sometimes need signals (e.g verified-professional-identity), aggregated trust scores, or pre-ranked search and would rather buy your pipeline than build it themselves. They pay for the compute, the SLA, and the support, not for the underlying (PDS) data, which stays free.
Enterprise / Teams variants. Organisations using your app internally (e.g. talent matching, employee directories, expert finding) have different needs (SSO, admin controls, audit logs, seat-based billing) than individuals. A different product wrapping the same data, sold with different mechanics.
Partnership and referral economics. When atproto apps drives signups to other (on- or off-protocol apps) or curates and hosts vetted rosters for partner products, there is referral or rev-share economics in play. This is not about licensing PDS data; it involves aligning incentives between two products that share users.
… (comment below with more suggestions )

I haven’t committed to a specific path yet, but my point is more that the pledges do (and should) not paint any app into a corner where the only options are advertising or shutdown. Real alternatives exist, none of which require breaking what’s pledged for free users.

Not asking about FEATURES or IF

To be clear: I’m not asking about features that should or should not be in a paid plan. This is about the frame the features sit inside since this frame is the part you can’t easily change later.

Also not asking whether to charge at all. I’m not 100% sure yet it will be paid plans for users, but if that plan moves forward, it will be according to the (improved variant of) pledges above.

I do think I’d much rather be funded by the actual users of a product, as opposed to a single VC that wants Sifa to grow 10× a year. I hope to retain that “luxury”. The question is how to charge in a way that is profitable (e.g. my family can eat and live) and that the free majority can still trust the service won’t turn to shit.

This could be more than a single app

Obvious structural worry: ATproto is open, lexicons/PDSes are public and protable…. Another AppView can read the same data and ignore every pledge here. If users don’t punish them for it, a pledge could become a unilateral disadvantage killing your app/business.

Three reasons I still think it’s worth making:

The pledge constrains how apps extracts value, not whether apps has value to extract. Kagi vs Google, Signal vs WhatsApp, Fastmail vs Gmail: trusted-and-paid survives alongside free-and-extractive.
Norms get set early. What gets pledged in the next year shapes what’s acceptable for the next decade. Going first is a brand position competitors must respond to.
Pledges get more powerful when shared. A unilateral pledge is fragile; a shared one becomes a coordination mechanism. A shameless competitor stands out as the bad actor, not the cleverer one.

Most of the pledge above isn’t Sifa-specific I think. And I’m not pretending this dissolves any worry. The case is load-bearing on users rewarding trust and on enough other builders making compatible pledges. It also feels a bit like we need to re-educate users on what it means to use apps and how to reward good apps, and that works much better when we do it together.

Push back!

I’m not the right person to write that pledge for an ecosystem I’m still relatively new to. But if you’re building an ATproto app and this resonates: let me know what you think! Thank you in advance for pushing back. That is the entire point of publishing this now, before any of it is real . And lets see if this could turn into something beyond just 1 app but as a baseline for atproto apps.

nikolas.ws · May 3, 2026, 4:29pm

This is good thinking, and something that I think we all have to grapple with to avoid a Cohost situation. My own thoughts about this question have centered on the cost-model of the applications themselves: with no storage costs, the commodity pricing that costs an operator are bandwidth and compute. If your application runs client side, then these also basically go away. To me, that means that the features that go behind a paywall have a commen requisite: bandwidth and/or compute heavy loads that run on the applications servers. This is where we anchor our value, and this is where the story to users has to be compelling.

iame.li · May 3, 2026, 6:19pm

I appreciate that you’re thinking deeply about this stuff, but I’m dubious there could be any enforceable mechanism for anti-enshittification other than open-sourcing the product. Even that doesn’t save you in many cases – see MinIO for a recent example, but at least then there can be an open-source fork and otherwise-enshittified users can at least coast on the most-recently-free version. Otherwise you sell out, and what, I go sue some multi-billion dollar PE firm for paywalling a feature that the long-gone founder promised not to paywall? I don’t see it.

I’d encourage you (and everybody else reading) to really think hard about whether open-sourcing your product is going to realistically preclude its success. Streamplace is open-source with a dead-simple single-binary deployment model and easy white label branding customization, and third-party nodes are still essentially nonexistant. Because we operate a big free one at https://stream.place, so why go to the trouble?

Bluesky has seen a few more forks, admittedly, but do the existence of https://witchsky.app/ and https://blacksky.community/ decrease Bluesky’s chances of success? To the contrary, the existence of third-party apps makes me more comfortable investing my time and energy in building my social presence on Bluesky because I can be confident that there will be alternatives if or when Bluesky PBC breaks bad.

gui.do · May 3, 2026, 7:09pm

You’re right that the pledge isn’t enforceable in any meaningful structural sense, and I should have been clearer about that. I never intended it as a contract. There’s no court, no recourse. I wrote it as a statement of intent that gets called out publicly if I (or others who adopt it) drift.

Pledges and open source work on different problems though. A pledge addresses pre-acquisition / pre-drift alignment; open source addresses post-acquisition / post-drift protection. Pledges aren’t only about handoff scenarios; they also constrain ongoing decisions while the founder is at the wheel and under pressure (revenue pressure to add an ad model, investor pressure to monetize harder, etc).

I think open source is a good answer, but not the only answer. There are other mechanisms that try to bind behavior beyond a personal promise:

Foundation / nonprofit / PBC structures (Ghost, Signal, Kagi) that encode commitments in the organization itself. Stronger than a pledge, weaker than open source on the fork-and-walk dimension, but they don’t require the project to be open source to bind the entity.
Statutes or articles of incorporation that limit what the company can do: things like “cannot be acquired without member vote” or “cannot rank by payment,” written into the foundational documents.
Distributed ownership models, like the community-owned investment / share structures Roomy is experimenting with (@erlend.sh could speak on that), or the older Mondragon cooperative tradition. If the people who would suffer from enshittification have a vote on the changes that would cause it, the pressure goes a different direction.

None of these perfect, but can all aid in the goal of not getting enshittified.

The realistic answer might really not be one thing, but a stack of non-perfect protections: pledge + organizational structure + open source where feasible + ecosystem norms. None of them work alone, but combined they raise the cost of enshittification enough that it stops being a profitable move.

erlend.sh · May 4, 2026, 8:36am

I like the sentiment, but to me as an app maker the most important pledge I have implicitly signed already is inherent to the atproto standard.

As a customer of atmospheric applications I know they’re strongly disincentivized to screw me over because I can very easily take my data elsewhere with a single button click.

As @iame.li points out, open source products take that implicit pledge one step further by opening themselves up to forking and remixing at will.

I don’t think that’s accurate. Pledges and open source licenses are both social contracts, but the former is purely symbolic whereas the latter is at least plausibly enforceable. And being open source is a strongly pro-socially aligning force by setting a structural precedent for transparency and commons enrichment.

dave.self.surf · May 4, 2026, 12:51pm

I recently passed the 1 year mark with building on atproto and things I value:

the company is the adversary (pfraze)
censorship-resistance (moderation-app-layer)
PBC/alternative in long-run (don’t fund stuff against the own interest of the customers)
building new experiences that are better than the incumbents for all parties (this looks different in each app and with every party involved).

Edit: business models look different depending on what you’re building. I would never go toward monetization of infrastructure because that will all be free (if not already). I would go towards fixing problems of apps that host data hostage:

(data estimates by Lumo AI (Proton))

bmann.ca · May 4, 2026, 5:10pm

I’ll note that Signal and Ghost are not really straightforward success stories.

Signal is a single entity that is vertically integrated. Some of the cryptography is re-usable and the source is open but you can’t really run other software that inter operates. Perfectly fine under their goals of security but we now have a single point of failure of one org.

Ghost is financially successful but manages its OSS only in so far as it supports their hosting service. It only supports Mailgun is one example. People are welcome to fork but there are no viable ones so far. This is totally within their right, but it’s not typically what we point to as a successful collaborative OSS project with inputs from many. (Ghost is very successful from a perspective of the foundation paying people to maintain it and I’m glad it exists, but the value mostly accrues to just the foundation)

More generally - we will have many types of business models on atproto. Including ones some people don’t like!

I don’t think the pledge is worth pushing at the moment, but rather finding what users see as valuable with your app. And, that a majority of your work should in fact be net-new-users, not “people who already have accounts”. That’s the big one that everyone needs, and how to get there will be different for each app.

holobrine.bsky.social · May 4, 2026, 10:08pm

I think we should consider how the economics is somewhat an inversion of what we’re used to in technofeudalism. Every cost the user takes on directly, like storage, is a cost the app developer no longer has to pay. The more the user feels like they are mostly paying for actual app development rather than underlying services, the better.

andyschwab.link · May 7, 2026, 11:12am

Thanks for initiating this conversation @gui.do - I’m learning a lot just reading through the discussion.

After reflecting, the TLDR for me: I think it would be better to take the spirit of the pledge and turn it into something that replaces trust with transparency, substituting specific prescriptive remedies with a template for descriptive state that helps users make better decisions.

The root issue is that builders lie, and not even intentionally. The question of what business models will look like for sustainable atproto projects is an open question; there needs to be room to experiment. And promises don’t matter if the business goes under, or gets bought, etc (as has been discussed already).

So rather than encouraging projects to explicitly ask for user trust, I’d shift to focus on transparency that can be asserted by a project and investigated and validated by the community. This has the added benefit of being a proactive, distributed activity: the community can produce transparency reports and descriptive analysis whether builders officially assert things or not.

At minimum, a transparency template would help builders understand what users care about, and help users assess pros and cons of using a tool. It might include:

Data Stewardship: how the app or service stores data. What user-related data is stored outside the PDS. Why? How can the user get or delete this data? Is data in the interoperable or proprietary? etc.
Team Composition: who is building the software and maintaining the business? Is this is one-person project, a small team, an open source initiative, or a large company? Is it all volunteer? How many paid staff are involved?
Funding Sources: how the app or service is financially sustained. Is it in the black right now? What is the runway if not? Is it operating on VC money, grants, donations, paying customers, a multisided ad market? etc.
Usage Enforcement: what powers does the team have to restrict access or service, and under what conditions? Under what circumstances can enforcement result in permanent loss of data or nework capabilities?
Redress Mechanism: how to users challenge enforcement actions and/or exit without loss of data or network capability?
Credible Exit Score: a simple checklist that shows the exit criteria for this app - this overlaps with others here, but is an example of a way to turn this idea into a few concrete artifacts that users can easily digest to make decisions - and that can be validated by the community.
Maturity Attestation: a enumerated set of maturity categories with simple definitions that help teams tell users the state of a product or service. Lots of atproto stuff is very alpha right now, which is fine, but that can make it hard to understand the risks of attempting to use it or build on it as a dependency in your own business.

I think this can start very simple (much simpler than I’ve outlined here). Thanks for reading through, hope this isn’t too tangential

jasonbu.online · May 19, 2026, 7:29pm

Super new on the community forum but I’ve been on Bluesky/developing for quiet awhile. I came to almost identical conclusions independently. I’d already written and committed to a version of this pledge for Kevara before stumbling on this thread: one consumer tier, caps before paywalls, PDS data never held hostage, cancellation portability.

The piece I’d add to the discussion, and why I think the pledge is more than symbolic, is that it has a natural enforcement mechanism most pledges lack: the AT Protocol itself. You can’t really pay-to-rank on a firehose. You can’t lock profile data that lives on someone else’s PDS. The architecture makes several of the worst enshittification moves structurally awkward, which means the pledge isn’t just a statement of intent, it’s a description of what the protocol already pressures you toward. Mostly for the “what stops someone from ignoring it” concern that’s come up above in the thread. I like what Andy put down in terms of transparency.

On Principle 5 (verification and trust labels stay free), I’ve been building toward this.

This is where I can offer something concrete rather than just agreement. This past weekend I published the public specification for Kevara’s Trust Gateway (Trust Gateway - Kevara Docs), a verification layer that signals via Ozone labels on AT Protocol.

What’s live today: a public Ozone labeler (labeler.kevara.app), label query via com.atproto.label.queryLabels, WebSocket subscription for real-time label state, and automatic revocation when a credential lapses. What’s specified and on the roadmap: credential-level revocation monitoring, machine-readable revocations, OID4VP presentation flow for external verifiers, and Open Badges 3.0 / CLR 2.0 issuance from institutional partners.

The verification label (kevara-verified) is free. It’s issued after review via a Keytrace flow, signed by our Ozone labeler, and portable across any AT Protocol client that subscribes. It is explicitly not part of the paid plan. The paid plan(when/if I finish it) is cosmetics, analytics, and workflow perks, not credentials.

I’d also point to the atmosphere-verification statement that Gui, Emily, and Sherif have put together, open for feedback until 31 May: statement.md at main · sherif.eurosky.social/atmosphere-verification

I’ll be co-signing that as well (just getting my thoughts arranged). I think the two documents sit well together, the pledge defines the commercial boundary, the statement defines the trust infrastructure that boundary protects (transparency). The ‘Trust Gateway’ is our working attempt at building that infrastructure.

Kevara uses id.sifa.* as its foundational professional profile lexicon. Happy to compare notes on implementation, economics, or where any of this gets harder. I’m still learning and break things often.

Thanks

gui.do · May 19, 2026, 8:19pm

Hey Jason, welcome to the forum as well and thx for commenting!

Yeah, you are right! And that brings me to where a pledge can also contribute: it’s a shared communication mechanism to the non-atproto world.

When I try to explain what makes atproto apps different, I usually burn the first ten minutes unwinding twenty years of internalised assumptions about how social apps “are supposed to work” (and if I dare mention “protocol” or “PDS” most people are already gone ).

Among developers it ratifies what the protocol already pushes us toward. But toward the outside world it can be a shared brand/marketing message, probably the simplest way to show people who’ll never run a PDS what the Atmosphere is all about.

jasonbu.online · May 19, 2026, 8:47pm

Absolutely. Every “new” technology goes through this phase. We saw it with crypto trying to become a mainstream payment mechanism, and even with something as simple as tap debit cards years ago and the Internet (information super highway, the www). The tech itself is only part of the battle. The bigger challenge is unwinding decades of assumptions about how systems are “supposed” to work and just the terminologies alone could take you hours.

That’s where shared education and a common vocabulary and lexicon (spoken and online) matter. If one app calls something a widget, another calls it a card, and a third calls it a module, users just experience confusion. Shared terminology across creators helps normalize behaviour, lowers friction, and speeds adoption because people stop having to relearn the same concept in every app. So, the approach is two fold.