I spoke with Jack Rhysider a little today about fleshing out the open podcast subscriptions standard. He's working on something similar and we might try to see if we can mesh the two ideas into a standard. We'll see.

Not sure yet, but I've started putting my original idea down "on paper" tonight:

Any first thoughts on this idea? Am I crazy?

· · Web · 6 · 5 · 8

@dave To the extent that I understand the concept it reads well to me.

@dave it goes a step further to define an api for letting the app know the private feed url (or perhaps a token, in your proposal) once the user has finished buying the subscription in a web view.

@mkadin Immediate reaction is this seems to establish a single user identity across platforms and there's a notion of being "signed in". Those are a real problem for adoption. I may be reading it wrong though. Still reading...

@mkadin Hmm, I think I misunderstood this. Seems like they are wanting the feed to contain a pointer to an endpoint where a standard identity object is passed back to the app after authentication. Interesting idea.

@mkadin Hey @podcastaddict , have you ever heard of this proposal? "PodPass"? Seems like it was created in 2019 and I've never heard of it. I wonder what the adoption barriers would be from the app side.

The first adoption barrier I see is the writeup. I had to read through a lot of pages of marketing sounding stuff to get to the actual tech specs. My personal opinion is that specs like this should get right to the point and show code and implementation examples.

@podcastaddict @mkadin Thanks. That's what I figured since it doesn't seem to have been pushed much. Something about it seems odd to me but I can't quite put my finger on it. Will have to sit with it.

@dave @podcastaddict Yea -- I don't think this got broad adoption, but the guys behind it (now they are at ACast) did their best to get adoption. As you know well, it's hard to get the traditional app developers to move the ball forward!

@dave @podcastaddict Securing the enclosure URLS and simplifying feeds is good! but I point out this proposal because it also works to improve the user experience so there isn't a bunch of copying and pasting for end users; you can subscribe / pay right from the mobile app, and instantly get the new feed (or in your case, crypto info) loaded right in.

If an open standard is to compete with Apple / Spotify on this, I think it has to have a comparably simple end user experience.

@mkadin @podcastaddict Agreed. I do like the idea a lot. I think we (meaning the pc2.0 community) could help give it some legs.

I'll try and reach out to them after the 20th. I have a zoom workshop I'm doing on that day for a "women in bitcoin" thing to teach about podcasting 2.0 stuff. Prep for that is eating up some of my time right now.

@dave so exciting to hear Jack is collaborating on an open standard for premium subscriptions. Darknet Diaries is one of the best podcasts out there.

@dave not crazy.

Yet another thing begging for an @agates open protocol revealed in a self-hostable service to make a wallet(s), subscriptions, listened/new (to the listener) podcasts, etc. under the control of the listener.

I think I like the TOTP-based approach, but think it's one more thing that could benefit from standardization of how a podcast consumer can manage their world in in concert with the great work already going on here in the podcast feed namespace.

@mikeneumann @agates Alecks brought up the notion of a JWT instead of TOTP a while back. I can go either way. The JWT would be easier to implement probably.

@dave @mikeneumann @agates I was just reading this morning about NPR+, and how they somehow integrate with some 3p players like Pocket Casts. It's not via a discoverable open protocol, but NPR uses Supporting Cast to do it, and they have an api

Interesting reading, the signing part might be applicable to what you're thinking about.

It would be great if Supporting Cast supported a discoverable open standard for this.

@dave Briliant idea. I assume the podcasting app on the user side silently generates the next timed number from the base seed for each private subscription . Will the end user be prompted for a 6 digit number when subscribing? Or is that the responsibility of the podcasting app? I would prefer that the podcasting app pre-generates and supplies the next number ( possibly as a default option). Allowing users to use an external number generator to feed to their podcasting app is another option.

@dave The big problem is loosing the seed value for a paid subscription - I assume you would go back to the podcast hoster to prove its you who paid for it to retrieve the seed for your podcasting app. It will be up to the podcasting apps to securely store the seeds if they are responsible for generating the number sequences when the podcast feed is accessed. Else its the users responsibility to store the seed in their password generator app ( eg AUTHY etc ).

Sign in to participate in the conversation
PodcastIndex Social

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