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
I've seen a few applications are hard-coding the phrase "Joule" around WebLN usage. While I'm flattered to see that, I'd like to avoid a MetaMask / Band-AID / Kleenex situation.
The way Web3 providers in the Ethereum world have traditionally been identified is the all-too-janky way of checking the class's constructor.name. To prevent that from happening here, it might be nice if WebLN providers could optionally provide a providerType or providerName property that identifies it for UI usage. This would allow UIs to do something to the tune of
return(<button>Make invoice with {webln.providerName||'WebLN'}</button>);
Any concern about fingerprinting or de-anonymizing could be fixed by either omitting the property, or by using the most common provider's name to hide your users (ala Brave avoiding detection by disguising itself as Chrome.)
The text was updated successfully, but these errors were encountered:
I've seen a few applications are hard-coding the phrase "Joule" around WebLN usage. While I'm flattered to see that, I'd like to avoid a MetaMask / Band-AID / Kleenex situation.
The way Web3 providers in the Ethereum world have traditionally been identified is the all-too-janky way of checking the class's
constructor.name
. To prevent that from happening here, it might be nice if WebLN providers could optionally provide aproviderType
orproviderName
property that identifies it for UI usage. This would allow UIs to do something to the tune ofAny concern about fingerprinting or de-anonymizing could be fixed by either omitting the property, or by using the most common provider's name to hide your users (ala Brave avoiding detection by disguising itself as Chrome.)
The text was updated successfully, but these errors were encountered: