emoji/unsafe identifiers and identifier collisions

[skibz]

as discussed previously:

• emojis found in chat identifiers are converted to emojitag, and then have their unsafe characters stripped using the existing regex solution

• identifiers that have already been encountered are given an integer suffix to make them distinct

• adds test (util_test.go) to assert behaviour is correct

• adds a dependency (😭) to help with managing emoji

• add missing empty string test cases

• add test cases for other types of invalid irc nicknames (eg: $$$)

• implement an encoding solution for said nicknames

[skibz]

i just realised now while looking at the diff that i should not have exported ircSafeString because there is already SafeString exported. sorry about that! i will fix this up as soon as possible.

[skibz]

it also just occurred to me that the tests i've written never assert that a resulting identifier is not an empty string! which is totally missing the point of this whole exercise 😄

i should also have a test case for when an identifier is entirely composed of non-emoji special characters.

what i'm thinking is that if someone has the name $$$ in whatsapp, they'd also end up with an empty string for name. so ultimately we'd have to find a new encoding to use for those sorts of names.

perhaps we could convert those names to a string containing the original identifier's hexadecimal representation, then prefix it with a safe character (like x or something) so that it doesn't look like a phone number.

eg: using the original example name $$$ the encoding i'm proposing would result in the name x242424.

a client can then also decode the name back to $$$ quite easily.

[lieuwex]

The problem with appending a number at the end of the identifier is is that the order of the chats in memory is arbitrary, so after a restart the identifier<->chat mapping can be completely different, or not, it depends. We should maybe add some ordering to the chat list as well.

About the issue with completely empty chatnames, I'm not sure what to do. I guess hex is a solution, I don't think it happens too often. So everything goes, I guess.

[skibz]

The problem with appending a number at the end of the identifier is is that the order of the chats in memory is arbitrary, so after a restart the identifier<->chat mapping can be completely different, or not, it depends. We should maybe add some ordering to the chat list as well.

oh man, i hadn't considered this. what sort of ordering do you propose? maybe there's a way we can side-step this problem entirely. is there a data-point provided by whatsapp that could be used to uniquely identify contacts?

[lieuwex]

is there a data-point provided by whatsapp that could be used to uniquely identify contacts?

IDs, but they aren't user friendly per se, I guess.

[lieuwex]

Okayyyy, due to some difficulties in how I wanted to fix the problem, I have merged your PR as 6732fee. The tests are missing, I don't really care, but if you do you can rewrite them since the code is a bit changed now :P. Thanks!

[skibz]

🍾