To inherit the social trust publicly with new npub you have to link it to the old one, publicly. So it's not really new identity for anyone.
What you seem to have in mind is the idea that you should be able to selectively reveal your social rating when that's needed.
One solution could be that by default you log in to a new app with randomly generated new keys (that are tied to main keys) and then if you have to "prove" you're trustworthy to some peer in that app then maybe your main keys sign an encrypted gift wrap that says "this child key is actually my main identity's subkey".
You could have separate key for every app/website, new keys for every session, every week, etc, that could be the default way to surf the web. And then you reveal yourself when that's absolutely necessary.
I think with nostr the power is in the ability to generate as many identities as you need without permission and make claims about relationships btw them. You may have one identity, one with many subkeys, many identities for different tasks, etc. And then we'll collectively figure out what's the best way to use this to enable interop but with proper level of privacy suiting each user.
Brave is problematic with nsec.app. Firefox should work, did the popup with nsec.app show up to you? Could you confirm the connection? If not then firefox blocked the popup 😟
This (slow opt in) is what we're working on now with nostr-login widget, signup starts with a local key and then when user has actually used the keys and signed something etc we'll be nudging them towards "key backup" - importing into a nip46 service etc.
You're suggesting a new kind of service where user enters a password and app sends ncrypt to a server so that if local copy of nsec is lost (or they want to use another app) then ncrypt is downloaded, password is entered and nsec is again stored locally. Right? This kind of "ncrypt store" is actually part of nsec.app setup (we store ncrypt on server so you could "login" into nsec.app in another browser/device), but you're proposing to make it a separate thing. Sounds interesting. The problem of apps having raw access to nsec still holds, but at least you're not copying it around, and password can live inside the password manager. Still a step forward over "nsec login", I would say.
I like Pablo's suggestion: https://github.com/nostr-protocol/nips/pull/829
Keys are definitely the cornerstone here, but same is true for bitcoin, and we have a massive pile of builders solving keys for bitcoin, and there are more and more robust and user-friendly solutions coming to market.
Here is how bitcoin keys compare to nostr keys in my mind:
- you can 'migrate' from one set of bitcoin keys to the other by transferring all funds. With the suggestion above, you can do something similar on Nostr (although it's not precisely "all value" that's being transferred). It will also take lot of work for apps to support this auto-migration, and there are technical issues with that particular suggestion, but it's a good start IMO.
- you can kind of manage risks with bitcoin keys using several different wallet setups with different amounts stored. But you could do the same on nostr, having several keys with different setups dedicated to different activities. We don't have widely used tools to store many keys and switch btw accounts in signers and in the apps, nsec.app and nostr-login help here.
- you have limited damage if bitcoin keys are stolen, but on nostr it feels unlimited - thieves can broadcast with your own keys forever, they can also post fake events in the past under your old name. We will probably have to opentimestamp important stuff we publish to add safeguards against back-dated fakes. Also if the above nip is implemented well, the damage here might be reduced significantly.
This is just what comes to mind on the spot, let's discuss this further.
Once your nsec is stolen, you can never recover it for your exclusive use, that's correct. Once it's lost, you can never recover it for any use, that's also correct. But same is true for bitcoin keys, and yet we're hoping to build the world around it, and people build tools to mitigate these risks. Nostr key != Bitcoin key, but there are much more similarities than differences. Here is more on this: nostr:nevent1qqs0qkyxmykx2a5f98e88c2ayyz44z53h8ntvqp0fusge4r62m9m7mcql9f4x
There aren't much tools and protocol-level solutions to key loss or theft atm. But that's just because nobody is trying to use them for mission critical stuff, once demand comes, solutions will come. I will keep repeating that nostr keys have lots in common to bitcoin keys, and we do hope to make bitcoin the core of our future economy, so how is nostr different in principle? More here: nostr:nevent1qqs0qkyxmykx2a5f98e88c2ayyz44z53h8ntvqp0fusge4r62m9m7mcql9f4x
We've had multisig for nostr more than year ago: https://github.com/nickfarrow/frostr It's just not user-friendly and not built into any signer and nobody really needs it. Maybe we should explore it with nsec.app?
The only reason you don't have robust solutions against nsec theft is because nobody cared enough yet.
Really great overview!
nostr:nevent1qvzqqqqqqypzq079lp2n40t48tz8je7yc35vl5yw3juaaecm08sj6kk6kgzmcpxnqy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqsz6q3g0w47d7jhufa79edesj8lwzrqltz9f0dnj0nqlmw7vn4dtfgyrackj
Meet the latest Nostr-Login widget release!
Nostr-Login has become a very powerful window.nostr provider (as of v1.3.0).
Just drop the nostr-login script into your web app, and your users will be able to login with extension, with Nostr Connect, in read-only mode, sign up with OAuth-style flow, switch accounts, etc. Your app just calls window.nostr, the rest is handled by nostr-login.
Here is a short demo where I login with Nostr Connect, and then add a read-only account, and then switch between them. You can try it in action on https://nostr.bandhttps://v.nostr.build/POD38.mp4
App devs, if the only option you're giving your users is "Login with extension" (or even "Paste your nsec") then maybe it's time for an upgrade. The more options for people to log in, the more your app is used!
Learn more on how to set up nostr-login at https://github.com/nostrband/nostr-login
For other "login with Nostr" options, check out https://nostrlogin.org
Nip46 is far from perfect indeed.
To your points:
1. Nip46 server can be built into a relay, so you would be "just contacting signing server directly" to save one roundtrip. Not sure there is any practical difference btw HTTP and WS, aside from less experience with WS for most devs. The most important stuff you lose without a relay is:
- you can't run your nip46 server behind NAT without a relay in the middle, so even if you had some server you owned (Umbrel etc) it would require a complex port forwarding etc setup to host keys on it, and you'd expose your server to the wide internet and then hope it's not getting hacked, etc.
- you can't build a client-side solution like nsec.app where you don't need to own a server to self-host your nip46 signer
Essentially, adding a relay REMOVES a lot of complexity for practical self-hosted use and adoption. And if you wanted to save on round-trips, there will be nip46 signers built into relays.
2. Nip04 use sucks, we will need to upgrade at some point. Do you think we should start asap?
Those events are ephemeral and encrypted, so they don't generally sit anywhere for too long, and not particularly useful for anyone except the app and the signer. What's your concern here?
That is indeed something that will eventually bite us. Do you have any ideas about how that could be fixed with nip46, without switching to a new protocol? Maybe nip46 relay could require nip42 auth and only serve you the events that match your identity?
I'm skeptical about most of the Pros listed:
> Multiple keypairs/identities are not needed
- that's just implementation detail, like generating tokens in oauth etc
> Access tokens are only useful for authorization and are generally short-lived, they don't leak any permanent information.
- not sure which parts of nip46 leak anything, can you provide details?
> Signer events are now "private" between clients and signers, and can't leak user activity such as note decryption when opening a new client.
- this one is valid concern
> No relay, no relay to trust
- most nip46 providers will host their own relay for many reasons, and even if they use a third-party relay - they will only recommend one they trust, so if you trust a provider, you probably trust the relay
> Http attack surface is well understood
- need more details and maybe examples here
> CORS could possibly be used as a security advantage for web clients
- need details and ideas of where and how
> Reduces signing server dev complexity
- you won't implement oauth yourself, you'll use a library, but then you can just use a library to implement nip46
> Full OAuth2 and identity management infrastructure already exists
- which of them could I start using tomorrow to use with Coracle or Snort on mobile? This might be true for corporate world, not much for individuals
> Since clients connect directly, network/http requests can be audited easily
- audited for what? all requests are signed, the only thing lacking with nip46 is peer's IP address, which is only useful for privacy violations of good users, since bad people hide their IP anyway
> Reduces client complexity and deprecated encryption spec
- you will use a library in both cases, so complexity is comparable. nip04 is bad, agreed.
Switching btw different real keys is hard (impossible with browser extensions, possible with Nostr Connect or local nsecs), but switching to Anon is trivial, apps can just have a switch "Reply as anon" and sign this particular event with burner keys. zapthreads comment widget deployed on habla.news has that
Ok this sounds like a possible addition for nostr-login library. We could add anon mode (ghost mode?), or even sign-single-event-then-burn-nsec-mode and with account switching and other stuff we already have it should be quite user friendly.
We could also auto-publish a profile event with some POW, or maybe use some ecash magic if someone smart chimes in, to get our anon event above noise thresholds.
I've just deployed a new nostr-login on nostr.band (reload hard please) that has account switching. I've got my real key connected, and also jack in read-only mode. Switching is a couple of clicks. Nostr.band doesn't personalize the experience much, but the concept is working. Switching is log out and in though from app's pov, so it might be heavy depending on the app.
Love this! Let me know if you have questions about bunkers (nostr connect, nip46), or maybe check out nostrconnect.org for an intro on client implementation.
I don't think it's just about young authoritarians.
On the web, the major way to get new content is to search for it or click through to it, which means you are unlikely to see unwanted stuff.
With social media, centralized or not, anyone can push content upon you. That's the point of social media. But the result is unwanted content on your screen.
Block may mean many things.
If block is "blocked people can't see your content" then sure it's just not possible on a public internet.
If block is "blocked people can't comment on your content" (which was mentioned in your quote) then it's not that simple. Website do have various forms of blocking (for comments, posting etc). Of course that doesn't "block" someone from commenting elsewhere and linking to your post, but that's a different thing.
It's almost like people feel "ownership" of their posts, and when someone replies, they almost feel like people have posted "on their space". So even muting doesn't feel like enough, they want no one to see bad stuff "on their space" (in replies). They feel as if they were talking in a some cosy space and then someone intruded with their bad stuff. You'd be upset IRL if someone interrupted your conversation with some BS, even if your conversation was happening "on a town square". IRL you could tell the intruder to get off or you could go away and stop the conversation, but it's not possible online - they can keep yelling at you forever and can invite friends, etc.
Maybe muting feels like not enough because if everyone can see how you're not responding (if you muted them) then everyone might think "if he has nothing to say then maybe their BS has merit". If you muted and not responding then for others it feels like you just have nothing to say, and that's not true. Maybe if there was a marker visible like "this person is muted by the person he's replying to so take that into account" it would help everyone understand the situation better and the urge for "blocking" would be lower.
Anyway, it's definitely a mismatch btw what's possible online and offline. You wouldn't let some idiot follow you in all public spaces IRL and yell at you, you'd punch them or call police. Or you would at least try to let everyone around know that you're actively ignoring the idiot. But what can you do online?
I didn't say blocking solves anything or is even possible on Nostr. I was stating the problem that people try to solve with blocks.
But please tell me how I should "not allow any spammer to do that"?
I didn't say we should stop people from doing something. I outlined why particular kinds of replies cause discomfort strong enough for people to be vocal and to even leave nostr, and how these interactions are different online vs offline. We can argue about semantics of ON or ABOUT all day, the discomfort doesn't go away from that.
Mute is a simple first tool we've built (another one is reports), and even that one isn't utilized to it's full potential by any app. Declaring it the only option (especially as implemented now) is assuming nothing can be improved. The problem won't go away by itself. People will seek solutions. Some of implemented solutions might cause you discomfort, just like their absence causes discomfort for someone else now. Deal with it.
A good explanation, although the accusation that I was suggesting dystopian solution is false. I outlined why people want blocking. I didn't suggest we implement it, in fact that's so hard to do on Nostr it will probably never happen.
Thanks a lot for the input. I wasn't able to reproduce the issue with Coracle on iOS, but I know it's there, thanks for the reminder. Shipyard needs an update to support the up-to-date nip46, for now it seems to only support nsecbunker.com (their custom connection strings). Flare doesn't seem to take nip46 bunker relays signalled by a provider into account and tries to communicate over random public relays (cc @zach)
I don't have up to date iPhone to test properly, but it sounds like you have enabled the push API. The way to check it is - try using highlighter with all nsec.app tabs closed. if you're able to like/reply/etc then it's working fine (nsec.app PWA receiving push messages to wake up and sign events). If it's not working without an nsec.app tab open, then we need to look for some Push API button somewhere.
Please let me know if you actually do more tests. Thank you!
Thank you for the hint on mobile extension behavior. Will move the Sign in with extension button to advanced section in case where extension isn't yet 'authorized'.
> Nip 46 is supposed to fix issues with mobile app login … but nsec bunker holds private keys in custody … so “Nostr login” was created as a “local storage” implementation.
Nostr login is not a "local storage" implementation. This sentence makes no sense to me. And even if you meant nsec.app instead of nostr login, it follows nip46 spec and doesn't invent anything proprietary wrt nip05 addresses etc.
> Nostr login requires what “looks like” a Nip05 address, but IS NOT.
It is nip05 address, you can have many of them, your nsecbunker/nsec.app issues one for you, as per nip46 spec.
> There’s not even a name to call this email looking address you’re “supposed” to enter … but it’s only available at one of two domains.
We call it username. And it's available on all modern nip46 services, except for locally-hosted ones like Gossip app.
> ALSO not explained is the fact that it’s “non custodial” (users have no idea) AND once you create one you have to remember it IN ADDITION to the Nip05 address AND Zap address that are ALL essential parts of Nostr.
You're probably speaking about nsec.app's 'non custodial' nature? It's not directly related to nostr-login library, but yes - I don't like it that you have to remember yet another username/nip05 address to login. I have some ideas here, thank you for reminding me.
> This is a MESS.
It is, this whole Nostr thing is a giant mess. It's our job to both create it and to manage it. Thank you for participating.
NIP05 is just a simpler way to login, nip46 provider may issue you a nip05 under their domain and when you enter it for login all the data needed for connection is automatically fetched from a known location on the provider domain. So you don't need to generate a bunker URL on provider first, just enter your nip05 name.
The biggest concern for major native apps (and web DM apps) is DM decryption - apps store the full history of DMs in encrypted form on disk, and decrypt them all on startup, which might mean thousands of request to keys every time the app starts. There are many ways to solve this (decrypt on demand when user opens DMs, store DMs in plaintext, store them encrypted with local key, etc) but they all quite complex or require compromises, all while Nostr Connect is just not a priority. Especially when there are platform-specific faster solutions like Amber which Amethyst supports.
Oddbean new post about login | logout
Notes by brugeman | export