The IRC Bot Identification Protocol Standard.
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.

README.md 3.3KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374
  1. # IBIP
  2. The IRC Bot Identification Protocol Standard
  3. ### Abstract
  4. The IRC Bot Identification Protocol, or IBIP, formalizes the detection and enumeration of robots on an IRC network.
  5. IBIP relies upon the standard behavior of IRC clients, as standardized in [RFC 2812](https://tools.ietf.org/html/rfc2812).
  6. This standard should be defined in the Server INFO response as a server feature/requirement.
  7. ### Labels
  8. * A **robot** or **bot** is an automated script or program that performs tasks on an IRC network.
  9. * A **client** is a user, usually humanoid, connected to an IRC network.
  10. * A **target** is an IRC channel or nickname used by both **clients** and **robots** to direct IBIP messages.
  11. ### Protocol
  12. IBIP has two mandatory components: a *call* component and a *response* component.
  13. Human **clients** are normally the originators of the *call* component, while **robots** respond to the call with the *response* component. However, nothing stop **robots** from originating an IBIP call, and nothing stops human **clients** from falsely responding to the call.
  14. #### The "call" component
  15. Clients expecting a response from **all** IBIP-compliant IRC bots in the current channel should send a PRIVMSG in the following format:
  16. ```
  17. PRIVMSG target :.bots
  18. ```
  19. Within an IRC client, this message will be just `.bots`.
  20. The target may be one of two options:
  21. * A channel, like `#bots` or `#help`
  22. * An IRC nickname, like `user123` or `johndoe`
  23. If the target is a channel, the client must expect to receive proper responses from all IBIP-compliant bots in the targeted channel.
  24. If the target is a nickname, the client must expect to receive either no proper responses or exactly one proper response from the IBIP-compliant bot messaged. If the nickname messaged is not the nickname of an IBIP-compliant bot **or** does not exist on the network, the client should not expect to receive a proper response.
  25. #### The "response" component
  26. Upon receiving a PRIVMSG of the format specified above, IBIP-compliant IRC bots are expected to send a response PRIVMSG in the following format:
  27. ```
  28. PRIVMSG target :Reporting in! [<language>] information
  29. ```
  30. Where the target is one of two options:
  31. * The IRC channel from which the request originated.
  32. * The IRC nickname of the user who sent the IBIP "call".
  33. If the call was sent through a channel and **not** privately, the bot should reply through the channel. If the call was sent privately, the bot should reply through a corresponding PRIVMSG directly to the sender.
  34. The response sent to the target has the following format:
  35. ```
  36. Reporting in! [<language>] information
  37. ```
  38. In this format, the "Reporting in!" component is **static** and should **not** vary between IBIP-compliant bots.
  39. The "[\<language\>]" component is **optional**, and specifies the language(s) in which the IRC bot was developed. If multiple languages were used, it is recommended that they be separated by slashes, although this is not mandatory. This component **may not** contain mIRC color codes or other non-text characters, to simplify parsing.
  40. After the "[\<language\>]" component, the bot writer may choose to specify any additional information they consider pertinent to someone identifying bots with IBIP. This information is **optional**.
  41. In summary, an example IBIP response might look like this:
  42. ```
  43. PRIVMSG #channel :Reporting in! [C] More info at http://example.com
  44. ```