Proposal: Live System Architecture

[Muppet1856]

Architecture Proposal

In order to settle on a tag, its important to settle on the usage of the system as a whole.

Conventions

To help with the example I use the following terms and conventions:
bold = subsystem

Terms

Subsystem:	creator	publisher	advertiser	provider	endpoint
Description:	Podcaster	Podcasting Host	Index	Application	Consumer Device
Examples:	No Agenda, Daily Tech News	Podbean, Self Hosted, Blubrry, BuzzSprout, PodBean, Youtube, Facebook Live	iTunes, Podcast Index	Hypercatcher, PlayaPod, Podfriend	iOS app, Google app, GrapheneOS app, Website

Considerations

• This solution attempts to maintain a fluid model whereby any subsystem could be handled by a single operator, and is not wholly dependent upon any one member of the supply chain
  • Ex.1 a user should be able to enter a RSS for a podcast into their endpoint, and the provider could arguably retrieve the xml, parse the tag, subscribe and provide the stream to the user without any other involvement.
  • Ex.2 A podcaster should be able to stand up their own repository and self-publish, combining the creator and publisher subsystems into one. Similarly, an endpoint could act as provider as well all within the application, such as with a browser plugin.

Proposed Use Case - A publisher model with centralized aggregation and decentralized propagation of notification

Note: The use of RTMP was chosen to provide a specific mechanism, but could be replaced with others interchangeably

1. Publishing the podcast as supported
   1. The creator indicates as a show
      • This is a publisher interface, maybe a checkbox? Its basically there to prompt the publisher to make sure there is a tag and it gets populated.
   2. The publisher adds tag to XML with stream source, stream notifier subscription address
      • This is the area of open question. It may be simple enough to have the stream address be fully qualified with the protocol and that would allow the standard to evolve with protocols.
      • My narrow view is RTMP, but there may be a better choice. I suppose the address could be an http(s) which could point a user to the big-tech options or a publisher based WebRTC.
   3. The advertiser updates the Index with the stream address, and the publisher subscription address
      • Would be an address that accepts POST whose payload includes the provider webhook for start/stop notification.
2. Subscribing to a show
   • provider enrolls in stream notification from publisher by posting the provider webhooks address to the publisher stream subscription address
3. Going Live with podcast
   1. The creator pushes stream to publisher
      • I envision this utilizing RTMP or RTMPS - one advantage here is the built in functionality of RTMP to fire events on stream start, such as a routine to notify the downstream consumers
   2. The creator announces stream to publisher
      • With RTMP(S), this can be as simple as pushing the stream to the publisher, or could require a user to push a "go live" button on their panel.
   3. The publisher announces stream to provider
      • webhooks...
   4. The provider announces stream to endpoint
   5. The endpoint accesses the stream utilizing the publisher stream address

Proposed Enclosures

<podcast:live>
   <item>
      <title>Podcasting 2.0 Live Show</title>
      <description>&lt;p&gt;A look into the future of podcasting and how we get to Podcasting 2.0!&lt;/p&gt;</description>
      <link>https://example.com/podcast/live</link>
      <guid isPermaLink="true">https://example.com/live</guid>
      <author>John Doe (john@example.com)</author>
      <podcast:scheduledstart>Fri, 09 Oct 2020 04:30:00 GMT</live:scheduledstart>
      <podcast:scheduledend>Fri, 09 Oct 2020 07:30:00 GMT</live:scheduledend>
      <itunes:image>https://example.com/ep0003/artMd.jpg</itunes:image>
      <podcast:images srcset="https://example.com/images/ep3/pci_avatar-massive.jpg 1500w,
         https://example.com/images/ep3/pci_avatar-middle.jpg 600w,
         https://example.com/images/ep3/pci_avatar-small.jpg 300w,
         https://example.com/images/ep3/pci_avatar-tiny.jpg 150w" />
      <itunes:explicit>no</itunes:explicit>
      <podcast:season name="Podcasting 2.0">1</podcast:season>
      <podcast:episode>3</podcast:episode>
      <podcast:person href="https://www.podchaser.com/creators/adam-curry-107ZzmWE5f" img="https://example.com/images/adamcurry.jpg">Adam Curry</podcast:person>
      <podcast:person role="guest" href="https://github.com/daveajones/" img="https://example.com/images/davejones.jpg">Dave Jones</podcast:person>
      <podcast:person group="visuals" role="cover art designer" href="https://example.com/artist/beckysmith">Becky Smith</podcast:person>
      <enclosure url="rtmps://live.example.com/live.mp3" type="audio/mpeg"/>
      <podcast:subscribe url="https://live.example.com/subscribe"/>
   </item>
