Display cover image on subscribe page

[keunes]

Short description: Display a feed's cover image when cover image URL is provided in a parameter.

Location: Subscription page: https://antennapod.org/deeplink/subscribe/?url=https://podcast.thelinuxexp.com/@tlenewspodcast/feed.xml&title=Linux%20%26%20Open%20Source%20News
I would display it left from the page/podcast title.

Why have this: Makes the subscription page more appealing

More info:

• Builds on: Make subscribe page nicer #303
• Context: https://forum.antennapod.org/t/webplayer-share-landing-page-deeplink/3865
• Inspiration: https://podcastindex.org/podcast/5948837 / https://github.com/Podcastindex-org/web-ui/blob/d9b8e005a0c6ccfb86cd7dcff534fa86935fa9ac/ui/src/components/PodcastHeader/index.tsx#L94
• Need to check CORS. As noted by @ueen:

CrossOriginResourceSharing would allow embedding images and audio. Whether this is supported by most podcasthosts is an open question that needs to be investigated.*

*check this out Podcastindex.org image and audio doesnt seem to be cached, its linked straight from podigee-cdn

Nice to haves: display also 'author' and 'description'. On app side we need to consider URL maximum length handled by browsers - i.e. probably make the Description (stripped of any HTML) the last parameter and cut off at 2048 characters.

[antennapod-bot]

This issue has been mentioned on AntennaPod Forum. There might be relevant details there:

https://forum.antennapod.org/t/webplayer-share-landing-page-deeplink/3865/11

[ueen]

update info @keunes : we should add a linktree with links to the original episode/podcast host/website and AP (deeplink) and playstore/deep links to AP and other podcast apps (just like overcast does: https://overcast.fm/+8-KHJvrSw)

First imrovement: do an API with db and short URLs so not to encode in URL and have short hanable URLs (maybe theres already an open source tool for this or smth similar, its also very easy to implement).
would maybe look like this
-shorten: give json, save to db and answer with short url
-resolve: give shorturl and get json from db

Further improvement: embed mp3 like podcastindex to have a webplayer

[ByteHamster]

If we actually commit on adding a db, do we want to make it just a redirect to the static website we currently have? That would mean that clicking the short links brings users to the long url, so they see it and could maybe even share the long url using their web browser. I think if we have a database anyway, the episode page could also maybe be managed as a non-static site. But that probably requires quite a bit of re-strucuturing of the server architecture

[ueen]

No if where doing it anyways we should do an API with the app sending the info as json, saved to db and the landing page then getting that info by the short URL. It could be totally separate from everything else. I'm not an experienced dev and I've done similar small scale things like this in a day with SQL and php and js, just designing front end (CSS) is not my strong suit and I would like to not do that. For the rest I could code something simple. :)

[ByteHamster]

Ah, right. I didn't think about doing an API-style thing.

@keunes I think that this feature might require a change in our privacy policy. Currently we do not store anything about user subscriptions. With that feature, we would have to store all shared subscriptions. Do we need to add a way to share without using our link shortening service?

[ueen]

This should not affect any privacy policy, because no (identifiable) data about a user is shared with or saved on the server, only about the episode that is publicly available anyway. API would look like this -shorten: give json, save to db and answer with short url -resolve: give shorturl and get json from db not sure it needs a db (would be good practice i guess) but it could also be done with php and txt-files to keep it basic.

[ByteHamster]

The section "What data the AntennaPod core team may have access to" would need to get updated saying that if the users share an episode, the AP core team will know that someone shared that episode. If the subscription contains a private URL, we would also get access to it.

not sure it needs a db (would be good practice i guess) but it could also be done with php and txt-files to keep it basic.

Yeah, a database is definitely the preferred way over hundreds of txt files.

[ueen]

Ok prefect so we do a db and try to embed cover and mp3 like podcast index?

Who's gonna do this? I could take a stab at it, do a first draft in a day or so, or is someone more skilled/experienced/excited to do it? :)

[keunes]

