Feature Requests

When Podlink was running, could customize the backend of the URL for an attractive link to share with potential listeners. Is that possible with Episodes.fm ?

When sharing links for episodes, they're displaying as "undefined". This is a new development; I haven't changed any of my settings. https://www.episodes.fm/1561294951

Please include a link to podcasts on Amazon Music (main podcast page here: https://music.amazon.com/podcasts ), which is one of the largest podcast services following Spotify and Apple.

Hearing impaired people benefit from capitalization to distinguish among words in vanity links so TTL service providers can recite links as intended. However pod.link/6DegreesOfCats doesn't work when you capitalize each word in the suffix. Could this be updated to make the string at the end of the pod.link non-case sensitive?

If I use Python's base64 standard functions, or the unix base64 command, then often padding (equals signs) is added to the string: $ printf https://www.burtonini.com/temp/early-green.rss | base64 aHR0cHM6Ly93d3cuYnVydG9uaW5pLmNvbS90ZW1wL2Vhcmx5LWdyZWVuLnJzcw== However, if I use this padded string on pod.link then the decoding fails and it doesn't work. Strip the padding and the link works. For example, https://pod.link/aHR0cHM6Ly93d3cuYnVydG9uaW5pLmNvbS90ZW1wL2Vhcmx5LWdyZWVuLnJzcw== redirects back to the home page, but https://pod.link/aHR0cHM6Ly93d3cuYnVydG9uaW5pLmNvbS90ZW1wL2Vhcmx5LWdyZWVuLnJzcw works. This makes integration somewhat annoying, as the padding has to be manually removed. The padding doesn't change the output, so this seems like a bug in the decoder.

I noticed that Snipd isn’t currently available as a destination on pod.link pages. Snipd is a popular iOS podcast app with stable deep links and Apple Podcasts ID resolution: https://www.snipd.com ( https://apps.apple.com/us/app/snipd-ai-podcast-player/id1557206126 ) Would love to see Snipd as a supported app destination.