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

Reply to this note

Please Login to reply.

Discussion

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 nostr:nprofile1qqs09jtvjlmyrxjn37zv70a89csegcz7rpyqjmnw29cveedhv7vagqqpp3mhxue69uhkyunz9e5k7qg4waehxw309ajkgetw9ehx7um5wghxcctwvs4hl7w6 would be pretty dope.

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.

It's uh, relentless depending on the app. Too many things to sign - hence why it's extremely annoying. Too many assumptions were made. I don't want to - but have to allow approval by default otherwise I'm inundated by all the signing requests.

I tried nostr:nprofile1qqs9xtvrphl7p8qnua0gk9zusft33lqjkqqr7cwkr6g8wusu0lle8jcpp3mhxue69uhkyunz9e5k7qg4waehxw309ajkgetw9ehx7um5wghxcctwvsqs6amnwvaz7tmwdaejumr0ds2g5zx8 with this. It's not only literally unusable but you notice it's signing crap events of kind 1000160 and things like that.

https://github.com/nostrability/nostrability/issues/195

nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 can you name the extension, and clarify if you mean primal web?

nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr which extension(s), and which app(s) did you experience this pain with?

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

This is great, ser. I tagged the respective devs on github https://github.com/nostrability/nostrability/issues/195#issuecomment-2891304844

I've used Amethyst and Yakihonne on Android with Amber. I think Yakihonne is much more usable than Amethyst.

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!

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.

https://video.nostr.build/6cb8a739de4c79f31c5c3c0f5428d0c274a013efbd4156d45dd065ed89f5ec72.mp4

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 😞

https://cdn.nostrcheck.me/1b6d998f47e7947b99466c626fa6ad76bed20779e2e8d76428968ae878b538e0.webm

Thanks you notice me that the nip-55 had add a **rejected** column field to the result. 🌹

I will handle it later.

https://github.com/nostr-protocol/nips/commit/57c84cc87a75e8598004530556fc5988dfc26c49

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: )

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?

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

Im always on paranoid mode on Amber.

I always review what I sign.

To keep some apps usable, I auto disallow some signings sometimes. But auto signing feels like a big no no

Interesting 🤔

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.

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?

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?

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

so, you want to review every signature, but you hate having to click on the approve? got it.

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 👍

real talk, doing this from now on.

nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn screen recording of trying to use flotilla in manual approve mode. also it does not let me reject signing anything

https://cdn.hzrd149.com/539f12c9efc4816fa1d5a69445c0475390bee10d7307ba8e3d49c7fef079e3c2.webm

https://cdn.hzrd149.com/28d77c9ddfe9cde71319670298ef48cb07436dc3a77172de24d2c24df18612d1.webm

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.

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

Use https://formstr.app works well with manual signing, infact it's been a priority for me that it does.

Even https://pollerama.fun if you're looking for aa more client-ish app

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.