> It's just really easy to use and easier authentication than any scheme I've worked with before.
But this is literally the same as just "connecting my pgp public key" to some authentication service that manages this. This is no more convenient than the stuff that happens the first time I ssh into a service.
And surprise, passwords crushed this and virtually nobody uses this for consumer applications.
> but most apps using this approach are going to natively interact with the blockchain, whether it's a financial app, gaming app, whatever.
Now the story is very different. You led with "a good use of web3 technologies is auth." Now you say "yeah, auth isn't any better but you might as well do it this way given that your web3 service is using ETH for whatever other hypothetical thing."
There are some that are direct. Cryptocurrencies do provide novel features for users. Whether those features are desirable or beneficial enough to justify the huge price of these tokens (and further growth) is something people disagree on. I also think that ETH does provide novel capabilities with distributed computation. But again, the cost is enormous. This makes it hard for many people to buy the idea that the whole web will transition to this model.
For auth though, I agree with you. The only thing new here is that a lot of people have public/private key pairs that never had them before. Maybe this means that adoption is easier but I'm skeptical that this is a meaningful difference over existing signature-based authentication systems.
Fair enough, I did use a circular argument example unintentionally, my bad. But yeah, I agree with you - I wouldn't use wallets for auth really unless I'm making a web3 app. You *can* use this authentication scheme for other sites if you wanted, but you're right in the fact that the question is "Why?" Your target audience isn't going to have a wallet, why use it for authentication? Unless we reach the point where more browsers have native wallets built in, but even then, I'm not sure I'd want to do it for a traditional web app. Even though I find it cool personally that I can auth in this manner, if the target audience for the service has no idea how to use it, then it's not a good idea.
And I just wanted to say that I personally don't think the whole web will transition to this model, despite me working in the field. The current web isn't really going anywhere, I don't really have pipedreams of everything under the sun getting decentralized, but what I see is the potential for creators to make something cool and it's a neat emerging field to explore as a developer.
And one more time, just because I mentioned it in the first post, ETH is ridiculously expensive right now, but there are alternatives. It's awful for anything other than pretty minor distributed computing currently. There are some really neat projects out there that may be able to get around this by using off-chain distributed computing on ETH, there is a product that I've been meaning to test out as a dev but haven't had the chance yet as I've been focusing in learning the Solana ecosystem for the past few months instead of Ethereum. But it's an emerging space and I think we'll continue to see a lot of innovations over the years; even in the past 2 years we've seen a huge influx of innovative projects.
> Now you say "yeah, auth isn't any better but you might as well do it this way given that your web3 service is using ETH for whatever other hypothetical thing."
Edit - And I did want to reply to this actually. The value I find in this as an authentication method is it does make it incredibly easy as a developer to integrate. I've worked with SSO before that's also super easy as well, however that relies on centralization of trust in an entity such as Google. Even if it is just minor, I do like the idea of being able to provide authentication that:
1. I don't need to store passwords or handle them whatsoever
2. I don't need to rely on an external arbiter of truth such as google / facebook
I have used webauthn a bit, not as a dev, but as an end user and it's really awesome. I would imagine it's not terribly difficult to integrate and would satisfy both of those above desires for my own projects. But yes, in crypto world, might as well use the keypairs everyone already has.
But this is literally the same as just "connecting my pgp public key" to some authentication service that manages this. This is no more convenient than the stuff that happens the first time I ssh into a service.
And surprise, passwords crushed this and virtually nobody uses this for consumer applications.
> but most apps using this approach are going to natively interact with the blockchain, whether it's a financial app, gaming app, whatever.
Now the story is very different. You led with "a good use of web3 technologies is auth." Now you say "yeah, auth isn't any better but you might as well do it this way given that your web3 service is using ETH for whatever other hypothetical thing."