Replies (52)
True
This also applies to web apps with nos2x-fox
Some apps have even somehow broken my nos2x-fox installs on Android so I have to go through pages of dead permission prompts to get to the active one every time there is one
Another issue is developers of native apps using the amber package name as a constant instead of getting it from the get public key method
This way you stop people from using another signers like nowser
If you expect every users to know what they are signing every time, Nostr will appeal to those that build on it, not general users.
Itβs a problem that exist on Ethereum now, app basically ask their user to verify the URL to not get hacked.
People will sign stuffs blindly, off course they will
This is correct, with Blockcore Notes (that I developed) it rarely asked for signing. For Nostria, I'm very much focused on limiting the amount of signing requests. Once you have provided the public key, that is enough. Only if you completely sign out, it should be requested again.
Primal asks for my pubkey all the time, signs empty settings, etc. I created an GitHub issue for it, hopefully they can improve it.
Sign in with a
@npub17tyk...3mgl would be pretty dope.
Shaving Kiwi waits for manual confirmation.
I tried
@primal with this. It's not only literally unusable but you notice it's signing crap events of kind 1000160 and things like that.
I've used Amethyst and Yakihonne on Android with Amber. I think Yakihonne is much more usable than Amethyst.
I mean Primal Android, I talked to Marko about it. Web probably signs similar tracking events?
I don't remember all the issues I've had but here is a quick review. if you want to know about any app in particular I'd be more than happy to find something to complain about
Android:
- Amethyst: Unusable, spams amber with 100+ decryption requests and NIP-42 auth even though I'm not viewing DMs
- 0xchat: one of the recent updates causes it to keep asking for NIP-42 auth events even after they are signed
- primal: keeps asking me to sign a 6+ 10000300 events, but will eventually be usable after I sign 6+ of them
Web:
I use nos2x-fox for NIP-07 signer
- yakihonne: last two times I visited it, it crashed by computer by opening too many decryption request windows ( partially an issue with nos2x-fox )
- primal.net: asks me to sign 4-5 kind 30078 events as soon as the app is open, but it does let me reject them
- snort.social: asks me to sign 2 events as soon as the apps opens, but after that its fine
- plebeian.market: wont stop asking me to sign NIP-98 events, but useable if I ignore them
- coracle.social: Asks me to sign NIP-42 events and a few decryption requests as soon as the app opens, and keeps asking for NIP-42 randomly as I use the app
- flotilla.social: asks for 6+ NIP-42 events as soon as the app opens, but is usable after signing one for each relay
- chachi.chat: same as flotilla, asks for NIP-42 for every relay and one decryption request. then becomes usable
Love it. When Amber first came out I didn't give it any permissions. It works great with Amethyst. I was happy to have granular signing control. Felt like the point.
Everyone was crying for one tap zaps, and I am like, I want to sign for sending my money!
how wired that coracle sneaked in a link on my post nmm
I think this is "you will change when you experience pain". It's when an incident by an automated signature occurs. However it's great to call for action now!
Many apps should support it, right? Because many apps had supported multiple signing methods.
It should work without extension also or any new person trying it out will say nostr is just broken, as they do today
Yes, however some apps are more broken as soon as you have an extension: )
I'm also looking into signing using XTAG 424 DNA NFC tags/cards. They support on-board secp256k1 signing. Might be possible to get working using Android.
What is your definition of unusable in the context of UX? When the signing confirmation modal of the extension pops up randomly without any interaction logic / user input?
Interesting π€
For android any signing request will switch the app over to amber, so if one signing request pops up its not bad. but when there are 5+ in a row it becomes unusable. in the worst case it never ends
For web the signer takes focus away from the window, so its annoying but sometime manageable if I ignore some of the signing requests
π―
What often bother me (and is maybe even worse) that if I decline a signing request, often nothing happens or things are just freezed.
"What's the point of having cryptographic signatures if I can only uses them in "sign everything" mode?"
With asking this question, you also state / assume that the user will fully distrust the client? Which is a good and fair point to start with imo :) but over time, your client could gain trust
Considering that there can be anything for anything on nostr, and there being a lot of kinds, here's a better solution (UX wise, a decent compromise between full trust and manual: Timed Trust):
Provide a new option for signers to implement:
"Fully trust for the next TIME"
TIME: 15 minutes, 1 hour, 6 hours, 1 day, 1 week, 1 month
Extra: to add custom timings the user can change.
I forgot about nostrmo, just tested it again and it does work as long as I accept all its NIP-44 decryption requests. however if I try to reject any signing or decryption request it just keeps asking me forever, which make the app unusable π
Gonna have to try this out. But I'm willing to bet, even in manual signing mode I'm not even going to understand what the f I'm giving permission to sign.
If memory serves correctly, a lot of the time this isn't presented in a very human readable way - or maybe I'm just stupid.
Jumble rarely requests signing events π
I forgot about that, I think ill try to use it more
What libraries are you using for the app?
Only nostr-tools, haha.
Since the app is simple and I personally find constant signing requests annoying, it rarely needs to sign events.
why is it annoying?
hzrd149
For all the Nostr developers out there I challenge you to use your apps in manual approve mode ( no automatic signing ) with a signer like alby or amber. I'm willing to bet it will be almost unusable
I would say at least half of the apps I've seen built on Nostr just don't work unless you give the app full control over your key, by either pasting the nsec or giving it automatic signing privlages.
This is bad UX and shows that the app does not respect the user at all. What's the point of having cryptographic signatures if I can only uses them in "sign everything" mode?
I will zap you 10k SATs if you post a screenshare in the next day or so of how well the app works or doesn't work with manual signing
View quoted note →
real talk, doing this from now on.
i just don't think client devs are qualified to speak about the subject of spam mitigation countermeasures, let alone mitigating impersonation attacks or sock puppets
i find it incredible that you don't even have experience with running an SSH server on a VPS and have never looked at the endless logs of attackers trying to breach your server with common passwords
it's not optional, and your comments, and hzrd149s demonstrate why a network protocol designed by client devs is going to be a failure
you don't remember reply guy?
We might not be talking about the same thing. What we're discussing is how most clients constantly prompt users to sign events, and if users refuse, the client becomes unusable.
By the way, my main job is backend development. I only started learning frontend development earlier this year.
clients must sign the events or the relay will not accept them, unlike clients, relays don't have the ability to skip that step
the signer is the issue then, but i personally dispute the theory that a web app can't be trusted to keep keys
most shitcoin web apps keep keys in the browser, there is strong isolation in web browsers now in part because of the amount of apps now existing that need to make and check signatures, i mean, the app i'm building part of the back end infrastructure for right now even uses a third party web service called web3auth that secures the key for users, i mean, lol, nostr devs worrying about their singular client app leaking secrets is quite laughable, and then on top to be complaining about then how signers, which are supposed to implement policies for signing, both bunkers and extension signers, i fail to see what the basis is for the complaint
i'm inclined to even say that if i was to build a web based client (and i'm part way through building a bunker) that i'd probably retain the option of the user being able to sign in with an nsec
the danger of breach is way overblown, browsers are not as insecure as they were even just 5 years ago, and back in 2016 i was using a web app that signed events to publish to a blockchain forum system was all there and literally zero incidents of people losing control of keys. 9 years ago.
You still donβt get what weβre talking about π
no, because it's very unclear and to me it just sounds like you are complaining about signers being burdensome on users, and outside of your control as client dev
i think i made the point pretty clearly that you DON'T have to kow-tow to the idiotic consensus that you "must use detached signers" for it to be a secure app, the only real concern is that users may become complacent about rogue apps, but equally they could become complacent about signers if more of them existed, so really the problem is moot, eggs, basket, same same
imagine how it is as a relay dev when for 6 months of the time i was in development with #realy, i couldn't find a client that actually let me point at my relay and ensure it was even working??? it just seems like a petty complaint to talk about UX of detached signers when you do have the option of controlling that yourself as client dev, not only that, you could bundle your own signer, there is already several forks of nos2x and you could just make your own that has sane policies built into it that fit your needs
what is it that i'm missing here?
hzrd149
I forgot about nostrmo, just tested it again and it does work as long as I accept all its NIP-44 decryption requests. however if I try to reject any signing or decryption request it just keeps asking me forever, which make the app unusable π
View quoted note →
so the subject is the shitty performance of web browsers at computing ECDH shared secrets?
i already had this out with hzrd149 about the subject and he was getting flak from a lot of people about not enabling a policy of decrypting all messages
it's quite hilarious anyway because so few clients even support DMs properly, that i abandoned even using nostr DMs about 6 months ago because they are so unreliably implemented
if this is what the complaints are about, then i see how it came to be that client devs have abandoned supporting DMs, why jumble doesn't support them. the signer has no complaints about allowing me to forever allow decryption requests, i just utterly fail to see what your and hzrd's point is about this subject
i could be wrong but i'm pretty sure even that the signer extensions are even implemented in native code and are actually quite fast
not only that, because i'm a relay dev, and constantly watching logs of what the client is doing, the number of times i see jumble pushing encrypted events of configuration events and mute lists also makes me really wonder what you are talking about, and maybe you have somehow forgotten about my issue, ongoing, with the lack of ability to disable private mutes in jumble?
this is a feature that kills all of the benefits of jumble for me as a relay dev because i depend on public mute lists to implement a blacklist for pubkeys on my relay, as soon as alexandria is into release i'm not going to be using any clients funded by opensats, for reasons of the endless instability and lack of minimal features required for my work, i know that stella cares about what us relay devs think because she knows that we are building the foundations of this protocol, and ignoring it is like expecting a building to stay up without laying foundations to stop the ground shifting and collapsing the walls
This thread is hilariously off topic. what I was referring to was how clients are commonly built expecting the user to automatically sign every event they request a signature on. or put another way they have no concept of the user reviewing or possibly refusing to sign an event so they tend to randomly ask the user to sign 10+ events in a row without any context to why the events need signing
This generally makes then unusable for me since I normally use all nostr apps in "manual approve" mode where I can review each event it wants me to sign.
The worse offenders are the apps that keep asking me to sign an event or decrypt something even after I've refused, or apps that randomly ask me to sign NIP-42 events while I'm simply browsing global or my timeline
@hodlbod screen recording of trying to use flotilla in manual approve mode. also it does not let me reject signing anything
I'll look into making it fail more gracefully. There is a trade-off between scope and trust though, and for coracle and flotilla I'm on the wide scope and high trust side of things. A lot of these approvals are used to probe relays to figure out what the user is allowed to do. I don't think every client should necessarily be sparing about signatures. "Sign everything" is a valid mode for some applications.
Hope you caught onto the topic by now, but I'm just chiming in to say I agree clients should retain the option to login with nsec, which Cody Tseng's jumble client does retain π
that's a fair point. it would just be nice if I could reject some of those and still have parts of the app work. or at least make it request the signatures when it needs them instead of when the app opens
Yeah, it could definitely be more graceful
so, you want to review every signature, but you hate having to click on the approve? got it.
I am still undergoing crazy debugging nightmares around my still broken nip46 work. But part of what keeps slowing me down are all these manual approvals. Sometimes I forget about them and wonder why the 2nd client is hanging... because it is waiting for my approval. Today I discovered that at least one of the reasons gossip was freezing was related to my desktop environment and not gossip itself (!) and removing gnome and kde packages fixed at least part of my nightmare. Hopefully I'll get it down to just one reason: the bug I'm after.
Even
if you're looking for aa more client-ish app
