Observations with Alecks

films

The beginning

For just under a year, Podping has been available and in use — through dedicated podcast hosting companies and also self-hosting individuals — to efficiently notify interested parties of updates to RSS feeds that define podcasts.

It was a bit rocky in the beginning, mostly because understanding the design simplicity offered by a decentralized message bus and defining a software interface to write to it efficiently are two different tasks. But it worked all along and we largely got through it without incident, thanks to the transparency and resiliency of the Hive blockchain.

Unfortunately, since it's on a blockchain, some of the initial experiments proving out the concept of the project at large are still around. One of the most important concepts of a project like this is people can depend on a defined schema, even if it's implemented in a schemaless manner (JSON).

Learning to communicate intent of the Podping project overall was helped by collaborating and putting out a stable release. The 1.0 release of podping-hivewriter, the current primary software we use to manage writing “podpings” to the Hive blockchain, came out several months after the original vision of the project had been laid down in a lowly Podcasting 2.0 developer roundtable.

Intent

While a stable release contributed to our understanding the stability of the system, we had only just begun to realize the potential we had beyond merely a simple podcast update system.

After all, the original scope of Podping was to help reduce unnecessary polling of RSS feeds when they had no change in content. We had already accomplished this by allowing anyone to announce the following data on the blockchain within a given a “podping” event:

{
    "version": "0.3",
    "num_urls": 1,
    "reason": "feed_update",
    "urls": ["https://example.com/super-great-pod.xml"],
}

Simple! This tells a user that an update to the RSS feed that defines a fictitious “super great pod” podcast occurred.

This alone is already more valuable than it would first appear. Not only can one reasonably assume they can stop polling feeds that get submitted via Podping; they also automatically obtain access to an entire history of podcasts. Without compromise.

That would be enough for most people.

Evolution

But a few things had happened since the Podping project had been started.

While the Podcasting 2.0 community had largely agreed that the movement was for more than podcasts, no one really understood how to make that work.

Eventually, I had postulated that the easiest way to do this was to tell the consumer and shortly after wrote the podcast:medium specification which was eventually finalized in The Podcast Namespace.

In parallel, the Podcasting 2.0 community had been throwing around ways to formalize live streams within RSS feeds.

Coincidentally, both had been finalized in Phase 4. It just so happens that the type of the live stream depends on the medium.

Our intent had evolved.

Since the intention of having a medium is to tell the consumer, and it's to be expected that not all consuming applications will care about all types of mediums, we had decided it was important enough to include in the basic event types of Podping.

We had also realized decentralized live feeds weren't of much use to anyone without the ability to instantly notify consumers when a live feed actually starts with an indication of priority beyond normal feed updates.

podping-hivewriter version 1.1

Given the above information, in addition of some new context about how the particularities of how Hive functions internally, we made the decision as a team to improve upon the Podping events by including the above metadata directly in the event names (known as operation IDs in Hive).

These event names are changing from podping to the format of pp_{medium}_{reason}, prefixed with pp_ to denote podping.

Where {medium} can be one of, as of this time of writing, the following:

  • podcast
  • music
  • video
  • film
  • audiobook
  • newsletter
  • blog

And {reason} can be one of, as of this time of writing, the following:

  • update
  • live

Importantly, the podping-hivewriter project will default to the podping medium and update reason to remain compatible with the current scope of users. Official documentation for the above reasons and their meaning will be available on the podping-hivewriter Github project by the time 1.1 stable is released.

One may replace the pp_ prefix with pplt_ for “podping livetest,” which is what we use during development and continuous integration of the podping-hivewriter project. You can use these “livetest” events to test these changes as a consumer before anyone officially adopts them.

Definition

In addition to the event name changes above, we also decided to change the on-chain Podping format to continue to communicate intent.

In short, the new schema will use version “1.0” to help compatibility and is defined as follows:

{
    "version": "1.0",
    "medium": "<ex: podcast>",
    "reason": "<ex: update>",
    "iris": ["list", "of", "iris"],
}

Most noticeably, urls is being changed to iris. This indicates given RSS feeds can be identifiers besides HTTP URLs — perhaps IPFS CIDs or magnet links, for example — and the character set is “internationalized,” supporting any UTF-8 character. Note that this has been assumed by podping-hivewriter since the 1.0 initial release and this is merely a name change.

The addition of the medium and reason slugs to this schema is primarily for portability of data and flexibility of filtering. It is redundant to have it both in the schema and the event name, and that is intentional.

Given the above additions, it's safe to say the following definition of Podping holds true and is identified by the intent of the given data:

Podping is a mechanism of using decentralized communication to relay notification of updates of RSS feeds that use The Podcast Namespace. It does so by supplying minimum relevant metadata to consumers to be able to make efficient and actionable decisions, allowing them to decide what to do with given RSS feeds without parsing them ahead of time.

Looking forward

We have some more ideas to expand upon the Podping update reasons listed above. However, many of these will require new Podcast Namespace features as outlined here by Brian of London.

For example, we want to be able to allow hosts to use Podping as a way to tell consumers when a feed is changing hosts. In order to prevent abuse, we want to be able to tell consumers to expect this type of event to come from a known Hive account set within the RSS feed.

After all, feeds already get polled to oblivion. Anyone announcing a feed update via podping is relatively harmless, even if it's not their feed. A host change, on the other hand, is another story altogether. We are trying to be cognizant of that for new features.

The <podcast:podping> proposal also allows consumers to actually know when a feed is set to update via Podping, as opposed to guessing, helping to remove ambiguity.

Conclusion

In the last year we've turned the Podping project around from an experiment that happens to work well to a full-fledged project with defined scope.

Podping doesn't just send URLs around to applications in hope that they know what to do with them, nor to funnel a user into clicking on something. It provides context as to why they were sent and how relevant the changes are to applications.

