-
Notifications
You must be signed in to change notification settings - Fork 33
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
feat: add webln provider config #172
Conversation
Updated dependencies detected. Learn more about Socket for GitHub ↗︎
|
await nwc.initNWC({ | ||
...(providerConfig?.nwc?.authorizationUrlOptions || {}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean we need to define all the potential provider config options here in BC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, they're all optional and it just defaults to an empty object
@@ -0,0 +1,7 @@ | |||
import {types} from '@getalby/sdk'; | |||
|
|||
export type WebLNProviderConfig = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this be generic?
These are options that a developer passes to an underlaying library. why does BC need to know about the potential options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it can to some extent, but we still need to know how to pass it - for example the NWC one if very specific right now (I don't know to do it generically yet, maybe we wait for a usecase?)
@bumi maybe what request methods could be used could eventually be passed to webln somehow. Like in |
No description provided.