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 👍
