How to rebuild social media on top of RSS

On a couple of occasions I have described my Grand Vision For How Social Media Ought To Be, which is roughly that there should be a bunch of different:

• publishing services, like Substack and Ghost
• reading apps, like Gmail and Matter
• community platforms, like Slack and Discord

and we should look for ways to make these reading, publishing, and community services all play nicely together. I'm calling this model "the unbundled web," and I think RSS should be the primary method of interop. (The term "decentralized" has already been co-opted by all those bitcoin people, so I'm using "unbundled" as a synonym with less baggage.)

That's a pretty high-level view of things. Over the past several months I've spent a lot of time trying to figure out what it looks like if you zoom in to the next level. If I had the ears of a bunch of people working on publishing, reading, and community apps, what features would I ask them to implement? What features should I implement in Yakread, my own reading app?

It's important to stick to the essentials. The less stuff there is that needs to be built, the higher the chance that it will actually be built. With that in mind, here's what I currently think the essentials are, subject to change:

1. Community apps should provide the option of publishing an RSS feed of all new posts.

Your reading app should be able to subscribe to new posts from all the communities you're in. You shouldn't have to check a bunch of different apps all the time. If there's a single place where people can go for new posts from all their communities, they'll be more likely to engage in lots of different communities instead of settling on a few.

Discourse is the only community app I'm aware of that publishes a feed. For example: https://meta.discourse.org/posts.rss. More apps should do this. It doesn't need to be mandatory—lots of communities want to be private. But I'd love it if I could tick a box in the settings page for my Discord server and have it start publishing a feed, with appropriate UX so that community members understand that my server is public. For private servers, maybe have password-protected feeds so that members can subscribe with their reading apps after signing in to the community.

2. Publishing apps should compile a "social feed" with your posts from communities you're in.

If a bunch of discussion apps started doing #1, then you could add all those feeds to your publishing app and tell it your username(s). The publishing app could pick out all the posts you wrote and turn it into another RSS feed. Then instead of telling people to follow you on Twitter, you can tell them to subscribe to your social feed.

Any publishing apps that wanted to be proactive about this can get started today with a few different community apps, even if it takes some custom code. It would be sweet to have a page + RSS feed on my website that contained all my comments from Hacker News, Reddit, Mastodon, Twitter*, and of course Discourse.

*Actually I decided to stop using Twitter today, so I wouldn't use a Twitter integration myself, but others might appreciate it.

3. Reading apps should provide a good experience for social feeds.

If my reading app includes subscriptions to Joe Schmoe's social feed, a Discourse feed, and a "regular" once-a-week newsletter feed, I don't want the high-frequency social feeds to drown out everything else. A very simple thing reading apps could do is automatically separate feeds by frequency. If a feed produces more than, say, one post per day on average, consider it to be a social feed. Group all the social feeds together in one timeline, and group all the less-frequent "normal" feeds in another timeline.

That implementation is just a suggestion. Reading apps are free to experiment with different ways of attacking the problem (that's the whole point of the unbundled web!); the import thing is just that the reader experience shouldn't break down if you subscribe to a bunch of social feeds.

At a minimum, reading apps shouldn't assume that all posts have titles (h/t Dave Winer).

4. Reading apps should make it really easy to subscribe to RSS feeds.

With all this RSS stuff, the elephant in the room must be addressed: most people don't even know what RSS feeds are, let alone how to subscribe to one. Even people who are familiar with RSS aren't necessarily in the habit of using a feed reader. We've got to make this as frictionless as possible, with a good onboarding experience for first-time RSS users.

My main idea here is that every reading app should let you create shareable links where people can subscribe to an RSS feed and sign up for the reading app at the same time. If I want to invite people to join my community or subscribe to my social feed, I give them one of these shareable links.

For example, give this here link a click: https://feedrabbit.com/?url=https://meta.discourse.org/posts.rss. You'll be taken to Feedrabbit, an RSS-to-email service. The RSS field has been prefilled with the feed from a Discourse server. Someone who doesn't know what RSS is could still follow that link, sign up with their email address, and start getting posts in their inbox.

All reading apps should have a similar feature. Not all apps would deliver the posts directly via email like Feedrabbit, but they can send daily digest emails to help new users develop a habit of checking their feed reader.

Another suggestion: provide browser extensions and iOS/Android sharing menu items so that it's easy to open an web page in the reading app. If there's one or more RSS feeds detected, throw in a subscribe button with checkboxes for each feed. The "shareable subscribe links" should include a link to the original RSS feed in the page metadata. Then if I click on the subscribe link but want to subscribe with a different RSS reader, I can do so easily.

Again, the goal here is that users should never need to know what RSS is: just "I can use this reading app to subscribe to stuff easily."