Alex (Podcast Guru)

https://podcastindex.social/@algrid

Public Key

npub10lzhk0n62my24p0u0zqw489j4lgkxxlzpwqs0xzazjxqj54t6y3s0jtuwr

NIP-05 Address

[email protected]

Profile Code

nprofile1qqs8l3tm8ea9dj92sh783q82nje2l5trr03qhqg8npw3frqf224azgcprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntxwxz75

Publishing to

relay.momostr.pink

Author Public Key

npub10lzhk0n62my24p0u0zqw489j4lgkxxlzpwqs0xzazjxqj54t6y3s0jtuwr

Show more details

Last Notes

2026-02-09 16:02:40 UTC

- reply

we'll keep our own format for now, but we'll see in the future, I'm not excluding anything.. :)

2026-02-02 13:13:15 UTC

- reply

yes, I guess we should be able to enable CORS there, thanks for the reminder. And we'll see what we can do about the data format. Not sure about completely changing it to the Fountain spec, but we can try to include a hint into the bolt11 description to distinguish boost vs stream payments. Like V4VB:... or V4VS:... prefix depending on the case or something like that.

2026-01-31 22:20:07 UTC

- reply

yes, in our case the information is inside the json that you can fetch by accessing the url following V4V. The description field can be too short to put actual data there, that’s why we only put a url there.

2026-01-31 19:23:54 UTC

- reply

If I recall correctly we have a boost vs stream flag in our metadata (basically it’s the same metadata that’s going with keysend payments). If that helps..

2025-12-06 12:34:16 UTC

- reply

No problem, thank you!

2025-12-05 20:04:59 UTC

@npub1rcn…dw4h @npub1fmx…wp74 Is there a reason why you keep alternateEnclosure with an inactive HLS stream for Podcasting 2.0 liveItems? We're preparing a new version of Podcast Guru that automatically picks up and uses alternateEnclosure if it's present and it's an HLS stream. As a result our beta version now plays a short "This stream is offline" video instead of proper live stream. I wonder if we should address that somehow or it's just a mistake in the RSS feed...

2025-10-31 18:15:52 UTC

- reply

No HLS/video today?

2025-10-22 16:09:28 UTC

- reply

also type="application.x-mpegURL" should probably be type="application/x-mpegURL". It's correct in one place, but for other alternateEnclosure tags it's with "." instead of "/".

2025-10-22 13:32:46 UTC

Podcasting 2.0 Episode 238 has an alternateEnclosure tag that points to https://hls.podcastindex.org/pc20_236.m3u8 which is for Episode 236 as far as I can tell. It that a mistake or I'm missing something? @npub1rcn…dw4h

2025-10-02 14:24:14 UTC

- reply

I'm looking at YouTube feeds which are in Atom format, but their "application/x-shockwave-flash" media type makes them basically useless for any podcast player, unless that podcast player simply loads a web view with YouTube web player.

2025-10-02 14:21:27 UTC

Are there any podcasts still using/having Atom feeds? Or pretty much everyone is on RSS 2.0 now?

2025-09-20 14:55:18 UTC

- reply

we do support HLS for a long time already. But we don’t support alt enclosure. It requires adding the choice which URL to play/download into the UI. Or we have to decide that automatically… Kind of complicates the UX and app’s logic.

2025-07-09 13:45:04 UTC

- reply

It used to be a simple text/link. Did it evolve into something bigger/more specialised?

2025-05-29 10:14:20 UTC

- reply

It's a small json file. /options wasn't really widely accepted, so the idea is to use /keysend now for exactly the same purpose. Here's an example: https://getalby.com/.well-known/keysend/alexrba

2025-05-28 14:01:06 UTC

- reply

If you have a keysend address in something like https://getalby.com/.well-known/keysend/username then podcast players can detect that and prioritise keysend over bolt11. At least that's what we are doing in Podcast Guru (technically we're looking at the "/options" URL instead of "/keysend", but we'll change that soon).

2025-05-27 17:45:27 UTC

- reply

yes, I know about the "/keysend", but I was under the impression that "/options" used to work. We're still using it, though switching to "/keysend" is in our immediate plans.

2025-05-27 17:39:48 UTC

Was the "options" query support already removed by Alby? I mean https://getalby.com/.well-known/lnurlp/username/options

2025-05-13 17:41:44 UTC

- reply

Oh, I didn't know that, thanks! I may need to change my code too then.

2025-05-13 17:38:12 UTC

- reply

I'm doing a similar thing (only trying the "options" request instead of "/keysend" if I recall correctly). But in this case I'm testing integration with Strike which only supports bolt11.

2025-05-13 17:25:36 UTC

At least Podcasting 2.0 has a couple of "lnaddress" recipients. 🙃 Are there any other podcasts with V4V recipients using "lnaddress"?
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/501/688/731/881/834/original/ec6434303d6caea7.png

2025-05-13 10:00:07 UTC

I'm wondering what's limiting the lnaddress adoption for V4V currently? Are the podcasters unwilling to switch to it because podcast players may not support it or are there any other problems?

2025-05-09 10:58:07 UTC

- reply

Works in Podcast Guru
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/477/516/213/379/597/original/f25c7143376cb7fe.png

2025-04-15 12:20:03 UTC

- reply

We do support it in Podcast Guru.

2025-04-08 16:56:21 UTC

- reply

sorry to bother you again with it, did you have a chance to take a look at that request?

2025-03-31 10:48:31 UTC

- reply

Sure, sent to the "info" email. 😀

2025-03-28 17:24:26 UTC

- reply

btw, does that batch endpoint have a limit number of requested podcasts? I'm hitting it with 238 of ids right now and get only 26 podcasts in return 🙂

2025-03-28 16:44:23 UTC

- reply

non-unique "guids" are real PITA 😖

2025-03-28 16:42:13 UTC

- reply

getting some duplicates with the same guids like this one:
guid=66162162-76b3-54c2-b519-096ccd887a6f, feedUrl=https://music.behindthesch3m3s.com/wp-content/uploads/Empath Eyes/East To West/east to west.xml
guid=66162162-76b3-54c2-b519-096ccd887a6f, feedUrl=https://music.behindthesch3m3s.com/wp-content/uploads/Empath%20Eyes/East%20To%20West/east%20to%20west.xml

2025-03-28 10:29:06 UTC

- reply

I didn't know that you have a guid batch endpoint. Will switch to it instead of individual requests, it's going to be a great improvement!

2025-03-28 10:27:17 UTC

- reply

no, not from PI. We're getting 429 fetching a ton of RSS feeds from wavlake.com.

2025-03-27 19:03:56 UTC

- reply

hah, interesting 🙃

2025-03-26 23:11:50 UTC

- reply

does speak:never work? https://www.w3.org/TR/css-speech-1/#speaking-props-speak

2025-03-26 18:42:19 UTC

Playlists based on remote items when they are big are really hard to handle. When you are trying to "resolve" all the episodes at once you end up downloading 100s of feeds and eventually get hit by HTTP 429 (too many requests). You can "resolve" the episodes dynamically when they are displayed, but this approach has it own limitations. I wonder if it would be better to also include some actual episode info in addition to the feedGuid/itemGuid?

2025-03-16 19:53:41 UTC

- reply

Awesome, thank you!

2025-03-16 19:45:46 UTC

- reply

Thanks! Can confirm that it works on my side now.
Btw, can you share a couple of other such feeds if you know any? I need it for testing.

2025-03-16 19:34:35 UTC

The "Boostagram Ball Playlist 1 to 25" feed contains a wrong podcast namespace: xmlns:podcast="https://github.com/Playlistindex-org/podcast-namespace/blob/main/docs/1.0.md" (it contains "Playlistindex-org" instead of "Podcastindex-org"). Took me some time to figure out why the parsing was breaking 🙃 @npub1rcn…dw4h @npub1unc…6rz6

2025-03-05 15:33:51 UTC

- reply

Could you recommend a couple of RSS feeds with small-ish episodes where we can test it? And maybe a test URL that always returns 429 if you have anything like that?

2025-03-05 15:32:25 UTC

- reply

