Closed otech47 closed 1 year ago
Thanks for bringing this up. Since enable()
throws an exception when a user declines the prompt (like any other method in WebLN) I think we should change our implementation here to not return anything. I've prepared a PR for that.
However that might break some existing applications out there :thinking: Did you notice any other services that use those parameters?
Thanks for bringing this up. Since
enable()
throws an exception when a user declines the prompt (like any other method in WebLN) I think we should change our implementation here to not return anything. I've prepared a PR for that.However that might break some existing applications out there 🤔 Did you notice any other services that use those parameters?
i will do my best to hunt them down and help patch.. asking around here
going through bolt.fun for LN enabled apps and compiling a list of patches for any apps that would break
cant find source code for Kollider browser extension... I checked kollider-lite-app and it seems unaffected by this
tagging a few contributors maybe we can find out if @kolliderhq should patch too at least on the browser extension side...
@fl-y @the-kollider @mk-kollider
thank you @otech47. This is some old old thing (it got falsely added in the first commit even)
According to this spec the enable function has a void return type
However the webln object injected by Alby has an enable function that does not adhere to this spec so it seems some app devs have assumed that enable may return an object with
enabled: true
orisEnabled: true
Seems this creates confusion for WebLN providers since
enable()
could be implemented in inconsistent waysCross-posting this in more than one place (https://github.com/BoltzExchange/boltz-web-app/issues/229) since I'm not sure what the best approach to fix this is... implementations are either building on an outdated spec or they are not compliant with a spec that cannot be enforced 🤔
any suggestions on what to do here?