Skip to content
Dialova

IRC Documentation · Beginner

History of IRC: From 1988 to IRCv3 Extensions

IRC is born in 1988: Jarkko Oikarinen develops Internet Relay Chat at the University of Oulu, Finland. The protocol makes real-time discussion between multiple users possible and then evolves through networks, software, and their extensions.

Dialova Team · Verified on

1988: A discussion tool that spreads #

The historical account gathered by Daniel Stenberg places the beginnings in the summer of 1988. IRC spreads through clients and servers capable of communicating with each other. Its history is not limited to an application: distinct teams develop software and administer networks.

1993 and 2000: Documenting the protocol #

RFC 1459, published in May 1993 by Jarkko Oikarinen and Darren Reed, describes the IRC protocol. It has Experimental status. In April 2000, several documents address the architecture and protocols; RFC 2812 deals with the client protocol and has Informational status.

These texts are reference points, not a guarantee that each current server applies the same frozen version. Implementations have evolved, sometimes with differences in modes, limits, and responses. Modern IRC documentation describes modern practices and explicitly states these discrepancies.

Networks, services, and new interfaces #

The ability to link servers accompanies the development of distinct networks. Network teams organize their rules and services, including account and channel management. NickServ and ChanServ are common names for services, but their presence and commands are not universal.

Interfaces are also changing: terminals, graphical software, web clients, and bouncers provide different ways to retrieve a conversation. These interface choices do not replace the protocol and do not standardize network policies.

IRCv3: Extend Without Replacing Everything #

IRCv3 gathers specifications that add negotiated mechanisms: authentication, tags, server timestamps, and message grouping, among others. The client discovers server capabilities with CAP. An extension remains useful only if both sides implement and negotiate it.

There is no universal button transforming all networks into the same 'IRCv3' experience. History, persistence, and identities still depend on available capabilities and the choices of each service.

Sources & Verification

Examples use pseudonyms and fictional domains, except for explicitly documented connection points. Network-specific extensions and settings are noted in the text.