The nsec app signup flow (at least on mobile) is terrible. It asks you for a million permissions, on top of the browser permissions, and when you grant them all, it asks you again for a new kind.
Did you sign up through the nsec app itself, or through the oauth signup flow from another app? Asking for new kind is probably due to app requesting to sign something right after you sign in. The other million permissions should be just one - connect to the app (this could probably be avoided, I could bundle it into create account button itself). Browser permission is a must, unfortunately. If you have any ideas on how to improve it I'd be very happy.
other app. I don't know what all it asked for but it was too much to click. I will check it out again soon.
@Kieran how about we make apps declare the perms they'd like to have from bunkers? So that connect requests could show the exact list of perms the app needs (not some default list), and also create_account would grant all those perms and thus wouldn't result in extra perm requests right after signup? Those could go to nostr.json in some separate section. Could also go to app's nip89 announcement, but the domain would have to point to that first, so it's less direct. cc @fiatjaf @PABLOF7z
Would be great. Same needed for create_account. It could be a comma-separated list of requested perms "perm1,perm2", each perm being nip46-method + optional param (kind, peer pubkey etc), like "sign_event:1" or "nip04_decrypt" or "nip04_encrypt:peer_pubkey_hex". Wdyt?
Added this - the last param to connect and create_account is the list of requested permissions, i.e. sign_event:1,sign_event:3 implemented at nsec.app and nostr-login, check in action on nostr.band. Any feedback? Should we be adding this to nip46? https://i.nostr.build/o9rx.jpg
I like it. nostr:nprofile1qyghwumn8ghj7vf5xqhxvdm69e5k7tcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpql2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afq85ne77 nostr:nprofile1qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qythwumn8ghj76twvfhhstnwdaehgu3wwa5kuef0qy2hwumn8ghj7mn0wd68ytn00p68ytnyv4mz7qpqgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqjt2msn nostr:nprofile1qyfhwumn8ghj7mmxve3ksctfdch8qatz9uqsuamnwvaz7tmwdaejumr0dshszxthwden5te0dphkgmrzdajzumn0wd68yvfwvdhk6tcqyztuwzjyxe4x2dwpgken87tna2rdlhpd02va5cvvgrrywpddnr3jyhdw0my nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgswaehxw309ahx7um5wghx6mmd9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqs0l5m4adqwkjrx26sz3mduswp97k8lp4wy5xaz9lnhghfgg5576zqgghzjt nostr:nprofile1qy88wumn8ghj77tpvf6jumt99uq3uamnwvaz7tmjv4kxz7fwdehhxarj9emkjun9v3hx2apwdfcz7qglwaehxw309ahx7um5wgkhyetvv9ujumn0ddhhgctjduhxxmmd9uqzqynpqwlamjxly44kuz4l6lehjlyqmnzw4z8hctu8m4qsggstf4jl6p64r3 nostr:nprofile1qyt8wumn8ghj7un9d3shjtnwdaehgu3wdejhgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsqgqh88vn0hyvp3ehp238tpvn3sgeufwyrakygxjaxnrd8pgruvfkautfdgl3 nostr:nprofile1qy88wumn8ghj77tpvf6jumt99uq3kamnwvaz7tmwwfjkccte9e3j6um5v4kxcctj9ehx2ap0qyghwumn8ghj7mn0wd68ytnhd9hx2tcqyrgazar3zhgkw5df0s3e73hvzupjjtpm06vc3w0tm48vguzmzhk5gd07gxp what do you think?
Yep, we already use a similar thing for Amber, @greenart7c3
Isn’t it too complicated for normies to understand technical/dev terms without a clickable explanatory statement?!
We're discussing the protocol level, the UI on screenshot is just the first implementation of it, we will make it more meaningful and simple later.
Excuse me for interfering in your technical discussion and allow me to annoy you with another question; Nostr provides some addresses such as NIP-05 (account verification address) or Alby’s addresses etc., wouldn’t it be useful to allow users to have email accounts using the obtained addresses?! (So that the email and the generated password can be connected somehow to any Nostr client without the nsec and used for third-party login?!
Sorry, I didn't mean to discourage you from providing feedback. Some nip05 services also provide email service using the same name, but not sure if that's relevant here. The nip05 and password can be used to sign in to (soon to be) any nostr client using nsec.app or other nip46 implementations. Try signing up on nsec.app (or import your relay keys there) and then you can use your name@nsec.app to sign in to nostr clients like Nostrudel, Snort, Habla etc.
Yo, that great. I just have small suggest is instead of use "event of kind 3", you can change it to "text event", "metadata event",... it more friendly than number
Isn’t it too complicated for normies to understand technical/dev terms without a clickable explanatory statement?!
We're discussing the protocol level, the UI on screenshot is just the first implementation of it, we will make it more meaningful and simple later.
Excuse me for interfering in your technical discussion and allow me to annoy you with another question; Nostr provides some addresses such as NIP-05 (account verification address) or Alby’s addresses etc., wouldn’t it be useful to allow users to have email accounts using the obtained addresses?! (So that the email and the generated password can be connected somehow to any Nostr client without the nsec and used for third-party login?!
Sorry, I didn't mean to discourage you from providing feedback. Some nip05 services also provide email service using the same name, but not sure if that's relevant here. The nip05 and password can be used to sign in to (soon to be) any nostr client using nsec.app or other nip46 implementations. Try signing up on nsec.app (or import your relay keys there) and then you can use your name@nsec.app to sign in to nostr clients like Nostrudel, Snort, Habla etc.