Oddbean new post about | logout
 We're working on a new design for the Damoose safari signer extension, it will be much different then the way Nostore currently works. The basic idea is instead of manually approving each request one by one, it will display a summary of all of the requests at once, with a high level description of what is happening:

nostrapp.com wants to:

- Decrypt 10 DMs ✅
- Update app settings ✅
- Update your profile ✅
- Nuke your contact list ❌

From here you can allow all or deny specific actions by tapping on them individually. 
 Maybe take some input from how Alby handles signing requests and allows denials 
 I've used that a few times but I never found it super intuitive 
 Its one by one as requests come in and you can choose whether to be asked again or not for future requests. Fairly logical, but not the best UX given how nostr event signing, encrypt and decrypt happens at different points asynchronously in response to whats going on. 

Addressing that may be improved if web apps enumerated permissions they want/need up front (and why) and allowed users choice in the same way android and ios app permissions are granted.

As a user, I really dont like arbitrary prompts wanting to decrypt without context. Last thing I'll tolerate is one wanting to deceypt DMs when im not even looking at DMs. So anytime decrypt is requested, context needs given to the user. FWIW, this is why Corny Chat asks the user if they want to decrypt n number of petnames. 
 when i say app enumerating permissions, i mean all the types of things the app could do, even if its not doing it at that time.

reprompting every X time (once a day?week? month? forever?) and ability to revoke/clear such grants would be useful  
 I've been thinking about this, I definitely prefer always having granular control of what is signed and what is not signed on a case-by-case basis, but I am a power user, so will have to see how other people prefer to use it. 
 That is preferable, but if you get pop ups all the time you take an action it leads to notification/confirmation fatigue. Best if it pop ups the first time and asks you for reasonable settings, and if you wanna go super custom then you can do that as well.  
 Alby (at least, used to) doesn't allow concurrent pending requests, and most apps don't do concurrent requests, how do you know these are the actions the app is about to execute, except for the first one? 
 Well its all async, there's no reason why an app couldn't make many concurrent requests at once, like when decrypting 100 notes.

It maintains a queue of requests (which contain promises that get called on approve/deny). The auth window gets updated in realtime, and then there is a button to lock-in and review incase they try to add something at the last moment without you noticing. 
 That's correct, what I am saying is that for whatever reason, maybe bcs it wasn't supported by other extensions, most apps don't do this, and if started would get errors from existing extensions, and thus it's not gonna be of any benefit for most apps.  
 hmm I guess that's ok for now, as it will show only one things instead of many, and it will be ready for future app updates. 
 We tried this with nsec.app, and went back to one req per confirm screen, because then there is more space for showing details of what the app is doing - raw json, raw encrypted payload, users added to contact list etc. Just saying, if that adds something to your design decisions. Maybe also check Amber, they are quite ahead of the curve here, i.e. support approval by nip, not just kind. 
 we will likely have a drill-down option, but I think we can fit a high level overview in a half-popup on the page 
 raw json is for nerds, most people won't know what they are looking at. I'm going to try to have ways to describe what is happening without having to show any json. of course there will be a way to view the json, but in reality most people won't be looking at that. 
 100% that's the way, but json is still necessary. This and all kinds of things the app might be doing is not trivial to design for, at least for me. 
 this is why I put it as challenge to rob xD 
 good point on the nip/kind distinction though. I think by nip makes sense. 
 I think manually defining categories may be better than NIPs because some NIPs you may want to only partially authorize for 
 forcing raw json on a man is akin to demanding a duel 🤺