Steven Bell :pci: :pc2red:

Bug Reports Here:
https://t.me/+NCqewc8q0eU4NzYx

https://getalby.com/p/steven

Artisanal Coder.

You may know me from such apps as: LNBeats, The Split Kit, Sovereign Feeds, Music Side Project, CurioCaster, &
TranscriptSearchTool

Public Key

npub12qsqnxcdzphcgvlc07f8fwhflx9kvvnzqmv99h83dc2ljnxewyds4wrqfx

NIP-05 Address

StevenB@podcastindex-social.mostr.pub

Profile Code

nprofile1qqs9qgqfnvx3qmuyx0u8lyn5ht5lnzmxxf3qdkzjmncku90efnvhzxcpz4mhxue69uhhyetvv9ujuerfw36x7tnsw43q2p5jkf

Publishing to

relay.ditto.pub

Author Public Key

npub12qsqnxcdzphcgvlc07f8fwhflx9kvvnzqmv99h83dc2ljnxewyds4wrqfx

Show more details

Last Notes

2026-03-27 17:09:45 UTC

- reply

@nprofile…cyex @nprofile…x5pc @nprofile…td70
Can't argue with this.
https://deathbyclawd.com/?url=lnbeats.com
https://cdn.masto.host/podcastindexsocial/media_attachments/files/116/302/240/945/570/345/original/ba66241d2fb9684c.png

2026-03-19 02:50:36 UTC

@nprofile…vfcp @nprofile…zpdn
Are either of you planning on implementing liveValue into your apps? It's an unofficial tag, but CurioCaster and @nprofile…cn7u support it.
Think of it as a live chapters block and live value block that gets sent over a websocket during a live show.
I'd like to discuss a format that makes sense and modify the proposal so everyone can agree on a good format for the tag
https://github.com/Podcastindex-org/podcast-namespace/discussions/547#discussioncomment-16201182

2026-02-24 21:27:55 UTC

- reply

@nprofile…k8p7
1) I send you the data, you send me a unique url
2) I send the payment and include the unique url in the message.
3) Fountain hosted wallets get the payment with the message, look in the database to find the metadata that's tied to that unique url found in the message and marks it as paid or verified.
4) You don't have to trust any of the apps, just that your wallet got the payment with the unique url generated by your server.

2026-02-24 21:19:24 UTC

- reply

@nprofile…k8p7 why can’t we skip the fetching part and I just send it to you direct?

2026-02-24 21:14:42 UTC

- reply

@nprofile…k8p7
So the app hosts the metadata, and Fountain fetches it?

2026-02-24 21:11:59 UTC

- reply

@nprofile…k8p7
If I send a Bolt 11 payment from a non-Fountain app, how does Fountain get the metadata?

2026-02-24 20:35:00 UTC

Why are none of the PC2.0 hosting companies stepping up to host metadata for their podcasters?
As an app dev, I'd be more than happy to POST the metadata that was in a TLV record to your server so you could build a badass dashboard to show your podcasters their stats.
I'm more than happy POSTing for your podcasters, but I'm not interested in HOSTing.

2026-02-24 13:47:23 UTC

- reply

@nprofile…lm4c @nprofile…x5pc
This whole business of having 20 different apps all hosting their own messages is stupid. The podcaster ends up needing a server anyway to go through all the invoices, fetch each message from each app, then display it in a user friendly way. If they're going to need a server to do that anyway, let's cut out the part where each app stores their metadata and the app can just send the metadata straight to their server instead.

2026-02-24 13:45:40 UTC

- reply

@nprofile…lm4c @nprofile…x5pc
This isn't the responsibility of the Index or the apps. This is the responsibility of the podcaster. If they want their messages, they should figure out how to receive and host them or hire a host that does.

2026-02-20 15:47:19 UTC

@nprofile…7fxa
Here you go dude, an easy place to send your podpings.
https://podping.me/

2025-11-14 18:29:18 UTC

- reply

@nprofile…amf2
Oh, that's good to know. How's the mobile experience connecting NWC?

2025-11-14 18:15:01 UTC

- reply

@nprofile…amf2 @nprofile…60s3 @nprofile…pnt8
The only issue with NWC from an app perspective, is it also allows other wallets to connect. Other wallets that don't support keysend like Alby does. Users will be confused why they can connect their Primal Wallet but not be able to send a boost. Once most podcasts are lnaddress, NWC will make more sense for apps to support without having to deal with users blaming the app for their failed boosts.

2025-11-07 18:05:51 UTC

- reply

@nprofile…xefh @nprofile…myyh
Can I have a private relay that public apps can post to, or would they need some secret way to post to the private relay?

2025-11-07 18:00:32 UTC

- reply

@nprofile…myyh
Totally agree. I think hosting a server to send the metadata to is no different than hosting a relay.
Unlike a relay though, a server has privacy built into it, and the self-hoster's would be able to figure out how to host their own metadata server, and those who can't can sign up with a hosting company or service that handles it for them.
Fundamentally, I don't see your nostr solution as being much different than a meta server. It's an app sending signed data to a server.

2025-11-07 17:33:37 UTC

- reply

@nprofile…myyh
Doesn't the podcaster need to know the relay the app is sending to so they can see data?
If I post something on Damus relay, and that's the only relay I'm connected to, and you're not connected to Damus relay, then you're not able to see what I posted.
Am I understanding nostr correctly, I can only see stuff from you if we're both connected to at least one similar relay?

2025-11-07 17:29:56 UTC

- reply

@nprofile…myyh
So, you're suggesting a url in the feed that connects to a server(relay) of the podcaster's choosing, and then all of the apps verify payment, create the metadata, sign the metadata, then send it to that server(relay)?

2025-11-07 17:19:40 UTC

- reply

@nprofile…myyh
How would the app know what relay(s) the podcaster wants the note posted to?

2025-11-07 15:28:32 UTC

- reply

@nprofile…myyh @nprofile…l26x
If Fountain has an API, and especially if it's in the feed, I'll be one of the first ones to start sending metadata your way.
I'm not able to host it on my own database, but would be more than happy to forward it along to a metadata service.

2025-11-07 15:23:48 UTC

- reply

@nprofile…myyh @nprofile…l26x
There is a third way.
That host stores the metadata. Each app sends it to the host API found in the feed.
This works well for Fountain as a business. Since you're willing to store metadata, all the apps send it to your API, and if someone wants access to their metadata, they choose a host like Fountain that gives them that data. More people choose Fountain as a host because you offer more services.

2025-11-07 15:07:30 UTC

- reply

@nprofile…myyh @nprofile…l26x
So if the listener sends a lunrlp Boost, how does the wallet get the metadata from the app? What will the app have to do to make all of this work?

2025-11-07 14:59:34 UTC

- reply

@nprofile…myyh
I guess this becomes a question of who's responsible for hosting/storing a podcaster's metadata, the podcaster/host or each app?
Being both an host and app company, this works for you, but it won't work for me or @nprofile…l26x (who I don't think runs a backend)
(I hope this doesn't come across as confrontational, more just pointing out a concern. I'm glad you guys are working on a solution.)

2025-11-07 14:53:48 UTC

- reply

@nprofile…myyh @nprofile…q064
With this solution, will the apps be expected to maintain a database and schema for podcasters to use to fetch their metadata?

2025-11-01 21:36:28 UTC

- reply

@nprofile…wsp3 @nprofile…y5nd
There's webhooks and api access tokens you can use. It's basically how the split box was built, which is a Rube Goldberg of a payment forwarder built around Alby's API.
Happy to answer any questions you have.
https://getalby.com/developer

2025-09-09 21:03:07 UTC

- reply

@nprofile…6746
I think the first question to ask, is do we want metadata to be public or private?
I'm not entirely sure I want you guys to know how many hours of Girl Boner Radio I listen to.
But, maybe metadata should be public. It would be pretty cool to let the data nerds do their thing and see what real stats are.

2025-07-17 12:45:18 UTC

- reply

@nprofile…6746
For the love of easy sats is a root of all kinds of evil.

2025-05-31 12:57:52 UTC

- reply

@nprofile…r3p6
4 is the big one. Fountain happens to run their own relay, so it would end up becoming the de facto one most people used. Any one can run a relay, it’s just a server, but if we’re going to require people to run a server or use their host’s server, I’d prefer we’re doing it on REST server instead of a nostr server.
Storing and displaying TLV records has always required a server, the wallet providers just handled that for us.

2025-05-31 12:53:29 UTC

- reply