we should add a linktree with links to the original episode/podcast host/website and AP (deeplink) and playstore/deep links to AP and other podcast apps (just like overcast does: https://overcast.fm/+8-KHJvrSw)

I don't really see why we need this; what the benefit might be. Sure it looks nicer, but most social media platforms already shorten URLs or have a fixed 'cost' in terms of characters.

CORS did not appear to be a problem, and I don't think another counter-argument was brought up (?)

[ueen]

I don't really see why we need this; what the benefit might be. Sure it looks nicer, but most social media platforms already shorten URLs or have a fixed 'cost' in terms of characters.

Not sure what you're saying here, the link tree is in spirit of an open podcast ecosystem, so it's not only AP to AP share. And the short link we need because its more concise and easier to handle for users.

[ueen]

I don't think another counter-argument was brought up (?)

So let's do this!

[keunes]

And the short link we need because its more concise and easier to handle for users.

Right… as I just noted we don't need concise links (see argument above). And I don't see why it's easier for users (a link is a link, and it's shared via the exact same 'share' button).

I don't think another counter-argument was brought up (?)

So let's do this!

You misunderstood. With 'this' I referred to the implementation as I described in the original post – i.e. having long links that contain the data. So let's do that! 😉

---

I am against having a database as

1. the site can no longer be fully static, and
2. it introduces a central point that is unnecessary (see arguments above).
   • Central point problem: if our database ever gets f*ed up/deleted, historic social media links are 100% useless. With a long link approach, the social media links are still worth 'something' (you can extract data).

[ueen]

I don't know, I don't get the spiritual desire to have a "static" site, whatever that means to you.
The issue is that the links would get really long if we do cover and mp3 and links to original page etc - essentially it would be a URL containing half a dozen other URLs, to me that's just stupid. 🙈
But ok I don't really care either way, I just think a db would be way cleaner and easier to maintain and the extra effort would be negligible, also I don't really get your @keunes strong opinions about coding issues as a non coder.... but fair enough I also offer more UI/UX opinions than I might be qualified for.
I just care about moving this ahead and this discourse begins to feel un-/counterproductive..
@ByteHamster what do you think?

[keunes]

I don't get the spiritual desire to have a "static" site, whatever that means to you

Maybe that's because you haven't been involved in maintaining the website because nobody else cares? (Note that that that's the position I've been in, even though it's not my expertise and would gladly see someone with the relevant experience committing to take over. Until that person is stepping up, I want to keep my work as simple as possible.)

The issue is that the links would get really long if we do cover and mp3 and links to original page etc - essentially it would be a URL containing half a dozen other URLs, to me that's just stupid

Can we focus on actual arguments, please? 'I find it stupid' is a worthless note here, doesn't help us any further. URLs being long is not an actual 'issue' (aka problem) – at least you haven't mentioned why long URLs might be a problem.

I don't really get your strong opinions about coding issues as a non coder

I haven't given any arguments about coding. I have given arguments about project maintainability, thinking beyond my personal involvement, many years in future. Please refrain from suggesting I said things which I haven't.

ok I don't really care either way, I just think a db would be way cleaner and easier to maintain

Focusing on the arguments: I've mentioned before why long URLs are better for long-term maintainability of the project. You are saying here that the contrary is the case. Care to explain why?

Also, why (and for whom) is it 'cleaner'? (Is this referring to URL length or complexity of website code?)

the extra effort would be negligible

I cannot judge the level of extra effort involved. But it needs no coding experience to know that no database is easier than a database, e.g. when in a year or two we change our (approach to) the digital infrastructure. (Note of context: There no official AntennaPod infrastructure currently – it's all on @ByteHamster's personal infrastructure. This is not healthy from a project management perspective and should change. I absolutely want to avoid the situation gPodder.net ended up in and the issues AntennaPod users have been faced with as a consequence.)

I don't really care either way … I just care about moving this ahead

Firstly: We know this – no need to repeat this over and over again on each of the wide range of topics that you suddenly are voicing your opinion on. I for one have acknowledged the issues you identified and do my best to keep up with the discussions you initiated (alongside other volunteer, professional and personal obligations). Your focus on pushing ahead without caring to engage in argument-based discussion on the different topics is getting on my nerves. This is a kind reminder of earlier requests to be respectful of the time we have invested in this project historically and are investing currently and, more importantly, the limits to our availability. (Considering also that there is no actual urgency for this task to be completed.)

Secondly, if you don't care about the approach and want to move ahead, please feel free to submit PRs for the app and website in line with the approach.