Mitch Downey :pci:

open source developer @ podverse.fm / fediverse / foss / javascript / node.js / podcasts / react / react native / typescript

Podverse: https://podverse.fm
Github: https://github.com/mitchdowney

Public Key

npub1p7v0a3mgwgqkhyuuwwrdf7kyt8c0gker3asa4lp0l626p0f3ck5sklqql0

NIP-05 Address

mitch_at_podcastindex.social@momostr.pink

Profile Code

nprofile1qqsqlx87ca58yqttjww88pk5ltz9nu85tv3c7cw6lshla9dqh5cut2gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds9k92m3

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1p7v0a3mgwgqkhyuuwwrdf7kyt8c0gker3asa4lp0l626p0f3ck5sklqql0

Show more details

Last Notes

2026-04-13 22:56:33 UTC

- reply

sorry I missed this. I’ll add it to our priority parsing list so it is less likely to fall through cracks in our legacy platform.

2026-03-19 05:33:00 UTC

- reply

this is also something we could add to Podverse Alpha fairly soon. The main blocker for me would just be a working livestream to dev and test against. Is there a 24/7 feed using this in the wild? Maybe too expensive for someone to run, but I imagine the use case could apply for displaying "Now Playing" info for 24/7 RSS radio/tv stations?
Also, the use case seems like it may be broader than "value" specifically. "Live Info Updates" or something.

2026-03-19 05:28:59 UTC

- reply

yes, I would like to support it.
re: a schema, a small suggestion I have would be, where possible, to follow patterns that align with RSS naming conventions?
channelTitle
itemTitle
Not sure what else this could apply to. Not strictly required. Just an idea.

2026-03-18 19:50:22 UTC

- reply

cool, thank you. I'm working on adding retry handling and better error message displays right now.

2026-03-18 19:02:13 UTC

- reply

do you know if the Podcasting 2.0 node has availability issues? In some of my tests, the lnaddress lookup works, and in others, it seems to fail.
@npub18xh…9nzr can you confirm if any of these errors are expected?
Unless these errors are entirely on Podverse's side, it seems there is quite a bit of cleanup and rejuvenation needed for the V4V Bitcoin Lightning ecosystem. We are happy to help however we can.

2026-03-18 18:58:29 UTC

Podverse Alpha update 🛠️
EXPERIMENTAL: USE AT OWN RISK
Bitcoin Lightning V4V transactions are live in Podverse alpha!
It supports the traditional "node" send approach with metadata for sending messages, and it also supports lnaddress, but does not yet support sending messages with lnaddress yet (it will just send an amount for now).
I tried sending a 1234 sats boost to @npub18xh…9nzr and Podcasting 2.0 with mixed results...unsure if these failures are due to node issues, or buggy PV code.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/251/680/484/742/949/original/dd2d496098ddb4e8.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/251/688/802/129/544/original/e2e38ef869640e75.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/251/693/834/951/408/original/4711529cda8efb48.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/251/697/474/068/516/original/4a49e4b841d78232.png

2026-02-28 05:44:10 UTC

- reply

tbh I enjoyed the moments of zen 🧘‍♂️

2026-02-24 21:18:27 UTC

- reply

interesting ok. So type="lightning" is sufficient to signal to us this is a BTC LN wallet. "type" on the recipient lets us know what approach to use to send to the wallet. Thank you! I have some rewriting to do 😂

2026-02-24 21:13:09 UTC

- reply

is it accurate to say that both "lnaddress" and "node" implementations are both method "keysend"?
I have been talking about "lnaddress" and "keysend" as if they are two different things, but it looks like (according to the P2.0 RSS feed) the difference is between "lnaddress" and "node" rather than keysend?

2026-02-24 21:08:53 UTC

- reply

Looks like the Podcasting 2.0 RSS feed has it. I'll use this as an example.
https://feeds.podcastindex.org/pc20.xml

2026-02-24 21:06:44 UTC

Can anyone point me to an RSS feed that has a proper <podcast:value> lnaddress implementation?

2026-02-21 18:04:01 UTC

- reply

nice feed report page! I hadn't seen this.

2026-02-21 00:32:27 UTC

- reply

as for Podverse, we've been talking it over, and we don't really want ownership responsibility of payment metadata, so we're looking into if there's a way to bridge these worlds. Continue using the lnaddress metadata format other apps are using, but look for an opt-in declaration by the podcasters for where they want their metadata sent.

2026-02-21 00:27:55 UTC

- reply

keysend still works as it did back in the beginning, I believe.
A key difference between keysend and lnaddress, is that keysend lets you send metadata with the payment, but lnaddress does not.
lnaddress does however, allow you send a memo, and so some apps are now hosting their own "boost metadata" endpoints, and including a link to boost metadata in the memo of the payments.
https://github.com/Podcastindex-org/podcast-namespace/pull/734
So keysend adoption appears to be fading, while lnaddress adoption is rising.

