The AT Protocol community is fixated on the wrong things. Everyone's caught up in vague web3 "decentralization" rhetoric, or worse, throwing around "sovereignty" like it's some aspirational ideal.

Sovereignty does mean something—it means border police brutalizing people because they've decided someone doesn't belong based on arbitrary criteria. That's what sovereignty is in practice. So when I see "data sovereignty" thrown around in our community, I only feel dread. The internet is and will be borderless, we don't need to be building borders on it. Trust and authenticity is worth building though, Authenticated Transfer.

Almost nobody appreciates what authenticated transfer enables. Look at how many apps in our ecosystem subscribe to the Jetstream, which explicitly strips away the signed data. That's if they even bother ingesting from the network at all. Too many apps don't have any form of actor-agnostic ingestion and only serve and push data from their SQL db while the data in your repo is just cosmetic.

What I find exciting is that you can create records on your PDS, your middleman service, as a way to orchestrate pushing these records to any subscribers. And those subscribers can verify it actually came from you because it's cryptographically signed by your key. Think about what this enables. Imagine pushing a website update from your laptop to your PDS, and three edge nodes around the world receive that signed update from your PDS and serve the new version of your site. It's your infrastructure, coordinated through a middleman you control. (And yes, you should self-host your PDS. Just do it, it's non-negotiable if you care about any of this.)

Or look at what atcr.io is doing with container registries. They store the OCI container blobs—which can get huge, but it's still attested to be from you because you signed it over to be held by them. And even so, it's trivial to self-host your own container registry and have it federate with the main app view. That's the pattern: authenticated transfer as a coordination layer, with practical concessions where they make sense.

This is what I've been trying to achieve with npm install -g wispctl. It straight up doesn't interact with my wisp.place servers at all because it doesn't need to. Site uploads are sent to your PDS, and when you want to serve content, it subscribes to your PDS's firehose. You can control the entire chain of automated site deployments if you want to while also allowing anyone else to subscribe too (like my wisp.place servers if you want a speedy cache). I want someone other than me to appreciate this pattern. I want to see more things built on authenticated transfer as an orchestration primitive. I really do.

I don't want to see another blogging platform. I don't want another social media app.