The specs for the lnaddress are really confusing.

[thebells1111]

Consider this value block.

<podcast:value type="lightning" method="keysend" suggested="0.00000005000">
    <podcast:valueRecipient name="Podping" type="node" 
        address="0266ad2656c7a19a219d37e82b280046660f4d7f3ae0c00b64a1629de4ea567668" customKey="818818" 
        customValue="podping" split="2"
    />
    <podcast:valueRecipient name="Strike Test" type="lnaddress" address="[email protected]" split="2"/>
</podcast:value>

Two different types for the recipient. Okay, this seems legit, but lnaddress may only return lnulp for it's option. So, my concern is, we have in podcast:value a method of keysend and an valueRecipient with a type of lnaddress that may only return lnurlp. Seems a little bit confusing to me.

Also, for a 'type' of 'lnaddress', my understanding is the app uses that to convert to the uri https://strike.me/.well-known/lnurlp/adam_txfzikfutr/options, which should return a list of payment options.

However, https://strike.me/.well-known/lnurlp/adam_txfzikfutr/options returns a 404. So, the app would do what the spec says and get a 404, which I guess means their is no option, so if an lnaddress is present try the option first, and if their isn't an option fall back to something like this? https://strike.me/.well-known/lnurlp/adam_txfzikfutr. More confusion.

And in this particular case, without the options this address is actually an lnurlp, so the type would more approriately be lnurlp instead of lnaddress, so we have a method of keysend with a lnurlp as the type for the valueRecipient, but it's typed as a lnaddress. How are hosts suppose to figure out for the podcasters (because we know the podcaster won't know) if [email protected] is an lnaddress to return an option, or lnurlp? And how are apps suppose to know if it's an lnaddress so fetch the option, or an lnurlp so fetch the callback. I mean we all sort of know what we're doing, and this is confusing.

We're asking the apps to transition over in short order, so we should really try to clarify what exactly the hosts need to do to mitigate the changes and how the apps are expected to understand and implement the new lnaddress and differentiate between lnaddress and lnurlp

[ericpp]

I wonder if anyone even checks for method="keysend"? It should be removed from the spec and we should just assume anything with type="node" means keysend.

An lnaddress using the options file can return lnurlp and/or keysend information. Unfortunately, like you discovered, the options file isn't actually part of the LNURL spec. It's something that PC20 created in hopes that it would be merged into the LNURL spec at some point.

The choices so far for knowing if there's an options well-known file is to either maintain a whitelist (like Oscar is doing with Podpay) or check the options file first and fallback to the standard lnurlp file. It would be nice if the spec could say which one to check rather than having to guess.