lnaddress don't work with onion domains

[elliedev80]

Describe the bug

ln addresses with onion domains are wrongly forced on https:// instead of http:// this cause wrong lnurl call

for instance:

user@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion

got lnurl call wrongly at

https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/.well-known/lnurlp/user

instead of

http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/.well-known/lnurlp/user

onion protocol doesn't need https encryption since it is already handle by onion protocol

at zeus this seems handled by utils/handleAnything.ts

const [username, domain] = value.split('@'); const url = https://${domain}/.well-known/lnurlp/${username.toLowerCase()};

this could be fixed for example:

    const [username, domain] = value.split('@');
    let url;
    if (domain.includes('.onion')) {
      url = `http://${domain}/.well-known/lnurlp/${username.toLowerCase()}`;
    }else{
      url = `https://${domain}/.well-known/lnurlp/${username.toLowerCase()}`;
    }

Reproduce

Reproduce the bug step by step.

• add lnaddress contact with onion address . ex. user1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion
• send a payment to such address

traffic never reach the lnurl service since it is fowarded to the wrong port : 443 instead of 80 https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/.well-known/lnurlp/user1

ZEUS version

v0.9.0

Node interface

LND (REST)

Network

Tor

Device

pixel7

Device operating system

graphene os

Log output

NA 
traffic never reach the server

[kaloudis]

Why did you close your PR with the fix?

[elliedev80]

here the code with the bug

https://github.com/ZeusLN/zeus/blob/master/utils/handleAnything.ts#L390-L394

lnurl on onion address exists and should be used .. here an implementation for iinstance https://blog.btcpayserver.org/btcpay-server-1-3-0/

[elliedev80]

Why did you close your PR with the fix?

unfortunately I wasn't able to create a test environment and your PR needs (very good job :) ) a lot of verifications :)

it should be very easy to fix

[elliedev80]

the correct behavior is also described at lnurl specs

https://github.com/lnurl/luds/blob/luds/16.md