Can RSS be a social network? ![rw-book-cover](https://imgs.scripting.com/2024/12/25/leftfacingsanta.png) ๐Ÿ”— **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? > ## ๐Ÿงญ 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 * ![](https://imgs.scripting.com/2024/12/25/leftfacingsanta.png)Back in 2022 I wrote a bit called [textcasting](https://textcasting.org/). I felt it was so important it deserved its own domain. [#](http://scripting.com/2026/07/09/152001.html#a155518) * Textcasting summarized the wrong turn we took when Twitter took over discourse, basically stripping all the features the web needed to be a great writing environment. Textcasting said this is what we have to have to get back on track. [#](http://scripting.com/2026/07/09/152001.html#a160717) * Meanwhile all I wanted was a nice little social network to use with a few of my programming buddies. [#](http://scripting.com/2026/07/09/152001.html#a155601) * To bootstrap a simple distributed network based only on web standards, with every part replaceable. [#](http://scripting.com/2026/07/09/152001.html#a151651) * I thought you could do it with RSS 2.0, OPML, Markdown, SQL and Web Sockets.[#](http://scripting.com/2026/07/09/152001.html#a160005) * It would work [like podcasting](https://textcasting.org/), anyone can publish, anyone can read. [#](http://scripting.com/2026/07/09/152001.html#a133439) * We can all have different spins on user experience, there should be *lots* of approaches, an infinite number of ways for people to connect, but we must all interop at a basic level, so users can use any software they want at either end to implement the network. [#](http://scripting.com/2026/07/09/152001.html#a133404) * We'd think of text the same way you think of MP3. It just should work everywhere. No one would ever say that MP3s could only be 300 seconds long. Or you can't play music, or have more than one person. Laughable, right? [#](http://scripting.com/2026/07/09/152001.html#a155713) * There's no mystery to this. 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. [#](http://scripting.com/2026/07/09/152001.html#a160106) * The right way, the way the web would do social networking: Every part is replaceable. Interop everywhere.[#](http://scripting.com/2026/07/09/152001.html#a151745) * There is no platform vendor. It's like the web because it *is* the web. [#](http://scripting.com/2026/07/09/152001.html#a151817), Can RSS be a social network?, scripting.com, 01kx4tefgvgn1v128f2987fn18.