2026-02-21 00:21:42 UTC

- reply

> I have no idea what kind of features have been implemented in the spec over the last year
I was posting the same thing a couple weeks ago 😂
In short, for BTC, lnaddress and keysend. Each has trade-offs.
lnaddress is nice bc it lets people specify a human readable, username/domain "email style" reference, that can be looked up to get the wallet address. this lets people provide their lnaddress, and potentially change the wallet address it directs to later.

2026-02-18 21:39:54 UTC

- reply

it certainly can produce garbage. It just seems like it can be steered effectively for dramatic productivity boosts in programming.
I'm throwing a pretty complex plan at Codex 5.2 today for v4v integration + metaboost + boostbox + alby prod/sandbox implementation. will see how it goes...

2026-02-18 20:52:40 UTC

- reply

true. I saw "The Tech Report" and assumed it was mostly a SWE audience.

2026-02-18 08:12:15 UTC

- reply

I keep seeing takes like this…and I’m wondering if I’m really bad at coding and naive, or people are in denial of just how effective LLM is at it.
I barely have to write syntax directly these days. I often have to prompt for improvements, and use some of my own knowledge with debugging, but even after all of that, I feel like my productivity is many times faster since December.
I lean towards the skepticism of this tech being more bullshit than the claims that it’s revolutionary.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/090/596/387/153/389/original/4a061e2d5decafdc.png

2026-02-15 02:31:04 UTC

- reply

I didn’t know about the metaboost tag. Seems like exactly what we’d need to support LNURL without losing boost message data.
Boost message data should probably be pulled out of the keysend implementations anyway since it’s so restrictive.
Podverse might be open to hosting a metaboost API as well. I don’t know how we’d manage the spam and abuse problems though…Alecks if you have ideas and would ever be up to talking about them I’d appreciate it.

2026-02-14 22:16:09 UTC

- reply

interesting! I'll keep this in mind. I agree we could offer something better than just Github issues and direct emails.

2026-02-10 23:42:26 UTC

- reply

Speaking of Podverse Nextgen bug reports, we now have ONE place for everyone to report bugs to.
The entire Podverse infrastructure (almost) is within this one Github monorepo. If you notice a bug or have a feature request, all are welcome to create issues here:
https://github.com/podverse/podverse/issues

2026-02-10 23:39:24 UTC

- reply

Podverse legacy also did not have web support for Add by RSS feeds at all. They were a mobile feature only, and an incomplete feature, at that.
With Podverse nextgen, you should be able to add your private RSS feeds on web, and have them available in mobile, and vice versa.
For many reasons, this has been the most complex feature to support in Podverse Nextgen yet...there are many different situations to test for, and we will likely have to iron out bugs as people report them to us.

2026-02-10 23:36:12 UTC

Podverse Alpha Update 🛠️
NEW: Add By RSS feeds on PV web 🎉
"Add by RSS" are feeds that are NOT in the Podcast Index, and are not supposed to be.
For example, private, premium content feeds that you get a link to when supporting a creator on Patreon.
Podverse legacy supported these feeds in the mobile app, but it did not let you add content from those feeds to your queue or playlists.
Podverse nextgen does support Add by RSS queue and playlist functionality. (cont.)
https://alpha.podverse.fm/add-by-rss/add
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/048/956/453/428/312/original/24e4450f358a892e.png

2026-02-06 18:04:05 UTC

- reply

hah I have not thought that far ahead yet...
But as long as the data can map to the same schema we end up with from parsing RSS, I imagine there's no reason we can't support AP or any other data format.
I do however lean towards RSS being a good enough data standard for podcasts/music/etc. What does AP offer in this context that RSS does not?

2026-02-06 17:50:27 UTC

This is a test thread for <podcast:socialInteract> tag testing.
(I need an activity pub post url for us with test RSS feeds.)

2026-02-06 17:11:06 UTC

- reply

that makes sense. However since the feed URL can change at a later time, I believe from the v5 requirement is not actually required any more.
I'll just add validation that it is any uuid (36 chars, 8-4-4-4-12).

2026-02-06 16:22:41 UTC

- reply

LLM suggests v1, v2, v4, and v5.
v3 apparently is deprecated.
v6, v7 seem reasonable.
v8 is "custom" which maybe we don't want.

2026-02-06 16:18:48 UTC

@npub1rcn…dw4h @npub1j0h…u952 @npub1yda…h4tz I think we discussed this before, but wanted to confirm.
The PI docs said a podcast:guid should be v5, but you also said that shouldn't be a strict requirement.
I'd like to implement at least some validation on that column in our database. Do you think v4 and v5 would be enough? Or just validate that it follows any of the uuid schemas? (apparently there are 8 versions)

