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
Currently most apps expect a bunker string, so yes - you click Connect app in nsec.app and it shows the bunker url.
If apps adopt nostr-login (or re-implement the OAuth-like flow themselves), users would just enter name@domain (@nsec.app or other nsecbunker domain) and get a popup to confirm the connection.
Oh yes on iOS it's early to celebrate - you need to enable Web Push API in Safari Settings -> Advanced -> Experimental, and then click 'Share' on nsec.app tab and click 'Add to homescreen' - that's the only way iOS allows push notifications to get delivered. Eventually the 'Settings' part will go away as the feature matures, but we'll need to instruct people about 'Add to homescreen' flow.
The create-account flow is described here: https://github.com/kind-0/nsecbunkerd/blob/master/OAUTH-LIKE-FLOW.md
Client (or nostr-login library) fetches nsec.app/.well-known/nostr.json, learns the npub and relay (of the nsec.app server - not the user), sends 'create_account' over NIP46, receives auth_url and shows the popup. Account is created by the auth_url tab (nsec.app or other nsecbunker).
The code for all this is scattered over nostr-login, noauth and noauthd repos at github.com/nostrband
Right now there is no way to delete keys in the app itself, you can clear all local data by clicking an icon to the left of tab url in your browser, then choose "Site data" or some such item, and then find "Delete" button. If you imported some real keys then you better have a copy of them in some other place.
Extension are not available on many mobile platforms. Also with remote signing you can give limited access to your keys to some server-side service that can't talk to your extension - i.e. import your tweets to Nostr, send DMs under your name, etc. Huge space of apps and services becomes viable.
All of you who generated new keys and claimed their preferred real usernames - I will make a 'transfer name' feature so that you could migrate your name to your real keys eventually.
Click add account choose advanced then import nsec. There are several reports here that it's not working in brave so I recommend you try signing up first to check with throwaway keys. Will look into the brave issues tomorrow
Trustworthy is easily game able, same with new users, so if there is monetary incentive you will get bots inviting bots. Or scammy trustworthy people inviting bots.
We should just build tools to simplify social onboarding, turning it into a contest will result in abuse. I don't see a trivial way to avoid that.
This is a great idea. But calculating it based on your criteria won't be trivial:
> is the first follow of a new account
This can't be calculated with certainty, because clients can rearrange contacts, but most of them don't, so might be ok.
> follows the new account within 24 hours
Not possible unless we track the full history of contact list editing by the advocates. We don't.
> is author or recipient of first Note or DM with the new account
OK
> “engages” with new account “regularly” during a period
A bit complex but ok.
> is “trusted” by trust.nostr.band
OK.
If we replace the second condition with just 'Follows the new account' then it might work. But I can't promise to deliver this soon - quite complex endeavor with an obvious result. Do you really need the confirmation in numbers to keep building your onboarding tool?
Great rant, thank you. I agree with most of the problems you're outlining.
First, on layers - I never suggested that we only need one single set of trust assignments. If we need several layers or facets - we could have more.
Second, on updating - manual or automated, any trust signal that is published will have to be updated periodically. UX might make it super smooth, but still.
Third, on discrete flags - instead of 0-100 scale you're suggesting 0-1 scale, what does that change in principle? If humans are limited - let them only publish 0 and 100, and leave the full range to machines.
Is there a preview of the NIP you're working on?
I'm not saying your work is a wasted effort, bcs right at the beginning of the paragraph that you're citing, I say 'naturally through friends' - that's exactly the best way to onboard someone and pass some trust you have to them.
I watched your video, looks great and I fully support your effort.
All I'm saying is that if someone has NO friends on nostr and joins nostr then they're indistinguishable from a bot. In fact, on Nostr they're much more likely to be a bot bcs it's an open network. And if they have to prove they're worthy of trust/attention by organic interaction then it will be hard bcs bots will be much more productive and persistent in attempts to gain trust by liking/commenting etc. For such people with no friends, doing PoW or paying fees seem like the only options to outpace bots.
I'm not saying your work is a wasted effort, bcs right at the beginning of the paragraph that you're citing, I say 'naturally through friends' - that's exactly the best way to onboard someone and pass some trust you have to them.
I watched your video, looks great and I fully support your effort.
All I'm saying is that if someone has NO friends on nostr and joins nostr then they're indistinguishable from a bot. In fact, on Nostr they're much more likely to be a bot bcs it's an open network. And if they have to prove they're worthy of trust/attention by organic interaction then it will be hard bcs bots will be much more productive and persistent in attempts to gain trust by liking/commenting etc. For such people with no friends, doing PoW or paying fees seem like the only options to outpace bots.
With an approach of 'each client publishes trust assignments then clients calculate trust ranks' private follows can be handled - your trust assignments would give non-zero values to privately followed users (if you so wish) and then others would use that info. Ofc if you want to keep your trust assignments 'private' that won't help.
Onboarding for new users is already a problem and requires some input from them - 'topics' etc, some seed from which we could work. Any seed will inevitably lead to some 'preferred' profiles, whose trust assignments can be used to calc trust ranks for this new user and show them something 'trustworthy'.
As for bootstrapping trust for new users - this has always happened naturally, through friend (someone invited you to join right?) or through genuine organic interactions (new user interacts with others and they reply and some trust is passed). But organic interactions take time, and also on Nostr it might simply be too costly to organically outpace bots that will try to gain trust the same way. That's the only place where I think PoW makes sense, also trust-bootstrapping services, or OpenTimestamp (onchain tx) with non-trivial fees spent (or a burn - but that's wasteful).
Link to trust assignments note: nostr:note13vpt4uqmfljhy9ql8rur23dpepkd8dkryxcp9mlf2wqjgxwj6puqnj3n6j
yeah apologies for the recent downtimes, been away from keyboard and that's when things start shaking, as usual. upgrading the relay hw setup to accommodate for the next year of nostr.
One year ago on Dec 28 I bought the nostr.band domain and decided to focus on Nostr.
It's been an amazing journey! I've met incredible people, assembled a small team and we are building tools and products to help Nostr win.
Thank you everyone who supported our efforts and used Nostr.Band!
We've made lots of updates to our advanced search features recently, and will be making them even better in 2024.
Excited to see what's going to be the next page of Nostr!
Thank you, it's a great motivation to keep building! I regularly take inspiration from the work you are doing! Being part of this community is the best experience of my professional life.
Thanks for the write-up!
Questions:
- should username & email should be optional for create_account? Clients shouldn't be forced to implement nip05 name selection, plus some bunkers might assign nip05 names from partners/different domains etc
- create_account is only for signup? it could in theory work in exactly the same way for login - user enters their nip05 on the client, client sends create_account but the bunker just checks if such nip05 exists and does the auth
- Should bunker add itself to user's 31989 as handler for 24113? If it did, then if user changes their nip05 later, they could still login through a client with their new nip05 - client asks for nip05, checks .well-known of the new nip05 to see if it supports nip46 for this user, and if not - looks at 31989 to find the possible nip46 app for this user
> the `connect` request is sent to the user's pubkey
But to which relay? 31989 to find the domain which leads to .well-known with your nip46/relay. Or?
Although the way I described it, new nip05 would be the priority :)
Anyways, since we're adding to 31989 anyways we could do both and figure out later which works better.
Do you envision passing app name and icon to auth_url? So that bunker could display them when asking for confirmation, and also in the list of connected apps? Or should those be part of create_account/connect requests?
I agree those are forgeable, but having no app name/icon would hurt all normal users, while potential forgery would only hurt occasionally.
I like your idea of using domain and nip05 of callbackUrl (I think you called it redirectUrl?). OAuth solves this by requiring app registration, but that not nostr way.
Maybe we could require callbackUrl and redirect user to callbackUrl?token=accessToken which then has to be 'consumed' by the app with a new nip46 method to confirm it's identity? If callbackUrl doesn't belong to the attacker then they won't have the accessToken, doing this + your idea of using domain+nip05 could solve both naming and forgery. Anything wrong with this aside from complexity?
As for the native apps without deep linking support, they could stick to using bunker: links which are more cumbersome for users but don't have these issues.
The future!
nostr:nevent1qqsrmd7nm3hkuzzgh784092lg79yywuy8gdr07v6vlxunfsw45u2akcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsyg86np9a0kajstc8u9h846rmy6320wdepdeydfz8w8cv7kh9sqv02gpsgqqqqqqsdtx52d
A big update on nostrapp.link!
If you consider njump's rendering of events a bit too technical, try nostrapp.link/<bech32>
1. It's very noob and mobile friendly.
2. It has custom rendering for many event kinds, supports 'alt' tags etc.
3. It has proper meta tags and is great for sharing on social/messengers.
4. It's fast - the event is pre-loaded on the server and thus displayed instantly.
5. It's not trying to render all the details of the event, and instead presents it as a 'preview' and encourages to choose an app to view it.
6. It suggests apps to view the event using nip89, not a pre-set list of apps, which means it's much more likely to suggest an app for unknown kinds.
7. No app has any preference, suggested app list is randomized.
8. Each app displays avatars of it's users.
Here is how a new 'video' 34235 events are rendered: https://nostrapp.link/naddr1qqr5u72rwuukxdqpp4mhxue69uhkummn9ekx7mqzyrt4xcnqhzx00ewv8l9ylq3ypu6zhsycwck08wz46htkteuvjhwukqcyqqqgtwc7qu42a
And here is a list of profiles: https://nostrapp.link/naddr1qqx4xmmxw3mkzun9ypzx2annqgsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgrqsqqqafs3ujm72
These improvements were long overdue, shout out to @mplorentz for pushing me to initiate them!
@Kieran maybe you could render links to njump or nostrapp.link for unknown kinds instead of these huge JSONs in Snort?
Well if you clicked the '...' button at the corner of suggested app you'd see the full list. I guess we should turn it into "And N other apps" button or something like that.
Thanks! I agree Profile list meta tags should be fixed.
I'm not against viewing the raw json, I just want a convenient open-with button displayed nearby, or at least in the menu.
This is amazing!
Do you plan to support some template system like mustache.js? Let's suppose you'd want to use ngine as a core for Ghost.org alternative - how hard could it be to provide similar level of customization/theming?
Amazing, a very important app!
nostr:nevent1qqstmzcm5zh6gx4t3mn2f0rywmpugpfpxz9zqkx792y5ml0un7hr98gpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9upzqla9dawkjc4trc7dgf88trpsq2uxvhmmpkxua607nc5g6a634sv5qvzqqqqqqyrmrrtf
Oddbean new post about login | logout
Notes by brugeman | export