jakobovrum / dirk Goto Github PK

If a user is voiced, hop, op, superop, etc., findUser() fails for that nick because the tracker tracks it as e.g. "~nick" instead of "nick".

This is especially crippling when Diggler is looking for admins and the admin user currently has a mode set like voice in the channel he is in.

Possible solution: Parse servers options when connecting and strip the characters in PREFIX, i.e. PREFIX=(qaohv)~&@%+ would mean ~, &, @, % and + are nick prefixes for owner, admin, op, hop and voice.

When splitting lines, Dirk does this with respect to the client sent string, but the server itself also has to send the PRIVMSGs back with the maximum of 510 chars. Unfortunately, the server additionally sends the userhost (e.g. [email protected]), so the strings sometimes get cut off anyways.

I looked into the IRSSI-source and they solved it by just subtracting an additional constant(they made an educated guess that it would be a maximum of 74 chars).

I took the liberty and applied the change to a fork:
Doeme@c92ec09

Several errors occur while building in dmd v2.068.0 (on Windows) in loader/loader.d and ssl/openssl.d. Log here.

Setting, removing, querying and tracking of user modes needs to be represented in the interface.

Channel mode prefixes are currently stripped from replies where they are present, which means the user is always presented with just the nick name, but is unable to inspect a user's channel modes.

If quit is called on the client, it is not removed from the eventloop as it should when it disconnects. This means run() does not return even if there are no clients left.

EDIT: Technically I'm calling diggler's CommandContext quit(), though I assume it just forwards the call.

EDIT2: In fact, removing the client manually from the event loop does not remove it from the event loop either, so I'm guessing remove is just broken.

IrcClient should have two modes: one that always passes input from the server to callbacks as-is (current behaviour), and one that transcodes from specified encoding X to UTF-8 before passing to callbacks.

Hi,

since the ssl socket wrapper class has "ssleay32" and "libeay32" hardcoded as ssl library names, it doesn't work on any system except windows where the openssl libraries are called that. I've tried making symlinks to libcrypto.so and libssl.so but that hasn't helped since the interfaces don't seem to be exactly compatible.

On freebsd, I get an error because there's no libdl. The functionality provided by libdl is superseded by libc there, so you can just leave out the requirement. Can you fix this? I would make a PR but I don't yet know all the ins and outs of dub.json.

There are currently a fair number of dynamic allocations that can be eliminated, and GC allocations that can be moved to the C heap. Most of the API should be @nogc.

Currently, certificate verification is simply unconditionally disabled.

handle() doesn't properly deal with INVITEs, and they fall through to the default block.

https://github.com/nerii/Dirk/commit/40840d05c6ac11bfd49277140ccda79386d7fdf1

Latest dub requires semver versioning - the old ~master specification is deprecated. It was overdue anyway.

Example output from putting a debugging writeln into the client code:

PRIVMSG "#xxxxxxx",x"54 68 65 20 49 50 20 72 61 6E 67 65 20 69 73 20 6F 77 6E 65 64 20 62 79 20 48 65 74 7A 6E 65 72 2C 20 61 20 73 65 72 76 65 72 20 68 6F 73 74 65 72 2C 20 73 6F 20 69 74 27 73 20 6F 62 76 69 6F 75 73 6C 79 20 6E 6F 74 20 61 20 6C 65 67 69 74 20 68 6F 6D 65 20 49 C3 50"c
src/rt/util/utf.d, 290, invalid UTF-8 sequence

IRC has no specific encoding for the messages. It's a binary protocol so to speak. Therefore, not crashing on invalid UTF-8 sequences would be preferential.

Crash can easily be triggered by using telnet to send some fun metacharacters.

The best course of action would be to fall back to CP1252 if UTF-8 decoding fails, as it is a superset of ISO-8859-1 used by Microsoft. Diggler which is built on Dirk should also not crash if this fails too.

Need to investigate.

The commented-out code in

Listing all nicknames in a group to work around the issue that way is unfortunately not possible, as /msg NickServ GLIST is access-restricted.

The best workaround seems to currently be to just assume the nickname is the account name, which is the one I use. Opinions on whether this change is sensible or if it needs some deeper restructurings are appreciated.