2026-01-29 22:38:00 UTC

- reply

that’d be great! Let me know if there’s a good day/time to chat.

2026-01-29 20:23:48 UTC

Podverse Alpha update 🛠️
We are nearly ready to implement V4V in Podverse Alpha web...and I am completely out-of-date in terms of what the current practices are.
Can anyone direct me to resources I should follow for a web-based Bitcoin V4V implementation? Is the standard still keysend? Are there multiple types of implementations we should support by now?
#podverse #pv2

2026-01-28 00:24:43 UTC

- reply

I have not even heard of it yet. Oh man...I have written so many skills already (well, telling LLM to write them mostly) forming a framework for the new monorepo. My impression is this may nullify or conflict with a lot of them. If it's a game-changer and the clear standards leader though, I wouldn't want to be left behind.
Also, I'm hoping to not stay confined to Claude / non-open source models. Can the plugin work with any model? I imagine it's just skills files?

2026-01-27 21:03:18 UTC

- reply

...then after Sonnet 4.5 seems happy with everything, I switch to Opus 4.5 to review the plans that Sonnet 4.5 created. When I do this, Opus 4.5 often finds gaps or issues that Sonnet 4.5 did not.
Once Opus 4.5 is happy with the plans, and I'm happy with the plans, I switch back to Sonnet 4.5 to run them (in parallel, when possible).
So far, the process seems to work well and save me a lot of money on API credit usage.

2026-01-27 21:00:42 UTC

LLM programming lesson learned...I have been using Opus 4.5 for large, complex tasks where I want the highest quality model available for the work, but Sonnet 4.5 (also by Anthropic) is also very good, and costs ~67% less $ than Opus 4.5 to use.
My latest approach is, when working on a large and complex task, have Sonnet 4.5 plan all the work upfront, and split the work into many plan files, and save them locally (target under 300 lines per plan, to keep them reasonably sized), then...

2026-01-23 21:30:47 UTC

- reply

but I'm also thinking it may be easier for open source contributors to create PRs for Podverse if they can just create 1 PR per feature. Right now, a typical feature update will require changes to multiple repos. It's a clean process imo, but it does add significant overhead to PR creation and reviews.
Anyone have experience and opinions on monorepos? Worth the switch in our case, or could it create more problems than it is worth?

2026-01-23 21:28:29 UTC

As the Podverse infrastructure has grown to 10+ repos, and given how LLM seems to perform better with all its context in one place, and it would be easier to save llm prompt history in one place...I'm wondering if we should make a major switch to a monorepo 😣
I've never done a monorepo before. If it were just LLM, then we may not need it (we could create yet another repo...podverse-llm or something) (cont)

2026-01-23 04:58:26 UTC

- reply

I still haven't tried Claude Code. Curious to hear how it goes.
My workflow has been Cursor using Auto mode ~95% of the time, and then for big or difficult tasks, I switch it to Opus 4.5, and in the rare case that doesn't work, I switch it to
I think I literally got 2 weeks of tedious refactoring, validation scripts, and documentation done today over 8 hours. Plus a feature on the website that I've been wondering how to do cleanly for like a decade (cont)

2026-01-14 16:45:02 UTC

- reply

it is! Web only though. I would say it’s about 80% finished.
I’m hoping that leaning into LLMs will help me finish the mobile app faster than I expected…we can’t fully release nextgen PV until mobile is finished since we need a major data migration. Trying to make the website and infrastructure a standalone open source project before then tho.
https://alpha.podverse.fm

2026-01-14 14:43:53 UTC

- reply

the new Podverse we are working on has alternate enclosure support built-in from the ground up. We will try to provide the best alternate enclosure functionality we can for your feeds.

2026-01-14 09:17:50 UTC

I’m finding trying to keep up with LLM advances for coding pretty disorienting…on one hand there are some real and magnificent breakthroughs, and on the other there is a lot of useless slop masquerading as breakthroughs.
Improved LLM models are already accelerating my productivity by several times, but I’m still seeing enough errors and anti-patterns, that I have a hard time believing the “you can do it all with prompts” and “you don’t need to review every line” camp isn’t being naive.

2026-01-12 05:45:53 UTC

- reply

awesome. Thank you!

2026-01-10 23:53:22 UTC

- reply

do you use a full CLI approach? I haven’t made that leap yet, and with how I’m using LLMs at least, it doesn’t seem like they’ve eliminated the need for manual edits in all cases.

2026-01-10 06:29:02 UTC

- reply

