Proposal: <podcast:podping> tag

[dellagustin]

Hello All,

As a developer of a podcast aggregator, I like the idea of "watching" the Hive blockchain for updates.
It would be interesting to have information in the feed that indicates I can rely on the hive blockchain information instead of polling the feed from time to time.

This is also an opportunity to consolidate it as a decentralized podcast and include information on the feed that allows the client to validate if the information on the blockchain was inserted by a trusted "writer" (I don't know the terms here, is it an account? a public key? something like that).

[francosolerio]

Really interesting. It would solve the problem where the app doesn't know when to stop polling the RSS feed, and when to resume polling the RSS feed too in case the publisher choses to quit/suspend using podping. The latter might not be great for us, but developers must be sure their apps data don't get stale.

[brianoflondon]

I'm 100% for this and I think the feed should absolutely include the authorised Hive account which might be unique to that podcast or a standard one for a given Host.

Right now all of rss.com transistor.fm, buzzsprout and captivate would list hivehydra

<podcast:podping authorized="hivehydra">

I'm not thinking that the watcher will check for the authorised account (it's too big an operation) but there could be a dedicated server that scans for feeds declaring a new hive account that hasn't been seen before to automate the process of allowing new accounts to Ping in the future.

[theDanielJLewis]

I'm also 100% for this!

[brianoflondon]

And @daveajones the PodcastIndex probably should have a database entry and api call for authorized podping sender which will serve as a way of knowing if a show needs to be polled or can just be watched for on Podping.

[brianoflondon]

This is the draft I wrote, perhaps it's a bit early to send a pull request.

The "podcast:podping" Sepcification

Version 1.0 by Brian of London - 2021.06.08

Purpose

The Podping notification system is rapidly developing as a new standard for signalling new episodes of podcasts to reduce constant polling. Once a new episode or entirely new podcast is sent out as a podping on the Hive blockchain, aggregators and apps can query the feed.

However, as pointed out in issue #258, there is, as yet, no way to know which feeds are using Podping.

This tag proposal will allow feed owners and the hosts of multiple feeds, to signal that future updates will be sent via Podping and there is no need to speculatively poll this rss feed.

An additional benefit will derive if feeds signal the name or names of the Hive accounts authorized to send Podpings. These authorized Hive accounts will be included in a <podcast:podpingAuth> tag

API Requirements

This tag can also contribute to a future API endpoint for the PodcastIndex which can easily return whether or not any given RSS feed is using Podping and return the Hive accounts authorized to send pings.

Specification

For the <podcast:podping> tag there are no attributes.

For the optional but helpful <podcast:podpingAuth> tag there is one attribute, a single value with a single allowed Hive account.

Example

<podcast:podping>
    <podcast:podpingAuth account="hivehydra"/>
    <podcast:podpingAuth account="hive-hydra"/>
</podcast:podping>

[brianoflondon]

As for how the tags go, I'm not sure if XML it would be better to do this:

<podcast:podping>
    <podcast:podpingAuth>hivehydra</podcast:podpingAuth>
    <podcast:podpingAuth>hive-hydra</podcast:podpingAuth>
</podcast:podping>

[brianoflondon]

I'm currently working on 3speak RSS feeds and while it makes sense to notify that this feed uses podping, the idea of saying which Hive account can actually send the notification doesn't make a lot of sense and we're unlikely to every use that feature.

I'm thinking that this is more appropriate.

        <podcast:podping usesPodping="true"/>

[daveajones]

Phase 4

[brianoflondon]

There's no harm in sticking that in feeds right now is there?

[daveajones]

No harm other than having to change it later if it gets altered. It'll be universally ignored now, so it's not going to hurt anything.

[brianoflondon]

Let's close this issue, it's taken over by the Proposal for Podping tag

[tomrossi7]

Couldn't this just be a selfclosing tag? If its there they are using Podping. If not, they aren't.

<podcast:podping />

[agates]

Could do, but I have some plans in the future to expand this with additional child tags for additional Podping functionality. Explicit rather than implicit makes more sense to me. And if you ever needed to turn this off for some reason an attribute would make that much more obvious.

[tomrossi7]

You can still extend the tag, but just the presence of the tag implies that podping is supported. 🤷‍♂️

[redimongo]

I can see the upside to this, as it would mean we would not get polled all the time, however I have an issue with the fact it looks from the documentation that this is a centralised server that if who ever is managing these servers went down or had an outage it could affect every single podcaster that uses the platform.
https://github.com/Podcastindex-org/podping.cloud/raw/main/framework1.png

The other thing that sounds confusing is that you're hoping that directories utilise this, which we know Google, Amazon, Youtube won't be doing, so who is this really designed for?

[agates]

https://github.com/Podcastindex-org/podping-hivewriter