In Moulin Rouge they said it was love. What happened?

Great read. I've got a small team working on this exact thing. Feeling a little less lonely now.

There's a school of thought that says if your website needs a chrome extension at all then as far as beginner users go you've already lost.

Yes, not the way forward IMO. Passkeys are just private keys that sign challenges from within the secure enclave on your iOS device, or from keychain, a TPM, Yubikey, even cross-platform third-party password managers. And with specific protocol scaffolding around them (WebAuthn/FIDO2).

Often when people say they’re doing something with passkeys for nostr it’s not actual passkey passkeys (not WebAuthn/FIDO2), it’s more like “passkey-inspired design". Because passkeys themselves are too limited.

Sure happy to chat. Just to be clear passkeys we concluded are a dead end (as in FIDO passkeys, what you use with Touch ID, etc.). They've no execution space, and curve issues too. It's JWTs which are the auth vehicle in the world of SSO and social sign in. A lot of things get confused between JWTs, FIDO passkeys, on-device enclaves (like for iOS), cloud enclaves, chip enclaves (intel TDX), etc.

We're doing this with frontline workers in Southeast Asia in mind. Nostr as it happens is a very good parts bin for communications tools for frontline workers (factory workers, drivers, hospitality workers, etc.) You can put together something Nostr-based that is much more attractive to the enterprise IT team than are the frontline licenses from Microsoft 365 or Google Workspace. But these are isolated, centralised deployments, not relying on any of the decentralisation aspects of Nostr, more the raw simplicity, also zaps are a good way to increase adoption (the big problem for all these companies is adoption, it's *always* adoption.)

Then it's just knocking on doors and old-fashioned B2B sales.

For a Nostr client in the wild this would be a pretty heavy technical lift, and also the question of how to cover infra costs without B2B revenue to offset (Nitro enclaves and zk-proving servers not so cheap). You can't really ask users themselves to pay to sign in with Google.

Yes, but we're doing that with a smart contract, again tied to the Google (or other) sign in. So a user can pull out their key if and when they're ready, and in such a way that the key can't be intercepted by a malicious backend. There are zk proofs in the mix also. The zk and smart contract stuff is also all abstracted away for the end user, for them it's just a request and delivery. (They can look under the hood if they really want, or in our case the corporate IT team can.)

So yeah, not only Google (and Auth0, Okta, etc.) but also AWS, and also another chain for the smart contract and zkproof stuff. Guess you can say it's a mix that's highly antithetical to the OG Nostr narrative, but there are only so many ways to get to that kind of a user experience, and in the end the user can be left with their key in hand.

We're doing pure social sign in (Sign in with Google) or else SSO (sign in with your company-issued corp account), in such a way that the Nostr keypair is abstracted away entirely, so from a user perspective it's no different to signing in to anything else, you don't have to ever hear the word "key".

In the end what you get are keys that only the owner of the Google (or Auth0 or whatever) account can command, but that are essentially beyond the event horizon of an enclave (enclaves have that execution space which Passkeys, Yubikeys, etc., do not) and all this hidden away from the user. It's more for B2B settings.

If you're interested in ways that don't involve big tech then this wouldn't be very helpful I'm afraid. But if you're looking for normie-friendly compromises that do use big tech then happy to jump on a call or a chat group if there is one for such things.

Gotcha. I saw below you said the passcode was optional, just wanted to make sure you were aware `sub` is global. User signs in to my app after yours, I get the same `sub`. (Apple is pairwise pseudonymous though.)

Hi, also working on this but different angle. What are you pulling from the JWT for Google?

Anyone else working on SSO via OIDC?