And friends of mine had trouble dealing with shared links from AP, either to the mp3 or the website of the podcast, both of which do not seemlessly open their favorite PodcastApp (hopefully AP).
I suggest doing this, seems easy enough, maybe someone is more experienced with web-dev, i feel i could do it but’d take me forever.
Thoughts?
Bonus: cooperate with Overcast and link them/have them link AP on the share-landing pages
(rational: its as much AP as there is on iOS as far as i know - even though its sadly not opensource but very free otherwise; and its an excellect piece of software)
Doesnt have to be so sophisticated, I would do it almost completely clientside. Let me paint a picture: Share is initiated on AP, an API request is preformed and sends all info that is required (cover link, mp3-link, feed-link) to the server which saves it and creates a a short link which is the response. This link can be shared and via deeplink opened and resolved in AP. I think it’s important in order to make this default to have a landing page in case the user doesn’t have a podcast app yet or another one and to keep in spirit of a open ecosystem.
The Share-Landing page could in a basic form just display the cover and a link tree with links to the original page, AP or other podcast apps, just like the overcast landing page.
If possible but optionally the mp3 could be embedded but CORS is a good point, I’m not sure about. But I think to get the DeepLink we just need the link tree landing page.
With this I would feel confident to make this the default share method, as to make the UI/UX more consistent, comfortable and overall nicer, while keeping the open ecosystem spirit and even promote it: If someone is using something like Spotify and maybe even doesn’t know about the open podcast ecosystem and a link like this is shared they get an opportunity to choose and AP is a great choice!
So for this we would need a simple script for the short link and a database and the basic link tree webpage. I estimate that this would take me 2-3 days but for a skilled dev this could probably done before lunch. Obviously to make it really nice and polished more time could be spend, but I’m very much in favor in getting a basic version out and polish afterwards with user feedback as a guide
I would even offer to work on this, I’m just terribly slow on CSS and HTML so I works greatly appreciate some support
The cover cannot be hotlinked because of CORS either. So to show a cover, the server needs to load it, cache it (so that it doesn’t get rate limited by the original host), and deliver it to the clients. So it needs cache management and quite a bit of storage+bandwidth. Almost nothing can be done entirely on the client because of CORS. And then the server needs spam prevention to avoid getting the database flooded, etc. So it’s much more than just a simple script.
I have already created a PR to make the updated deeplink page the default share page.
I looked into it a bit and if anything is preventing it it would be SameOriginPolicy. On the contrary CrossOriginResourceSharing would allow embedding images and audio. Whether this is supported by most podcasthosts is an open question that needs to be investigated.*
Still without cover and mp3 we could dislay the title of the episode and provide the link to the original podcats website, the RSS feed, to antennapod and other apps. If you’re worried about the database, we could also encode everything in the url, that would be a long url but it would still work - no database required.
So the bare bones version would be, encode everything in the url and proivde a linktree on the share page - i feel this would be required before making it the default in AP to keep the spirit of an open ecosystem, it feels a lot like apple if the default shared link can only be used to open antennapod. (overcast is setting a great example)
Maybe the bare bones version is a good start, low time effort and high reward plus we can improve from there
Yeah, better think things through before doing them than having to fix stuff in production later. Because usually I’m the one who has to do the time-critical fixes later.
I’m all for thinking things through, I just wish for a open, true and constructive process.
For adding single episodes I proposed a nice UI/UX as well that would remove the featureless preview completely and offer the full (hidden, not updated) feed instead, which would also enable download and adding to queue - something extremely useful for moderate effort.
And then extending the share landing page (with shortend links and cover, and webplayer) would make sense.
I think we should take great UI/UX inspiration from overcast and for the CORS look at how podcastindex is doing it, because I agree, AP shouldn’t run a CDN!
See Add/play single episode without subscribing to podcast · Issue #4710 · AntennaPod/AntennaPod · GitHub, that’s exactly what we settled on. It just needs someone to implement it. That is a huge feature that will probably take months of development and testing to get it right (for example, the “all episodes” screen should not show these hidden subscriptions, it needs to be considered during search, sync, auto-download, etc. The hidden subscriptions should be cleaned up automatically at some point. The hidden subscriptions should still sometimes be refreshed when opening their details screen. It should be clear for users why “real” subscriptions store the “played” state while the hidden ones don’t, etc).
The barebones version with encoding everything in the URL is implemented now (for feeds, without image) and will be released in AntennaPod 3.3.