joeruelle / Joe Ruelle is on Nostr

Working on SSO for nostr for isolated B2B deployments

Last Notes

2026-01-21 06:31:03

One of the many scratch your chin moments when working with enterprises that have PQC requirements (which is many these days) is when you realise there isn't a simple, drop-in Diffie-Hellman analogue for the post-quantum world. We’ve spent decades building things around the DH handshake, but the PQC world is dominated by KEMs, and will likely stay that way for a good while since all the DH analogues we've thought up so far are all pretty wobbly. So it's not just a swap of algorithms, it's a pretty considerable shift in how we handle design and function.

2025-12-20 11:00:40

- reply

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

2025-12-16 23:09:37

- reply

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

2025-12-15 11:39:22

- reply

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.

2025-12-11 06:39:26

- reply

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.

2025-12-09 19:58:52

- reply

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.

2025-12-09 19:27:28

- reply

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.

2025-12-09 19:10:05

- reply

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.

2025-12-09 18:07:29

- reply

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.

2025-12-09 12:18:58

- reply

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.)

2025-12-09 08:28:45

- reply

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

2025-12-09 05:37:48

Anyone else working on SSO via OIDC?