and yeah cost is a big concern. You can set budget limits with the LLM APIs though to prevent surprise overspending. Planning the prompts and trying to write the most efficient way to get the work done is important when cost is a constraint.
So far GLM 4.7 seems pretty good. Not Opus level but reasonably close, and 10% the cost is a huge selling point. Only been messing with it for a couple hours but I'm happy with it so far.

2026-01-10 06:23:53 UTC

- reply

yeah, and it's important to be cautious. I still reviewed all the code, and there were some issues with it, and some choices it made that were not my preference...but even after the manual changes I needed to make, it saved me so much time, it's crazy.

2026-01-10 04:41:10 UTC

- reply

The cost of using Opus 4.5 is substantial. A long 12 hour day of work cost me almost $50 in Anthropic API credits.
Since we haven't turned a profit yet with Podverse, that comes out of my pocket and is not easy to sustain, but the time and energy savings make it worth it.
I'm currently trying to replace Opus 4.5 in my setup with GLM 4.7, which is the highest rated open source / MIT LLM for coding available today. API credits are 10% the cost of Anthropic's, so hopefully it will be good enough.

2026-01-10 04:36:51 UTC

I don't know if there is anyone left who is skeptical...but the LLM updates over the past couple months for programming are a giant leap forward, and it seems like we've crossed an inflection point for the industry.
Using Opus 4.5, I was able to get what would have been 5 days of work for me finished in 1 day.
One stage of my work included writing 8 paragraphs of instructions for Opus, and it wrote hundreds of lines of code across 7 repos, and was ~99% accurate and finished after a few minutes

2026-01-10 04:28:49 UTC

- reply

I don't see an artist RSS feed for Hartlight in Podcast Index:
https://podcastindex.org/search?q=hartlight&type=all
Our search directly queries PI API, so if a feed is not discoverable there, it won't be discoverable in PV.
I see that the album feed has a publisher tag that is pointing to the artist feed, which is great, but we have as a requirement that only feed that are in PI can be added to our database.
Does Fountain typically add artist feeds to PI? Or does PI not seek to include them?

2026-01-09 04:48:24 UTC

- reply

yikes 😬
I guess there must have been an error that caused it to abort the parses instantly and bombard you with requests.
Maybe I'll add I short timeout at the beginning of parse operations to make sure you don't get spammed that badly if something goes wrong.

2026-01-09 00:31:29 UTC

- reply

the user agent should be:
Podverse/Alpha/2/Worker
Maybe there was a high volume of requests. I had "recursively parse remote items" enabled in our parser, which not only parses one feed, but also parses the remote items from that feed.
I could add some form of rate limiting to our parser to not barrage PI too quickly.

2026-01-08 21:51:09 UTC

- reply

after an hour, it appears that the Cloudflare restriction was lifted.
However, we could really use some way to ensure we don't get blocked by Cloudflare. I would think a valid PI API key should be enough, but I guess the Cloudflare protection must preclude API key validation. Any ideas would be appreciated.

2026-01-08 21:23:57 UTC

@npub1rcn…dw4h @npub1hta…eg8a how can we avoid Cloudflare breaking our connection to PI API?
I was able to make 3 successful requests to PI API from Alpha server, and I didn't change or redeploy anything...and since then, my 4 attempts to make a request to PI API have failed. The error message is 429, and it is an HTML respnse that includes:
Access denied | api.podcastindex.org used Cloudflare to restrict access
cc @npub1yda…h4tz

2026-01-02 06:28:54 UTC

Podverse Alpha Web update 🛠️
Added the Artists and Artist page.
This is our first implementation of Podcasting 2.0 "publisher" feeds.
A "publisher" feed is an RSS feed that contains references to other RSS feeds.
In general, individual Music RSS feeds represent an Album or Track of music.
Publisher feeds allow artists to group all of their Album RSS feeds under their artist name.
https://alpha.podverse.fm/artists
https://alpha.podverse.fm/artist/FTTwdF9Ral
#podverse #pv2
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/824/074/377/301/317/original/a939c77565c13003.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/824/083/956/723/904/original/8b46dd9f8275b4e6.png

2026-01-01 01:43:54 UTC

- reply

nice! I’ll use it for deving

2025-12-31 22:53:58 UTC

- reply

I figured you’d already have a solution lol.
This would be perfect for our purposes. It provides a way for apps to display *lists* of publisher feeds grouped by medium type.
@npub1gfn…mk8j @npub1rcn…dw4h any thoughts on this? (I don’t know who else is creating publisher feeds to @)

2025-12-31 22:44:26 UTC

- reply

do you have any thoughts on this use case?
We'd like to be able to differentiate between Music Publishers and Podcast Publishers within the PV2 UX. I'm not seeing a way to differentiate without our own duck typing at this point.

2025-12-31 21:11:41 UTC

- reply

