Nick Gerakines
@ngerakines.me
he/him; Protocols, platforms, and machine learning; Building things and stuff ngerakines.me
he/him; Protocols, platforms, and machine learning; Building things and stuff ngerakines.me
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.