Another app with remote key access support!
nostr:nevent1qvzqqqqqqypzpm7r06tl5nadv70yvjm6vxzqpxmucas94n4sch6kk3jd9wvx5c8sqyghwumn8ghj7mn0wd68ytnhd9hx2tcppemhxue69uhkummn9ekx7mp0qqsyjvlesl7umqzddp85glh278hdz935we3kjp6uhfrcv0chvpdwj6c9nzm8l
Remote key access support spreading on Nostr!
nostr:nevent1qvzqqqqqqypzph0s8t9gtt0q88n8gt2mau7lx5klrxws6v0z9wv93eld4pwt8wa7qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqypf0gvfprmjkw6d7jnmkywel6gy9t0stqpddlensjzs4sxr8djtejtzwxct
You can now transfer usernames in nsec.app!
Many people tried nsec.app and claimed their preferred username, but due to UX issues have it attached to throwaway test keys. We've (hopefully) fixed the signup UX, but also added a name transfer feature. You can now transfer your username to your real keys.
Make sure you reload the app properly (open tab, close tab, open again) to get the updated version with this feature. There is a menu button near your nip05 name in the app, where you can request a transfer to a specified npub. That npub then would have to change their username manually to the transferred one to "accept" it.
We've also made some serious improvements to the app, particularly with how well it works when your keys are imported into several devices/browsers. If you've had issues in that mode - please try this new version please.
Here is a quick demo of the name transfer:
https://v.nostr.build/zGgZ.mp4
@The Fishcake🐶🐾 is there nip46 auth planned for nostr.build? I'm buying premium and don't have extension, you could snap nostr-login there so I could use nsec.app for it.
If you want to try with your real keys go to nsec.app and import them. It's non-custodial, keys stay in your browser. Or just go through sign up flow to try with new keys.
https://github.com/nostrband/noauth readme has some instructions. nostr:npub1ky4kxtyg0uxgw8g5p5mmedh8c8s6sqny6zmaaqj44gv4rk0plaus3m4fd2is working on dockerising it and promised a long post with a detailed manual.
@Stuart Bowman Hi what do you think on adding remote key access nip46 support to Satellite? There is nostr-login lib to simplify that. Would be great to login to Satellite on mobile without extensions
You want to copy your nsec and paste it somewhere, or store somewhere, if it's plaintext nsec then one mistake and it's pasted publicly. This nip allows to get nsec in an encrypted form, so that even if ncryptsec1... leaks, noone can decrypt it without password. When you try to import it into other app if it supports nip49 it will ask for password and decrypt it.
The spec is too badly written. The reply has format of
"content": "METHOD({id: <request-id>, result: <string>, error: <reason-string>})",
And the "result" field contains the method-specific payload.
The spec is being rewritten now with oauth-stuff added, hopefully it gets more readable.
We plan to let you include just a form without modal in your page, we could also fire a authUrl event and then you could redirect there, but then somehow we would have to forward people back. There was a redirect url param somewhere in nip46, will look into that
Thanks for your help! You don't get much more security by self hosting (it's non custodial anyways) but maybe you find other reasons...
nostr:nevent1qqs93zz8trrgwvwgfqqmvdvawfzsmmvv4a2w3g76fu44aezcpfjuawcppamhxue69uhkummnw3ezumt0d5pzpvftvvkgslcvsuw3grfhhjmw0s0p4qpxf59hm6p9t2se28v7rlmeqvzqqqqqqy5p4d9h
Case in point - nip46 nip04_decrypt method used to return [plaintext], which didn't make sense, but that was spec-ed. Snort implemented a sane, but broken version - expecting just plaintext string. It wasn't working with ndk that returned [plaintext], so I looked things up, people were proposing to "fix" it - change the spec, I saw 'No it will break implementations' comment and went on to fix Snort - make it accept [plaintext]. Turns out that was "fixed" in the spec now and changed in NDK - it returns plaintext string now, but Snort has no idea about it and now I have to unfix Snort. I'm not sure, maybe I and Kieran aren't following the right process to stay up to date w/ NIP changes but this kinda illustrates the point.
Thanks for your work.
How could I better follow NIP changes? Just watch the git repo on github? Maybe there could be nostr-nip-report account or hashtag that would scream at devs that there were some changes to existing specs? Some changes are inevitable so I'd rather stay up to date than stay ignorant.
How about a list of these changes in NIP repo readme, at the very top? Full dated list w/ full history (starting from today), so that whenever someone looks there they see it. The fact that it's at the very scarce readme space could help avoid normalizing changes...
I'm no expert, but that link says:
> When encoding passwords with UTF-8, it is important to realize that there may be multiple UTF-8 representations of a given string. Since the key generated by a password-base key derivation function is dependent on the specific bytes, this matters a great deal.
The 'oauth on another device' issue is partially fixed now - if there is another active device/browser that can send authUrl then you'll see login screen first, and if you login it will proceed to asking for confirmation etc. The unresolved case of 'there are no active devices that can send authUrl' stays, will be fixing it differently.
Introducing nsec.app and nostr-login!
I've shown the prototype of https://nsec.app in December, and it's essentially an nsecbunker in your browser. It is non-custodial - your keys are stored locally in the browser, and apps can get access to your keys using NIP46. We've now turned that prototype into a real thing, and I invite you to try it. Shoutout to @nielliesmons for the designs!
Now how do we help Nostr apps adopt NIP46 for remote key access?
That's where nostr-login library comes in. If your app uses NIP07 to talk to a browser extension, then with just two lines of code you can make it talk over NIP46.
Both of these tools support the new OAuth-like flow proposed by Pablo. Below you can watch a demo of how nostr-login (added to my fork of Snort) works with Nsec.app (or would work with any other nsecbunker).
What this all means is that people could join Nostr on the web, without installing extensions or mobile apps, with their keys stored non-custodially in the Nsec.app, and then could log in to other Nostr apps without copying their private keys.
Demo: https://void.cat/d/JSWwYMTtbWxTDTLpe132Kr.mp4
Links:
Snort+nostr-login: https://snort.nostrapps.org
nsec app: https://github.com/nostrband/noauth
nsec app server: https://github.com/nostrband/noauthd
nostr-login: https://github.com/nostrband/nostr-login
Indeed nip49 doesn't solve my issue.
I need to think through whether I can provide some protections first. Amethyst requires you to enter system pin / scan finger to verify your identity. Otherwise anyone who has 10 second access to your device could steal your nsec. Either I need to ask for a password first for nsec export, or add WebAuthn auth, or maybe some other clever way to do that.
We've improved the sign up UX, and also added a name transfer feature, could you please try it?
nostr:nevent1qvzqqqqqqypzqv6kmesm89j8jvww3vs5pv46hqm7pqgvpm63twlf9hszfqzqhz7aqyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszrnhwden5te0dehhxtnvdakz7qpq059p6ulldm7frlcyyf4lq4fvfpc2e9tkrsvpvwzxadfsrk9xnutqq8vpes
Name transfer available now:
nostr:nevent1qvzqqqqqqypzqv6kmesm89j8jvww3vs5pv46hqm7pqgvpm63twlf9hszfqzqhz7aqyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszrnhwden5te0dehhxtnvdakz7qpq059p6ulldm7frlcyyf4lq4fvfpc2e9tkrsvpvwzxadfsrk9xnutqq8vpes
I have it on nsec.app todo list, but I'm not yet sure which one I should serve - 3 or 10002. Read relays in 3 and 10002 seem to have different meaning.
Oddbean new post about login | logout
Notes by brugeman | export
The spec is too badly written. The reply has format of "content": "METHOD({id: <request-id>, result: <string>, error: <reason-string>})", And the "result" field contains the method-specific payload. The spec is being rewritten now with oauth-stuff added, hopefully it gets more readable.