Live Events in Podcast Apps

The <podcast:liveItem> element was introduced into the podcast namespace in January of 2022. It's description reads as such:

The liveItem tag is used for a feed to deliver a live audio or video stream to podcast apps. It takes the same format as a standard <item> episode tag, and all tags that are allowed as children of a normal <item> are also allowed as children of <podcast:liveItem>. Note that "allowed" is not the same as "supported". So, just like a normal <item>, you cannot depend on all apps to support all tags within <podcast:liveItem>, especially when the function of the tag is not obvious. For instance, including an <itunes:duration> tag in a live item is probably a waste of time since apps will not know what to do with that value in the context of live media.

This tag will also make use of the podping notification network. A podping notification SHOULD be sent out by the host when the live stream starts, to let apps know.

Before we dive into the technical side, let’s first discuss the framework of ideas that this element exists in.

Audio Delivery

The world of audio delivery can be broadly divided into two categories: live or on demand. Broadcast radio fits into the live category. When you turn on the car stereo, you get what you get. You are not in charge of the sequence of programming as it's delivered to you. Even if what you are hearing is pre-recorded, you are experiencing it "live" in the sense that the listener and broadcaster are in sync with one another. They are delivering content X and you are hearing content X at the same time. When I refer to "live", this is what I mean.

Digital audio is largely in the other camp. It's on-demand. In this model the "broadcaster" is really a publisher, in the sense that they are making content available, but aren't controlling in what order the listener consumes it. There is some sort of directory or guide or search mechanism where the listener chooses what they want and then plays it. The broadcaster might have just published content X, but you are listening to content Y.

Now, if you look at podcasting specifically, it has qualities of both. At any given time you are choosing what you want to listen to - but within each feed, you are not in charge of the content that will be delivered. The episodes come to you and can sometimes disappear from the feed if the publisher removes them. You don’t get to decide what a podcast feed will deliver, only whether or not you will listen to each episode. You could call this a sort of docketed live experience where it’s not real time delivery but it’s not fully on demand either.

Kinda Live vs. Actually Live

Ideologically, podcast listeners already, on some level, accept the fact that there is a curated experience wrapped up into their overall self-directed content experience. Radio stations understood this a long time ago when they began packaging their broadcasts as episodes after the fact and pushing them out on an RSS feed as a podcast. They took what was live and served it to the on-demand world. But, they retained that measure of control over what and when the content was made available.

It can go further. If a radio station can serve live content as an on-demand episode. It’s really not that much different than serving live content as an actual real-time event, maintaining the full integrity and control of the live experience. All that's needed is a content delivery description that fully accounts for the needed parts.

This is the sort of thinking that lead to the creation of a specific live item tag for RSS podcasting. But, let’s first look at an example of a standard podcast episode in an RSS feed. Then we will compare it to a live event in RSS.

This is a very stripped down version of a standard episode you'd find in a podcast RSS feed:

<item>
    <title>Episode 214: Poem Crate</title>
    <description>Adam and Dave Talk about Tom, Matt and a Donkey</description>
    <link>https://www.podpage.com/podcasting-20/214-poem-crate/</link>
    <guid isPermaLink="false">PC20-214</guid>
    <pubDate>Fri, 14 Mar 2025 19:21:22 +0000</pubDate>
    <enclosure url="https://mp3s.nashownotes.com/PC20-214-2025-03-14-Final.mp3" type="audio/mpeg" length="68197295"/>
</item>

You can see in the example that it would be quite simple to just change the enclosure tag to reference a live audio stream; something like an Icecast server URL since most audio streams are just mp3 encoded anyway.

Maybe it could look like this:

<enclosure url="https://live.noagendastream.com/noagenda" type="audio/mpeg" length="1" />

That might work sometimes. But there’s a lot missing here for a live event experience. Some notable ones are:

• Simply changing an enclosure URL to be a live stream URL confuses downloaders because the length of the download is effectively infinite.
• There is no way for a podcast app to know when the live event will start or stop.
• Attaching other metadata to the live event doesn’t make sense in the context of non-live events (i.e. - normal episode items).

These are the problems that the <podcast:liveItem> element was created to solve. It follows the exact same design language as a standard podcast <item> element, making it familiar to anyone who is comfortable with RSS podcast feeds. Let's explore it in both ideological and technical detail.

Elements as Semaphores

Elements within an RSS feed aren't simply packaged bits of information intended to be unwrapped by the receiver. They also carry a meaning. For instance, an <item> holds all of the expected information that a podcast app would need in order to render an episode to a listener. And, at the same time, the presence of an <item> means "episode" to the app developer. This function can't be overlooked. As an app developer you aren't just transliterating XML into some other format like maybe a collection of native app elements. You have in your mind during the coding process that this <item> is actually an "episode" of an audio show. That's why developers go to the lengths they do to create a design that makes sense to the purpose of audio. These elements mean something in the mind of the programmer.

This semantic aspect of the data packaging itself is a primary driver of whether or not to create a new RSS element for a feature, or instead try to fit a feature into an existing element or set of elements. Does the new feature require enough semantic force that a developer would need to keep it front of mind during the coding process? Then a new element might be justified. It's not the only concern, but it's not a small one either.

