Protocol.txt 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265
  1. ngIRCd - Next Generation IRC Server
  2. http://ngircd.barton.de/
  3. (c)2001-2019 Alexander Barton and Contributors.
  4. ngIRCd is free software and published under the
  5. terms of the GNU General Public License.
  6. -- Protocol.txt --
  7. I. Compatibility
  8. ~~~~~~~~~~~~~~~~
  9. The ngIRCd implements the Internet Relay Chat (IRC) protocol version 2.10
  10. as defined in RFC ("request for comment") 1459 and 2810-2813. These (and
  11. probably further relevant RFCs) are listed in doc/RFC.txt.
  12. Unfortunately, even the "original" ircd doesn't follow these specifications
  13. in all details. But because the ngIRCd should be a fully compatible
  14. replacement for this server ("ircd") it tries to emulate these differences.
  15. If you don't like this behavior please ./configure the ngIRCd using the
  16. "--enable-strict-rfc" command line option. But keep in mind: not all IRC
  17. clients are compatible with a server configured that way, some can't even
  18. connect at all! Therefore this option usually isn't desired for "normal
  19. server operation".
  20. In addition, ngIRCd implements some "IRCv3" features. This includes:
  21. - IRCv3 Client Capability Negotiation
  22. - IRCv3.1 multi-prefix Extension
  23. - IRCv3.2 userhost-in-names Extension
  24. Please see the IRCv3 homepage for more information: <https://ircv3.net>.
  25. II. The IRC+ Protocol
  26. ~~~~~~~~~~~~~~~~~~~~~
  27. Starting with version 0.5.0, the ngIRCd extends the original IRC protocol
  28. as defined in RFC 2810-2813. This enhanced protocol is named "IRC+". It is
  29. backwards compatible to the "plain" IRC protocol and will only be used by
  30. the ngIRCd if it detects that the peer supports it as well.
  31. The "PASS" command is used to detect the protocol and peer versions see
  32. RFC 2813 (section 4.1.1) and below.
  33. II.1 Register new server link
  34. Command: PASS
  35. Parameters: <password> <version> <flags> [<options>]
  36. Used by: servers only (with these parameters)
  37. <password> is the password for this new server link as defined in the server
  38. configuration which is sent to the peer or received from it.
  39. <version> consists of two parts and is at least 4, at most 14 characters
  40. long: the first four bytes contain the IRC protocol version number, whereas
  41. the first two bytes represent the major version, the last two bytes the
  42. minor version (the string "0210" indicates version 2.10, e.g.).
  43. The following optional(!) 10 bytes contain an implementation-dependent
  44. version number. Servers supporting the IRC+ protocol as defined in this
  45. document provide the string "-IRC+" here.
  46. Example for <version>: "0210-IRC+".
  47. <flags> consists of two parts separated with the character "|" and is at
  48. most 100 bytes long. The first part contains the name of the implementation
  49. (ngIRCd sets this to "ngircd", the original ircd to "IRC", e.g.). The second
  50. part is implementation-dependent and should only be parsed if the peer
  51. supports the IRC+ protocol as well. In this case the following syntax is
  52. used: "<serverversion>[:<serverflags>]".
  53. <serverversion> is an ASCII representation of the clear-text server version
  54. number, <serverflags> indicates the supported IRC+ protocol extensions (and
  55. may be empty!).
  56. The following <serverflags> are defined at the moment:
  57. - C: The server supports the CHANINFO command.
  58. - L: INVITE- and BAN-lists should be synchronized between servers: if the
  59. peer understands this flag, it will send "MODE +I" and "MODE +b"
  60. commands after the server link has been established.
  61. - H: The server supports the "enhanced server handshake", see section II.2
  62. for a detailed description.
  63. - M: Changing client "metadata" (hostname, real name, ...) using the
  64. METADATA command is supported.
  65. - o: IRC operators are allowed to change channel- and channel-user-modes
  66. even if they aren't channel-operator of the affected channel.
  67. - S: The server supports the SERVICE command (on this link).
  68. - X: Server supports XOP channel modes (owner, admin, halfop) and supports
  69. these user prefixes in CHANINFO commands, for example.
  70. - Z: Compressed server links are supported by the server.
  71. Example for a complete <flags> string: "ngircd|0.7.5:CZ".
  72. The optional parameter <options> is used to propagate server options as
  73. defined in RFC 2813, section 4.1.1.
  74. II.2 Enhanced Server Handshake
  75. The "enhanced server handshake" is used when both servers support this IRC+
  76. extension, which is indicated by the 'H' flag in the <serverflags> sent with
  77. the PASS command, see section II.1.
  78. It basically means, that after exchanging the PASS and SERVER commands the
  79. server is not registered in the network (as usual), but that IRC numerics
  80. are exchanged until the numeric 376 (ENDOFMOTD) is received. Afterwards the
  81. peer is registered in the network as with the regular IRC protocol.
  82. A server implementing the enhanced server handshake (and indicating this
  83. using 'H' in the <serverflags>) MUST ignore all unknown numerics to it
  84. silently.
  85. In addition, such a server should at least send the numeric 005 (ISUPPORT)
  86. to its peer, containing the following information. Syntax: <key>=<value>,
  87. one token per IRC parameter. If the server has to send more than 12 token
  88. it must send separate ISUPPORT numerics (this is a limitation of the IRC
  89. protocol which allows at max 15 arguments per command).
  90. - NICKLEN: Maximum nickname length. Default: 9.
  91. - CASEMAPPING: Case mapping used for nick- and channel name comparing.
  92. Default: "ascii", the chars [a-z] are lowercase of [A-Z].
  93. - PREFIX: List of channel modes a person can get and the respective prefix
  94. a channel or nickname will get in case the person has it. The order of the
  95. modes goes from most powerful to least powerful. Default: "(ov)@+"
  96. - CHANTYPES: Supported channel prefixes. Default: "#".
  97. - CHANMODES: List of channel modes for 4 types, separated by comma (","):
  98. Mode that adds or removes a nick or address to a list, mode that changes
  99. a setting (both have always has a parameter), mode that changes a setting
  100. and only has a parameter when set, and mode that changes a setting and
  101. never has a parameter. For example "bI,k,l,imnPst".
  102. - CHANLIMIT: Maximum number of channels allowed to join by channel prefix,
  103. for example "#:10".
  104. Please see <http://www.irc.org/tech_docs/005.html> for details.
  105. The information exchanged using ISUPPORT can be used to detect configuration
  106. incompatibilities (different maximum nickname length, for example) and
  107. therefore to disconnect the peer prior to registering it in the network.
  108. II.3 Exchange channel-modes, topics, and persistent channels
  109. Command: CHANINFO
  110. Parameters: <channel> +<modes> [[<key> <limit>] <topic>]
  111. Used by: servers only
  112. CHANINFO is used by servers to inform each other about a channel: its
  113. modes, channel key, user limits and its topic. The parameter combination
  114. <key> and <limit> is optional, as well as the <topic> parameter, so that
  115. there are three possible forms of this command:
  116. CHANINFO <channel> +<modes>
  117. CHANINFO <channel> +<modes> <topic>
  118. CHANINFO <channel> +<modes> <key> <limit> <topic>
  119. If the channel already exists on the server receiving the CHANINFO command,
  120. it only adopts the <modes> (or the <topic>) if there are no modes (or topic)
  121. already set. It there are already values set the server ignores the
  122. corresponding parameter.
  123. If the channel doesn't exists at all it will be created.
  124. The parameter <key> must be ignored if a channel has no key (the parameter
  125. <modes> doesn't list the "k" channel mode). In this case <key> should
  126. contain "*" because the parameter <key> is required by the CHANINFO syntax
  127. and therefore can't be omitted. The parameter <limit> must be ignored when
  128. a channel has no user limit (the parameter <modes> doesn't list the "l"
  129. channel mode). In this case <limit> should be "0".
  130. II.4 Update webchat/proxy client information
  131. Command: WEBIRC
  132. Parameters: <password> <username> <hostname> <ip-address> [<ignored>]
  133. Used by: unregistered clients only
  134. The WEBIRC command is used by some Web-to-IRC gateways to set the correct
  135. user name and host name of users instead of their own. It must be the very
  136. first command sent to the server, even before USER and NICK commands!
  137. The <password> must be set in the server configuration file to prevent
  138. unauthorized clients to fake their identity; it is an arbitrary string.
  139. Optionally, a 5th parameter is accepted to comply with an IRCv3 extension,
  140. see <https://github.com/ircv3/ircv3-ideas/issues/12>, but ignored.
  141. II.5 Client character encoding conversion
  142. Command: CHARCONV
  143. Parameters: <client-charset>
  144. Used by: registered clients
  145. Replies: RPL_IP_CHARCONV, ERR_IP_CHARCONV
  146. A client can set its character set encoding using the CHARCONV command:
  147. after receiving such a command, the server translates all message data
  148. received from the client using the set <client-charset> to the server
  149. encoding (UTF-8), and all message data which is to be sent to the client
  150. from the server encoding (UTF-8) to <client-charset>.
  151. The list of supported client character sets is implementation dependent.
  152. If a client sets its <client-charset> to the server encoding (UTF-8),
  153. it disables all conversions; the connection behaves as if no CHARCONV
  154. command has been sent at all in this session.
  155. II.6 Update client "metadata"
  156. Command: METADATA
  157. Parameters: <target> <key> <value>
  158. Used by: servers only
  159. The METADATA command is used on server-links to update "metadata" information
  160. of clients, like the hostname, the info text ("real name"), or the user name.
  161. The server updates its client database according to the received <key> and
  162. <value> parameters, and passes the METADATA command on to all the other
  163. servers in the network that support this command (see section II.1 "Register
  164. new server link", <serverflag> "M"), even if it doesn't support the given
  165. <key> itself: unknown <key> names are ignored silently!
  166. The following <key> names are defined:
  167. - "accountname": the account name of a client (can't be empty)
  168. - "certfp": the certificate fingerprint of a client (can't be empty)
  169. - "cloakhost": the cloaked hostname of a client
  170. - "host": the hostname of a client (can't be empty)
  171. - "info": info text ("real name") of a client
  172. - "user": the user name of a client (can't be empty)
  173. III. Numerics used by IRC+ Protocol
  174. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  175. The IRC+ protocol uses numerics in the range 800-899 which aren't used by
  176. RFC 2812 and hopefully don't clash with other implementations ...
  177. Numerics 800-849 are used for status and success messages, and numerics
  178. 850-899 are failure and error messages.
  179. III.1 IRC+ status and success numerics
  180. 801 - RPL_IP_CHARCONV
  181. %1 :Client encoding set"
  182. %1 client character set
  183. III.2 IRC+ failure and error numerics
  184. 851 - ERR_IP_CHARCONV
  185. :Can't initialize client encoding