@adam @js @jamescridland @SirSpencer @dave @theDanielJLewis totally agree and I’ll stop making the argument lol.

I just want to advocate for Podcasting 2.0 apps to contribute to an open source socialInteract library to accelerate adoption and save us from duplicated efforts. Next time Podverse works on socialInteract we’ll start a JS library if it doesn’t exist yet.

@js @jamescridland @adam @SirSpencer @dave @theDanielJLewis but if Buzzsprout already added tags before any apps supported it, then there's a precedent. My suggestion just would be if Podcasting 2.0 community pushes forward with socialInteract app adoption, I think we should focus on an open source library. It's difficult for app developers to individually research the various implementation details of each socialInteract platform, and liable to breaking when the 3rd party platforms change.

@js @jamescridland @adam @SirSpencer @dave @theDanielJLewis I think it's difficult for RSS companies to want to present users with the option of adding a socialInteract tag when afaik there are no apps adopting it (except partial AP support in Podverse). Every option added to their RSS builder UI is overhead. If they can't explain to users how a tag will be useful for them today, they're unlikely to want to add that overhead. It's a bit of a "chicken or the egg" problem for adoption.

@js @jamescridland @adam @SirSpencer @dave @theDanielJLewis imo helper libraries may be necessary to get socialInteraction adoption. If every app has to add their own client-side query handling and UI rendering for socialInteraction, it's a lot of overhead. It's a big enough project to be someone's primary year-round project. That said, if someone creates an open source library for socialInteraction, it could take 15 minutes for all other developers to add socialInteraction support.

@dave is the dead podcasts endpoint broken? I'm getting a 500 error.

I'm trying this URL: api.podcastindex.org/api/1.0/p

Other PI API endpoints are working for me, but not that one. Anyway no rush.

Chris Fisher's epic rant about why Linux and the Free Software Foundation should support Podcasting 2.0 and Value-4-Value Bitcoin donations

From Linux Unplugged, Episode 440, ft. @dave podverse.fm/clip/uEwEyhe68

@mitch @SirSpencer @jamescridland @dave @theDanielJLewis @js one last thought then Ill stop spamming…a few podcasts I listen to have a livestream available only to premium paying members. Typically the live stream is on a Discord server or a hidden YouTube page. I’d love to get notifications for when they’re streaming, but it doesn’t sound like that will be feasible if the spec only has support for publicly accessible live-streaming endpoints.

@mitch @SirSpencer @jamescridland @dave @theDanielJLewis @js let me put it another way…if hypothetically I’m using Podverse, and I got a notification from Podverse that says “Joe Rogan streaming live now” and I open the notification, and then Podverse displays a screen that says “listen on Spotify”, I’m not morally opposed to that UX. It’d be better if I just watch it in Podverse, but if I can consolidate my livestream notifications to one app I’d still appreciate that as a user.

@mitch @SirSpencer @jamescridland @dave @theDanielJLewis @js but honestly I feel over my head in this debate. This seems like the first time where we have a spec where our decision making is not based solely on what podcasters want to do, but rather what we want podcasters to do. I might be misunderstanding the whole thing though. I just lean towards creating specs that let podcasters do what they want. In any case however PI specs it though, we’ll be adding support to Podverse day 1.

@SirSpencer @jamescridland @dave @theDanielJLewis @js I’m having a hard time grasping why liveitem can’t support in-app streaming and outbound links to closed streaming platforms. It seems trivially easy to add support for both to the spec. I don’t think it should slow the release either way, but I do think someone else will push a spec that allows links to closed platforms if we don’t allow it in the spec from the start, which makes me lean towards just including it from the start.

@theDanielJLewis @jamescridland @dave @js it’s not ideal, but a lot of people stream to multiple platforms simultaneously. Sometimes one platform’s stream goes down while the others stay up, so having backups is not entirely bad.

@StevenB oh dear 😨 hmm I use Brave as well, but I'm not getting this CORS error when I search for a podcast on our website...could there be a security setting or extension on your browser causing the different behavior?

@jamescridland @dave @theDanielJLewis @js if it's somehow in conflict with the spirit of Podcast Index to push a standard that includes non-open live streaming alternateEnclosures I can accept that. I just think it seems inevitable podcasters will want to include links to all their livestream options in their RSS feeds, open or not, and if the standard to support that is written outside of PI, maybe the competing standard won't support decentralized streaming capabilities as well as PI's would.

@jamescridland @dave @theDanielJLewis @js the "text/html" approach seems so trivially easy to implement, that even if PI doesn't support it someone else could push it as a standard.

Imo as long as the namespace ensures apps can reliably determine which alternateEnclosures are open streaming endpoints, and which are closed streaming page URLs, I'm not opposed to including both in a standard. I do wonder tho is "text/html" alone the right way for apps to distinguish open vs closed live streaming?

Show older
PodcastIndex Social

Intended for all stake holders of podcasting who are interested in improving the eco system