Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Permit multiple URIs for LndHub server #292

Open
HamishMacEwan opened this issue Sep 11, 2021 · 3 comments
Open

Feature Request: Permit multiple URIs for LndHub server #292

HamishMacEwan opened this issue Sep 11, 2021 · 3 comments

Comments

@HamishMacEwan
Copy link

HamishMacEwan commented Sep 11, 2021

Presently an LndHub server may appear at different addresses, but only one fixed URI is supported per Card/Account, and editing is not permitted.

Every node operator who is using LndHub server, or LNbits with LndHub extension has some form of local and remote addressing but can't use both simultaneously with Blue Wallet.

An LndHub server may have at least four addresses (private IP, public IP, domain.tld and v3.onion) and BW won't allow more than one account that has the same credentials despite a different address.

e.g.

lndhub://admin:c9acredactedbb89@https://domain.tld:50011/lndhub/ext/

lndhub://admin:c9acredactedbb89@https://torv3.onion:5001/lndhub/ext/

and so on for 192.168.1.x, and public IPv4 & IPv6

All work, but only one at a time is permitted by BW.

There's plenty of other data to ensure the accessed card/account is valid, both by the client and the server.

https://github.com/BlueWallet/LndHub/blob/master/doc/Send-requirements.md#explaining-oauth2-mechanism

It isn't useful or necessary to deny additional card/account combinations with different URI for the LndHub service where those credentials are accepted.

One solution would be for Blue Wallet to accept the same credentials with a different URI is valid for importation. Or to allow duplication of an existing card with a different URI.

A more comprehensive solution would be to define LndHub services separately with a collection of URIs that all reach the same server. If one is enough, that's no change from the current structure. But where there are multiple connections available they could be provided and Blue Wallet could either offer a user selection drop down menu, or automatically determine which are available, on the fly.

When creating a card/account, the LndHub service definition would import or at least offer all URIs to the user for selection.

My thanks to ramp up for the discussion (starting here: https://t.me/bluewallet/57357) and suggestion:

so a suggested feature would be to in BlueWallet Client have a list of connection endpoints in dropdown? meny that preferably auto rotates in priority order, until connected ?

make a issue at github as feature request and add a bounty to it ?

@xraid_telegram @xraid

Happy to get an estimate of what this feature would deserve as a bounty.

@Overtorment
Copy link
Member

if I got this correctly, its a matter of simply adjusting BW to account for uris in backup string, so same credentials but on different servers would be uniq and not throw "wallet already exists" error
if that's so that is quite a simple fix

@HamishMacEwan
Copy link
Author

HamishMacEwan commented Sep 14, 2021

Yes, the more elaborate solution is appealing because it seems I will soon have another address, somewhere in I2P, but it would be sufficient the way you describe the simple fix.

I guess with lnd and Tor's onion routing and now I2P, the transport and security burden can be spread around and public key addresses mean private keys sign verifiable claims about the node that holds it. No need for certs, and once the onion routes are up, dns can be built-in.

@Overtorment
Copy link
Member

actually, cannot reproduce.
i import same wallet two times (lndhub://aaa:[email protected] and lndhub://aaa:[email protected]) and everything works, they get imported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants