This is a value for value post: see the explanation in the footer.
Today I put in a proposal to Podcasting 2.0 for a "Decentralised GUID system based on Podping". I'll be back posting about v4vapp v2 soon.
TL;DR What I'm proposing here is a decentralised lookup for a universal identifier for all podcasts. This has never been done before, people have used the Apple generated PodcastIDs or any number of non-universal keys.
The PodcastIndex defined a new GUID but right now only the PodcastIndex keeps a record of these. This idea is to use Hive as a decentralised lookup system which can't be censored or blocked.
https://github.com/Podcastindex-org/podcast-namespace/discussions/533
Over reliance on PodcastIndex.org's API
We recognize that enormous development has been spurred by the PodcastIndex and the API is being widely used but at the same time many of us know the inherently decentralised nature of Podcasting is one of its greatest strengths.
No large entities have captured podcasting and we're doing our best to make sure they don't.
GUID
Into this we recognised very early on that we needed a more reliable Unique Identifier for Podcasts which was host independent. Up to this point RSS Feed URLs have largely defined a feed with hit and miss methods to move feeds from one host to another. This has led to duplication and confusion.
To fill the roll of a unique, unchanging identifier for any podcast the GUID was adopted in Phase 3 1st June 2021.
GUID use increasing
As we move toward new tags such as <remoteItem> it becomes clear that the GUID is the most sensible way to identify third party feeds. Any use of URLs can lead to ambiguity and relies on unreliable redirection chains which may break.
GUID resolving
At present the only way to find an RSS Feed URL from a GUID is to query the PodcastIndex API or other systems run by PodcastIndex.
Proposal
Self Hosted GUID Resolver via Podping
What I'm proposing to build is a self hosted GUID resolver which can keep itself up to date independently of PodcastIndex (eventually). There are three components to this on the client side, all of which I believe will run happily side by side on a single modest server.
API server and Database
I propose and API server and MongoDB database running together in Docker. This will be able to return RSS URLs for any GUID (unfortunately there are some non-unique duplicated GUIDs at present) and the opposite to find a GUID of an RSS Feed if one isn't in the XML.
GUID-Slurper
This component (which can run alongside the API and Database, will stream Hive blocks and watch for announced GUID changes.
On first start up the system will fetch a recent data dump of all 6m+ GUID records and populate its own database. From then on it will scan Hive to catch up on any changes since the data dump and continue forward updating and maintaining itself without any further action. If it goes down, it will be able to catch up from where it left off.
This is similar to what I have already got running for Podping: api.podping.org.
Traefik Reverse Proxy
Included in the configuration would be a Traefik reverse proxy which handles SSL certs and makes the API available on a domain name.
Podping for GUIDs
At the PodcastIndex end (and with the option to decentralise later) is a simple addition to Podping which sends out a suitable message announcing any changes to GUIDs and URLs.
There is a higher degree of trust needed here: for the current system where most RSS Feed Hosts use podping.cloud this system is trustable. For later independent announcing of GUID changes (which I believe may only happen some years into this) we would have to rely on the RSS feed using the currently proposed <podcast:podping> tag to identify which Hive accounts (and only those Hive accounts) have authority to issue a GUID URL mapping change. It should also be possible to confirm that the GUID URL change requested is actually present in the RSS feed and they match at the time of ingestion.
Conclusion
What I'm proposing is that anyone can grab a domain name, pull a single docker-compose.yaml file from GitHub and with one command start up a GUID resolver.
Even whilst most of the input for this system will come via PodcastIndex to begin with, the tools and techniques necessary to announce a change of URL for a given GUID will all be public domain, free, open and permissionless.
Value for Value
For the last few months while building @v4vapp I was generously supported by the DHF. Going forward I have a much more modest support which covers direct server costs and a little of my time.
If you appreciate the work I do on and around Hive, you can express this directly: upvoting posts on Hive is great. Also consider a direct donation (there's a Tip button on Hive or a Lightning Address) on all my posts.
Support Proposal 244 on PeakD
Support Proposal 244 with Hivesigner
Support Proposal 244 on Ecency
Vote for Brianoflondon's Witness KeyChain or HiveSigner
