You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To simplify auth implementations for JS-centric clients, it would make sense for WebLN to have an auth() method that follows the same spec as LNURL's LUD-04, but have the back-and-forth happen entirely on the client via JS rather than requiring a server-side component be implemented using long polling or websockets. This would hopefully make for a much easier implementation.
The implementation would look something like this, matching LUD-04:
And an implementation would look something like this:
import{requestProvider}from"webln"asyncfunctionregister(username: string){// Initiailize WebLNconstwebln=awaitrequestProvider();awaitwebln.enable();// Auth with WebLNconstk1=awaitgenerateChallengeHex();// Your custom implementation hereconst{ sig, key }=awaitwebln.auth(k1,"register");// Send auth information to your backendfetch("/api/register",{method: "POST",body: JSON.stringify({
k1,
sig,
key,
username,}),})}
I have not personally implemented an LNURL auth flow end to end, so I'd love to hear from folks who have on if there are any other considerations we could add to the WebLN implementation that would improve the developer experience.
The text was updated successfully, but these errors were encountered:
To simplify auth implementations for JS-centric clients, it would make sense for WebLN to have an
auth()
method that follows the same spec as LNURL'sLUD-04
, but have the back-and-forth happen entirely on the client via JS rather than requiring a server-side component be implemented using long polling or websockets. This would hopefully make for a much easier implementation.The implementation would look something like this, matching LUD-04:
And an implementation would look something like this:
I have not personally implemented an LNURL auth flow end to end, so I'd love to hear from folks who have on if there are any other considerations we could add to the WebLN implementation that would improve the developer experience.
The text was updated successfully, but these errors were encountered: