Feeds

There are 71 posts filed in Feeds (this is page 1 of 8).

Can the use of semaphore be useful today?

Ken Smith recently wrote about the use of semaphore and RSS in transmitting information. He relates an experience where he organized students to send a message across a university campus. The historic use of semaphore flags was to communicate between ships. In the 18th century, the “optical telegraph” was developed, and messages could be sent from Amsterdam to Venice in an hour. With the development of the electric telegraph, the use of the optical telegraph fell to the wayside.

Today, people can use RSS readers to monitor posts on websites, and use other social media systems (Twitter, Facebook, Threads, Bluesky) to do the same. The rssCloud protocol also provides almost instant notification. I think that the question Ken Smith is asking is “can a group of individuals use this to be able to respond to a crisis“. The answer is “Yes”, but people “would have to be trained to do more than just send or receive a message on the system”.

So – do we choose to do something here? What crisis should we work to avoid?

Not just a blogroll – it’s a feedroll

In mid-March 2024, Dave Winer rolled out a new feature on Scripting News – a blogroll with dynamic content. I think it is interesting, but it is more than a “traditional” blogroll, in that it is not just a list of sites, but is presenting content from those sites, and ordering them in terms of the sites most recently updated at the top of the list. Blogrolls of the past were a static list of sites. In his podcast announcing the rollout, Dave Winer comments that future development directions will be up to users (about 8 minutes into the podcast), as it should be.

Until recently, though, it was unclear how other users would be able to access this feature. However, some one at Automattic developed a WordPress plugin to display the Dave Winer blogroll on a WordPress site. Yesterday, the first new user (Doc Searls) announced that he had the blogroll plugin working on his site.

I think it is great when people are adding features to their sites. I also think it is great that Dave Winer is working to migrate his ideas to other platforms like WordPress, which have a large base of users. The base technology of this feature is based on the FeedLand service, so there is still a linkage between Dave Winer’s tool and deployment of this feature – something for users to keep in mind.

My last observation on this is perhaps a subtle one, but still significant. Following comments from Dave Winer over the years about RSS, and that new format creators should use a different name than RSS, I think there should be a different name for this feature, as it is a significant enhancement from traditional blogrolls. When I looked at Doc Searls’ implementation, I saw that the title of his was “Feedroll”. I think this is a great name for this new feature – let’s use it!

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.