Posts

Answering questions about @podping on Hive

avatar of @brianoflondon
25
@brianoflondon
·
0 views
·
5 min read

Thank you to all who've already voted, the proposal is almost funded but I'm happy to answer any questions. These questions came in as a comment from @gerber

Support this as proposal 181 on PeakD Support proposal 181 on Hivesigner

Q1 what's the point of saving urls to centralized rss feeds on hive, i found manually not working one by checking few old urls, is there use case for this? how you query it from hive? Is it usable only for notifications from live stream?

OK this is the big picture: there are 3.9m podcast RSS feeds, 99,000 have updated at some point in the last 3 days. In order to know if any of them have updated you have to hit their RSS URL and ask, is this feed different from last time.

Even that operation is not exactly simple because some feeds don't always update their timestamps correctly and have other meta data problems. Sometimes its not enough just to perform a HEAD request so you have to download the entire RSS file and some of these are bloated and huge.

Podping is NOT a replacement for a centralised index of all podcasts. Up to now the largest and most frequently used podcast index was Apple's. Google has one too. So does Spotify. However each of those indexes has shown themselves willing to censor podcasts. Podcast Index (@podcastindex) was set up to be a new index which operates on a neutral, censorship free basis.

This update notification service, which Podcast Index is sharing with the world, can eventually cut all RSS polling traffic for finding new episodes down to almost nothing. That needs the big hosts to adopt it (we have 4 and other working to come on stream next week). There are only around 26 hosting companies accounting for 90% of active podcasts. We can do this!

Eventually the idea is when 80 to 90% of all active RSS feeds for podcast industry are using podping, lots of client applications and indexes can stop speculatively checking RSS feeds every hour and just check all the shows that appear on podping, or only the ones they're interested in.

And the point here is that if a podcast is "deplatformed" by Apple or Google, its pings can't be blocked because Hive is anti-censorship especially for tiny notifications like this.

Now if you want to start up a new podcast app, in the past you either had to use Apple's API or build your own index. But Apple have been messing around with their API and they have started banning shows on ideological grounds like Alex Jones. That isn't kosher.

Podcast Index is the index that promises a free API based on value for value donations and promises to be as free speech as possible (within the law in the US of course).

Any new or existing app can do searches and find shows via podcast index but getting updates of new shows was always reliant on doing their own polling. Podping makes that much easier and uses far fewer resources for both the web hosts that host podcast shows' RSS feeds and the clients who will now only download the shows that alert their updates via podping.

Q2 what's the point of spamming hive so much, transaction count? can be reduced significantly by simple grouping, also py code above(probably not actually used already) I think would crash on 5+jsons/block. Generally tx count means nothing in this case with centralized app broadcasting data. You can make it more or less, with line of code.

You can find all the data on live use of Podping here on Seakingtruth's site

I'm being pretty careful to limit the TXs to around 3 per minute averaged over the day. We're averaging 3 to 5 URLs per custom_json. This is a good trade off for immediacy and keeping the overall notification time quick. There's an unreleased update that tries to minimise some of the meta data (using a single integer for the version number)

Q3 does indexing happens on hive or centralized database? The big success so far is Podping. This is now deployed and in beta and being used by four major podcast hosting companies and by Podcast Index itself.

There's no need or use for indexing on Hive of this custom_json data though future parts of Hivemind I believe will do something like that. If there was a way to make these custom_json's ephemeral I'd be using it. We probably only need at most 4 weeks worth to be stored. But this is all new.

how it's used? live stream of notifications that can be achieved same way podping does by any other centralized app? Is there anything that makes podping better? so before they were streaming rss feeds now they stream hive?

What's the benefit of using hive instead of just building API?

:)

Sure: Podcast Index could build a centralised API server system to do this, and in fact, Dave Jones had actually proposed something called Hydra to run a decentralised polling system which relied on volunteers running a local code, being given 100,000 feeds to check and then return answers to the centre if any had changed. But who wants another centralised point of failure especially in front of the still largely decentralised world of podcasts!

It was after hearing about this system that I proposed that Hive act as the message carrier in the middle. Anyone can write to Hive (with an account) and anyone can listen to the stream without an account.

And the system is resilient, has run consistently for years and this use doesn't stress it significantly. Podping is currently posting less than 0.6% of all the custom_json traffic on Hive!

And yes, a global, cross platform, uncensorable "going live" notification system is next. One where it doesn't matter what platform you're live on or what app your subscribers are on, nobody stops the Hive Podping getting through.

Podping on Hive may well form the basis of an entirely new form of blockchain based Internet Protocol: this is what I'm hoping it becomes!

Support this as proposal 181 on PeakD Support proposal 181 on Hivesigner

Much more information here: