You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.adoc 19KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593
  1. = KtIrc {version}
  2. Chris Smith
  3. :version: 0.11.0
  4. :toc: left
  5. :toc-position: left
  6. :toclevels: 5
  7. == About KtIrc
  8. KtIrc is a Kotlin JVM library for connecting to and interacting with IRC servers.
  9. It is still in an early stage of development. Its main features:
  10. .Built for Kotlin
  11. KtIrc is written in and designed for use in Kotlin; it uses extension methods,
  12. DSLs, sealed classes, and so on, to make it much easier to use than an
  13. equivalent Java library.
  14. .Coroutine-powered
  15. KtIrc uses co-routines for all of its input/output which lets it deal with
  16. IRC messages in the background while your app does other things, without
  17. the overhead of creating a new thread per IRC client.
  18. .Modern IRC standards
  19. KtIrc supports many IRCv3 features such as SASL authentication, message IDs,
  20. server timestamps, replies, reactions, account tags, and more. These features
  21. (where server support is available) make it easier to develop bots and
  22. clients, and enhance IRC with new user-facing functionality.
  23. == Getting started
  24. === Installing
  25. All you need to do to start using KtIrc is add a single dependency.
  26. KtIrc is published to JCenter, making it quick and easy to pull in
  27. to almost any project. The examples below show how to add the JCenter
  28. repository and then the KtIrc dependency; you may already be using
  29. JCenter for other dependencies -- in that case just skip the
  30. repository configuration!
  31. [TIP]
  32. ====
  33. KtIrc adheres to semantic versioning: you can expect to upgrade between
  34. minor versions without problems (e.g. from `0.1.2` to `0.13.7`); major
  35. version changes may include breaking changes such as the removal of
  36. deprecated methods. You should check the changelog before updating to
  37. a new major version.
  38. ====
  39. .Gradle (using Kotlin DSL)
  40. [source,kotlin,subs="attributes"]
  41. ----
  42. repositories {
  43. jcenter()
  44. }
  45. dependencies {
  46. implementation("com.dmdirc:ktirc:{version}")
  47. }
  48. ----
  49. .Gradle (using Groovy DSL)
  50. [source,groovy,subs="attributes"]
  51. ----
  52. buildscript {
  53. repositories {
  54. jcenter()
  55. }
  56. }
  57. implementation 'com.dmdirc:ktirc:{version}'
  58. ----
  59. .Maven
  60. [source,xml,subs="attributes"]
  61. ----
  62. <repositories>
  63. <repository>
  64. <id>jcenter</id>
  65. <url>https://jcenter.bintray.com</url>
  66. </repository>
  67. </repositories>
  68. <dependencies>
  69. <dependency>
  70. <groupId>com.dmdirc</groupId>
  71. <artifactId>ktirc</artifactId>
  72. <version>{version}</version>
  73. </dependency>
  74. </dependencies>
  75. ----
  76. === Creating your first client
  77. KtIrc provides a DSL ("domain specific language") for configuring a
  78. client that allows you to set the connection details, the user's
  79. details, and configure the behaviour of KtIrc itself. The DSL is
  80. accessed through the `IrcClient` function. For full details of all
  81. supported options, see the <<IrcClient DSL>> reference.
  82. A basic client will look like this:
  83. [source,kotlin]
  84. ----
  85. val client = IrcClient {
  86. server {
  87. host = "my.server.com"
  88. }
  89. profile {
  90. nickname = "nick"
  91. username = "username"
  92. realName = "Hi there"
  93. }
  94. }
  95. ----
  96. === Connecting and handling events
  97. Getting KtIrc to start connecting is as simple as calling the `connect()`
  98. method, but before that we probably want to add an event listener to deal
  99. with incoming messages:
  100. [source,kotlin]
  101. ----
  102. client.onEvent { event -> <1>
  103. when (event) { <2>
  104. is ServerReady ->
  105. client.sendJoin("#ktirc") <3>
  106. is ServerDisconnected ->
  107. client.connect()
  108. is MessageReceived ->
  109. if (event.message == "!test") <4>
  110. client.reply(event, "Test successful!") <5>
  111. }
  112. }
  113. client.connect() <6>
  114. ----
  115. <1> An event listener is registered using the `onEvent` method. It receives
  116. a single IrcEvent.
  117. <2> A Kotlin `when` statement provides a convenient way to switch on the
  118. type of event received.
  119. <3> Most common IRC commands have `send` methods defined to quickly and
  120. safely send the message with the right formatting.
  121. <4> Kotlin smart-casts the event, so you can access the properties specific
  122. to the matched event class, such as `message`.
  123. <5> The IrcClient class provides useful methods to react and respond to
  124. events.
  125. <6> The connect() method starts connecting and returns immediately. You'll
  126. receive events updating you on the progress.
  127. In this example, we're waiting for three events: `ServerReady`, which occurs
  128. after we have connected and the server has sent us all of the pre-amble
  129. such as its configuration and capabilities; `ServerDisconnected` which
  130. is raised whenever KtIrc gets disconnected from (or fails to connect to) the
  131. IRC server; and `MessageReceived` which occurs, unsuprisingly, whenever a
  132. message is received. KtIrc has many events: for more information, see the
  133. <<Events>> reference.
  134. [CAUTION]
  135. ====
  136. With this code, KtIrc will immediately try to reconnect as soon as it is
  137. disconnected. If the server closes the connection early (due to, for
  138. example, a bad password or the user being banned) this will result in a
  139. huge number of connection attempts in a short time. In real code you should
  140. always delay reconnections -- preferably with a backoff -- to avoid
  141. excessive connection attempts.
  142. ====
  143. You can see that KtIrc provides a number of useful methods for sending
  144. requests to the server, and reacting and responding to events. IRC
  145. commands that KtIrc supports can be invoked using the `send*` methods,
  146. which are documented in the <<Messages>> reference. Other useful methods
  147. such as `reply` can be found in the <<Utility methods>> reference.
  148. == Reference
  149. === IrcClient DSL
  150. The DSL for creating a new `IrcClient` allows you to set a number of
  151. options relating to how KtIrc connects, what user details it provides,
  152. and how it behaves. The full range of options available in the DSL is
  153. shown below:
  154. [source,kotlin]
  155. ----
  156. server {
  157. host = "irc.example.com"
  158. port = 6667
  159. useTls = true
  160. password = "H4ckTh3Pl4n3t"
  161. }
  162. profile {
  163. nickname = "MyBot"
  164. username = "bot"
  165. realName = "Botomatic v1.2"
  166. }
  167. behaviour {
  168. requestModesOnJoin = true
  169. alwaysEchoMessages = true
  170. }
  171. sasl {
  172. mechanisms += "PLAIN"
  173. username = "botaccount"
  174. password = "s3cur3"
  175. }
  176. ----
  177. ==== Server settings
  178. The server block allows you to specify the details of the IRC server you
  179. wish to connect to:
  180. * `host` - the hostname or IP address of the server *(required)*
  181. * `port` - the port to connect on _(default: 6667)_
  182. * `useTls` - whether to use a secure connection or not _(default: false)_
  183. * `password` - the password to provide to the server _(default: null)_
  184. An alternative more compact syntax is available for configuring server details:
  185. [source,kotlin]
  186. ----
  187. server("irc.example.com", 6667, true, "H4ckTh3Pl4n3t")
  188. ----
  189. You can, if you wish, combine the two or use named parameters:
  190. [source,kotlin]
  191. ----
  192. server(useTls = true, port = 6697) {
  193. host = "irc.example.com"
  194. password = "H4ckTh3Pl4n3t"
  195. }
  196. ----
  197. ==== User profile
  198. The user profile controls how KtIrc will present itself to the IRC server, and
  199. how other users on that server will see the KtIrc user:
  200. * `nickname` - the initial nickname you wish to use *(required)*
  201. * `username` - the "username" to provide to the server _(default: KtIrc)_
  202. * `realName` - the "real name" that will be seen by other clients
  203. _(default: KtIrc User)_
  204. [TIP]
  205. ====
  206. The "username" is sometimes called the "ident" or "gecos". Some IRC servers
  207. will check for an ident reply from your host and use that in place of the
  208. username provided if it gets a response. The username (or ident reply)
  209. becomes part of your client's hostmask, and is visible to other users. It
  210. is unrelated to nickserv or other account usernames.
  211. ====
  212. As with the <<Server settings>> you can use a more compact syntax:
  213. [source,kotlin]
  214. ----
  215. profile("nickname", "username", "real name")
  216. ----
  217. ==== Behaviour
  218. The behaviour block allows you to tweak how KtIrc itself operates. These
  219. options allow you perform common operations automatically, or enjoy more
  220. advanced IRC features even if the server doesn't support them:
  221. * `requestModesOnJoin` - if enabled, automatically requests channel modes
  222. when the client joins a new channel _(default: false)_
  223. * `alwaysEchoMessages` - if enabled, every message you send will result
  224. in a `MessageReceived` event being returned. Servers that support the
  225. IRCv3 `echo-message` capability will do this automatically; enabling the
  226. behaviour will make all servers act the same way _(default: false)_
  227. The behaviour block is optional in its entirety.
  228. ==== SASL configuration
  229. SASL ("Simple Authentication and Security Layer") is a standard mechanism
  230. for securely authenticating to a service that has recently been adopted
  231. for use in IRC. SASL supports a number of 'mechanisms' that describe how
  232. the data will be exchanged between the client and server. KtIrc supports
  233. the following mechanisms:
  234. * `EXTERNAL` - the server uses some external means to authenticate the
  235. client, instead of a username and password. On most servers this
  236. means checking the client certificate against one registered with
  237. the user's account. _(disabled by default)_
  238. * `PLAIN` - the client sends the username and password in plain text
  239. during the connection phase. This offers slightly more security
  240. than calling `nickserv identify` (for example) after connecting.
  241. * `SCRAM-SHA-1` - this mechanism involves a "salted challenge" being
  242. completed which results in both the server and the client proving that
  243. they know the user's password, but without it every being transmitted.
  244. This is based on the `SHA-1` algorithm which has known issues, but is
  245. more than sufficient when used in this manner.
  246. * `SCRAM-SHA-256` - the same as `SCRAM-SHA-1` but using the `SHA-256`
  247. algorithm instead, which is more modern and secure.
  248. To use `PLAIN`, `SCRAM-SHA-1` or `SCRAM-SHA-256`, you must supply a username
  249. and password in the configuration:
  250. [source,kotlin]
  251. ----
  252. sasl {
  253. username = "botaccount"
  254. password = "s3cur3"
  255. }
  256. ----
  257. KtIrc enables `SCRAM-SHA-256`, `SCRAM-SHA-1` and `PLAIN` by default, and will
  258. use them in that order of preference if the server supports more than one.
  259. You can modify the `mechanisms` parameter if you wish to disable one:
  260. [source,kotlin]
  261. ----
  262. sasl {
  263. mechanisms -= "PLAIN"
  264. username = "botaccount"
  265. password = "s3cur3"
  266. }
  267. ----
  268. You can also clear all the default mechanisms and provide your own list:
  269. [source,kotlin]
  270. ----
  271. sasl {
  272. mechanisms("SCRAM-SHA-256", "PLAIN")
  273. username = "botaccount"
  274. password = "s3cur3"
  275. }
  276. ----
  277. If you wish to enable the `EXTERNAL` mechanism, you do not need to provide
  278. a username or password:
  279. [source,kotlin]
  280. ----
  281. sasl {
  282. mechanisms("EXTERNAL")
  283. }
  284. ----
  285. Alternatively, if you wish to enable `EXTERNAL` but fall back to other
  286. mechanisms if it doesn't work:
  287. [source,kotlin]
  288. ----
  289. sasl {
  290. mechanisms += "EXTERNAL"
  291. username = "botaccount"
  292. password = "s3cur3"
  293. }
  294. ----
  295. The SASL block is optional in its entirety.
  296. === State
  297. KtIrc attempts to track all reasonable state of the IRC network. This includes
  298. details about the server, channels the client is joined to, and users that are
  299. also in those channels. The state is exposed in a several fields accessible
  300. from the `IrcClient`:
  301. ==== ServerState
  302. The server state provides information about the server, and our connection to
  303. it.
  304. [IMPORTANT]
  305. ====
  306. The server state will be updated frequently while KtIrc is connecting to a
  307. server. The values within it should not be relied upon until a `ServerReady`
  308. event is received, as they may be incomplete or estimates before then.
  309. ====
  310. .serverState.status (ServerStatus)
  311. Provides an enum containing the current server state. One of:
  312. * `Disconnected` - the server is not connected
  313. * `Connecting` - we are attempting to establish a connection
  314. * `Negotiating` - we are logging in, negotiating capabilities, etc
  315. * `Ready` - we are connected and commands may be sent
  316. .serverState.localNickname (String)
  317. The current nickname we are using on the IRC server. While connecting this
  318. will default to the nickname from the <<User profile>>, but it may be updated
  319. if e.g. the nick is in use or not allowed.
  320. .serverState.serverName (String)
  321. The name the server uses for itself. While connecting this defaults to the
  322. hostname given in the <<Server settings>>, but it will be updated to the
  323. value provided by the server. For example, you may connect to
  324. `irc.example.com` and during the negotiation phase KtIrc will see that it
  325. is actually talking to `server3.uk.irc.example.com` and update the
  326. serverName to reflect that.
  327. [TIP]
  328. ====
  329. For a user-friendly identifier most servers provide a `NETWORK` token in
  330. the ISUPPORT reply, which is available via the <<Features>> property.
  331. ====
  332. .serverState.channelModePrefix (ModePrefixMapping)
  333. Provides a mapping from channel user modes (such as "o" for op, "v" for
  334. voice) to the prefixes used before nicknames (such as "@" and "+").
  335. To map prefixes to modes, you can use the `getMode()` or `getModes()`
  336. functions:
  337. [source,kotlin]
  338. ----
  339. getMode('@') == 'o'
  340. getModes("@+") == "ov"
  341. ----
  342. .serverState.channelTypes (String)
  343. Contains the types of channels that are allowed by the server, such as
  344. `\#&amp;` for normal channels ("#") and local channels ("&").
  345. ===== Capabilities
  346. The IRCv3 specifications introduce the concept of 'capability negotiation'.
  347. This allows the client and server to negotiate and enable new capabilities
  348. that are mutually supported.
  349. The capabilities state contains the following properties:
  350. .serverState.capabilities.negotiationState (CapabilitiesNegotiationState)
  351. The current state of negotiating with the server. One of:
  352. * `AWAITING_LIST` - we have requested a list of capabitilies and are awaiting
  353. a reply
  354. * `AWAITING_ACK` - we have sent the capabilities we want to enable, and are
  355. waitin for the server to acknowledge them
  356. * `AUTHENTICATING` - we are attempting to authenticate with SASL
  357. * `FINISHED` - we have completed negotiation
  358. Where a server does not support IRCv3 capability negotiation, the state will
  359. remain at `AWAITING_LIST`.
  360. .serverState.capabilities.advertisedCapabilities (Map<String, String>)
  361. Contains a map of capability names to values that the server offered. This
  362. should only be required for advance use cases, such as looking up the
  363. languages offered by a server when providing the user with a choice of
  364. translations.
  365. .serverState.capabilities.enabledCapabilities (Map<Capability, String>)
  366. Contains a map of capabilities that KtIrc has successfully negotiated with
  367. the server.
  368. ====== Supported capabilities
  369. * `sasl` - used to perform SASL authentication during connection
  370. * `message-tags` - allows arbitrary tags on messages
  371. * `server-time` - the server adds a timestamp tag to each incoming message
  372. * `account-tag` - the server adds an account tag to incoming user messages
  373. * `userhost-in-names` - the NAMES reply includes users hosts not just nicknames
  374. * `multi-prefix` - all modes are included in nick prefixes (e.g. `@+nick`)
  375. * `extended-join` - more information is sent when a user joins a channel
  376. * `batch` - allows multi-line responses to be batched together
  377. * `echo-message` - echos the client's own messages back to it
  378. * `draft/labeled-responses` - responses are labeled so the client knows which
  379. incoming message corresponds to which command it sent
  380. * `account-notify` - the server sends a message when a user's account changes
  381. * `away-notify` - the server sends a message when a user's away state changes
  382. * `chghost` - the server sends a message when a user's host changes
  383. ===== Features
  384. Features are KtIrc's way of exposing the information the server declares in
  385. its ISUPPORT messages. These describe how the server is configured, and what
  386. limits are placed on clients. You access features using the `features` map
  387. in the server state:
  388. [source,kotlin]
  389. ----
  390. ircClient.serverState.features[ServerFeature.Network]
  391. ----
  392. The following features are available:
  393. * `Network` - the name of the network the server belongs to __(String?)__
  394. * `ServerCaseMapping` - the current case mapping of the server __(CaseMapping!)__
  395. * `Modeprefixes` - the user mode prefix mapping (e.g. ov to @+) __(ModePrefixMapping!)__
  396. * `MaximumChannels` - the maximum number of channels a user can join __(Int?)__
  397. * `ChannelModes` - the modes supported in channels __(Array<String>?)__
  398. * `ChannelTypes` - the types of channel supported (e.g. "#&") __(String!)__
  399. * `MaximumChannelNameLength` - how long channel names may be __(Int!)__
  400. * `WhoxSupport` - whether the server supports extended whos ("WHOX") __(Boolean!)__
  401. [NOTE]
  402. ====
  403. If the server does not define a feature, KtIrc will either fall back to a
  404. default value based on the IRC RFCs or common practice (for those features
  405. identified with a non-null type such as `Int!` or `String!`); otherwise
  406. the value of the feature will be `null` (such as for those identified as
  407. `Int?` or `String?` types).
  408. ====
  409. ==== UserState
  410. The client's UserState object tracks the details of all users in common
  411. channels. It can be used to find the most up-to-date and comprehensive
  412. information for those users, as well as the set of channels that we share
  413. with them.
  414. The UserState is accessed via the `userState` property of IrcClient and
  415. acts as a map, accessible using either a nickname or a `User` object:
  416. [source,kotlin]
  417. ----
  418. ircClient.userState["acidBurn"]
  419. val user: User = myIrcEvent.user
  420. ircClient.userState[user]
  421. ----
  422. The UserState returns a `KnownUser` object which exposes a `details`
  423. property containing the user details, and a `channels` property
  424. containing the common channel names. You can also use the `in`
  425. operator to check if the user is in a channel:
  426. [source,kotlin]
  427. ----
  428. ircClient.userState["acidBurn"]?.let { knownUser ->
  429. val accountName = knownUser.account
  430. val inChannel = "#channel" in knownUser
  431. val allChannels = knownUser.channels
  432. }
  433. ----
  434. ==== ChannelState
  435. The ChannelState keeps track of the state for all channels that the client
  436. is joined to. It is indexed by channel name:
  437. [source,kotlin]
  438. ----
  439. ircClient.channelState["#ktirc"]
  440. ----
  441. Each channel's state contains the following properties:
  442. * `receivingUserList` - boolean value indicating whether we are in the process
  443. of receiving the list of users for the channel. If we are, the `users`
  444. property will be incomplete.
  445. * `modesDiscovered` - boolean value indicating whether we have received the
  446. full set of modes set on the channel. The `requestModesOnJoin` <<Behaviour>>
  447. allows you to make KtIrc request these automatically.
  448. * `topic` - a ChannelTopic object representing the current channel topic.
  449. If no topic is set, then a ChannelTopic with `null` properties will be
  450. provided.
  451. * `users` - a map of all known users in the channel, see <<Channel users>>
  452. for more information
  453. * `modes` - A map of the current channel modes and their values. Only
  454. complete if `modesDiscovered` is true.
  455. ===== Channel users
  456. Channel users are accessed using the `users` property, which provides an
  457. iterable map of nickname to `ChannelUser`. Each `ChannelUser` contains
  458. the nickname and current modes for that user. To get further details about
  459. a user, such as their hostmask or real name, you should query the <<UserState>>
  460. with the given nickname.
  461. [source,kotlin]
  462. ----
  463. ircClient.channelState["#ktirc"]?.users?.forEach { user ->
  464. println("${user.nickname} has modes ${user.modes}")
  465. }
  466. ----
  467. === Events
  468. TODO
  469. === Messages
  470. TODO
  471. === Utility methods
  472. TODO
  473. === IRCv3 support
  474. TODO