Can RSS be a social network?
🔗 **Source:** [Can RSS be a social network?](http://scripting.com/2026/07/09/152001.html?title=canRssBeASocialNetwork)
> [!note]+ Document Notes
> tags: [rss, open-web, decentralization, interoperability, indieweb, social-networks]
> author: Dave Winer
> source: Scripting News
> reference: http://scripting.com/2026/07/09/152001.html?title=canRssBeASocialNetwork
> date created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
>
> # 🏷️ Title: Can RSS be a social network?
>
<!-- 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)
### 🔗 References
- [Textcasting](https://textcasting.org/) — Winer's 2022 spec for portable social text.
- [Scripting News (source post)](http://scripting.com/2026/07/09/152001.html?title=canRssBeASocialNetwork)
## 📝 Summary
- Dave Winer, co-creator of RSS, argues that a social network can and should be built out of open web standards rather than a proprietary platform.
- It matters because it reframes "social networking" as a protocol problem, not a product problem — the missing piece is interop, not features.
- Key stakeholders: independent writers and developers, the IndieWeb community, and the incumbent silos (Twitter/X-style networks) whose business model depends on incompatibility.
- Risks and tradeoffs: the technical stack is easy; the hard part is coordination and the fact that big networks are commercially motivated to stay incompatible.
- Bottom line: the "right way" to do social is to make every part replaceable and interoperable, because then there's no platform vendor — it's just the web.
## 📖 Main Content
- The post is a short, aphoristic list restating a thesis Winer first published in 2022 as "textcasting." Textcasting's premise: when Twitter took over public discourse, it stripped away the features the open web needs to be a good writing environment (links, styling, enclosures, titles, unlimited length), and getting "back on track" means restoring those.
- His actual want is modest — "a nice little social network to use with a few of my programming buddies" — but the design principle scales: bootstrap a distributed network from web standards where every component is swappable.
- Proposed building blocks: RSS 2.0, OPML, Markdown, SQL, and WebSockets. The model is podcasting — anyone can publish, anyone can read, and no gatekeeper approves either side.
- Core design value: many divergent user experiences are fine (encouraged, even), but all clients must interoperate at a basic level so a user can pick any software at either end.
- The MP3 analogy carries the argument: we treat audio as a universal format that "just works" everywhere, and nobody accepts arbitrary limits like a 300-second cap. Text should be the same. The reason text *isn't* portable is not technical — it's that the big networks profit from mutual incompatibility.
- Contested/uncertain: the piece asserts feasibility ("I thought you could do it") but doesn't demonstrate a running network at scale here; the practical blockers (identity, spam, moderation, discovery) go unaddressed in this short post. It's a manifesto restatement, not an implementation report.
### 🗒️ Notes
- The framing question — "Can RSS be a social network?" — is answered implicitly yes, provided you add a thin real-time and storage layer (WebSockets + SQL) and a document/outline layer (Markdown + OPML) on top of feeds.
- "Every part is replaceable" is the load-bearing idea. It's the anti-lock-in principle: no single vendor can hold the network hostage because any piece can be re-implemented.
- The podcasting precedent is doing heavy lifting rhetorically — podcasting is Winer's own proof that an open, RSS-based publish/subscribe system can reach mass scale without a platform owner.
- The MP3 comparison targets platform-imposed constraints (character limits, single-author posts, media restrictions) and calls them "laughable" when applied to a universal format.
- Business-model claim: incompatibility is a feature for incumbents, not a bug. This is the crux — the obstacle is economic incentive, not missing standards.
- Closing move collapses the distinction between "a social network like the web" and "the web itself": there is no platform vendor because it *is* the web.
## 📚 References
- [Textcasting](https://textcasting.org/) — Winer's spec for what portable social text requires.
- [Scripting News](http://scripting.com/) — Winer's blog and the primary source.
- RSS 2.0, OPML, Markdown, SQL, WebSockets — the named stack (no links in source; these are the standards he proposes).
## 🗣️ Paraphrase
- Back in 2022 Winer wrote "textcasting," important enough to get its own domain; it named the wrong turn taken when Twitter centralized discourse and stripped the web's writing features, and laid out what's needed to recover.
- All he really wanted was a small social network for a few programming friends — bootstrapped from web standards with every part replaceable, built from RSS 2.0, OPML, Markdown, SQL, and WebSockets.
- It would work like podcasting: anyone publishes, anyone reads. Many user experiences should exist, but everything must interoperate at a base level so any client works at either end.
- Text should behave like MP3 — universal, no arbitrary limits. The reason it doesn't is that big networks don't want compatibility because incompatibility is good for their business.
- The web's way to do social: every part replaceable, interop everywhere, no platform vendor — because it *is* the web.
## 📰 Newsletter
- From the co-inventor of RSS comes a tidy reminder that "social" was never supposed to require a landlord. Dave Winer's latest Scripting News post asks whether RSS can be a social network and quietly answers: it already can be, if we insist on interop. For WordPress folks this lands close to home — feeds, IndieWeb plugins, Micropub, and ActivityPub all chase the same "every part replaceable" ideal. Worth a read alongside his [textcasting](https://textcasting.org/) spec if you're building anything that federates.
## ✅ Action Items
#### DevRel
- Developer advocacy: Not applicable to this source — the post is an opinion piece with no product or program to advocate.
- Developer experience: frame IndieWeb/RSS onboarding around the "pick any client at either end" interop promise.
#### OSPO
- Not applicable to this source — no organization, licensing, or governance artifact is discussed.
#### Community
- Ecosystem: use the "incompatibility is good for their business" claim as a talking point in decentralization advocacy.
#### WordPress
- Core: Not applicable to this source — no core-level ask.
- Community: connect the textcasting principles to WordPress's existing feed and IndieWeb tooling in meetup/education material.
### FAIR
- Technical independence: the "every part is replaceable, no platform vendor" principle is a clean statement of technical-independence goals; cite it in FAIR framing.
## 🧪 Hypotheses
- A social network built purely on RSS 2.0 + OPML + Markdown + SQL + WebSockets can reach usable feature parity with a basic timeline-style network.
- The primary barrier to text portability across networks is commercial incentive, not technical capability.
- An interop-first design (any client at either end) increases user retention versus single-client silos because switching costs drop.
- Treating text as a universal format (MP3 analogy) would eliminate platform-imposed constraints like length caps and single-author limits.
- A small-group "programming buddies" network is a viable bootstrap path to a larger distributed one.
### 📊 Methodology
- Build a reference implementation of the named stack and measure whether a small cohort can publish/subscribe without a central server.
- Comparative analysis: survey incumbent networks' documented reasons (or revealed behavior) for not federating, to test the "bad for business" claim.
- Interop conformance test suite: verify that two independently written clients can round-trip posts.
- Longitudinal retention study comparing interop-first vs single-client tools.
### ❓ Questions
- How do identity, spam control, and moderation work when every part is replaceable and there's no platform vendor?
- What is the minimum real-time layer (WebSockets) needed before RSS-based social feels "live" rather than blog-like?
- Does OPML solve discovery and follow-graphs adequately, or is a separate directory needed?
- Where does ActivityPub/Fediverse fit relative to Winer's RSS-centric stack — complement or competitor?
### 🔮 Future Research
- Map the concrete gaps between a feeds-plus-WebSockets network and a modern social UX (notifications, mentions, threading).
- Study whether Micropub/IndieWeb already implements much of what textcasting asks, and where they diverge.
- Investigate governance/anti-capture models for a vendorless network (the piece is silent on this).
### 💡 Implications
- This is a foundational open-web argument that maps directly onto IndieWeb practice: own your content, publish from your own site, syndicate outward (POSSE), and let any reader consume it. Winer's "every part replaceable" is the same principle behind IndieWeb's building-block plugins (Micropub, Webmention, IndieAuth) and behind platform-decentralization efforts broadly.
- For WordPress specifically, it validates the co-developed IndieWeb plugin stack and the feed-first mindset: the network effect comes from shared protocols, not shared platforms. Post Kinds, Micropub, and ActivityPub integrations are practical expressions of "interop everywhere."
- For policy and platform decentralization: the claim that incumbents stay incompatible "for business" reframes federation as an economic and regulatory question, not merely a technical one — relevant to interoperability mandates and to the Fediverse's growth thesis.
- For education and funding models: teaching social as a protocol (like email or podcasting) rather than a product changes how communities invest — in standards conformance and client diversity rather than in a single hosted app.
### 🧠 Learning Styles Assessment
- Reading level estimate: roughly Flesch-Kincaid grade 7–8 — short declarative sentences, conversational, low jargon. Informal register with rhetorical questions.
#### 👀 Visual learners
- Present: one decorative Santa figure image; no diagrams.
- Improve: a stack diagram (RSS/OPML/Markdown/SQL/WebSockets layers) and a before/after silo-vs-interop flow.
#### 🔊 Aural learners
- Present: none.
- Improve: a 2-minute audio read of the list; ironic fit given the podcasting analogy.
#### 🗣️ Verbal learners
- Present: strong analogies (MP3, podcasting) and plain-language framing.
- Improve: a short glossary for OPML, WebSockets, textcasting.
#### 🧩 Kinesthetic learners
- Present: none.
- Improve: a runnable minimal demo or "publish your first textcast" walkthrough.
#### 🧠 Logical learners
- Present: implicit if-then structure (if interop, then no vendor).
- Improve: a decision table of feature vs standard vs current-silo-limit.
#### 🧑🤝🧑 Social learners
- Present: the "programming buddies" framing invites collaboration.
- Improve: a discussion prompt or linked reader responses.
#### 🧘♀️ Solitary learners
- Present: self-contained manifesto suited to quiet reflection.
- Improve: reflection prompts on lock-in in tools you use.
#### 🌿 Naturalistic learners
- Present: none.
- Improve: framing interop as an ecosystem/biodiversity analogy (many clients, one habitat).
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: content is a semantic unordered list; heading structure is the blog's, not the post's.
- Improve: the decorative Santa image needs empty/decorative alt (it appears purely ornamental).
#### Keyboard navigation
- Present: standard links (permalink anchors per item).
- Improve: Not applicable to this source — no interactive widgets to trap focus.
#### Contrast and readability
- Not applicable to this source — styling is the host blog's theme, not evaluable from the extracted text.
#### Text resizing and reflow
- Not applicable to this source — no layout to assess from content alone.
#### Media and captions
- Present: no audio/video; only a static decorative image.
- Improve: add alt text to the image.
#### Forms and interactions
- Not applicable to this source — no forms.
#### Standards reference
- Closest WCAG mapping: 1.1.1 Non-text Content (decorative image should have appropriate alt).
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: none specific.
- Improve: examples beyond a US/programmer-centric frame; global relevance of open protocols.
#### Inclusive language
- Present: neutral, no exclusionary terms; "programming buddies" is casual and inclusive.
- Improve: define jargon (OPML, WebSockets) for non-developer readers.
#### Neurodiversity support
- Present: short, chunked bullets with predictable structure — friendly to varied attention.
- Improve: a one-line thesis up top before the list.
#### Representation
- Not applicable to this source — no people or identities are depicted or quoted beyond the author.
#### Psychological safety
- Present: respectful, non-adversarial tone even toward "big networks."
- Improve: none needed.
### ✅ Logical Validity
#### Strong reasoning
- Analogical (strong): the MP3/podcasting analogy — a universal, vendorless format at scale — is a real existence proof that Winer himself helped build, so the analogy is grounded, not merely illustrative.
- Causal (moderate): "text can't go everywhere because the big networks don't want to be compatible" identifies a plausible incentive mechanism; strong as a hypothesis, though asserted rather than evidenced here.
#### Fallacies
- Appeal to simplicity / oversimplification: "There's no mystery to this" and the tidy stack list understate hard problems (identity, spam, moderation, discovery). Fix: acknowledge the coordination and abuse-handling gaps explicitly.
- Possible false dichotomy: framing it as web-interop vs platform-vendor omits hybrid/federated middle grounds (e.g., ActivityPub servers). Fix: situate the proposal against existing federation efforts.
#### Tone of voice
- Confident, plainspoken, lightly polemical ("Laughable, right?"), and idealistic — a veteran restating a long-held conviction rather than persuading skeptics point by point.
### 🛡️ DARVO Analysis
- Not applicable to this source — the post is a constructive technical/architectural argument, not a defense against an accusation. No denial, attack, or victim/offender reversal is present. The nearest thing is a mild attribution of motive to "big networks" ("Bad for business"), which is a market critique, not DARVO rhetoric.
## 🎯 Conclusion
- Bottom line: Winer says yes — RSS can anchor a social network, provided the design insists on interop and treats every component as replaceable, leaving no platform vendor because the result simply *is* the web.
- Practical next steps for readers: read the [textcasting](https://textcasting.org/) spec; audit your own tools for lock-in; if you run WordPress, lean into the IndieWeb/feed stack (Micropub, Webmention, ActivityPub) as concrete expressions of "interop everywhere."
## 🔄 Refactor Appendix — Can RSS be a social network?
### 📚 Literature Atoms (H3)
#### [H1] Open social networks require replaceable, interoperable parts
> [!quote] ID:rw_01kx4tefgvgn1v128f2987fn18
> The right way, the way the web would do social networking: Every part is replaceable. Interop everywhere.
**Context & use**:
- Near the close of the post; the summarizing design principle.
- The core anti-lock-in thesis — interop, not features, is the missing piece.
**Tags**: #xref #aphorisms
**Highlight**: source list item #a151745
<!-- atomicity: 1 idea ✓ -->
#### [H2] Text should be a universal format like MP3
> [!quote] ID:rw_01kx4tefgvgn1v128f2987fn18
> We'd think of text the same way you think of MP3. It just should work everywhere.
**Context & use**:
- Mid-post analogy attacking platform-imposed limits (length caps, single-author).
- Reframes portability as a solved-elsewhere problem.
**Tags**: #xref
**Highlight**: source list item #a155713
<!-- atomicity: 1 idea ✓ -->
#### [H3] Incompatibility between networks is commercially motivated
> [!quote] ID:rw_01kx4tefgvgn1v128f2987fn18
> The fact that our text can't go everywhere is because the big networks don't want to be compatible with each other. Bad for business.
**Context & use**:
- Identifies the barrier as economic incentive, not technical limitation.
- The crux claim for anyone arguing federation policy.
**Tags**: #xref #articleseed
**Highlight**: source list item #a160106
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates (H4)
#### [P1] Interop, not features, is what makes a network open
**Claim** (one sentence, Courtney's voice): A social network is open only when any client can interoperate at either end, so no single vendor can capture it.
**Evidence pointer**: [[#H1]]
**Scope & conditions**: Holds for publish/subscribe systems with a shared base protocol (RSS, ActivityPub); breaks when identity, moderation, or discovery force a central coordinator.
**Links**:
- [[IndieWeb]] — because applies-in independent publishing
- [[Fediverse / ActivityPub]] — because contrasts on federation model
- [[Platform lock-in]] — because contrasts on incentive
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Compare textcasting's RSS+WebSockets stack against ActivityPub feature-by-feature — http://scripting.com/2026/07/09/152001.html #fleeting #inbox
- [F2] Does the WordPress IndieWeb plugin stack already satisfy textcasting's requirements? #fleeting #inbox
### → Things 3 (max 2 actions)
- [ ] Read the textcasting spec and note gaps vs IndieWeb — https://textcasting.org/ #things
<!-- deep-read:sections end -->
📄 **Full text:** [[Full Document Contents/Articles/Can RSS be a social network.md|Can RSS be a social network? by scripting.com]]
## Highlights
- To bootstrap a simple distributed network based only on web standards, with every part replaceable. ([View Highlight](https://read.readwise.io/read/01kx4tmt2zy3ftcjhf3jze51bm))
- Note: The design goal — a distributed network from web standards with swappable components.
- Tags: atom/literature/h2
- We'd think of text the same way you think of MP3. It just should work everywhere. ([View Highlight](https://read.readwise.io/read/01kx4tmedwypffrwb1r5xa52g6))
- Note: Central analogy — text portability as an already-solved problem attacking platform-imposed limits.
- Tags: atom/literature/h2
- The fact that our text can't go everywhere is because the big networks don't want to be compatible with each other. Bad for business. ([View Highlight](https://read.readwise.io/read/01kx4tmk3sxez0vzcx6xmykxdz))
- Note: Crux — the barrier to portability is commercial incentive, not technical capability.
- Tags: atom/literature/h1
- The right way, the way the web would do social networking: Every part is replaceable. Interop everywhere. ([View Highlight](https://read.readwise.io/read/01kx4tma1ta8bawmpes81a4hnp))
- Note: Core anti-lock-in thesis — interop, not features, is the missing piece.
- Tags: atom/literature/h1
- There is no platform vendor. ([View Highlight](https://read.readwise.io/read/01kx4tmyqgxk5afeevrs66v4ng))
- Note: The payoff of full interop — no gatekeeper because the network is just the web.
- Tags: atom/literature/h3