Mitch Downey :pci:

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

⚡️:[email protected]

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

Public Key

npub1p7v0a3mgwgqkhyuuwwrdf7kyt8c0gker3asa4lp0l626p0f3ck5sklqql0

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsqlx87ca58yqttjww88pk5ltz9nu85tv3c7cw6lshla9dqh5cut2gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds9k92m3

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1p7v0a3mgwgqkhyuuwwrdf7kyt8c0gker3asa4lp0l626p0f3ck5sklqql0

Show more details

Last Notes

2024-08-30 22:00:38

- reply

I think I see those 2 same soundbites in two different episodes. The episode named "Culture" has the error. The episode named "Community" does not. Does that help?

2024-08-29 22:19:27

Podcasting 2.0 question:
Is it correct to say that the Value Time Splits cannot be in a <podcast:value> tag that are included in the <channel> level?
I don't think they can but want to double check...
https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#value-time-split

2024-08-11 23:23:14

- reply

yeah, sorry way too much social media…we’re using Matrix because it seems to be favored by open source devs over Discord…but customers prefer to use Discord so I gotta monitor both channels 😓

2024-08-11 22:19:52

Anyone want to help brainstorm for Podverse Next Gen?
The HQ for PV2.0 development is in this Matrix room:
https://matrix.to/#/#podverse-next-gen:matrix.org

2024-08-11 09:05:14

- reply

My guess is that P2.0 feeds are generally supposed to have content grouped by medium type, so channel level makes sense, and <podcast:remoteItem> has medium as a preview of what type of content is in the remote feed.
The "mixed" medium for <podcast:medium> has confused me for a while...but I think it makes sense if "mixed" refers to a feed with only remoteItems, because then a medium would be available on each remoteItem.

2024-08-11 09:01:45

Can individual <item> tags have a <podcast:medium> in a Podcasting 2.0 RSS feed?
It looks like <channel> and <podcast:remoteItem> can have one, but any reason <item> can't as well?

2024-08-10 01:23:02

- reply

we can make it work by identifying a season podcast by looking at its <item> tags, it's just less convenient / requires a little "duck-typing" on our side. Current approach is for us to save a column like "has_seasons=true" to our Channel table for that podcast, so our apps know to handle the podcast with seasons.
Not a big deal but I'm wondering if I'm missing something at the <channel> level of RSS feeds.

2024-08-10 01:17:11

How do apps determine if a podcast should be handled by apps as a "Seasons" podcast feed?
Afaik the only way you can determine this is by detecting <itunes:season> or <podcast:season> within the <item> tags...but wouldn't this be useful information to signal within a <channel> tag?
There is a <channel> level <itunes:type> tag with a possible value of "serial" which usually corresponds with "season" podcasts, but I don't think it's required for seasons.
@npub1fh2…2kq0 I might need a reminder 😬

2024-08-09 20:27:14

- reply

something @npub137c…y0lh mentioned is PI doesn’t provide alternate enclosure data. Is that true? I was thinking of building PV with alt enclosure support from the ground up and regular enclosures as the fallback.

2024-08-09 20:23:22

- reply

thanks that is helpful. I’ll continue in this direction of using extra tables.
If it won’t pose a risk to have read access to PI DB that would be cool.

2024-08-09 20:19:47

- reply

makes sense, thanks!

2024-08-09 06:44:05

- reply

Most of these columns come from the Podcast Namespace RSS spec:
https://github.com/Podcastindex-org/podcast-namespace/blob/ccfb191c98762ba31f98620bd1ba30c1822f6fbd/docs/1.0.md
As for our dead tuples issue, I am thinking our table design may not have much of an impact, and instead we'll need to significantly reduce the frequency of write / delete operations to our tables in nextgen, to keep dead tuples from being created out of control.

2024-08-09 06:42:58

Any database / postgres experts want to help review this sql file?
For Podverse nextgen, we're thinking of splitting data into more tables, rather than trying to stuff ALL of, for example, channel (aka podcast) data in a big channel table.
Is this worthwhile, or does it just bloat the database with more rows across more tables?
We've run into issues with dead tuples in our existing / older podcast parsing infrastructure. Would this design help / hurt / do nothing?
https://github.com/podverse/podverse-ops/blob/v5-develop/docs/database/database-schema.sql

2024-08-09 04:35:50

Trying to figure out how to use the <podcast:person> tag with database relationships...
Since Adam Curry is one person, at first glance it seems like I would want a singular "Adam Curry" person row in a table, and that row gets referenced to many channels and items.
But it doesn't look like <podcast:person> is meant to be used this way, or I imagine it'd have a guid.
I guess we will save person with each channel and item row, and for a "list all by person" feature, we'll need special handling

2024-08-08 21:24:56

@npub1rcn…dw4h is there a way to query Podcast Index API to get a list of only podcasts that have livestreams?
@npub1yda…h4tz and I are trying to reduce dependence on our own parsing system, to avoid overdoing it...but I'm thinking there may be no way around our own parser system to offer full range of features.

2024-08-08 07:20:57

Podverse Next-Gen:
Paired with @npub1yda…h4tz today on NG git practices, the new repo setup, and database schema.
A key difference between current Podverse and next-gen is we'll be trying to lean on Podcast Index API for data as much as possible. This should dramatically reduce the size and complexity of our podcast parsing infrastructure.
We'll still need to support "Add by RSS feed," but those can be handled separately.

2024-08-07 07:59:18

Podverse v5 dev update:
- Created new branches for podverse-ops and api repos. Erased v4 files, initialized new database, and setup a basic express + typeorm app.
https://github.com/podverse/podverse-api/tree/v5-develop
https://github.com/podverse/podverse-ops/tree/v5-develop

2024-08-07 06:20:54

Hey P2.0! Sorry I have been MIA for so long. After working on Podverse evenings and weekends for ~9 years, and never making a paycheck off it, I needed to take some time away, but it's back as my main focus, and I'm working on a totally new version of @npub1wma…5az9.
Everything will be rewritten from scratch, starting with the database and api. I'll be sharing brief updates here to document progress as I go. I hope 2024 is going well for everyone and GO PODCASTING!

2024-06-28 19:46:48

- reply

doesn’t seem to be playing for me. That a me issue or other ppl too?

2024-06-19 06:31:36

- reply

PocketCasts is a great app, and if it works for you then perfect. I do want to say tho that their "open source" license afaik doesn't allow other ppl to deploy instances of their app, and they only share the front-end code of their app, but none of the back-end / data API services.
On the other hand, Podverse's entire tech stack is open source. These are nuances not everyone cares about, but just want to point out that not all "open source" is equal.