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-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: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 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-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-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 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-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-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-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-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-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 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: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:16:47 UTC

- reply

@nprofile…cguj @nprofile…326g @nprofile…pvn3 @nprofile…h82d
But it's all just a thought. I think lots of nostr people want to do away with existing protocols and change everything to some nostr protocol. I'm sticking with RSS, it's proven, but I'm just toying with ideas on how we can use this new thing to our benefit, and not just for social.

2024-12-18 18:15:16 UTC

- reply

@nprofile…cguj @nprofile…326g @nprofile…pvn3 @nprofile…h82d
Oh yeah, this isn't a replacement of the DNS, it's a backup if your DNS ever goes down. Nothing about the delivery mechanism of RSS changes, it just provides an alternative one in case the primary one goes down. Totally backwards compatible.

2024-12-18 17:16:09 UTC

- reply

Here's the code to fetch the feed from nostr.
https://gist.github.com/thebells1111/d21b46803a02c3492649ff9d997713de

2024-12-18 16:53:52 UTC

- reply

So, if one puts the id and pubkey in their feed, when someone subscribes to your feed, the app can now find your updated feed on nostr.

2024-12-18 16:53:03 UTC

- reply

Any one who knows what they're doing (I'm not one of them yet) can find it with this... I think.
id: '4e55ae60f5583112bb1e63c41b675bd72dd64ed6c6e680c78ba1896f70572051',
pubkey: '93ddf8f20daa5520b604bf14f566354c70540f870706f55e13cf8cded02943a5',

2024-12-18 15:53:02 UTC

- reply

Just need a tag in the feed with the nostr message id and a list of known nostr servers that store the feed. We keep the underlying structure, just add a new delivery mechanism that has some built in redundancy. When I publish the feed, I just have my feed server store it like it always has, but then sign a message and broadcast it to all the nostr relays so they know I've given their server permission to update my feed.
2/2

2024-12-18 15:51:53 UTC

As I've dug into nostr, I don't see any reason RSS couldn't be extended to include nostr.
Right now, if I want a feed, I fetch it from the url. I could have my app just as easily connect with a nostr server and request the message that returns my RSS file.
1/2

2024-12-18 14:36:16 UTC

- reply

@nprofile…mp2c @nprofile…h82d @nprofile…v2ca @nprofile…3ram
CDN problem. It takes some time for the CDN to update to the new file. If you were just fetching the file, it's available immediately, but lots are serving their files from a CDN.

2024-12-16 15:38:10 UTC

- reply

@nprofile…8p9w @nprofile…2802 @nprofile…zn42
SSN got me in further. Got stuck at this page.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/663/245/113/598/834/original/89d025f5e31089e7.png

2024-12-16 14:58:23 UTC

- reply

@nprofile…2802
Yeah, it's an Employment Identification Number. It's part of our tax system.

2024-12-16 14:47:44 UTC

Bad news for Strike oAUTH API integration. It requires an EIN to setup.
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/663/044/036/607/914/original/a19c51bb3f525d0c.png

2024-12-13 16:32:04 UTC

- reply

@nprofile…v2ca @nprofile…h82d @nprofile…3ram @nprofile…2802
Planning on offering a commercial version?

2024-12-12 19:26:25 UTC

- reply

@nprofile…f05c @nprofile…v2ca
Maybe it should be a options.json file. That makes a lot of sense, especially for people that are using something like a wordpress website.

2024-12-12 19:13:42 UTC

- reply

@nprofile…f05c @nprofile…v2ca
You would also host this file
https://getalby.com/.well-known/lnurlp/satsandsounds
at
satsandsounds.com/.well-known/lnurlp/satsandsounds/
Now, in your value block, your lnaddress would be satsandsounds@satsandsounds.com
It's not exactly difficult, but it can be confusing.

2024-12-12 19:13:04 UTC

- reply

@nprofile…f05c @nprofile…v2ca
You would take the information you find here
https://getalby.com/.well-known/keysend/satsandsounds
and here
https://getalby.com/.well-known/lnurlp/satsandsounds
And combine them to make a new file that looks like this.
https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/lnaddress.md#options-file
Then you would host that file at this route.
satsandsounds.com/.well-known/lnurlp/satsandsounds/options

2024-12-12 19:04:43 UTC

- reply

@nprofile…f05c @nprofile…v2ca
What's your getalby address?
Do you have your own website you can host files on?

2024-12-12 17:02:35 UTC

- reply

@nprofile…v2ca
Okay, so I need to host my own .well-known, so my lnaddress would be steve@curiohoster.com?

2024-12-09 15:48:47 UTC

- reply

@nprofile…fhff
What's your profile, I'd like to check out what it is Gravatar is building. I was just starting a lightning enabled Linktree alternative, but if Gravatar is already doing it, I can just tell people to set that up.

2024-12-09 13:58:39 UTC

I'm not discouraging anyone from building for other coins, I think it's cool the the value spec is extendable to support any sort of programmable payment. But I won't be pushing for or supporting every possible coin. The more payment systems we introduce, the more fractured things become, as podcasts that use different payment types will only be supported in the niche apps that support that payment type. The idea of podcasting was one feed, any app. It may become one feed, certain apps.

2024-12-09 06:03:21 UTC

- reply

@nprofile…zn42 @nprofile…6746 @nprofile…r3p6 @nprofile…h82d @nprofile…2d4u
Your Strike account keys are different from Strike oauth keys. You need a business account to create oauth keys. I just created some api keys, there's no redirect url with the account api keys.

2024-12-08 21:59:20 UTC

- reply

@nprofile…pvn3
Well then, Wallet-geddon is postponed. I'm actually pulling back on supporting LNURLp. I'll let others go through the headaches of figuring out how to make it work, and if it proves itself, then I'll revisit it. If people want to use my apps, get your own node or use coinos. I don't cater to the 99%, I'm a 1 percenter.
@nprofile…vu32

2024-12-08 19:41:39 UTC

If we do move away from lnaddress for some reason, I'd still like something in the value block that tells the app to fetch my address from my server instead of it being hard coded in the feed. Because I don't have control of every feed I may appear in, I'd still like to have the feed to have a way to reference a document I do have control over. Maybe lnaddress isn't the solution, but I don't want to contact every podcaster or musician I share a split with every time I change my wallet address.

2024-12-08 15:53:52 UTC

- reply

@nprofile…r3p6 @nprofile…zn42 @nprofile…h82d
Maybe we don't need to figure out 'easier' alternative wallets, we just need to train listeners on how to host their own wallet. After going through the experience, it's no more difficult than figuring out how to navigate Strike or CashApp.
Remember when you had to tell them how to click the RSS symbol to load a feed. It's like that except now they need to be walked through setting up a Alby Hub node on their own device.

2024-12-08 15:36:51 UTC

- reply

@nprofile…v2ca @nprofile…h82d @nprofile…3ram
What programming language and frame work is this going to be in?

2024-12-08 04:12:28 UTC

- reply

@nprofile…cguj @nprofile…6746 @nprofile…mp2c @nprofile…ut03 @nprofile…xmw7
This is the one I'm running on. https://www.amazon.com/dp/B072BGSTQJ

2024-12-08 00:21:13 UTC

- reply

@nprofile…6746 @nprofile…mp2c @nprofile…ut03 @nprofile…xmw7
I did initially setup a new node, and that's easy peasy, and very quick. I ended up deleting it so I could migrate my Alby Cloud node, but for someone starting fresh, it's a very easy process. Anyone comfortable with loading an operating system can handle this.
I spent $80 on my PC, a used HP business machine, and a few hours of my time working through docs and asking questions, and now I have my own node that is humming along. Pretty cool.

2024-12-08 00:18:29 UTC

- reply

@nprofile…6746 @nprofile…mp2c @nprofile…ut03 @nprofile…xmw7
Okay, Wallet is migrated. Initial thoughts. Migrating is not for the feint of heart. There's a period of time where your node is shut down and it takes a bit for your new Hub to migrate everything over, and I wasn't able to see my funds, and I'm thinking "Crap, did I just mess something up and now I lost 800k sats" If I did it again, I would transfer my sats to my cold storage wallet first for peace of mind.

2024-12-07 22:52:46 UTC

- reply

So, the thing with your solution using boostCallback is it requires wallet holders (you know, the ones that can create lightning invoices, which need a preimage to work) to support the boostCallback. You're willing to be a wallet holder is seems, so you can support it and generate invoices for the wallets you hold. But you're creating a solution in which all the other potential wallet holders have to now support boostCallback. They don't support keysend, why do you think they'll support this?

2024-12-07 22:44:31 UTC

- reply

@nprofile…v2ca
It's not magic, it's an engineering problem with a logical explanation, and if you're not able to explain it, you don't understand it.

2024-12-07 22:34:51 UTC

- reply

@nprofile…v2ca
How is your app creating the lightning invoice for Dave's wallet if you don't have access to Dave's wallet? Somebody needs to create a preimage to create the invoice, who is creating that preimage?

2024-12-07 20:39:52 UTC

- reply

@nprofile…mp2c @nprofile…6746 @nprofile…ut03 @nprofile…xmw7
Okay, one thing I noticed is when I'm logged into my machine from a different machine on the local network, I click Launch UI for Alby Hub, and I get a 'Site can't be reached' error. When I do it from the actual machine, it connects to Alby Hub. I kind of want to go headless with the machine and just keep it in a closet or something, so I need to be able to Launch the UI from a different machine on the network.

2024-12-07 20:25:02 UTC

- reply

@nprofile…mp2c @nprofile…6746 @nprofile…ut03 @nprofile…xmw7
Well, everyone trusted you guys with their sats sitting on your node for the last two years, I'm not sure why they wouldn't trust your remote blockchain data.

2024-12-07 20:09:28 UTC

- reply

@nprofile…mp2c @nprofile…6746 @nprofile…ut03 @nprofile…xmw7
Let me see if I understand. If I was pushing 1M sats around, I may want to validate everything to ensure there's no funny business going on, but for sending 1k sats, if there's something weird going on, I risk losing a much smaller amount.
You guys are providing the remote blockchain to simplify things for smaller wallets, but the exchange for the simplicity is it's now not entirely trustless, so make sure you trust the remote block chain provider.

2024-12-07 19:55:28 UTC

- reply

@nprofile…mp2c @nprofile…6746 @nprofile…ut03 @nprofile…xmw7
If I do it without the chain, can I later download the chain if I wanted to without breaking things?

2024-12-07 19:13:17 UTC

- reply

Ok, when I install Lightning are most of you using LND or Core Lightning?

2024-12-07 19:07:18 UTC

Ok, I have start9 on my new machine, how do I setup a wallet?

2024-12-07 16:34:43 UTC

- reply

@nprofile…v2ca
Ok cool.
How do we get around this with your solution?
Dave is using Russell's service, so Russell generates the random number when his service creates the invoice that's returned to Alice.
In order for Dave to clear the HTLC, he needs to get the random number produced by Russell's service. How does Dave get that random number that your service generated?
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/612/486/094/197/137/original/e3e8611d837096b1.png
https://cdn.masto.host/podcastindexsocial/media_attachments/files/113/612/495/237/234/359/original/b75de5bdd779ee92.png

2024-12-07 10:31:40 UTC

- reply

@nprofile…v2ca
I don't think you're understanding me.
If your app generates the hash for a lighting bolt payment to my wallet, what does your app do with the preimage, because my wallet needs it to verify the hash? How does my wallet get it from your app?

2024-12-07 10:25:45 UTC

- reply

@nprofile…v2ca
When you generate the invoice, how does my wallet get the preimage you used to generate the payment hash to verify the transaction wasn't tampered by the payer?