Is Clave the only #iOS NIP-46 singer published on AppStore/A...
npub1alptdev5srcw2hxg03567p4k6xs3lgj7f6545suc0rzp0xw98svse7rg94
hex
0000199b1620b09bdb34d6d2142b72e5ff0906bfe5d394cbf2e7a1e04f68626anevent
nevent1qqsqqqqenvtzpvymmv6dd5s59dewtlcfq6l7t5u5e0ew0g0qfa5xy6sprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgswls4kuk2gpu89tny8c6d0q6mdrggl5f0ya226gwv833qhn8zncxg4y3c2vKind-1 (TextNote)
Is Clave the only #iOS NIP-46 singer published on AppStore/AltStore today? #asknostr
And why do we still allow pasting a raw nsec/ncryptsec into the clients? Why? Something is still not working with these signers? Somebody believes that all clients actually securely store the secrets, properly zeroize memory after exiting, and so on?
Properly managing these secrets was never an easy thing to do. It should never be delegated to some random vibe-coded stuff, that was not designed specifically for that; very few normal users are capable of understanding the significance of that, yet we happily provide them an input field for nsec like it's something acceptable!
This is, BTW, the only signer I'm aware of that hardens memory with mlock; there's nothing close to that in normal clients and probably never will be there:
https://laantungir.net/git/laantungir/n_signer
I've recently had an experience of explaining why pasting nsec should never be practiced with ordinary clients, why it's not the same thing as a changeable password—yet this person pasted it anyway to "fix" something: Armada Android client was failing to publish a NIP-65 relay list. This will never change: if there's a wrong button, it will be pressed for stupid reasons, many times.
I think the "nsec SHOULD never be used directly in clients; NIP-46 and NIP-07 SHOULD be used instead" should be written in some NIP already. With blood.
#security #devstr
nostr:nevent1qqs9jjzlsd858yc97waddzs8l5gjcvzerwme5sfg3psla2ugdt0jmdspz4mhxue69uhhyetvv9ujuerfw36x7tnsw43qmdwlup
原始 JSON
{
"kind": 1,
"id": "0000199b1620b09bdb34d6d2142b72e5ff0906bfe5d394cbf2e7a1e04f68626a",
"pubkey": "efc2b6e59480f0e55cc87c69af06b6d1a11fa25e4ea95a439878c41799c53c19",
"created_at": 1787749853,
"tags": [
[
"L",
"ISO-639-1"
],
[
"l",
"en",
"ISO-639-1"
],
[
"q",
"59485f834f439305f3bad68a07fd112c30591bb79a41288861feab886adf2db6",
"wss://relay.ditto.pub",
"0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd"
],
[
"p",
"0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd"
],
[
"t",
"ios"
],
[
"t",
"asknostr"
],
[
"t",
"security"
],
[
"t",
"devstr"
],
[
"nonce",
"163691",
"17"
]
],
"content": "Is Clave the only #iOS NIP-46 singer published on AppStore/AltStore today? #asknostr\n\nAnd why do we still allow pasting a raw nsec/ncryptsec into the clients? Why? Something is still not working with these signers? Somebody believes that all clients actually securely store the secrets, properly zeroize memory after exiting, and so on?\n\nProperly managing these secrets was never an easy thing to do. It should never be delegated to some random vibe-coded stuff, that was not designed specifically for that; very few normal users are capable of understanding the significance of that, yet we happily provide them an input field for nsec like it's something acceptable!\n\nThis is, BTW, the only signer I'm aware of that hardens memory with `mlock`; there's nothing close to that in normal clients and probably never will be there:\n\nhttps://laantungir.net/git/laantungir/n_signer\n\nI've recently had an experience of explaining why pasting nsec should never be practiced with ordinary clients, why it's not the same thing as a changeable password—yet this person pasted it anyway to \"fix\" something: Armada Android client was failing to publish a NIP-65 relay list. This will never change: if there's a wrong button, it will be pressed for stupid reasons, many times.\n\nI think the \"nsec SHOULD never be used directly in clients; NIP-46 and NIP-07 SHOULD be used instead\" should be written in some NIP already. With blood.\n\n#security #devstr\n\nnostr:nevent1qqs9jjzlsd858yc97waddzs8l5gjcvzerwme5sfg3psla2ugdt0jmdspz4mhxue69uhhyetvv9ujuerfw36x7tnsw43qmdwlup\n",
"sig": "e5e241e08b824e314bf1f67ea3eaae76611fc02ba93bdd0ed8211c1e9f914efda26e37caa65fcbc3aa8eb93b804b96c099c86523ccf4e282cdff7343e09eb41e"
}