Feeds

There are 76 posts filed in Feeds (this is page 2 of 8).

Who should be working together on Textcasting?

In recent posts, Dave Winer has been bringing up the “working together” mantra in regards to the Textcasting concept. This has been a difficult concept for me to grasp – working together with who? Today, Dave sheds a little more light on this:

When I say textcasting is “applying the philosophy of podcasting to text” — what I mean in practical terms is that my flow of ideas is available “where ever you get your text.” Choice in subscribing has to be that fluid, commonsense, and choice is something people feel entitled to, as they do with podcasts. I’ve been told people would never understand the philosophy of podcasting, but they do, they understand they’re entitled to choice in how to listen and thus producers are free to choose where to publish. Somehow text, which is so much easier to transmit than audio, is far less flexible. That’s a mistake I want to undo, but I can’t do it alone. I need to work with other people who have writing and reading tools, and people who have something to say and want all the features of writing to be at their disposal, and for it to be easy, inexpensive but not free of charge, and not owned by the titans of tech. (bold/italics emphasis by Andy Sylvester)

from http://scripting.com/2023/12/30.html#a160414

I think the key part of the highlighted text is “other people who have writing and reading tools” – that is, people who are involved in developing writing and reading tools, or the primary developers of reading and writing tools. Dave Winer did press Bluesky to add RSS feeds as a native feature in the Bluesky client, and this occurred on December 22. He has also developed some software to be able to post to WordPress, Mastodon, and Bluesky via a REST call, so I guess these three platforms are not the ones Dave wants to work with?

Two other concepts in this paragraph also deserve some review:

  • my flow of ideas is available “where ever you get your text.”
  • Choice in subscribing has to be that fluid, commonsense, and choice is something people feel entitled to, as they do with podcasts.

To me, this moves beyond the “feature list” as defined at Textcasting.org. The first bullet implies that a writer should be able to publish their writing such that it can be seen in any tool. Apps that create RSS feeds of content could be read in any RSS reader, so if all writing apps created RSS feeds of the output of their apps, a user could use a RSS reader app to read that content. However, I don’t think that is the direction that the first bullet is heading. My feeling is that the real message of this bullet is “my flow of ideas should be able to be posted on any social media network without me having to re-enter my ideas into some other editor or tool”. THAT would definitely require app developers to work together to make that happen. And why would they do that? I have been thinking about the struggle to get Twitter/X/Facebook/Threads to create RSS feeds. My simplistic thought is that if users could get the content using RSS feeds without going through the platform app/interface, the users would not be exposed to the ads that that the platform has, which is the primary means of support for those applications. From that standpoint, it does not make business sense for those applications to give the content placed in their apps away in that manner.

This brings me to the second bullet mentioned above. To me, this could be a description of the “pain” experienced by Mastodon users when trying to follow another Mastodon user on a Mastodon instance different from the one that hosts their accounts. Similarly, it could also describe the pain of trying to subscribe to a RSS feed. As I mentioned earlier, THAT would definitely require app developers to work together to make that (cross-app subscription and forwarding of content) happen. And why would they do that? I don’t know. As an aside, for many podcasting apps, their feed search feature is good enough to find a podcast feed from search terms, so I don’t think that is the use case being highlighted by the second bullet.

To return to the title of this post, I think the people that need to work together on textcasting are primarily developers. As the developers have applications, they should then evangelize their work to potential users. To me, this seems to be the approach that the Textcasting “movement” needs to follow.

What is “interop” for social media apps?

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 13th:

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….

Open letter to Dave Winer’s call to develop feed-based social media apps

On December 3, Dave Winer published a “call to develop” for a feed-based social media app (he mentioned Mastodon in his post, but could be any social media app out there in my opinion). Sounds great to me! I have a feed-based app using rssCloud for notification called MyStatusTool (link to Github repo and my install). It is implemented using Node.js, Express, and Embedded Javascript for templating. It inspired Colin Walker to develop a PHP implementation of the tool (Github repo, his install). We were able to use our tools to interop with each other (have a real-time conversation), and to follow other feeds using rssCloud for notification. I have tested my implementation with the rssCloud user feeds from FeedLand and WordPress.com in addition to Colin Walker’s MyStatusTool implementation, and verified the real-time performance (new posts showed up almost immediately).

Now, is MyStatusTool a fully-developed thing? Nope! It’s a bootstrap. It does use a number of Node packages developed by Dave Winer for feed generation and feed reading, and uses Andrew Shell’s rssCloud server for notification, so I think it falls into the “working together” category that Dave Winer wrote about in 2015: “When you have a choice, instead of re-inventing someone else’s work, use it.”

I am ready to work for interop with whatever Dave develops. I don’t have any illusion that MyStatusTool is the epiphany of feed-based social media tools, but I developed it to see if one could be developed, and it spawned another implementation, so I think that is pretty cool. Let’s get busy and see what happens!