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

Method for opening a channel #2

Open
wbobeirne opened this issue Nov 2, 2018 · 5 comments
Open

Method for opening a channel #2

wbobeirne opened this issue Nov 2, 2018 · 5 comments

Comments

@wbobeirne
Copy link
Member

wbobeirne commented Nov 2, 2018

Proposal

Add a new method to the WebLNProvider called openChannel that prompts the user to open a channel with a node. If they already had a channel open, the promise should resolve with the channel data immediately, without prompting the user.

function openChannel(pubkey: string, opts?: OpenChannelOptions): Promise<Channel>;

interface OpenChannelOptions {
  minimum?: string; // Minimum number of satoshis to open the channel with. UI only, should be enforced with node configuration.
  maximum?: string; // Maximum number of satoshis they should be allowed to open a channel with.UI only, should be enforced with node configuration.
  private?: boolean; // Whether or not the channel should be private. If not set, the user can select.
}

interface Channel {
  channelId: string;
  channelPoint: string;
  active: boolean;
  private: boolean;
  capacity: string;
  localBalance: string;
  remoteBalance: string;
}

Questions

  • Should this be an explicit call, or should we expect that the future of autopiloting channels would make this obsolete?
  • Are there any other options a site would want to provide for the request?
@Kixunil
Copy link

Kixunil commented Dec 27, 2018

I think the address of the node is needed as well, not just pubkey.

Further, I have another idea: method ensureRoutable(amount: string, pubkey: string, address:string) that attempts to find a route for amount satoshis to pubkey and if it fails, it opens a dialog suggesting opening a channel. This is probably better than making direct channels every time.

@wbobeirne
Copy link
Member Author

wbobeirne commented Dec 27, 2018

You're totally right about needing the address, thanks for that note.

My hope would be that that kind of logic would all be handled by the WebLN provider client. So you try to sendPayment, the client checks the route, and if it's not available, suggests alternatives (e.g. open a channel with them, or a large node with capacity, etc.) I don't think that apps that interface with WebLN should need to have too much logic around handling the quirks of the Lightning Network.

My thought of the purpose of a channel opening method would be more for the sake of opening a channel, not as a means to the end of making a payment. For instance I've seen some apps offer to open a channel back to you if you open one with them, or you could use it as a form of membership to an app (e.g. members must have a channel of X capacity to use a site.)

@Kixunil
Copy link

Kixunil commented Dec 28, 2018

I should have described my use case idea... It might happen that a visitor of a website doesn't want to wait for payment. E.g. if the workflow is 1. open the website, 2. do something for 30 minutes, pay with LN (plausible in case of e-shops, when you are searching for and selecting products to buy). If one starts opening the channel sooner, he might avoid waiting later.

I'm not saying this is sure thing, nor do I develop anything that would need it. Just throwing this idea here.

@juscamarena
Copy link

How about a method to connect out to a peer another node?

Would simplify channel opening services to fall back to using webln for this that say don't support our thor service with lnurl

@wbobeirne
Copy link
Member Author

That's definitely a good idea, and should be quite easy to implement.

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

4 participants
@juscamarena @wbobeirne @Kixunil and others