Open Social 🔗 **Source:** [Open Social](https://overreacted.io/open-social/) > [!note]+ Document Notes > ```yaml > tags: [open-social, atproto, decentralization] > author: [Dan Abramov] > source: [overreacted.io] > reference: [https://overreacted.io/open-social/] > date created: 2026-01-09 10:00 > ``` > > # 🏷️ Title: Open Social > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary - What happened: Abramov introduces “open social” built on the AT Protocol, where user data lives in user-owned repositories addressable via `at://` rather than inside any single app. - Why it matters: Restores “hosting independence” and composability for social data, analogous to what open source did for code. - Key stakeholders: Users, app developers, infra providers (relays, indexers), protocol/community stewards. - Risks and tradeoffs: Complexity, early UX roughness, coordination and governance challenges, potential new centralization points in infra. - Bottom line: When “the protocol is the API,” apps become interchangeable views over user-owned social graphs, making lock‑in and data loss much harder. --- ## 📖 Main Content - The article argues we’re at a similar inflection point with social apps as we were with open source decades ago: centralized, closed platforms dominate, but a user-centric, open alternative is now technically plausible. - Classic web model: domains (`https://alice.com`) give people control over hosting; links represent relationships between documents, not physical servers. This makes hosts interchangeable and keeps them honest. - Social platforms inverted this: posts, likes, follows, etc. live as rows in a company database. Aggregation (feeds, search, notifications) is powerful but traps the “social web” inside each app’s box. - Lock‑in: Leaving a platform means losing your graph and context; “export your data” yields dead JSON, not a living network. Network effects push people back. - Open social (AT Protocol / atproto) re-centers the user: - Your handle is a domain you own (`@alice.com`). - Your data (posts, likes, follows) lives in a personal repository implementing AT Protocol, addressable as `at://alice.com/...`. - Each record is signed JSON; links between records form a “web of hyperlinked JSON,” analogous to HTML hyperlinks, but for structured social data. - Apps become CMS-like views: - Bluesky posts, Leaflet documents, Tangled stars all live in your repository, namespaced by record type. - Apps write to your repo and can read from others’ repos; they can piggyback on data without private APIs (“the protocol is the API”). - Product lifecycle changes: - If a product dies, user data persists in repos. New apps can resurrect or remix it; forking products becomes straightforward. - Cold-start is softened: new apps can reuse existing follow graphs, profiles, etc., or define their own formats. - Cross‑app remixing emerges (e.g., Leaflet docs inside Bluesky clients, Popfeed cross‑posting). - Aggregation and infra: - Millions of repos are aggregated via relays that stream signed commits (events) from across the network. - Apps subscribe to relevant record types and maintain their own indexes; they needn’t trust relays because commits are cryptographically signed (“authenticated transfer”). - Ecosystem tools appear for feeds, indexing, and automation. - Big-picture framing: - Pre‑social web got ownership and linking right but lacked shared aggregation. - Current social platforms nailed aggregation but centralized ownership and control. - Open social seeks both: user-owned data plus composable aggregation over a shared protocol. - Adoption will start with “stubborn enthusiasts” and compound over time, like open source; author expects open social to eventually feel inevitable. --- ### 🗒️ Notes - Open source analogy: - “What open source did for code, open social does for data.” - Open source moved the commons for software infrastructure into shared, inspectable, forkable codebases. - Open social aims to move the social graph into shared, user-controlled, forkable data. - Web vs social silos: - Traditional web: `https://alice.com` → Alice’s site. She can change hosts without breaking URLs because domains abstract away infrastructure. - Hosting providers must compete; users can “walk away” without losing links/traffic. - Social apps replaced domains with platform‑allocated usernames (`@alice`), and HTML pages with app-specific entities (posts, profiles, likes) stored in proprietary DBs. - Social aggregation (feeds, notifications, search) made this model compelling but re-centralized control. - Lock‑in dynamics: - Users can’t leave without leaving behind their “web” of relationships and content. - Data exports are contextless “dead data” — JSON shards divorced from live graphs. - Coordinated mass migration to a new platform is nearly impossible; network effects pull users back. - This weakens user leverage and encourages platforms to prioritize advertising, acquisitions, or investor demands over user interests. - AT Protocol model: - Identity: users own domains; handles like `@alice.com` map to their AT repositories. - Repository: a web server speaking AT Protocol, storing signed JSON records (posts, follows, likes, etc.). - Each record has an `at://` URI; links between records express relationships across repos (e.g., Alice following Bob, Bob commenting on Alice’s post). - Data locality: each user’s records are hosted where they choose; repos from multiple users can coexist on one host or be scattered across many. - Hosting independence: `https://alice.com` and `at://alice.com` can point to different servers, decoupling websites from social data hosting. - User experience: - Technical users may self-host and inspect repos with tools; nontechnical users simply sign up to apps that provision repos behind the scenes. - From the UI perspective, open social apps look much like current social apps; the change is in data architecture and portability. - Cross‑app composition: - Repos group data by record type (e.g., `app.bsky.feed.post`, `pub.leaflet.doc`). - Apps can read each other’s record types from a user’s repo (e.g., Tangled using Bluesky profile avatar). - This resembles generalized Gravatar: any piece of data can be reused across apps. - “There is no API to hit… The protocol is the API.” Apps integrate by speaking the protocol and parsing typed JSON from repos. - Product lifecycle and forking: - Product shutdowns don’t destroy data; users retain repos, and others can build replacements or forks. - New apps can bootstrap from existing social graphs or define alternate formats and follow records. - Remixing: clients like Anisota or Popfeed combine data from multiple apps; clients can add support for new record types independent of original app vendors. - Aggregation & infra: - Scaling aggregation: relays stream events (signed commits) from all known repos. - Apps subscribe to record types they care about and maintain application-specific indexes. - Multiple relays can exist (e.g., community‑run relays); integrity comes from signatures, not centralized trust. - Emerging infra: feed builders, indexers, query/automation tools tailored to atproto. - Philosophy & trajectory: - Pre‑social web: strong user ownership, weak aggregation. - Current silos: strong aggregation, weak ownership. - Open social: aims for both; user-centered architecture with shared indexing infra. - Adoption will likely follow the open source curve: slow, community-driven, compounding until it becomes the default. - Author expects users will eventually just notice that data flows across apps and that they keep reach when switching — even if they never say “decentralization.” --- ## 📚 References - Original article: [Open Social – overreacted.io](https://overreacted.io/open-social/) - AT Protocol overview: https://atproto.com - Bluesky social: https://bsky.app - ATProto relays and ecosystem (example community relay): https://atproto.africa --- ## 🗣️ Paraphrase - Paragraph A: Modern social media centralized our social graphs in company databases, creating great aggregation features but trapping our data and relationships inside each platform. - Paragraph B: The AT Protocol proposes that people own their identities and social data in portable repositories addressable via a shared protocol, letting different apps read and write that data so users can switch apps without losing their networks. --- ## 📰 Newsletter Open Social is a compelling reminder for WordPress folks: the same way we value owning our content and domains, AT Protocol aims to give people ownership of their social data. Instead of chasing “everything apps,” it imagines a world where identity and posts live in user-controlled repos and apps are just views on top. For WordPress builders, this resonates with decoupled architectures and content APIs. Imagine WordPress sites that can both publish to and read from atproto repos, reusing social graphs instead of rebuilding them per property. As this ecosystem matures, there’s room for plugins that bridge WordPress users and open social: identity mapping, cross‑posting, and analytics over user-owned streams. If you work on WordPress or adjacent tooling, keep an eye on protocols, not just platforms — they’re increasingly where the long-term leverage lives. --- ## ✅ Action Items #### DevRel - Create developer guides and examples showing how to build apps that treat “the protocol as the API” (e.g., querying user repos, writing signed records). - Run workshops on designing record schemas and namespacing for new open social apps. - Produce reference SDKs and quickstarts for popular languages to interact with AT Protocol repos and relays. - Publish case studies on products that successfully remix data from multiple apps. - Foster a community forum or Discord/Matrix space for protocol implementers and client authors. #### OSPO - Define contribution policies and governance models for protocol evolution and core reference implementations. - Clarify licensing for protocol specs, reference servers, and client libraries to encourage adoption. - Integrate security review and signing/verification practices into standard contribution workflows. - Track dependencies on protocol infra within the organization and maintain SBOMs and update cadences. - Support upstream funding for key infra (relays, indexers, reference repos). #### Community - Help maintainers of early open social apps with roadmap clinics and governance templates. - Improve contributor onboarding for protocol tooling (docs, “good first issue,” pairing). - Engage sponsors and donors around funding shared infra that multiple apps can reuse. - Coordinate cross-project incident drills (e.g., relay outages, signing key compromises). #### WordPress - Core: explore how WordPress identities (users, sites) could map to protocol-level handles and repos. - Core Performance: profile and optimize integrations that read/write to external repos (caching, background sync). - Core AI: ensure any AI features that consume open social data respect user ownership and consent. - Core Program Team: align experiments around decentralized identity and content portability. - Playground: prototype WordPress–AT Protocol play spaces where developers can safely test integrations. - Community: create meetup kits discussing protocols, data portability, and how WordPress can participate. - Training: add lessons on decentralized protocols and open social to Learn WordPress. - Marketing: highlight stories where owning your content, domain, and social graph work together. - Documentation: add patterns for building plugins that integrate with external social protocols. #### The WPOCC - Programs: support fellows exploring decentralized identity and social data in the WordPress ecosystem. - Projects: sponsor documentation and reference implementations for WordPress–open social bridges. - Funding experiments: pilot microgrants for plugins that treat “the protocol as the API” for social features. ### FAIR - Promote technical independence by ensuring local validation of signed records and clear provenance for social data. - Encourage transparent funding and governance for protocol stewards to mitigate capture by any single vendor. - Develop reusable governance artifacts (charters, operator agreements) for running relays and shared infra. --- ## 🧪 Hypotheses - H1: Users are more likely to switch social apps when their identity and follower graph are portable by protocol, not by ad‑hoc exports. - H2: Open social ecosystems will see higher experimentation and app diversity because new apps can bootstrap off existing graphs. - H3: Apps built on user-owned repos will experience less backlash over shutdowns or pivots than closed platforms, because user data remains live. - H4: Protocol-based data access (“the protocol is the API”) will reduce integration costs compared to a landscape of proprietary APIs. --- ### 📊 Methodology - To test H1: Run a field or natural experiment comparing migration rates between communities on traditional platforms vs. those on AT Protocol after major policy changes. - To test H2: Compare number and diversity of third‑party clients and niche apps over time between open social ecosystems and closed platforms of similar size. - To test H3: Survey user sentiment and retention following app shutdowns in both models; measure continued access/use of data via alternative clients. - To test H4: Survey and instrument integration time/maintenance metrics for developers building on standardized protocol vs. multiple platform APIs. --- ### ❓ Questions - What governance structures best prevent protocol capture while enabling coherent evolution? - How can nontechnical users meaningfully exercise hosting choice without added cognitive burden? - Where might new centralization pressures (e.g., dominant relay or hosting providers) arise, and how can they be mitigated? - How will spam, abuse, and moderation scale in a world of user-owned, cross‑app data? --- ### 🔮 Future Research - Empirical studies of user attitudes toward data portability once they experience “log in and your graph is already here.” - Design patterns for UX that communicates hosting independence and portability without technical jargon. - Economic models for relay and repo hosting that don’t reintroduce lock‑in. - Comparative security analysis between centralized social DBs and distributed signed‑record architectures. --- ### 💡 Implications - Practice: App builders should consider protocols as first-class product surfaces; design for read/write against user repos rather than proprietary DB-only models. - Policy: Regulators exploring interoperability mandates can look at AT Protocol as a concrete architecture for practical portability. - Security: Signed commits and verifiable records shift some trust from platforms to cryptographic guarantees, but key management becomes critical. - Education: Developers need training in protocol thinking, distributed data models, and governance. - Funding: Shared infra (relays, indexers, reference repos) looks like digital public goods that may warrant collective support. --- ## 🧠 Learning Styles Assessment - Reading level estimate: roughly upper high-school to early college; concept density and metaphors are moderate, but jargon is explained. #### 👀 Visual learners - Present: diagrams contrasting web vs app DBs, arrows for social graphs and repos. - Improve: architecture diagrams showing request flows, before/after data ownership states, examples of `at://` vs `https://`. #### 🔊 Aural learners - Present: none mentioned. - Improve: short audio summary explaining the open social story in plain language. #### 🗣️ Verbal learners - Present: strong analogies (open source, web vs hosting, dead JSON), careful definitions. - Improve: a brief glossary of protocol terms and social graph concepts. #### 🧩 Kinesthetic learners - Present: none. - Improve: hands-on tutorials for spinning up a repo, inspecting records, or building a tiny client. #### 🧠 Logical learners - Present: stepwise comparison (old web → silos → open social), causal reasoning about incentives and lock‑in. - Improve: explicit tables comparing models, simple decision trees (when to move hosts, when to fork products). #### 🧑‍🤝‍🧑 Social learners - Present: scenarios with “Alice and Bob,” community emphasis. - Improve: guided discussion prompts or group exercises on designing an open social app. #### 🧘‍♀️ Solitary learners - Present: long-form essay suited to reflective reading. - Improve: reflection questions at the end (“What would it mean if you owned your social graph?”). #### 🌿 Naturalistic learners - Present: no environment/sustainability framing. - Improve: analogies to ecosystems (data as species moving between habitats, resilience via diversity). --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: standard HTML article semantics likely; headings used. - Improve: ensure headings are properly nested and any diagrams have descriptive alt text. #### Keyboard navigation - Present: likely basic navigation via browser. - Improve: confirm all interactive elements (if any) are keyboard accessible with visible focus. #### Contrast and readability - Present: overreacted.io typically uses readable typography, but exact contrast depends on theme. - Improve: verify 4.5:1 contrast, comfortable line-height, and font sizes. #### Text resizing and reflow - Present: likely responsive layout. - Improve: test at 200% zoom for reflow without horizontal scrolling; honor reduced-motion preferences. #### Media and captions - Present: static diagrams only. - Improve: provide text alternatives or captions for all images/diagrams. #### Forms and interactions - Present: none core to article. - Improve: n/a beyond general site forms. #### Standards reference - Map checks to WCAG 2.2 AA, especially 1.4.x (contrast), 1.3.1 (info and relationships), 2.1.x (keyboard), 1.4.10 (reflow). --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: largely Western tech culture framing; open source history. - Improve: incorporate examples and communities from diverse regions using open social. #### Inclusive language - Present: generally neutral and accessible; some profanity used rhetorically. - Improve: explain idioms and keep key concepts in plain language summaries. #### Neurodiversity support - Present: chunked sections, recurring Alice/Bob narrative. - Improve: more consistent headings, bullet summaries at section ends, and explicit signposting. #### Representation - Present: generic “Alice and Bob” figures only. - Improve: mention a more varied set of user personas and use alt text that respects diversity if images are added. #### Psychological safety - Present: critical of platforms, but not of users; tone is generally respectful. - Improve: add explicit content notes if discussing harassment or abuse scenarios in more detail. --- ### ✅ Logical Validity #### Strong reasoning - Uses analogical reasoning effectively (hosting vs social platforms) to show how control and incentives change. - Causal logic: tying hosting independence to provider discipline, and lack of exit options to user exploitation, is clearly argued. #### Fallacies - Some extrapolation (“at some point, open is bound to win”) leans on historical analogy; could be tempered by acknowledging failure modes. - Potential survivorship bias in focusing on successful open-source outcomes. #### Tone of voice - Conversational, slightly irreverent, opinionated yet reflective. - Mixes technical explanation with storytelling and occasional sharp criticism of exploitative platform behavior. --- ### 🛡️ DARVO Analysis - Deny: No denial of harms; the piece explicitly acknowledges user exploitation and lock‑in. - Attack: Critiques are aimed at platform incentives and outcomes rather than individual users; no personal attacks on accusers or victims. - Reverse victim/offender: The article does not attempt to recast powerful actors as victims; instead it centers users as those harmed by current incentives. - Overall: This is not a defensive text; it’s a critical and constructive proposal, so DARVO patterns are not present. --- ## 🎯 Conclusion Open Social outlines how AT Protocol can make social data user-owned and app-portable, much like domains and open source reshaped the web and software. By treating “the protocol as the API,” apps become interchangeable views over a shared, user-controlled graph. For practitioners, the next steps are to experiment with repos, record schemas, and clients — and to design products that assume users, not platforms, own the social web. --- ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Open social re-centers data on users > [!quote] [Open Social](https://overreacted.io/open-social/) by [[Dan Abramov]] via [[overreacted.io]]. Published 2025-09-25. Accessed 2026-01-09. > “What open source did for code, open social does for data.” Two lines: contrasts centralized platform databases with user-owned repositories. Useful to ground discussions of protocol-centric social design. [view highlight](https://overreacted.io/open-social/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] The protocol becomes the social API > [!quote] [Open Social](https://overreacted.io/open-social/) > “There is no API to hit, no integrations to build… The protocol is the API.” Two lines: frames AT Protocol as a universal integration layer replacing bespoke platform APIs, informing architecture choices. [view highlight](https://overreacted.io/open-social/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] Open social separates data from apps - In open social, user repos hold signed records; apps become interchangeable lenses. - Pointer to article sections on personal repositories and app CMS analogy. - Links: [[Social-Web-Architecture]] [[Data-Portability]] #### [Z2] Protocol-level access reduces integration lock-in - Apps integrating via a shared protocol can read/write data without bespoke APIs. - Pointer to sections stating “the protocol is the API” and cross‑app remixing. - Links: [[Interoperability]] [[Platform-Risk]] --- ### ✏️ Fleeting Queue (Extract by Selection) - [F1] Explore a WordPress plugin that maps WP users to AT Protocol handles and repos — https://overreacted.io/open-social/ #fleeting #inbox - [F2] Prototype a small client that reads Bluesky posts directly from a repo and renders them on a personal site — https://overreacted.io/open-social/ #fleeting #inbox - [F3] Draft a talk contrasting “API as product” vs “protocol as API” for dev communities — https://overreacted.io/open-social/ #fleeting #inbox --- <!-- deep-read:sections end -->