dtonon on Nostr: An user just informed me that he burned his nesc: he opened Iris.to to test it, ...
An user just informed me that he burned his nesc: he opened Iris.to to test it, pressed "Sign Up" and filled in the only input in the form, which actually asked for the *name*. So his nsec has been scattered and leaked to all the default relays... <add a shit reaction here>.
Of course, the error is quite silly because the top text, "What should we call you?", is clear. But it is understable if you are overthinking and are used to seeing the nsec login as the first input. In fact I already saw in the past days a couple of profiles with an nsec*** name, and now I probably know why.
This led me to reflect on a simple UI best practice that can mitigate this sort of problem: filtering.
- If you are developing an app, check and filter the inputs, preferably client-side: if the user pastes a nsec in a non logical place (name, bio, pubkey field, etc.) reject it. When composing a note, it could make sense to ask for confirmation, highlighting the risks. The same confirmation procedure should work well for hex keys.
- If you are developing a frontend toolkit, you can probably help to automate the previous point by offering different input/textarea types with built-in validation.
Side thought: it is easy to confuse "Sign Up" and "Sign In". "Login" and "Create account" seem like a more distinctive and effective labeling. The mentioned user began to fail in this first step, thinking he was logging in, when he was instead going through a registration process.
Let's make Nostr easier and safer.
/cc Martti Malmi (npub1g53…drvk) Kieran (npub1v0l…qj49)
#nostrdesign
Of course, the error is quite silly because the top text, "What should we call you?", is clear. But it is understable if you are overthinking and are used to seeing the nsec login as the first input. In fact I already saw in the past days a couple of profiles with an nsec*** name, and now I probably know why.
This led me to reflect on a simple UI best practice that can mitigate this sort of problem: filtering.
- If you are developing an app, check and filter the inputs, preferably client-side: if the user pastes a nsec in a non logical place (name, bio, pubkey field, etc.) reject it. When composing a note, it could make sense to ask for confirmation, highlighting the risks. The same confirmation procedure should work well for hex keys.
- If you are developing a frontend toolkit, you can probably help to automate the previous point by offering different input/textarea types with built-in validation.
Side thought: it is easy to confuse "Sign Up" and "Sign In". "Login" and "Create account" seem like a more distinctive and effective labeling. The mentioned user began to fail in this first step, thinking he was logging in, when he was instead going through a registration process.
Let's make Nostr easier and safer.
/cc Martti Malmi (npub1g53…drvk) Kieran (npub1v0l…qj49)
#nostrdesign