What we can easily do is probably to show an appropriate message to the user when we hit a 429 (looks like it's going to happen for manually initiated downloads most of the times).

2025-03-05 15:30:02 UTC

- reply

3 requests per minute sounds like a really hard limitation. Users can easily select 3-5 or more episodes and initiate download for them. And if the files are small we can hit the limit really quick.

2025-03-05 11:16:35 UTC

- reply

What is the scope of that 429 response? I mean what is the client is expected to do: to stop requesting that URL? Or any media URL for that podcast? Or any URL from that host?

2025-02-16 17:09:39 UTC

- reply

What we're doing: we use the info from the feed (because we have it cached or fetch it anyway). And if the feed has no value block - only then we make a call to the Index.

2025-02-15 13:40:13 UTC

- reply

hmm, I always considered the feed to be the primary source of truth and the Index is rather a workaround for those who are unable to include the relevant information into the feed.

2025-02-12 19:07:17 UTC

- reply

That's great! 😅 Adding basic V4V info to the "comment" field for bolt11 payments.

2025-02-06 18:28:05 UTC

- reply

Yep, we got a business account there. Just had a meeting with them, hopefully we'll be able to implement OAuth & integrate their API.

2025-02-06 18:24:59 UTC

- reply

oh, I didn't know about .well-known/keysend. In theory it should be the same keysend address as in the options.

2025-02-06 17:49:16 UTC

- reply

I think the original idea with lnurlp options lookup wasn't that bad. The main method of accepting lightning could become bolt11, but those who support keysend could make it resolvable too and apps could dynamically detect that.

2025-02-06 17:45:00 UTC

- reply

We're working on integrating with Strike in addition to Alby, but they don't support keysend. So users with Strike wallets will only be able to send sats to podcasters who support bolt11/lnaddress.

2025-01-22 17:03:53 UTC

- reply

regarding the timing it looks like indeed it started to happen somewhere last week and it is quite rare (though we mostly use the API for search so we don't make a huge number of requests).

2025-01-22 17:02:06 UTC

- reply

I was able to find this really old info on stackoverflow that mentions compression, I have no idea how relevant it is today: https://stackoverflow.com/questions/11458107/nsurlerrordomain-cannot-decode-raw-data

2025-01-22 17:00:10 UTC

- reply

I don't have too much detail on that, I have an error code that the URLSession API returns to me (it's a native iOS app): https://developer.apple.com/documentation/foundation/1508628-url_loading_system_error_codes/nsurlerrorcannotdecoderawdata No further details on why it happens :(

2025-01-21 18:00:58 UTC

- reply

btw, I was unable to find any similar errors on Android, so it can be something iOS client-specific.

2025-01-21 17:59:41 UTC

- reply

I can see occasional "URLSessionTask failed with error: cannot decode raw data" in our iOS logs. Which can be related to compression in theory. It's really rare and I can't reproduce it. Will keep an eye on it though.

2025-01-19 21:30:20 UTC

- reply

Nice, thanks! I will add support for it too. Will put boostagram message there and maybe some other boost info if it fits. I suppose it’s just plain text, no specific format there.. Not much we can do with 200 chars though.

2025-01-19 20:23:40 UTC

- reply

Is it the “comment” field that goes into the invoice generation url?

2025-01-19 16:24:21 UTC

- reply

For keysend payments we send the data as usual, but for bolt11 we send no data at all currently. There's no universally accepted way of doing it. Once the community agrees on something, we'll definitely add it.

2025-01-06 15:57:04 UTC

- reply

hmm, I would expect Steven's version to be the correct one. podcast:valueTimeSplit at the top (channel) level is a bit strange. But maybe I'm missing something, we don't support it yet in Podcast Guru.

2024-12-31 19:57:00 UTC

- reply

not really, what does it do? Is it a similar idea?

2024-12-31 16:32:25 UTC

- reply

This way the user can pay the invoice using any wallet type he likes.
I wonder if any crypto service would be interested to implement that. In theory this could be combined with crypto (or even fiat) echange allowing users to use more payment methods.

2024-12-31 16:32:14 UTC

I'm thinking about some methods that would allow users to use any lightning wallet they like for V4V payments.
One can imagine an API that a hypothetical crypto exchange service could implement: a P2.0 app supplies a list of splits (lightning addresses and corresponding amounts) and get in response a bolt11 invoice for the total sum + some fee. Once the invoice is paid, the service distributes all the splits to their destinations.

2024-12-21 20:38:28 UTC

- reply

But that would be something non-standard, right? Nostr specifies a protocol and it’s always websocket-based? Or there are other standard options?

2024-12-21 11:57:31 UTC

- reply

yeah, afaik no such thing for websockets. But if it’s for comments only, maybe there’s no need for background updates?

2024-12-21 11:51:05 UTC

- reply

yep, it’s exactly as you say, websockets or not. In my experience 30 sec isn’t enough for 50-100 feeds. You need another tricks like inspecting cache headers, using a special iOS API to download files in background etc…

2024-12-21 11:27:12 UTC

- reply

There’s nothing special about websocket connections in background afaik. The app has to be allowed to run in background in the first place. Like if your app plays audio - it’s allowed to execute in background - it can do whatever you like, including websocket connections.

2024-12-18 15:09:54 UTC

- reply

ok, it didn't require a big effort anyway, so not a big deal 😀 Having a simple lnurlp which always means bolt11 makes the logic a bit simpler.

2024-12-18 14:51:27 UTC

So is the lnaddress options file is still a thing or people already decided that it wasn't such a good idea? I just finished implementing that lookup in our Android code 😅

2024-12-16 14:50:59 UTC

- reply

ouch, I don't even know what's that. Some US tax system stuff?

2024-12-15 13:27:10 UTC

- reply

I really like the idea of being able to simply load a json file with comments for a given podcast or episode. What about posting comments though? Is it the old Twitter/youtube/… ways or the idea is to add to that list a simple HTTP API that apps could use (someone would have to implement a backend for that)?

2024-12-12 13:06:08 UTC

- reply

What callback? Do you propose to put the metadata into the comment field of the callback that’s generating a bolt11 invoice? In this case podcasters can include a metaBoost tag with your specific protocol id in their RSS feed to let apps know that this specific approach is supported.

2024-12-12 12:18:49 UTC

- reply

looking at different proposals, I think the podcast:metaBoost tag should be flexible enough to specify the required data for different approaches/protocols. And in the future we will see which approach will win.

2024-12-11 17:28:35 UTC

- reply

btw, do you know any RSS feeds supporting (containing valueReceivers with) lnaddress other than Fountain Radio? I'm in the process of adding support to it to Podcast Guru and would like to test it.

2024-12-11 17:23:06 UTC

- reply

Thank you for the info! I agree that having a unique solution at the end would be quite desirable.

2024-12-11 16:16:26 UTC

Am I correct that we don't have yet a standard way of sending V4V payment metadata when the payment is done via a bolt11 invoice? In the case of keysend we have "custom records" / TLV key 7629169. Nothing like that for bolt11 so far? @npub1rcn…dw4h @npub1cwm…wcs6 @npub1glq…4zwa

2024-12-10 12:41:58 UTC

- reply

does lnaddress necessarily mean bolt11? I thought the options file can specify several options, like both bolt11 and keysend so that the paying side can decide which one it prefers/can use.

2024-12-10 10:50:48 UTC

Regarding the "method" attribute of the podcast:value tag. In the specs it's marked as required. We used to have "keysend" there. Now that people are transitioning to lnaddress - do we omit the "method" at the podcast:value level completely? Fountain Radio feed doesn't have it. @npub1cwm…wcs6 @npub1rcn…dw4h @npub18a6…pny4

2024-12-07 15:44:31 UTC

- reply

is it about extending their API to support lnaddress or about hosting the options file for Alby wallet owners? If that's about API then it's probably not a big deal - apps can resolve the addresses on their side before calling the API.

2024-12-06 14:35:55 UTC

- reply

and one also needs to get a "business account" from them as far as I understand.

2024-12-04 15:49:24 UTC

@npub1cwm…wcs6 thank you for creating an RSS feed (Fountain Radio) that's using type="lnaddress" for value recipients! Is there anyone else who does the same? I'm going to try to add support for it to Podcast Guru.

2024-12-04 15:08:59 UTC

- reply

ok, so as far as I understand, in practical terms if we don't have our own lightning infrastructure, then right now we can concentrate on integrating Strike API and see how it works.

2024-12-04 15:03:40 UTC

- reply

is there a document describing how to do those LNURL requests? I mean is it an HTTP request? How to pass the parameters, what the result looks like etc...

2024-12-04 10:54:30 UTC

- reply

It would be really cool to allow people to use as many different wallets as possible, but all this stuff is rather new to me and I don't quite see how it is technically possible. Will bolt11 invoices help with that? We are not talking about podcast app users having to manually pay for every split as an invoice?

2024-12-04 10:48:49 UTC

Regarding the "Walletpocalypse" that's coming (last P2.0 podcast episode). 😀 Is the idea to have more alternatives to Alby to do V4V payments? Alby has Oauth and a nice API for payments and it was quite easy to integrate. Does Strike (or any other alternatives) have that? @npub1fmx…wp74 @npub1rcn…dw4h @npub1cwm…wcs6

2024-09-23 08:09:57 UTC

- reply

Glad that you were able to figure it out! Indeed, the app needs a valid period of time with non-zero duration to detect it as corresponding to the given VTS.

2024-09-20 10:36:44 UTC

- reply

We don't support it currently in Podcast Guru, so no problem if there are any changes there. In general, I'm not sure if I like to have video support there, but otherwise it's fine.

2024-09-03 16:31:05 UTC

- reply

You know, it's an interesting idea in general. We'll discuss it with Jason @npub1qvx…hseu and see what we can do. 😀

2024-09-03 15:34:34 UTC

- reply

But I'm not sure... One of the reasons we did not add it is that we don't have a 100% guarantee that your sats weren't sent when we have such a "failed" boost. If network fails after we sent a payment request and before we got a response, Alby could execute the payment, but the app will register an error. It's a rare situation, but it can happen.

2024-09-03 15:30:10 UTC

- reply

If it's about the situation when the whole boost is marked as "failed" (like on the picture), then in theory we could add a "Retry" button.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/074/330/020/007/818/original/b62e9508ba7edea5.png

2024-09-03 14:17:25 UTC

- reply

When payments fail for some recipients it's usually because the address is incorrect (probably outdated). Alby API reports failure when we try to send sats to them. Podcasters should update their feeds and indicate correct addresses to solve that.

2024-08-27 14:57:38 UTC

- reply

Thanks! I can see the update for 1552623721. But 1521703224 still returns an incorrect feed URL.

2024-08-27 14:49:55 UTC

@npub1rcn…dw4h Hi! We had been contacted recently by a couple of podcast authors about incorrect/outdated data for their podcasts. The data comes from podcastindex.org API. What's the right way for podcast authors to update their data?

2024-08-07 10:26:51 UTC

- reply

Could you send a bug report from the app? ("Feedback&Help" in the main menu) I will check the logs to make sure that podping notification is delivered. We can also check for HTTP caching: you can make a small change in the feed and I will look at it on my side.

2024-07-16 10:30:09 UTC

- reply

Thanks! Is it the latest episode that goes with <itunes:duration>3644</itunes:duration> (60 minutes 44 sec)? And one more question: when you play that episode, on the player screen is the duration correct there or not? I mean the numbers under seek bar.

2024-07-14 17:19:32 UTC

- reply

No, everything happens on the phone, our backend is not involved here. Could you give me your RSS feed URL? I will try it on my phone.

2024-07-14 16:50:12 UTC

- reply

I just tried your link on my iPhone (from Safari and Telegram) and it successfully opens the app.

2024-07-14 16:49:19 UTC

- reply

Do you have the app installed on your phone? The problem with this kind of links: the browser/OS behaviour can be somewhat inconsistent when they decide how to open the link. For example if you previously tried to open this link by copying and pasting it into Safari address bar, it can decide to open it inside Safari. We can't change this behaviour, it's all about how iOS/Safari/the app you click the link on handles it.

2024-07-14 16:37:01 UTC

- reply

Hi! Are you on Android or iOS? When you play an episode the app may save the "real" audio duration that it gets from the audio player and use that value from that moment.

2024-07-13 15:14:54 UTC

- reply

Usually you just tap the link on your mobile device and the OS handles it: if you have Podcast Guru installed it will be started automatically.

2024-07-13 14:53:48 UTC

- reply

Sorry about that! It's a known limitation of our website. This link will work when opened in the app, but will fail on the website. Technically it's because our site only supports identifying podcasts by their iTunes id and sometimes iTunes id is unknown when you create a share link. We are definitely going to fix this, but it all requires time...

2024-07-13 13:46:55 UTC

- reply

looks good!
https://cdn.masto.host/podcastindexsocial/media_attachments/files/112/779/486/935/680/199/original/e9fd91bf0a1971fc.png