Ah fuck. It is a good point. Typing the same password on a different kind of keyboard may actually give a different unicode representation. I did know about this but it didn't come to mind. This isn't even an scrypt specific problem, and it rarely presents, and people have probably learned not to use combining characters in their passwords. But the edge case can be solved by normalizing to NFKC. It would be a breaking change. 😆
Let's break it now before its too late.
I was able to update my code in 15 minutes, so maybe we can break it.
Devil's advocate: it doesn't matter how long it takes if the people who have the legacy version don't ever hear about it, or aren't maintaining their code any more
God's advocate: nip 49 was only recently merged in, and I think we only have gossip, amethyst and fiatjaf's tools implementing it, but I could be wrong. Also, the change changes almost nothing: 99.99% of actual passwords will work either way. Without the change, some passwords will fail to be portable between computers. With the change, no password will fail to be portable between updated clients. Devil's Advocate: But between updated and non-updated clients, even more passwords will fail to be portable than before the change.
I already had one user testing an emoji password :) Not sure if it would have broken it, but probably did.
This is really an issue between the user and the client... how does the user communicate the proper UTF-8 password to the client? It isn't strictly a protocol issue. It is the client's job to somehow get the password UTF-8 bytes from the user, and to get those bytes correctly. But the protocol can help out and ease the burden on clients if it specified NFKC normalization. I'm of two minds on this.