What is Nostr?
Zen /
npub1lgy…s73e
2024-04-05 15:14:15
in reply to nevent1q…ny8h

Zen on Nostr: I didn't realize that y'all actually responded to this, sorry for the delay! hodlbod ...

I didn't realize that y'all actually responded to this, sorry for the delay!

hodlbod (nprofile…v73f) valid point on the client seeing the password, and you identified a potential solution here. I'm not a huge fan of login portals but I'm sure that a basic one wouldn't be too much effort for untrusted clients.

Generally though, I want to make clients which are trustworthy because they are simple and independent of third-party libraries - clients where you can read through all the relevant Javascript in 5 minutes. I find it much easier to trust a fetch() call to my home server than the piles of encryption libraries in NDK - especially when a developer may have tampered with them.

fiatjaf (nprofile…pcuz) I don't think it's an XOR thing - I want to encourage everyone to be self-custodial. localhost doesn't work across devices, but if I was using a secondary device then I would just log into my account from the external address - similar to the way that nsec.app already operates.

At the end of the day, there is no practical way to transfer & share identity between two devices without relying on some kind of third party - It's Zooko's triangle, again. Domain names exist because IP addresses are difficult to remember, and NIP-05 identifiers exist for the same reason. I think that allowing those webservers to hold the same data that nsec.app currently holds (encrypted private keys that require a password to decrypt) would be decreasing third party reliance, not increasing it.

I've already started working on this because it's how I would like to interact with the nostr network. Is it worth me writing out my workflow as a NIP so that other people can review and iterate on it?
Author Public Key
npub1lgyh0e6kk78eqzy4jadqxv7u00qwehsc0q3kje99uryaumyy8vgqyjs73e