@nprofile…r3p6
1) I don’t like that the data is sent as a flat array
2) it’s the Wild West, want to make a podcast event, maybe someone has shear done that, why reinvent the wheel? Which NIP do you look at, which kind should I use, I don’t know, everyone is just making stuff up,
3) Highly inefficient. Want to find a list of events, query every relay, get all the events sent back, and every relay sends duplicates.
4) Want a specific message, you better know star relay its stored on.

2025-05-30 15:15:25 UTC

- reply

@nprofile…zn42 @nprofile…27yh
I’m not a big fan of using nostr as it’s a public protocol and anyone can view the notes and metadata. I’ve always valued privacy. Also, having built stuff for nostr, I think it’s a terminally flawed protocol, but I can definitely understand the appeal of it, especially considering Fountains goal of being a nostr app. If that’s the direction most people want to go, I’ll follow.

2025-05-28 12:56:14 UTC

- reply

@nprofile…27yh
I totally agree, and the valueBlock is extremely open. The competing goals of interoperability and being open to other protocols is a a two edged sword for sure.

2025-05-28 12:42:09 UTC

I understand something like being lnaddress exclusive is going to be different than how things have been done before. But different payment options have been available since the creation of the valueBlock. At any point, someone could've decided to use Hive or Monero as their payment protocol. Any podcaster choosing that payment method would not be able to receive value from some apps, or the app would've had to build for a different payment type. lnaddress only is fundamentally no different.

2025-05-28 12:14:31 UTC

- reply

@nprofile…ayy4 This won't effect anyone but Fountain Blue users. If you like your keysend, you can keep your keysend. Some apps that won't work with lnaddress won't be able to be used to send payments to any splits that are lnaddress. This has been the case for a year now. In the future, I'm sure some apps will be lnaddress only, and you won't be able to receive value from those apps. We all have to make decisions with the compromises we want.
@nprofile…2d4u @nprofile…s2q5 @nprofile…zn42 @nprofile…r3p6 @nprofile…h82d

2025-05-27 22:56:12 UTC

- reply

@nprofile…r3p6
I agree, we need to consolidate on a solution. I’ve said my piece about the direction this should go, which is a meta server url in the feed to send the data to, but I don’t want to get involved in any more in fighting. We’ve stagnated because nobody can agree on anything any more, and we’ve already started splintering. Whatever everyone decides on, I’ll start sending the metadata for lnaddress there.
@nprofile…2d4u @nprofile…s2q5 @nprofile…h82d @nprofile…zn42

2025-05-27 20:51:51 UTC

- reply

@nprofile…r3p6
Is your main beef with the metadata, or do you have other issues with lnaddress?
If there was an agreed upon way to handle getting metadata to a podcaster that wasn't via a TLV record, would you support it?
Is there anything technically stopping you from supporting lnaddress running serverless, or is it a preference thing you have?
@nprofile…2d4u @nprofile…s2q5 @nprofile…h82d @nprofile…zn42

2025-05-27 17:42:15 UTC

- reply

@nprofile…r3p6 @nprofile…2d4u @nprofile…s2q5 @nprofile…h82d
v4v isn't metadata. v4v was PayPal and checks and gold coins and any other way you want to support a show, well before we started lightning payments.
But this does break the metadata, I agree. And I've tried to suggest solutions to address that. However, lnaddress is the direction everyone but PC2.0 is going. As much as I hate it, I can't deny it. I prefer keysend, I've just conceded that we've lost that battle.

2025-05-27 17:37:46 UTC

- reply

@nprofile…r3p6 @nprofile…2d4u @nprofile…s2q5 @nprofile…h82d
The reality is, the spec is very open. Fountain could've chosen to not support lightning at all and gone all in on Hive or Monero, and the spec allows it. Then we'd have to decide if we want to build an app that supports the Hive or Monero protocol, because there would be valid RSS feeds using something besides lightning for listener support.

2025-05-27 17:35:39 UTC

- reply

@nprofile…r3p6 @nprofile…2d4u @nprofile…s2q5 @nprofile…h82d
You're not being forced to do anything. It's your choice if you want to support that part of the spec or not.
There is no simple solution, but holding onto keysend isn't the solution either. Very few wallets support it.
We chose Betamax, it's a superior solution. The rest of the world chose VHS. We can hold onto Betamax if we want to, but nobody else is going to.