Because we don't need new ways to send people URLs. People have been trying that for the last 16 years.

#podcasting20 #rss #podping #hive #blockchain #podcasts #music #films #audiobooks #videos

Diving into controversy

If you know anything about me, you know I'm a very technical person. I am often the first person to point out when someone is merely arguing semantics that have no impact on a technical solution.

Perhaps stirred by the news that Anchor is only creating RSS feeds for its podcasts if users request one, James Cridland of Podnews recently responded about the semantics of “What is a podcast?

An argument about the benefits of an open ecosystem certainly helps.

However, it’s probably not too helpful to tell people who have just spent an hour listening to their favourite podcast on YouTube that, in fact, they’ve not been listening to a podcast. Because they have.

My last post even led with the exact same question. I'd go as far to say and agree that a podcast doesn't require an RSS feed. From a technical perspective, it's all semantics; one could implement the exact same functionality without RSS feeds and still keep it open.

The fact is an RSS feed is a standardized data interchange format. The tradition of using data within RSS feeds to supply audio files and other contextual information within an open ecosystem has worked well for the last nearly two decades, and there's no reason to stop.

But something phenomenal happened.

Falling for fallacy

For better or worse, the cultural phenomenon known as “podcasts” has outgrown its original technological implementation.

Reasons and motivations for this aside, it means podcasts have won. They've become more than an implementation detail. They are a modern representation of a cultural idea which has transcended what any single entity can control; that's the point.

Arguing about whether or not an RSS feed is required for this talk/theater-oriented, on-demand audio experience is merely a distraction. Organizations will either use it or they wont.

It's on us to keep the general art of podcasting open as a platform for free speech, available for all when the closed platforms ultimately fall apart. The proposition that podcasts don't require RSS feeds — while an effort I otherwise disagree with — wholeheartedly validates the Podcasting 2.0 movement by affirming RSS is for more than podcasts.

But how do we add more than podcasts? What if I want to create an application that utilizes RSS for films or music?

Overcomplication

If you're like me, many of you are thinking about nerdy tech-details of hosting or client-side implementation of new features. I get it. These concepts are new and non-trivial.

But we need to slow down. Before we can figure out what kind of data or user experience is needed for something like films, we need a way to know what's classified as a film. It's more than just a video file, and it's often a different user experience from watching YouTube or a television show.

Ask anyone if the film “Pulp Fiction” (pretend it's in an RSS feed) is a video podcast and you're likely to get either very confused looks or laughter, even if the delivery mechanism is fundamentally the same. But the same person knows films aren't limited to distribution on VHS tapes or DVDs.

Similarly, the move away from a definition of a podcast that mandates the use of an RSS feed makes the problem easier for us.

A long-solved problem

Users already know what they want. Even if they can't give you a definition of what it is, they know how to find it. Long before the internet — even electricity — people had stories around fires, cave paintings, town squares, theaters, books, newspapers... Currently these experiences are primarily, or at least most obviously, realized through different levels of applications or social media.

TikTok is the most obvious recent example of this phenomenon. It's not the company that made it popular, either; video shorts have been around for years, perhaps most notably from Snapchat.

It turns out semantics have already solved this problem for us. The distinction between the application and the medium they represent is a subtle, yet, significant point.

Medium

The medium is the message because it is the medium that shapes and controls the scale and form of human association and action. The content or uses of such media are as diverse as they are ineffectual in shaping the form of human association. Indeed, it is only too typical that the “content” of any medium blinds us to the character of the medium.

— Marshall McLuhan (Understanding Media: The Extensions of Man, 1964, p. 9)

Podcasts are a medium in their own right. Why not embrace it?

The construct of podcasts as a medium offers us a new, powerful opportunity: We can, at once, define a podcast beyond its technological implementation and use this concept to logically distribute other mediums within the same system of podcasts while not adversely affecting existing podcast applications.

We can use this idea to offer applications discoverability of mediums, existing or new, and give said applications hints at how to handle the content distributed by these mediums beyond only knowing how to handle an audio or video file.

Films and audiobooks might just be one item per RSS feed, because that's how users expect these mediums to behave. You don't typically search for the studio that creates a film when you want to watch the film — you search for the film itself.

Music, which technically plays fine in any existing podcast player, is often grouped into singles or albums but a user might prefer to follow the artist for new content.

The above user experience scenarios are only possible with knowledge of the medium — something which is already happening within the ecosystem of applications and websites but has yet to be called out explicitly within a content distribution framework.

Inversion of control

This isn't only for films, music, podcasts, or audiobooks. The mere standardization of data in an extensible, open, decentralized ecosystem with a method of practical real time updates opens up a whole new world of applications.

If someone has a new idea for a medium that doesn't exist yet, or they want to take an existing medium that's been locked into proprietary applications, it's as simple as defining it and showing the world. Why not take the concept of “video shorts” and open them up to the floodgates of reasonable competition?

As unlikely a scenario as it is, TikTok, Instagram, or even Spotify could just be hosting companies for video shorts, photographs, or music, respectively.

The inversion of control for applications to implement or define a medium without worrying about economies of scale within a decentralized ecosystem is possibly the most disruptive concept in technology since the creation of the World Wide Web.

For all we know, Adam Curry may well one day be clutching the last podcast of its kind within his cold hands, but a medium-agnostic, adaptable, open ecosystem laid out by Podcasting 2.0 will live on forever.

It's Space-Grade!

Stop worrying

Podcasts have grown beyond their original technological implementations that solved very specific problems into a medium in their own right.

Now is the time to extend the same courtesy of the open ecosystem to other mediums and take our own advice:

Stop worrying about the closed systems. We've already won.

#podcasting20 #rss #podcasts #music #films #audiobooks