Damus
codonaft · 2d
That's not how I see acceptable NIP-07 extensions: I don't accept those that store keys at all but accept those extensions that connect to a NIP-46 bunker (Bunker46 extension in particular).
mleku profile picture
yeah, but you don't even need an extension to connect to a bunker except running a bunker you can't access local network ports without having TLS certificates installed that will allow it to do so. localhost on http is blocked. bunkers are useless if they are running on a machine not under your physical control. they have effectively closed this option off without fiddling around with certificates to bypass the browser's ban on non-TLS connections. localhost connections actually are secure, no other process can access the socket buffers.

but if you follow all the logic it's the same same if the container isolation of the browser runtime is correct, and i'm quite sure it is. what isn't, and what the claims about pasting in nsec into web apps is sketchy, is that if that app loads any scripts from anywhere else, they potentially can access the memory. everything is public, inside a web page runtime, even service workers connected to it *if it's javascript*. wasm, this is not the case, wasm WebWorkers do not expose access to either their allocated memory *or* anything that you have not explicitly exported to the javascript shim. it is trivial to do this. an extension with nip-07 and built in wasm would be even more secure, while enabling the user to use it with any number of running web apps.
1
codonaft · 2d
> you don't even need an extension to connect to a bunker Unless a client doesn't (properly) support NIP-46 but still supports NIP-07. I think we've got too many ways to sign in to web clients right now; it's confusing to users and complicated for testers. I personally found that having a single N...