Amazing, a very important app!
nostr:nevent1qqstmzcm5zh6gx4t3mn2f0rywmpugpfpxz9zqkx792y5ml0un7hr98gpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9upzqla9dawkjc4trc7dgf88trpsq2uxvhmmpkxua607nc5g6a634sv5qvzqqqqqqyrmrrtf
@Vitor Pamplona would you consider changing the Amethyst's nip89 description?
If you change the URL template to "intent:<bech32>#Intent;scheme=nostr;package=com.vitorpamplona.amethyst;end%60;" then clicking Amethyst on Android would lead directly to it, and not the app picker like nostr: link does. njump has hardcoded this for several Android apps, I'd like this approach to work in nip89 way.
Thanks again Niel, the designs are being implemented.
Some feedback:
- I think we'll go with just "Username" field at signup (and a small explainer) - no email or password, not even @nsec.app suffix/dropdown. I'd like to make signup as low friction as possible, all the other details can be figured out later when person starts using nostr
- would be great to have a way to show 'warnings' above YOUR LOGIN section (icon + message), like "Please add password to protect your account". We'll be encouraging users to improve their settings as their usage of nostr starts increasing, but won't bother them with complications if they've posted just a couple of likes.
- we don't have good use for email atm, so removing it for now, it will most probably come back later, but only as backup/recovery setting, not required at signup
- no need to show password under YOUR LOGIN screen - password is optional, and might end up as not even a primary method for auth/decryption, so we'll move it to "cloud sync" settings.
Overall this is a great input and progress, thank you!
We will make the above-mentioned modifications to the design ourselves to iterate faster, and will be happy to incorporate any changes later based on your feedback.
Finally!
Nostr.Band now renders proper meta-tags for profiles and event pages - links to profiles and events look much better when shared in messengers or xitters.
https://void.cat/d/U11QD7GAb58wcYn3Zcjtse.webp
This works with a small http server that fetches events/profiles on the server and injects meta tags into index.html of our built SPA. Just in case you need that in your own apps: https://github.com/nostrband/nometa
A little handy update here - it will print the fetched event and profile into window.nometaPreloadedEvents={ event, profile } so that your SPA could render them ASAP without re-fetching on the client.
Starting to play with decentralized trust ranking in Spring v0.12.
You can estimate, adjust and publish trust scores for other users - these are estimated from your recent interactions.
https://void.cat/d/T5HriPK2C8QSd7cGsoJVL6.webp@rabble has been advocating the TrustNet as a web of trust implementation, useful for spam filtering etc.
The algorithm has two steps - first, each user publishes 'trust assignments' - that's trust scores your can now publish with Spring. These are published as 10629 replaceable events with a list of 'p' tags and a score, typical size will probably be ~100 pubkeys. We provide an estimate based on past interactions, but it can't be precise - you may and should adjust it to match your actual relationships.
The second step is that apps can download trust assignments of users close to your network (contacts, people you like/zap a lot etc) and run a calculation akin to PageRank, but it's not global - it's local to your network. The result will be several thousand pubkeys with non-zero trust ranks - a much wider network of users who could be trusted.
This way the trust ranking is a) based on everyone's actual relationships, because you can adjust the trust scores you're publishing, and b) efficient and can be used by any app - it just needs to download several hundred trust score lists and run the trustnet algo periodically and store results in local cache.
Spring only does step one at the moment. When enough people publish their trust assignments we will add the second step and let you calculate your own trust ranks. Spring will show the trust ranks under profiles, and will use it for spam filtering later. Other apps will probably find other uses for it.
More on TrustNet here: https://cblgh.org/trustnet/
The underlying algo is Appleseed, it's an old 'peer-reviewed' thing https://github.com/cblgh/appleseed-metric
It runs in several iterations until the trust ranks converge, each iteration should be around n^2, number of iterations will probably be around several dozen in our cases. All that doesn't matter much as we aren't trying to calculate the global ranks - several thousand trust assignments for local ranks will be trivial to handle by any client on any device.
Honestly, I'd prefer public discussions here, but if it matters you can hit me on telegram @nostrband
I will probably build a micro app just for publishing trust assignments and calculating the ranks so everyone could participate. And thanks, will definitely reach out if I need help!
It's there the Friend labels on the screenshot. Also on the 5-star ratings nostr:naddr1qq25gnzpveay5jns29z9xdrkdgehw5mvv46k6q3qarkn0xxxll4llgy9qxkrncn3vc4l69s0dz8ef3zadykcwe7ax3dqxpqqqp65wuucp8v
Remember these trust score lists are public. I am pretty sure everyone has at least one special person that will really appreciate that one extra point you can assing that takes them to the top.
Actually this could help - even if new person follows a couple connected users apps could use their trust ranks to filter the global feed and suggest more people to follow. This could make a difference!
There are labels to the right of the profile name - Friend/Peer/Partner/Acquaintance/New person, it changes if you're dragging the slider (on the screenshot above). People questioned whether it's intuitive... I'd say never mind, the issue is too minor without the actual use or feedback atm.
There is no algo that would give results matching your real relationships, without making people adjust the values we'll get garbage-in garbage-out trust ranking.
I need to do more research here. One question though - if nsec is encrypted by password then user would still have to enter it in the app, even if server only needs webauthn to return the encrypted nsec. So from user's point of view, it's still a second factor, even if server needs just one. Or am I missing something?
Yes, hash of master password is used in bitwarden for server auth (since user already has to remember it to decrypt the master key), and webauthn can be used as a second factor.
I have the same concern actually. Here is my line of thinking:
Ultimately, user has to remember some secret (or have a reliable device storing that secret). Password can at least go through a hard key derivation function and be much shorter then the actual nsec and easier to remember. And w/ webauthn as a second factor, a leaked password alone can't be used to recover key from the cloud and decrypt it - user could be notified about the failed cloud access and be asked to change the password.
I need to think more on this, I feel like there is still something here in what you're saying.
nip46 spec says that nip04_decrypt returns [plaintext], and that's what ndk's nip46 backend does, not sure what the reasoning is. It's been there from the start, might have been a typo.
I will add describe soon and get_relays later. Also, wdyt of a new get_nip04_key method to let apps request a nip04 shared key to avoid RPC when decrypting lots of DMs? https://github.com/vitorpamplona/amethyst/issues/592#issuecomment-1840775927
nostr:nprofile1qqs8lft0t45k92c78n2zfe6ccvqzhpn977cd3h8wnl579zxhw5dvr9qpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qy88wumn8ghj7mn0wvhxcmmv9ucc4x55 would you please add support for nip46 to habla? The bunker:// string in particular to allow us to specify the relay. Shouldn't be hard with ndk
App initiates flow is bad, app can't know which relay to use and will pick a random one which won't work bcs of rate limits etc. And the copy url flow is not ideal UX, Pablo is working on oauth like flow, so that will improve. For now a bunker:// url support would be great for starters
I guess bunker://pubkey-in-bunker?relay=x was the original url Pablo came up with, but then he simplified it to just npub of pubkey in bunker (assuming app connects to his relay). And then Pablo invented a token that is nsecbunker specific thing, a pre-approved set of permissions. I would say you could go with bunker:// url, while we figure out a better oauth like ux.
Thanks for this input.
1. Donation must be a burn, not a transfer, otherwise there will be wash transfers. The simplest burn to make is to run some PoW, so for new users that have no reputation I don't think there is a better costly signal than publishing a PoW event.
2. I agree that local trust score is the right solution (I think people refer to it WoT, but it's vague), and we're experimenting with applying TrustNet (https://cblgh.org/trustnet/) on the client so that users wouldn't have to rely on our opaque global trust rank.
If donation is verified by the platform (geyser) then it's fine (for that platform), although not decentralized - others can't verify the donation was made without trusting geyser and integrating their api.
PoW is trivial to verify by anyone, and trivial to execute (no need to setup LN wallet etc) - although as mentioned elsewhere - there will be PoW marketplaces which means people who have access to them (and to LN to pay for them) will have several order of magnitude cheaper PoW. Plus that's a burn - it actually boils the oceans for the sake of it. So overall, I think PoW has it's place only for new/anon users with zero reputation (who are ready to "pay" to bootstrap), after that we should use other signals - content and links (trust ranks).
I suppose that the alternative to advertising is direct monetisation with bitcoin, and without ads privacy invasion might go away. Can you please talk more about the scaling debate, and how things ended up on the server, which is counter intuitive - moving more to the client should scale better.
When you say writing and editing went to server, what do you mean exactly? The early browser that was an editor would build the actual html and server would just serve it (like nostr relay does), vs current web apps where users just fill some abstract fields and server decides how to display them? Am I getting it right?
Thanks, that makes sense. Question - do you think Amaya is way too complex for an average user and that's why it never took off? Could it be that the reason it's so complex is that it mixes data with representation? Html is all about how it looks, which can be infinitely detailed and complex, while people mostly care about data - those domain specific fields they fill.
When you say that those things can now be achieved, which parts of nostr do you think would be used, aside from user identities and nip98? Relays, signed events, event kinds? Do you have a more detailed outline of the new architecture?
Love this!
nostr:nevent1qqsxd7eh3lc3lp4vptprcs77tz34fyqff5wytqzmememmcgz4qm6rhqppamhxue69uhkummnw3ezumt0d5pzqak8r2hr5jglrk0wc37t59lz98x6gyf6pwaku6hpwakhvslznjh6qvzqqqqqqy3trkny
We will expose it to apps running inside Spring, although I am not sure it can be done seamlessly and magically. External access is not a priority, but why not
Take a look at this prototype. It's a Nostr signer web-app - it works in your browser, doesn't need extensions, and stores your keys locally.
I love the recent ideas by @PABLOF7z and @rabble about OAuth-like nostr signup/login flows, but OAuth is so smooth because it works on the web - no extensions or apps needed. And the only Nostr web-signing option we had until now was to give custody of your keys to a remote nsecbunker, or paste nsec into every app.
This app, though, is a pure web app, and it does signing locally. It uses NIP46 just like nsecbunker, so it shouldn't be too hard for apps to start supporting it - the one that already works is Snort. With nip05 names added on top we can make signup/login flows that are very smooth and users would only deal with email-like usernames and passwords, without the custody of keys by third-parties.
Ok, let's watch the demo. Your eyes will bleed, but it's a prototype. Maybe #nostrdesign team would help us turn it into something pleasant.
https://video.nostr.build/b3bbcd1aa40ca6d1a3175f6690171e859dc85d41d7f4878b1bbc8f9b9c264fa9.mp4
This approach technically works across devices, but that's unreliable on mobile if device is locked, plus your devices are offline sometimes, so the best way would be to have this app store keys on each of your devices so that at least one instance of the signer is always online (on the device you're using right now). That's why this app has built-in password-protected cloud sync for keys.
It's open source.
App: https://login.nostrapps.org
Client: https://github.com/nostrband/noauth
Server: https://github.com/nostrband/noauthd
I just want to tell coracle which relay to use for nip46, bunker: url allows that. See nostr:nevent1qqsphc9rv7820h4hqchyg86h45q4hyvpsecscadpfwjx94pcuksjthcppamhxue69uhkummnw3ezumt0d5pzqv6kmesm89j8jvww3vs5pv46hqm7pqgvpm63twlf9hszfqzqhz7aqvzqqqqqqy86wtkn
Technically that's completely optional addon here. Signing works perfectly fine without this cloud sync capability.
But the 'flow-for-normies' I was imagining was that on signup they get a nip05 name + enter a password, keys are stored on one device and synched to the cloud. Then they go to another device and 'login' by entering the nip05 and password - keys are synched to this new device and now it can sign too. This would make the experience very familiar, advanced users could turn this off and do manual key backups etc.
Sync is end-to-end encrypted, server can't read your plaintext key unless it cracks your password. It works similar to Bitwarden if you heard of it.
Oh wow, amazing! I didn't mean to discourage the bunker-link approach - nip05 doesn't remove the bunker-links, maybe when there is an OAuth-like flow we'd get rid of it. The nip05 would just be useful for logging into the Signer on a new device - it's easier to remember than npub.
Pop ups look awesome, nothing to add atm!
I would think on the Your Key section on homepage more:
1. The bunker link is not a 'key' - it's not secret, and we probably shouldn't mix the terminology with private keys.
2. I don't think we need to show the bunker-link on homescreen - it's content is meaningless and only useful rarely to connect a new app.
3. How about a 'Connect app' button that shows a modal with a QR-code of bunker-link, 'Copy' button, and a 'Paste this code to your app' message?
4. Also maybe a 'Cloud sync' button with a checkbox - shows a modal that explains it and asks to enter the password, checkbox turns checked after it was all set up?
5. Maybe we should show the npub under Your key section (instead of bunker-link) - as much as I think it's an awkward thing for normies, we won't get rid of npubs any time soon, and many apps ask for it, so a quick way to see and copy it would be useful. 'What is this' would show a small explainer about npub.
WDYT?
Re. the name - we have nsec.app domain name for it, let's call it 'Nsec app' ? I store my nsec/keys in the nsec app :)
I like the style, could we also have the light theme?
Re. drawing the nip05 stuff - without it user would have to remember their npub and password to login into the Nsec app on another device. The nip05 would simplify it to email-like nip05 and password - much easier to understand and remember. So maybe nip05 could just be displayed under the user's name near the avatar - would help people remember it? And of course on the Nsec app login screen, and maybe on 'import key' screen.
Thank you for your help! #nostrdesign
I cannot reproduce your gains. I'm trying to improve the performance of our web-signer for batch-processing of decrypts.
I copied your ende.ts and replaced nostr-tools with it, absolutely no effect. In fact chrome profiler shows no time spent in base64 codec, all the time is spent on crypto stuff - keygen and cipher.
Do you have a reproducible benchmark code that shows 4k events decrypted in 2 sec? Was your measurement made in the browser or nodejs?
Are you sure shared key caching wasn't the trick? I added that and got significant improvement, although didn't work on measuring it specifically (my focus was on nip46 flow where other stuff is also slow).
Oddbean new post about login | logout
Notes by brugeman | export
A little handy update here - it will print the fetched event and profile into window.nometaPreloadedEvents={ event, profile } so that your SPA could render them ASAP without re-fetching on the client.