Maybe send that optionally as the third argument to "connect"?
nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 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 nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft
Discussion
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?
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, nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
I think Amber and nsecbunker do something like this already. I agree, it would be nice to formalise it in the spec.
Yeah, this sounds reasonable to me
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.