2025-05-27 16:19:25 UTC

- reply

@nprofile…2d4u @nprofile…s2q5
It's been in the spec for almost a year now. I think any of the apps wanting to do it have had ample time.
I actually think this is a good move, and you guys should move forward with it with your transition, that way you don't have to go back and update your feeds later.

2025-05-27 15:10:25 UTC

@nprofile…2d4u @nprofile…s2q5 I heard Fountain Blue is going to be lnaddress exclusively. Is this true?
If so, the other apps are going to really want to start implementing lnaddress support, or there's going to be a lot of podcasts their app doesn't do lightning payments for.

2025-05-16 17:04:07 UTC

- reply

@nprofile…nza4
This was a very unique and lovely experience.

2025-05-16 15:20:14 UTC

- reply

@nprofile…ayy4 @nprofile…mg8l
You can add it manually in the Manual edit in SF.
I can add it. But it adds to bloat.
I'm a podcaster. I see a field for title and another one for itunes:title.
Here's what I'm thinking:
WTF is this?
Which one am I suppose to use?
Why not just have one thing called title?
This is so confusing. This host sucks.
As a hosting provider, I want to avoid that, so I simplify. Maybe they don't get the full functionality. They don't care. They want ease.

2025-05-13 17:40:29 UTC

- reply

@nprofile…2802
The options proposal got scrapped, so I fell back to looking up keysend first, as it accomplishes what options was trying to do.

2025-05-13 17:31:29 UTC

- reply

@nprofile…2802
One thing I've been doing as a courtesy with lnaddress addresses, is do a .well-known/keysend look up first based on their lnaddress. If it returns an address, I'll send the boost over keysend so they get the TLV record, if not, I fall back to the lnurlp lookup and request and invoice.

2025-05-13 12:17:31 UTC

- reply

@nprofile…6746 @nprofile…2802 @nprofile…pvn3 @nprofile…h82d @nprofile…zn42
The problem on the podcaster side is they lose the TLV record (comments, if the wallet allows are limited to 200 or so characters). I don't know how much of the TLV is needed, but stuff like remoteItem is usual for something like a music show.
There are solutions to this as well. The podcaster could have a TLV hosting service they use that the app sends the record to. This has other problems, but those are solvable too using Webhooks to verify payments.

2025-05-13 12:09:33 UTC

- reply

@nprofile…6746 @nprofile…2802 @nprofile…pvn3 @nprofile…h82d @nprofile…zn42
I would love for a push to be made that keysend is deprecated and valueblocks should have lnaddress. It's the direction things are going, we should to.
The difficulty on the app side is simply the number of network calls that need to be made. For a mobile app, there's worries that it will drain the battery, but it can be done without a server.

2025-05-11 04:25:24 UTC

- reply

My hats off the Podcasting 2.0 community. They really understand what v4v is all about. This event was a hallmark of the time, talent, treasure model, and I couldn't be more proud of what was accomplished tonight.

2025-05-11 04:22:35 UTC

We just stress tested The Split Box. It was able to support the Satellite Spotlight, an event that sent 2.2 million sats worth of boosts, 1.2 million of them being through TSB.
The means the listener was able to scan a QR code from the wallet of their choice, and over 20 splits were handled on the backend.
This means you can paste your QR code on fliers, merch, the drumkit, and your fans can boost from the wallet of their choosing and each band member gets their split.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/487/271/805/313/365/original/18cf4b792babf55c.png

2025-05-01 12:00:53 UTC

- reply

@nprofile…cguj
You free to jump on a call later tonight? I can walk you through things and answer any questions.

2025-04-30 13:05:01 UTC

- reply

@nprofile…0a2a @nprofile…pvn3
I wonder if your time 'might' be better spent figuring out how to implement Hive in the value block. I don't know if it's a better solution, but perhaps it addresses some of the pain points we're having with lightning.
IMO, a perfect solution would need at at least:
SPLITS!!!!!!
Micropayments.
Easily convertible to fiat.
A dead simple wallet that a mid-wit can figure out and fund
Programmable.
An easy API for an app dev to figure out.
Anything else???

2025-04-29 20:39:59 UTC

- reply

@nprofile…326g @nprofile…6746
And look at all those splits going out back out!!!
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/423/181/871/190/636/original/8d6cb7af510c2219.png