</podcast:live>

Concerns

<podcast:scheduledstart> could be a discrete time, or a pattern? Having someone update their XML and hope that it propagates to their subscribers in time is worrisome.
<podcast:scheduledstop> could be a disaster. I don't even know if anyone would care...
<title> & <podcast:episode> are either redundant or useless. I'm not sure they are helpful in the context. The <channel> text is probably the most helpful here and <podcast:episode> suffers from the same issue as <scheduledstart>.

[daveajones]

Thank you for putting in the work for such a thorough writeup. Very helpful.

[agates]

Hmm, I've seen various live tags proposed in several different places now... this aligns most closely with what I've had in mind, and I'm going to give a shot at an opinionated implementation for Peertube.

A few thoughts.

I understand some people just want one stream link and a recurring schedule, but we all know the schedules never match up with reality except for perhaps stricter business use cases. I think we can optionally allow for a "planned" schedule such as an ICS file, but I think this would be most useful for 1. feed refresh hints 2. UX display in a sort of calendar setting (when is this stream happening next)

WIth ISO 8601 durations we can include the planned start and end time into one tag. The benefit of this is it doesn't strictly require an end time, like you alluded to, but it can be included. I can see a use case both with and without and I think websub should be a strict requirement around this feature for it to function correctly regardless, where the RSS feed host either removes the live item or adds an end after the stream ends. There may be a need here for Podcast Index to offer a basic live notification API for applications that don't host their own servers.

RTMP is fine but it's also the most difficult to support especially on the web. I think RTMP, HLS, and DASH should all be options and I foresee HLS initially being the most common due to existing web technologies. All three have their pros/cons that I can see various different providers being interested in supporting. I think peertube does a weird RTMP->HLS thing both to support existing streaming software (OBS for example) but to get the benefits of HLS+peer-to-peer.

I know even less about the audio-only streaming side so I can't really speak to that. I'm going to go ahead and plug alternateEnclosure here for those various benefits. Maybe there's also opportunity to provide embedded players instead of having every client bring their own? That could be disastrous for UX, so I'm not sure.

Lastly, why not <podcast:liveItem>? I can see the point about just including <item> under a live tag, however I think it's important for this to semantically serve a different purpose and it will also contain tags that <item> would not. Yes there is some duplication, but it's also a completely new thing (and let's be honest, this isn't a normalized schema).

Anyway, with the right implementation here I can see this so close to becoming both youtube live/twitch alternatives with all of our own features built on top. Kind of curious to see if the Floatplane guys would have any input also and be willing to collaborate, since they represent a pretty strong community as a realistic youtube-alternative.

[Muppet1856]

I understand some people just want one stream link and a recurring schedule, but we all know the schedules never match up with reality except for perhaps stricter business use cases. I think we can optionally allow for a "planned" schedule such as an ICS file, but I think this would be most useful for 1. feed refresh hints 2. UX display in a sort of calendar setting (when is this stream happening next)

I had thought of this as an optional tag, for people who intend on keeping a schedule, or at least attempting to keep one. One of the things I had always heard about the success of a podcast is to have a show that maintains some sort of schedule. The granularity may be the most suspect thing. Many shows offer a "daily, weekdays", "weekly", "twice-a-week", with no guarantee on time of day. This is probably the most difficult part of setting a standard for schedule.