Live audio events, are distinct enough from standard podcast episodes that it really needs to carry such a weight. An RSS element dedicated to just live events, rather than getting shoe-horned into a standard <item>, makes the most sense. It actually makes the process cleaner for the podcast app developer.

Anatomy of a Live Item

Let's look at an example of a live item in its full RSS context:

<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:podcast="https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md" version="2.0">
    <channel>
        <title>Podcasting 2.0</title>
        <description>The Podcast Index presents Podcasting 2.0 - Upgrading Podcasting</description>
        <link>http://podcastindex.org</link>
        <docs>http://blogs.law.harvard.edu/tech/rss</docs>
        <language>en</language>
        <generator>Sovereign Feeds</generator>
        <pubDate>Mon, 24 Mar 2025 15:36:38 +0000</pubDate>
        <lastBuildDate>Mon, 24 Mar 2025 15:36:38 +0000</lastBuildDate>
        
        <podcast:liveItem status="pending" start="2025-03-21T17:20:00.000Z" end="2025-03-21T19:50:00.000Z">
            <title>PC2.0 215 Live March 21st 2025</title>
            <description>PC2.0 Episode #215 March 21st 2025 Live!</description>
            <enclosure length="33" type="audio/mpeg" url="https://live.noagendastream.com/noagenda"/>
            <guid isPermaLink="false">9997e1e0-186e-49cb-b64b-5471453d1ede</guid>
            <itunes:image href="https://behindthesch3m3s.com/wp-content/uploads/2023/01/v4v-storm-good-quality.gif"/>
            <podcast:contentLink href="http://adam.curry.com/html/NoAgendaStreamandCha-1414965812.html">Listen Live in the Chat Room</podcast:contentLink>
            <podcast:chat server="irc.zeronode.net" protocol="irc" accountId="adamc1999" space="#Podcasting20" embedUrl="https://kiwiirc.com/nextclient/irc.zeronode.net/?nick=webtroll?#Podcasting20"/>
            <podcast:socialInteract uri="https://podcastindex.social/@dave/110634382833124876" protocol="activitypub" accountId="adam" accountUrl="https://podcastindex.social/users/dave"/>
            <podcast:liveValue uri="https://curiohoster.com/event?event_id=8a2cfa5a-7a4d-466a-9d32-362ad68f945e" protocol="socket.io"/>
        </podcast:liveItem>

        <item>
            <title>Episode 215: Traffic and Weather on the 8's</title>
            <description>Podcasting 2.0 March 21st 2025 Episode 215: "Traffic and Weather on the 8's</description>
            <link>https://www.podpage.com/podcasting-20/215-trafficandweather/</link>
            <guid isPermaLink="false">PC20-215</guid>
            <pubDate>Fri, 21 Mar 2025 19:16:29 +0000</pubDate>
            <enclosure url="mp3s.nashownotes.com/PC20-215-2025-03-21-Final.mp3" type="audio/mpeg" length="68017364"/>
        </item>
        
        <item>
            <title>Episode 214: Poem Crate</title>
            <description>Adam and Dave Talk about Tom, Matt and a Donkey</description>
            <link>https://www.podpage.com/podcasting-20/214-poem-crate/</link>
            <guid isPermaLink="false">PC20-214</guid>
            <pubDate>Fri, 14 Mar 2025 19:21:22 +0000</pubDate>
            <enclosure url="mp3s.nashownotes.com/PC20-214-2025-03-14-Final.mp3" type="audio/mpeg" length="68197295"/>
        </item>
       
        ...
        
    </channel>
</rss>

You can see in the example above that a live event (<podcast:liveItem>) is a full peer to a normal episode (<item>). They are treated as equals within the RSS <channel> and live side by side. Indeed, they look almost exactly the same. Remember the documentation:

[The live item] takes the same format as a standard <item> episode tag, and all tags that are allowed as children of a normal <item> are also allowed as children of <podcast:liveItem>.

The <podcast:liveItem> element has three important areas that differ from a normal <item> and each will need to be handled properly by a podcast app developer in order to have a faithful live event experience for users. We can call these areas the "schedule", the "stream" and the "side channel". Let's look at each in order.

The Schedule

How does a podcast app know when to begin streaming a live event, when to stop and what state the event is currently in? It knows by using the <podcast:liveItem> element itself. There is also another option called Podping which I will discuss in a later blog post. For now let's go over the scheduling attributes from the example above. I encourage you to look back at the example to match up what we talk about as we go.

• The status attribute is either "pending", "live" or "ended". A status of "pending" means that the live event is scheduled but hasn't started yet. Keep this in mind. We will come back to it shortly. The "live" status means the event is in progress and you can listen now. The "ended" status means that the live event is over.
• The start attribute is the date and time that the event will (or already did) start. This is given in UTC time.
• The end attribute is the date and time that the event will (or already did) end. This is also in UTC time.