2025-04-29 19:57:11 UTC

It's coming.... 5/10/25
One QR to rule them all,
one QR to find them,
One QR to bring them all
and in the darkness bind them.
One QR code, multiple splits, splits can change on your command, in real time.
Verify the splits were made.
https://thesplitbox.com/metadata/d5def5f7-63da-4292-9ff8-18fb7fdc18fe
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/423/002/595/551/910/original/25c6abe7538747ca.png

2025-04-28 01:39:25 UTC

For any of you early adopters, Sovereign Feeds now supports the new Location tag attributes in the channel, item, and liveItem.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/413/033/452/549/657/original/7910744bc4b106e5.png

2025-04-21 13:57:20 UTC

- reply

@nprofile…h82d
Only 12-24 months to go... according to AI.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/376/299/666/375/539/original/e1e398bbbc685e9e.png

2025-04-01 13:02:55 UTC

- reply

@nprofile…v2ca TSK is quite a bit more than a broadcaster for liveEvents. If someone one just interested in sending liveEvents, they totally can without using TSK. It's just a json file sent of a websocket.
I suppose someone could use my socket server rather than setting up their own, and their app sends the correct message to TSK, and then TSK rebroadcasts to all the clients, but I'd have to quite a bit of work to change how my authorization for who's allowed to send updates works.

2025-04-01 12:55:47 UTC

- reply

@nprofile…v2ca @nprofile…326g @nprofile…cguj
Now I have an endpoint looking for eventGuid, feedGuid, and itemGuid. It parses those from the query, looks up the feed and item from the Index, connects to your event over socket.io, and sends the stuff to build a block automatically.

2025-04-01 12:55:11 UTC

- reply

@nprofile…v2ca @nprofile…326g @nprofile…cguj
If the artist is using TSK, then they create an event in TSK, which gives them an eventGuid. As they add new block to each event, a new blockGuid is created. Those are used internally. Those don't really need to be in the mp3, that's left over from an old method.

2025-04-01 12:38:14 UTC

- reply

@nprofile…v2ca @nprofile…326g @nprofile…cguj
Then you just need to broadcast the liveEvent over socket.io and put the server url in the feed so the apps know which socket to connect to.
Right now, Podcast Guru and CurioCaster are the only two apps listening for liveEvents.
Here's the discussion, and what data the apps are getting looks like.
https://github.com/Podcastindex-org/podcast-namespace/discussions/547

2025-04-01 12:32:25 UTC

- reply

@nprofile…v2ca @nprofile…326g @nprofile…cguj
The radio station could send out the data the apps are looking for over socket.io. Right now, TSK is the only liveEvent broadcasting app, so someone either has to build their events manually, or send a feedGuid and itemGuid to my endpoint so I can build the events automatically. I put that info in the mp3 files they download from TSK so they don't have to look it up, their software can just send what's already in the metadata.

2025-04-01 00:13:17 UTC

- reply

@nprofile…v2ca @nprofile…326g @nprofile…cguj. Ideally, it would be able to get a signal from a radio station to update the artwork and value block in real time to reflect the current show or song being broadcast. Getting metadata from the stream that can be used for updating live chapters and value blocks is something we’re trying to figure out for podcasting radio.

2025-04-01 00:10:28 UTC

- reply

@nprofile…v2ca @nprofile…326g @nprofile…cguj Once the show goes to recorded podcast, all of those live events can be converted to VTS and chapters in the feed.

2025-04-01 00:09:09 UTC

- reply

@nprofile…v2ca @nprofile…326g @nprofile…cguj It’s a tool I developed to send live info to any of the apps listening to the socket.io event found in the feed. By listening the app can get live data from the podcaster, think live value blocks and live chapters that update in real time on any listening app.

2025-03-31 20:52:55 UTC

- reply

@nprofile…cguj
If you drop an mp3 download from TSK into a metadata reader like this https://www.metadata2go.com/result#j=74918a66-cbea-4ab1-925b-38381a8c770c You'll see I'm adding the stuff that needs to be read and sent to TSK. Again, it's built for mAirList, but if Azurecast is able to send data, I can build something around it. I really just need the feedGuid and itemGuid if you're trying to play a song and it builds your TSK event in real time.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/114/259/014/896/513/152/original/d43226516e0d1e56.png

2025-03-31 20:47:45 UTC

- reply

@nprofile…cguj @nprofile…zn42 @nprofile…326g
But any software that can send the eventGuid, feedGuid, and itemGuid whenever the song changes would work.

2025-03-31 20:47:01 UTC

- reply

@nprofile…cguj
When you download the mp3 from TSK, I add some extra metadata into the mp3, stuff like the eventGuid, blockGuid, feedGuid, and itemGuid. Software like mAirList is able to read that metadata, then send it to an endpoint I have. Depending on the endpoint, it either adds and activates a new block to your TSK event, or it activates an existing block.
@nprofile…zn42 and @nprofile…326g use mAirList for building/broadcasting their shows, so that's what it's built around.

2025-03-31 20:41:12 UTC

- reply

@nprofile…cguj
I'm not sure how Azuracast works, but if it has a way to read the metadata from an mp3 downloaded from TSK, then send that metadata to an API endpoint when the mp3 plays, then yes.

2025-03-31 17:24:43 UTC

- reply

@nprofile…cguj
I created a demo in which you can look at the feeds and verify the feeds here.
https://svelte.dev/playground/134809f1af4d4651a35516502432cf3b?version=5.25.3
If you click the link to the feeds, you'll notice I used <podcast:auth> and nostr signatures, but it's more a proof of concept then needing to use npubs/nsec and the nostr protocol for signing events. Any sort of pub/secret key signing of the hash should work.

2025-03-31 17:21:16 UTC

- reply

@nprofile…cguj
The problem is solves, if one can say it's even much of a problem, is if a DNS or server error occurs, your back up feed is available, or if your host decides to de-platform you, you have back up servers available to ensure your content is available.
I don't know if this solution is really needed, just thinking about how we can use ideas from other areas and adapt them into ours if it makes sense to.

2025-03-31 17:19:20 UTC

- reply

@nprofile…cguj
This allows me to upload to a backup server. If an app gets a 404 error on the primary server, it can look for the feed on the backup server, and verify the feed hasn't been tampered with on the back up server as well and also check that it's the same feed signed by the feed owner.
It would ideally be automated, so when you press publish, everything is done behind the scenes, including hashing, signing, and pushing to all of your backup servers.

2025-03-31 17:17:02 UTC

- reply

@nprofile…cguj
It wasn't so much to integrate with nostr, as to see if we could use an idea from nostr for our own purposes.
The idea is to hash and sign the xml, then insert it into the xml and publish. The verify, strip the signature tag from the xml, then hash it and compare to the hash from the strip tagged. Using the public key, we can verify that the signature was signed by the corresponding secret key.

2025-03-30 22:18:23 UTC

- reply

But I don't know if the signature/hash is entirely necessary, which is why I want to hear everyone's input, and it seems that most agree it's more of a solution looking for a problem.
Though, as Eric points out, the signature in a feed to verify ownership may be something worth considering for changing hosts, especially as we've moved away from emails in the feed.

2025-03-30 22:16:49 UTC

My idea with the signature in the feed isn't so much that we need to figure out how we can integrate with nostr, I'm not convinced we need to. It's more that some of their criticisms about why nostr is better than RSS may have some merit worth considering, and if so, how we can use their ideas for our own purposes.
I'm open to criticism so we can improve things we may not notice because we're insiders and can sometimes be myopic when viewing something we love.

2025-03-30 14:37:19 UTC

- reply

My question to those that have been in the game a while, is this a solution looking for a problem?
Is redundancy that big of a deal in RSS?
We've been podcasting for 20 years without a need for redundancy, and I've never heard about a server going down being a big issue for a podcaster.
I'm more curious if this is an idea worth pursuing, and we can use the idea redundancy across multiple servers, or is my time better spent elsewhere?
3/3

2025-03-30 14:37:07 UTC

I've been working on an idea that involves putting a hash and signature in your feed to verify ownership and authenticity, so you can have your feed hosted on multiple servers, and the host can know it's from you, and the apps can know it wasn't tampered with.
2/3

2025-03-06 05:29:21 UTC

- reply

@nprofile…h82d @nprofile…xy55
Either makes sense to me. I prefer the 'itunes:image' tag over the 'image' tag, so think copying that one makes more sense, which would be 'href'.

2025-02-21 13:20:25 UTC

- reply

@nprofile…j90y
If no apps or feeds support a tag, it’s de facto removed, it’s just in the docs. I think removing tags is worth considering because it doesn’t cause a breaking change .When modifying tags should be much more cautious so we don’t break apps and parsers, but removing is safe. I also think we should have a trial period with tags before formal adoption so we can discover problems as the tag is used in the wild that we didn’t foresee, and during that time those tags can break.

2025-02-15 16:06:51 UTC

- reply

@nprofile…2802 @nprofile…wuyh
I do too, which means I have to make a call to the feedUrl so I can get info the Index isn't currently parsing for, but also make a call to the Index, just to make sure the podcaster might have a value block.
Prior to needing to get info from the feed that wasn't in the Index, I only made one call, to the Index, since it had all of the info I needed.
If I did it to save code and bandwidth, I suspect other apps are doing it as well.

2025-02-15 13:14:02 UTC

- reply

@nprofile…wuyh
Because of the wallet shim, some apps only use the value blocks from the Podcast Index. Since Fountain relies very heavily on the wallet shim, this may be the case. Concerning wallets, the feed isn't the source of truth, the Index is.

2025-02-07 16:39:35 UTC

- reply

@nprofile…zn42 @nprofile…h82d
Awesome! That's good news.

2025-02-06 18:18:04 UTC

- reply

@nprofile…2802
I don't think it's a bad idea either, but getting wallets on board with it seemed to be problematic. Alby was willing to play along, but I think apps like Strike or CashApp, not so much.
I actually do a .well-known/keysend lookup with the address first to see if it supports keysend, then fall back to .well-known/lnurlp if the first request fails, so I'm not sure the options lookup is strictly necessary since I'm doing the same number of calls this way anyway.

2025-02-06 18:14:11 UTC

- reply

@nprofile…2802
Were you guys able to get a Strike business account? The Strike API integration would be very beneficial for any app wanting to create a simple wallet/app connection.
And what you're saying is mostly the problem I'm talking about. All of the keysend address aren't going to be able to be paid using anything but a Breez, Alby, or Zebedee wallet. Right now, this isn't a big deal, but as more people start wanting to use easier wallets like CashApp or Strike, it will become an issue.

2025-01-24 13:49:02 UTC

- reply

@nprofile…r3p6
Is your adversion to a server component simply that? I ask because I keep you in mind when thinking about how payments could/should work in an app, but it seems like servers are necessary, especially for keysend, and either you're running it or someone else is. For payments, we simply sent an array to Alby, and Alby's servers handled it.
1/2

2025-01-17 16:12:55 UTC

- reply

@nprofile…cq0g @nprofile…pvn3
Give it some time then, the Index will catch up with the feed.

2025-01-17 15:28:53 UTC

- reply

@nprofile…pvn3 @nprofile…cq0g
Index has some cached data that's not in sync with the feed.
Did you podping it?
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/844/397/497/004/308/original/280aa6b1e38fe2df.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/844/401/038/653/938/original/29c5721aec3b45f2.png

2025-01-15 03:31:40 UTC

@nprofile…xy55
What's the function to get a link for a podcast and episode for linking to https://episodes.fm/ ?

2025-01-06 21:44:52 UTC

- reply

@nprofile…3ram @nprofile…2802
In fact, doing something like
<podcast:remoteItem
feedGuid="a71b097b-4cf0-5e74-b6a9-1271373bb396"
itemGuid="a45376c3-c8b3-4173-80c4-4cdfa266e0db"
remotePercentage="99"
startTime="123"
duration="60"
/>
could be pretty useful for putting clips in a feed.
Fetch that podcast, then start playing it at timestamp 123 for 60 seconds.

2025-01-06 21:42:49 UTC

- reply

@nprofile…3ram @nprofile…2802
I don't think it's necessarily a mistake, it's more that if others come across it and it doesn't match the spec, they probably didn't build to the way you're building.
I think the easiest way to handle it is to do something like
<podcast:remoteItem
feedGuid="a71b097b-4cf0-5e74-b6a9-1271373bb396"
itemGuid="a45376c3-c8b3-4173-80c4-4cdfa266e0db"
remotePercentage="99"
/>
That will add the remotePercentage you need as an attribute and won't break any other apps.

2025-01-06 12:40:57 UTC

- reply

@nprofile…3ram
Hey Sam, I'm not sure if there's a different way of doing musicL in the specs, but our musicL formats are pretty different. If yours is valid, I'd like to know so I can work on my parser to make sure I can play your feeds or figure out what I need to do to change my feeds.
https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#examples-17
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/781/455/266/818/724/original/789291d58295d75a.png

2025-01-06 05:06:02 UTC

- reply

@nprofile…wuyh
Have you seen the Value Block Updater in SF? They idea is you can update an address once, and it will update it across all your feeds, It's still a slow, tedious process.

2025-01-06 03:02:53 UTC

LN Beats is now hosting music playlists. Available in all apps that support musicL.
https://podcastindex.org/podcast/7157117
https://lnbeats.com/album/eeeb0e31-f3da-54f2-909f-4fd640c684cc

2024-12-27 16:05:28 UTC

- reply

@nprofile…g5pf @nprofile…6746
A little devil's advocate... I've seen people spend more on a six pack they'll piss out the next morning, a lotto ticket they'll most likely lose, or a fast food meal they'll shit out tomorrow.
If you want to see if running your own node is right for you, I can think of worse ways to spend the $21 bucks for three months to see if this is something you may want to continue paying for. Or you may find out how easy it is and put it on your own hardware... for free.

2024-12-20 14:44:04 UTC

@nprofile…mp2c
Do the Alby Webhooks work apart from getalby.com?
If I'm running Alby Hub, are the webhooks coming from my machine, or are they coming from getalby somehonw?

2024-12-19 18:52:08 UTC

- reply

@nprofile…2d4u @nprofile…pvn3
Probably a more efficient way to get all of the data, but as a proof of concept for the apps to see how easy getting comments can be, this works.
Shows user name and boost amount.
https://svelte.dev/playground/8d92451e56ce401db17bf3ea83476605?version=5.14.5

2024-12-19 18:02:22 UTC

- reply

@nprofile…pvn3
Something up with my code. I'm looking for 9735s, but not getting anything.
https://svelte.dev/playground/8d92451e56ce401db17bf3ea83476605?version=5.14.5

2024-12-19 14:25:56 UTC

- reply

@nprofile…2d4u @nprofile…6746 @nprofile…5pjr
And you don't even need an nsec/npub to fetch comments, just know the relay address and connect with websocket. nsec is needed if you want to make comments.

2024-12-19 14:24:31 UTC

- reply

@nprofile…2d4u @nprofile…6746 @nprofile…5pjr
Perfect, and that's all done in the client connected to the websocket, so even serverless apps can do it. At least browsers. I don't know how iOS apps handle websockets.

2024-12-19 14:13:10 UTC

- reply

@nprofile…6746 @nprofile…5pjr @nprofile…2d4u
I don't know enough about nostr messages yet. Maybe Oscar can help. If Todd writes a message on Fountain that is connected to Podcasting 2.0, and I don't follow Todd, how can I find that message to display when I'm showing messages connected to that PC2.0 episode?

2024-12-19 04:47:18 UTC

- reply

@nprofile…ayy4
No argument from me. I like keysend.

2024-12-19 04:38:07 UTC

- reply

@nprofile…ayy4
See that little group of people playing off by themselves in the corner? That’s us.
https://podcastindex.social/@js/113664682761204916

2024-12-18 19:34:21 UTC

FWIW, here's a link to my nostr podcast player that gets the xml from a nostr relay.
https://svelte.dev/playground/ff177c532f0743e490bdfaaaa2884d40

2024-12-18 18:28:44 UTC

- reply

@nprofile…cguj @nprofile…326g @nprofile…pvn3 @nprofile…h82d
I think we found the solution 20 years ago with RSS, but maybe I'm just an old head. I'm really just trying to understand the tool and explore what it might be useful for. Most of what I build is just me playing around.

2024-12-18 18:24:13 UTC

- reply

@nprofile…cguj @nprofile…326g @nprofile…pvn3 @nprofile…h82d
Store a copy of things across multiple servers. That's all nostr is doing. I send a message to Damus, Damus stores it. If you're not on Damus, you don't see the message. I have to send it to multiple relays and hope you're also on one of the relays I sent it to.
Nostr would store the rss on multiple relays. http server, only your one server. The redundancy is the thing I find most interesting.
And can we really ignore that relays have DNS?