Hmmm… so valid nostr npubs are all supposed to be ‘even’ (y coordinate is always even)? I was wondering about that because the pubkey is 32 byte hex, while ‘compressed keys’ are supposed to be 33 bytes where the first byte denote odd or even (0x03 or 0x02). Do all of the nsec generation algorithms generate to even points only?
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgwwaehxw309ahx7uewd3hkctcpz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hszynhwden5te0dehhxarjxgcjucm0d5hszxnhwden5te0dehhxarj9e6xsetnv9kk2cmpwshxjme0qqs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crsjtrhkf i only just yesterday became alert to the fact that unofficially nostr npubs are supposed to be "even" - and this impacts direct messaging because the encryption doesn't work if you expect them to have a 2 pubkey and they actually have a 3, they cannot decrypt your message, and probably clients just ignore it and don't show it.
it's the secret problem of nostr and why DMs have been broken the whole last 19 months or so how ever long it has been
see here:
https://github.com/nostr-protocol/nips/issues/1398
please weigh in on this
i think we are past the point we can fix this by "making" key generators check for a 2 pubkey, we need to start broadcasting this and then clients need to check for it and flip the ecdh so DMs work
i'm almost certain now that why DMs have been such a mess in nostr is because of this bug in the protocol
i think that it's fine to have all keys expected to be even keys, but we need an optional field in kind 0 to signal an odd key
Discussion
No replies yet.