Sam Sethi: 0:12

Hello and welcome back to Podnews Weekly. I'm joined today by a friend of the show, Nathan Gathright. Nathan is the CEO. You probably know of episodes. fm. Nathan, Hello. How are you?

Nathan Gathright: 0:22

Hey there. Nice to be here.

Sam Sethi: 0:23

Now, Nathan, you and I have been on GitHub for the podcast 2.0 namespace talking about events which are to do with in-person events that you might want to publish in your RSS feed. where we got to.

Nathan Gathright: 0:38

Yeah, I think we're pretty close to landing on a fully fleshed out idea to help podcast apps display upcoming tour dates that either before VR artists or podcasters might have if they're doing a live recording or just a concert or any other sort of in-person event that listeners might want to buy tickets for. And the podcast apps could help promote that to their listeners.

Sam Sethi: 1:02

one of the things that you developed was the idea of a fully formed RSS feed for this event feed rather than a remote item publisher feed.

Nathan Gathright: 1:12

Yeah, I think you had a lot of enthusiasm to start with, but I just wanted to poke holes at it until it would make sense to everybody else to build in the same direction.

Sam Sethi: 1:21

I just say enthusiasm means you have no clue what you were talking about. That's what you meant. Thank you very much. Anyway, what you did was you took the crazy thoughts that I had, which was if you are a podcaster and you want to publish an event listing, it's easy. I thought if you've got a single venue with multiple dates because then you'd have a single location tag, a single person, maybe for the organizer, and then you would have multiple publisher dates. I couldn't work out in my head how you were going to do multiple dates at multiple venues for a single podcaster, and then you came up with it.

Nathan Gathright: 2:05

Yeah. I think equating the idea of making some sort of like events feed where all of that metadata is subservient to one off events. You know, maybe it's a podcast is going on tour and they'll have different guests at every single stop on the tour. Obviously, it's different venues. If they're in different cities or different start times. All of that metadata shouldn't live in like the channel level of the events feed. It should live at the item level of the event speed. So I took all the ideas you were throwing out there and wrote up an example spec feed of events so that we could just sort of nail all these ideas.

Sam Sethi: 2:40

And it's going to be there on GitHub. The nice thing about it is that we're using the existing podcasting to the tags, the location tag, the person tag, and we're mixing those together to create this new events feed. What also works really well is that there is a new link tag in there which allows the event organizer say, This is where I want maybe you to buy tickets or have the website of the event. If you just want to have more information.

Nathan Gathright: 3:09

Just like the link tag in any item, in any RSS feed, it's taking you out to a web page. In this case, it's a web page where somebody could buy a ticket. I think it's perfectly feasible for podcast apps to append maybe their own referral parameter and maybe some affiliate fees can flow back to the apps that way. We initially were sort of talking about what does splits look like in this use case? And it seems like it was maybe too daunting of a task to figure out how splits would work when you're dealing with, you know, ticketing capacities and refunds and all sorts of other things to do with live in-person.

Sam Sethi: 3:47

But I think it's a case of, yeah, let's not boil the ocean. It's fairly fundamentally easy to do in terms we just had a value block write to each event, but let's not try and out that before we've done everything else. The other part of this that I like is there is a possibility of using popping as well because it's a fully formed RSS feed. You might have a podcast with their RSS, with a podcast, events tag pointing to this new events feed. But in the event's feed, as I said, there's a link out to go and buy ticket. What might be nice is that when tickets are being bought from the third party ticket organizer, that there's a pod ping, an update to the RSS feed that says 77 tickets, 75 tickets, 12 tickets sold out or whatever, because again, the podcast app has to show or could show doesn't have to show how many tickets are available. So what is the capacity? And as that ticketing is going down, as more tickets are sold, it would be nice and popping could be the way because it's a standalone fully formed RSS feed.

Nathan Gathright: 5:03

Yeah, we all have to come up with some new tags to hold that metadata like, you know, remaining tickets available, those sorts of metadata that changes live after the tickets go on sale. But I think it makes a lot of sense for the events feed to be managed by whatever entity is handling the inventory of tickets.

