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?
Zen /
npub1lg…js73e
2024-04-05 15:14:15
in reply to nevent1q…ny8h
Author Public Key
npub1lgyh0e6kk78eqzy4jadqxv7u00qwehsc0q3kje99uryaumyy8vgqyjs73ePublished at
2024-04-05 15:14:15Event JSON
{
"id": "52deefe0e62d430fba5baad10d99e149a71a480edb693b51ae04511ab80ed2eb",
"pubkey": "fa0977e756b78f900895975a0333dc7bc0ecde1878236964a5e0c9de6c843b10",
"created_at": 1712330055,
"kind": 1,
"tags": [
[
"p",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
"wss://pyramid.fiatjaf.com/",
"hodlbod"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"wss://countries.fiatjaf.com/",
"fiatjaf"
],
[
"e",
"e27b207a3c0871648b6ce91f6bed589e66fc1821a3b30014e4c0dcfd102034bd",
"wss://hodlbod.nostr1.com/",
"root"
],
[
"e",
"c92f738d77bbf69cd99a65ef99dd57914e03c49955634ea084ad549418245a8b",
"wss://relay.westernbtc.com/",
"reply"
]
],
"content": "I didn't realize that y'all actually responded to this, sorry for the delay! \n\nnostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qguwaehxw309a5x7ervvfhkgtnrdaexzcmvv5h8gmm0d3ej7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshszythwden5te0dehhxarj9emkjmn99uqzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cez4sv73f 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. \n\nGenerally 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.\n\nnostr:nprofile1qyw8wumn8ghj7cm0w4h8gunfv4ejuenfv96x5ctx9e3k7mf0qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsqgpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5uppcuz 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.\n\nAt the end of the day, there is no practical way to transfer \u0026 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.\n\nI'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?",
"sig": "c491cd8d26cf0c938060f0347bea4d95ecea06c8f13071431864e440cff8cd30ad454f74eacc500ef7611884866963b492a67cd191d2034408a5bf64cb7a104a"
}