For now, I'll proceed as if every publisher feed is a "Music Publisher", but that won't hold up for "Podcast Publisher" feeds.
I imagine grouping Music Publisher feeds as "Artists", and Podcast Publisher feeds as "Networks", but it would be nice if the feed indicated which group to put it in.
It may be good enough to simply count the medium attrs of the remoteItems in a publisher feed, music or podcast, & chose whatever has more, but if those attrs are missing, we have nothing to base that on.

2025-12-31 21:03:52 UTC

- reply

created this endpoint that displays publisher feeds hosted on RSS Blue.
https://publishers.rssblue.com/api/all
I see that he included medium="music" attributes on the remoteItems, which we could could use in Podverse to "duck type" a publisher feed and mark it as a "Music Publisher" for our purposes, and load those feeds on our Artists page.
That's a fuzzy approach however, and publishers can combine music and podcast data into the same feed. Is there a better way for us to identify "artist" feeds?

2025-12-31 20:58:35 UTC

Podcasting 2.0 question:
We're starting to work on "publisher" feed integration with Podverse Alpha Web.
Publisher feed allow you to reference many RSS feeds, grouping them together.
Since music RSS feeds tend to represent an Album, EP, or a Single, publisher feeds allow you to group those feeds together under an Artist.
My question is, how do we differentiate music/artist publisher feeds, from other types of publisher (ex. podcast publisher) feeds? Is there a recommended approach?
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/816/168/382/437/250/original/acc736d8713b1b41.png

2025-12-29 06:14:23 UTC

Podverse has started maintaining a fork of the Partytime RSS Feed parser library.
Partytime is a comprehensive Node.js RSS podcast feed parser, with support for all Podcasting 2.0 namespaces.
Thank you to @npub1kk8…ht7k and @npub1rcn…dw4h for creating the library! The code is easy to work with, and the unit tests are appreciated 😄
https://github.com/podverse/podverse-partytime
#podverse #pv2

2025-12-27 00:17:34 UTC

- reply

we should be able to integrate with the Rust parser outputs. I think we may want a layer of Typescript types to go with the output. That’s just a data mapping exercise tho, and not strictly necessary.

2025-12-26 18:38:16 UTC

- reply

but also...partytime just seems really stable for our purposes, so I'm not sure if it is worth it for us to break from our full-stack JS pattern to incorporate feedparser/Rust. Also partytime uses Typescript types which is good for our builds and workflow.
Anyway, if no one else is eager to maintain partytime, I think I will fork it tomorrow, make the changes needed, and maybe longer term start a migration to feedparser. I see you made some PRs that are not merged and I can take a look.

2025-12-26 18:35:06 UTC

- reply

I have seen it. I'm open to using it at some point, but podcast-partytime works well with our full-stack JavaScript infrastructure.
I'm thinking it would take me a day of work to add the missing pieces we need to podcast-partytime, but switching to feedparser which is written in Rust would be a bigger initiative.
partytime logic is only used in podverse-parser/src/lib/compat and podverse-parser/src/lib/rss, so swapping it out doesn't seem crazy difficult
https://github.com/podverse/podverse-parser/blob/v5-develop/src/lib/rss/channel/channel.ts

2025-12-26 17:36:24 UTC

- reply

So I'm wondering, Ryan would you like to continue maintaining Partytime, or should we move forward with a fork?
And if we do fork it, does anyone else want to be the maintainer?
I can bring it under the Podverse org umbrella, and I don't think it would be overwhelming bc Partytime seems to do 99% of what it needs to already, but if someone else would like to be the maintainer, we'd certainly appreciate it.

2025-12-26 17:32:38 UTC

The Podcast Partytime JS library that @npub1kk8…ht7k made has been working great for us, but it needs a few (I think light-weight) updates to get us past some blocking limitations.
One of the issues is that Partytime doesn't parse the "list" medium types, which is an issue for list feeds that people like @npub1e88…nva7 make.
https://github.com/RyanHirsch/partytime/issues/61
Ryan has done amazing work but I'm not sure if he is still able to maintain it.
https://github.com/RyanHirsch/partytime/issues
cc @npub137c…y0lh @npub1hta…eg8a @npub1yda…h4tz @npub1rcn…dw4h @npub1fmx…wp74

2025-12-22 07:51:23 UTC

Podverse Alpha Web update 🛠️
Added the Music Livestreams and Music Livestream pages.
Also added the Repeat and Shuffle buttons to the player.
Reduced some font/image sizes a bit, and applied some fixes for mobile layouts.
Coming soon: auto-play next behavior for Playlists, remember last repeat/shuffle setting on page load, and Artist pages.
https://alpha.podverse.fm
#podverse #pv2
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/762/039/006/463/669/original/c18b85e53f678d94.png

