Support for notification "threading"

[kylef]

To be able to group message notifications together by a buffer (in APNS terms that's notification threading which is achieve by attaching a theadId to the notification). We need to construct a thread identifier which is unique to the buffer. There is a proposal at cocodelabs/api.palaverapp.com#58 for doing this base on network UUID + buffer name, however this is flawed as it doesn't count for the case insensitive nature of the buffer names (nicknames and channel names).

I can think of two solutions:

1. The API request contains the case mapping for the IRC server so that it can do appropriate normalisation.
2. The sender and channel names are normalised on the server implementation side.

I think soltion 1 may be the best approach, normalisation logic is in one place and we have the original cased channel and sender so that we can display these in the interface as-is instead of in the normalised form.

[kylef]

@slingamn perhaps you may have some suggestions given your interest in #2.

[slingamn]

You know more about this than I do, but my feeling is that the typical server implementation (Oragono included) always sends an authoritative form of the name, which should be consistent unless the client manually changes it. So there should not be a pressing need to compare identifiers in a case-insensitive manner on the client side. Rather, channel names will always be byte-for-byte identical in server output (barring the draft RENAME extension, which I believe is not widely implemented). For nicknames, users can change case with NICK, but this is not conceptually distinct from changing to a completely different nickname and expecting clients to keep track of user identity across nickname changes.

Thoughts?

[kylef]

We've seen cases where this hasn't been true, although I do not recall the details (it was some years ago). This may be a specific IRCd and not widespread.

When it comes to bouncers like ZNC which also has its own sense of normalisation which might differ, I think there could be cases where you'd see different cases for nicks depending on origin. Perhaps none that affect this feature though. I am able to reproduce inconsistencies such as echo-message replaying the clients case (which is different to upstream server).