Oddbean new post about login | logout you are saying allow 66 character pubkey fields tho, or what?
No. Let me be very clear now. Dont change the protocol. Let 3s exist on the network. Dont touch it, dont break what we have. I have no proposal. Whatever workaround you want, is find by me. Just dont change the protocol. Im specifically not getting involved, because I dont want the protocol to change. I'll just cross my fingers on that, tho!
ah, yes, so you are gonna do the same as what the rest of them do because of the survivorship bias of not seeing the users who left for reasons of not being able to use DMs, helpful.
it is the fault of the NIP maintainers also, btw, because BIP-340 clearly states this but then again BIP-340 is horribly worded as well, it took me some time to figure a lot of it out... my fork of btcec has the extra 4 test vectors in the test suite that roasbeef refused to bother to complete, i even handed it to him on a platter
It's not that. There's tons of ways to do a DM already. They all work. Cant really invalidate user accounts on an existing system, that prides itself on users not being able to be cancelled. That would go against the marketing. Devs will just have to find another way, of which there are multiple, and they'll figure something out.
yeah, i've been thinking about it, because i have part way done the tooling to manage a paid relay service using DMs and for the customer side we need to be able to tolerate anything, so there's things that can be done one, the relay will never generate or use 3 keys, that's now fully fixed in my codebase two, the initial messages with a user will send out assuming both 2 and 3, and each one will have a different string that the user is asked to paste and return, and this will confirm, and if 3 keys are discovered they will be stored in the database - probably just make a public event with a note saying "this key is an odd key" so others can discover this after that i think that is enough measures other than simply pointing it out to the nip guardians that their protocol uses ecdh without strict odd prohibition (as you say, you can either roll again for a 2 or you can modulo subtract the curve order G from the key and voila - considering this avoids needing to derive the key again i might need to revisit this option