3 sets up an irc connection, and not much more.
8 - [x] tls (optional cert validation)
9 - [?] sasl plain (untested)
10 - [x] set user and nick
11 - [x] wait for motd/001-message
12 - [x] optionally, do an initial join
16 - respond to server pings
17 - keep track of when we last received an irc mesasge; if t > $timeout, send ping ourselves.
18 (first implementation can just send a ping every $timeout (milli)seconds)
19 (should $timeout be the time between last message and send-ping or between last message and ping-reponse?)
23 - time between sent message and received response
24 - send/recv block: invalid, due to polling
28 - read from stdin, write to stdout
29 - cli for setting timeout, user/nick, server info, ...
30 - netcat-like (everything but host[{: }port] optional
32 - how to specify auth?
33 - relatively secure password handling!
38 - we don't guard against escape sequences in responses. when used interactively,
39 a bad actor could send malicious sequences causing terminal corruption.
40 causing data leaks (by querying terminal information) is unlikely, as the
41 responses won't be proper irc PRIVMSGs.
44 ## dropped features (patches accepted)
45 - nickserv: freenode and hackint support sasl, efenet neither. rest don't care.
46 - sasl cert: don't care for it
47 - optionally use unix domain socket instead of stdin/stdout? (-U?)
48 - checking responses to NICK, JOIN, CAP-REQ, AUTHENTICATE
49 for now, we're just assuming everything went ok.
51 ok: 001 (checked, to block further commands)
52 err: 432 433 436 437 <nick>
55 err: 471 473 474 475 403 405 437 <chan>
62 err: 902 904 905 908 <nick>
63 - maybe allow HOST:PORT (nc doesn't)
64 - maybe allow HOST +PORT and/or HOST:+PORT for tls
65 - maybe allow irc://HOST:PORT and ircs://HOST:PORT
66 - what to do when nick is taken
68 - use fallback nick (append '_')
69 - allow specifying alternate nicks
70 - exit (this is what we do now on receiving the numeric error response)
74 sending more than roughly 4 privmsgs to the same channel in rapid succession
75 can trigger anti-spam measures. an input filter could easily delay bursts.
76 all of these would require modifying the streaming data, which is more trouble
77 than it's worth. these could be implemented as external filters, though.
78 - -C flag to translate CRLF to LF (from server) and LF to CRLF (from stdin)
79 - -A flag to strip ctrlchars (formatting, colors, etc) from stdout
80 - enforce max line length (512 bytes, including CRLF) by splitting PRIVMSG
81 - output filter to highlight PRIVMSGs (nick, channel, message)
85 we need to check and handle multiple responses to commands we've send:
86 - ping: pong (everytime, everywhere. keep current hack)
87 - sasl: cap-ack, 900+903 or 90x (when authenticating, during setup)
88 - (after connecting/authenticating): 001, nick-in-use (everytime, during setup)
90 the server may send unrelated responses in-between - including pings - and we
91 want to enforce a timeout in which we expect the response (2000ms).
94 essentially, we send a command, then block until we receive a response or an error.
95 commands we send that we need to wait for are: