spec.txt

   1 # ircpipe
   2
   3 sets up an irc connection, and not much more.
   4
   5 ## on connection
   6
   7 - [x] connect
   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
  13
  14 ## in the background
  15
  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?)
  20         - different timeouts:
  21           - ping interval
  22           - connect timeout
  23           - time between sent message and received response
  24           - send/recv block: invalid, due to polling
  25
  26 ## interfaces
  27
  28 - read from stdin, write to stdout
  29 - cli for setting timeout, user/nick, server info, ...
  30   - netcat-like (everything but host[{: }port] optional
  31   - how to specify tls?
  32   - how to specify auth?
  33     - relatively secure password handling!
  34
  35
  36 ## vulnerabilities
  37
  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.
  42
  43
  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.
  50   - NICK/USER
  51      ok: 001 (checked, to block further commands)
  52      err: 432 433 436 437 <nick>
  53   - JOIN
  54      ok: JOIN <chan>
  55      err: 471 473 474 475 403 405 437 <chan>
  56   - CAP REQ/CAP END
  57      ok: CAP <nick?> ACK
  58      err: CAP <nick?> NAK
  59      err: 421
  60   - AUTHENTICATE
  61      ok: 900 903 <nick>
  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
  67   - use random nick
  68   - use fallback nick (append '_')
  69   - allow specifying alternate nicks
  70   - exit (this is what we do now on receiving the numeric error response)
  71
  72 ## discarded ideas
  73 - flood protection!
  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)
  82
  83 ## for responses
  84
  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)
  89
  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).
  92
  93
  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:
  96  - PING
  97     ok: PONG :<whatever>
  98