I reached out to Simplecast to see if they were planning on implementing PC2.0 namespace items, mainly because I listen to TheBibleProject, and they would totally benefit from chapter art. Here's their response:

"We do not currently support Podcasting 2.0 Namespace, mainly because it has yet to be adopted by any of the major listening apps."

I'm a little disappointed.


CurioCaster is ready for some Peer 2 Peer testing. Click the link above, hit play, then the link below. The link below will take you to a test site that shows all the peers your sharing bandwidth with, easing the load on the servers hosting the file, lowering their overall cost to host the file. If you find any bugs, let me know.


@agates What's the best way to handle a WebTorrent tracker. Should that be done by the app developer or the video hoster. If a video hoster has a tracker, should they include that info in the alternateEnclosure so the app can make sure to use that tracker?

This issue got me thinking about it.


@Drebscott I just saw the black rooster on the the latest PC2.0, and thought something was wrong with my CSS file.

@brianoflondon @dave Would it be possible to store episode comments on the hive block chain, and then anyone who wants to get the comments is able to get them off of the chain, store them in a database, then just monitor the chain for new comments to store in the database?

Oh man, I'm jonesin for a new PC2.0 episode. I keep checking my feed every 10 mins to see if it's been posted.

I wonder when @dave is having a craving for something, if he calls it Dave "Jonesin"?

I'll look into and add it as an option. Mr. Gates, you have taken me down quite the rabbit hole with this alternateEnclosure. 😉

Yeah, I have three instances with the html open, but I'm not seeing them pop up on Novage, so I'm not sure if my code is allowing p2p to work.

@agates Just to be clear, you're eventually doing away with "application/x-bittorrent".

"application/x-mpegURL" is what you're moving towards, which should save you bandwidth for popular feeds.

Am I correct in my understanding?

Does anyone ever use the volume controls inside of a podcast player?

I find I never do, and just use the keyboard controls or the volume controls on the phone.

It’s taking up mobile screen real estate, and if nobody’s using it, I want to nix it.


I saw you merged the PR, but I'm not seeing CurioCaster in the list of apps. Can you double check to make sure I entered everything in properly?

That makes sense. Something that indicates this feed will only ever have one item, so when the feed is clicked, it automatically loads the enclosureUrl and brings up the player rather than going to a list of episodes.


Super Interesting Read about the Wuhan Lab Leak Hypothesis.

I love this line
"...might never have happened if a radical and decentralized group of outsiders hadn't challenged the status quo"

2) having a badge that displays “new” whenever new episodes are detected in the app, but will mark those episodes as stale after a certain time period or when the app is reloaded. After the episodes are marked as stale, the new badge disappears until fresh episodes are detected

3) something else I’ve not considered


Show thread

What do you think makes for a better UX to indicate a feed has new episodes available?

1) having a badge that displays the unseen episodes count with the ability to mark all episodes as seen. This count stays persistent until the episode is view, listened to, or marked as seen.


@dave Would it be easy to have a separate API endpoint that only returns the last time the feed was updated.

Something like `/api/1.0/lastupdate/byfeedid?id=`
Then, whenever a feed is pinged or parsed, the lastupdate time is changed.

Right now, every 30 mins, my app reads each feed, then has to parse through the data to see when the last update was. It would save a ton of bandwidth if I had only the lastupdate time returned, then if I need to I can hit the feed url to get the new episodes.

I'm wondering if newpodcastapps.com needs a little bit of redesign. My thinking is if podcasters are sending their audience there to find players that support the PC2.0 features, they're probably not interested in hosts and directories.

I'm wondering if having two separate pages would serve the community better, one for podcasters and one for listeners.

As the number of apps grow, the list will get longer, and we may want a separation of concerns to serve two different groups.

To the best testing team in the universe, curiocaster.com/ has a new feature to test.

Podcast specific boosting / streams.

No more having to change your values for each separate podcast.

Like Ron Popeil says "Just set it, and forget it"

Show older
PodcastIndex Social

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