2025-12-18 17:29:04 UTC

- reply

no pressure but I noticed before the PI search endpoint apparently lets you filter by music but not by video.
It’s not critical but if PI search ever supports filtering by any medium, we could add radio buttons below the search bar so people could refine their search.
If it takes a lot of work, it’s not worth it, but if it’s trivial to add, could be nice.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/741/745/889/288/115/original/f738f22eff951e79.png

2025-12-18 16:59:48 UTC

- reply

How about fighting LLM with LLM? Adding an LLM service layer all feeds must pass through before they are added to PI directory? The service flags suspicious feeds and saves references to them in a separate table.
Feeds marked as spam incorrectly would still need to be corrected somehow…maybe via a privileged endpoint RSS hosting companies support teams can interact with, and/or crowdsourced maintenance by trusted community members.

2025-12-17 18:31:39 UTC

🛠️ Podverse Alpha Update 🛠️
IT'S A BIG ONE
Started to add the Albums, Album, Tracks, and Track pages for Music playback.
The UX also splits the Queue, History, and Playlist into Podcasts and Music.
Any feedback or suggestions for improvement would be appreciated!
https://alpha.podverse.fm
#podverse #pv2
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/736/331/378/281/651/original/2e21b660fcb53be1.mp4

2025-12-17 06:37:29 UTC

- reply

i18n (internationalization) is fairly straight forward. It is basically maintaining a JSON (or any text file type) file with the root language, and then mapping those keys to different values in different language files.
We have Podverse Alpha setup with en.json as the root lang, and then we feed that file thru LLM to have it automatically generate es.json, fr.json, etc. based on the root file
We also have override files to fix weird LLM translations as needed.

2025-12-17 06:28:30 UTC

- reply

private post lol
I agree content in <podcast:tags> should be open ended, but I do think we'll need to offer some guidance to RSS feed generators to standardize genre names, or else we'll run into translation gaps like Electronica and Elektronische Musik.
We *could* make the apps do all of that language mapping, but...there's a lot of languages to map.

2025-12-17 06:14:09 UTC

- reply

well, I'm not trying to stymie anything 😆 I'd just like to understand the reasoning.
I think music medium + tags is enough to have a functional genre system. Every "genre" makes sense as a tag, even if every tag is not a genre.
If it's decided that more context is needed, we can just extend the spec in the future.

2025-12-17 05:50:58 UTC

- reply

I'm sure we can find some 😄

2025-12-17 05:50:09 UTC

- reply

hmm one thought I have is, how could we handle different languages if tags is used for genres?
I guess Apple just decided on making English translations the standard with <itunes:category>. It's a linguistic bias, but should be fairly trivial for RSS feed generators to map their "genre" tag inputs to the English version.
We'll run into issues like Rock, vs Rock and Roll, vs Rock & Roll, but again maybe RSS generators can reach a consensus.

2025-12-17 05:35:14 UTC

- reply

if tags is a good fit, i'll use them.

2025-12-17 01:25:14 UTC

- reply

ok. I'm probably going to hold off on adding "genre" support for now...

2025-12-17 01:13:20 UTC

- reply

> Wavlake adopted the category tag, implemented wrongly, but whatever, it works.
What did they handle incorrectly? I see this example from The Underclass:
<podcast:category text="Rock">
<podcast:category text="British Invasion"/>
</podcast:category>
is that incorrect?
https://wavlake.com/feed/music/fa16edd9-d3d2-4c6f-a6e1-c9d43307a0bf

2025-12-17 01:04:47 UTC

@npub1e88…nva7 @npub1unc…6rz6 i've asked this before but forget 🤦‍♂️
is there something comparable to "categories" or "genres" in use for P2.0 music feeds?

2025-12-16 22:52:29 UTC

- reply

Yeah, I don't think there is a "right" answer for fallback track order handling...the season + episode tags are the only way to unambiguously tell apps what the intended track order should be.
If SF is missing some season + episode tags in a music feed, maybe an "update track order" button could help normalize / fill the in the missing track numbers? Not to put work on your plate @npub18a6…pny4 😬 something for down the road possibly.

2025-12-16 21:18:48 UTC

- reply

this is good to know. thanks!

2025-12-15 21:01:51 UTC

- reply

Thank you to @npub1ncy…zkql and the Doerfels for this complex feed test case 😂
Some items in the feed have a season and episode number, and some do not.
I'd recommend continuing to add them going forward for apps to handle auto-play ordering like you expect, but if not, apps can use fallbacks similar to what we have.
https://www.doerfelverse.com/feeds/music-from-the-doerfelverse.xml

2025-12-15 20:58:11 UTC

- reply

