The What
Two days ago, RadPress didn't exist. It started as a throwaway idea in a Telegram chat, turned into an architecture session, and by the time I'm writing this — on RadPress itself — it's a live, feature-rich blogging platform where your ATProtocol identity is your login, your PDS domain determines your features, and every tip flows through XRD without the blogger ever touching a wallet.
This is the build story.
The Spark
The idea landed in a Telegram conversation the way most good ideas do — sideways. We were talking about the quack.space ecosystem, about how the tip cart and Radix Connect integration already work, about how ATProtocol handles are these beautiful portable identities that nobody's using for anything beyond social posting. And someone said something like, "why isn't there a blogging platform that just uses your handle?"
That's when it clicked. Not just "login with ATProto" — that's table stakes. The real insight was: your PDS domain suffix IS your subscription tier. If your handle ends in pds.quack.space, you get premium features. If it ends in rlydev.social, you get whatever that community decides. If you're on bsky.social, you get the free tier. No Stripe. No credit cards. No "upgrade to Pro" buttons. Your identity is your membership.
WordPress has spent twenty years building a subscription and payments layer on top of a blogging engine. We skipped all of it by leaning on two things that already exist: ATProtocol for identity, and Radix for value transfer.
The Architecture That Makes It Work
RadPress has a two-layer content model, and this is the part I'm most proud of because it threads a needle that most platforms get wrong.
Layer 1 is ATProtocol records. When you publish a blog post on RadPress, the markdown text, title, tags, and metadata get written as a record on your PDS. You own that record. It lives in your repo. If RadPress disappeared tomorrow, your content is still there — any ATProto client could render it. Your comments live on your PDS too. Your subscriptions to other blogs live on your PDS. It's all portable, all user-owned.
Layer 2 is the RadPress presentation engine. This is where your theme lives, your custom CSS, your hero images served from a CDN, your SEO configuration, your analytics, your tip button settings. None of this touches the PDS. It lives in RadPress's database, keyed to the ATProto record URIs so the two layers merge seamlessly at render time.
The result: you can leave anytime, but you'd never want to. Take your skeleton across the moat — the plain text, the comments, the subscriber relationships — it's all in your PDS. But the experience? The theme that makes your blog look stunning, the layout that took you an hour to customize, the tip integrations, the analytics history? That's RadPress. That's the value we earn, not the data we hold hostage.
This is how lock-in should work. Honest retention through value, not through data capture.
Hub and Spoke: Why RadPress Doesn't Touch Crypto
Here's where the quack.space architecture pays off in a way I didn't fully appreciate until we built it.
RadPress is a spoke. quack.space is the hub. All payment functionality — tipping blog authors, tipping commenters, purchasing premium features — routes through quack.space's existing cart and checkout infrastructure. RadPress never imports a wallet SDK. Never builds a transaction manifest. Never touches a Radix address.
Here's the actual flow when you tip an article on RadPress:
- You're logged into RadPress with your ATProto handle and app password
- You click "Tip 1 XRD" on an article you liked
- RadPress uses your session to write an
app.quack.tipcart.itemrecord directly to your PDS - That's it. You keep reading. You tip three more articles. Each one is another record on your PDS.
- Whenever you feel like it — maybe hours later — you go to quack.space and open your cart
- Everything's there. Your RadPress tips, any Bluesky tips you added through quack.space directly, all of it
- One checkout. One Radix Connect transaction. Done.
- quack.space fires a webhook to RadPress confirming each tip. RadPress updates the tip totals on the articles.
The critical insight was that we don't need an API between RadPress and quack.space for payment initiation. The user's PDS is the shared data layer. RadPress writes cart items to the PDS using the user's own access token. quack.space reads cart items from the same PDS. ATProtocol is doing the integration work for free.
The entire quack.space build for this integration was: accept cart items that don't have a pre-resolved wallet address (RadPress only knows DIDs, not Radix addresses), resolve the address at checkout time, and fire a webhook when RadPress-sourced items complete. Zero new API endpoints. Modifications to one existing file. That's the power of building on the right primitives.
The Secret Shopper Problem
Here's something we caught during the architecture phase that most platforms would have missed: ATProtocol repos are public. Anyone can enumerate your records. Which means if you add a "Buy Premium Theme" item to your PDS cart and then go make dinner before checking out, anyone scraping ATProto repos can see that you're shopping for premium themes.
For tips this is fine — maybe even good. Social tipping is a feature, not a bug. But for purchases? Nobody wants their shopping cart to be public.
So RadPress has a dual cart system. Quack Direct is for tips — instant write to the PDS, shows up in your quack.space cart immediately, fully public. Secret Shopper is for purchases and anything else you want to keep private — stored in RadPress's database, completely invisible to the ATProto network, transferred to your PDS cart only when you're ready to check out. The window between "items appear on PDS" and "checkout completes" shrinks from hours to seconds.
What's Actually Running Right Now
This isn't a whitepaper. RadPress is live. You're reading this on it.
Phase 1 shipped with ATProto authentication, blog creation, a full markdown editor with live preview, publish-to-PDS flow, draft management, public blog rendering, domain tier enforcement, Quack Direct tipping, webhook processing, theme support, and RSS feeds.
Phase 2 added the secret shopper cart, federated comments, blog subscriptions, the admin dashboard, analytics, scheduled posts, custom CSS for gated tiers, SEO tools, and the purchase flow for buying additional blog slots and premium themes.
The domain tier system is live. If you log in with a pds.quack.space handle, you get two blog slots and the full feature set. Unlisted domains get one blog and the free tier. The admin dashboard lets me add new domain tiers without deploying code — when a new community PDS wants in, I add a row and toggle their features.
What This Means for the Ecosystem
RadPress proves something that's been theoretical until now: the hub-and-spoke model works. A spoke application can be feature-rich, fully independent, and completely free of Web3 infrastructure while still participating in the XRD payment economy. The only thing connecting RadPress to Radix is a few lines of code that write cart items to a PDS and a webhook endpoint that receives payment confirmations.
This matters because it lowers the bar for the next spoke. The pattern is established. Any ATProto application can now integrate quack.space tipping by writing a handful of records to the user's PDS. No SDK. No wallet integration. No blockchain knowledge required.
The blogging platform is the first spoke. It won't be the last.
What's Next
We're designing an agentic developer marketplace where AI agents build themes, widgets, and components for RadPress bloggers — all paid in XRD, all flowing through the same cart infrastructure. Agents submit work programmatically, get validated automatically, earn micropayments at scale. The economics of theme development invert completely when your developers are autonomous and your payment rails handle fractions of a cent.
But that's a post for another day. Right now, I'm going to hit publish, watch the ATProto record land on my PDS, and tip myself for writing it. Because I can.
RadPress is live at radpress.fyi. Log in with any ATProtocol handle. Build your blog. Own your content.
quack.space handles the rest.