Building on AT Protocol
🔗 **Source:** [Building on AT Protocol](https://dbushell.com/2026/03/10/building-on-at-protocol/)
> [!note]+ Document Notes
> tags: #at-protocol #bluesky #decentralization #social-media #oauth #personal-data-server
> author: David Bushell
> source: dbushell.com
> reference: https://dbushell.com/2026/03/10/building-on-at-protocol/
> date created: 2024-12-19 14:30
>
> # 🏷️ Title: Building on AT Protocol
>
<!-- deep-read:sections start -->
## 🧰 Action Inbox
- [H1] Explore AT Protocol for decentralized social app development — personal project exploration #at-protocol
- [H2] Research PDS hosting options and self-hosting requirements — technical implementation #personal-data-server
- [H3] Investigate atcute TypeScript libraries for AT Protocol integration — development tools #typescript
## 🧭 Table of Contents
- [[#📝 Summary]]
- [[#📖 Main Content]]
- [[#🗒️ Notes]]
- [[#📚 References]]
- [[#🗣️ Paraphrase]]
- [[#📰 Newsletter]]
- [[#✅ Action Items]]
- [[#🧪 Hypotheses]]
- [[#📊 Methodology]]
- [[#❓ Questions]]
- [[#🔮 Future Research]]
- [[#💡 Implications]]
- [[#🧠 Learning Styles Assessment]]
- [[#📊 Accessibility Assessment]]
- [[#🌍 DEIB Assessment]]
- [[#✅ Logical Validity]]
- [[#🛡️ DARVO Analysis]]
- [[#🎯 Conclusion]]
### 🔗 References
- [AT Protocol](https://atproto.com)
- [Bluesky](https://bsky.app)
## 📝 Summary
- Developer David Bushell explores building applications on AT Protocol, the decentralized technology powering Bluesky
- AT Protocol provides user data ownership through Personal Data Servers (PDS) and OAuth-style authentication across apps
- Bushell created attic.social as a demonstration app with bookmarking features using AT Protocol
- The protocol's power lies in user data portability and prevention of platform lock-in
- Users can move accounts between different PDS providers while maintaining access across AT Protocol apps
## 📖 Main Content
AT Protocol (atproto) serves as the foundational technology for Bluesky and emerging social web applications, functioning primarily as an authorization and data layer. The protocol addresses platform lock-in concerns by giving users ownership of their data and accounts.
The data model makes all atproto information inherently public, though encryption for private use is theoretically possible with metadata considerations. Users control cryptographic keys to their data stored on Personal Data Servers, which can be self-hosted or managed by providers like Bluesky, Blacksky, or Eurosky.
Authentication follows an OAuth-like pattern where user identity verification occurs through their chosen PDS rather than being locked to a specific platform. This allows accounts created on one service to authenticate with other AT Protocol applications.
Bushell demonstrates these concepts through attic.social, a bookmark management application built using atcute TypeScript libraries and deployed on Cloudflare Workers. The implementation uses encrypted HTTP-only cookies for stateless session management.
## 🗒️ Notes
#### Article Beginning — [H1] AT Protocol captures developer interest
- Key idea: Developer enthusiasm for AT Protocol's decentralized social architecture
- Evidence: "At Protocol has got me! I'm morphing into an atmosphere nerd."
#### Data Ownership Model — [H2] Users own their data through PDS
- Key idea: Personal Data Servers give users control over their information
- Evidence: "Atproto users own the keys to their data which is stored on a Personal Data Server (PDS)"
#### Authentication System — [H2] OAuth-style auth without platform lock-in
- Key idea: Identity verification happens through user's chosen PDS
- Evidence: "Atproto provides OAuth; think 'Sign in with GitHub'. But instead of an account being locked behind the whims of proprietary slopware, user identity is proven via their PDS"
#### Cross-Platform Usage — [H3] Single account works across multiple apps
- Key idea: Accounts created on one service can authenticate with other AT Protocol apps
- Evidence: "Social apps like Bluesky host a PDS allowing users to create a new account. That account can be used to login to other apps like pckt, Leaflet, or Tangled"
#### Attic.social Demo — [H1] Practical implementation example
- Key idea: Real-world application demonstrating AT Protocol capabilities
- Evidence: "Of course I did. You can sign in at attic.social"
#### Technical Implementation — [H3] Stateless server design with encrypted cookies
- Key idea: Server architecture using HTTP-only cookies for session state
- Evidence: "to keep the server stateless I borrowed ideas from my old SvelteKit auth experiment. OAuth and session state is stored in encrypted HTTP-only cookies"
#### Data Portability — [H2] Users can move between PDS providers
- Key idea: Account and data migration prevents vendor lock-in
- Evidence: "You can move your data to another PDS like Blacksky or Eurosky"
#### Lexicon System — [H3] Standardized data formats across apps
- Key idea: Common conventions allow apps to share and read each other's data
- Evidence: "Apps write data to a PDS using a lexicon; a convention to say: 'this is a Bluesky post', for example"
#### Permission Model — [H3] Users control app data access
- Key idea: Granular permissions for what data apps can write
- Evidence: "During authorization, apps must ask for permission to write to specific lexicons. The user is in control"
#### Platform Protection — [H1] Architecture prevents Twitter-style shutdowns
- Key idea: Decentralized model makes it difficult to kill third-party apps
- Evidence: "What's important is that atproto makes it difficult for Bluesky to 'pull a Twitter', i.e. kill 3rd party apps"
#### Data Recovery — [H2] Information remains accessible even if apps disappear
- Key idea: Users retain data access regardless of application availability
- Evidence: "If I ever abandon attic.social your data is still in your hands. Even if the domain expires!"
## 📚 References
- [AT Protocol](https://atproto.com)
- [Bluesky Social](https://bsky.app)
- [atcute TypeScript libraries](https://github.com/mary-ext/atcute)
- [attic.social](https://attic.social)
## 🗣️ Paraphrase
- AT Protocol provides a decentralized foundation for social applications where users own their data through Personal Data Servers and can move between providers without losing access to their accounts or information
- The authentication system works like "Sign in with GitHub" but uses the user's chosen data server for identity verification instead of locking them into a specific platform's ecosystem
- Developers can build applications that interoperate through shared data conventions called lexicons, while users maintain granular control over what data each app can access and modify
## 📰 Newsletter
AT Protocol is emerging as a powerful foundation for building decentralized social applications, as demonstrated by developer David Bushell's new attic.social project. Unlike traditional social platforms, AT Protocol gives users true ownership of their data through Personal Data Servers while enabling seamless authentication across multiple applications.
For WordPress developers, this represents an interesting parallel to our open-source philosophy of user agency and data portability. The protocol's lexicon system for shared data standards and granular permission controls offer valuable lessons for plugin and theme development.
Key benefits include protection against platform lock-in, user-controlled data migration, and prevention of Twitter-style third-party app shutdowns. Bushell's technical implementation using TypeScript libraries and stateless server design provides a practical roadmap for developers interested in this space.
Resources: [AT Protocol Documentation](https://atproto.com), [atcute Libraries](https://github.com/mary-ext/atcute), [WordPress Developer Resources](https://developer.wordpress.org/)
## ✅ Action Items
#### DevRel
- Developer advocacy: Create AT Protocol integration tutorials for WordPress developers
- Education: Workshop on decentralized authentication patterns
- Developer experience: Document OAuth alternatives and data portability patterns
- Developer marketing: Case studies comparing AT Protocol to traditional social auth
- Community management: Foster discussion around decentralized web standards
#### OSPO
- Policy & Governance: Evaluate AT Protocol's governance model for open source insights
- License Compliance: Review AT Protocol licensing and dependency implications
- Security Management: Assess decentralized authentication security considerations
- Strategic Alignment: Consider AT Protocol patterns for WordPress.org infrastructure
#### Community
- Maintainers: Share decentralized data ownership lessons with Core team
- Contributors: Explore AT Protocol integration opportunities for WordPress
- Ecosystem: Connect AT Protocol developers with WordPress community
#### WordPress
- Core: Investigate decentralized authentication options
- Meta: Consider AT Protocol patterns for WordPress.org account portability
- Community: Share AT Protocol governance lessons with working groups
## 🧪 Hypotheses
- AT Protocol's data portability model could influence WordPress user data export standards
- Decentralized authentication patterns might reduce dependency on third-party OAuth providers
- Lexicon-based data standards could inspire WordPress REST API schema improvements
- Personal Data Server concepts could inform WordPress multisite architecture decisions
### 📊 Methodology
- Prototype AT Protocol integration with WordPress authentication system
- Survey WordPress developers on interest in decentralized authentication options
- Compare AT Protocol governance model with WordPress decision-making processes
### ❓ Questions
- How could WordPress implement AT Protocol-style data portability for user content?
- What would WordPress.org federation look like using AT Protocol patterns?
- Could decentralized authentication reduce WordPress.org single point of failure risks?
### 🔮 Future Research
- AT Protocol scalability implications for WordPress.com-scale deployments
- Integration possibilities between AT Protocol apps and WordPress sites
- Decentralized content moderation approaches applicable to WordPress communities
### 💡 Implications
- Practice: New authentication patterns could simplify cross-platform development
- Policy: Data portability regulations may favor AT Protocol-style architectures
- Security: Decentralized authentication reduces single points of failure
- Education: Developers need training on decentralized web principles
- Funding: Investment in decentralized infrastructure could accelerate adoption
### 🧠 Learning Styles Assessment
Reading level estimate: Grade 10-12
#### 👀 Visual learners
- Present: Login form screenshot showing AT Protocol integration
- Improve: Architecture diagrams showing PDS relationships, data flow visualizations
#### 🔊 Aural learners
- Present: Synthesized audio version available on source site
- Improve: Podcast discussion of AT Protocol implications
#### 🗣️ Verbal learners
- Present: Clear analogies like "Sign in with GitHub" comparison
- Improve: More real-world examples of data portability scenarios
#### 🧩 Kinesthetic learners
- Present: Live demo site (attic.social) for hands-on exploration
- Improve: Step-by-step tutorial for building AT Protocol apps
#### 🧠 Logical learners
- Present: Clear technical architecture explanation and implementation details
- Improve: Comparison tables between AT Protocol and traditional OAuth
#### 🧑🤝🧑 Social learners
- Present: Community references and shared development resources
- Improve: Discussion forums for AT Protocol developers
#### 🧘♀️ Solitary learners
- Present: Self-contained explanation with external resource links
- Improve: Reflection prompts on decentralization benefits
#### 🌿 Naturalistic learners
- Present: Ecosystem metaphors around app interconnection
- Improve: Environmental benefits of decentralized infrastructure
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: Clean heading structure and descriptive text
- Improve: Alt text for login form screenshot
#### Keyboard navigation
- Present: Standard web navigation patterns
- Improve: Skip links for long technical explanations
#### Contrast and readability
- Present: High contrast text on clean background
- Improve: Code syntax highlighting with sufficient contrast
#### Text resizing and reflow
- Present: Responsive design accommodating zoom
- Improve: Ensure code blocks don't break at higher zoom levels
#### Media and captions
- Present: Audio version available
- Improve: Transcript for synthesized audio content
#### Forms and interactions
- Present: Clear form labeling in screenshots
- Improve: Accessible form examples in tutorials
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: Technical content accessible to global developer audience
- Improve: Examples from different regional PDS providers
#### Inclusive language
- Present: Gender-neutral technical terminology
- Improve: Plain-language explanations of complex concepts
#### Neurodiversity support
- Present: Well-structured content with clear headings
- Improve: Summary sections and key takeaway boxes
#### Representation
- Present: Focus on technical merit rather than individual characteristics
- Improve: Diverse examples in implementation scenarios
#### Psychological safety
- Present: Encouraging tone about learning new technology
- Improve: Explicit welcome for developers at different skill levels
### ✅ Logical Validity
#### Strong reasoning
- Deductive strength: Strong logical flow from AT Protocol principles to implementation benefits
- Inductive strength: Good use of specific example (attic.social) to illustrate general principles
- Causal reasoning: Clear explanation of how PDS ownership prevents platform lock-in
- Analogical strength: Effective OAuth comparison helps readers understand concept
#### Fallacies
- None identified: Technical explanation is factually grounded and avoids logical errors
#### Tone of voice
- Overall tone: Enthusiastic but technically precise, accessible to developers while maintaining accuracy
### 🛡️ DARVO Analysis
- Deny: No defensive rhetoric present
- Attack: No attacks on critics or competing approaches
- Reverse victim/offender: Not applicable to technical content
- Emotional cues and rhetoric: Positive enthusiasm without manipulation
## 🎯 Conclusion
AT Protocol represents a significant advancement in decentralized social infrastructure, offering developers the ability to build applications with true user data ownership and cross-platform interoperability. Bushell's practical implementation demonstrates the protocol's viability while highlighting the technical considerations involved in adopting decentralized authentication patterns. For the broader web development community, AT Protocol's approach to data portability and user agency provides valuable lessons that could influence future platform architectures beyond social media applications.
## 🧱 Refactor Appendix
### 📚 Literature Split Pad
Purpose: Stage CEE units that become Literature notes.
Split level: H3
### [H1] AT Protocol enables decentralized social application development
> [!quote] Building on AT Protocol by David Bushell via dbushell.com. Published 2026-03-10. Accessed 2024-12-19.
> "AT Protocol — atproto for short — is the underlying tech that powers Bluesky and new social web apps."
Core technology explanation demonstrating practical implementation approach.
[view highlight](https://dbushell.com/2026/03/10/building-on-at-protocol/#H1) #xref #articleseed ID:rw_atproto_foundation
### [H2] Personal Data Servers give users control over their information
> [!quote] Building on AT Protocol
> "Atproto users own the keys to their data which is stored on a Personal Data Server (PDS)."
Data ownership model that prevents platform lock-in through user-controlled storage.
[view highlight](https://dbushell.com/2026/03/10/building-on-at-protocol/#H2) #xref ID:rw_pds_ownership
---
### 🔖 Atomic Split Pad (Zettel Candidates)
Purpose: Promote reusable claims into Atomic notes.
Split level: H4
#### [Z1] Decentralized authentication prevents platform vendor lock-in
- Applies to OAuth-style systems using user-controlled identity providers
- Pointer to authentication system explanation section
- Links: [[OAuth]] [[Decentralization]] [[Platform-Independence]]
#### [Z2] Data portability requires standardized formats and user key control
- Scope: Social media and user-generated content platforms
- Pointer to lexicon system and PDS discussion
- Links: [[Data-Portability]] [[User-Agency]] [[Standardization]]
---
### ✏️ Fleeting Queue
Purpose: Capture quick actions for Fleeting notes.
- [F1] Research atcute TypeScript library documentation — development tool exploration #fleeting #inbox
- [F2] Compare AT Protocol governance to WordPress.org decision-making — governance research #fleeting #inbox
- [F3] Explore self-hosting PDS requirements and costs — infrastructure planning #fleeting #inbox
<!-- deep-read:sections end -->
📄 **Full text:** ![[Full Document Contents/Articles/Building on AT Protocol|Building on AT Protocol, dbushell.com]]
## Highlights
- Social apps like Bluesky host a PDS allowing users to create a new account. That account can be used to [login to other apps](https://bsky.app/profile/pckt.blog/post/3mgh4crd7ws2d) like [pckt](https://pckt.blog/), [Leaflet](https://leaflet.pub/), or [Tangled](https://tangled.org/). You could start a new account on Tangled’s PDS and use that for Bluesky. Atproto apps are not required to provide a PDS but it helps to onboard new users. ([View Highlight](https://read.readwise.io/read/01kkc5qzc0f171k01vbqxkfy1e))
- Tags: 👻 ai highlighted