Ideas and attempts have been made to develop a new standard for podcast synchronisation (see GitHub - OpenPodcastAPI/api-specs: Open Podcast API specifications · GitHub). With the hope that it would come of the ground, I purchased a nice domain that AntennaPod or the project independently could use to host the synchronisation server. (I don’t want to name the domain here just in case.)
There’s a lot of interest from AntennaPod users in a better and easier way to synchronise their listening progress. Progress (in the defining of an API) has stalled a bit, however, and given the uncertainty I’m not interested in renewing the domain out of my own pocket.
What do people think of renewing the domain with AntennaPod money? It’s € 70 for two years.
Please reply with a or to give your opinion. In two weeks from now I’ll check the votes and, based on the outcome, will renew the domain or not. I will only renew if a majority is in favour.
we should only allow AntennaPod users to create an account on this service, i.e. no web registration but in-app registration
we should keep a very close eye on database and performance
we should, therefore, actively (co-)maintain the sync server
Reason: if things go south for whatever reason we have plausible deniability – as we have done with gpodder.net.
Do we want to be responsible (also brand-wise) for our own sync server? It’s a considerable responsibility. If yes, who will take up this work (for eternity)?
Also:
serving the open podcast community: I’d rather have (spend money/time/effort on) a sync server that can also cater users who don’t use AntennaPod (e.g. Kasts + Pocket casts).
server load spread: there will probably/hopefully be more sync servers. Having an ‘official’ AntennaPod server in the list will probably mean a higher load on this single server than would have been the case if there are only ‘third-party’ servers. All our regular users would blindly pick the official one if it exists. If there is no ‘official’ one, they might do a little research into the possible servers (find a compatible server online if we don’t provide a drop-down like is the case now, or research which server to pick if we do offer a drop-down). We could counter this by randomising sign-ups (in the app) between a limited set of trusted servers, but then there’s no point of having an ‘official’ server.
(Related problem, which I expect to be more prominent with an official server: users are likely to use sync as a back-up solution. There’s some measures we could take to counter this, which would require more involvement in the server software.)
For me, this is more an ‘upstream contribution’ then ‘we need something for AntennaPod’. And indeed we’re swimming in money so can afford it.
Not sure this is really relevant. It will not be a web player, so the only time you’ll see this URL is when you add/link or remove/unlink a device. Sure, having it on our domain would create some level of trust, but our users will trust whatever is in our list (as proven by all users who had no problem signing up to gpodder.net)
I don’t think that’s necessarily related to the domain name. If anything I think it’s good advertising to offer our services as a public sync server under the AP domain, that being said obviously we might have to review it if it suddenly became viral, but I think that’s a far off concern.
I’d add that if in the future the service has to be taken down, as it’s only a sync service it’s easy for users to simply export the state from their local devices as a backup, so planning long term is perhaps not quite as much of an issue as something that would be irreplicable. On that note:
Yeah, it might be wise to do something like automatically delete user data where they haven’t synced in 30 days or something and make it clear that it’s purely a sync service. Then again, I doubt very much that the service should have very much resource demands at all. Just holding a list of sync items for a couple of thousand users should be able to run on a Raspberry Pi without much issue IMO, if architected carefully.
The reason why gpodder.net was unreliable was that those “simple” sync items accumulated to hundreds of gigabytes on a pretty beefy server. Depending on how actively we promote the server, it might have to serve hundreds of requests per second during peak hours at AntennaPod’s current user base.
I feel like if we start to host something as the core team, this results in essentially the same responsibility no matter what domain the server is hosted on.
Generally speaking, given that core team time is scarcer than funding, I agree with @keunes that donating upstream makes more sense than embarking on a time-consuming project with unknown running costs.
On the other hand, reading the above, I think some clarification is needed on the outlook for the upstream project and whether/to what extent the donation is likely to contribute to further progress there.
That’s a fair question. I’ve built a bit of frustration with the speed of progress in this area, but I also know it’s part of the deal with open source. Everyone has a life apart from FOSS and we’re doing this in our own time, for fun.
I do think that if commit to helping this get further, we can make progress. There’s field knowledge from several podcast clients (AntennaPod & Kasts), we have someone willing to write the API specs, and we’ve folks willing to implement a server. It’s (just) a matter of spending time to bring the three together and getting momentum.
Long story short: if we pull our weight, I’m convinced we can have a sync server well within two years (the time span of the funding I was suggesting). But yes, that would imply making the choice to spend time on this (which takes away time from other efforts).
or 
to give your opinion. In two weeks from now I’ll check the votes and, based on the outcome, will renew the domain or not. I will only renew if a majority is in favour.
.