Internet Relay Chat ( IRC ) is an application layer protocol that facilitates communication in text form. The chat process works on the client/server network model. IRC clients are user-installed computer programs on their systems or web-based applications that run either locally in the browser or on third-party servers. This client communicates with the chat server to transfer messages to other clients. IRC is primarily designed for group communication in discussion forums, called channels, but also allows one-to-one communication through private messages as well as chat and data transfer, including file sharing.
Client software is available for every major operating system that supports Internet access. As of April 2011, the top 100 IRC networks serve more than half a million users at a time, with hundreds of thousands of channels running on a total of about 1,500 servers from around 3,200 servers worldwide. The use of IRC has declined steadily since 2003, losing 60% of its users (from 1 million to about 400,000 in 2012) and half of its channels (from half a million in 2003).
Video Internet Relay Chat
Histori
Memulai
IRC was created by Jarkko Oikarinen in August 1988 to replace a program called MUT (MultiUser Talk) on a BBS called OuluBox at Oulu University in Finland, where he worked in the Information Processing Science Department. Jarkko intends to expand the BBS software he manages, to allow news in Usenet style, real-time discussions, and similar BBS features. The first part he carried out was the chat section, which he did with the borrowed parts written by his friends Jyrki Kuoppala and Jukka Pihl. The first IRC network runs on a single server named tolsun.oulu.fi. Oikarinen finds inspiration in a chat system known as Bitnet Relay, which operates on BITNET.
Jyrki Kuoppala encouraged Jarkko to ask Oulu University to release IRC code so it could also run outside Oulu, and after they were finally released, Jyrki Kuoppala immediately installed another server. This is the first "irc network". Jarkko got friends at the University of Helsinki and the University of Tampere to start running IRC servers as the number of users increased and other universities soon followed. At the moment Jarkko realizes that the rest of the BBS features may not fit in the program.
Jarkko deals with people at the University of Denver and Oregon State University. They have their own IRC network and want to connect to Finnish network. They have obtained a program from one of Jarkko's friends, Vijay Subramaniam - the first non-Finnish to use IRC. IRC then grew larger and accustomed across Finland's national network - Funet - and then connected to Nordunet, the Scandinavian internet branch. In November 1988, IRC had spread across the Internet and in mid-1989, there were about 40 servers worldwide.
EFnet
In August 1990, the first major dispute took place in the IRC world. The "A-net" (Anarchy net) includes a server named eris.berkeley.edu. Everything is open, does not require a password and does not limit the number of connectors. As Greg "wumpus" Lindahl explains: "it has a wildcard server line, so people hooked up the server and crashed everyone." "Eris Free Network", EFnet, creates the first Q-lined (Q for quarantine) eraser engine from IRC. In the words of wumpus again: "Eris refuses to remove the sentence, so I formed EFnet.That's not a fight, I have all the centers to join, and almost everyone is involved." A-net is formed with eris server, EFnet is formed with non-eris server. History shows most servers and users use EFnet. After ANET broke up, the name EFnet became meaningless, and again it was the only IRC network.
Around that time IRC was used to report attempts by the 1991 Soviet coup during media outages. It was previously used in the same way during the Gulf War. These chat logs and other events are stored in the ibiblio archives.
Undernet Fork
Another fork effort, the first of which really made a big and lasting difference, was initiated by 'Wildthang' in the US, October 1992 (it was taken from EFnet ircd version 2.8.10). It was meant to be just a test network for developing bots but quickly grew to the network "to their friends and friends". In Europe and Canada a separate new network is underway and in December French servers are connected with Canada, and by the end of the month, French and Canadian networks are connected to the US, forming a network that then comes called "The Undernet".
The "undernetters" want to take ircd further in an attempt to make it less consumptive bandwidth and try to sort out the channel chaos (netsplits and takeovers) that are beginning to suffer. For the latter purpose, Undernet implements a time stamp, a new routing and offers CService - a program that allows users to register channels and then attempts to protect them from troublemakers. The list of first servers presented, from 15 February 1993, included servers from the United States, Canada, France, Croatia and Japan. As of August 15, a record number of new users is set for 57 users.
Standardization
In May 1993, RFC 1459 was published and details simple protocols for client/server operations, channels, one-to-one and one-to-many conversations. It should be noted that a large number of extensions such as CTCP, color and format are not included in the protocol specification, or character encoding, which causes various server and client implementations to deviate. In fact, software implementations vary significantly from one network to another, each network implementing their own policies and standards within their own codebase.
DALnet Fork
During the summer of 1994, the Undernet itself branched off. The new network is called DALnet (named after its founder: dalvenjah), established for better user service and more users and channel protection. One of the more significant changes in DALnet is the use of longer nicknames (the original ircd limit is 9 letters). Modified DALnet ircd created by Alexei "Lefler" Kosut. DALnet is thus based on the ircd undernet server, although the DALnet pioneer is an EFnet repellent. According to James Ng, early DALnet people were "ops in #StarTrek sick of constant splits/leftovers/takeovers/etc".
DALnet is quick to offer global WallOps (IRCop messages visible to users who w (/NickName w mode)), longer nickname, Q: Names of lined lines (unusable nicknames ChanServ, IRCop, NickServ, etc. ), global K: Line (prohibition of one person or entire domain from server or whole network), communication only IRCop: GlobOps, H mode indicating that IRCop is "helpop" Many of DALnet's new functions were written in early 1995 by Brian "Morpher" Smith and allow users to have nicknames, control channels, send scraps, and more.
IRCnet Fork or Great Split
In July 1996, after months of fire warfare and discussion on the mailing list, there was still more division because of disagreements about how ircd developments should evolve. Especially, "Europe" (most of those servers are in Europe) who later called themselves IRCnet argue for nick and channel delays where EFnet parties argue for timestamps. There is also disagreement about policy: the European side has begun to establish a set of rules that direct what IRCops can and can not do, a point of view opposed by the US side.
Most (not all) IRCnet servers exist in Europe, while most EFnet servers reside in the US. This event is also known as "The Great Split" in many IRC communities. Since then, EFnet (since August 1998) has grown and exceeded the number of users it has. In the fall of 2000, EFnet had around 50,000 users and IRCnet 70,000.
Today
After the golden era during the 1990s and early 2000s (240,000 users in QuakeNet in 2004), IRC has significantly decreased, losing about 60% of users between 2003 and 2012, with users moving to more modern social media platforms such as Facebook or Twitter, but also to open platforms such as XMPP developed in 1999. Certain networks such as Freenode have not followed the overall trend and have more than quadrupled in size over the same period. By 2016, Freenode is the largest IRC network with about 90,000 users.
In 2016, a new standardization effort is underway under a working group called IRCv3, which focuses on more advanced client features such as instant notifications, better history support, and enhanced security.
Maps Internet Relay Chat
Technical information
IRC is an open protocol that uses TCP and, optionally, TLS. The IRC server can connect to other IRC servers to expand the IRC network. The user accesses the IRC network by connecting the client to the server. There are many client implementations, such as mIRC, HexChat and irssi, and server implementations, eg. The original IRCd. Most IRC servers do not require users to register an account but a nick (nickname) is required before connecting.
IRC was originally a plain text protocol (though later extended), which on request was assigned port 194/TCP by IANA. However, the de facto standard always runs IRC on 6667/TCP and the nearest port number (eg TCP port 6660-6669, 7000) to avoid having to run IRCd software with root privileges.
The protocol specifies that the character is 8-bit but does not specify the text encoding character that should be used. This can cause problems when users using different clients and/or different platforms want to communicate.
All currently used client-to-server IRC protocols are derived from protocols implemented in IRC2's irc2.4.0 server version, and are documented in RFC 1459. Since RFC 1459 was published, a new feature in irc2.10 implementation led to the publication of several protocol documents that revised (RFC 2810, RFC 2811, RFC 2812 and RFC 2813); However, changes to this protocol have not been widely adopted among other implementations.
Although many specifications on the IRC protocol have been published, there is no official specification, because the protocol remains dynamic. There are hardly any clients and very few servers that rely solely on the above RFC as a reference.
Microsoft created an extension for IRC in 1998 via proprietary IRCX. They then stop distributing software that supports IRCX, instead of developing an exclusive MSNP.
The standard structure of IRC server network is a tree. Messages are routed along only the required tree branches but the state of the network is sent to each server and there is generally a high level of implicit trust between servers. This architecture has a number of problems. Malicious or harmful servers can cause massive damage to the network and any changes in the structure, whether intentional or consequent to the conditions on the underlying network, require net-splits and net-join. This results in a lot of network traffic and fake out/joining messages to users and the loss of temporary communications to users on separate servers. Adding a server to a large network means a large background bandwidth load on the network and a large memory load on the server. However, once defined, each message to multiple recipients is delivered in the same way as multicast, meaning each message travels to the network link exactly once. This is the power compared to non-multicasting protocols such as Simple Mail Transfer Protocol (SMTP) or Extensible Messaging and Presence Protocol (XMPP).
IRC daemons can also be used on local area networks (LANs). IRC can be used to facilitate communication between people within a local area network (internal communication).
Commands and replies
IRC has a line-based structure. The client sends a single line message to the server, receives a reply to the message and receives a copy of some messages sent by another client. In most clients, users can enter a command by prefixing with '/'. Depending on the command, this can be handled entirely by the client, or (generally for commands that the client does not recognize) is passed directly to the server, possibly with some modifications.
Due to the nature of the protocol, automated systems may not always be able to pair commands sent in reply with full reliability and are subject to guessing.
Channels
The basic means of communicating with a group of users in an established IRC session is via the channel . Channels on the network can be displayed using the IRC LIST command, which lists all currently available channels that do not have s or p set mode, on a particular network.
Users can join channels using the JOIN command, in most clients available as /join #channelname . Messages sent to the joined channel are then forwarded to all other users.
Channels available across IRC networks start with '#', while local to server uses '& amp;'. Other less common types of channels include channel '- channel' modeless' without operator - and '!' channel, channel-time shape that is timestamped on networks that are not normally time-stamped.
Mode
Users and channels may have mode represented by case-sensitive letters and set using the MODE command. The user mode and channel mode are separate and can use the same letter to interpret different things (eg user mode "i" is invisible mode while the "i" channel mode is just an invitation.) The mode is usually set and not set using the mode command that picks up target (user or channel), a set of modes to set () or unset (-) and any necessary parameters of the mode.
Some but not all channel modes take parameters and some channel modes apply to users on the channel or add or remove masks (eg ban masks) from the list associated with the channel instead of applying to the channel as a whole. The mode that applies to users on the channel has the corresponding symbol used to represent the mode in the name reply (sent to the client for the first time joining the channel and the use of the name command) and in many clients it is also used to represent it in the client list of users displayed in the channel or to display its own indicator for user mode.
To correctly decode the sign in message and track the status of the channel, the client must know which mode of that type and for the mode that applies to the user on the channel whose symbol applies to what letter. At the beginning of this IRC implementation it has to be hard coded in the client but now there is a de facto default extension on a protocol called ISUPPORT that sends this information to the client at connection time using numeric 005.
There is a minor design error in the IRC associated mode that applies to users on the channel: the name message used to create the initial channel state can only send one mode per user on the channel, but some of these modes can be set on a single user. For example, if the user holds the carrier status (o) and the voice (v) status of the channel, the new client will not be able to see the lower priority mode (ie voice). Workaround for this is possible both on the client and server side but nothing is widely applied.
Standard (RFC 1459)
Many daemons and networks have added additional modes or modified the behavior of modes in the list above.
Channel Operator
A Channel Operator is a client on an IRC channel that manages channels. IRC Channel operators can be easily seen by the symbol "@" beginning with their name, or the Latin letter "o"/"o". In most networks, operators can:
- Kick a user
- Block users
- Provide Operator Status for other user IRC Channels or Voice IRC Channel Status.
- Change the IRC Channel topic while channel t mode is set.
- Change the IRC Channel Mode key.
IRC operators
There are also users who retain high privileges on their local servers, or the entire network; these are called IRC operators, sometimes shortened to IRCops or Opers (not to be confused with channel operators). Because IRCd implementation varies, so does IRC operator IRCd privilege given. RFC 1459 claims that IRC operators are "necessary crimes" to maintain cleanliness of the network, and therefore they should be able to disconnect and reconnect servers. In addition, to prevent malicious users or even malicious auto programs from entering IRC, IRC operators are usually allowed to disconnect clients and completely disallow IP addresses or complete subnets. Service-carrying networks (Nickserv et al.) Usually allow their IRC operators to also handle basic "ownership" issues. Further privileges may include channel bans (can join channels they may not follow, if not operated), can use channels they can not operate, be automatically-opped in channel always and so on.
Hostmasks
Hostmask is a unique IRC client identifier connected to an IRC server. IRC servers, services and clients including bots can use them to identify specific IRC sessions.
The hostmask format is nick! User @ host
. Hostmask looks similar to, but should not be confused with the e-mail address.
The nick part is the user's chosen nickname and can be changed when connected. The user part is the username reported by the ident on the client. If the ident is not available on the client, the username specified when the connected client is used after starting with the tilde.
The host part is the hostname that the client contacts. If the client's IP address can not be resolved to a valid hostname by the server, it is used instead of the hostname.
Because privacy implications expose IP addresses or client host names, some IRC daemons also provide privacy features, such as InspIRCD or UnrealIRCd mode "x". It lists the client's IP address or hides part of the client host name, making it unreadable by users other than IRCops. Users can also have the option to request a "virtual host" (or "vhost"), which will be displayed in the hostmask to allow for further anonymity. Some IRC networks like Freenode use this as "cloaks" to indicate that a user is affiliated with a group or project.
Challenges
The original IRC design problem is the amount of shared state data that limits its scalability, the absence of unique user identification leading to nicknamed collision problems, lack of netsplit protection by cyclic routing, trade-offs in scalability for real-time user presence information, weaknesses protocols that provide a platform for abuse, no transparent and optimized message redirects, and no encryption. Some of these issues have been discussed in IRC Modern .
Attack
Because IRC connections are usually unencrypted and typically include long periods of time, they are an attractive target for DoS/DDoS attackers and hackers. Therefore, a careful security policy is required to ensure that IRC networks are not vulnerable to attacks such as takeover wars. IRC networks may also be K-line or G-line users or servers that have adverse effects.
Some IRC servers support SSL/TLS connections for security purposes. This helps stop the use of packet sniffer programs to obtain IRC user passwords, but has little use beyond this scope due to the general nature of IRC channels. SSL connections require client and server support (which may require users to install SSL binaries and patches or IRC client-specific modules on their computers). Some networks also use SSL for server connections to servers, and provide custom channel flags (such as S
) to only allow users connected to SSL on the channel, while not allowing operator identification in clear text, to utilize better benefits given SSL.
IRC serves as an early laboratory for various types of Internet attacks, such as using ICMP unreachable messages to disconnect a TCP-based IRC (nuking) connection to disrupt users or facilitate a takeover.
Abuse prevention
One of the most controversial technical issues surrounding the implementation of IRC, which has survived to this day, is the feasibility of the "Nick/Channel Delay" protocol vs. "Timestamp". Both methods exist to solve the problem of denial-of-service attacks, but take a very different approach. The problem with the original IRC protocol implemented was that when two servers were split and rejoined, both sides of the network would join their channel. If a user can join a "split" server, where channels on the other side of the network are empty, and get operator status, they will be "combined" channel operators after netsplit expires; if the user takes a nickname that is on the other side of the network, the server will kill both users when rejoined (ie, 'collision'). It is often abused to "mass kill" all users on the channel, thus creating a "no-op" channel where no operator is present to handle abuse. In addition to causing problems in IRC, it encourages people to reject service attacks against IRC servers to cause netsplits, which they then abuse.
Suspend nick/channel
The nick/channel delay solution (abbreviated ND/CD) for this problem is very simple. Once the outbound and nicknamed users become available, or the channel stops there because all users are separated (as is often the case during netsplit), the server will not allow the user to use that nickname or join the channel, until a certain period of time (delays ) has passed. The idea behind this is that even if netsplit happens, it's useless to the offender because they can not take the nickname or get the carrier status on the channel, and thus no nicknames or 'coalescing' collisions can occur. To some extent, this inconvenience is a legitimate user, who may be forced to use a different name shortly after re-joining (adding underscore is popular).
Timestamping
Alternate protocols, time stamps or TS , take a different approach. Every nickname and channel on the network is given a timestamp - the date and time it was created. When netsplit occurs, two users on each side are free to use the same nickname or channel, but when both parties join, only one can survive. In the case of nicknames, newer users, according to their TS, are killed; when the channel collides, the members (users in the channel) are merged, but the channel operators on the "losing side" of the separation lose their carrier channel status.
TS is a much more complex protocol than ND/CD, both in design and implementation, and although it has been through several revisions, some implementations still encounter problems with "desyncs" (where two servers on the same network disagree about the current status of the network ), and allows too much leeway in what is allowed by the losers. Under the original TS protocol, for example, there is no protection against the user specifying a ban or other mode on the missing channel which will then be merged when the separation is combined, even though the user who has set the mode loses the status of their channel operator. Some modern TS-based IR servers also incorporate some form of ND and/or CD in addition to timestamping in an effort to prevent further abuse.
Most networks today use the timestamping approach. The limitation of timestamp versus ND/CD causes some servers to break away from EFnet and form a newer IRCnet. After the split, EFnet moves to the TS protocol, while IRCnet uses ND/CD.
SAVE
In the latest version of IRCnet ircd, as well as ircds using the TS6 protocol (including Charybdis), ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns each client a UID when connected to an IRC server. This ID starts with a number, which is forbidden in nicks (although some ircds, ie IRCnet and InspIRCd, allow clients to switch to their own UID as a nickname).
If two clients with the same nickname join from different sides of netsplit ("nick collision"), the first server to see this collision will force the second client to change their nick to their UID, thus saving both. client from disconnected. In IRCnet, the nickname will also be locked for some time (ND) to prevent both clients from changing back to the original nickname, thus colliding again.
Network
There are thousands of IRC networks running in the world. They run various IRC server implementations, and are managed by various groups of IRC operators, but the protocols exposed to IRC users are very similar, and all IRC networks are accessible by the same client software, although there may be slight incompatibilities and limited. functionality due to the implementation of different server software.
The largest IRC networks have traditionally been classified as "the Big Four" - the term for networks that are above statistics. The Big Four network changes periodically, but because of the nature of the IRC community, there are a large number of other networks for users to choose from.
Historis "Big Four" adalah:
- EFnet
- IRCnet
- Undernet
- DALnet
IRC reached 6 million simultaneous users in 2001 and 10 million users in 2003.
In March 2015, the largest IRC network is:
- freenode - about 99k users in peak hours
- IRCNetÃ, - about 44k users in peak hours
- QuakeNetÃ, - about 36k users in peak hours
- EFnetÃ, - about 26k users in peak hours
- Undernet - about 25k users in peak hours
- RizonÃ, - about 25k users in peak hours
- AnonOpsÃ, - about 30k users in peak hours
- ChatAmigosÃ, - about 24k users in peak hours
Currently, the top 100 IRC networks have around 460k of users connected during peak hours.
Timeline
URI scheme
There are three uniform identifiable resource identification (URI) schemes for Internet Relay Chats: irc
, irc6
, and ircs
. When supported, they allow hyperlinks of various forms, including
irc://& lt; host & gt; [: & lt; port & gt;]/[& lt; channel & gt; [? & lt; channel_keyword & gt;]] ircs://& lt; host & gt; [: & lt; port & gt;]/[& lt; channel & gt; [? & lt; channel_keyword & gt;]] irc6://& lt; host & gt; [: & lt; port & gt;]/[& lt; channel & gt; [? & lt; channel_keyword & gt;]]
(where items enclosed within brackets ([,]) are optional) to be used (if necessary) connected to a specified host (or network, if known to an IRC client) and join the specified channel. (This can be used inside the client itself, or from other applications such as Web browsers). irc is the default URI, irc6 specifies the connection made using IPv6, and ircs specifies a secure connection.
As per the specification, the usual hash symbol (#) will be added to the channel name starting with alphanumeric characters - allowing it to be deleted. Some implementations (for example, mIRC) will do so unconditionally to generate additional (usually unintentional) (for example, channel ##), if included in the URL.
Some implementations allow multiple channels to be specified, separated by commas. [1]
Client
Client software
The client software exists for various operating systems or software packages, as well as web-based or inside games. Many different clients are available for different operating systems, including Windows, Unix and Linux, Mac OS X and mobile operating systems (such as iOS and Android). In Windows, mIRC is one of the most popular clients.
Some programs that can be expanded via plug-in also serve as a platform for IRC clients. For example, a client called ERC, written entirely in Emacs Lisp, is included in v.22.3 Emacs. Therefore, any platform that can run Emacs can run ERC.
A number of web browsers have internal IRC clients, such as Opera (version 12.17 and earlier) and ChatZilla add-ons for Mozilla Firefox (included as a built-in component of SeaMonkey). Web-based clients, such as Mibbit and open source KiwiIRC, can run on most browsers.
Games like WarÃ,çow , Unreal Tournament (up to Unreal Tournament 2004), Uplink based games, 0 AD and ZDaemon include IRC.
The Ustream chat interface is IRC with custom authentication as well as twitch.tv (Formerly Justin.tv).
Bots
The typical use of bots in IRC is to provide IRC services or specific functionality in the channel such as to host a chat-based game or provide notification of external events. But some IRC bots are used to launch malicious attacks such as denial of service, spam, or exploitation.
Bouncer
A program that runs as a daemon on a server and serves as a persistent proxy known as a BNC or bouncer. The goal is to maintain a connection to an IRC server, acting as a relay between server and client, or simply acting as a proxy. If a client loses network connectivity, BNC can stay connected and archive all traffic for later delivery, allowing users to continue their IRC session without interrupting their connection to the server.
Furthermore, as a way to get effects like bouncers, IRC clients (usually text-based, eg Irssi) can run on an ever-active server where users connect via ssh. It also allows devices that only have ssh functionality, but no self-installed IRC client, to connect to IRC, and allow sharing of IRC sessions.
In order for IRC clients not to stop when the ssh connection is closed, the client can run inside a terminal multiplexer such as GNU Screen or tmux, so that it stays connected to the IRC (s) network constantly and can record conversations on channels that the user is interested in, or maintain the presence of channels on the network. Modeled after this setting, in 2004 IRC clients followed a client-server model, called Smuxi, launched.
Search engine
There are many search engines available to help users find what they are looking for on IRC. Generally search engines consist of two parts, "back-end" (or "spider/crawler") and "search engine" front-end.
The back-end (spider/webcrawler) is the workhorse of the search engine. It is responsible for crawling the IRC server to index the information sent through it. The indexed information usually consists only of channel text (text publicly displayed on public channels). Storage methods are usually some kind of relational database, such as MySQL or Oracle.
"Search engine" front-end is the user interface to the database. It supplies users with a way to search the indexed information database to retrieve the data they are looking for. This front-end search engine can also be encoded in various programming languages.
Most search engines have their own spiders which are sole applications responsible for crawling IRC data and indexing itself; however, others are "user-based" indexers. The latter rely on users to install their "add-on" into their IRC clients; the add-on is what transmits the channel information database from whatever channel happens to the user.
Many users have implemented their own ad hoc search engine using logging features built into many IRC clients. This search engine is usually implemented as a bot and is dedicated to a particular channel or group of related channels.
IRC Modern
IRC has changed a lot throughout its life on the Internet. The new server software has added many new features.
- Services: Network-operated bots to facilitate the registration of nicknames and channels, send messages for offline users and network operator functions.
- Additional mode: Although the original IRC system uses a set of user modes and standard channels, the new server adds many new modes to features such as removing color codes from text, or obfusing the "cloaking" hostmask to protect against denial-of- service.
- Proxy detection: Most modern servers support user detection attempting to connect via an insecure (misconfigured or exploited proxy) proxy server, which can then be rejected. An example is the Blitzed Open Proxy Monitor or BOPM. This proxy detection software is used by some networks, although the real time proxy list is dead since early 2006.
- Additional commands: New commands can be things like short commands to issue commands to the Service, to network operator commands only to manipulate user user attacks.
- Encryption: For the client-to-server foot of the SSL connection it might be used (messages are no longer safe after being redirected to other users on standard connections, but it makes tapping or tapping individual IRC sessions difficult). For client-to-client communication, SDCC (Secure DCC) can be used.
- Connection protocol: IRC can be connected via IPv4, the current standard version of the Internet Protocol, or by IPv6, the next generation protocol version.
There is a standardization effort and adding new features to the IRC protocol by the IRCv3 working group.
Character encoding
IRC still does not have a globally accepted standard convention for how to transmit characters beyond the 7-bit ASCII repertoire. IRC servers typically transfer messages from clients to other clients only as a byte sequence, without interpretation or recoding of characters. The IRC protocol (unlike for example MIME or HTTP) does not have a mechanism for announcing and negotiating character encoding options. This has placed the responsibility for selecting the appropriate codec character on the client. In practice, IRC channels mostly use the same character encodings that are also used by operating systems (especially Unix derivatives) in their respective language communities:
- The 7-bit Era: In the early days of IRC, especially among Scandinavian and Finnish language users, the ISO 646 national variant was the dominant character encoding. It encodes non-ASCII characters such as ÃÆ' ÃÆ' à ¢ ÃÆ'... ÃÆ' ä ÃÆ' ö ÃÆ' à ¥ in position code 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D (AS-ASCII: [ \ ] { | } ). That's why these codes are always allowed in the nickname. According to RFC 1459, {| } in the nickname should be treated as a case equivalent [\] respectively. In the late 1990s, the use of 7-bit coding has disappeared in favor of ISO 8859-1, and such equality mapping was dropped from some IRC daemons.
- The 8-bit Era: Since the early 1990s, 8-bit encodings such as ISO 8859-1 have become commonly used for European languages. Russian users have a choice of KOI8-R, ISO 8859-5 and CP1251, and since about 2000, modern Russian IRC networks convert between these commonly used Cyrillic codes.
- Multi-byte era: For a long time, East Asian IRC channels with ideographic scripts in China, Japan and Korea have used multi-byte coding like EUC or ISO-2022-JP. With the general migration from ISO 8859 to UTF-8 on Linux and Unix platforms since about 2002, UTF-8 has become an increasingly popular substitute for many of the 8-bit encodings used earlier in the European channel. Some IRC clients are now able to read messages either in ISO 8859-1 or UTF-8 on the same channel, consciously autodetecting which encoding is used. The shift to UTF-8 started especially in Finnish-speaking IRC (Merkist̮'̦ (Finnish) ).
Today, encoding UTF-8 Unicode/ISO 10646 will be the most likely competitor for future single-character encoding of characters for all IRC communications, if such standards relax the 510-byte message size restriction. UTF-8 is ASCII compatible and includes a superset of all common character set character sets that are used.
Share file
Just like sharing a conventional P2P file, users can create file servers that allow them to share files with each other using bots or IRC scripts specific to their IRC clients. Often users will group together to distribute warez via the IRC bot network.
Source of the article : Wikipedia