That isn't very complex, but things get complicated when a music feed contains tracks that have an "episode number", and tracks that do not have an "episode number". Where do the non-numbered tracks go in the auto play order?
To handle this, I (::cough:: llm) wrote the query to handle all tracks in a music feed that do not have an episode number as if it had a season of -1, and to sort those by pub_date, while the sort for properly numbered tracks get handled as normal.
https://github.com/podverse/podverse-orm/commit/3470108ab6c81de9dac9a1f0a7c9fd6bbc810ffa#diff-c3343c792900d109ee2695d00313b8b2e68844b2d088a3271b7527b4c88d459eR384

2025-12-15 20:54:51 UTC

Podverse Alpha update
Started to add Music player support.
One of the key differences between Podcast and Music in a Podcasting 2.0 app is how the "auto play next from queue" is handled.
For a podcast, you would typically autoplay the next episode, sorted by its pubDate.
For a music album, you need to play sorted by a track number. The convention used is the season and "episode" tags. Instead of sorting by pubDate, tracks are sorted by the "episode number"...

2025-12-10 06:16:12 UTC

⚠️ Podverse Alpha Update ⚠️
I'm shutting off the Alpha website for the night, as there is a critical security vulnerability with the version of Next.js it is using (CVE-2025-55182).
Should have it redeployed and patched tomorrow.
Good video explaining the CVE: https://www.youtube.com/watch?v=s81dVUM-cQM
Thanks to @npub1yda…h4tz or notifying me.
#podverse #pv2

2025-12-04 18:38:37 UTC

The Podverse Alpha website is now live!
This is a work-in-progress, public demo of the upcoming Podverse "2.0".
The new Podverse is designed, from the ground up, to support as many Podcasting 2.0 features as possible.
Functionality is limited right now, but the core is there.
The test website can be found at https://alpha.podverse.fm
For more info, please read https://alpha.podverse.fm/updates We will be continuously posting updates there.
We would greatly appreciate help with testing and feedback.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/662/741/977/015/912/original/026483f52fc2c99c.png

2025-12-01 20:08:01 UTC

Update on Podverse 2.0...first version of the Alpha website should be publicly accessible this week.
Technically could be shared now...but ironing out some things and finishing some pages before that.

2025-11-26 07:07:19 UTC

Podverse 2.0 Preview:
Added the Home and Episodes page.
Next I'll be adding the Clips, Livestreams, Videos, and Music pages. It should be fairly simple with the new endpoints and UI components in place.
The PV2 Alpha website should be publicly accessible for testing before the end of this month.
cc @npub1yda…h4tz who handles the ops and more for Podverse, and I couldn't do any of this without him.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/614/706/982/373/391/original/36cc38baac4947b7.png

2025-11-22 04:34:03 UTC

Grid view preview for Podverse 2.0
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/591/480/283/168/666/original/74c55c8ebd129df9.png

2025-11-19 18:59:11 UTC

@npub1fmx…wp74 @npub1kga…9vap just fyi, it appears the chapters URL is not working for NA episode 1817:
Error: Unsupported /chapters/ url(original-json-chapters-url returned invalid chapters)
https://reflex.livewire.io/chapters/podcast/856cd618-7f34-57ea-9b84-3600f1f65e7f/item/http://1817.noagendanotes.com/chapters/https://chapters.hypercatcher.com/http:feed.nashownotes.comrss.xml/http:1817.noagendanotes.com
episode 1816 however does work:
https://reflex.livewire.io/chapters/podcast/856cd618-7f34-57ea-9b84-3600f1f65e7f/item/http://1816.noagendanotes.com/chapters/https://chapters.hypercatcher.com/http:feed.nashownotes.comrss.xml/http:1816.noagendanotes.com

2025-11-16 19:12:34 UTC

It's LONG overdo, but I think the Podverse 2.0 website will finally be available in beta before the end of this month.
The goal of Podverse 2.0 is to support as many Podcasting 2.0 features as possible, from the ground up. Emphasis is placed on multiple medium experiences (podcast, video, music), alternate enclosures, and livestreams.
Other goals include a focus on optimizing app performance, simplifying code, and closing feature gaps between web and mobile (web will support custom RSS feeds).
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/560/788/224/496/906/original/10f65aacb202e768.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/560/804/720/898/793/original/9133aff6cb7106f2.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/115/560/806/157/928/740/original/10cb17c3173718e0.png

2025-11-16 18:20:57 UTC

- reply

thanks for the info. For audio only livestreams, fortunately there is the 24/7 No Agenda radio stream.
Something the No Agenda stream doesn't provide afaik though is multiple enclosure types. Anyway I'm finally setting up test feeds to test complex alt enclosure setups.

2025-11-12 00:38:51 UTC