WIth ISO 8601 durations we can include the planned start and end time into one tag. The benefit of this is it doesn't strictly require an end time, like you alluded to, but it can be included.

Existing standards are good, and for explicit dates I think ISO8601 is a possible solution, but it does not lend itself to posting a schedule... Thursdays and Sundays at 12PM Eastern or Weekdays at 3, at least not from what I can garner from reading the wiki.

I can see a use case both with and without and I think websub should be a strict requirement around this feature for it to function correctly regardless, where the RSS feed host either removes the live item or adds an end after the stream ends. There may be a need here for Podcast Index to offer a basic live notification API for applications that don't host their own servers.

I was unaware of websub when I wrote it down. After reading up on it, it looks like I am endorsing the same. I would like to hear hosting providers opinion on this point, as they would bear the burden of running it. That said, there are a lot of implementations that allow for this to be leveraged... (https://github.com/w3c/websub/tree/master/implementation-reports)

RTMP is fine but it's also the most difficult to support especially on the web. I think RTMP, HLS, and DASH should all be options and I foresee HLS initially being the most common due to existing web technologies. All three have their pros/cons that I can see various different providers being interested in supporting. I think peertube does a weird RTMP->HLS thing both to support existing streaming software (OBS for example) but to get the benefits of HLS+peer-to-peer.

I'm not clear on how difficult this is to stand up. I did it in just a few minutes using nginx and the RTMP extension on a RaspberryPi 3 and putting one up as a publisher should be trivial as well. I don't know how it scales in terms of compute resources... This doesn't feel like a limiting aspect of a <live> tag, and should probably be left to folks who might have to provide these resources to optimize.
FYI - as of today, this is what each of the "major" streaming services support for ingest.

Provider	RTMP	RTMPS	HLS	DASH
YouTube	x	x	x	x
Twitch	x	-	-	-
Facebook Live	-	x	-	Beta
PeerTube	x	-	-	-

I know even less about the audio-only streaming side so I can't really speak to that. I'm going to go ahead and plug alternateEnclosure here for those various benefits. Maybe there's also opportunity to provide embedded players instead of having every client bring their own? That could be disastrous for UX, so I'm not sure.

I'd like to see what @daveajones has to say here as NA does a live audio stream, but I think they are using a basic html5 <video> element with only an audio source... Not sure what the ingest looks like.

Lastly, why not <podcast:liveItem>? I can see the point about just including <item> under a live tag, however I think it's important for this to semantically serve a different purpose and it will also contain tags that <item> would not. Yes there is some duplication, but it's also a completely new thing (and let's be honest, this isn't a normalized schema).

I don't know how the various feed aggregators would handle any of this. Does Apple just ignore any tags and their children that it doesn't support? Frankly, I wrote something here to start this conversation...

Anyway, with the right implementation here I can see this so close to becoming both youtube live/twitch alternatives with all of our own features built on top. Kind of curious to see if the Floatplane guys would have any input also and be willing to collaborate, since they represent a pretty strong community as a realistic youtube-alternative.

My goal with this description and of the <live> tag is not to replace the existing live-streaming infrastructure, but to augment it. Hopefully, with adoption, people will see the light and take control of their content, leveraging a <value> friendly distribution method.

[agates]

Existing standards are good, and for explicit dates I think ISO8601 is a possible solution, but it does not lend itself to posting a schedule... Thursdays and Sundays at 12PM Eastern or Weekdays at 3, at least not from what I can garner from reading the wiki.

A schedule of when a stream plans to start and the actual start are two very different things. The schedule is ultimately meaningless in the face of when something goes live and trying to predict it will fail, you can only provide a suggestion.

To represent the schedule itself, I think ICS is perfect here. It's widespread and a very well known standard. This could just be a URL with a last modified timestamp.

I am all for a schedule.

However, I'm separately suggesting the "start"/"end" (duration) be the time when the stream has started/ended and applications can display it as an active live stream or know when its over. The live item could even disappear completely if the stream doesn't persist as something to watch after it's over.

This gets us the distance between the client application merely guessing when something might be live to having a reasonable amount of confidence that it's live so it can display it and notify the user. It really depends on websub + application notifications however.

[daveajones]

This tag deserves a phase all to itself I think. It’s a big one and we need to get it right.

[keunes]

(Regarding schedule, #154 might be related/relevant.)

[Muppet1856]

A schedule of when a stream plans to start and the actual start are two very different things. The schedule is ultimately meaningless in the face of when something goes live and trying to predict it will fail, you can only provide a suggestion.

This was my intent - that a suggestion could be part of the feed so an app could surface it to the end user. Like a reminder in the morning.

To represent the schedule itself, I think ICS is perfect here. It's widespread and a very well known standard. This could just be a URL with a last modified timestamp.

No disagreement there.

However, I'm separately suggesting the "start"/"end" (duration) be the time when the stream has started/ended and applications can display it as an active live stream or know when its over. The live item could even disappear completely if the stream doesn't persist as something to watch after it's over.

I'm assuming that this might just be "solved" because a live episode that comes back as a "produced" episode would automatically update the feed with the permanent version and a temporal live episode with no watch later wouldn't exist.

I'm also guessing this particular comment has to do with nuances of peertube and I don't yet understand the challenges there.

This gets us the distance between the client application merely guessing when something might be live to having a reasonable amount of confidence that it's live so it can display it and notify the user. It really depends on websub + application notifications however.

I see this is as a "morning reminder" that my show is scheduled to be live at 12:00 (local). PodPing would do the actual announcement.

[saerdnaer]

Whats the reason to wrap the item into <podcast:live>? Every item which does not have an enclosure tag is normally ignored by regular podcast apps, so we could simply add a new item which only contains the livestream urls e.g. via the <alternateEnclosure> tags...

[daveajones]

I feel like this was discussed but I don’t remember why the decision was made.

@agates @Muppet1856 ?

[agates]

I don't think live stream URLs have to live within alternateEnclosure. The two tags are pretty independent now.

Regardless, I need to get a usable test implementation out before saying I have a preference either way. My gut feeling is it should just be podcast:liveItem.

[agates]

A schedule of when a stream plans to start and the actual start are two very different things. The schedule is ultimately meaningless in the face of when something goes live and trying to predict it will fail, you can only provide a suggestion.

This was my intent - that a suggestion could be part of the feed so an app could surface it to the end user. Like a reminder in the morning.

To represent the schedule itself, I think ICS is perfect here. It's widespread and a very well known standard. This could just be a URL with a last modified timestamp.

No disagreement there.

However, I'm separately suggesting the "start"/"end" (duration) be the time when the stream has started/ended and applications can display it as an active live stream or know when its over. The live item could even disappear completely if the stream doesn't persist as something to watch after it's over.

I'm assuming that this might just be "solved" because a live episode that comes back as a "produced" episode would automatically update the feed with the permanent version and a temporal live episode with no watch later wouldn't exist.

I'm also guessing this particular comment has to do with nuances of peertube and I don't yet understand the challenges there.

Well my intention is to provide enough information to keep the application from having to assume anything. If we provide a way to explicitly tell the application what happened, no assumptions have to be made (ignoring the issue with bad data but we will never prevent that).

This gets us the distance between the client application merely guessing when something might be live to having a reasonable amount of confidence that it's live so it can display it and notify the user. It really depends on websub + application notifications however.

I see this is as a "morning reminder" that my show is scheduled to be live at 12:00 (local). PodPing would do the actual announcement.

Yeah, PodPing wasn't a thing when I made this comment :). However schedules do not indicate liveness. They can and will be wrong.

[Muppet1856]

@agates, I feel like we've both come to the conclusion that podping is the obvious solution to notification of live.

Maybe I should rename it from podcast:scheduledstart to podcast:suggestedstart or podcast:plannedstart ?