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.

Reply to this note

Please Login to reply.

Discussion

Yeah, definitely interested in the normie compromise at this moment. Is the key recoverable for migration to self hosting?

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.

Sounds great to me, how are you planning to productize it? Libraries and and API?

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.

Very cool, sounds like an interesting project fueled by some very specific experience in the industry. I just followed you, and I'll let you know if I want to dive more deeply into the passkeys approach (email based is getting increasingly painful as I flesh the spec out, but I'm still going to see if I an complete it)

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.

Ah that actually makes way more sense, you can do a lot with a JWT. I had read quite a while ago that passkeys weren't the way forward, but I've never done my homework on it

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.

I'd zap you if I could. I was just thinking about how we need more practical bridges for normies