Grand unified theory of how social media ought to work

In the TFOS intro post (We need better tools for online speech) I mentioned my “unbundling social media” idea which is that:

  1. you can conceptually split up social media into four main functions: reading/“consuming”, publishing, discussion, and aggregation.
  2. these four functions should be interchangeable between platforms/tools.

to give one example, if you publish a post on site A, someone should be able to read it on site B just as if the post had been published on site B.

One of the biggest things I’m working on is trying to flesh out and refine this model so that I can build services which adhere to it and convince others to do the same. I’ll use this thread as a place to write my evolving ideas on this area.

Lately I’ve been thinking a lot about how discussion communities should fit into this. Relatedly, I’ve also been wondering how he fit Twitter into this model. (The model doesn’t have to fit everything–the goal is to be useful, not 100% correct–but still).

one approach to decentralized discussion would be to treat discussion comments/posts just like regular blog posts: host them on your own domain/some hosting service, and then layer reply notifications and such on top.

I think this is unnecessary. I think it’s better to separate posts into primarily “broadcast” posts, which fall under my “publishing” category, and discussion posts. I think it makes sense for discussion posts to be tied to a particular location/community/piece of software.

that’s vague; so to give an example: I think it’s fine to have a community on a particular service like Slack, Discord, Discourse, etc, and require that people in the community use that service. I don’t think there needs to be some kind of discussion protocol so that e.g. you could have a single community where some people members are using slack and some are using discord; with the slack people never even needing to create a discord account and vice-versa.

But still, there are some ways in which it would be nice to have discussion communities interoperate with the other services in my model (reading, publishing, aggregation). so my question is: what are those ways?

(actually, figuring that out for all the services–figuring out which functions should happen within services, and which should happen via multiple services working together–is pretty much the whole point of this thread. but lately I’ve been particularly thinking about it in regard to discussion services)

and again, the other big question is, does Twitter fit into this model? I’ve been mainly thinking of discussion communities as relatively small, focused communities, like slack, discord and so on. under this model, do you treat “Twitter” as a single, giant discussion community? or do you just leave it out of the model? again, not every facet of online communication needs to fit in this model; rather the idea is simply “going forward, the model is a useful tool for designing new services”.

originally I was inclined towards the latter, under the thinking that you just don’t need a single big community with everyone in it. there might not be anything of value lost if discussion primarily happened in a network of these smaller communities. it would be harder for things to go viral, but a lot of people say that would be a good thing. for a message to spread across communities, you’d have to manually copy and paste it instead of just hitting retweet.

and actually, that still seems like not a bad approach. but at the same time, I think Twitter is valuable for making new connections between people who otherwise might not have been in the same community. maybe those kinds of connections would still happen in my new model, via different methods. :person_shrugging:. but in any case, I guess it doesn’t hurt to treat Twitter like a single community even though it’s huge. if the unbundled model does gain adoption, then either small communities really are sufficient and Twitter can be left to fade away, or Twitter does have unique value and it’ll continue to be used.

OK, that was all kind of abstract, so next I think it’d be best new to list out the actual concrete ways in which these discussion communities would interop with reading, publishing, and aggregation services.

(actually maybe for new I’ll focus just on the interop between publishing and reading services–more on that later)

reader apps should display notifications from discussion communities

I want all my notifications to go through my reading app. I don’t want 5 different apps all trying to suck me in. the reading app can manage which notifications are allowed to go through (I hate that Twitter has started giving me notification spam, E.g. “person A tweeted something”–it boosts engagement for Twitter no doubt). the reader app can throttle them too. E.g. I don’t need push notifications if they’re all in one app. if I’m always going to that one app to read stuff anyway, I’ll see the notifications soon enough–and that way I’ll never get interrupted by a notification.

(in the current setup, I could avoid interruption if I just turn off notifications–however I do like finding out about replies/mentions at a frequency higher than once per day, and checking five apps manually multiple times per day is even worse than having notifications turned on).

from what I saw, twitter doesn’t expose notifications in its API. I’m not surprised. I haven’t looked at other things like reddit/discourse. this might be a good selling point for new discussion services: make them amenable to being mediated by reader apps.

publishing apps should be able to publish a single feed with a user’s activity from all the (public) discussion communities they’re in

social media feeds don’t just show you “root” posts that your friends publish. they also show you things like “Bob replied to/liked this post”. I think it’d be useful to have a similar thing in the new model. that would provide a handy discovery mechanism for these small, focused, separate communities, too.

it might work something like this: from your publishing service, you connect to all the public communities you’re in. E.g. connect your Twitter + reddit accounts, type in your hacker news username, paste a link to any discourse forums you’re in + your username…

the publishing service would pull in all the posts, replies and reactions you’ve made in those communities, and collate them all into a single feed. maybe an RSS feed, or come up with some new protocol. (I should look at what activity pub does. I think it uses RSS/Atom for this?). this feed would be published on your site along with your “regular” rss feed which contains all your blog posts.

on the reader app side: if you subscribe to an rss feed, the reader app can check the home page for that feed, and see if there is a second feed for these community interactions. if so, the reader app can mix in those things too.

implementation details:

  • could also link to the second feed from within the main rss feed instead of from the home page. that might be a better implementation, but I’m concerned it would hurt adoption–E.g. I’m pretty sure ghost lets you put whatever extra html you want in your homepage head element, but I don’t think it lets you do the equivalent with your rss feed. maybe best to support both methods.

  • if the feed is listed in the homepage head, need to make sure that it doesn’t get confused for the main rss feed. so maybe don’t use “application/atom+xml” for the link type, but the actual file format could still be rss/Atom.

Prime example!

Actually I think this is the way to do it. Having the “secondary” feed linked from within the “primary” feed will make it easy for RSS readers to know when a secondary feed exists (or no longer exists)–otherwise RSS readers have to poll the homepage in addition to the RSS feed.

I don’t think adoption will matter. I’m planning to implement this in Yakread. Anyone who creates a Yakread profile will get both of these feeds; and the primary feed can pull content from other places too. e.g. say you write on substack and twitter. In Yakread, you connenct to twitter and you paste in a link to your substack account. Now your yakread profile has a main feed which is basically a copy of your Substack RSS feed, except Yakread’s copy includes the link to your secondary feed which includes your tweets etc. Not to mention that Yakread will also be the only RSS reader that recognizes these secondary feeds anyway, at least at first.

So Yakread can provide a proof-of-concept implementation on both the publisher and the reader side, and then after Yakread grows a bunch hopefully other RSS readers and publishers will follow suit.

(This is an example of how to overcome the standards innovation paradox: create implementations on both the producer and consumer side of the standard, then add new features yourself. If you have growth, then other producer/consumer implementations will ideally start to support the features so they can interop with you. I wish Substack would take this approach. Maybe Amazon would do it if they made a social network)