Monitoring users with formatted masks

[FrozenPigs]

Some users on Rizon have formatted masks from things like holiday events and such, and that is causing an issue with removing that user from the ircv3 monitoring. They can have things like bold and underline, and I believe other things.

PART ('#wednesday',) {}
NOTICE ('wednesday', 'Parting #wednesday.') {}
Failed to execute on_raw_part handler.
Traceback (most recent call last):
  File "/usr/home/wednesday/.local/lib/python3.7/site-packages/pydle/client.py", line 430, in on_raw
    await handler(message)
  File "/usr/home/wednesday/.local/lib/python3.7/site-packages/pydle/features/rfc1459/client.py", line 689, in on_raw_part
    self._destroy_channel(channel)
  File "/usr/home/wednesday/.local/lib/python3.7/site-packages/pydle/client.py", line 196, in _destroy_channel
    self._destroy_user(user, channel)
  File "/usr/home/wednesday/.local/lib/python3.7/site-packages/pydle/features/ircv3/monitor.py", line 34, in _destroy_user
    del self.users[nickname]
  File "/usr/home/wednesday/.local/lib/python3.7/site-packages/pydle/features/rfc1459/parsing.py", line 168, in __delitem__
    del self.storage[normalize(key, case_mapping=self.case_mapping)]
KeyError: '\x030winter.solstice\x03.\x02'

The user with said mask is greenbagels over on Rizon in #wednesday if you needed to see.

[ineeee]

greenbagels' host has three different escape codes: bold, underline and color(?): greenbagels!GreenBagel@\u0002\u001f\u00030Winter.Solstice\u0003.\u0002\u001fgreenbagels

• \u0002 () is bold
• \u001f () is underline
• \u0003 + 0 (0) is color tag + color 0 (white)

[theunkn0wn1]

Very interesting error, I will need to do some digging to see why this is occurring.

If you could please: 1) provide exact steps to reproduce 2) a minimum test case to reproduce the issue 3) a code snippet used for the above two steps

[FrozenPigs]

Well it is occurring with my Taigabot3 repository, when the bot is only in a single channel with that user, then leaves the channel it has in common with them.

So with that said, it should be possible to recreate this issue with a minimal bot by just:

1. Joining a channel with the user (you're free to use my channel #wednesday on Rizon with the user greenbagels in it)
2. Parting that channel

Here may be some relevant bits of documentation and code from the network that @inexist3nce found: Formatting Codes Services code for the masks

Edit: While Parting another channel I found another host that triggered it KeyError: '\x034xmas\x03.\x033at\x03.\x032rizon\x03.'

[theunkn0wn1]

Please note that these hostmasks are strictly invalid under the RFC and IRCv3 specifications. Therefore, Pydle cannot offer proper support for them.

to cite from RFC 952 which defines host names,

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.).  

Under this definition, hostmasks that contain non-alpha numeric characters (excluding - and .) are invalid.

Further, under RFC 1178 (page 4) hostmasks

      Don't use non-alphanumeric characters in a name.

         Your own computer may handle punctuation or control characters
         in a name, but most others do not.  If you ever expect to
         connect your computer to a heterogeneous network, you can count
         on a variety of interpretations of non-alphanumeric characters
         in names.  Network conventions on this are surprisingly

That being said, RFC 1459 (the IRC specification) leaves a note regarding IRC message handling that helps contribute to the fix:

    1) <SPACE> is consists only of SPACE character(s) (0x20).
     Specially notice that TABULATION, and all other control
     characters are considered NON-WHITE-SPACE.

As Pydle is erroneously splitting on these control characters, that bug will be fixed by #114 , which also appears to resolve the reported bug here.

Bottom line

Rizon's non-standard behavior is not officially supported by this library, as this Library strictly abides by the standards that be. This issue can be resolved in a fashion that abides by the standards cited above, and the fix is applied in #114 .

Please apply #114 to your downstream Tagiabot and let me know if it resolves your issue.

---

On a unrelated note, for future reference PLEASE warn people that the channel they can observe an issue on is NSFW, or at the very least likely contain offensive material. 😒

[FrozenPigs]

I can confirm that this fixes the issue.