Stepping outside the shapes series for a deep dive: how space configuration decides which people and which apps get credentials. Here be dragons.
A self-keyed space gives notifications a home you control: every app gets an append-only sink to write into, you pick the reader that turns them into pushes and emails, and allowing or revoking an app is an access control you already have.
Public feed generators drink from a firehose that permissioned data never enters, so a feed that includes space content has to become a syncer, keep a live model of who can see what, and serve a different skeleton to every viewer.
A poll is a space, a ballot is an address, and read_self is the ballot screen: voters cast and change their own votes while no voter's client can read anyone else's.
A forum with public categories, private categories, and one set of record shapes across both: members own their posts, the forum owns the submission wrappers that admit them into categories, and moderators deactivate into tombstones instead of deleting.
A community can own spaces the way a person does: a club's members post to each other under a dedicated community DID, with a feed space for content, a moderation space for notes, a labels space for filtering, and a single app view as the only window into any of it.
A private events space is the first shape with other people in it: a member list of friends and family, guest RSVPs that live on the guests' own PDSes, and an app allowlist that controls which services ever see the venue address.
A self-only space is the smallest shape permissioned data can take: one authority, one member, one repo, and private bookmarks that share a record shape and a write path with public ones.
AT Protocol is public by default. Everything you write goes into a signed, archived, and rebroadcastable repository that anyone can read from and moves through relays. This core design decision makes the network so legible and easy to build on, but it also blocks entire types of apps, like private groups, gated content, member-only forums, or anything that isn’t meant for everyone.
attested.network is an open spec for decentralized proof of payments on ATProtocol, built on what we learned making atprotofans.com. It formalizes the three-party attestation model and opens it up for any app to implement.
Atproto users need a way to express granular AI preferences and carve out exceptions for specific entities or content types. This post introduces community.lexicon.preference.ai, a lexicon schema that decomposes AI usage into distinct categories and adds a scoped override mechanism built on top of Bluesky's User Intents proposal.
atprotofans.com was a proof of concept for payments on ATProtocol built at Graze Social. This post is about what we built, why proof of payment on protocol matters, and what it makes possible.
Graze Social sponsored my first in-person IETF meeting in Montreal last November. This post is about what it was like to be there and why standards participation matters for small companies.
IFTTA is an automation platform built on ATProtocol at Graze Social. It started as a hack-day idea and became a working system for event processing on protocol.
OAuth is the first challenge developers face in the atmosphere. This post is about AIP, the authorization gateway we built at Graze Social to alleviate some of the pain.
Public anchor records paired with sidecar records in permissioned spaces give ATProtocol apps a composable pattern for blending open discoverability with controlled access.
Record elicitation is a pattern where a client asks an AppView to construct a record from the user's intent, rather than building it locally. This lets the AppView handle business logic, validation, and schema complexity while the client retains full authority over what gets written to the user's repository.
How ATProtocol uses Content Identifiers to create a versioned, verifiable, and portable data model.
A deep dive into Content Identifiers, the self-describing cryptographic fingerprints that form the foundation of ATProtocol’s data model.
This is a B-sides post with unpolished thoughts that didn’t make it into the main article.
Permissioned data is a love triangle between the user, the identities they grant permissions to, and the applications everyone uses to view controlled data. We don't need to change or reinvent the protocol to have it, because ATProtocol already supports it.
Lexicon Garden is growing and moving! With community support, the service is migrating to new infrastructure in Europe, offering better hardware and more space for new features.
Lexicon Garden can help you explore and interact with lexicons both in the browser and with the help of your favorite agent.
You can use Lexicon Garden to create and manage lexicon schemas right from the browser.
ATProtocol OAuth pairs effortlessly with Lexicon Garden to make it easy for developers to experiment with authenticated XRPC endpoints.
In my last post, I talked about the community manager pattern. I focused on the basics including how membership attestations work, how the wrapper pattern handles content, and what the lifecycle of a book club community looks like.
This post looks more closely at Brittany Ellich's work on representing groups in ATProtocol. It builds on earlier conversations and explores how these ideas might work in practice.
Authentication is an area that generally has really difficult UX constraints and the language really matters.
ATProtocol's inter-service authentication currently has no way to identify which client is making a request on behalf of a user, forcing services to rely on forgeable headers or clunky workarounds to establish trust relationships. Adding an optional client_id claim to inter-service JWTs would solve this cleanly, enabling service-to-service trust, rate limiting, and feature flags using the cryptographic infrastructure we already have.
"Don't feed the trolls" emerged as folk wisdom in 1990s Usenet culture and became internet gospel, grounded in solid psychological research showing that trolls seek negative attention and ignoring them removes their reward.
This post introduces the formal ATProtocol attestation specification, a framework for adding cryptographic signatures to ATProto records through two complementary patterns: inline attestations that embed signatures directly in records, and remote attestations that store proof in separate repository records. The specification prevents replay attacks through repository binding, uses CID-based content addressing for integrity, and provides the cryptographic foundation for verified credentials, trusted content, and authenticated interactions in the decentralized ATProtocol ecosystem.
Deep technical implementation of the unforgeable endorsement system. Covers step-by-step CID computation, complete code for the endorsement workflow, validation algorithms, firehose event processing, and detailed security analysis of attack vectors. Includes working code examples, lexicon definitions, and the cryptographic mechanisms that make forgery mathematically impossible.
Traditional professional endorsements on platforms like LinkedIn lack cryptographic proof—anyone could forge them, and the platform controls the truth. This article introduces a two-record architecture using ATProtocol's Content Identifiers (CIDs) and Decentralized Identifiers (DIDs) to create mathematically unforgeable mutual attestations. By separating proof creation from endorsement acceptance and leveraging the firehose for distributed validation, we build a system where both parties cryptographically consent and no central authority can manipulate the record.
at://work is a modern job board built on ATProtocol where your profile and job listings are stored on your own Personal Data Server, giving you true ownership of your professional data. As a full AppView with XRPC APIs and remote MCP server capabilities, it makes job market data accessible to both users and developers while proving that professional networking can be decentralized and user-controlled.
Ohio's new age verification law requiring ID to access adult websites (starting September 29, 2025) fails to protect children while forcing adults to surrender personal data to access legal content. This "small government" Republican law creates a surveillance system that invades privacy without addressing the real online dangers kids face.
QuickDID is a high-performance, open source handle resolution service for the ATmosphere that serves as both public infrastructure at https://quickdid.smokesignal.tools and deployable software under MIT license. It offers flexible caching strategies (memory/Redis/SQLite), scales from single-instance to distributed deployments, and includes production features like rate limiting and proactive cache refresh. Currently a release candidate, it provides a drop-in alternative to Bluesky's resolver while giving developers full control over their handle resolution infrastructure.
Exploring how AT Protocol and SMTP can work together to make secure messaging possible by combining 50-year-old email infrastructure with modern cryptographic identity. Building on Chris Boscolo's AT-SMS proposal, this post introduces ideas for adding SMTP services directly to DID documents and leveraging PDS-level cryptographic operations through XRPC methods. The result: verifiable, encrypted communication where messages work like signed JWTs over email, handles prove identity without centralized authorities, and users maintain complete control over their messaging infrastructure. A technical deep-dive into how "boring" technology like SMTP and DNS, combined with AT Protocol's identity primitives, could finally deliver truly portable, private, and permanent messaging.
Another if-this-then-at blueprint I've been exploring: