Add a new address type for lightning address (in valueRecipient)

[MerryOscar]

Having the pubkey listed in the value block in the RSS feed complicates things massively for service providers enabling value for value.

If a service provider wants to change their underlying infrastructure, their pubkey is likely to change too, and therefore all feeds that reference the original pubkey will need to update their value blocks. This is infeasible because of the nature of podcasting having so many distributed hosting providers and also self-hosting options. It's fine now as value for value is still small but if we're serious about onboarding more podcasters and hosting providers we need to solve this problem.

Both Fountain and Alby support the keysend lnurlp lookup format:

• https://fountain.fm/.well-known/keysend/merryoscar
• https://getalby.com/.well-known/keysend/bumi

Therefore I suggest that we modify the <podcast:valueRecipient> spec so that the address field can either be the keysend pubkey OR a Lightning Address. We can use the existing type field to signify that the address is keysend rather than a node pubkey:

<podcast:valueRecipient
        name="Oscar Merry"
        type="keysend"
        address="merryoscar@fountain.fm"
        split="90"
        />

The argument against doing this has always been that it's an extra http request in the payment flow. In my view this is no way near a good enough reason to accept this glaringly obvious flaw with the spec that effectively blocks all infrastructure migration for service providers. The extra http request is worth solving this problem.

Lets do this now before value for value grows any further and we'll save ourselves massive amounts of headaches!

---

cc @daveajones @bumi @joksas @blastshielddown @jamescridland

[joksas]

I like this implementation.

Re additional HTTP requests, if that's really a huge problem, podcast players can cache the Lightning address -> node address lookups for short periods of time (e.g., a day).

[MerryOscar]

yes exactly!

[daveajones]

This is less problematic than full LNurl which would require multiple http calls per wallet lookup. So that’s alright.

Two things, however:

1). This introduces DNS into the mix, whereas pure node pub keys avoid that. For app devs that could now mean a new source of customer support requests if a payment fails because the podcaster’s wallet provider’s domain is blocked by a corporate firewall, pihole, etc.

2). Feeds with lots of splits will get even slower payments. Currently a serverless app like Castamatic can take 2 to 3 seconds per split to make a payment. This would increase that even more because of the http lookups. Some feeds have as many as 20 splits.

I’m not against this. We just need to discuss possible ways to solve or reduce the impact of these issues because they are real.

[adamc199]

Being a self hoster, I would be required to ADD infrastructure I do not have.

In light of the recent decentralization discussions, this issue should be the responsibility of the podcaster in my opinion.

If you choose for a centralized solution, these are downsides. You may need to adjust your feed if your wallet provider makes changes.

But you specify "service provider". Is that a new name for custodial wallet?

[bumi]

Regarding DNS: don't we already have this as most RSS feeds are hosted on a domain and we depend on that already?
And if you self-host you already have the infrastructure to serve the feed. The proposal here would require you to serve another static file which should be pretty simple.

Regarding speed: I think those requests can easily be cached and ideally the response also has correct HTTP cache headers

[johnspurlock]

This is optional right? It would be a new type so old feeds would continue to work as they do now, like any self-hosters that don't want to update.

[jamescridland]

This is optional right?

As I read this, it's optional for the CREATOR, but it would appear to be, essentially, mandatory for the APP DEVELOPER to support, otherwise we'll lose payments.

[MerryOscar]

1). This introduces DNS into the mix, whereas pure node pub keys avoid that. For app devs that could now mean a new source of customer support requests if a payment fails because the podcaster’s wallet provider’s domain is blocked by a corporate firewall, pihole, etc.

This is true - but in my opinion the downsides are worth it given the pain of updating pubkeys in feeds across potentially dozens of hosting companies. Also if fountain.fm or getalby.com were blocked by a corporate firewall - surely api.fountain.fm and api.getalby.com would also be blocked so apps using Alby OAuth wouldn't be able to make payments anyway?

--

2). Feeds with lots of splits will get even slower payments. Currently a serverless app like Castamatic can take 2 to 3 seconds per split to make a payment. This would increase that even more because of the http lookups. Some feeds have as many as 20 splits.

I think the caching approach @joksas suggested makes a lot of sense - especially with streaming payments. App developers could resolve the Lightning Address when the user starts playing an episode and then cache for all the actual streaming payments. Feeds with 20 splits are going to be slow either way. If the app is making the payments in series then from a users perspective 20s or 40s feels the same - it's really slow and from a ux perspective shouldn't be behind a loading state - instead the payments should resolve in the ui 1 by 1.

[thebells1111]

This isn't an idea I'm against, but it only solves issue for wallet hosters changing their internal infrastructure. If a guest who appeared on multiple podcasts were to change his wallet from xxx@fountain.fm to xxx@getalby.com, the same issue of needing to update every feed that person appears in remains.

Probably a separate issue to open, but one possible solution is each person has their own personal RSS feed with their name, image, person:guid, and Lightning Address, and the podcast:value references the persons personal RSS feed. Instead of making a call to the lnurlp, a call is made to the persons feed to get their current address. Within their personal feed can be either a pubkey or lnurlp.

[Kolomona]

@thebells1111 Are you proposing something like a nip-05 spec for guests? example kolomona@libresults.com resolves to https://libreleaf.com/.well-known/nostr.json?name=kolomona

Forgive me but I don't see the issue here. If a podcast feed changes and a podping is issued then the hosts just update to the new rss feed with the new wallet infrastructure. This may take some time but it should sort itself out.

To me changing the type to lnurlp is preferable as it is a different type of payment system. The downside is only apps that support lnurlp will work. (which seems to me to be even a bigger challenge to overcome)

Having the node addresses in the rss seems to me to be more sovereign as the RSS is the source of truth pointing directly to the node receiving the btc. Less behind the scenes shenanigans can occur.

[thebells1111]

I'm suggesting something like a remoteItem that points to another feed, but the feed is a persons personal feed with all the info they want to surface in their own feed, which they choose to host however they see fit. If I decide to update my node, it's in my feed, so all another feed ever needs to know is the guid or url to reference my feed.

The issue is, if your show ever becomes big, and you are inteviewed on 20 different podcasts, your address is hardcoded into each feed. Now, if you change your address, you have to go to each podcast and request that they update your address in their feed. Using a lnurl instead of an address doesn't change having to contact every single podcast you've ever been a guest on to update your lnurl if you ever decide to use a different wallet host.

The lnurl works great if you stay with Fountain and Fountain changes your address info. The lnurl fails if you change from Fountain to Alby, because hardcoded in each of the 20 feeds you were interviewed in is kolomona@fountain.fm

[bumi]

imo identity is always an issue especially as long as we use domain names and people might not own the domain.
How would you solve the problem that this referenced URL is also not "owned" by the person and they can not migrate away from that one?

[Kolomona]

I see. This occurred to me back when splits were first introduced, I don't think remote item was even a thing then.

Remote item personal identity feeds seems like an idea worthy of exploration.

[daveajones]

What's prompting this concern @MerryOscar ? Is there a wallet provider moving things around in a way that they would lose their current pubkey? My understanding is that LND allows for importing a public key to the default wallet. I know larger infrastructure might use LDK or c-lightning but surely that functionality would also exist there.

Just trying to understand what prompted the immediate concern.

[bumi]

For us this is generally an issue not only because it prevents us from chaning our node infrastrucutre but it makes a redundant setup impossible.
When the node is offline (for whatever reason) there is no way to load balance the traffic to another node which makes it hard to have a redundant high availablity setup.

[MerryOscar]

There wasn't any specific concern it's just something I've been thinking about for a while as not ideal.

We do still have many value blocks that are pointed to our LNPay node despite us having moved most of our infrastructure over to zebedee. We are contacting them one by one which is not ideal.

As @bumi said redundancy is an issue - but I also feel it limits our flexibility and willingness to experiment with new ideas that involve podcasters or hosting companies adding value block info to their feeds.

[daveajones]

If we add a new type to the spec, all the apps need to be prepared for it and have some input first. I'll post on PIsocial and also discuss in the board room this week so we can get plenty of feedback.

[daveajones]

For clarity, we're talking about just keysend .well-known address lookup right? Not full lnurl-pay? Because full lnurl-pay with invoice generation and all that would be a disaster for most apps.

[MerryOscar]

great thanks @daveajones - and yep just the /.well-known/keysend - totally agree we need all the apps to have input - but figure it's best to do now before there are more of them! :)

[adamc199]

As @bumi said redundancy is an issue - but I also feel it limits our flexibility and willingness to experiment with new ideas that involve podcasters or hosting companies adding value block info to their feeds.<<

While custodial wallets are certainly important and an easy onboarding path, non-custodial solutions are not far off and all stakeholders must be taken into account, not just the biggest.

Perhaps you can detail the new ideas you are experimenting with so all parties can put their thinking caps on? There may be more than one way to solve your forward thinking ideas. Experimentation in this project has always been open.

[MerryOscar]

Perhaps you can detail the new ideas you are experimenting with so all parties can put their thinking caps on? There may be more than one way to solve your forward thinking ideas. Experimentation in this project has always been open.

@adamc199 the main example I'm thinking about is that we ask podcasters to give us a 1% split so we can show boosts from other apps in Fountain. Because this is a service that is not related to providing custodial user wallets - then we can be more flexible on how we run the infrastructure to support it. It would be great if we could make these kinds of infrastructure decisions without thinking in the back of our minds that it will be incredibly painful to change it.

--

While custodial wallets are certainly important and an easy onboarding path, non-custodial solutions are not far off and all stakeholders must be taken into account, not just the biggest.

Because this proposed change would be optional - I don't see how it would affect non-custodial solutions? Apps like Fountain would still support paying directly to a pubkey and non-custodial apps would still be able to lookup the pubkey via the Lightning Address?

[adamc199]

@adamc199 the main example I'm thinking about is that we ask podcasters to give us a 1% split so we can show boosts from other apps in Fountain. Because this is a service that is not related to providing custodial user wallets - then we can be more flexible on how we run the infrastructure to support it. It would be great if we could make these kinds of infrastructure decisions without thinking in the back of our minds that it will be incredibly painful to change it.

Got it.

Because this proposed change would be optional - I don't see how it would affect non-custodial solutions? Apps like Fountain would still support paying directly to a pubkey and non-custodial apps would still be able to lookup the pubkey via the Lightning Address?

Ah, I didn't understand it as optional. All good then, to be discussed in the boardroom!

[dhk2]

I would think implementing the lighting address in addition to the node address instead of replacing it makes more sense. If the payment to the node address fails, then lookup the keysend lightning address info for sending the payment.

1. This would be backward compatible.

2. It handles the high availability case @bumi brought up

3. It handles cases of temporary connection or liquidity issues for the node address

4. it handles the case of the node address going permanently offline

5. it only generates extra traffic if their is an issue with the provided node address

   <podcast:valueRecipient
   name="[name of recipient(string)]"
   type="[address type(string)]"
   address="[the receiving address(string)]"
   customKey="[optional key to pass(mixed)]"
   customValue="[optional value to pass(mixed)]"
   split="[share count(int)]"
   lnurlp="[lightning address]"
   fee=[true|false]
   />

[dhk2]

Shouldn't come into any conflict First the app should try the node address if present in the value split, if that fails or isn't present, grab the current node address by looking up the well known for the lnAddress and trying that.

If Alby changes their infrastructure after the RSS feed is created, the initial boost attempt with the invalid value will fail, and the lnAddress is used to get the current node address.

if (split.address) {
    if (sendBoost(split.address, boost)) return true
}
if (split.lnAddress){
    let address = lookUp(split.lnAddress)
    if (address && sendBoost(address, boost)) return true
    }
}
log.error(`Unable to boost "+split.name)
return false;

[joksas]

@MerryOscar @bumi can you please check if this is the process you had in mind. Are there any scenarios where you change the infrastructure, but the boost to the old address doesn't fail?

[bumi]

I would see it the other way around.
the lnaddress should be prioritized. So if this is available the data should be looked up from there and then be used to send the boost.

[MerryOscar]

yes I would also agree with bumi that the lookup should be prioritised

[ericpp]

I assume the type would determine which attributes are required/optional? I can think of three cases here:

Recipient only has a node pubkey: address required to send payment:

<podcast:valueRecipient type="node" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" ... />

Recipient only has an lnaddress: lnaddress required, but address optional?

<podcast:valueRecipient type="lnaddress" lnaddress="ericpp@getalby.com" ... />

Recipient has both an lnaddress and a pubkey: lnaddress required and address optionally specified

<podcast:valueRecipient type="lnaddress" lnaddress="ericpp@getalby.com" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" ... />

[daveajones]

@MerryOscar @bumi Can we call this something other than lnurlp since the lnurl people haven't ratified this type of address lookup? Maybe "keysendaddr" or something?

[daveajones]

Normally naming isn't a concern, but naming it that might cause implementers to make bad assumptions.

[ericpp]

I think this tag (and most of the tags in general) should be descriptive rather than prescriptive. This tag should be saying "this recipient has a lightning address" rather than "use /.well-known/lnurlp/user or /.well-known/keysend/user to look up this recipient's lightning address info". It should be the application's job to figure out the best way to send a payment to a lightning address.

[bumi]

Yes, you're right, we should call it something differently as it also is not lnurlp and ideally as @ericpp says it can be up to the application on how to do the transaction (even though afaik keysend is the only option right now)

what is with the lnaddress suggestion?

[dhk2]

PeerTube's latest build example value block

<podcast:valueRecipient type="lightning" method="keysend" suggested="0.00000005000">
<podcast:valueRecipient name="Podcast Index" type="node" split="75" address="03ae9f91a0cb8ff43840e3c322c4c61f019d8c1c3cea15a25cfc425ac605e61a4a"/>
<podcast:valueRecipient name="Matt Christiansen Media" type="node" split="5" lightning="mcduquesne@getalby.com" fee="true" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="ukPtJhg4rq1RaSdQlrYs"/>
<podcast:valueRecipient name="Brian of London (Hive and PodPing Dev)" type="node" split="10" lightning="brianoflondon@v4v.app" address="0266ad2656c7a19a219d37e82b280046660f4d7f3ae0c00b64a1629de4ea567668" customKey="818818" customValue="brianoflondon"/>
<podcast:valueRecipient name="Dave Jones (Pod Sage)" type="node" split="10" lightning="dave@getalby.com" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="t2vRy8BdZutknl3LYOSG"/>
</podcast:valueRecipient>

[jamescridland]

Podnews's latest build example value block - https://podnews.net/rss/

<podcast:value type="lightning" method="keysend" suggested="0.00000100000">
  <podcast:valueRecipient name="IPFS Podcasting" type="node" address="028eb5be336f7fdf2a4e40c57ff55d3d5d71277bb4197ea14957f756bff249e623" split="5"/>
  <podcast:valueRecipient name="Podnews" type="node" address="02b307fdad2e68d08ba5a59cfc8a0a7ec0ff375291e1082fa22a5524e68608c520" split="1"/>
  <podcast:valueRecipient name="Podnews at Alby" lightning="podnews@getalby.com" type="node" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="GSGsn63p5aqcbxadLSk1" split="87"/>
  <podcast:valueRecipient name="Podnews at Fountain" lightning="jamescridland@fountain.fm" type="node" address="03b6f613e88bd874177c28c6ad83b3baba43c4c656f56be1f8df84669556054b79" customKey="906608" customValue="011VUCMUGSgkOAK6Ls3Cj5" split="1"/>
  <podcast:valueRecipient name="Podcastindex.org" type="node" address="03ae9f91a0cb8ff43840e3c322c4c61f019d8c1c3cea15a25cfc425ac605e61a4a" fee="true" split="1"/>
  <podcast:valueRecipient name="reflex.livewire.io" type="node" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="x3VXZtbcfIBVLIUqzWKV" split="5" />
</podcast:value>

I think the reflex one is also an Alby address, so perhaps this is a "fun" test of a mixed version.

(If you're reading this within two hours of this message, it won't be live yet. But it will be at 0600 EST).

[MerryOscar]

So I think we're all agreed we should make this change - the last question is what the new lightning address attribute should be named?

• lightning="jamescridland@fountain.fm"
• lnaddress="jamescridland@fountain.fm"
• lnkeysend="jamescridland@fountain.fm"
• keysend="jamescridland@fountain.fm"

The last two I added as options because this is all relevant to keysend payments rather than the broader lightning / ln

My vote would probably just be to go with keysend= as it is both simple and specific and also matches the path in the actual lookup - https://fountain.fm/.well-known/keysend/jamescridland

[ericpp]

Aren't non-lightning address (i.e. pubkey) payments also sent through keysend? Would a keysend attribute here only refer to lightning address-based keysend payments and not pubkey-based keysend payments?

My concern with calling it keysend is that the term refers to two different things:

• Sending a keysend payment through the Lightning Network using a pubkey
• Resolving a lightning address to a pubkey through /.well-known/keysend

[francosolerio]

I absolutely don't agree the lookup should have priority, for serverless stacks this would mean making more network calls and worsening battery drain. 30 years of internet history teaches us that relying on web server configuration for cache expiration times is pure utopia.

[francosolerio]

At this time Alby APIs for keysend accept only "destination hex-string pubkey" + custom record.
https://guides.getalby.com/developer-guide/v/alby-wallet-api/reference/api-reference/payments

[daveajones]

@bumi @MoritzKa Will this be changed so that app devs can just supply the lightning address instead of having to make lookup calls on-device?

[bumi]

considering the goal is that any app/wallet can be used to send payments I don't think we should necessarily rely on the wallet to implement parts of the spec.
Even though there is no timeline for this Alby will provide more of such high-level APIs to make it easy and allow devs to simply provide a ln address to send boostagrams and payments.
But I think in the spec discussion this should not matter.

imo apps should do the lookup and decide on the caching locally. It should be more than enough if the player for example loads once per playing an episode this information. So I don't think that is a significant increase in network requests. at wich amount of requests would you be worried @francosolerio ?

[francosolerio]

@bumi It's really impossible to give numbers for things like this, the only viable strategy is the fewer requests the better. With streaming payments we already transformed an activity with zero impact on network activity (playing an episode that was previously downloaded), into some with a considerable amount of network activity. Consider also that there are shows with 10+ splits, and value time splits increases that too.
Also are errors returned for a wallet that was moved to a new address different than common "no route" errors?

[bumi]

Also are errors returned for a wallet that was moved to a new address different than common "no route" errors?
You mean if keysend details changed? Then there are no errors, the server returns the current keysend details.

Thinking again, if we don't have any issues during the transition phase I actually don't care what has priority.
Requests should be reduced, but I think loading the static payment data once per episode or day or something should be quick. And imo the advantages for the services providers/wallet outweighs those requests.

[daveajones]

I'm going to agree with @MerryOscar and say let's call the attribute keysend.

[dhk2]

Pod sage has spoken
latest build value block output:

<podcast:value type="lightning" method="keysend" suggested="0.00000005000">
<podcast:valueRecipient name="Podcast Index" type="node" split="75" address="03ae9f91a0cb8ff43840e3c322c4c61f019d8c1c3cea15a25cfc425ac605e61a4a"/>
<podcast:valueRecipient name="Matt Christiansen Media" type="node" split="5" keysend="mcduquesne@getalby.com" fee="true" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="ukPtJhg4rq1RaSdQlrYs"/>
<podcast:valueRecipient name="Brian of London (Hive and PodPing Dev)" type="node" split="10" keysend="brianoflondon@v4v.app" address="0266ad2656c7a19a219d37e82b280046660f4d7f3ae0c00b64a1629de4ea567668" customKey="818818" customValue="brianoflondon"/>
<podcast:valueRecipient name="Dave Jones (Pod Sage)" type="node" split="10" keysend="dave@getalby.com" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="t2vRy8BdZutknl3LYOSG"/>
</podcast:value>

[jamescridland]

https://podnews.net/rss now has

<podcast:value type="lightning" method="keysend" suggested="0.00000100000"> <podcast:valueRecipient name="IPFS Podcasting" type="node" address="028eb5be336f7fdf2a4e40c57ff55d3d5d71277bb4197ea14957f756bff249e623" split="5"/> <podcast:valueRecipient name="Podnews" type="node" address="02b307fdad2e68d08ba5a59cfc8a0a7ec0ff375291e1082fa22a5524e68608c520" split="1"/> <podcast:valueRecipient name="Podnews at Alby" keysend="podnews@getalby.com" type="node" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="GSGsn63p5aqcbxadLSk1" split="87"/> <podcast:valueRecipient name="Podnews at Fountain" keysend="jamescridland@fountain.fm" type="node" address="03b6f613e88bd874177c28c6ad83b3baba43c4c656f56be1f8df84669556054b79" customKey="906608" customValue="011VUCMUGSgkOAK6Ls3Cj5" split="1"/> <podcast:valueRecipient name="Podcastindex.org" type="node" address="03ae9f91a0cb8ff43840e3c322c4c61f019d8c1c3cea15a25cfc425ac605e61a4a" fee="true" split="1"/> <podcast:valueRecipient name="reflex.livewire.io" type="node" address="030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3" customKey="696969" customValue="x3VXZtbcfIBVLIUqzWKV" split="5" /> </podcast:value>

[blastshielddown]

@MerryOscar and @bumi suggest here that the address lookup should be prioritized over the address attribute. But looking at these examples, I think allowing the inclusion of both thekeysend and address attributes will make that prioritization less clear. It reads like each are valid (and it doesn't help that the keysend value can look like an lnurl address). I would suggest allowing either one or the other, but not both at the same time. I understand the fallback reasoning laid out by @dhk2 in that same thread but think this might be too heavy a lift for clients, especially when keysends do not fail immediately.

Also, does the method attribute in the parent value tag imply that the splits within a value block could not be a mix of keysend and lightning addresses? The way I'm reading this it looks like all the splits have to be either one or the other.

[dhk2]

Prioritizing the address is up to the individual apps, and not a choice i'd make. Working on implementing the client side now. Got it working for boosts so far, pretty straightforward. Method is keysend irregardless of which method you use to get the pubkey/customdata.

especially when keysends do not fail immediately.

Keysend returning failure for a non existent wallet is in the millisecond range for both webLN and the Alby API. My logging only goes to the nearest second and the attempt and response happen within the same second in testing.

[dhk2]

1 if address is available with pubkey , try that.
2. if it fails or if address isn't present and keysend field is, do a look up
3. if the returned json provides a different address, try that

most boosts, no lookup required, just 1 keysend transaction. if the first boost fails, a lookup and another keysend are required. This should be a tiny fraction of payments requiring 3 transactions

Compared to every transaction requiring lookup first then a keysend

average transactions 1.01 vs 2

[blastshielddown]

One request for the sake of clarity: the term "Lightning Address" strongly implies the LNURL static ids spec. I think there should be a clearer distinction made here that the addresses used are not lud16 addresses. I was confused by this in the proposal until recently. I would imagine others would be as well.

Edit: lud16 not lud06

[ericpp]

Is the /.well-known/keysend/<username> format documented somewhere?

[daveajones]

@MerryOscar Didn't you have this documented? If not, I can write it up somewhere.

[daveajones]

I'd really love to get this into the spec, but need @bumi or @MoritzKa to weigh in on whether the Alby API has a way to resolve these addresses during payment or if the clients will need to pre-resolve.

[daveajones]

Not to say that's a deal killer. We just need a clear path as we make this change.

[bumi]

As just mentioned above I think we should not rely on wallet/payment providers to implement parts of the spec and it should be independent.
I don't see a problem with the amount of network requests as clients can simply cache the data locally. They even could do some smart expiry and only update the date if a payment fails.
In a simple way it's one additional network requests per X. (could be for example per day or episode or such) is that really a problem?

[ericpp]

If we're mirroring LUD-16 for this keysend spec, it does say that the wallet is in charge of doing the lookup: https://github.com/lnurl/luds/blob/luds/16.md .

[bumi]

@kingonly you mentioned there are some bolt12 plans. (assuming this happens before it's all rainbows and unicorns)
do we need to consider something regarding bolt12?
That probably would just be a new type="bolt12" then?

[MerryOscar]

@kingonly how can we get the keysend address lookup format that both Fountain / Alby support added to the lnaddress spec - what's the path for this?

https://fountain.fm/.well-known/keysend/merryoscar
https://getalby.com/.well-known/keysend/bumi

[kingonly]

The path is to expand the lnaddress spec. For example, add an 'options' call that returns the available types as discussed here: https://t.me/lnurl/31603
Why not open an issue/PR in the lnaddress repo for keysend and options support? I think everyone wants it.

[MerryOscar]

ok great 👍

so something like:

https://fountain.fm/.well-known/pay/merryoscar/options -->

{
"status":"OK",
"options": [
   { 
     "type": "lnurlp",
     "url": "https://fountain.fm/.well-known/lnurlp/merryoscar"
   },
   {
     "type": "keysend",
     "url": "https://fountain.fm/.well-known/keysend/merryoscar"
   },
   {
     "type": "bolt12magic",
     "url": "oneday"
   }
 ]
}

in the podcasting 2.0 case we wouldn't have to worry about the /pay/user/options lookup - because we could assume all the addresses support keysend and hosting companies could do the validation.

@bumi @kingonly thoughts?

[bumi]

@kingonly @MerryOscar if I understand that correctly, that would invent something completely new? New for all wallet providers and new for all players.
Do you think that will happen?

[kingonly]

Isn't keysend via lnaddress also new? This is completely backward compatible. I just don't understand:

we could assume all the addresses support keysend

If that's the assumption (which isn't good long term imo), why add 'options'?

I think lnaddress will also support bolt12, so yes.

[thebells1111]

I'm confused as to why the apps would be expected to do a lookup for the lightning_address using the ln_urlp.
I understand why a wallet provider would want to be able to update their wallet structure without having to burden all of the feeds with changing the lightning_address in their feed. That makes perfect sense. But shouldn't the wallet provider be the one that is handling how the payments are processed?

If I'm using Fountain for my wallet, and I boost to a value block that has steven@getalby.com as the keysend, then why can't the Fountain wallet do the lookup for steven@getalby.com, then route the payment to the appropriate address.

@francosolerio has a concern about battery usage doing all of the lookups on the client side, and it's a valid one. Since this primarily benefits the wallet providers, it seems like the wallet providers doing the lookup on the server side would satisfy their desire to have the ln_urlp as a way to define an address in the value block, and satisfy the app devs that want to minimize the amount of network traffic and conserve battery life.

[bumi]

But shouldn't the wallet provider be the one that is handling how the payments are processed?

yes, but I think that is a implementation detail and depends on what wallet provider the sender is using and what it supports.

[thebells1111]

I guess I'm not following what the implementation details are. I assumed all wallet providers in the 2.0 space were using address, custom_key, custom_value, and we were using keysend. I thought using something like https://fountain.fm/.well-known/keysend/merryoscar would just make a request to that page, fetch the address and custom stuff, then send a keysend, so the wallet provider could make the request just prior to processing the payment.

[brianoflondon]

I'm working right now on my own implementation of the Alby Wallet API

https://guides.getalby.com/developer-guide/v/alby-wallet-api

I presume this is the way all the apps send payments right now:

Make multiple keysend payments in 1 request
POST
https://api.getalby.com/payments/keysend/multi

All that would need to happen would be for there to be an optional Lightning Address option in the Keysend payment body which if present would resolve at the server to whatever the result of the well-known lookup is.

From my point of view, as a provider of this Wallet service, I would easily be able to lookup at payment time and resolve a lightning address. I would not want to make the payment via LNURL though, only Keysend to the looked up address and customKey customValue pair.

[MerryOscar]

As @daveajones asked - I thought I'd try and provide a summary of where we're at on this:

Agreement on Issue:

I think everyone is in agreement that having an option to remove the pubkey from the podcast value block is a good idea because it's a burden on wallet providers in terms of migrating to new infrastructure. Fountain, Alby, Wavlake, ZEBEDEE all agree on this.

I think everyone is also agreed that a new optional field should be added to the <podcast:valueRecipient tag which will contain a keysend enabled lightning address, and which the apps would use to lookup the keysend pubkey.

Open Questions:

1. What should the new attribute be called?

Two options have been proposed:

1. keysend (keysend = merryoscar@fountain.fm) - this is specific to keysend and tells app developers that this is a keysend lightning address for which they can lookup the pubkey and customData via this unofficial keysend path that both Fountain and Alby support - https://fountain.fm/.well-known/keysend/merryoscar
2. lnaddress(lnaddress = merryoscar@fountain.fm) - this would be a more generic lighting address attribute which would make the attribute extensible for things like Bolt12. Apps + hosting companies could validate the supported features of a lightning address by looking up an options path - https://fountain.fm/.well-known/lnurlp/merryoscar/options (I've added this to Fountain as an example but Alby, Wavlake, ZEBEDEE etc would have to also support)

Personally since there is starting to be more talk about Bolt12 I agree with @kingonly that the second option with a generic lnaddress field would be better - but this does have a dependency on somehow getting this added to the lightning address spec.

2. Should apps or wallet api providers do the lookup?

Should wallet api providers allow just sending the lightning address in the api calls to save app developers from having to do this every time the user wants to make a payment?

In my view the wallet api providers probably should offer this as it's relatively trivial for them - but I don't think having wallet providers agree to do this should be a blocker on us adding the new attribute. If wallet API providers want to offer this they can and that might be something that influences app developers choice on which wallet provider to use.

---

Anyway hopefully that's a helpful summary - I think it would be great specifically if some people from the lnurl spec community could comment on this - please tag them if you know them @kingonly @bumi @andrerfneves

[daveajones]

I agree that lnaddress is the better route. Where is the "lightning address spec" located?

[MerryOscar]

@daveajones it's here - https://github.com/lnurl/luds

[daveajones]

Unfortunate that it's tied to the lnurl spec since those seem like distinct things to me. It would be nice to have some adoption there, but I don't feel it's a blocker to coming up with a format for a future use case.

[daveajones]

I'm going to write it up with the lnaddress attribute and we can just work on the syntax of the options file.

[brianoflondon]

Across the lighting world i've noticed that most apps deal with an address both with and without the lightning: prefix. My own app does that (if that prefix is there it strips it, if it isn't it just tries the call anyways).

Should we perhaps put that prefix in the field?

[jooray]

I don't think keysend is a good name, because keysend is actually what it is doing right now with the pubkey of node.

The keysend RPC command attempts to find a route to the given destination, and send the specified amount to it. Unlike the pay RPC command the keysend command does not require an invoice, instead it uses the destination node ID, and amount to find a route to the specified node.

Core Lightning documentation - but similar terminology is used in other Lightning implementations.

We are going to use LN Address, not keysend. The underlying mechanism after the address is resolved might be a keysend, but that does not differentiate it to "node" keysend, which we use right now.

So let's call it lnAddress, lightningAddr or something similar, which makes it actually different to "node" type (which is a keysend to the node).