Editing IRCd (section)

== History ==
{{Update|section|date=January 2015}} <!-- IRCv3? -->
The original IRCd was known as 'ircd', and was authored by [[Jarkko Oikarinen]] (WiZ on IRC) in 1988.<ref>[http://www.irc.org/history_docs/jarkko.html IRC History on IRC.org]</ref><ref>[http://daniel.haxx.se/irchistory.html History of IRC, Daniel Stenberg]</ref> He received help from a number of others, such as Markku Savela (msa on IRC), who helped with the 2.2+msa release, etc.

In its first revisions, IRC did not have many features that are taken for granted today, such as named channels and [[Internet Relay Chat channel operator|channel operators]]. Channels were numbered &ndash; channel 4 and channel 57, for example &ndash; and the channel '''topic''' described the kind of conversation that took place in the channel. One holdover of this is that joining channel 0 causes a client to leave all the channels it is presently on: "CHANNEL 0" being the original command to leave the current channel.

The first major change to IRC, in version 2.5, was to add '''named channels''' &ndash; "+channels". "+channels" were later replaced with "#channels" in version 2.7, numeric channels were removed entirely and channel bans (mode +b) were implemented.

Around version 2.7, there was a small but notable dispute{{Clarify| reason=What was the acutal dispute?| date=March 2013}}, which led to ircu &ndash; the [[Undernet]] fork of ircd.

irc2.8 added "&channels" (those that exist only on the current server, rather than the entire network) and "!channels" (those that are theoretically safe from suffering from the many ways that a user could exploit a channel by "[[IRC takeover|riding a netsplit]]"), and is the baseline release from which nearly all current implementations are derived.

Around 2.8 came the concept of nick and channel delay, a system designed to help curb abusive practices such as [[IRC takeover|takeovers]] and split riding. This was not agreed on by the majority of modern IRC (EFnet, DALnet, Undernet, etc.) – and thus, 2.8 was forked into a number of different daemons using an opposing theory known as TS &ndash; or time stamping, which stored a unique time stamp with each channel or nickname on the network to decide which was the 'correct' one to keep.

Time stamping itself has been revised several times to fix various issues in its design. The latest versions of such protocols are:
* the TS6 protocol, which is used by [[EFnet]], and Hybrid and Ratbox based servers amongst others
* the [[#P10|P10 protocol]], which is used by [[Undernet]] and ircu based servers.

While the client-to-server protocols are at least functionally similar, [[server-to-server]] protocols differ widely (TS5, P10, and ND/CD server protocols are incompatible), making it very difficult to "link" two separate implementations of the IRC server. Some "bridge" servers do exist, to allow linking of, for example, 2.10 servers to TS5 servers, but these are often accompanied with restrictions of which parts of each protocol may be used, and are not widely deployed.

Significant releases based on 2.8 included:
* 2.8.21+CS, developed by Chris Behrens ('''Comstud''')
* 2.8+th, Taner Halicioglu's patchset, which later became
** Hybrid IRCd, originally developed by Jon Lusky ('''Rodder''') and Diane Bruce ('''Dianora''') as 2.8/hybrid, later joined by a large development team.
* 2.9, 2.10, 2.11, ... continue the development of the original codebase,

The original code base continued to be developed mainly for use on the [[IRCnet]] network. New server-to-server protocols were introduced in version 2.10, released in 1998, and in 2.11, first released in 2004, and current {{As of|2007|lc=on}}. This daemon is used by [[IRCnet]] and it can be found at http://www.irc.org/ftp/irc/server/ The original ircd is [[free software]], licensed under the [[GNU General Public License]]. This development line produced the 4 IRC RFCs released after RFC 1459, which document this server protocol exclusively.

2.8.21+CS and Hybrid IRCd continue to be used on [[EFnet]], with ircd-ratbox (an offshoot of ircd-hybrid) {{As of|2004|lc=on}} being the most popular.

=== Sidestream versions ===
[[File:IRCd software implementations3.svg|thumb|right|Diagram of derivations and relations for common IRCd implementations.]]

More recently, several irc daemons were written from scratch, such as ithildin,<ref>[http://www.ithildin.org/ Ithildin IRCd]</ref> InspIRCd,<ref>[http://www.inspircd.org/ Inspire IRCd]</ref> csircd (also written by Chris Behrens), ConferenceRoom,<ref>{{Cite web |url=http://www.conferenceroom.com/ |title=WebMaster Inc. |access-date=2020-01-20 |archive-url=https://web.archive.org/web/20160303213029/http://www.conferenceroom.com/ |archive-date=2016-03-03 |url-status=dead }}</ref> Microsoft Exchange Chat Service, WeIRCd,<ref>{{Cite web |url=http://eloxoph.com/weircd/ |title=WeIRCd |access-date=2009-03-26 |archive-url=https://web.archive.org/web/20100514140803/http://eloxoph.com/weircd/ |archive-date=2010-05-14 |url-status=usurped }}</ref> or IRCPlus/IRCXPro.<ref>[http://www.ircxpro.com OfficeIRC – IRC Server Software, Web Chat, Internal Communications and Instant Messaging (IM)]</ref>

These attempts have met with mixed success, and large doses of skepticism from the existing IRC development community. With each new IRCd, a slightly different version of the IRC protocol is used,<ref>[http://smartirc4net.meebey.net/jaws/index.php?blog/show/SmartIrc4net_035_released Blog entry mentioning RFC violations]</ref><ref>[http://www.alien.net.au/irc/irc2numerics.html Numerics diversity of different IRC daemons]</ref> and many [[IRC client]]s and [[IRC bot|bots]] are forced to compromise on features or vary their implementation based on the server to which they are connected.<ref>[http://git.dmdirc.com/cgit.cgi/parser/tree/src/com/dmdirc/parser/irc/IRCParser.java Client source (DMDirc) showing conditions for different servers (e.g. in function starting at line 1523)]</ref> These are often implemented for the purpose of improving usability, security, separation of powers, or ease of integration with [[IRC services|services]]. Possibly one of the most common and visible differences is the inclusion or exclusion of the half-op [[Internet Relay Chat channel operator|channel operator]] status (which is not a requirement of the RFCs).