So, let's start the next talk.
Introduction to the Open API, podcast API with Kuhn Glotsman and Karen Einzwort.
Sorry for the pronunciation.
So the stage is yours.
Thank you.
All right.
Thank you.
Thank you, everyone.
So, yeah.
We are here to present the...
Thank you.
Thank you.
We're here to present the Open Podcast API, which is a new specification that allows
users to actually synchronize their podcast listening data, like your subscriptions episodes
where you started, where you want to continue, et cetera, et cetera.
So why are we actually doing this new API?
It's because we have a problem.
The problem is that there is actually a defecto standard for synchronizing podcasting data
between devices, but it has a couple of challenges, let's say.
One of them being that it's no longer actively maintained for the moment.
There is a draft for a new version of the API, which is good, but has been still for
a while.
So that's one issue.
But maybe a bigger problem is that there are some technical issues fundamentally in the
API and the way it's designed.
One of them is about the episode identification, which is basically based on the media URL,
which is in the RSS feed.
And that thing is not always unique.
RSS is a standard, but it's a Wild West at the same time.
So we can't really rely too much on that.
So that's a problem.
And also, the software behind this standard has some issues with feed duplication, which
occurs if a podcast changes the RSS feed, they change their URL, then you get the same podcast
twice in your subscriptions list.
So I said, well, we didn't say that yet, but I'm with Antenna Pot and Kiran is with Funqvill.
And in Antenna Pot, what we see is that that service, that software behind the API de facto
standard is actually used as a centralized service.
So there's a lot of users, which is great, but it's also a restrain on the servers.
And so that overload is actually causing end users in Antenna Pot to see errors, and then
they come and complain to us and we're like, well, yeah, we don't have too much influence
over that.
So the solution there to this, these set of problems, is to build that new API standard,
which is actually building on the existing standard, but being more extensible, more
standards compliant, easier to implement across different projects so that we avoid the centralization
aspect.
So for users, that means that they can synchronize their subscriptions, listening progress, favorites,
cues, etc., etc.
That the idea is that they can connect all their different devices.
So whether you're on your desktop or mobile, or if you have a work mobile and a private
mobile, that all your listening progress, etc., moves from one to the other.
And also, this integration with the different apps would allow you as a user to actually
switch from Antenna Pot to Cast if you don't like Antenna Pot for some weird reason.
And so, that's on the end user side, but we need developers to implement that API, of
course.
To make that as easy as possible, we want to have clear and comprehensive documentation
about the features, but also about the behavior.
So if I send this API call, then what is expected to happen?
We want to have the specs being reliable and easy to implement.
And also, we want them to be feature complete, because different podcasting apps and servers
and services all have different features.
Some might have multiple queues that you can create.
Some like Antenna Pot, we only have one queue that you can create.
So we need to make sure that the API covers all these different use cases.
So the approach there is to build a new API spec based on the existing standard, which
I assume many of you might have guessed, is gpotter.net.
Notice that it's a great thing to start from.
And there are some issues that we are trying to solve.
So we're building on it in a way.
We're not building on it.
We're taking inspiration from it, I should say.
But actually, compatibility with it is not our main focus.
We also try to follow the OpenAPI standard specification, because that allows for easier
integration into software.
With by respecting this standard, we can have CI create libraries, which are always up to
date with the latest specifications.
And that's our plan also to do that for different languages.
And an important aspect there is also that RSS is our single source of truth, meaning
that we don't want to synchronize, for example, episode titles, because that's already in
the RSS feed.
So why would we synchronize data that's already in the RSS feed?
But at the same time, we also have already the GUIT of an episode, the unique identifier
of an episode in the RSS feed.
That's unique, but not really, because of RSS Wild West.
So we do actually expect to create and synchronize a true unique identifier for episodes.
And then we're also trying to be podcasting to the already, which refers specifically
to the GUIT at the podcast level.
And there are some technical challenges.
One is about the episode identification.
Like I said, there's a GUIT in the feed to identify an episode, but that's not always
globally unique.
So why is it called a GUIT anyway?
You have links and you have enclosure URLs.
And we thought, okay, to identify an episode in order to sync data between devices, we
could do a hash of these three, but they're all changing.
They're all optional in the RSS standard.
So you might have none of these and then end up with no hash, I guess.
So that doesn't really work.
So yeah, we are having the solution that the first discover of an episode, whether that's
a server, if it pulls RSS feed, the RSS feed, or if it's a client, it creates the GUIT.
And then yeah, there's some things that we need to consider.
Like first pull the new information from the server and then send it back to avoid race
condition, et cetera.
And also we expect the client to do the application of episodes.
But if you're interested in more technical aspects, there's a link to the notes.
Okay, thank you.
So building on that sort of quite specific example, there's the more general question
of feature compatibility.
So clients and servers need to agree in a way on what is compatible.
We need to have a way of communicating that.
So we can't expect all apps and services to support every single endpoint, every single
call because different apps implement different things in different ways.
So to sort of get around this, what we've decided is that we should have essentially
a core feature set where we say that specific endpoints are considered core and you must
support them as a client or as a server in order to be considered open podcast compatible.
There is of course then scope to optionally sort of extend this and to add additional
endpoints which give us more functionality but are not considered core.
So you can then negotiate that between your API, your server and your client.
These would be then documented in the specification, what is necessary for compliance, what is
an optional extension and then we can sort of work with clients and servers to map that
and say what is this, what works for you and what do you need to implement.
So what sort of endpoints are we looking to add?
Well, we've got a few that we've already been working on.
So as Kun has already mentioned, subscriptions is a big one.
It's fetching and storing and syncing all of your feeds, all of your subscriptions between
devices with the option to update them, change their URL or change their position or whatever
it may be and delete them and to manage them across all devices.
Versioning this is an important one.
If the specification changes and we decide to deprecate something, change an endpoint,
we need to express what major versions are supported so that clients are aware of what
they are able to get from the server.
We are currently discussing episodes but as Kun has already alluded to, this is a very
complicated thing.
So we already have a pad full of information about how we will synchronize this but the
goal is to have that sort of implemented to synchronize status and playback position,
how long you've played it, that kind of thing for all episodes across all different feeds.
In future, we would also like to be able to synchronize settings or give an optional
endpoint for synchronizing settings, search endpoint, discovery for discovering similar
podcasts and features and also ratings and reviews which are becoming a big part of a
lot of podcast stores.
Who's involved?
Currently, you've got myself and Kun.
We're from Antenapod and Funqwell respectively.
We've also been in conversations with casts, pod friend, Gpod Async for NextCloud and Musicpod.
The idea is to get as many projects on board as possible from both the client side and
the server side.
Funqwell acts as both but we're more steering for server side at the moment.
If you are involved in a podcast adjacent project, we would love to hear from you and
get your buy-in and your advice and feedback.
Just to mention on that last point, those are all open source but the idea is that closed
source projects could also use this if they wanted to.
What are our next steps?
As mentioned, we're still discussing episodes.
It's a big thing.
Something we need to get right and something that we need to finalize before we can consider
ourselves at a point where we have a core endpoint.
We also need to discuss authentication.
This is super important.
You should not be able to query somebody else's status and you should not be able to get a
hold of anyone else's data.
It must be locked down.
We need to discuss how we want to do that.
It will probably be just a case of OAuth.
That is for someone who knows more about OAuth than me to decide.
We're currently building a new website.
Currently we have a website which is built using Sphinx but we found some limitations
with Sphinx in terms of having dynamic content.
We're going to be rebuilding that using Astro and Starlight.
It's currently just in a pull request somewhere.
We're just waiting for that to get deployed somewhere.
We're mapping features across apps so we need to get a greater understanding of what different
features are available in different applications, how they present that information, and therefore
how we can present that in our API specifications.
We want to get a beta implementation in a few applications.
Client applications specifically.
We would like to have at least two maybe more supporting some of those core API endpoints
so that we can show that it works.
Which of course means we also want to have a reference server implementation which the
FunQuel team will be working on just so that people have something to test against, something
that they can deploy themselves if they want to.
We can check that our client implementations also work as expected and according to the
specification.
If you want to get in contact with us, contact details are up here.
There's a QR code you can scan but basically search for Open Podcast API.
It's where we are.
We're on Matrix.
We have the website which I mentioned we'll be replacing soon.
Obviously we have a GitHub organization which is where all of the conversations are currently
happening.
Get in touch especially if you are interested in podcasting or are currently involved in
podcasting we'd really like to hear from you.
If you have questions we will be outside I guess and we would love to hear from you.
We're very friendly I promise.
Thank you very much for listening.
I'll just put the contact details up again so that you can all take your time, scan the
code.
Thank you very much.
It was lovely.