user A gets secret A and user B gets secret B and they can't communicate

it's a 2x2 grid, two cases where A and B pubkeys are 3s you can't get the same shared secret

most generators already either reject 3s or subtract the curve order from the secret to get the opposite sign, but even with this in mind you still have teh problem that you have to try a second one to test if it's just the wrong one and that only gives you 25% of cases where they are wrong, in the other direction, where you guess the pubkey prefix/sign, it works

i have seen this in DMs before and it was infuriating, but i didn't test it enough, i'd generate a key, have problems, and without knowing what was going on, that key would be discarded and another one generated, and 50% of the time it would work and seem like the stars were out of alignment, but it's a bug in the protocol that needs to be strongly stipulated about the keys being ONLY 2 prefix, even pubkeys because of ECDH

the ways around it are difficult, the only solution i see is signalling optionally in kind 0 if you have an odd pubkey

that solves the problem

if two people have 3 keys and their software guesses 2s both sides can't communicate, otherwise, you have a case where one way works the other doesn't 

 I guess what I'm trying to say is, from a libraries' perspective, there is no way (unless the caller tells me) for me to know what the proper sign is. It will just happily decrypt garbage and return it to the user. I can't know if the decrypted data is correct. In nip44 we can check the MAC, but for nip04 you just have to hope for the best?? 

 all events have a MAC in fact, the presence of it in NIP-44 is redundant, that's what the event signature is

it doesn't have to authenticate on the plaintext after you decrypt it, if you already certified the ciphertext

this is another retarded element of nip-44 

 But I still can't know if the decrypted plaintext is correct. That's what I'm saying. The signature tells me nothing about the plaintext 

 yes, this is correct, you would have to have a sentinel to enable this, the first byte even it could be, or maybe better first 4 bytes to eliminate the chances of decrypting the same by both 

 also, yes, you don't need that bit for signature verification, that's one of the neat things about Schnorr signatures

but it does not apply to ECDH 

 two points though

one, having to decrypt the whole message and then discover you need to flip the bit is wasteful of computation and time

two, it still doesn't fix the problem of two 3 key users with software imputing 2 keys