Permissioned Data: Space Access
Stepping outside the shapes series for a deep dive: how space configuration decides which people and which apps get credentials. Here be dragons.
Nick's Blog
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. This is the second post in a series applying atproto's permissioned data proposal to the shapes I expect people to actually build. The first, Permissioned Data Shapes:…
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. Proposal 0016 ,…
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.
Validate both lexicon schemas and records against those schemas.
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.
Lexicon Garden helps you browse, view, and understand ATProtocol Lexicons.
View post on Bluesky View post on Bluesky View post on Bluesky Ben Folds (Oct 5) View post on Bluesky View post on Bluesky View post on Bluesky View post on Bluesky Sammy Rae (Apr 16) Palace (Mar 18) View post on Bluesky
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 time, I want to show a use case that isn't possible yet, but would fit well with the community manager pattern: discussion forums. The Problem Today Forums have…
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. Dan Abramov launched https://internethandle.org/ in late November and has been promoting the use of "Internet Handle" as a standard term for authentication in the ATProtocol ecosystem. View post on Bluesky I'm open to the idea, but I don't think "handle" will catch on quickly since users…
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…
"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…
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…
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…
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…
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…
Another if-this-then-at blueprint I've been exploring: IF an identity has a cryptographically-signed payment proof THEN unlock access to confidential data services The Blueprint Pattern This blueprint combines two powerful ATProtocol patterns: Signed attestations (proof of payment/ticket purchase) Confidential record hydration (privacy-aware data serving) The result: trustless payment gates for…