Sam Sethi: 5:23

Now that's the events thing and obviously we're talking to a UK company who's organising an event so we can actually put it into practice, which is pod life events. And with my true fan CEO on, we have implemented an example. There's one called Oh for Food Sake, which again, if you went and looked for it in true fans, you'd find the events tab and in there you would be able to buy tickets to that event and so it all works. It's a fully functioning working platform example, although let's not say that there's many more than one right now, but there is one. Now, the other crazy thing that you and I were talking about, and I've been talking to Russell up Pod two and Kevin over our free pod is about creating a radio feed. Tell me more about what we were talking about.

Nathan Gathright: 6:17

Yeah, I think we were hashing out what, you know, if radio equals medium needed to be a thing and boiling it down to its core parts and realizing maybe we actually have all the tags we already need, the publisher feed gives us a cross show view of all the shows that, you know, a radio station might be broadcasting live. So if every show on a publisher has life items that are pending, you could aggregate those together and make a schedule to see what is the programming for this publisher and present that in a user experience that allows somebody to enjoy it the same way they enjoy a radio station except with the benefit of the value block as switching between shows and things like that. Yeah.

Sam Sethi: 7:03

So step one is you would create the radio station. Step two, you would add the shows to that radio feed for want of a better word, just for clarity.

Nathan Gathright: 7:14

That's really, you know, it's just a publisher feed, which hopefully they'll already be interested in making so that they can have a publisher page in the various podcast apps, but they don't need to add anything special to that publisher feed in order to for apps to be able to build features like this.

Sam Sethi: 7:30

And then step three would be to show or highlight all the pending live shows coming up. And then as you said correctly, it's abstract that into a single list view, which will be the schedule. And then the complex part, of course, is you would then add the publisher into each individual show's value. BLOCK Possibly or maybe do a way that the publisher actually gets paid a percentage when that played right. Each shows play to maybe the onus is not on asking each individual podcaster to add a publisher to the value block. But there is a better way to add the publisher themselves so they can say We've created this list and if anyone plays are list from our radio station, we get 5%. So maybe we do top down rather than bottom up is what I'm trying to say.

Nathan Gathright: 8:26

Yeah, that's a you know, that's a situation where it really proves the value of the reciprocal link of the publisher feed linking to the show and the show linking back to that publisher feed. You don't want somebody making a rogue publisher feed claiming, Oh yeah, I produce all of these shows and I should get a cut for all the listeners that come in to listen, even though I don't own any of them. So the reciprocal like link back and forth in the publisher feeds is a great sort of self verification method.

Sam Sethi: 8:56

the nice thing, you know, just to bring this up, Nathan, was actually we didn't really create much that was new. We just reused tags that were already out there.

Nathan Gathright: 9:05

Yeah, I think the sort of beauty of building a namespace full of little modular components is that you can figure out new and interesting ways to stack them together like Lego blocks and build something interesting.

Sam Sethi: 9:16

I guess we'll be talking more about these in the coming weeks, but thank you Nathan, for all of your input and you will be able to come to true fans and click on radio and click on events and be able to see these working. And what we really hope is that people go and look in the GitHub and actually see what Nathan's done and what a crazy idea. As I've commented around it. And then between us, we would love everyone else's feedback. And then if other apps, if they want to implement this, that would be amazing. Nathan, thank you so much for everything you've done Quickly. Episode. Stefan Give us a quick update. How's that going?

Nathan Gathright: 9:54

Yeah, episodes of Fame is going great. It's growing every day. I think we were over something like 5000 monthly active users when I last checked, but we are working towards opening it up so that podcasts, whether they're on the Apple Directory or not, can have a page on episodes of them. And more importantly, that people can claim their show claim of vanity URL, set up a custom domain, things like that. All of that's underway and there'll be more to tell soon.

Sam Sethi: 10:21

Brilliant. They think that's right. CEO of Episode Side of Fame. Thanks so much for your input. Speaker So.

Nathan Gathright: 10:27

Thank you.