Podcasting 2.0 – Evolution of Podping

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.

Reposted from https://write.agates.io/podcasting-2-0-evolution-of-podping