[bo1024]

This is very interesting and I agree about all the upsides of desktop apps. However, in web3, people’s blockchain credentials could be used to interact with many different websites. This seems hard to reproduce with desktop-based apps, right?

[jeroenhd]

I imagine this should be possible with a very small connector addon that calls out to a secure wallet running on the desktop as a native application.

This requires some careful consideration to prevent phishing and other nastiness, but a native application could use native window prompts and techniques such as Windows Hello/TouchID as an authentication technique that's hard to spoof.

The complexity and risks are still there but you can hide away the important secrets much better with a native application than a browser extension ever could. It would also allow access to better sources of randomness and all kinds of sandboxing and exploit protection that aren't available with WASM.

[nailer]

Crypto wallets also have access to the secure enclave via webauthn. I develop a new wallet (Portal) which will have webauthn but I know Glow uses Windows Hello right now.

[lxgr]

Yes, but WebAuthN can't be used for arbitrary signatures (which would be required to support various cryptocurrencies/blockchains), nor can it be used to decrypt data or derive keys, which would allow using it as an unlocking key for some hybrid solution.

I'm happy to be proven wrong if you've found a way around these fundamental constraints!

[jeroenhd]

Interesting! Does the WebAuthn API provide enough of a cryptographic basis to fulfill the needs of cryptocurrency wallets?

I know it works through public/private key sharing but I wasn't aware that it provides such direct primitives.

[lxgr]

It doesn't, at least not for generic/unmodified cryptographic applications.

WebAuthN signatures are of a very specific challenge/response format [1] that applications need to explicitly support. For example, SSH had to add new key and signature formats [2] to support it.

Theoretically, a blockchain/cryptocurrency application could adopt the WebAuthN signature format as its canonical or an alternative signature format, but I'm not aware of any popular one having done so.

[1] https://developers.yubico.com/WebAuthn/Concepts/Using_WebAut...

[2] https://github.com/openssh/openssh-portable/blob/master/PROT...

[jeroenhd]

Thank you for explaining!

[aww_dang]

NEAR Protocol is interesting in this regard. Wallet users opt-in to create separate key pairs for each application. Key pairs are limited to specific contract addresses, function calls and gas limitations.

The traditional Web3 model is too open to abuse. It is as if they took the old "allow this Java applet outside of the sandbox? y/n " dialog and added banking.

[mike_hearn]

Browser makers don't seem to really want people interacting with non-web stuff from the web, or extending web capabilities with desktop apps, as that reduces your dependence on them. Still, there are some ways to do it. Firstly, the much more common need is to log in to SSO services, not act as an auth provider. OAuth is kind of messy but can be done and Conveyor makes it easy to register URL handlers, there's a demo of how to package the GitHub Desktop electron app here [1] which uses "Sign in with GitHub". One feature we've considered adding is doing "Sign in with ..." for you, so you don't need to use OAuth libs, your app starts and there's a logged in token in an env var already.

To extend the web from a desktop app there are a few ways to do it. Chrome extensions offer native messaging [2]. By pairing a desktop app with an extension you can have the minimal logic needed in the extension to bridge between your app and the page. But you have to get the user to install the extension manually, as Chrome will try to block apps doing it for you.

Another way for credentials specifically is to use SSL client certificates. They were designed specifically to let you log in to services with cryptographic keys. There's a discussion of the extinct <keygen> tag running elsewhere on HN right now. The app can generate a client certificate, get it signed by some authority, and install it into the user's key store. Now browsers should use it automatically when challenged by a server (except maybe Firefox?). You have to pay attention to how it's used to avoid bad browser UX, e.g. you'd have to use an XMLHttpRequest to ensure you control error handling if the cert is missing. But this is one way to make phishing harder, for example (there is no password for the user to type in).

Another way is to use loopback connections, but that's not ideal.

Ultimately, yes, the web is controlled by the Chrome team and they want you to only write Chrome apps. If you name your project "web3" you have to accept that it's kind of meaningless because you're not Chrome so your views and ideas don't matter, in the end. That's why it never made sense to me and I didn't work on it. In the early days it made a bit more sense because the Ethereum guys tried to make a custom browser called Mist using Electron, but they gave up and did a talk/blog post on why they burned out on it [3].

In the end I concluded the web just isn't a good proving ground for experimental or new ideas.

[1] https://hydraulic.software/blog/8-packaging-electron-apps.ht...

[2] https://developer.chrome.com/docs/extensions/mv3/nativeMessa...

[3] https://avsa.medium.com/sunsetting-mist-da21c8e943d2

[bo1024]

Thanks, very interesting.