Cool. I have a (poor man’s) “Login with Nostr” prototype for Ruby using cookies for sessions.

Why does this matter? You can log into websites without sharing your private key, while still proving you have access to it. Impersonation is not possible.

Most Nostr sites today just load your pubkey and then ask to sign posts as you publish them - that’s fine too. The goal here is to only show content for that pubkey - so proof you hold the private keys are required sooner (basically just a normal login).

Reply to this note

Please Login to reply.

Discussion

CC #[1]

Source code here.

https://gist.github.com/blakejakopovic/b0065b9327c48c148bfe989c08137ba1

For clarity, this doesn’t do full event auth validation, as I may not use Ruby - no reason it can’t be added where I’ve commented.

This is the simplest code to get this working, so not prod ready, but decent example code.

And we may need a new NIP for this as we don’t need parts of 42 that are relay specific.

Where I think this could be fun and useful is being able to log into a relay via a web porta and set personal preferences like “friends of friends only mode”, or “explicit content filter”, or whatever. Maybe even see stats for your pubkey or devices recently active.

#[0]

How do you do that from your phone, though?

Using a mobile browser extension works

I'm not sure, I didn't check how it was working. I don't have so much time right now.

But calm down guys! I'm coming soon with a login spec + PoC

What’s different between this and NIP46?

https://coinstr.app/articles/nostr-connect/

It’s a cool NIP that I need to read more about.

Basically what I tested was 100% local using Nostr browser extensions to sign an event using a server auth challenge. It’s more similar to NIP-42 however doesn’t need to be a relay, and doesn’t need websockets. It just uses a similar event payload over REST.

So I’d say fewer devices, less network dependent, more transitional sessions using cookies, etc. A simpler approach, but also less features.

You’re more focused on individual nsec protection rather than multi account authentication I take it?

Nostr has a decent way to go with key management - unless you are careful with your private key.

Things like rotating, expiring or migrating - or multi-sig keys, are all under development.

I just needed a simple enough way to add login to a website or web service, that didn’t allow impersonation. It may get replaced as things develop.

Pretty sure that was #[3]​ usecase for this NIP originally.

Personally I think a whole identity management layer could be built around it.

The current workflow of client > identity > relay is ass-backwards to me. Identity should be front and centre, we’re not utilising it anywhere near as well as we should be and as a result the onboarding process for newbies sucks.

i like this idea