Blogging

There are 96 posts filed in Blogging (this is page 2 of 10).

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

Saw via my RSS feeds that Colin Walker had signed up for Bluesky. I reached out to follow him, and he was online at the same time! We had a mini-conversation, it felt good!

More on POSSE – Scott Hanson posted that he is writing posts on Micro.blog, which sends them to Mastodon and Bluesky, then uses IFTTT to read his RSS feed and post to Twitter. A good example of “getting started” doing POSSE (re: end of Tantek Celik post on this topic)!

Thoughts on POSSE and Textcasting

A number of people have posted recently on the subject of POSSE (Dave Winer, Tantek Celik, The Verge, and Bix Fronkonis). POSSE is an acronym for Publish On (your own) Site, Syndicate Elsewhere. Dave Winer has also been talking about Textcasting, where he proposes that blogging/social media tools support a common set of features. Dave Winer also talks about “Two-Way RSS”, which I think means that a tool can generate RSS feeds and can use RSS feeds as an input to posts within the tool. I would like to explore these ideas further in the next few paragraphs.

Recently, I got the impression that a Textcasting use case is to allow a user to write in their tool/platform, and have that output be accepted on other platforms as “first-class posts”. What I mean by that is the post appears on the other platform to have been written by the user using the platform’s own tools. Now, a number of platforms don’t support all the features in the Textcasting spec, so even if the other platform accepts input from the user’s platform, it may not represent the text as it appeared in the original platform. In this instance, I might call that a “second-class post”. It may have all the text from the original user platform, but not the styling, or links, or an enclosure.

So, it seems to me that the target of Textcasting is to get Threads/Bluesky/Mastodon/Twitter/Facebook to support the Textcasting feature set (which I assume they don’t, or at least not equally). In each of these cases, the user must have an account on those platforms, so they have an identity and the platform can recognize who is posting. Dave Winer mentions that other blogging tools that support peering for the Textcasting feature set is WordPress and micro.blog. Again, both of these tools require a user account, same as the social media tools listed above, for the same reasons.

What about people who just want to post on your own site? Go ahead – nothing stopping you! For people that want their message to go further, we shall have to wait and see if those platforms are open to change. For open source platforms (Mastodon), someone could make changes in a Mastodon version to support Textcasting. The other aspect of the social media platforms, to me, is that they are social. If you are a writer that wants to have interaction with your readers, and your readers are on those platforms, it makes sense to “get your message out there”.

I recently had to “return to the office”. To make things easier, I am trying to prepare things at the end of the day to make things quicker in the morning (following Anna Havron’s checklist advice). So far, doing prep the night before is working!

Overheard as I passed some cleaners as I was getting off a plane: “Adults can be pigs”.