December 2023

There were 13 posts published in December 2023 (this is page 1 of 2).

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.

My three favorite podcast episodes

Here are the three podcasts that I have recorded that are my favorites:

The end of podcasting, episode 60 – I channel Keith Olbermann in a snarky podcast about downturns in the podcasting industry (December 2023)

In The Car Podcast Episode 4 – Home Impeachment Edition – I sing “The Christmas Song” with new lyrics about Donald Trump’s first impeachment (December 2019)

Thoughts from a user – After listening to some voicemail casts by Dave Winer (I called them asynchronous podcasts, since they were a conversation with Doc Searls), I decided to record one of my one to Dave Winer. He did not reply via a podcast, but he did acknowledge it on Scripting News. (January 2020)

Merry Christmas, everyone!

Lazyweb request: is there a Zoom filter that can make you look thinner on camera? I was in a hybrid meeting recently, and the camera in the conference room kept focusing on me – help!

The end of podcasting, chapter 61

Well, I did not think I would be writing another chapter so soon, but here are some links to the latest podcasting industry downturns:

  • TechCrunch: Spotify cuts 17% jobs amid rising capital costs
  • TechCrunch: Everything you know about the podcast industry is a lie – Analysis of the Spotify layoffs
  • Leo LaPorte: “Radio got about a hundred years, podcasting got a decade’ – Leo Laporte on his recent layoffs (link to 3 minute audio clip)
  • Nick Hilton: A Year On From the Death of Podcasting… – Talks about his similar “death of podcasting” post from 2022, discusses Spotify layoffs, advertising issues, talent issues,….

I think my podcast from chapter 60 still applies….check it out!

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

Sometimes I feel bad that I collect links and don’t do anything with them (except create more link dump documents), but after reading Karl Voit’s article about his PIM debt, I don’t feel quite as bad about it!

Creating a local start page

I have been getting in the habit of keeping a set of browser tabs open to various pages. As this list has grown, it became a not-insignificant amount of the browser tab space. I use the Brave web browser, and 85-90 tabs is about the limit of visible tabs, so giving up 20-25 tabs was sometimes an issue. I then remembered this page from Ton Zijlstra on start pages, and decided to create one myself. The site Ton linked to was not active anymore, so went to the Internet Archive to get a copy. I added both web sites and local files. You can see it here – feel free to steal and make your own!