These three elements of information give an app developer what is needed to know when to start streaming (or at least when to notify the listener) the live event, when they can expect the event to end and whether the event has already started or ended. These attributes should be ingested by an app when reading the podcast RSS feed so that later, at the appropriate time, the actions can be taken to allow the listener to tune in.

Some examples of alerting the listener:

It's important here to talk about starting and stopping of live events and how that doesn't always happen at the exact times we plan on. Life is messy. Technology fails. People don't show up on time. There is traffic. All of that is just normal life. And, for those reasons, a start time of March 29th at 8:30 AM CDT might actually turn into more like 8:38 AM CDT. The Podping network solves this problem of inexact timing. But, it's not required. Just keep in mind that when humans are involved in time sensitive triggers a measure of buffer is always appropriate. Each app (if not using Podping) will need to make an account for this and find the front-side and end-side buffers that make the most sense for them.

The Stream

As we've already seen, referencing a live mp3 stream can be as easy as changing the <enclosure> element to reference an mp3 audio stream url instead of a downloadable file. If that route is taken, it's important to remember that the length attribute becomes effectively meaningless. It should still be greater than zero since some parsers and/or apps will have trouble with a zero length attribute. But, it can really be any positive integer value.

Another option is to go even further and use the <podcast:alternateEnclosure> element to get extremely fine-grained in handling different codecs and bit-rates. But, that's something we will cover in a future post. For now just know that the <enclosure> tag can serve the live purpose we need, and it's universally already understood by podcast apps. This is again why the semantic purpose of having a dedicated live item element matters. It can carry these changed meanings with it to sub-elements.

The Side-Channel

Finally, there are other data interactions you can "attach" to a live event that will enhance the listener experience. Some of these can be seen in the example up above. There are five that jump out:

• <podcast:contentLink> - The content link element allows the podcast publisher to give the app an alternate location (like a website or another app) where the live event can be viewed in case the podcast app can't handle the event directly. For instance, maybe the podcast "app" in this equation is a simple XSLT page transformation of the RSS feed. The page may decide to convert the content link element to a clickable link over to the alternate web location.
• <podcast:chat> - The chat element allows a podcast publisher to give podcast apps information about where a live chat for this event can be found. The protocol (IRC, Nostr, Matrix, XMPP, etc.) can be specified along with channel/room/topic information for joining the chat. Supporting this can be a heavy lift for some apps to support since chat protocols aren't easy.
  Luckily there are many available libraries to ease some of the pain.
• <podcast:socialInteract> - The social interaction element is very much like the chat element, except it specifies a social media platform and post where discussion about the live event will occur. This could be the Fediverse using ActivityPub, BlueSky using the AT protocol, X, Nostr, etc. The primary difference between social interact and chat is that chat is expected to be ephemeral and less publicly visible (not the same as private), whereas social network interactions are long-lived and more public.
• <podcast:funding> - The funding tag allows the podcast creator to specify a link to their donation page. No opinions are given for what this can be. If it can fit into a url, it's acceptable. This can be a powerful way to ask for monetary donations during a live event.
• <podcast:value> - The value tag specifies a set of receiving wallets for real-time payments sent directly to the creator. It takes the capabilities of the funding tag and adds minute by minute or single button donations to it. This tag is wide-ranging and will have a dedicated series of posts in the future.

We could brainstorm and come up with many more side-channel items that would live alongside a live event experience and make it better. These are just a few of the active ones in use today.

But, Why?

The technical implementation is straightforward. But, the bigger question is "why" podcast platforms should start supporting live events. Is it because "everyone else is doing it"? Is it the "next big thing"? Well kind of yes, kind of no and perhaps some other reason altogether.

YouTube, the ultimate on-demand proprietary creator platform, integrated live events into their offering years ago. Twitter/X did a few years ago as well. Netflix has recently added it. Hulu and other video streamers have added linear TV broadcasts. Amazon Prime has added live NFL games. Apple TV has added live baseball. Why have they all done this? Because, there is a feeling of incompleteness when you don't have both sides of the media delivery equation. We don't just read the news. We also talk about it with our friends. Life is always a mix of both past and present.

Podcasting, without the ability to stream events live, feels incomplete and immature in a way I can't fully verbalize. It's kind of hard to take it seriously. There is already a perception problem with podcasting. Often, when celebrities and news personalities leave (or get fired) from high paying roles they will go on to the next phase of their career by "starting a podcast". It's sort of the 2020's version of "spending more time with family". If we want the public to see podcasting as a fully developed, mature option for media consumption instead of a collection of also-rans and fringe content strung together on apps nobody has ever heard of, then live event support is non-negotiable. It carries with it a sense of legitimacy that I believe podcasting very much needs.

There is really no reason not to integrate live events into podcast apps. It's been working wonderfully for over 2 years now in the apps that support this feature. There are so many benefits to be had, and not a single downside I can think of. The lack of universal live event support in podcast apps is actively harming podcasting by making it impossible for linear broadcasters to make a full digital transition. The solution is simple and already in use. It just needs more coverage and awareness of how simple it is to implement.

To put it bluntly, stop complaining about YouTube if you can't even do what they do. If you only do half of a thing, someone else will come along and do the other half. And, that's on us for not finishing.