I have been busy lately, but something Dave Winer wrote recently about interop bothers me, and now I have a little time to discuss it. Dave said this on December 13^th:

Andrew Hickey is one of my favorite bloggers, and it’s somewhat weird because..

• He blogs on Bluesky but it works because..
• John Spurlock added RSS 2.0 feeds for Bluesky, built on their API, I am able to subscribe Hickey’s observations in FeedLand, because..
• Of course FeedLand understands RSS.

And it all happened without getting complicated. No federation needed. Just plain old RSS.

from https://feedland.blog/2023/12/13/the-power-of-open-formats/

So – let’s break this down. Someone (in this case, Andrew Hickey) is using the social media app/service, Bluesky. Another person (John Spurlock) has created a web service that uses the Bluesky API to allow a user of the web service firesky.tv to create on demand an RSS feed of posts for a Bluesky user. This RSS feed can then be read by any feed reader supporting RSS. In the post, Dave Winer links to the feed for Andrew Hickey’s account as presented by his feed management system/application, FeedLand. The display of the items in the feed are attractive and easy to read. However, since the feed is public, anyone could create a similar display (like this one). To me, this demonstrates the interoperability of RSS – anyone can take an RSS feed, consume it however they wish, and present the feed however they wish (either privately (like someone using Feedly or Inoreader) or publically (like the FeedLand representation or my representation)). I agree that no “federation” was needed, but that service from John Spurlock was needed, otherwise there would have been no RSS feed for FeedLand or my app to read.

Now, this example does not, in my opinion, demostrate any “interop” with the Bluesky application or service. John Spurlock’s application is using data from Bluesky using its API, but the interaction is one way – Bluesky to firesky.tv. That, in and of itself, is fine. There are many applications in the world that provide an API to allow other applications to get data from the application (and presumably to send data to the application). There is a list of such applications for Bluesky (https://atproto.com/community/projects), so no one is stopping innovation in this area. My impression is that Bluesky is not charging for use of its API (unlike X/Twitter), so this also should foster innovation in applications using data from Bluesky and client development for Bluesky.

Now, returning to the Dave Winer post linked at the top of this article, he is putting out the call to add feed support to social media systems (i.e., outbound feeds, publishing the posts that users make using Bluesky as feeds, separate from what someone would see using a Bluesky client, such that someone could keep up with posts on Bluesky without using the native app or any other app besides a feed reader):

I am lobbying everyone I know to add great feed support to social media systems, so we can get out of the mode of dominant platforms before Threads becomes the dominant platform.

from https://feedland.blog/2023/12/13/the-power-of-open-formats/

In pushing for this, if all social media services produced feeds, then this could be used to support moving content between services, and for other uses. Mastodon natively supports outbound RSS feeds, but Bluesky does not (John Spurlock’s Firesky.tv service appears to be the main way to read RSS feeds of Bluesky posts).

So, what about peering? Currently, there is no peering of data between Bluesky and Mastodon or any other social media service. It is, of course, possible to send content from Bluesky to Mastodon or the other way around, or any other service, as long is there is a protocol or API that supports that sharing of content. Again, those protocols do exist (AT Protocol, Activity Pub, and Mastodon API), so content could be moved around (if someone wanted to invest in doing that work).

So, what about federation? This is where different servers and/or services could communicate with each other. The Mastodon documentation has a summary:

“Unlike a traditional website, Mastodon websites can interoperate, letting their users communicate with each other; just like you can send an email from your Gmail account to someone from Outlook, Fastmail, Protonmail, or any other email provider, as long as you know their email address, you can mention or message anyone on any website using their address.”

from https://docs.joinmastodon.org/#federation

This is part of the nirvana promised by the concept of federation – you can post anywhere, mention a user, and have that user be notified. The mechanics of that, however, can be tricky, and depends on multiple servers/apps using the same protocol.

Even though there seems to be a lot of heat/activity in trying to make federation work, what if that was not the key feature that users want? Dave Winer comments here:

“Imho, what’s valued is the ability to publish something quickly, and without much fuss, and follow others, again easily without having to have a deep understanding of how these things are architected.”

from http://scripting.com/2023/12/13.html#a135218

In my opinion, this is the use case that could benefit from universal RSS support across social media applications. If that was in place, the ability to flow content via RSS between social media apps would be straightforward, and perhaps not require any effort on the part of the social media apps to federate. The world will have to wait and see….