Idea: Create a reference design for a "Login with bitcoin" feature #732
Comments
|
Should this topic be more generalized to various forms identity, including decentralized identity approaches? |
|
I am not sure. I assume general identify primarily focuses on authentication only, while logging in with Lightning has expectations of wallet access and simple payment handling. Those two aspects could be also be discussed separately. Are there specific other approaches you are thinking about? |
|
Maybe not until a bit later but there is this https://www.coindesk.com/business/2021/11/08/microsofts-decentralized-identity-head-leaves-to-join-square/ |
The whole DIDs (Digital Identity) space is really interesting. I learned about it somewhat when my meetup group studied the TBDex whitepaper. In bitcoin, we use "wallet" as a skeumorphic description for something that holds your bitcoin. Well, a real wallet holds more than just cash, it also holds your driver's license, insurance cards, and other forms of ID. So you can imagine a piece of wallet software that acts as a container for DIDs that conform to the W3C DID spec. It's not bitcoin specifically, but interesting stuff. |
|
We could start by adding a note to this section in the activity page about this: https://bitcoin.design/guide/daily-spending-wallet/activity/#beyond-transactions. Unsure if this would be the place to include designs on this concept though. I wouldn't make this a top level reference design though, I think they should be reserved for larger concepts (spending / savings wallet etc). |
|
I really do like the idea of a sort of reference design/library, even one that is started in this sense from a place of need, or rather something that was requested by the general audience. I do think that it is useful for UX designers to have a quick reference library which they know they can refer to. Something which I am sure you might have already come across is this website, which shows UX reference designs across various industries, when searching for wallet, there are only reference designs for traditional bitcoin wallets. I think its is very interesting and educational to see how for example the onboarding process is done by Coinbase. Then would imagine that if a UX designer is building a lighting wallet from scratch that they too would find it useful to see baseline reference designs from larger players who have been in the market so that they can then adopt the best UX practices of a particular screenstate (for example) when they are designing. |
|
I'm trying to address some of the points you put up for discussion and share what I've learnt during the last weeks. I feel like the whole terminology is a bit confusing, so I'll start by trying to make some things more clear: Terminology & Limits of lnurl-authWebLN lnurl-auth (https://github.com/fiatjaf/lnurl-rfc/blob/luds/04.md) There is just one login protocol behind all methods:
Your identity is a 66-character random string, different for each website. This is the only information service providers can use to link data to it (email-address, orders, etc). DiscussionsChange accounts Considerations
👆 This is indeed an interesting point. Currently any website could check |
GBKS
changed the title
I think I quiet understand the difference between Webln and lnurl. Thanks for this
|
|
I like the idea of a the feature and how It can simplify the authentication process. This problem was a hard one for me in during the boltfun Hackathon. Apart from the login process would a sign up process be ok for new users? |
|
Here's a new video with the latest iteration. |
|
Great video, though for a simple sign in (not payments) users can also authenticate to a service without LNURL or WebLN. Users can just sign a message which identifies them, these standards aren't always necessary. See https://amboss.space/ login for an example. Also if you haven't the Synonym's Slashtags demo goes into this type of UX. A cool feature in the Slashtags demo is you can actually use new key pairs (derived from a master I presume) for each site. This would give some added privacy as each service you sign up to would be saving slightly different data kept on you. |
|
You could also use any other encryption mechanism to do this (don't even need bitcoin), but the idea here is to use the available/emerging standards to build rich experiences. Authentication is the starting point and from there we can explore both what is possible with current options, and what we may want to make possible as the tech evolves. |
|
I set up a draft PR for this is pretty narrowly focused on web applications and lightning wallets. Figured I start with something specific that works today, and we can expand as needed. The page is a pretty general introduction. Before digging deeper, I'd like to get feedback on what information would be useful to have. Here's the preview. |
There were several conversations about this feature during the Shock the Web hackathon, and pretty much every Lightning application will have to figure this out. My personal opinion is that most existing Lightning apps also handle this very poorly. We could come up a reference design to help reduce this duplication of work. A second outcome could be that someone developers a drop-in library for this design. Logging in is the least interesting part of an application and should be smooth and easy.
This should cover different technical options (webLN, LNURL-auth...) and various states (user logged out/in, support yes/no, wallet detected yes/no), along with various privacy and security considerations, as well as best practices like allowing users to switch an account to a new wallet.
Should also debate what to call this feature. Do we want to use the term "Lightning" in this prominent way, despite trying hard to minimize it elsewhere?
The text was updated successfully, but these errors were encountered: