joule-labs / webln

Spec and client library for WebLN apps and providers
244 stars 28 forks source link

Method for opening a channel #2

Open wbobeirne opened 5 years ago

wbobeirne commented 5 years ago

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

Kixunil commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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