Does anyone know of a 24/7 podcasting 2.0 compatible video livestream, I could use for dev purposes?
Adding video livestream support to Podverse 2.0. I'll have to learn how to setup my own livestreams on localhost sooner than later, but wondering if there's already a video live feed people know of.

2025-07-24 05:11:15 UTC

Some notable omissions in Time’s “Top 100 Podcasts of All Time” 😂
https://time.com/collections/100-best-podcasts/?utm_source=twitter&utm_medium=social&utm_campaign=editorial&utm_term=entertainment_podcasts&linkId=844303163

2025-07-15 23:05:31 UTC

- reply

that makes sense to me.
I was mainly wondering if PI automatically adds the Publisher feed if it finds a Publisher feed tag within a Music Track/Album feed.
If yes, then there shouldn't be an issue with Podverse requiring a PI feed ID for all feeds in our database.
If no, then we may need to remove that requirement, but for now, I'll see how it goes while keeping the requirement.

2025-07-15 22:11:19 UTC

- reply

is it a guarantee that both the music track's RSS feed, and the publisher feed will be parsed and assigned a Podcast Index ID in Podcast Index?
The publisher feed in the above example (Wavlake) I do not think is in Podcast Index, although I see an RSS Blue publisher feed.
https://podcastindex.org/podcast/6907064
If publisher feeds aren't always in Podcast Index, I'll need to redesign this schema so that we only require a Podcast Index ID for each feed if it is NOT a publisher feed.

2025-07-15 22:07:49 UTC

- reply

it looks like for group RSS feeds by music artists, we need a publisher feed with:
<podcast:medium>publisher</podcast:medium>
<podcast:remoteItem medium="music" ... />
example: https://wavlake.com/feed/artist/3dac722c-4375-458c-80f6-3b4040574ee7
and within the remote feeds, it should cross reference the publisher feed with a remote item:
<podcast:remoteItem medium="publisher" ...>
https://wavlake.com/feed/music/e5c8aedd-13a1-449c-aaa8-13cfbfbbac97
At the moment, Podverse 2.0 will only add RSS feeds to our directory if that RSS feed is in Podcast Index, but...

2025-07-15 21:26:01 UTC

Podcasting 2.0 question:
How are people handling grouping music RSS feeds by artist? Is that a use case for the publisher tag?
Are there any examples in the wild, or RSS feed companies that support this?
Finally making progress on the new Podverse 2.0 website, and it'd be nice to be able to group music feeds by artist.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/859/351/808/523/802/original/4e8ae850ae78436e.png

2025-07-03 02:37:02 UTC

- reply

also...i attempted to run our feed parser on your feed url locally, and it worked successfully...but the same code on our server is failing. It makes me think some caching by your server *might* be interfering with our server getting the latest up to date version.
our server parser logic hasn't updated for over a year, so i'm kind of hoping it is a caching issue, as that might resolve itself within a day when cache is reset.
sorry if i'm talking too technical 😅

2025-07-03 02:33:26 UTC

- reply

ok I'm still kinda scratching my head about what is going wrong...
the html output our server's parser is receiving looks like this attachment.
do you know what html that corresponds with?
it does not seem to correspond with the html i see at https://serve.podhome.fm/rss/cc53d03a-3e90-5285-a256-3cb641ab9ae0
do you know if it is possible that our server is receiving a cached version of https://m2h2music.com/podcast.xml or https://serve.podhome.fm/rss/cc53d03a-3e90-5285-a256-3cb641ab9ae0 from your server, instead of the current version?
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/786/953/679/574/349/original/14422d56e8645b72.png

2025-07-03 02:19:50 UTC

- reply

the one you just linked appears to be for "Shooting It Straight". is that the wrong feed?
but regardless, it does seem like podcast partytime is not handling this redirect as expected. i see in the logs HTML page data rather than an expected RSS format.
the parsers usually handle redirects successfully, so i wonder what is different about this case where it is failing...still investigating

2025-07-03 02:15:11 UTC

- reply

ok hmm, there it appears that partytime (the library we use for RSS parsing) does not like something in the new RSS format:
***** PODCAST PARSING FAILED *****
podcast.title Mountain Music Happy Hour
podcast.id za6VaYBlvf
feedUrl.id r6iBxGIoB
feedUrl.url https://m2h2music.com/podcast.xml
parseFeedUrl invalid partytime parser response
i'm still looking into it, trying to identify what exactly it doesn't like...

2025-07-03 02:00:54 UTC

- reply

hi @npub1hvx…cwd3 our podcast directory only detects updates when Podcast Index does, and when I search the Podcast Index, I am not seeing Mountain Music Happy Hour in it.
I'm searching for Mountain Music here but don't see it https://podcastindex.org/search?q=mountain%20music&type=all
I'll look into it more now...