Live item tag formalized. Please put eyeballs on this and check for typos if you can help a brotha out:

· · Web · 7 · 3 · 6

@dave so as I understand it, the link that has to point directly to the streaming audio is in the <podcast:source> tag? And the <link> can be to a broader page about listening live...

I'm just confused as to the <guid isPermaLink> tag in the example code, should this be different from the link or from the podcast feed's unique guid?

@SirSpencer Look at a standard <item> tag in your feed and base it off that. <pocdast:liveItem> and <item> are identical in their structure. The only difference is that liveItem has attributes (status, start, end) and uses <podcast:alternateEnclosure> instead of <enclosure>.

The other tags within the item continue to function as they do within a standard <item>, meaning <link> is a link to a web page for the episode and <guid> is a unique id for each individual episode in the feed.

@SirSpencer <podcast:source> is the sub-element of <podcast:alternateEnclosure> that specifies the url for the live stream data. So something like your icecast server stream url.

@dave oh gotcha, so like a permalink to the blog post or shownotes of that specific episode 👍


I can start getting this in the Genny. I'm thinking I can have it ready by the 21st.

Were you and @adam planning on doing a board meeting live soon? I was thinking on the NA Live stream, but it looks like that might interfere with Grumpy Old Bens.

@StevenB @adam Not sure when. Will prob discuss this week in the board meeting to nail down a time. Alecks is working on the new version of podping, so might wait for it to be done before trying to do one live.

BTW, I just made a change after talking to Alecks and we decided to allow a normal <enclosure> instead of forcing <alternateEnclosure>. Since 90% of people will probably just point <enclosure> at their icecast server, this will be easier.

@StevenB @adam I don't have mkultra finished yet either, but I guess we can just use the NA troll room as a test run to start.

@dave @adam

I've been playing around with a prototype, and the trollroom works well enough because I can just put it in an iframe, but still use all my wallet stuff for boosting.
(it's only styled for desktop right now)

Will MKUltra be able to use iframes?

@StevenB @adam For sure. It can load in an iframe. It's just a standard site, using websockets.

@StevenB @adam Hey, that prototype looks really good Steven. I dig it.

@dave @adam I'd like to have a leader board on right side that shows the top boosters, a boost/stream goal for the episode, and how close we are to reaching the goal, like one of those charity thermometer things.

@StevenB @dave @adam after I saw fountain's leader board for 2021 I want all apps to have one 🤩

@SirSpencer @StevenB @dave @adam it would be interesting for the podcaster to have a leaderboard. Having it just be in the app seems a little limiting. I boost from multiple apps and lose track of totals.

@Drebscott @StevenB @dave @adam yeah donors should be leaderboarded show-by-show, I'm just referring to the top earning shows in each app like fountain put out:

@StevenB @adam Yeah, Alecks has a good head for those things. You can make all the spec demands in the world but people will do what is easy. Best to accommodate it and not kick against the goads.

@dave as soon as this can generated and one app supports it, I'll announce and use on NA

@adam 👍👍 We can sandbox it on pc20 and work the bugs out. Brian and Alecks are working on podping bat signal support right now.

@dave @adam

Have you worked out how the live tag will be return in an Index Query?

I'm envisioning something where the live item is put up a few hours before the live event, then the app can check the start time, then start increasing it's polling frequency for that episode the closer it get to the start time until it confirms the episode is live, but I'm speculating on how this all will work.

@StevenB @dave @adam the live is going to work best when a pidping signal is sent like the bat signal Adam puts out. We could even do something cunning like watch twitter. 😎

@brianoflondon @dave @adam

How will the apps know an episode went live? Will they have to start monitoring podping?

@StevenB @dave @adam yes. And then use whatever notification system they currently use to notify apps. This bit is a bit outside my present knowledge.

@brianoflondon @dave @adam
Hmm... well, hopefully there's some documentation and examples written up, or I fear this will go the way of in-app comments because it's too difficult to figure out or implement.

@brianoflondon @dave @adam
I get the feed from PI every 30 mins, then compare to the feed I have stored, and of there's a diff I update the variables I need to and notify. I was thinking the PI would be pinged with live, then update the feed, which I would get every 30 mins.


It's serverless functions on Node.js over Vercel, so, I'm a little bit limited with some things, like no websockets.


I could do something like that.

To understand podping a little more though, would I be hitting the hive servers several times a minute, always looking for updates to the feed.


Do have a gut feeling how much processing resources checking and processing the hive chain every few seconds uses? I'm thinking about battery life for phones, but maybe it's pretty negligible.

@StevenB what I also think we will do, using a new feature of Hive that's only just coming on stream, is have our own relatively low power (i.e. we can have a few) dedicated API servers just for Podping and Podping-Live which will prefilter the chain and ONLY have the podping traffic.

That's what I'm building toward. Then watching the chain will be I hope really low energy if one can say, only give me live notifications.

@StevenB You'd be able to hit that ever minute perhaps sending a list of shows your watching and get back an answer.

@StevenB @brianoflondon You're not going to watch hive from the client, especially not mobile. You'll need a server somewhere doing it.

I'm doing it on my backend, and make podpings available over websockets - if you want to use it from your server go for it. Info here:

@js @brianoflondon @dave

This is what I was thinking. I figured having a <live> tag returned in the feed from the index with something like the status, start time, and stop time for each <live:item> would be enough for the app developers to get something put together. Then when the live ping goes out, the status is changed to "On Air" or something.

@StevenB @js @dave @agates and I have begun cooking up a plan which I hope will become a Hive funded proposal:

Alecks wants to build a general purpose server that watches the Hive chain and serves up whatever slice of live Hive your client requests as a websocket or other tech.

This would be a self configurable server so people can roll their own but we would run some nodes.

@StevenB @js @brianoflondon I'm watching podping already, and could easily put together a separate endpoint that monitors for status changes. Once I see what Brian and Alecks bake as the final form I'll start wiring it up.

@js @StevenB @brianoflondon I love all the glue you build John. It makes hard things easy.

@StevenB the api servers for Hive can cope, this is trivial for them.

Every browser running a view of a Hive based site is making API calls all the time. That's what the system is built for.


Now you just have to convince everyone Hive is the best alternative for comments as well.

@StevenB in Hebrew we say פרה פרה which literally means cow cow. It means you have to wait for the cows to go past one by one.

Arabic has a similar expression. shwaya shwaya. I can't type Arabic 😎

I can only do what I can do.

Just remember, 9 months ago you were the crazy Hive guy, now you have podping updating the database and soon for live.


@StevenB @adam I haven't thought that through yet. Are you talking about doing that through API calls?

Sign in to participate in the conversation
PodcastIndex Social

Intended for all stake holders of podcasting who are interested in improving the eco system