1. The feed
A few namespaced elements: provider, accepted payment processors, tiers, per-item access state. Nothing else changes.
A small, namespaced extension to RSS that lets any publisher charge for content and any reader unlock it. Three moving parts, eight conformance levels, MIT and CC-BY-4.0 throughout.
A publisher who adopts om adds a handful of namespaced elements to their existing RSS feed. That is the whole protocol surface a reader has to recognise to unlock paid content.
<rss version="2.0" xmlns:om="http://purl.org/rss/modules/membership/">
<channel>
<title>Field Notes</title>
<om:provider>https://fieldnotes.example</om:provider>
<om:discovery>https://fieldnotes.example/.well-known/open-membership</om:discovery>
<om:psp id="stripe" account="acct_..." />
<om:tier id="paid" price="USD 8.00" period="monthly">Supporter</om:tier>
<om:offer id="supporter-monthly" tier="paid">
<om:price amount="8.00" currency="USD" period="P1M" />
<om:checkout psp="stripe" price_id="price_supporter_..." />
</om:offer>
<item>
<title>Members-only investigation: the warehouse fire</title>
<om:access>locked</om:access>
<om:preview>The fire investigators' report was filed two weeks before...</om:preview>
<om:unlock>https://fieldnotes.example/unlock/2026-04-fire</om:unlock>
</item>
</channel>
</rss>
A reader that does not understand om keeps working unchanged. A reader that does, presents previews and unlock prompts. Compatibility-first.
A few namespaced elements: provider, accepted payment processors, tiers, per-item access state. Nothing else changes.
One JSON document at .well-known/open-membership, composing with RFC 9728. Token endpoints, auth methods, revocation policy, privacy posture. One fetch, no negotiation.
A URL token, an OAuth bearer, or a W3C Verifiable Credential, depending on the publisher's conformance level. Portable across reader apps; export shape defined.
Without unlinkability, every publisher in the ecosystem accumulates a profile of every cross-publisher subscriber. om solves this with a Verifiable Credential profile (OM-VC, and OM-VC-SD using BBS+ selective disclosure) that lets a subscriber prove "I am a paid member of this tier" without revealing any stable identifier that publishers could correlate against each other.
Pseudonymous mode is built for publications where a subscriber list could be subpoenaed. Investigative journalism, medical and mental-health publications, legal-research services. The credential layer is the part of the privacy story the protocol can address.
Implementers commit to a level, the test suite verifies the level, and the level is what they advertise. Levels are cumulative.
| Level | What it covers | Implementer effort |
|---|---|---|
| 1 | Parsing the namespace; previews; signup-URL display | one afternoon |
| 2 | URL token auth; unlock endpoints; publisher-managed groups | 1 to 2 weeks |
| 3 | OAuth bearer + DPoP; time-windowed access; SCIM groups | 2 to 4 weeks |
| 4 | OM-VC (W3C Verifiable Credentials) presentation auth | 3 to 6 weeks |
| 5 | Commerce: PSP declarations, offers, checkout, entitlements, gifts | 2 to 4 weeks |
| 6 | Value-for-value: time-split recipients, Lightning composition | 2 to 4 weeks |
| 7 | OM-VC-SD pseudonymous mode (BBS+ selective disclosure) | 4 to 8 weeks |
| 8 | Bundle aggregation across publishers | 2 to 4 weeks |
Most publishers and reader apps will implement Level 1, 2, or 5.
Read the spec, look at the Ghost or WordPress reference implementation, and open an issue describing your setup if you want help onboarding.
Reference pluginsStart with the Level 1 parsing tests and the Miniflux patch plan. Level 1 is one afternoon.
Test suiteThe appendices in spec/ cover ActivityPub co-existence, the Platform Adapter Profile, syndication mappings (Atom + JSON Feed), and the subscriber portability format.