This is a good point I need to explain.
Sending out Podpings is a behind the scenes activity, very few users do it directly or are aware of it. 95% of Podpings are sent by a podcast hosting company sending a signal with just the podcast RSS feed address to podping.cloud which then gathers up all those RSS feeds and writes them to a custom_json every few seconds.
When designing Podping we deliberately made the messages as small as possible. It isn't Podping's job to tell you what has changed in a podcast's RSS feed, just that it needs to be checked. Parsing and decoding RSS feeds and looking for changes is a big deal and we don't do that, but those entities (like PodcastIndex or Apple, Google and Spotify) all have to do this to run Podcast indexes.
So if you publish a new show, then go back in and edit the show notes or update the title, those things can result in a podping going out again and again. This generally accounts for the multiple sending.
"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."
Oh okay, so a Dapp like D.Buzz could organize & render the Podpings, and display it on our site for #DBuzz users.
Posted via D.Buzz
There isn't much point to that. Podping is more like a behind the scenes communication protocol. Automated systems tell each other to do something out start something with it.
Eventually Dbuzz might like to show live podcasts for example but unless Dbuzz wants to be a general purpose podcast listening app I'm not sure what else they could do with podping.