𝖂𝖎ƙ𝖎𝖊

Internet Relay Chat: mudanças entre as edições

imported>Júlio Chagas
(WP:V)
imported>VulcanSphere
 
(122 revisões intermediárias por 39 usuários não estão sendo mostradas)
Linha 1: Linha 1:
{{Desatualizado|Esta página}}
{{Short description|Protocolo para bate-papo e mensagens em tempo real na Internet}}
{{mais notas|data=dezembro de 2013}}
{{Hatnote|''"IRC" redireciona aqui. Para outros usos, consulte [[IRC (desambiguação)]].'' {{Hatnote inline|selfref=yes|1=''Para canais IRC relacionados com a Wikipédia, veja [[Wikipedia:IRC]].''}}}}
{{Alvo-redireccionamento|IRC}}
{{Pilha de protocolos TCP/IP}}
{{ProtocolosIP}}
[[File:Tolsun 2.jpg|thumb|right|O primeiro servidor ''IRC'', tolsun.oulu.fi, um servidor <!-- [[:en:Sun-3]] -->''Sun-3'' em exibição perto do centro de informática da universidade de Oulu (2001).]]
[[Ficheiro:Screenshot-XChat- Moniker42 @ FreeNode - -ubuntuforums (+tn)-1.png|thumb|250px|Uma captura de ecrã do XChat, a multiplataforma do IRC.]]
<!-- [[Imagem:Screenshot-XChat- Moniker42 @ FreeNode - -ubuntuforums (+tn)-1.png|thumb|250px|Uma captura de tela do ''XChat'', um cliente ''IRC'' multiplataforma]] -->
'''Internet Relay Chat''' ('''IRC''') é um protocolo de comunicação utilizado na [[Internet]]. Ele é utilizado basicamente como bate-papo ([[chat]]) e troca de arquivos, permitindo a conversa em grupo ou privada. Foi documentado formalmente pela primeira vez em 1993, com a RFC 1459.
O '''''Internet relay chat''''' (''IRC'') é um sistema de bate-papo baseado em texto que permite discussões entre qualquer número de participantes nos chamados canais de conversação, bem como discussões entre apenas dois parceiros (em diálogos de perguntas e respostas, por exemplo).<ref name="RFC 1459">
{{citar web
|autor1 =Jarkko Oikarinen
|autor2 =Darren Reed
|url=https://datatracker.ietf.org/doc/html/rfc1459#section-1
|título=''RFC'' 1459, Protocolo ''IRC''
|língua=en
|data=maio de 1993
|acessodata=12-06-2021}}
</ref> Qualquer participante pode abrir um novo canal de conversa e, um único usuário de computador pode, participar de vários canais simultâneos.


== História ==
Para estabelecer ou participar de um bate-papo, um programa de rede conhecido como cliente ''IRC'', conectando-se a um servidor, é necessário para acessar um canal. O cliente ''IRC'' pode ser um programa independente no computador local (''mIRC'' e ''XChat'', por exemplo) ou assumir a forma de uma interface de usuário especial de dentro de um programa maior, como um navegador de {{lang|en|''Internet''}}. Por exemplo, o navegador ''[[Opera]]'' inclui um cliente ''IRC'' e clientes como o <!-- [[:en:Mibbit]] -->''Mibbit'', o ''IRCCloud'', o ''KiwiIRC'' e o ''The Lounge Chat'' do [[Instituto de Tecnologia de Massachusetts|''MIT'']] podem funcionar em conexão com muitos navegadores populares.
=== Nascimento ===
O IRC foi escrito pelo programador [[finlandês]] [[Jarkko Oikarinen]] em [[1988]] na Universidade de [[Oulu]] na [[Finlândia]].<ref>{{citar web
|url=http://daniel.haxx.se/irchistory.html
|titulo=History of IRC (Internet Relay Chat)
|publicado=daniel.haxx.se
|acessodata=[[19]] de fevereiro  de [[2011]]
}}</ref> O trabalho começou em agosto daquele ano e o objetivo era criar um sistema de [[teletexto]] comunitário que rodasse em [[TCP/IP]] com recursos avançados como conversa pública massiva entre milhares de usuários separados por canais e com mensagens privadas entre eles. Eles diziam que o IRC seria um complemento e até um avanço da [[Usenet]] pois permitiria encontro maciço de grupos em tempo real. Os amigos de Jarkko, Markku Järvinen e Vijay Subramaniam ajudaram na concepção dos clientes e servidores.


As primeiras redes surgiram na Finlândia e rodavam em servidores de Universidades. Logo se espalharam por instituições em toda [[Escandinávia]]. Em [[1989]] já existiam mais de 40 servidores espalhados por todo o mundo. Em [[1993]] durante a [[Guerra da Golfo]] o IRC foi usado para noticiar eventos em tempo real<ref>{{citar web
Uma rede ''IRC'' de servidores interconectados que operam como estações de retransmissão é usada para mediar as chamadas no ''IRC''. O recurso essencial desta rede é sua topologia de comunicação ''BITNET'', que permite apenas um caminho de comunicação entre dois participantes. Historicamente, isso garantiu comunicação eficiente porque, nos primeiros dias do ''IRC'', as linhas intercontinentais de dados tinham uma capacidade muito limitada. A topologia permitiu que mensagens de um cliente em um continente não fossem enviadas individualmente para cada cliente em outro continente mas apenas uma vez para um servidor local que então as distribui para os clientes. Apesar das capacidades de gerenciamento limitadas, foram possíveis "paisagens de bate-papo". A desvantagem é a falta de redundância, que se manifesta nos chamados {{lang|en|''net split''}}''s'': se algum servidor falha, a rede divide automaticamente as peças separadas até que uma nova conexão seja estabelecida entre as partes.
 
As maiores redes ''IRC'' consistem em várias dezenas de servidores ''IRC'' que conectam simultaneamente mais de 100.000 usuários e gerenciam dezenas de milhares de canais em que milhares de pessoas podem participar simultaneamente. Apesar dessas enormes proporções, o atraso em um texto enviado é na ordem de décimos de segundo e raramente excede o tempo de um segundo.
 
A utilização do ''IRC'' vem, desde 2003, diminuindo constantemente. Os números apontam uma perda de 60% dos usuários (de 1 milhão em 2003 para cerca de 400 mil em 2021) e mais de metade dos canais (de meio milhão em 2003 para menos de 200 mil em 2021). Em abril de 2011, hospedando centenas de milhares de canais e operando em um total de aproximadamente 1.500 servidores (além de aproximadamente 3.200 servidores ''IRC'' em todo o mundo),<ref>
{{citar web
|url=http://irc.netsplit.de/servers/summary.php
|título=Servidores ''IRC'' - sumário
|língua=en
|acessodata=21-07-2021
|publicado=irc.netsplit.de
|arquivourl=https://web.archive.org/web/20110422191726/http://irc.netsplit.de/servers/summary.php
|arquivodata=22-04-2011
|urlmorta=sim}}
</ref> as 100 principais redes ''IRC'' serviam mais de meio milhão de usuários.<ref name="irc networks top 100">
{{citar web
|url=http://irc.netsplit.de/networks/top100.php
|título=Redes ''IRC'' - ''Top'' 100
|língua=en
|acessodata=21-07-2021
|publicado=irc.netsplit.de}}
</ref> Em junho de 2021, existiam 481 diferentes redes ''IRC'' conhecidas por estarem operando.<ref name="networks">
{{citar web
|url=https://netsplit.de/networks/
|título=Redes ''IRC'' - em ordem alfabética
|língua=en
|ano=2020
|website=netsplit.de
|acessodata=21-07-2021}}
</ref> Dentre tais redes, a ''[[Libera Chat]]'' de código aberto (fundada em maio de 2021) tem a maioria dos usuários, com 21.348 canais em 15.433 servidores. Também entre elas, as 100 melhores compartilhavam 188.336 canais operando em 96.708 servidores.<ref name="top 100">
{{citar web
|url=https://netsplit.de/networks/top100.php
|título=Redes ''IRC'' - ''Top'' 100
|ano=2020
|website=netsplit.de
|acessodata=21-07-2021}}
</ref>
 
Do ponto de vista técnico, o {{lang|en|''Internet relay chat''}} é implementado como um protocolo de [[camada de aplicação]] para facilitar a comunicação na forma de texto. O processo de {{lang|en|''chat''}} funciona em um [[Modelo cliente–servidor|modelo de rede cliente-servidor]]. Conforme já discutido, os clientes ''IRC'' podem ser programas de computador autônomos ou aplicativos baseados na {{lang|en|''web''}} executados localmente no navegador ou em um servidor de terceiros. Esses clientes se comunicam com servidores de {{lang|en|''chat''}} para transferir mensagens para outros clientes.<ref name="rfc 1459 1 introduction">
{{citar web
|url=https://datatracker.ietf.org/doc/html/rfc1459#section-1
|título=Protocolo ''IRC'' - Introdução
|língua=en
|seção=1
|página=4
|doi=10.17487/RFC1459
|acessodata=21-07-2021}}
</ref> O ''IRC'' é projetado principalmente para <!-- [[:en:Many-to-many]] -->
comunicação em grupo (em fóruns de discussões chamados de [[#Canal|
canais]])<ref>
{{citar web
|url=https://datatracker.ietf.org/doc/html/rfc1459#section-3.2
|título=Protocolo ''IRC'' - Um para muitos
|língua=en
|seção=3.2
|página=11
|doi=10.17487/RFC1459
|acessodata=21-07-2021}}
</ref> mas também permite comunicação um-para-um por meio de [[Mensageiro instantâneo|mensagens privadas]],<ref>
{{citar web
|url=https://datatracker.ietf.org/doc/html/rfc2810#section-5.1
|título=''IRC'': Arquitetura - Comunicação um para um
|língua=en
|seção=5.1
|página=5
|doi=10.17487/RFC1459
|acessodata=21-07-2021}}
</ref> bem como [[Direct Client-to-Client|bate-papo e transferência de dados]]<ref>
{{citar web
|url=http://www.irchelp.org/irchelp/rfc/dccspec.html
|título=Descrição do protocolo ''DCC''
|língua=en
|acessodata=21-07-2021
|último =Rollo
|primeiro =Troy
|publicado=irchelp.org}}
</ref> (incluindo [[compartilhamento de arquivos]]).<ref>
{{citar livro
|último =Wang
|primeiro =Wallace
|título=Roube este livro de compartilhamento de arquivos
|língua=en
|edição=1ª
|data=25-10-2004
|publicado=<!-- [[:en:No Starch Press]] -->no starch press
|local=[[São Francisco (Califórnia)]]
|isbn=978-1-59327-050-6
|páginas=[https://archive.org/details/stealthisfilesha00wang/page/61 61 à 67]
|capítulo=Mensagens instantâneas e salas de ''chat'' ''online'': ''Internet Relay Chat'' (''IRC'')
|capítulourl= https://archive.org/details/stealthisfilesha00wang/page/61}}
</ref>
 
O [[Comparação dos clientes de IRC|{{lang|en|''software''}} cliente]] está disponível para todos os principais sistemas operacionais que oferecem suporte ao acesso à {{lang|en|''Internet''}}.<ref name=Sage>
{{citar web
|título=Canal ''IRC'' ''SAGE''
|língua=en
|url=http://www.sage.org/about/irc.html
|publicado=Sage - Grupo de interesse especial ''USENIX'' para administradores de sistemas
|acessodata=21-07-2021
|arquivourl=https://web.archive.org/web/20120207191923/http://sage.org/about/irc.html
|arquivodata=07-02-2012
|urlmorta=sim}}
</ref>
 
== História == <!-- {{anchor|:en:MultiUser Talk}} Esta seção está vinculada ao redirecionamento
"[[:en:MultiUser Talk]]" na enwiki e, assim como o {{see also|:en:IRCd#History}}, ainda não existe na ptwiki -->
 
O ''IRC'' foi criado por [[Jarkko Oikarinen]] em agosto de 1988 para substituir um programa chamado ''MUT'' (''MultiUser Talk'') em um [[Bulletin board system|''BBS'']] chamado ''OuluBox'' na <!-- [[:en:University of Oulu]] -->
Universidade de Oulu na [[Finlândia]], onde ele trabalhava no departamento de ciência de processamento de informação. Jarkko pretendia estender o {{lang|en|''software''}} ''BBS'' que administrava, para permitir notícias no estilo ''[[Usenet]]'', discussões em tempo real e recursos ''BBS'' semelhantes. A primeira parte que ele implementou foi a parte do {{lang|en|''chat''}}, que ele fez com partes emprestadas escritas por seus amigos Jyrki Kuoppala e Jukka Pihl. A primeira rede ''IRC'' estava rodando em um único servidor chamado tolsun.oulu.fi.<ref name="stenberg">
{{citar web
|último =Stenberg
|primeiro =Daniel
|título=História do ''IRC'' (''Internet relay chat'')
|língua=en
|url=https://daniel.haxx.se/irchistory.html
|acessodata=21-07-2021
|data=29-03-2011
|citação=Eu não experimentei tudo isso. Encontrei informações em vários lugares e recebi informações de várias pessoas para escrever isto. As pessoas que me ajudaram com isso incluem: Greg "wumpus" Lindahl, Vesa "vesa" Ruokonen, James Ng, Tuomas Heino, Richard (águia na undernet), Ari Lemmke}}
</ref> Oikarinen encontrou inspiração em um sistema de bate-papo conhecido como <!-- [[:en:BITNET Relay]] -->
''Bitnet Relay'', que operava na ''[[BITNET]]''.<ref name="founding irc">
{{citar web
|url=http://www.mirc.com/jarkko.html
|título=''IRC'' de fundação
|língua=en
|acessodata=21-07-2021
|último =Oikarinen
|primeiro =Jarkko
|autorlink =Jarkko Oikarinen}}
</ref>
 
Jyrki Kuoppala pressionou Oikarinen para pedir à Universidade de Oulu que liberasse o código do ''IRC'' para que ele também pudesse ser executado fora de Oulu e, depois que eles finalmente o liberaram, Jyrki Kuoppala imediatamente instalou outro servidor. Esta foi a primeira "rede ''IRC''". Oikarinen conseguiu que alguns amigos da [[Universidade de Helsinque]] e da [[Universidade de Tampere]] começassem a rodar servidores ''IRC'' quando seu número de usuários aumentou e outras universidades o seguiram. Nesse momento, Oikarinen percebeu que o restante dos recursos do ''BBS'' provavelmente não caberiam em seu programa.<ref name="stenberg"/>
 
Oikarinen entrou em contato com pessoas da [[Universidade de Denver]] e da [[Universidade do Estado do Oregon|Universidade do Estado de Oregon]]. Eles tinham sua própria rede ''IRC'' funcionando e queriam se conectar à rede finlandesa. Eles haviam obtido o programa de um dos amigos de Oikarinen, Vijay Subramaniam (a primeira pessoa não finlandesa a usar o ''IRC''). O ''IRC'' cresceu , foi usado em toda a rede nacional finlandesa (''Funet'') e então conectado à <!-- [[:en:NORDUnet]] -->''NORDUnet'', a ramificação escandinava da {{lang|en|''Internet''}}. Em novembro de 1988, o ''IRC'' se espalhou pela {{lang|en|''Internet''}} e, em meados de 1989, haviam cerca de 40 servidores em todo o mundo.<ref name="stenberg"/>
 
=== ''EFnet'' ===
 
Em agosto de 1990, o primeiro grande desacordo ocorreu no mundo ''IRC''. A "''A-net''" (rede  anarquia) incluía um servidor chamado eris.berkeley.edu. Estava tudo aberto, não exigia senhas e não tinha limite para o número de conexões. Como Greg "wumpus" Lindahl explica: "ela tinha uma linha de servidor curinga, então as pessoas estavam conectando servidores e <!-- [[:en:IRC_takeover#Nick_collision]] -->colidindo com todo mundo". A "Rede Livre Eris" (''[[EFnet]]'') fez a máquina eris ser a primeira do ''IRC''
a ser alinhada como Q (Q para quarentena). Nas palavras de wumpus novamente: "''Eris'' se recusou a remover essa linha, então formei a ''EFnet''. Não foi muito difícil, consegui todos os {{lang|en|''hub''}}s para entrar e quase todo mundo foi levado junto." A ''A-net'' foi formada com os servidores eris, enquanto a ''EFnet'' foi formada com os servidores não-eris. A história mostra que a maioria dos servidores e usuários usam a ''EFnet''. Assim que a ''A-net'' se desfez, o nome ''EFnet'' perdeu o sentido e mais uma vez existia uma única rede ''IRC''.<ref name="stenberg"/>
 
Naquela época, o ''IRC'' foi usado para relatar a [[tentativa de golpe de Estado na União Soviética em 1991]] durante um <!-- [[:en:Media blackout]] -->apagão da mídia.<ref>
{{citar web
|url=http://www.ibiblio.org/pub/academic/communications/logs/report-ussr-gorbatchev
|título=Transcrições do ''IRC'' da época da tentativa de golpe de estado soviético de 1991
|língua=en
|acessodata=21-07-2021
|publicado=<!-- [[:en:ibiblio]] -->ibiblio
|local=[[Chapel Hill (Carolina do Norte)]]
|arquivourl=https://web.archive.org/web/20090628013626/http://www.ibiblio.org/pub/academic/communications/logs/report-ussr-gorbatchev
|arquivodata=28-06-2009}}
</ref> Anteriormente, ele havia sido usado de forma semelhante durante a [[Guerra do Golfo]].<ref>
{{citar web
|url=http://www.ibiblio.org/pub/academic/communications/logs/Gulf-War/
|url=http://www.ibiblio.org/pub/academic/communications/logs/Gulf-War/
|titulo=Index of /pub/academic/communications/logs/Gulf-War
|título=Registros IRC de eventos da Guerra do Golfo
|publicado=www.ibiblio.org
|língua=en
|acessodata=[[19]] de fevereiro  de [[2011]]
|acessodata=21-07-2021
}}</ref> entre usuários que tinham acesso à Internet em Universidades do [[Oriente Médio]].
|publicado=<!-- [[:en:ibiblio]] -->ibiblio
|local=[[Chapel Hill (Carolina do Norte)]]}}
</ref> <!-- [[:en:Chat log]] -->Registros de bate-papo desses e de outros eventos são mantidos no arquivo <!-- [[:en:ibiblio]] -->''ibiblio''.<ref>
{{citar web
|url=http://www.ibiblio.org/pub/academic/communications/logs/
|título=Registros dos principais eventos na comunidade ''online''
|língua=en
|acessodata=21-07-2021
|publicado=<!-- [[:en:ibiblio]] -->ibiblio
|local=[[Chapel Hill (Carolina do Norte)]]}}
</ref>
 
=== Bifurcação ''Undernet'' ===
 
Outra tentativa de bifurcação, a primeira que realmente fez uma grande e duradoura diferença, foi iniciada por "''Wildthang''" nos Estados Unidos da América em outubro de 1992 (saiu da ''EFnet'' ''ircd'' versão 2.8.10). Era para ser apenas uma rede de teste para desenvolver {{lang|en|''bot''}}s, mas rapidamente cresceu para uma rede "para amigos e seus amigos". Na Europa e no Canadá uma nova rede separada estava sendo trabalhada e em dezembro os servidores franceses se conectaram aos canadenses. No final do mês, as redes francesa e canadense foram conectadas à dos Estados Unidos da América, formando a que mais tarde veio a ser chamada de "''a [[Undernet]]''".<ref name="stenberg"/>
 
Os "''undernetters''" queriam levar o ''ircd'' mais longe, na tentativa de torná-lo menos consumidor de largura de banda e tentar resolver o caos de canais ([[Netsplit|{{lang|en|''netsplit''}}''s'']] e <!-- [[:en:IRC takeover]] -->{{lang|en|''takeover''}}''s'') que a ''EFnet'' começou a sofrer. Para o último propósito, a ''Undernet'' implementou {{lang|en|''timestamp''}}''s'', novo roteamento e ofereceu o ''CService'' (um programa que permitia aos usuários registrar canais e então tentava protegê-los de criadores de problemas). A primeira lista de servidores apresentada, de 15 de fevereiro de 1993, incluia os servidores dos Estados Unidos da América, do Canadá, da França, da Croácia e do Japão. Em 15 de agosto, o novo registro de contagem de usuários foi estabelecido para 57 usuários.<ref name="stenberg"/>
 
Em maio de 1993, a RFC 1459<ref name="rfc 1459 1 introduction"/> foi publicada e detalhou um protocolo simples para operações de clientes, servidores, canais, conversas um para um e um para muitos.<ref name="stenberg"/> É notável que um número significativo de extensões como o ''CTCP'', as cores, os formatos e a codificação de caracteres<ref name="rfc 1459 2.2 character codes"/> não estavam incluídas nas especificações do protocolo e isso levou várias implementações de servidores e clientes à divergências. Na verdade, a implementação do {{lang|en|''software''}} variava significativamente de uma rede para outra e cada uma delas implementava suas próprias políticas e seus próprios padrões em suas próprias bases de código.
 
=== Bifurcação ''DALnet'' ===
 
Durante o verão de 1994 a ''Undernet'' foi bifurcada e a nova rede, formada para melhor serviço de usuário e mais proteções de usuários e canais, foi chamada de ''[[DALnet]]''. Uma das alterações mais significativas nessa nova rede, foi o uso de apelidos mais longos (o limite original do ''ircd'' sendo 9 letras). As modificações no ''ircd'' foram feitas por Alexei "Lefler" Kosut e a ''DALnet'' foi, portanto, baseada no servidor ''ircd'' da ''Undernet'' (embora os pioneiros da ''DALnet'' fossem pessoas que deixaram a ''EFnet''). De acordo com James Ng, os pioneiros da ''DALnet'' foram "''ops'' do canal #''startrek'' que estavam cansados de constantes divisões ({{lang|en|''split''}}''s''), colisões, atrasos ({{lang|en|''lag''}}''s''), aquisições ({{lang|en|''takeover''}}''s'') e etc".<ref name="stenberg"/>
 
A ''DALnet'' prontamente ofereceu:
 
* ''WallOps'' globais - mensagens de ''IRCops'' que podem ser vistas por usuários que são ''+w'',
* apelidos mais longos,
* apelidos "''alinhados com Q''" - apelidos que não podem ser usados (como ''ChanServ'', ''IRCop'' e ''NickServ'', por exemplo),
* "''linhas K''" globais - para banir uma pessoa ou um domínio inteiro de um servidor ou de toda a rede e
* comunicações somente de ''IRCops'':
** ''GlobOps'',
** modo +H mostrando que um ''IRCop'' é um "''helpop''" e etc.
Muitas das novas funções da ''DALnet'' foram escritas por Brian "Morpher" Smith, no início de 1995, e permitem que os usuários possuam apelidos, controlem canais, enviem memorandos e mais.<ref name="stenberg"/>
 
=== Bifurcação ''IRCnet'' ===
 
Em julho de 1996, após meses de [[Flaming#Flame war|guerras inflamadas]] e discussões em listas de {{lang|en|''e-mail''}}''s'', houve outra divisão devido ao desacordo sobre como deveria evoluir o desenvolvimento do ''ircd''. Mais notavelmente, o lado "europeu" (a maioria desses servidores estavam na Europa) que mais tarde se autodenominou ''[[IRCnet]]'' argumentou sobre atrasos de {{lang|en|''nick''}} e canal, enquanto o lado ''EFnet'' argumentou sobre os {{lang|en|''timestamp''}}''s''.<ref name="stenberg"/> Também haviam desacordos sobre as políticas: o lado europeu havia começado a estabelecer um conjunto de regras que direcionavam o que os ''IRCops'' podiam e não podiam fazer e o lado americano se opôs à tal ponto de vista.<ref>
{{citar web
|url=http://www.irc.org/history_docs/TheGreatSplit.html
|título=A grande divisão
|língua=en
|publicado=irc.org
|último =Engen
|primeiro =Vegard
|data=maio de 2000
|acessodata=22-07-2021}}
</ref>


=== Expansão ===
A maioria (não todos) dos servidores ''IRCnet'' estavam na Europa e a maioria dos servidores ''EFnet'' estavam nos Estados Unidos da América. Este evento também é conhecido como "a grande divisão" em muitas sociedades ''IRC''. A ''EFnet'', desde então (em agosto de 1998), cresceu e ultrapassou o número de usuários que tinha na época. No outono (do norte) de 2000, a ''EFnet'' tinha cerca de 50.000 e a ''IRCnet'' tinha cerca de 70.000.<ref name="stenberg"/>
Com a abertura comercial da Internet ao grande público em [[1993]], ao longo dos [[anos 1990]] grandes redes de IRC começaram a surgir como [[EFnet]] e [[Undernet]] possibilitando que qualquer pessoa assinante de um [[provedor de acesso]] pudesse se conectar a essas redes. Muitas das novas redes que surgiam eram separações de grupos de usuários que não concordavam com regras dos servidores. Foi assim que em [[1995]] as primeiras redes de IRC no [[Brasil]] nasceram sendo fundadas por usuários brasileiros que já se conectavam às redes estrangeiras.


=== Popularidade ===
=== ''IRC'' moderno ===
O IRC se tornou o principal meio de bate-papo na Internet no final dos anos 1990 e início dos [[anos 2000]], concentrando milhares de usuários todos os dias. Tentaram recriar o mesmo sistema na [[Web]] e em [[Java]], mas o IRC era insuperável pela capacidade de gerenciamento e o modo como os usuários interagiam. Por exemplo, os OPs (Operadores) cuidavam do bom andamento do canal expulsando usuários mal educados e que provacassem confusão.


O [[mIRC]], cliente de IRC para [[Windows]] foi com certeza o mais popular e largamente utilizado, era fácil de usar e apresentava uma interface clara e agradável aos olhos dos iniciantes. Também possuia uma linguagem de [[script]]s que permitiu que muitos programadores criassem variações do mIRC traduzidas para o português e com muitos recursos que facilitavam o seu uso. Surgiram também muitos [[jogos]] em canais, de [[enquete]]s e até [[Xadrez por computador]] foi portado para o sistema que lidava apenas com texto ditando as notações do tabuleiro. O ápice do IRC no Brasil foi em 2001 onde ambas [[BrasIRC]] e [[BrasNET]] registraram recordes de usuários conectados.
O ''IRC'' mudou muito ao longo de sua vida na {{lang|en|''Internet''}}. O novo {{lang|en|''software''}} de servidor adicionou uma infinidade de novos recursos.
* <!-- [[:en:IRC services]] -->Serviços: {{lang|en|''bot''}}''s'' operados em rede para facilitar o registro de apelidos e canais, envio de mensagens para usuários {{lang|en|''offline''}} e funções de operador de rede.
* Modos extras: Enquanto o sistema ''IRC'' original usava um conjunto de modos de usuário e canal padrão, novos servidores adicionam muitos novos modos para recursos como a remoção de códigos de cores do texto,<ref>
{{citar web
|título=Modos de canal
|língua=en
|url=https://www.unrealircd.org/docs/Channel_modes
|website=Wiki de documentação UnrealIRCd
|acessodata=23-07-2021}}
</ref> ou obscurecimento da máscara de {{lang|en|''host''}} de um usuário ("camuflagem") para proteção contra [[Ataque de negação de serviço|ataques de negação de serviço]].<ref>
{{citar web
|título=Camuflagem
|língua=en
|url=https://www.unrealircd.org/docs/Cloaking
|website=Wiki de documentação UnrealIRCd
|acessodata=23-07-2021}}
</ref>
* Detecção de {{lang|en|''proxy''}}: a maioria dos servidores modernos oferece suporte à detecção de usuários que tentam se conectar por meio de um [[Proxy|servidor {{lang|en|''proxy''}}]] inseguro (mal configurado ou explorado), que pode ter a conexão negada. Este {{lang|en|''software''}} de detecção de {{lang|en|''proxy''}} é usado por várias redes, embora a lista de {{lang|en|''proxies''}} em tempo real esteja extinta desde o início de 2006.<ref>
{{citar web
|url=https://github.com/blitzed-org/bopm
|título=Monitor aberto de ''proxy'' ''Blitzed''
|língua=en
|citação=O monitor aberto de ''proxy'' fornecido pela rede ''IRC'' ''Blitzed'' foi desligado... O banco de dados era tão grande que é quase impossível para a equipe fazer ''backup'' ou encontrar um novo local para continuar o serviço. Somado a isso, a maioria dos membros da equipe não tem mais tempo para manter o serviço funcionando.}}
</ref>
* Comandos adicionais: novos comandos podem ser coisas como comandos abreviados para emitir comandos para serviços. Para comandos de operador de rede manipular a máscara de {{lang|en|''host''}} de um usuário.
* [[Encriptação]]: para o trecho cliente-servidor da conexão, o [[Transport Layer Security|''TLS'']] pode ser usado (as mensagens deixam de ser seguras quando são retransmitidas para outros usuários em conexões padrão, mas dificulta a [[Ataque man-in-the-middle|espionagem]] ou a "escuta" de sessões ''IRC'' de um indivíduo). Para a comunicação cliente a cliente, o [[Direct Client-to-Client|cliente a cliente direto]] seguro (''SDCC'') pode ser usado.
* Protocolo de conexão: é possível conectar-se ao ''IRC'' via [[IPv4|''IP''v4'']], a versão antiga do [[Protocolo de Internet|protocolo de {{lang|en|''Internet''}}]], ou via [[IPv6|''IP''v6]], o padrão atual do protocolo.


=== Decadência ===
* Desde 2016, um novo esforço de padronização está em andamento em um grupo de trabalho chamado ''IRC''v3 (que se concentra em recursos mais avançados de cliente, como notificações instantâneas, melhor suporte de histórico e segurança aprimorada).<ref name="ircv3">
[[Ficheiro:Xaric screen shot.jpg|thumb|250px|Xaric, um console baseado no IRC. São mostrados dois canais de IRC e uma conversa privada com o autor do software.]]
{{citar web
A decadência do IRC começou por volta de [[2003]] quando os [[Mensageiro instantâneo|mensageiros instantâneos]] se tornavam ainda mais populares, permitindo bate-papo com amigos sem ser importunado por desconhecidos e uma série de recursos que o IRC não permitia. Primeiramente o [[ICQ]] chamou a atenção dos usuários, pela praticidade e simplicidade na comunicação direta entre estes. Posteriormente o [[MSN|MSN Messenger]] foi ganhando espaço pois permitia conversas em vídeo por [[webcam]]s e [[voz]], além de integração com e-mail do [[Hotmail]], jogos do portal MSN e salas de chat comunitárias que eram tão eficientes como o IRC em controle de usuários. Apesar de o bate-papo comunitário nos mensageiros não ter prosperado, eles permitiam conexões com sites de [[namoro]] aumentando a eficiência em conhecer gente nova como acontecia no IRC.
|título=''IRC''v3
|língua=en
|url=http://ircv3.net/
|publicado=Grupo de trabalho ''IRC''v3
|acessodata=24-07-2021
|ano=2016
|citação=O grupo de trabalho ''IRC''v3 é uma coleção de autores de ''software'' cliente e servidor de ''IRC'' trabalhando para aprimorar, manter e padronizar o protocolo ''IRC'' usando extensões compatíveis com versões anteriores.}}
</ref> Em 2019, nenhuma grande rede ''IRC'' havia adotado totalmente o padrão proposto.<ref name="ircv3usage">
{{citar web
|título=Redes - ''IRC''v3
|língua=en
|url=https://ircv3.net/support/networks.html
|acessodata=24-07-2021
|ano=2019}}
</ref>


O lançamento da rede social [[Orkut]] foi o golpe final para as redes de IRC brasileiras. Os usuários do Orkut se reúnem em comunidades que possuem [[forum|fóruns]] e neles organizam sistemas de [[chat]] nos tópicos. Com o auxílio do MSN, o Orkut sepultou de vez o IRC no Brasil e desde 2004 é restrito a encontro de [[nostalgia|saudosistas]] e [[subcultura]]s.
Após sua era de ouro durante a década de 1990 e início de 2000 (240.000 usuários na ''QuakeNet'' em 2004), o ''IRC'' teve um declínio significativo. Perdeu cerca de 60% dos usuários entre 2003 e 2012, os usuários mudaram para plataformas de [[Mídias sociais|mídia social]] mais recentes (como o ''[[Facebook]]'' ou o ''[[Twitter]]'') e também abriram plataformas como o [[Extensible Messaging and Presence Protocol|''XMPP'']] (desenvolvido em 1999). Certas redes, como a ''[[Freenode]]'', não seguiram a tendência geral e mais do que quadruplicaram de tamanho durante o mesmo período. No entanto, a ''Freenode'' (que em 2016 tinha cerca de 90.000 usuários) desde então diminuiu para cerca de 65.000 usuários.<ref>
{{citar web
|título=netsplit.de - Top 10
|língua=en
|url=http://irc.netsplit.de/networks/top10.php
|acessodata=24-07-2021}}
</ref>


No exterior, o IRC teve uma queda mais branda: apesar de perder muitos usuários, ainda mantinha uma boa taxa de conexões. O sistema de [[forum|fóruns]] baseados em [[PHP]] foi também um dos grandes responsáveis pela queda do IRC por lá. Os usuários passaram a se organizar nesses fóruns e mantinham conversas em tempo real no MSN.
As maiores redes de ''IRC'' têm sido tradicionalmente agrupadas como as "quatro grandes ({{lang|en|''big four''}})",<ref name="the book of irc">
{{citar livro
|último =Charalabidis
|primeiro =Alex
|título=O livro do IRC: o guia definitivo para o Internet relay chat <!-- |url-access=registration -->
|edição=1ª
|data=15-12-1999
|publicado=<!-- [[:en:No Starch Press]] -->no starch press
|local=[[São Francisco (Califórnia)|São Francisco]], [[Califórnia]]
|isbn=978-1-886411-29-6
|página=[https://archive.org/details/bookofirc00char/page/61 61]
|capítulo=''IRCing'' no ''Macintosh'': ''Ircle''
|citação=Em grandes redes como as quatro grandes (''EFnet'', ''IRCnet'', ''Undernet'' e ''DALnet'') tentar listar os milhares de canais com o ''Ircle'' sempre faz com que você se desconecte devido à enxurrada de informações. Enquanto que com outros clientes é possível gerenciar o feito se estiver em uma conexão ''ethernet'' direta.
|url=https://archive.org/details/bookofirc00char}}
</ref><ref name="encyclopedia of new media">
{{citar livro
|editor-sobrenome =Jones
|editor-nome =Steve
|título=Enciclopédia de novas mídias: uma referência essencial para comunicação e tecnologia
|língua=en
|url=https://archive.org/details/encyclopediaofne00jone
<!-- |url-access=registration -->
|edição=1ª
|data=10-12-2002
|publicado=<!-- [[:en:SAGE Publishing]] -->Publicações SAGE
|local=[[Thousand Oaks]], [[Califórnia]]
|isbn=978-0-7619-2382-4
|página=[https://archive.org/details/encyclopediaofne00jone/page/257 257]
|capítulo=Internet relay chat
|citação=Hoje existem centenas de redes ''IRC'' independentes, mas as "quatro grandes" são ''EFNet'', ''UnderNet'', ''DALnet'' e ''IRCnet''.}}
</ref><ref name="the imac book">{{citar livro
|último =Rittner
|primeiro =Don
|título=O livro do iMac
|língua=en
|edição=1ª
|data=03-03-1999
|publicado=Grupo Coriolis
|local=[[Scottsdale]], [[Arizona]]
|isbn=978-1-57610-429-3
|página=215
|citação=Existem várias redes grandes: ''EFnet'', ''UnderNET'', ''DALnet'' e ''IRCnet'' constituem as quatro grandes.}}
</ref><ref name="information technology for management">
{{citar livro
|último1 =Turban
|primeiro1 =Efraim
|último2 =Leidner
|primeiro2 =Dorothy
|último3 =McLean
|primeiro3 =Ephraim
|último4 =Wetherbe
|primeiro4 =James
|título=Tecnologia da informação para gestão: transformando as organizações na economia digital
|língua=en
|edição=5ª
|data=07-02-2005
|publicado=[[John Wiley & Sons]]
|local=[[Hoboken (Nova Jérsei)]], [[Nova Jérsia|Nova Jérsei]]
|isbn=978-0-471-70522-2
|páginas=106 e 107
|capítulo=Comunicação
|citação=As maiores redes têm sido tradicionalmente agrupadas como as "quatro grandes": ''EFNet'', ''IrcNet'', ''QuakeNet'' e ''UnderNet''.}}
</ref> uma designação para redes que encabeçam as estatísticas. As quatro grandes redes mudam periodicamente, mas devido à natureza comunitária do ''IRC'', há um grande número de outras redes para os usuários escolherem.


=== Tempos atuais ===
Historicamente, as "quatro grandes" eram:<ref name="the book of irc"/><ref name="encyclopedia of new media"/><ref name="the imac book"/>
[[Ficheiro:CyberScript.jpg|thumb|250px|Cyber Script, um dos scripts mais usados no momento.]]
* ''[[EFnet]]''
O IRC ainda existe, com milhares de redes ativas para quem queira usufruir de seus recursos. O número de freqüentadores, porém, é deveras baixo para bate-papo. O IRC hoje é usado para fins mais específicos. Existem canais que realizam [[troca de arquivos]] entre usuários semelhantes aos que os [[peer to peer]] fazem. Além disso o IRC é bastante utilizado por distribuições [[linux]] que utilizam o IRC para dar suporte aos usuarios, como a [[Ubuntu (distribuição de Linux)|Ubuntu]].
* ''[[IRCnet]]''
* ''[[Undernet]]''
* ''[[DALnet]]''
O ''IRC'' atingiu 6 milhões de usuários simultâneos em 2001, 10 milhões de usuários em 2003 e caiu para 371 mil em 2018.{{carece de fontes|date=01-2015}}


Top 10 das redes com maior volume de usuários: <ref name=":0" />
Em outubro de 2018, as maiores redes de IRC são:
# IRCNet
* ''[[freenode]]'' - cerca de 90 mil usuários nos horários de pico,
# QuakeNet
* ''[[IRCnet]]'' - cerca de 30 mil usuários nas horas de pico,
# EFnet
* ''[[EFnet]]'' - cerca de 18 mil usuários em horários de pico,
# Rizon
* ''[[Undernet]]'' - cerca de 17 mil usuários nos horários de pico,
# Undernet
* ''[[QuakeNet]]'' - cerca de 15 mil usuários em horários de pico,
# ChLame
* <!-- [[:en:Rizon]] -->''Rizon'' - cerca de 14 mil usuários nos horários de pico,
# IRC-Hispano
* <!-- [[:en:Open and Free Technology Community]] -->''OFTC'' - cerca de 13 mil usuários nos horários de pico e
# OFTC
* ''[[DALnet]]'' - cerca de 8 mil usuários nos horários de pico.
# Ustream
Hoje, as 100 principais redes ''IRC'' têm cerca de aproximadamente 370 mil usuários conectados nos horários de pico.<ref name="netsplitde-top100">
# DALnet
{{citar web
|url=http://irc.netsplit.de/networks/top100.php
|título=Redes ''IRC'' - ''Top'' 100
|website=irc.netsplit.de |publicado=netsplit.de
|acessodata=25-07-2021}}
</ref> <!-- Não confirmado. A freenode e etc. ausentes na referência. -->


O IRC é também, atualmente, um meio usado para execução de [[Botnet]]s em que se conectam usuários infectados por [[virus]] e [[trojans]]. Esses usuários hospedeiros ignoram tais conexões para servidores e canais, e, a partir de lá, lançam ataques de [[SPAM]] a milhares de computadores pelo mundo. Isso permite que o hacker propagador, nesse caso, permaneça anônimo e use pessoas infectadas para fazer ataques usando seus respectivos [[IP]]s. O sistema deve ser bem estruturado para que não se perca o controle do usuário-hospedeiro e que seja de difícil reconhecimento por parte dos provedores, já que utilizam portas e protocolos de IRC, sendo assim muitos provedores estão bloqueando o acesso IRC. Mas caso o usuário tenha um bom anti-vírus não teremos esse problema.
=== Linha do tempo ===
Linha do tempo dos principais servidores:


=== Reascensão ===
* ''[[EFnet]]'' - de 1990 até o presente,
Em dias atuais por meio de uma plataforma chamada, web IRC, dentre as quais podemos destacar serviços como: [[LightIRC]]; KiwiIRC; Mibbit, que permite que usuários adentrem ao sistema IRC por meio de acesso à web, que pode ser incorporada a sites via Iframe, o que vem aumentando gradativamente usuários no IRC. Redes brasileiras como a [[ChatBrasil]], sVipCHAT, vIRCio, VirtuaLife, entre outras, tem feito uso dessa plataforma fornecendo webchat para diversos sites, entre eles sites de Música Sertaneja e outros. Exemplo são algumas rádios web, que chegam a ter picos elevados de pessoas participando destes Chats, usando o protocolo IRC. Muito sites usam essa plataforma, web IRC,  oferecendo um chat semelhante aos conhecidos como: Terra; UOL, dividido por: temas; estados; cidades, idades; classes; gêneros musicais, etc.,  tendo como exemplo as redes: [[ChatBrasil]]; [[sVipCHAT]]; ZetBoo; vIRCio, entre muitas outras. Podem existir redes de IRC com fusão entre países, como é o caso do Brasil com Portugal, rede BrasPort.
* ''[[Undernet]]'' - de 1992 até o presente,
* ''[[DALnet]]'' - de 1994 até o presente,
* ''[[freenode]]'' - 1995 até o presente,
* ''[[IRCnet]]'' - de 1996 até o presente,
* ''[[QuakeNet]]'' - de 1997 até o presente
* <!-- [[:en:Open and Free Technology Community]] -->Comunidade de tecnologia aberta e livre - de 2001 até o presente,
* <!-- [[:en:Rizon]] -->''Rizon'' - de 2002 até o presente e
* ''[[Libera Chat]]'' - de 2021 até o presente.


== Informação técnica ==
== Informação técnica ==
O IRC é um [[protocolo]] aberto que usa o [[TCP]] e opcionalmente [[SSL]]. Um servidor de IRC pode ser ligado a outros servidores de forma a expandir a rede de IRC. Para que os utilizadores tenham acesso às redes de IRC é necessário ligar a um dos servidores utilizando um cliente apropriado. Existem muitas implementações do IRC em clientes e servidores sendo que a maioria dos servidores de IRC não requerem que o utilizador se identifique, no entanto o utilizador terá de escolher um apelido antes de efectuar a ligação.


O IRC é um protocolo de texto simples, o que quer dizer que é possível (embora algo inconveniente) usar o IRC através de um cliente como o [[netcat]] ou o [[telnet]].  
<!-- Commented out: [[Imagem:MIRC 6.31 Screenshot.png|direita|thumb|Uma captura de tela do [[mIRC]], um cliente IRC para versões do [[Microsoft Windows|Windows]].]] -->
Embora o protocolo use uma versão ligeiramente alterada do [[ASCII]] como codificação de caracteres, não tem suporte para quaisquer caracteres não ASCII sendo que isso leva ao uso de outros tipos de codificação de caracteres incompatíveis (como o [[ISO 8859-1]] e [[UTF-8]]).
 
[[Imagem:Hexchat 2.16.0 screenshot.png|direita|thumb|Uma captura de tela do [[HexChat]], um cliente IRC para ambientes [[GTK]].]]
 
[[Imagem:Xaric screen shot.jpg|direita|thumb|Xaric, um cliente IRC baseado em texto, em uso no [[Mac OS X]]. São mostrados dois canais de IRC e uma conversa privada com o autor do software.]]
 
O IRC é um [[Protocolo de rede|protocolo]] aberto que usa [[Transmission control protocol|TCP]]<ref name="tools.ietf.org">{{citar web |último=Oikarinen |primeiro=J. |último2=Reed |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-1 |título=IRC protocol - Introduction (section 1) |data=maio de 1993 |acessodata=05-04-2021 |publicado=IETF |página=4 |língua=en |títulotrad=Protocolo IRC - Introdução  (seção 1) |doi=10.17487/RFC1459 |rfc=1459}}</ref> e, opcionalmente, [[Transport Layer Security|TLS]]. Um [[IRCd|servidor IRC]] pode se conectar a outros servidores IRC para expandir a rede IRC.<ref>{{citar web |último=Oikarinen |primeiro=J. |último2=Reed |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-1.1 |título=IRC protocol - Server (section 1.1) |data=maio de 1993 |acessodata=05-04-2021 |publicado=IETF |página=4 |língua=en |títulotrad=Protocolo IRC - Servidores (seção 1.1) |doi=10.17487/RFC1459 |rfc=1459}}</ref> Os usuários acessam redes IRC conectando um cliente a um servidor.<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2810#section-2.2 |título=IRC: Architecture - Clients (section 2.2) |data=abril de 2000 |acessodata=05-04-2021 |publicado=IETF |página=3 |língua=en |títulotrad=Arquitetura IRC - Clientes (seção 2.2) |doi=10.17487/RFC2810 |rfc=2810}}</ref> Existem muitas implementações de cliente (como [[mIRC]], [[HexChat]] e [[irssi]]) e implementações de servidor (por exemplo, o [[IRCd]] original). A maioria dos servidores IRC não exige que os usuários registrem uma conta, mas um [[Nickname#Computing|apelido]] é necessário antes de se conectar.<ref>{{citar web |último=Oikarinen |primeiro=J. |último2=Reed |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-1.2 |titulo=IRC protocol - Clients (section 1.2) |data=maio de 2021 |acessodata=05-04-2021 |publicado=IETF |pagina=5 |língua=en |títulotrad=Protocolo IRC - Clientes (seção 1.2) |doi=10.17487/RFC1459 |rfc=1459}}</ref>
 
O IRC era originalmente um [[Protocolo baseado em texto|protocolo de texto simples]]<ref name="tools.ietf.org"/> (embora posteriormente estendido) que, a pedido, foi atribuído a porta [[Lista de portas dos protocolos TCP e UDP|TCP 194]] pela [[Internet Assigned Numbers Authority|IANA]].<ref>{{citar web |url=https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=5 |título=Port numbers |data=06-04-2011 |acessodata=05-04-2021 |publicado=[[Internet Assigned Numbers Authority]] |local=[[Marina del Rey|Marina del Rey, California]] |língua=en |títulotrad=Números de porta }}</ref> No entanto, o ''[[padrão de fato]]'' sempre foi executar o IRC em TCP 6667<ref>{{citar web |último=Oikarinen |primeiro=J. |último2=Reed |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-4.3.5 |título=IRC protocol - Connect message (section 4.3.5) |data=maio de 1993 |acessodata=05-04-2021 |publicado=IETF |página=29 |língua=en |títulotrad=Protocolo IRC -  Mensagem de conexão (seção 4.3.5) |doi=10.17487/RFC1459 |rfc=1459}}</ref> e números de porta próximos (por exemplo, portas TCP 6660-6669 e 7000)<ref>{{citar livro|título=Firewall policies and VPN configurations|primeiro1=Mark|primeiro2=Abhishek|primeiro3=Chris|data=5 de outubro de 2006|publicado=Syngress Publishing|editor-sobrenome=Henmi|editor-nome=Anne|local=[[Rockland (Massachusetts)|Rockland]], [[Massachusetts]]|página=93|língua=en|títulotrad=Políticas de firewall e configurações de VPN|isbn=978-1-59749-088-7|último3=Cantrell|último2=Singh|capítulo=Defining a firewall - Definindo um firewall|último1=Lucas}}</ref> para evitar ter que executar o software [[IRCd]] com [[Superusuário|privilégios de root]].
 
O protocolo especificava que os caracteres eram de 8 bits, mas não especificava a codificação de caracteres que o texto deveria usar.<ref name="rfc 1459 2.2 character codes">
{{citar web
|autor1 =Jarkko Oikarinen
|autor2 =Darren Reed
|url=https://datatracker.ietf.org/doc/html/rfc1459#section-2.2
|título=Protocolo ''IRC'' - Códigos de caracteres (seção 2.2)
|página=7
|doi=10.17487/RFC1459
|língua=en
|rfc=1459
|data=maio de 1993
|acessodata=25-07-2021}}
</ref> Isso pode causar problemas quando os usuários que usam clientes e (ou) plataformas diferentes desejam conversar.
 
Todos os protocolos IRC (cliente pra servidor) em uso hoje descendem do protocolo implementado na versão irc 2.4.0 do servidor IRC2 e documentado na RFC 1459. Desde a publicação da RFC 1459, os novos recursos na implementação do irc 2.10 levaram à publicação de vários documentos de protocolo revisados (RFC 2810, RFC 2811, RFC 2812 e RFC 2813). No entanto, essas alterações de protocolo não foram amplamente adotadas entre outras implementações.
 
Embora muitas especificações sobre o protocolo IRC tenham sido publicadas, não há uma especificação oficial, pois o protocolo permanece dinâmico. Praticamente nenhum cliente e muito poucos servidores confiam estritamente nas RFCs acima como referência.
 
A Microsoft fez uma extensão para o IRC em 1998 através do proprietário [[IRCX]].<ref>{{citar web |último=Abraham |primeiro=Dalen |url=https://tools.ietf.org/html/draft-pfenning-irc-extensions-04 |título=Extensions to the IRC protocol |data=junho de 1998 |acessodata=06-04-2021 |publicado=IETF |língua=en |títulotrad=Extensões para o protocolo IRC}}</ref> Posteriormente, eles pararam de distribuir software que suportasse o IRCX e desenvolveram o proprietário [[Protocolo de notificação Microsoft|MSNP]].
 
A estrutura padrão de uma rede de servidores IRC é uma [[Rede em árvore|árvore]].<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2810#section-3 |título=IRC: Architecture (section 3) |data=abril de 2000 |acessodata=06-04-2021 |publicado=IETF |páginas=3 e 4 |língua=en |títulotrad=IRC : Arquitetura (seção 3) |doi=10.17487/RFC2810 |rfc=2810}}</ref> As mensagens são encaminhadas apenas para os ramos necessários da árvore, mas o estado da rede é enviado para cada servidor<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2810#section-1 |título=IRC: Architecture - Introduction (section 1) |data=abril de 2000 |acessodata=06-04-2021 |publicado=IETF |página=2 |língua=en |títulotrad=IRC : Arquitetura - Introdução (seção 1) |doi=10.17487/RFC2810 |rfc=2810}}</ref> e geralmente há um alto grau de confiança implícita entre os servidores.  Essa arquitetura tem, no entanto, vários problemas. Um servidor mal-intencionado ou com comportamento inadequado pode causar grandes danos à rede<ref>{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-1 |título=IRC protocol - Algorithms (section 9.3) |data=maio de 1993 |acessodata=06-04-2021 |publicado=IETF |página=64 |língua=en |títulotrad=Protocolo IRC - Algoritmos (seção 9.3) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref> e quaisquer mudanças na estrutura, sejam intencionais ou resultado de condições na rede subjacente, requerem uma divisão de rede e junção de rede. Isso resulta em muito tráfego de rede, falsas mensagens (de entrada saída) para os usuários<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2810#section-6.3 |título=IRC: Architecture - Network congestion (section 6.3) |data=abril de 2000 |acessodata=06-04-2021 |publicado=IETF |páginas=7 e 8 |língua=en |títulotrad=IRC : Arquitetura - Congestionamento de rede (seção 6.3) |doi=10.17487/RFC2810 |rfc=2810}}</ref> e perda temporária de comunicação com os usuários nos servidores de divisão. Adicionar um servidor a uma grande rede significa uma grande carga de largura de banda em segundo plano na rede e uma grande carga de memória no servidor. Uma vez estabelecida, no entanto, cada mensagem para vários destinatários é entregue de maneira semelhante a [[multicast]], o que significa que cada mensagem viaja por um link de rede exatamente uma vez.<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2810#section-5.2.1 |título=IRC: Architecture - To a channel (section 5.2.1) |data=abril de 2000 |acessodata=06-04-2021 |publicado=IETF |páginas=5 e 6 |língua=en |títulotrad=IRC : Arquitetura - Pra um canal (seção 5.2.1) |doi=10.17487/RFC2810 |rfc=2810}}</ref> Isso é um ponto forte em comparação aos protocolos 'não multicast', como o [[Simple Mail Transfer Protocol]] (SMTP) ou o [[Extensible Messaging and Presence Protocol]] (XMPP).
 
Um daemon IRC também pode ser usado em uma rede local (LAN). O IRC pode, portanto, ser usado para facilitar a comunicação entre as pessoas dentro da rede local (comunicação interna).<ref>{{Citar web|url=http://computerquestionhelp.com/content/how-guide-setup-your-own-irc-server-using-personal-or-dedicated-system-or-server-top-freewar|título=IRC daemons for LAN|publicado=|acessodata=2 de outubro de 2014}}</ref><ref>{{Citar web|url=http://www.irc-wiki.org/IRC_server|título=Running an own IRC server|publicado=|acessodata=2 de outubro de 2014}}</ref>
 
=== Comandos e respostas ===
 
{{Artigo principal|Lista de comandos IRC}}
 
O IRC tem uma estrutura baseada em linha. Os clientes enviam mensagens de linha única para o servidor<ref>{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-2.3.1 |título=IRC protocol - Message format in 'pseudo' BNF (section 2.3.1) |data=maio de 1993 |acessodata=06-04-2021 |publicado=IETF |página=8 |língua=en |títulotrad=Protocolo IRC - Formato de mensagem em 'pseudo' BNF (seção 2.3.1) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref> recebem respostas para essas mensagens<ref>{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-2.4 |título=IRC protocol - Numeric replies (section 2.4) |data=maio de 1993 |acessodata=06-04-2021 |publicado=IETF |página=10 |língua=en |títulotrad=Protocolo IRC - Respostas numéricas (seção 2.4) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref> e cópias de algumas mensagens enviadas por outros clientes. Na maioria dos clientes, os usuários podem inserir comandos prefixando-os com '/'. Dependendo do comando, eles podem ser manipulados inteiramente pelo cliente ou, geralmente para comandos que o cliente não reconhece, passados diretamente para o servidor (possivelmente com alguma modificação).
 
Devido à natureza do protocolo, os sistemas automatizados nem sempre emparelham corretamente um comando enviado com sua resposta com total confiabilidade e estão sujeitos a adivinhação.<ref>{{Citar web |último=Cormack |primeiro=Shane Mc |url=https://blog.dataforce.org.uk/irc-musings/#listmode |título=IRC list modes – List mode extension showing pair confusion for lists |data= |acessodata=15-04-2021 |publicado=Dataforce's blog |língua=en |títulotrad=Modos de lista de IRC - extensão do modo de lista mostrando confusão de pares para listas}}</ref>
 
=== Canal ===
 
O meio básico de comunicação com um grupo de usuários em uma sessão de IRC estabelecida é através de um ''[[chat room|canal]]''.<ref name="rfc 1459 3.2.2 to a group (channel)">{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-3.2.2 |título=IRC Protocol - To a group (channel) (section 3.2.2) |data=maio de 1993 |acessodata=15-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=11 |língua=en |títulotrad=Protocolo IRC - Para um grupo (canal) (seção 3.2.2) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref> Canais em uma rede podem ser exibidos usando o comando ''LIST'',<ref>{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-4.2.6 |título=IRC Protocol - List message (section 4.2.6) |data=maio de 1993 |acessodata=15-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=24 |língua=en |títulotrad=Protocolo IRC - Mensagem de lista (seção 4.2.6) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref> que lista todos os canais atualmente disponíveis que não têm os modos +s ou +p definidos nessa rede específica.
 
Os usuários podem ''ingressar'' em um canal usando o comando ''JOIN'',<ref name="rfc 1459 4.2.1 join message">{{citar web |último=Oikarinen |primeiro=J. |último2=Reed |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-4.2.1 |titulo=IRC Protocol - Join message (section 4.2.1) |data=maio de 1993 |acessodata=16-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |língua=en |títulotrad=Protocolo IRC - Mensagem de adesão (seção 4.2.1) |doi=10.17487/RFC1459 |rfc=1459}}</ref> disponível na maioria dos clientes como ''/join'' #nome do canal. As mensagens enviadas aos canais associados são, então, retransmitidas à  todos os outros usuários.<ref name="rfc 1459 3.2.2 to a group (channel)" />
 
Os canais que estão disponíveis em uma rede ''IRC'' inteira são prefixados com um '#', enquanto aqueles locais para um servidor usam '&'.<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2811#section-2.2 |título=IRC: Channel management - Channel scope (section 2.2) |data=abril de 2000 |acessodata=16-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |páginas=3 e 4 |língua=en |títulotrad=IRC: Gerenciamento de canal - escopo do canal (seção 2.2) |doi=10.17487/RFC2811 |rfc=2811}}</ref> Outros tipos de canais menos comuns incluem canais '+' (canais ''modeless'', sem operadores)<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2811#section-2.3 |título=IRC: Channel management - Channel properties (section 2.3) |data=abril de 2000 |acessodata=16-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=4 |língua=en |títulotrad=IRC: Gerenciamento de canal - Propriedades do canal (seção 2.3) |doi=10.17487/RFC2811 |rfc=2811}}</ref> e canais '!' (uma forma de canal ''timestamped'' em redes normalmente sem ''timestamped''.<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2811#section-3 |título=IRC: Channel management - Channel lifetime (section 3) |data=abril de 2000 |acessodata=16-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |pagina=5 |língua=en |títulotrad=IRC: Gerenciamento de canal - Tempo de vida do canal (seção 3) |doi=10.17487/RFC2811 |rfc=2811}}</ref>
 
=== Modos ===
 
Usuários e canais podem ter "modos" que são representados por letras simples, que diferenciam maiúsculas de minúsculas<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2811#section-4 |título=IRC: Channel management - Channel modes (section 4) |data=abril de 2000 |acessodata=16-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=7 |língua=en |títulotrad=IRC: Gerenciamento de canal - Modos de canal (seção 4) |doi=10.17487/RFC2811 |rfc=2811}}</ref> e são configurados usando o comando ''MODE''.<ref>{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-4.2.3 |título=IRC Protocol - Mode message (section 4.2.3) |data=maio de 1993 |acessodata=16-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=21 |língua=en |títulotrad=Protocolo IRC - Mensagem de modo (seção 4.2.3) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref> Modos de usuário e modos de canal são separados e podem usar a mesma letra para significar coisas diferentes (por exemplo, o modo de usuário "i" é o modo invisível, enquanto o modo de canal "i" é o que define que apenas convidados podem ingressar no canal.<ref>{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-4.2.3.1 |título=IRC Protocol - Channel modes (section 4.2.3.1) |data=maio de 1993 |acessodata=16-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |páginas=21 e 22 |língua=en |títulotrad=Protocolo IRC - Modos de canal (seção 4.2.3.1) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref>) Os modos são, geralmente, configurados ou não configurados usando o comando de modo que pega um alvo (usuário ou canal), um conjunto de modos para configurar (+) ou desconfigurar (-) e quaisquer parâmetros que os modos precisem.
 
Alguns modos de canal usam parâmetros e outros modos de canal se aplicam à um usuário em um canal ou adicionam ou removem uma máscara (por exemplo, uma máscara de proibição) de uma lista associada ao canal em vez de aplicar ao canal como um todo.<ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2811#section-4.3 |título=IRC: Channel management - Channel access control (section 4.3) |data=abril de 2000 |acessodata=17-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |páginas=10 e 11 |língua=en |títulotrad=IRC: Gerenciamento de canal - Controle de acesso ao canal (seção 4.3) |doi=10.17487/RFC2811 |rfc=2811}}</ref> Os modos que se aplicam à usuários em um canal têm um símbolo associado que é usado para representar o modo nas respostas de nomes<ref name="rfc 1459 p.51 rpl_namreply">{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#page-51 |título=IRC Protocol - Command responses: 353 RPL_NAMREPLY |data=maio de 1993 |acessodata=17-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |pagina=51 |língua=en |títulotrad=Protocolo IRC - Respostas de comando: 353 RPL_NAMREPLY |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref> (enviada aos clientes na primeira entrada em um canal<ref name="rfc 1459 4.2.1 join message" /> e no uso dos comandos de nomes) e, em muitos clientes, é usado também para representá-los na lista de usuários exibida pelo cliente em um canal ou para exibir um indicador próprio para os modos de um usuário.
 
A fim de analisar corretamente as mensagens do modo de entrada e rastrear o estado do canal, o cliente deve saber qual modo é de qual tipo e, para os modos que se aplicam a um usuário em um canal, qual símbolo vai com qual letra. Nas primeiras implementações do ''IRC'', isso tinha que ser codificado no cliente. Mas agora, existe uma extensão padrão de fato para o protocolo chamado ''ISUPPORT'' que envia essas informações ao cliente no momento da conexão usando o 005 numérico.<ref>{{Citar web |url=http://www.irc.org/tech_docs/005.html |título=The 005 numeric: ISUPPORT |acessodata=10-04-2011 |último=Roeckx |primeiro=Kurt |data=14 de outubro de 2004 |publicado= irc.org}}</ref><ref>{{citar web |último=Brocklesby |primeiro=Edward |url=https://tools.ietf.org/html/draft-brocklesby-irc-isupport-03 |título=IRC RPL_ISUPPORT numeric definition (I-D draft-brocklesby-irc-isupport-03) |data=setembro de 2002 |acessodata=17-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |títulotrad=Definição numérica IRC RPL_ISUPPORT (I-D draft-brocklesby-irc-isupport-03)}}</ref>
 
uma pequena falha de design no ''IRC'' em relação aos modos que se aplicam aos usuários nos canais: a mensagem de nomes usada para estabelecer o estado inicial do canal pode enviar apenas um modo por usuário no canal<ref name="rfc 1459 p.51 rpl_namreply" /> mas vários desses modos podem ser definidos em um único usuário. Por exemplo, se um usuário mantém o status de operador (+o) e o status de voz (+v) em um canal, um novo cliente não será capaz de ver o modo com menos prioridade (ou seja, o de voz). Soluções alternativas para isso são possíveis no lado do cliente e do servidor mas nenhuma é amplamente implementada.
 
==== Modos do padrão (RFC 1459) ====
 
{| class="wikitable"
|+ Modos de usuário
|-
! Letra
! Símbolo
! Descrição
|-
| '''i'''
|
| Invisível (não pode ser visto sem um canal comum ou sem saber o nome exato).
|-
| '''s'''
|
| Recebe avisos do servidor.
|-
| '''w'''
|
| Recebe ''wallops''.<ref>{{citar web |último=Oikarinen |primeiro=J. |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-5.6 |título=IRC Protocol - Operwall message (section 5.6) |data=maio de 1993 |acessodata=17-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=41 |língua=en |títulotrad=Protocolo IRC - Mensagem ''operwall'' (seção 5.6) |doi=10.17487/RFC1459 |rfc=1459 |último2=Reed}}</ref>
|-
| '''o'''
|
| O usuário é um operador de IRC (ircop).
|}
 
{| class="wikitable"
|+ Modos de canal
|-
! Letra
! Símbolo
! Parâmetro(s)
! Descrição
|-
| '''o'''
| @
| Nome do usuário afetado
| Operador de canal (pode alterar os modos do canal e expulsar usuários do canal, entre outras coisas).
|-
| '''s'''
|
|
| Canal secreto (não mostrado na lista de canais ou ''whois'' de usuário, exceto para usuários que já estão no canal).
|-
| '''p'''
|
|
| Canal privado (listado na lista de canais como ''prv'' de acordo com <nowiki>RFC 1459</nowiki>).
|-
| '''n'''
|
|
| Os usuários não podem enviar mensagens para o canal externamente.
|-
| '''m'''
|
|
| O canal é moderado (apenas aqueles que possuem status de operador de canal ou status de voz no canal podem enviar mensagens para ele).
|-
| '''i'''
|
|
| Apenas usuários com convites podem entrar no canal.
|-
| '''t'''
|
|
| Apenas operadores de canal podem mudar o tópico do canal.
|-
| '''l'''
|
| Número limite
| Limita o número de usuários que podem estar no canal (quando cheio, nenhum novo usuário pode entrar).
|-
| '''b'''
|
| Máscara de proibição (apelido!usuário@''host'' com caracteres curinga permitidos)
| Bane máscaras de hosts do canal.
|-
| '''v''' <!-- Isso pertence aqui com os modos de canal. Não é um modo de usuário -->
| +
| Nome do usuário afetado
| Concede ''status'' de voz ao usuário no canal (veja +m acima).
|-
| '''k'''
|
| Nova chave de canal
| Define uma chave de canal de forma que somente usuários que conheçam a chave possam entrar.
|}
 
Muitos daemons e redes adicionaram modos extras ou modificaram o comportamento dos modos na lista acima.<ref>{{Citar web |url=http://www.alien.net.au/irc/usermodes.html |título=IRC user modes list |acessodata= 10-04-2011 |último=Butcher |primeiro=Simon |data=12-01-2005 |publicado=alien.net.au
}}</ref><ref>{{Citar web | url=http://www.alien.net.au/irc/chanmodes.html
|título= IRC channel modes list |acessodata= 10-04-2011 |último=Butcher |primeiro=Simon |data=12-01-2005 |publicado=alien.net.au }}</ref><ref>{{Citar web |url=http://www.alien.net.au/irc/servermodes.html |título= IRC server modes list |acessodata=10-04-2011 |último=Butcher |primeiro=Simon |data=12-01-2005 |publicado=alien.net.au }}</ref><ref>{{Citar web |url=http://webtoman.com/opera/panel/ircdmodes.html |título=IRCd modes |acessodata=10-04-2011 |último=Olsen |primeiro=Tommy |publicado=webtoman.com |arquivourl=https://web.archive.org/web/20111015190740/http://webtoman.com/opera/panel/ircdmodes.html |arquivodata=15-10-2011
}}</ref>
 
=== Operadores de canal ===
 
Um ''operador de canal'' é um [[Cliente (computação)|cliente]] em um [[canal IRC]] que gerencia o canal.
Operadores de canal de IRC podem ser facilmente vistos por um símbolo ou ícone próximo ao seu nome (varia de acordo com a implementação do cliente, normalmente um prefixo de símbolo "@", um círculo verde ou uma letra latina "+o" ou "o").
Na maioria das redes, um operador pode:
* Chutar(expulsar) um usuário.
* Banir um usuário.
* Conceder a outro usuário o status de operador ou voz do canal IRC.
* Alterar o tópico do canal IRC enquanto o modo de canal +t estiver definido.
* Alterar os bloqueios do modo de canal IRC.
 
=== Operadores IRC ===
 
Também há usuários que mantêm direitos elevados em seu servidor local ou em toda a rede, são chamados de operadores ''IRC''<ref name="rfc 1459 1.2.1 operators">{{citar web |último=Oikarinen |primeiro=J. |último2=Reed |primeiro2=D. |url=https://tools.ietf.org/html/rfc1459#section-1.2.1 |titulo=IRC Protocol - Operators (section 1.2.1) |data=maio de 1993 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=5 |língua=en |títulotrad=Protocolo IRC - Operadores (seção 1.2.1) |doi=10.17487/RFC1459 |rfc=1459}}</ref> e, às vezes, abreviados para ''IRCops'' ou ''Opers'' (não devem ser confundidos com operadores de canal). Como a implementação do ''IRCd'' varia, também variam os privilégios do operador de ''IRC'' no ''IRCd'' fornecido. A ''RFC 1459''<ref name="rfc 1459 1.2.1 operators" /> afirma que os operadores de ''IRC'' são "um mal necessário" para manter um estado limpo da rede e, como tal, precisam ser capazes de desconectar e reconectar servidores. Além disso, para evitar que usuários mal-intencionados ou mesmo programas automatizados prejudiciais entrem no ''IRC'', os operadores de ''IRC'' geralmente têm permissão para desconectar clientes e proibir completamente endereços ''IP'' ou sub-redes completas. Redes que transportam serviços geralmente permitem que seus operadores de ''IRC'' lidem com questões básicas de "propriedade" também. Outros direitos privilegiados podem incluir a anulação de proibições (ser capaz de entrar em canais que não teriam permissão para entrar se não fossem operadores), se promover a operador (sem ser operador do canal), ''auto-op'' e etc.
 
=== Máscara de ''host'' ===
 
Uma máscara de ''host'' é um identificador único de um [[Cliente (computação)|cliente]] ''IRC'' conectado à um [[servidor (computação)|servidor]] ''IRC''.<ref name="thiedeke-2003">{{citar livro|título=Virtuelle gruppen: charakteristika und problemdimensionen|último=Thiedeke|primeiro=Udo|data=23 de setembro de 2003|publicado=Springer VS|páginas=314, 337|língua=de|isbn=978-3-531-33372-4|acessodata=20-04-2021|títulotrad=Grupos virtuais: características e dimensões do problema|capítulourl=https://books.google.com/?id=aQ74THYRyYsC&lpg=PA314&pg=PA315#v=onepage&q=hostmask|edição=2|capítulo=Nicola Döring, Alexander Schestag}}</ref><ref name="rogers-2005">{{citar livro|título=Hackeando uma rede terrorista: a ameaça silenciosa de canais secretos|último=Rogers|primeiro=Russ|data=13-01-2004|publicado=Syngress Publishing|editor-sobrenome=Devost|editor-nome=Matthew G.|local=[[Rockland (Massachusetts)|Rockland]], [[Massachusetts]]|página=10|isbn=978-1-928994-98-5|acessodata=20-04-2021|capítulourl=https://books.google.com/books?id=e3ggsGgTzUgC&lpg=PA10&pg=PA10#v=onepage&q=Hostmask%20IRC|edição=1|capítulo=The mind of terror}}</ref> [[IRCd|Servidores]], [[Serviços de Internet Relay Chat|serviços]] e outros clientes (incluindo [[Robô de IRC|''bots'']]) ''IRC'' podem usá-la para identificar uma sessão de ''IRC'' específica.
 
O formato de uma máscara de ''host'' é <code>apelido!usuário@''host''</code>. A máscara de ''host'' é semelhante, mas não deve ser confundida com, um [[Endereço de e-mail|endereço de ''e-mail'']].
 
A parte do apelido é o apelido escolhido pelo usuário e pode ser alterado durante a conexão.
A parte do usuário é o nome de usuário relatado pelo [[ident protocol|protocolo ''ident'']] no cliente.<ref name="petersen-2002">{{citar livro |editor-sobrenome=Petersen |editor-nome=Julie K. |título=The telecommunications illustrated dictionary |títulotrad=O dicionário ilustrado de telecomunicações |capítulourl=https://books.google.com/books?id=b2mMzS0hCkAC&lpg=PA500&pg=PA500#v=onepage&q=Hostmask |acessodata=20-04-2021 |edição=2 |data=29-05-2002 |publicado=[[CRC Press]] |isbn=978-0-8493-1173-4 |página=500 |capítulo=Internet relay chat
}}</ref> Se o ''ident'' não estiver disponível no cliente, o nome de usuário especificado quando o cliente conectou-se é usado após ser prefixado com um [[til]].<ref name="freenode faq">{{Citar web |url=http://freenode.net/faq.shtml |título=Frequently-asked questions |acessodata=20-04-2021 |publicado=[[Freenode]] |lingua=en |titulotrad=Perguntas frequentes |arquivourl=https://web.archive.org/web/20100326082146/http://freenode.net/faq.shtml |arquivodata=26-04-2010}}</ref>
 
A parte do ''host'' é o ''[[hostname]]'' do qual o cliente está se conectando. Se o [[Endereço IP|endereço <nowiki>''IP''</nowiki>]] do cliente não puder ser resolvido para um ''hostname'' válido pelo servidor, ele (o endereço de ''IP'') será usado em vez do nome do ''host''.
 
Devido às implicações de [[privacidade]] de expor o endereço ''IP'' ou o nome de ''host'' de um cliente, alguns [[IRCd|''daemons IRC'']] também fornecem recursos de privacidade como o ''InspIRCD'' ou o modo "+ x" do ''UnrealIRCd''. Isto [[função hash criptográfica|criptografa]] um endereço de ''IP'' do cliente ou mascara parte do nome do ''host'' de um cliente (tornando-o ilegível para usuários que não sejam [[Internet Relay Chat#IRC Operators|''IRCops'']]). Os usuários também podem ter a opção de solicitar um "''host'' virtual" (ou "''vhost''"), exibido na máscara de ''host'' para permitir maior anonimato. Algumas redes ''IRC'', como a ''[[Freenode]]'', os usam como "disfarces" para indicar que um usuário é afiliado a um grupo ou projeto.<ref>{{Citar web |url=http://meta.wikimedia.org/wiki/IRC/Cloaks |título=IRC/Cloaks |acessodata=20-04-2021 |publicado=[[Wikipédia:Meta-wiki|Meta-wiki]] |lingua=en}}</ref>
 
=== Esquema URI ===
 
Existem três esquemas ''[[Uniform resource identifier|URI]]'' reconhecidos para o ''IRC'': ''<code>irc</code>, <code>ircs</code>'', e ''<code>irc6</code>''.<ref>{{Citar web |url=http://www.iana.org/assignments/uri-schemes.html |título=Uniform resource identifier (URI) schemes |acessodata=20-04-2021 |publicado=Internet Assigned Numbers Authority |língua=en |títulotrad=Esquemas URI (identificador de recurso uniforme)}}</ref> Quando suportados, eles permitem [[Hiperligação|ligações]] de várias formas, incluindo:
<nowiki>irc://<host>[:<porta>]/[<canal>[?<senha do canal>]]</nowiki>
<nowiki>ircs://<host>[:<porta>]/[<canal>[?<senha do canal>]]</nowiki>
<nowiki>irc6://<host>[:<porta>]/[<canal>[?<senha do canal>]]</nowiki>
Os itens entre colchetes são opcionais para serem usados (se necessário) para se conectar ao ''host'' especificado (ou rede, se conhecido do cliente ''IRC'') e ingressar no canal especificado.<ref>{{citar web |último=Butcher |primeiro=Simon |url=https://tools.ietf.org/html/draft-butcher-irc-url-04 |título=URI schemes for IRC entities |data=janeiro de 2003 |acessodata=20-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |língua=en |títulotrad=Esquemas URI para entidades IRC}}</ref> Isso pode ser usado no próprio cliente ou em outro aplicativo (como um navegador da ''web''). O ''URI'' padrão é ''irc''. O ''irc6'' especifica uma conexão a ser feita usando ''IPv6'' e o ''ircs'' especifica uma conexão segura.
 
De acordo com a especificação, o usual [[Cerquilha|símbolo ''hash'' (#)]] prefixado em nomes de canais que começam com um caractere [[alfanumérico]] permite que eles sejam omitidos. Algumas implementações (por exemplo, ''mIRC'') farão isso "incondicionalmente", resultando em um (geralmente não intencional) extra (por exemplo, canal ##), se incluído na ''URL''.
 
Algumas implementações permitem que vários canais sejam especificados (separados por vírgulas).<ref>{{Citar web |url=https://www.npmjs.com/package/node-irc |título=node-irc |acessodata=2021-04-20 |website=npm |língua=en}}</ref>
 
== Desafios ==
 
Os problemas no ''design'' original do ''IRC'' eram a quantidade de dados de estado compartilhados<ref>{{citar web |último=Reed |primeiro=D. |url=https://tools.ietf.org/html/rfc1324#section-2.5.1 |título=A discussion on computer network conferencing - Size (section 2.5.1) |data=maio de 1992 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |páginas=5 e 6 |língua=en |títulotrad=Uma discussão sobre conferência em rede de computadores - Tamanho (seção 2.5.1) |doi=10.17487/RFC1324 |rfc=1324}}</ref><ref>{{citar web |último=Kalt |primeiro=C. |url=https://tools.ietf.org/html/rfc2810#section-6.1 |título=IRC: Architecture - Scalability section 6.1) |data=abril de 2000 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=7 |língua=en |títulotrad=IRC: Arquitetura - Escalabilidade seção 6.1) |doi=10.17487/RFC2810 |rfc=2810}}</ref> sendo uma limitação em sua escalabilidade,<ref>{{harvnb|Loesch|2003}} 1.2.1 Growth - Crescimento</ref> a ausência de identificações de usuário exclusivas levando ao problema de colisão de apelidos,<ref>{{citar web |último=Reed |primeiro=D. |url=https://tools.ietf.org/html/rfc1324#section-5.4.1 |título=A discussion on computer network conferencing - User identification (section 5.4.1) |data=maio de 1992 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=10 |língua=en |títulotrad=Uma discussão sobre conferência em rede de computadores - Identificação do usuário (seção 5.4.1) |doi=10.17487/RFC1324 |rfc=1324}}</ref> falta de proteção de [[netsplit|divisões de redes]] por meio de roteamento cíclico,<ref>{{citar web |último=Reed |primeiro=D. |url=https://tools.ietf.org/html/rfc1324#section-5.4.2 |título=A discussion on computer network conferencing - Trees and cycles (section 5.4.2) |data=maio de 1992 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=10 |língua=en |títulotrad=Uma discussão sobre conferência de rede de computadores - Árvores e ciclos (seção 5.4.2) |doi=10.17487/RFC1324 |rfc=1324}}</ref><ref>{{harvnb|Loesch|2003}} 1.2.2 Network failures - Falhas de rede</ref> a compensação em escalabilidade por causa das informações de presença do usuário em tempo real,<ref>{{citar web |último=Reed |primeiro=D. |url=https://tools.ietf.org/html/rfc1324#section-2.1 |título=A discussion on computer network conferencing - State information problems (section 2.1) |data=maio de 1992 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=4 |língua=en |títulotrad=Uma discussão sobre conferência de rede de computadores - Problemas de informação de estado (seção 2.1) |doi=10.17487/RFC1324 |rfc=1324}}</ref> fraquezas do protocolo fornecendo uma plataforma para mau uso,<ref>{{harvnb|Loesch|2003}} 1.2.3 Sociological and security aspects - Aspectos sociológicos e de segurança</ref> nenhuma passagem de mensagem transparente e otimizável<ref>{{citar web |último=Reed |primeiro=D. |url=https://tools.ietf.org/html/rfc1324#section-5.2.1 |título=A discussion on computer network conferencing - Message passing (section 5.2.1) |data=maio de 1992 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |página=7 |língua=en |títulotrad=Uma discussão sobre conferência em rede de computadores - passagem de mensagens (seção 5.2.1) |doi=10.17487/RFC1324 |rfc=1324}}</ref> e ausência de criptografia.<ref>{{citar web |ultimo=Reed |primeiro=D. |url=https://tools.ietf.org/html/rfc1324#section-5.2.4 |titulo=A discussion on computer network conferencing - Conference security (5.2.4) |data=maio de 1992 |acessodata=19-04-2021 |publicado=[[Internet Engineering Task Force|IETF]] |pagina=8 |lingua=en |titulotrad=Uma discussão sobre conferência em rede de computadores - segurança de conferência (5.2.4) |doi=10.17487/RFC1324 |rfc=1324}}</ref> Algumas dessas questões foram tratadas no "''IRC'' moderno".
 
=== Ataques ===
 
Como as conexões ''IRC'' podem não ser criptografadas e normalmente se estendem por longos períodos, elas são um alvo atraente para [[ataque de negação de serviço|ataques ''DoS/DDoS'']] e ''[[hacker]]s''. Por causa disso, uma política de segurança cuidadosa é necessária para garantir que uma rede ''IRC'' não seja suscetível à um ataque como uma guerra para [[Internet Relay Chat takeover|assumir o controle]]. As redes ''IRC'' também podem listar em "[[linha K (IRC)|linha K]]" ou "[[linha G]]" usuários ou servidores que tenham um efeito prejudicial.
 
Alguns servidores ''IRC'' suportam conexões [[Transport Layer Security|''SSL/TLS'']] para fins de segurança. Isso ajuda a interromper o uso de programas [[Analisador de pacotes|analisadores de pacotes]] para obter as senhas de usuários de ''IRC'', mas tem pouco uso além desse escopo devido à natureza pública dos canais de ''IRC''. As conexões ''SSL'' requerem suporte ao cliente e ao servidor (que pode exigir que o usuário instale binários ''SSL'' e patches ou módulos específicos do cliente ''IRC'' em seus computadores). Algumas redes também usam ''SSL'' para conexões servidor a servidor e fornecem um sinalizador de canal especial (como <code>+S</code>) para permitir apenas usuários conectados por ''SSL'' no canal, enquanto proíbe a identificação do operador em texto não criptografado, para melhor utilizar as vantagens que o ''SSL'' oferece.<ref>{{Citar web |url=http://esper.net/help.php |título=Getting help on EsperNet |acessodata=20-04-2021 |publicado=The EsperNet IRC network |língua=en |títulotrad=Obtendo ajuda na EsperNet}}</ref><ref>{{Citar web |url=http://www.dal.net/news/shownews.php?id=67 |título=New feature: SSL for users |data=18 de maio de 2010 |acessodata=20-04-2021 |publicado=DALnet |autor=brandon |língua=en |títulotrad=Novo recurso: SSL para usuários}}</ref>
 
O ''IRC'' serviu como um primeiro laboratório para muitos tipos de ataques na ''internet'', como o uso de
inacessíveis falsas mensagens [[Internet Control Message Protocol|''ICMP'']] para quebrar as conexões ''IRC'' baseadas no [[Transmission Control Protocol|TCP]] ([[Nuke (computador)|''nuking'']]) para incomodar os usuários ou facilitar [[Internet Relay Chat takeover|assumir o controle (''takeover'')]].
 
=== Prevenção de mau uso ===
 
Uma das questões técnicas mais controversas em torno das implementações de ''IRC'', que sobrevive até hoje, é o mérito dos protocolos ''"nick/channel delay vs. timestamp"''. Ambos os métodos existem para resolver o problema de ataques de negação de serviço, mas têm abordagens muito diferentes.
O problema com o protocolo ''IRC'' original implementado era que, quando dois servidores se dividiam e se juntavam, os dois lados da rede simplesmente fundiam seus canais. Se um usuário entrarasse em um servidor "dividido", em um canal (que existia do outro lado da rede) vazio e obtesse o ''status'' de operador, ele se tornaria um operador de canal do canal "combinado" após o término do ''[[netsplit]]''. Se um usuário pegasse um apelido que existia do outro lado da rede, o servidor "mataria" os dois usuários ao reingressarem (ou seja, "colisão de apelidos").
Isso era freqüentemente usado para "matar em massa" todos os usuários em um canal, criando canais ''"opless"'' (onde nenhum operador estava presente para lidar com o mau uso). Além de causar problemas dentro do ''IRC'', isso encorajou as pessoas à conduzirem ataques de negação de serviço contra servidores ''IRC'' para causar ''netsplits'' (dos quais elas, então, se aproveitariam para mau uso).
 
{{anchor|delay}}


Devido ao uso de ligações em forma de árvore entre os servidores de IRC não existe redundância e como tal uma falha num servidor ou ligação pode causar o que é chamado de [[netsplit]].
As estratégias de ''nick delay'' e ''channel delay'' visam prevenir mau uso (atrasando reconexões e renomeações). Depois que um usuário termina a sessão e o [[apelido]] fica disponível, ou um canal deixa de existir porque todos os seus usuários partiram (como freqüentemente acontece durante uma [[netsplit|divisão de rede]]), o servidor não permite que usuário algum use aquele apelido ou entre naquele canal, até que um certo período de tempo (o "atraso") tenha passado. A ideia por trás disso é que, mesmo que ocorra uma divisão de rede, é inútil para os usuários "mal-intencionados" porque eles não podem pegar o apelido ou obter ''status'' de operador em um canal por meio da vulnerabilidade anteriormente mencionada (portanto, a colisão de um apelido ou a "fusão" de um canal não pode acontecer). Até certo ponto, isso é inconveniente para os usuários legítimos, que podem ser "forçados (ou induzidos)" à usar, brevemente, um nome (apelido) diferente após o retorno (anexar um [[sublinhado]] é prática comum nesses casos).


Para conseguir utilizar este protocolo, é necessário, primeiro, ter um cliente de IRC, que é um programa que se comunica com um servidor de uma rede de IRC. No [[sistemas operacionais|sistema operativo]] [[Windows]], o mais famoso é o [[mIRC]], no [[Linux]], o mais usado é o [[XChat]]. Temos também o Kvirc que pode ser rodado tanto em linux quanto em windows.
O protocolo ''timestamp'' é uma alternativa, aos atrasos de apelido/canal, que resolve colisões usando a prioridade de ''timestamp''. Cada apelido e canal na rede são atribuídos à um ''timestamp'' com a data e a hora em que foram criados. Quando ocorre um ''netsplit'', dois usuários de cada lado são livres para usar o mesmo apelido ou canal, mas quando os dois lados são unidos, apenas um pode "sobreviver". No caso de apelidos, o usuário mais novo, de acordo com seu ''timestamp'', é "morto". Quando um canal colide, os membros (usuários no canal) são mesclados, mas os operadores de canal no lado "perdedor" da divisão perdem seu ''status'' de operador de canal.


Os servidores não são simples servidores, também podem ser unidos numa rede. Grandes redes podem juntar, num horário de pico, dezenas de milhares de pessoas. A especificação do protocolo é disponibilizada pelo RFC 2812.
O ''TS'' (''timestamp'') é um protocolo muito mais complicado do que o ''ND'' (''nick delay'')/''CD'' (''channel delay''), tanto em ''design'' como em implementação. Apesar de ter passado por várias revisões, algumas implementações ainda têm problemas com "dessincronização" (onde dois servidores na mesma rede discordam sobre o estado atual da rede), permitindo muita clemência no que seria permitido pelo lado "perdedor". Sob os protocolos ''TS'' originais, por exemplo, não havia proteção contra usuários definindo banimentos ou outros modos no canal perdedor (que seriam então mesclados na fusão quando a divisão (''netsplit'') terminasse, mesmo que os usuários que configuraram esses modos perdessem seus ''status'' de operador de canal). Alguns servidores ''IRC'' modernos baseados em ''TS'' também incorporaram alguma forma de ''ND''/''CD'', além da marcação de tempo, em uma tentativa de conter ainda mais o mau uso.


=== Evolução ===
A maioria das redes hoje usa a abordagem de carimbo de data/hora. Os desacordos de ''"TS versus ND/CD"'' fizeram com que vários servidores se separassem da ''[[EFnet]]'' e formassem os mais novos ''[[IRCnet]]s''. Após a divisão, a ''EFnet'' mudou para um protocolo ''TS'', enquanto a ''IRCnet'' optou pelo ''ND''/''CD''.
Todos os protocolos cliente-servidor de IRC em uso descendem do protocolo implementado na versão 2.8 do IRC2server, documentado na RFC 1459. Desde que esta foi publicada, as novas funcionalidades do IRC 2.10 levaram à publicação de outras propostas de protocolos; RFC 2810, RFC 2811, RFC 2812 e RFC 2813, no entanto estas alterações não foram largamente adaptadas pelas outras implementações. O IRC 2.10 é largamente usado na rede [[IRCnet]]. O protocolo IRC foi estendido pela Microsoft em 1998 através do seu protocolo [[IRCX]] que resolve muitos dos problemas que as redes de IRC têm, juntamente com algumas funcionalidades que a maioria dos utilizadores sentiu "estarem à frente do tempo". Embora muitas especificações do protocolo IRC tenham sido publicadas, não existe especificação oficial como o protocolo permanece dinâmico. Virtualmente nenhum cliente e muitos poucos servidores se restringem apenas às RFCs mencionadas como referência.


Enquanto os protocolos cliente-servidor são pelo menos similarmente funcionais, os protocolos servidor-servidor variam largamente (TS5, P10, e ND/CD são vários dos protocolos mais usados), tornando a ligação entre dois servidores com implementações diferentes muito difícil. Alguns servidores "ponte" existem para permitirem a ligação, de por exemplo, servidores 2.10 a servidores TS5, mas estes são normalmente acompanhados de restrições no que toca ao uso de partes de cada protocolo, e não estão largamente adaptados.
Em versões recentes do ''ircd IRCnet'', bem como ''ircds'' usando o protocolo ''TS6'' (incluindo ''Charybdis''), o ''ND'' foi estendido/substituído por um mecanismo chamado ''SAVE''. Este mecanismo atribui um [[identificador exclusivo]] à cada cliente (ao se conectar à um servidor ''IRC''). Este ''ID'' começa com um número, é proibido em apelidos (''nicknames'') (embora alguns ''ircds'', nomeadamente ''IRCnet'' e ''InspIRCd'', permitam que os clientes usem o próprio ''UID'' como apelido).


Nas suas primeiras versões, o IRC não tinha muitas das funcionalidades existentes hoje em dia, como canais com nomes e operadores de canais. Os canais eram numerados – canal 4 e 57, por exemplo – e o '''tópico''' do canal descrevia o tipo de conversação que tomava lugar no canal. Uma consequência deste tipo de numeração é que ao entrar no canal 0 faz com que o cliente deixe todos os canais em que está no momento: sendo "CHANNEL 0" o comando original para deixar o canal corrente.
Se dois clientes com o mesmo apelido se juntam de lados diferentes de um ''netsplit'' ("colisão de apelidos"), o primeiro servidor a ver esta colisão "força ambos" os clientes à mudarem seu apelido (''nickname'') para seu ''UID''( evitando assim que ambos os clientes sejam desconectados). Na ''IRCnet'', o apelido também ficará bloqueado por algum tempo (''ND'') para evitar que ambos os clientes voltem ao apelido original, colidindo novamente.


A primeira grande alteração ao IRC ocorreu na versão 2.5 com a adição de '''nomes''' aos canais – "+canal" sendo que mais tarde viria a ser substituído por "#canal" na versão 2.7, tendo os canais numéricos sido completamente removidos e implementados os bans de canal (modo +b). O irc2.8 adicionou a forma "&canal" sendo que esta representa todos os canais que existem no servidor corrente, ao invés de serem globais a toda a rede; e "!canal" representando os canais que teoricamente estariam a salvo de sofrer as consequências da exploração indevida pelos utilizadores através dos netsplits, sendo esta a versão a partir da qual quase todas as implementações derivam.
== Clientes ==


Edições baseadas na versão 2.8 incluem:
=== ''Software'' cliente ===


* 2.8.1+CS, desenvolvido por Comstud
<!--
* 2.8+th, conjunto de correcções de Taner, que mais tarde viria a tornar-se
{{Details| Comparação dos clientes de IRC}}
* 2.8/hybrid, originalmente desenvolvido por Jon Lusky ('''Rodder''') e Diana Bruce ('''Dianora'''), tendo mais tarde incorporado uma extensa equipa de desenvolvimento.
* 2.9, 2.10, 2.11, … continuam o desenvolvimento da base de código original, principalmente para o uso na rede IRCnet. Esta linha de desenvolvimento produziu 4 especificações de IRC (RFC) editadas após a RFC 1459, que documentam este protocolo de servidor exclusivamente.


2.8.21+CS e 2.8/hybrid continuam a ser usadas na rede [[EFnet]], com o ircd-ratbox (uma versão do 2.8/hybrid) desde 2004 sendo um dos mais populares.
[[Imagem:Ircnetz-Schema.svg|direita|thumb| Esquema de uma rede ''IRC'' com [[Cliente (computação)|clientes normais]] (verde), ''[[Robô de IRC|bots]]'' (azul) e ''[[BNC (software)|bouncers]]'' (laranja)]]
-->


O servidor de IRC da rede [[Undernet]], ircu, é um dos poucos servidores que não descendem do irc2.8, mas sim do código base do irc2.7.
<!-- A imagem e o artigo de comparação acima não estão traduzidos. -->


Muitos dos servidores modernos de IRC foram programados do zero, como o csircd (também pela autoria de Comstud), ConferenceRoom, [[Microsoft Exchange Server]], Chat Service e IRCPlus/IRCXPro.
O ''software'' cliente existe para vários [[sistemas operacionais]] ou pacotes de ''software'', bem como jogos baseados na ''web'' ou internos. Muitos clientes diferentes estão disponíveis para os vários sistemas operacionais, incluindo ''[[Microsoft Windows|Windows]]'', ''[[Unix]]'' e ''[[Linux]]'', ''[[Mac OS X]]'' e sistemas operacionais móveis (tais como ''[[iOS]]'' e ''[[Android (sistema operacional)|Android]]''). No ''Windows'', ''[[mIRC]]'' é um dos clientes mais populares.<ref>{{citar livro|url=https://archive.org/details/isbn_9780789722836/page/289|título=Manual de configuração de inicialização múltipla|último=Smith|primeiro=Roderick W.|data=08-04-2000|publicado=Que Publishing|series=Handbook series|local=[[Upper Saddle River]], [[Nova Jérsia|Nova Jérsei]]|página=[https://archive.org/details/isbn_9780789722836/page/289 289]|lingua=en|isbn=978-0-7897-2283-6|citação=O mIRC é um dos clientes IRC mais populares do Windows.|acessodata=20-04-2021|capítulourl=https://books.google.com/books?id=OuPtI5fHhBoC|capítulo=A internet: usando o IRC para obter ajuda}}</ref>


=== Canais e modos ===
Alguns programas extensíveis através de ''[[plug-in]]s'' também servem como plataformas para clientes ''IRC''. Por exemplo, um cliente chamado ''[[ERC (software)|ERC]]'', escrito inteiramente em ''[[Emacs Lisp]]'', está incluído na versão 22.3 do ''Emacs''. Portanto, qualquer plataforma que pode executar o ''Emacs'' pode executar o ''ERC''.
[[Ficheiro:Tolsun 2.jpg|thumb|250px|O primeiro [[Servidor]] IRC, tolsun.oulu.fi.]]
A forma mais típica de comunicação numa sessão de IRC é a conversação num canal onde os utilizadores podem juntar-se e enviar mensagens as quais são depois reenviadas para todos os outros utilizadores do mesmo canal. Os canais que estão disponíveis através de toda a rede de IRC são precedidos de um ‘#’, enquanto os canais locais de um servidor são precedidos por ‘&’. Outros tipos de canais (não standard) incluem canais ‘+’ – ‘sem modos’, canais sem operadores, e canais ‘!’, uma forma de canal com [[marca temporal|marcação temporal]] em redes sem marca temporal.


Ambos utilizadores e canais podem ter modos que são no fundo um tipo de atributos ou opções. Os modos são abreviados por letras para que seja possível agrupa-los de forma concisa. Um exemplo de um modo de utilizador é o ‘i’, que quer dizer invisível. (Não é possível saber se um dado utilizador invisível está num canal, amenos que se junte ao canal ou use o comando whois no seu apelido). Um exemplo simples de um modo de canal é ‘m’ (moderado), o qual específica que apenas utilizadores com ‘voice’ e operadores de canal podem falar no canal. Existem cinco tipos de modos de canais, quatro dos quais aceitam um argumento, tipo A que aceita um argumento para adicionar/remover valores de uma lista (tal como ‘b’); tipo B que aceita um argumento para alterar o valor entre ‘ligado’ e ‘desligado’ (tal como ‘k’); tipo C que aceita um argumento apenas quando o modo está ‘ligado’ (tal como ‘l’); tipo D que não aceita argumentos e é simplesmente uma opção booleana (tal como ‘m’, ‘n’, e ‘t’); e tipo E (normalmente chamado modo ‘class’ ou ‘prefixo’) que dá ou tira um privilégio de um utilizador num canal (tal como ‘o’).
Vários [[navegadores]] têm clientes ''IRC'' integrados (como o ''[[Opera]]'' versões 12.18 e anteriores<ref>{{Citar web |url=http://operawiki.info/OperaIR |título=Opera browser wiki: IRC client |acessodata=20-04-2021 |lingua=en |titulotrad=Wiki do navegador Opera: cliente IRC |arquivourl=https://web.archive.org/web/20110317014824/http://operawiki.info/OperaIRC |arquivodata=17-03-2011 |urlmorta=Sim}}</ref> e o complemento ''[[ChatZilla]]'' para ''Mozilla [[Firefox]]'' (56 e anteriores) incluído como um componente integrado do ''[[SeaMonkey]]''). Clientes baseados na Web, como ''[[Mibbit]]'' e ''KiwiIRC'' de código aberto, podem ser executados na maioria dos navegadores.


Os modos do tipo E (classes de canais) especificam quais os utilizadores que têm privilégios num canal, e qual o nível dos privilégios que têm. Originalmente apenas os modos de operadores de canal (modo ‘o’) e ‘voice’ (modo ‘v’) existiam. Os privilégios dos operadores de canal (normalmente abreviados por chanop ou simplesmente ‘op’) permitem expulsar utilizadores (kick), colocar modos, e alterar o tópico do canal se este estiver ‘+t’. Os privilégios dos utilizadores com ‘voice’ permitem ao utilizador falar no canal se este estiver moderado (modo ‘m’). Outros modos adicionais destas classes são: ‘fundador’ (modo ‘q’) criado pela Microsoft na sua implementação IRCX (e mais tarde usado pelo UnrealIrcd); ‘half-operator’ (também referido como ‘halfop’, modo ‘h’) que é similar a um operador de canal, excepto que os utilizadores com este privilégio não podem colocar certos modos e apenas podem expulsar utilizadores normais; ‘protegido’ (modo ‘a’); ‘administrator’ (modo ‘a’ ou ‘u’); e muitos mais.
Jogos como ''[[Warsow|War§ow]]'',<ref>{{Citar web |url=http://www.warsow.net/wiki/index.php?title=IRC_Module |título=Warsow wiki: IRC module |acessodata=20-04-2021 |lingua=en |titulotrad=Wiki Warsow: módulo IRC |arquivourl=https://web.archive.org/web/20110425010535/http://www.warsow.net/wiki/index.php?title=IRC_Module |arquivodata=25-04-2011 |urlmorta=Sim}}</ref> ''[[Unreal tournament]]'' (até o ''[[Unreal Tournament 2004|Unreal tournament 2004]]''),<ref>{{Citar web |último=Guenter |primeiro=Daniel |url=http://www.bcchardware.com/index.php?option=com_content&task=view&id=35&Itemid=40 |título=UT2004 review |data=21-06-2004 |acessodata=20-04-2021 |publicado=BCCHardware |lingua=en |titulotrad=Análise UT2004}}</ref> ''[[Uplink (video game)|Uplink]]'',<ref>{{Citar web |url=http://guide.modlink.net/section11.php |título=The ultimate uplink guide |acessodata=20-04-2021 |lingua=en |titulotrad=O melhor guia Uplink}}</ref> jogos baseados em ''[[Spring engine]]'', ''[[0 A.D.]]'' e ''ZDaemon'' têm o ''IRC'' incluído.<ref>{{Citar web |url=https://doomwiki.org/wiki/ZDaemon#Other_utilities |título=ZDaemon – The doom wiki: other utilities |acessodata=20-04-2021 |lingua=en |titulotrad=ZDaemon - The doom wiki: outros utilitários}}</ref>


Cada classe de canal tem associado um prefixo que é mostrado ao lado do apelido de cada utilizador que estiver associado com o canal. Os prefixos mais comuns são ‘@’ para operadores de canal, ‘+’ para ‘voices’, ‘%’ para ‘half-op’, ‘.’ ou ‘~’ para os fundadores, ‘&para utilizadores protegidos, e ‘!’ ou ‘*’ para administrador.
A interface de chat do ''[[Ustream]]'' é ''IRC'' com autenticação personalizada,<ref>{{Citar web |url=http://ustream-helpers.com/how-to/ircclient |título=How to setup &#91;sic&#93; an IRC client to connect and login &#91;sic&#93; to Ustream |data=29-01-2012 |acessodata=20-04-2021 |publicado=Ustream-Helpers |titulotrad=Como configurar &#91;sic&#93; um cliente IRC para conectar e fazer login &#91;sic&#93; para Ustream |urlmorta=Sim}}</ref> bem como a do [[Twitch (serviço)|Twitch]] (anteriormente Justin.tv).<ref>{{Citar web |url=http://www.liquidsilver.org/2010/06/ustream-v-justin/ |título=Ustream vs. Justin.tv |data=20-06-2010 |acessodata=20-04-2021 |publicado=LiquidSilver |autor=Mauldor |urlmorta=Sim}}</ref><ref>{{Citar web |url=https://help.twitch.tv/customer/portal/articles/1302780-twitch-irc |título=Twitch IRC |data=07-04-2017 |acessodata=20-04-2021 |website=Twitch help center |língua=en |urlmorta=Sim}}</ref>


A maioria das redes de IRC tem uma série de modos extra não especificados em qualquer dos documentos RFC. No entanto existe uma maneira elegante para os clientes se adaptarem, uma lista de todos os modos de utilizadores e canais é enviada para os clientes na resposta RPL_MYINFO quando o utilizador efectua o logon. Em adição, a lista de modos de canal (e o tipo de argumentos que estes aceitam), e os prefixos para as classes de modo são especificados na resposta do protocolo (RPL_PROTOCTL ou 005) enviado por parte da maioria dos servidores de IRC quando um cliente liga. Esta mensagem é usada para informar os clientes quais são as funcionalidades que o servidor aceita e quais são os limites (por exemplo, o número máximo de utilizadores que pode ter na lista de notificação, ou o tamanho máximo do apelido do utilizador).
=== ''Bots'' ===
Existem também utilizadores cujos privilégios se estendem para servidores inteiros ou mesmo redes de servidores;  chamado de [[operador de IRC]] (também muitas vezes referidos como [[IRCop]]). Em algumas implementações do IRC, aos operadores de IRC é também garantido o privilégio de operador de canal em todos os canais embora muitas pessoas acreditem que a administração dos canais e a administração da rede deva ser mantida separada e que o estatuto de operador de IRC não deve conferir o direito em interferir na operação de um canal particular.


Devido às ligações ao IRC não serem encriptadas e tipicamente estarem activas durante um longo período, são um alvo atractivo para actividades maliciosas. Devido a este facto, uma política de segurança eficaz é necessária para que uma rede de IRC não seja susceptível a ataques como os tradicionais ''takeovers''. As redes de IRC também podem colocar [[k-line]] ou [[g-line]] a utilizadores ou redes que tendam a ter efeitos negativos para com as mesmas.
{{Artigo principal|Robô de IRC}}


O IRC serviu como um laboratório para muitos tipos de ataques na Internet, como usar mensagens [[ICMP]] do tipo ''unreachable'' para desligar ligações [[TCP]] ao IRC (o chamado "nuke") para chatear utilizadores ou facilitar takeovers.
Um uso típico de ''bots'' no ''IRC'' é o de fornecer [[Serviços IRC|serviços]] ou funcionalidades específicas dentro de um canal, como hospedar um jogo baseado em ''chat'' ou fornecer notificações de eventos externos. No entanto, alguns ''bots IRC'' são usados para lançar ataques maliciosos, como negação de serviço, ''spamming'' ou exploração.<ref>{{Citar web |último=Canavan |primeiro=John |url=http://www.symantec.com/avcenter/reference/the.evolution.of.malicious.irc.bots.pdf |título=The evolution of malicious IRC bots |acessodata=20-04-2021 |website=Symantec |publicado=Symantec security response |língua=en |títulotrad=A evolução dos bots IRC maliciosos |arquivourl=https://web.archive.org/web/20171010050528/http://www.symantec.com/avcenter/reference/the.evolution.of.malicious.irc.bots.pdf |arquivodata=10-10-2017}}</ref>


=== Prevenção de abuso: marca temporal x ''nick/channel delay'' ===
=== ''Bouncer'' ===
Uma das dificuldades técnicas do IRC mais contenciosa, e que ainda hoje persiste, é o mérito dos protocolos "Nick/Channel Delay" x [[marca temporal]]. Ambos os métodos existem para resolver o problema dos ataques de negação de serviço ([[Denial of Service]]), mas têm soluções muito diferentes.


O problema com o protocolo original do IRC como implementado era que quando dois servidores se separavam e voltavam a ligar-se, os dois lados da rede simplesmente juntavam os canais. Se um utilizador entrasse num servidor separado da rede, num canal que existisse em ambos os lados da rede e estivesse vazio, ganhasse estatuto de operador de canal, este tornar-se-ia operador de canal dos canais "combinados" da junção da rede; se um utilizador utilizasse um apelido que existisse no outro lado da rede, o servidor desligaria ambos quando ocorresse a junção.
{{Artigo principal|BNC (software)}}


Isto era muitas vezes usado para fazer "mass-ban/kick" sobre todos os utilizadores de um canal, criando assim canais sem operadores de canal: aonde não existiam operadores disponíveis para tomar conta do abuso. Além de criar problemas dentro do IRC, isto encorajava as pessoas a efectuarem ataques de negação de serviço contra servidores de IRC para causar netsplits, os quais seriam então abusados.
Um programa que é executado como um ''[[Daemon (computação)|daemon]]'' em um [[Servidor (computação)|servidor]] e funciona como um ''[[proxy]]'' persistente é conhecido como ''BNC'' ou bouncer. O objetivo é manter uma conexão com um servidor ''IRC'', atuando como um retransmissor entre o servidor e o cliente, ou simplesmente atuar como um ''proxy''. Caso o cliente perca a conectividade de rede, o ''BNC'' pode permanecer conectado e arquivar todo o tráfego para entrega posterior, permitindo ao usuário retomar sua sessão de ''IRC'' sem interromper sua conexão com o servidor.<ref>{{Citar web |url=http://www.psybnc.at/readme.txt |título= psyBNC Readme |títulotrad=Leia-me psyBNC |língua=en |acessodata=20-04-2021 |publicado=psybnc.at}}</ref>


==== Protocolo ''Nick/Channel Delay'' ====
Além disso, como forma de obter um efeito semelhante ao do bouncer, um cliente ''IRC'', normalmente [[Interface de base texto|baseado em texto]] (como o ''[[Irssi]]'' por exemplo), pode ser executado em um servidor sempre ativo ao qual o usuário se conecta via ''[[Secure Shell|SSH]]''. Isso também permite que dispositivos que têm apenas a funcionalidade ssh, mas nenhum cliente de ''IRC'' real instalado, se conectem ao ''IRC'' e permite o compartilhamento de sessões de ''IRC''.<ref>{{Citar web |url=http://chriscarey.com/wordpress/2009/07/18/irc-with-irssi-proxy-screen/
A solução do protocolo de espera de nick/canal (conhecida do inglês como "Nick/Channel delay" e abreviada ND/CD) para este problema era simples. Após um utilizador ter saído da rede e o apelido tornando-se disponível, ou um canal ter deixado de existir porque todos os seus utilizadores o tinham deixado (como regularmente acontece num netsplit), o servidor não permitiria nenhum utilizador usar esse apelido ou entrar naquele canal, respectivamente, até que um certo período de tempo tivesse ocorrido (delay). A ideia por trás disto era que mesmo que um netsplit ocorresse, seria inútil para um utilizador mal intencionado porque não poderiam mudar o apelido ou ganhar privilégios de operador de canal, não havendo assim colisões de apelido caso uma junção de um canal ocorresse. Até certo ponto, isto torna-se inconveniente para utilizadores legítimos que podem ser obrigados a usar, durante um breve tempo, um nome diferente depois de voltar ao canal.
|título= IRC with irssi-proxy + screen |títulotrad=IRC com irssi-proxy + tela |língua=en |acessodata=20-04-2021 |último=Carey |primeiro=Chris |data=18-07-2009 |publicado=chriscarey.com
}}</ref>


==== Protocolo de marca temporal ====
Para evitar que o cliente ''IRC'' feche quando a conexão ssh for fechada, o cliente pode ser executado dentro de um [[terminal multiplexador]], como ''[[GNU Screen]]'' ou ''[[tmux]]'', mantendo-se assim constantemente ligado à(s) rede(s) ''IRC'', podendo registar as conversações nos canais de interesse do utilizador e manter a presença nos canais na rede. Modelado a partir dessa configuração, em 2004 um cliente ''IRC'' seguindo o [[modelo cliente-servidor]], chamado ''[[Smuxi]]'', foi lançado.<ref>{{Citar web |título=Detachable frontend (core rewrite) / UML / Windows Port (kicking glade) |data=25-12-2004 |acessodata=20-04-2021 |publicado=smuxi.org |língua=en |url=http://www.smuxi.org/blog/show/Detachable_Frontend_Core_Rewrite__UML__Windows_Port_kicking_Glade}}</ref><ref>{{Citar web |url=http://www.smuxi.org/page/About |título=About Smuxi |acessodata=20-04-2021 |publicado=smuxi.org |língua=en |títulotrad=Sobre o Smuxi}}</ref>
A alternativa, a [[marca temporal]] ou protocolo TS, tomou uma aproximação diferente. A todos os apelido e canais numa rede era atribuído uma marca temporal – a data e tempo da sua criação. Quando um netsplit ocorria, dois utilizadores nos dois lados da rede eram livres de usar o mesmo apelido e canal, mas quando os dois lados eram juntos, apenas um poderia sobreviver. No caso dos apelidos, o utilizador mais recente, de acordo com a sua marca de tempo, seria desligado; quando um canal colidisse, os membros do canal eram juntos, mas os operadores de canais ficavam a perder sendo-lhes retirado o estatuto de operador.


O protocolo TS é muito mais complicado que o ND/CD, tanto em desenho como em implementação, e apesar de terem sido várias as revisões, algumas implementações ainda têm problemas de dessincronização (referido como "desyncs", aonde todos os servidores na mesma rede discordam à cerca do estado corrente da rede), permitindo muita leniedade no que era permitido pelo lado que perdia. No protocolo TS original, por exemplo, não existia protecção contra utilizadores que colocassem bans ou outros modos no canal no lado afectado pelo netsplit, que depois viriam a ser juntos quando os servidores se ligassem novamente, mesmo sabendo que os utilizadores que tivessem colocado esses modos não estivessem mais com estatuto de operador. Alguns servidores de IRC modernos que implementam o TS também incorporam alguma forma do ND e ou CD em adição a marcação temporal numa tentativa de restringir os abusos.
== Mecanismos de pesquisa ==


Não existe, e muito provavelmente não existirá, um consenso entre marcação temporal e o protocolo ND/CD; no entanto a maioria das redes hoje em dia usam o método de marcação temporal. Parte das dificuldades e das discordâncias causaram com que uma série de servidores se separassem da rede EFnet e formassem a nova IRCnet (usando a Efnet o protocolo TS, e a IRCnet o ND/CD), sendo que os apoiantes de ambos os lados ficaram conhecidos pelos seus argumentos quentes relativamente aos méritos das suas soluções.
Existem vários motores de busca disponíveis para ajudar o usuário a encontrar o que procura no ''IRC''.<ref>{{citar livro|título=IRC hacks|último=Mutton|primeiro=Paul|data=27-07-2004|publicado=[[O'Reilly Media]]|local=[[Sebastopol (Califórnia)|Sebastopol, California]]|páginas=44 à 46|lingua=en|titulotrad=Hacks IRC|isbn=978-0-596-00687-7|edição=1|capítulo=Users and channels - Usuários e canais}}</ref><ref>{{citar livro|url=https://archive.org/details/stealthisfilesha00wang/page/65|título=Steal this file sharing book|último=Wang|primeiro=Wallace|data=25-10-2004|publicado=[[No Starch Press]]|local=[[São Francisco (Califórnia)|San Francisco, California]]|páginas=[https://archive.org/details/stealthisfilesha00wang/page/65 65 à 67]|lingua=en|titulotrad=Roube este livro de compartilhamento de arquivos|isbn=978-1-59327-050-6|edição=1|capítulo=Instant messaging and online chat rooms: internet relay chat (IRCarquivo ) - Mensagens instantâneas e salas de bate-papo online: internet relay chat (IRCarquivo)}}</ref> Geralmente, o mecanismo de pesquisa consiste em duas partes, um ''"back-end"'' (ou ''"spider''/''crawler"'') e um "mecanismo de pesquisa" ''"front-end"''.


== Servidores ==
O ''back-end'' (''spider'' /''webcrawler'') é o cavalo de batalha do mecanismo de pesquisa. É responsável por rastrear servidores ''IRC'' para indexar as informações enviadas por eles. As informações indexadas, geralmente, consistem apenas no texto do canal (texto que é exibido publicamente em canais públicos).
IRCd é o nome dado ao servidor atual de IRC. O servidor IRCd que fornece os comandos que foram citados assim como permitir que os clientes IRC possam se comunicar usando o protocolo IRC.


Podemos ter como servidores IRC rodados em plataformas Linux ou Windows. As plataformas mais usadas para criação de um IRCd são:
O "mecanismo de busca" ''front-end'' é a interface do usuário para o banco de dados. Ele fornece aos usuários uma maneira de pesquisar o banco de dados de informações indexadas para recuperar os dados que estão procurando. Esses mecanismos de pesquisa ''front-end'' também podem ser codificados em várias linguagens de programação.
* UnrealIRCd
* IRCd-Hybrid
* InspIRCd
* ircd-ratbox


== Services/Stats ==
A maioria dos mecanismos de pesquisa tem seu próprio ''spider'', que é o único aplicativo responsável por rastrear o ''IRC'' e indexar os próprios dados; entretanto, outros são indexadores "baseados no usuário". Os últimos contam com os usuários para instalarem seu "complemento" em seu cliente ''IRC''; o add-on é o que envia as informações de canal de quaisquer canais em que o usuário esteja ao banco de dados.
Os services e o stats são servidores especiais que algumas redes tem eles linkado como opção ele ajuda no controle de nicks, canais, host virtuais e alguns bots, e também controle operacional da rede. Pseudoclientes que a grande maioria desses servidores possuem é o NickServ, ChanServ, HostServ, BotServ, MemoServ e OperServ, entre outros. Os services disponíveis variam de rede para rede, depedendo de modulos instalados pelos ROOT's da rede.
* NickServ: Servidor de registro e manutenção de nicks, com ele registramos nicks atrelando a ele senhas e/ou emails. Uma vez com o nick registrado o usuário tem acesso todos os outros services. Também pode-se dizer que com o nick registrado outras pessoas a não ser aquelas que possuem a senha registrada podem acessar o nick registrado;
* ChanServ: Servidor de registro e manutenção de canais, com ele podemos registrar canais, colocar nicks registrados na lista de acesso ao qual ela da os famosos status irc como + % @ & ~ e administrando funções básicas de canais como manutenção do topico, modos, sistema de trava entre outras funções.
* MemoServ: Servidor de recados virtuais. Com o MemoServ podemos enviar memos a outros nicks registrados ou memos a um canal registrado. Os administradores da rede depedendo de modulos carregados ao MemoServ podem enviar memos a donos de canais, a todos usuários registrados da rede ou a todos canais registrados da rede.
* BotServ: Servidor de bots da rede: Este servidor administra bots da rede aos quando um BotServ é associado a um canal ele permanece em um canal ao menos quando um usuário estiver no canal. O BotServ controla os status do dos nicks registrados ao access do canal e administra tabem comandos fantasy, como o !seen que mostra usuários que estiveram no canal ou ainda estão, !k usuado quando um % ou superior registrado ao access do canal faz com o BotServ kick um usuário de um canal, !kb kick e Ban.
* HostServ: Servidor de Hosts Virtuias na rede: Este servidor é responsável em administrar os hosts virtuais de nicks registrado ao NickServ, hosts personalizadas podem ser atreladas a um nick e toda vez que o nick entrar na rede e se identificar junto ao NickServ automaticamente sua host é alterada com o auxilio do HostServ.
* OperServ: Servidor de operção e administração da rede: Com o OperServ os IRCops e Administradores da rede tem uma ferramenta fundamental na administração da rede, com apoio na segurança e funções básicas da rede. Temos nesse servidor funções básicas como akill que ajuda a adicionar mascaras de recusa de conexão na rede, ferramente para administradores alterarem nicks de usuários, e muitas outras funções diversas.
* SeenServ: Servidor de Seen. Com o SeenServ por meio do fantasy !seen Nick em um canal com o SeenServ presente o usurario pode ver quanto tempo um nick saiu da rede, mudou de nick, e sua mensagem de quit entre outras informações.
* LimitServ: Servidor limitador de usuários em canais. Com o LimitServ podemos a medida do tempo ele setar o mode +l no canal definido um novo limite em cima da quantidade de usuário presentes no canal. Exemplo se o LimitServ está programado para limitar 10 acima quando o canal ter 37 usuários o limitaddor seta o mode +l 47 no respectivo canal.
* ProfileServ: Servidor de perfis virtuais: Este servidor cadastra perfis virtuais de um devido nick, como por exemplo Nome, Idade, entre outros.
* LogServ: Servidor de Log de Canais. Com ele temos a logagem de canais da rede. Muito útil para administradores da rede verem o que se foi dito em tal hora e tal dia, podendo até servir de prova contra alguma acusação. Algumas redes disponibilizam seus logs para o público de forma aberta. Lembrando que logar um canal sem a devida autorização de seus participante ou logar canais privados, secretos, fechados ou somente invitaveis é CRIME de ivasão de privacidade previsto no codigo penal Brasileiro e Portugues.
* StatServ: Servidor de estastíscas na rede. Com ele temos dados como canais mais acessados, servidores linkados e seus fluxos de usuários, gerando até gráficos que podem ser mostrados em um site ou ftp.
* GameServ: Servidor de jogos. Algumas redes podem adotar um GameServ para canais de jogos, muitos jogos podem ser adicionados a esse servidor como por exemplo, trivia, gama-game, rpg, war, cards, sorte, uno entre outros.
* InfoServ: Servidor que pode vira a trazer informações diferenciadas para administradores pelo services. Depende da implementação dada pela rede.
* SpamServ: Quando implementado na rede promove proteções adicionais com SPAM, podendo ser desconectado ou até mesmo banido o cliente IRC que esteja infligindo as regras colocadas no SpamServ como por exemplo nomes de sites ou até mesmo nomes de redes concorrentes.
* GhostServ: Funciona de forma adicional ao NickServ promovendo o serviço que em algumas redes é realizado pelo NickServ de dar Ghost em sessões fantasmas de clientes IRC.
* ProxyScan ou OPSB: Promove a função de buscar portas no IP conectado ao servidor IRC que seja referentes a proxy aberta sem restrição ao modo "connect" que pode vir a causar problemas a rede em que esse IP conectou.
* BlistServ ou BLSB: Promove a função de busca em listas públicas como a da dronebl banindo os ips que estão presente nessas listas. Tais listas são geradas por Spam, ataques DDos entre outras situações.


=== Atalhos muito usado aos services/stats ===
Muitos usuários implementaram seus próprios motores de busca ''[[Redes ad hoc|ad hoc]]'' usando os recursos de registro embutidos em muitos clientes ''IRC''. Esses mecanismos de pesquisa são geralmente implementados como ''bots'' e dedicados a um determinado canal ou grupo de canais associados.
Isso depende muito do sistema que foi implantado pela Rede IRC. Tomando como exemplo do NickServ pode-se ter /msg NickServ ou /NickServ ou simplesmente /ns. Vejamos abaixo a lista de atalhos mais usados em muitas redes.
* NickServ: /ns
* ChanServ: /cs
* BotServ: /bs
* HostServ: /hs
* OperServ: /os
* HelpServ: /he
* StatServ: /ss
* MemoServ: /ms


== Link Inter Redes ==
== Codificação de caracteres ==
Existe uma novidade em tempos atuais que permite a interligação de redes IRC diferentes sem ocorrer a desistência de uma pelos seus registros de services. Essa interligação acontece por um link simples e permite que todos ou parte dos canais das redes sejam compartilhados entre ambas redes. Essa novidade tem unido diversas redes que se separaram no passado e cada servidor se separou que criou sua rede podem se reunir sem prejuízo de perder seus respectivos cadastro de canais e nicks.


Pode-se exemplificar o trabalho que Sistema mIRCPlus tem feito que já uniu algumas redes como sVipCHAT, ChatBrasil, BrIRC e ChatPoint, que tem promovido a união e compartilhamento do canal #Brasil aumentando os usuários no IRC dando uma sobrevida ao IRC no Brasil que teve sua queda drástica no uso nos últimos anos.
O ''IRC'' ainda carece de uma única convenção padrão globalmente aceita para transmitir caracteres fora do repertório ''[[ASCII]]'' de 7 ''bits''.
Os servidores ''IRC'' normalmente transferem mensagens de um cliente para outro cliente como sequências de ''bytes'', sem nenhuma interpretação ou recodificação de [[caractere]]s.
O protocolo ''IRC'' (ao contrário, por exemplo, do ''[[MIME]]'' ou ''[[HTTP]]'') carece de mecanismos para anunciar e negociar opções de codificação de caracteres. Isso colocou a responsabilidade de escolher o ''codec'' de caractere apropriado no cliente. Na prática, os canais de ''IRC'' têm usado amplamente as mesmas codificações de caracteres que também foram usadas pelos sistemas operacionais (em particular os derivados ''[[Unix]]'') nas respectivas comunidades linguísticas:


O Sistema de Link Inter Redes é uma inovação em que acredita-se que irá ressuscitar o falecido IRC brasileiro.
* '''Era de 7 bits:''' Nos primeiros dias do ''IRC'', especialmente entre os usuários de [[línguas germânicas do norte|escandinavo]] e [[língua finlandesa]], as variantes nacionais de ''[[ISO 646]]'' eram dominantes como [[codificação de caracteres]]. Estes codificam caracteres (não ''ASCII'') como Ä, Ö, Å, ä, ö, e å nas posições de código 0x5B, 0x5C, 0x5D, 0x7B, 0x7C e 0x7D (''[[ASCII]]'': '''[,''' '''\,''' '''],''' '''{,''' '''|''' e '''}'''). É por isso que esses códigos são sempre permitidos em apelidos. De acordo com a ''RFC'' 1459, "{", "|" e "}" em apelidos devem ser tratados, respectivamente, como equivalente (em minúsculas) de "[", "\" e "]".<ref name="rfc 1459 2.2 character codes" /> No final da década de 1990, o uso de codificações de 7 ''bits'' desapareceu em favor do ''[[ISO 8859-1]]'' e tais mapeamentos de equivalência foram retirados de alguns ''daemons IRC''.
* '''Era de 8 bits:''' Desde o início dos anos 1990, codificações de 8 ''bits'' como ''[[ISO 8859-1]]'' tornaram-se comumente usadas para idiomas europeus. Os usuários russos podiam escolher ''[[KOI8-R]]'', ''[[ISO 8859-5]]'' e ''[[Windows-1251]]'', e desde cerca de 2000, as redes ''IRC'' russas modernas convertem entre essas diferentes codificações comumente usadas do [[Alfabeto cirílico|''script'' cirílico]].
* '''Era ''multibyte'':''' Por muito tempo, os canais ''IRC'' do leste asiático com ''scripts'' logográficos na China, Japão e Coreia têm usado codificações ''multibyte'', como ''[[Extended Unix Code|EUC]]'' ou ''[[ISO-2022-JP]]''. Com a migração comum de ''ISO'' 8859 para ''[[UTF-8]]'' em plataformas ''Linux'' e ''Unix'' desde cerca de 2002, o ''UTF-8'' tornou-se um substituto cada vez mais popular para muitas das codificações de 8 ''bits'' usadas anteriormente em canais europeus. Alguns clientes de ''IRC'' agora são capazes de ler mensagens em ''ISO'' 8859-1 ou ''UTF-8'' no mesmo canal, detectando heuristicamente qual codificação é usada. A mudança para ''UTF-8'' começou em particular no ''IRC'' de língua finlandesa ([[:fi:IRC#Merkistö|Merkistö]] <small>(em finlandês)</small>).


Hoje, a codificação ''UTF-8'' de ''[[Unicode]]''/''[[ISO/IEC 10646]]'' seria a candidata mais provável para uma única codificação de caracteres padrão futura para todas as comunicações ''IRC'', se tal padrão já relaxou a restrição de tamanho de mensagem de 510 ''bytes''. O ''UTF-8'' é compatível com o ''ASCII'' e cobre o superconjunto de todos os outros [[Codificação de caracteres|conjuntos de caracteres codificados]] padrões comumente usados.


{{Referências}}
== Compartilhamento de arquivos ==
 
Muito parecido com o convencional compartilhamento de arquivos [[Ponto a ponto|''P2P'']], os usuários podem criar servidores de arquivos que lhes permitem compartilhar arquivos uns com os outros usando [[Robô de IRC|''bots'']] ou ''scripts'' personalizados para seu [[Internet Relay Chat#Clientes|cliente]]. Freqüentemente, os usuários se agrupam para distribuir ''[[warez]]'' por meio de uma rede de ''bots IRC''.<ref>{{citar jornal |url=http://www.zdnet.com/news/pirated-movies-now-playing-on-a-server-near-you/122663 |título=Pirated movies: now playing on a server near you |títulotrad= Filmes piratas: reproduzindo agora em um servidor perto de você |língua=en |acessodata=21-04-2021 |último=Vamosi |primeiro=Robert |data=08-05-2002 |obra=[[ZDNet]]}}</ref>
 
Tecnicamente, o ''IRC'' não fornece mecanismos de [[transferência de arquivo]]. O compartilhamento de arquivos é implementado pelos "clientes" ''IRC'', normalmente usando o protocolo ''[[Direct Client-to-Client|DCC]]'', no qual as transferências de arquivos são negociadas por meio da troca de mensagens privadas entre clientes. A grande maioria dos clientes de ''IRC'' oferece suporte para transferências de arquivos ''DCC'', daí a visão de que o compartilhamento de arquivos é um recurso integral do ''IRC''.<ref>{{Citar web |url=http://www.macobserver.com/tip/2002/04/04.1.shtml |título=IRC 101: What is it & how do i use it? |títulotrad=IRC 101: O que é e como devo usá-lo? |língua=en |acessodata=21-04-2021 |último=Sasaki |primeiro=Darla |data=04-04-2002 |publicado=Macobserver.com
}}</ref> O uso comum desse protocolo, entretanto, às vezes também causa ''[[spam]]'' de ''DCC''. Os comandos ''DCC'' também têm sido usados para explorar clientes vulneráveis para executar uma ação, como desconectar do servidor ou sair do cliente.


== Ver também ==
== Ver também ==
* [[Direct Connect]] e [[DC++]] rede de troca de arquivos que foi influenciada pelo IRC.
 
* [[Comparação dos clientes de IRC]]
* [[Direct Connect]]
* [[Internetês]]
 
{{Referências}}


== Ligações externas ==
== Ligações externas ==
{{Commons|IRC}}
{{Commons|IRC}}
{{Wikilivros|Internet Relay Chat}}
{{Wikilivros|Internet Relay Chat}}
 
* {{Link|título=Lista de redes por país|en|http://www.irchelp.org/irchelp/networks/local.html}}
* {{Link|en|http://www.irchelp.org/irchelp/networks/local.html Lista de redes por país}}
* RFC 2812
* RFC 2812
* {{Link|pt|http://voltamirc.hub4ever.org|Tutorial completo sobre IRC/mIRC em Português}}
* {{Link|pt|2=http://voltamirc.hub4ever.org |3=Tutorial completo sobre IRC/mIRC em Português}}
* [https://irc-source.com/networks/ Rank de Redes Segundo a IRC-Sources]
* [https://irc-source.com Rank de Redes Segundo a IRC-Sources] {{Wayback|url=https://irc-source.com/ |date=20201008234127 }}
* [http://irc.netsplit.de/networks/top100.php Rank de Redes Segundo a Netsplit.de]
* [http://irc.netsplit.de/networks/top100.php Rank de Redes Segundo a Netsplit.de]
* [http://search.mibbit.com/networks Rank de Redes Segundo ao Mibbit]
* [http://search.mibbit.com/networks Rank de Redes Segundo ao Mibbit]
Linha 195: Linha 706:


[[Categoria:Protocolos Internet]]
[[Categoria:Protocolos Internet]]
[[Categoria:IRC| ]]
[[Categoria:IRC]]
[[Categoria:Comunidades virtuais]][[Categoria:Noticias_do_mundial]]
[[Categoria:Comunidades virtuais]]

Edição atual tal como às 15h41min de 5 de fevereiro de 2022

Predefinição:Short description Predefinição:Hatnote Erro de script: Nenhum módulo desse tipo "sidebar".

O primeiro servidor IRC, tolsun.oulu.fi, um servidor Sun-3 em exibição perto do centro de informática da universidade de Oulu (2001).

O Internet relay chat (IRC) é um sistema de bate-papo baseado em texto que permite discussões entre qualquer número de participantes nos chamados canais de conversação, bem como discussões entre apenas dois parceiros (em diálogos de perguntas e respostas, por exemplo).[1] Qualquer participante pode abrir um novo canal de conversa e, um único usuário de computador pode, participar de vários canais simultâneos.

Para estabelecer ou participar de um bate-papo, um programa de rede conhecido como cliente IRC, conectando-se a um servidor, é necessário para acessar um canal. O cliente IRC pode ser um programa independente no computador local (mIRC e XChat, por exemplo) ou assumir a forma de uma interface de usuário especial de dentro de um programa maior, como um navegador de Internet. Por exemplo, o navegador Opera inclui um cliente IRC e clientes como o Mibbit, o IRCCloud, o KiwiIRC e o The Lounge Chat do MIT podem funcionar em conexão com muitos navegadores populares.

Uma rede IRC de servidores interconectados que operam como estações de retransmissão é usada para mediar as chamadas no IRC. O recurso essencial desta rede é sua topologia de comunicação BITNET, que permite apenas um caminho de comunicação entre dois participantes. Historicamente, isso garantiu comunicação eficiente porque, nos primeiros dias do IRC, as linhas intercontinentais de dados tinham uma capacidade muito limitada. A topologia permitiu que mensagens de um cliente em um continente não fossem enviadas individualmente para cada cliente em outro continente mas apenas uma vez para um servidor local que então as distribui para os clientes. Apesar das capacidades de gerenciamento limitadas, foram possíveis "paisagens de bate-papo". A desvantagem é a falta de redundância, que se manifesta nos chamados net splits: se algum servidor falha, a rede divide automaticamente as peças separadas até que uma nova conexão seja estabelecida entre as partes.

As maiores redes IRC consistem em várias dezenas de servidores IRC que conectam simultaneamente mais de 100.000 usuários e gerenciam dezenas de milhares de canais em que milhares de pessoas podem participar simultaneamente. Apesar dessas enormes proporções, o atraso em um texto enviado é na ordem de décimos de segundo e raramente excede o tempo de um segundo.

A utilização do IRC vem, desde 2003, diminuindo constantemente. Os números apontam uma perda de 60% dos usuários (de 1 milhão em 2003 para cerca de 400 mil em 2021) e mais de metade dos canais (de meio milhão em 2003 para menos de 200 mil em 2021). Em abril de 2011, hospedando centenas de milhares de canais e operando em um total de aproximadamente 1.500 servidores (além de aproximadamente 3.200 servidores IRC em todo o mundo),[2] as 100 principais redes IRC serviam mais de meio milhão de usuários.[3] Em junho de 2021, existiam 481 diferentes redes IRC conhecidas por estarem operando.[4] Dentre tais redes, a Libera Chat de código aberto (fundada em maio de 2021) tem a maioria dos usuários, com 21.348 canais em 15.433 servidores. Também entre elas, as 100 melhores compartilhavam 188.336 canais operando em 96.708 servidores.[5]

Do ponto de vista técnico, o Internet relay chat é implementado como um protocolo de camada de aplicação para facilitar a comunicação na forma de texto. O processo de chat funciona em um modelo de rede cliente-servidor. Conforme já discutido, os clientes IRC podem ser programas de computador autônomos ou aplicativos baseados na web executados localmente no navegador ou em um servidor de terceiros. Esses clientes se comunicam com servidores de chat para transferir mensagens para outros clientes.[6] O IRC é projetado principalmente para comunicação em grupo (em fóruns de discussões chamados de canais)[7] mas também permite comunicação um-para-um por meio de mensagens privadas,[8] bem como bate-papo e transferência de dados[9] (incluindo compartilhamento de arquivos).[10]

O software cliente está disponível para todos os principais sistemas operacionais que oferecem suporte ao acesso à Internet.[11]

História

O IRC foi criado por Jarkko Oikarinen em agosto de 1988 para substituir um programa chamado MUT (MultiUser Talk) em um BBS chamado OuluBox na Universidade de Oulu na Finlândia, onde ele trabalhava no departamento de ciência de processamento de informação. Jarkko pretendia estender o software BBS que administrava, para permitir notícias no estilo Usenet, discussões em tempo real e recursos BBS semelhantes. A primeira parte que ele implementou foi a parte do chat, que ele fez com partes emprestadas escritas por seus amigos Jyrki Kuoppala e Jukka Pihl. A primeira rede IRC estava rodando em um único servidor chamado tolsun.oulu.fi.[12] Oikarinen encontrou inspiração em um sistema de bate-papo conhecido como Bitnet Relay, que operava na BITNET.[13]

Jyrki Kuoppala pressionou Oikarinen para pedir à Universidade de Oulu que liberasse o código do IRC para que ele também pudesse ser executado fora de Oulu e, depois que eles finalmente o liberaram, Jyrki Kuoppala imediatamente instalou outro servidor. Esta foi a primeira "rede IRC". Oikarinen conseguiu que alguns amigos da Universidade de Helsinque e da Universidade de Tampere começassem a rodar servidores IRC quando seu número de usuários aumentou e outras universidades o seguiram. Nesse momento, Oikarinen percebeu que o restante dos recursos do BBS provavelmente não caberiam em seu programa.[12]

Oikarinen entrou em contato com pessoas da Universidade de Denver e da Universidade do Estado de Oregon. Eles tinham sua própria rede IRC funcionando e queriam se conectar à rede finlandesa. Eles haviam obtido o programa de um dos amigos de Oikarinen, Vijay Subramaniam (a primeira pessoa não finlandesa a usar o IRC). O IRC cresceu , foi usado em toda a rede nacional finlandesa (Funet) e então conectado à NORDUnet, a ramificação escandinava da Internet. Em novembro de 1988, o IRC se espalhou pela Internet e, em meados de 1989, haviam cerca de 40 servidores em todo o mundo.[12]

EFnet

Em agosto de 1990, o primeiro grande desacordo ocorreu no mundo IRC. A "A-net" (rede anarquia) incluía um servidor chamado eris.berkeley.edu. Estava tudo aberto, não exigia senhas e não tinha limite para o número de conexões. Como Greg "wumpus" Lindahl explica: "ela tinha uma linha de servidor curinga, então as pessoas estavam conectando servidores e colidindo com todo mundo". A "Rede Livre Eris" (EFnet) fez a máquina eris ser a primeira do IRC a ser alinhada como Q (Q para quarentena). Nas palavras de wumpus novamente: "Eris se recusou a remover essa linha, então formei a EFnet. Não foi muito difícil, consegui todos os hubs para entrar e quase todo mundo foi levado junto." A A-net foi formada com os servidores eris, enquanto a EFnet foi formada com os servidores não-eris. A história mostra que a maioria dos servidores e usuários usam a EFnet. Assim que a A-net se desfez, o nome EFnet perdeu o sentido e mais uma vez existia uma única rede IRC.[12]

Naquela época, o IRC foi usado para relatar a tentativa de golpe de Estado na União Soviética em 1991 durante um apagão da mídia.[14] Anteriormente, ele havia sido usado de forma semelhante durante a Guerra do Golfo.[15] Registros de bate-papo desses e de outros eventos são mantidos no arquivo ibiblio.[16]

Bifurcação Undernet

Outra tentativa de bifurcação, a primeira que realmente fez uma grande e duradoura diferença, foi iniciada por "Wildthang" nos Estados Unidos da América em outubro de 1992 (saiu da EFnet ircd versão 2.8.10). Era para ser apenas uma rede de teste para desenvolver bots, mas rapidamente cresceu para uma rede "para amigos e seus amigos". Na Europa e no Canadá uma nova rede separada estava sendo trabalhada e em dezembro os servidores franceses se conectaram aos canadenses. No final do mês, as redes francesa e canadense foram conectadas à dos Estados Unidos da América, formando a que mais tarde veio a ser chamada de "a Undernet".[12]

Os "undernetters" queriam levar o ircd mais longe, na tentativa de torná-lo menos consumidor de largura de banda e tentar resolver o caos de canais (netsplits e takeovers) que a EFnet começou a sofrer. Para o último propósito, a Undernet implementou timestamps, novo roteamento e ofereceu o CService (um programa que permitia aos usuários registrar canais e então tentava protegê-los de criadores de problemas). A primeira lista de servidores apresentada, de 15 de fevereiro de 1993, incluia os servidores dos Estados Unidos da América, do Canadá, da França, da Croácia e do Japão. Em 15 de agosto, o novo registro de contagem de usuários foi estabelecido para 57 usuários.[12]

Em maio de 1993, a RFC 1459[6] foi publicada e detalhou um protocolo simples para operações de clientes, servidores, canais, conversas um para um e um para muitos.[12] É notável que um número significativo de extensões como o CTCP, as cores, os formatos e a codificação de caracteres[17] não estavam incluídas nas especificações do protocolo e isso levou várias implementações de servidores e clientes à divergências. Na verdade, a implementação do software variava significativamente de uma rede para outra e cada uma delas implementava suas próprias políticas e seus próprios padrões em suas próprias bases de código.

Bifurcação DALnet

Durante o verão de 1994 a Undernet foi bifurcada e a nova rede, formada para melhor serviço de usuário e mais proteções de usuários e canais, foi chamada de DALnet. Uma das alterações mais significativas nessa nova rede, foi o uso de apelidos mais longos (o limite original do ircd sendo 9 letras). As modificações no ircd foram feitas por Alexei "Lefler" Kosut e a DALnet foi, portanto, baseada no servidor ircd da Undernet (embora os pioneiros da DALnet fossem pessoas que deixaram a EFnet). De acordo com James Ng, os pioneiros da DALnet foram "ops do canal #startrek que estavam cansados de constantes divisões (splits), colisões, atrasos (lags), aquisições (takeovers) e etc".[12]

A DALnet prontamente ofereceu:

  • WallOps globais - mensagens de IRCops que podem ser vistas por usuários que são +w,
  • apelidos mais longos,
  • apelidos "alinhados com Q" - apelidos que não podem ser usados (como ChanServ, IRCop e NickServ, por exemplo),
  • "linhas K" globais - para banir uma pessoa ou um domínio inteiro de um servidor ou de toda a rede e
  • comunicações somente de IRCops:
    • GlobOps,
    • modo +H mostrando que um IRCop é um "helpop" e etc.

Muitas das novas funções da DALnet foram escritas por Brian "Morpher" Smith, no início de 1995, e permitem que os usuários possuam apelidos, controlem canais, enviem memorandos e mais.[12]

Bifurcação IRCnet

Em julho de 1996, após meses de guerras inflamadas e discussões em listas de e-mails, houve outra divisão devido ao desacordo sobre como deveria evoluir o desenvolvimento do ircd. Mais notavelmente, o lado "europeu" (a maioria desses servidores estavam na Europa) que mais tarde se autodenominou IRCnet argumentou sobre atrasos de nick e canal, enquanto o lado EFnet argumentou sobre os timestamps.[12] Também haviam desacordos sobre as políticas: o lado europeu havia começado a estabelecer um conjunto de regras que direcionavam o que os IRCops podiam e não podiam fazer e o lado americano se opôs à tal ponto de vista.[18]

A maioria (não todos) dos servidores IRCnet estavam na Europa e a maioria dos servidores EFnet estavam nos Estados Unidos da América. Este evento também é conhecido como "a grande divisão" em muitas sociedades IRC. A EFnet, desde então (em agosto de 1998), cresceu e ultrapassou o número de usuários que tinha na época. No outono (do norte) de 2000, a EFnet tinha cerca de 50.000 e a IRCnet tinha cerca de 70.000.[12]

IRC moderno

O IRC mudou muito ao longo de sua vida na Internet. O novo software de servidor adicionou uma infinidade de novos recursos.

  • Serviços: bots operados em rede para facilitar o registro de apelidos e canais, envio de mensagens para usuários offline e funções de operador de rede.
  • Modos extras: Enquanto o sistema IRC original usava um conjunto de modos de usuário e canal padrão, novos servidores adicionam muitos novos modos para recursos como a remoção de códigos de cores do texto,[19] ou obscurecimento da máscara de host de um usuário ("camuflagem") para proteção contra ataques de negação de serviço.[20]
  • Detecção de proxy: a maioria dos servidores modernos oferece suporte à detecção de usuários que tentam se conectar por meio de um servidor proxy inseguro (mal configurado ou explorado), que pode ter a conexão negada. Este software de detecção de proxy é usado por várias redes, embora a lista de proxies em tempo real esteja extinta desde o início de 2006.[21]
  • Comandos adicionais: novos comandos podem ser coisas como comandos abreviados para emitir comandos para serviços. Para comandos de operador de rede manipular a máscara de host de um usuário.
  • Encriptação: para o trecho cliente-servidor da conexão, o TLS pode ser usado (as mensagens deixam de ser seguras quando são retransmitidas para outros usuários em conexões padrão, mas dificulta a espionagem ou a "escuta" de sessões IRC de um indivíduo). Para a comunicação cliente a cliente, o cliente a cliente direto seguro (SDCC) pode ser usado.
  • Protocolo de conexão: é possível conectar-se ao IRC via IPv4, a versão antiga do protocolo de Internet, ou via IPv6, o padrão atual do protocolo.
  • Desde 2016, um novo esforço de padronização está em andamento em um grupo de trabalho chamado IRCv3 (que se concentra em recursos mais avançados de cliente, como notificações instantâneas, melhor suporte de histórico e segurança aprimorada).[22] Em 2019, nenhuma grande rede IRC havia adotado totalmente o padrão proposto.[23]

Após sua era de ouro durante a década de 1990 e início de 2000 (240.000 usuários na QuakeNet em 2004), o IRC teve um declínio significativo. Perdeu cerca de 60% dos usuários entre 2003 e 2012, os usuários mudaram para plataformas de mídia social mais recentes (como o Facebook ou o Twitter) e também abriram plataformas como o XMPP (desenvolvido em 1999). Certas redes, como a Freenode, não seguiram a tendência geral e mais do que quadruplicaram de tamanho durante o mesmo período. No entanto, a Freenode (que em 2016 tinha cerca de 90.000 usuários) desde então diminuiu para cerca de 65.000 usuários.[24]

As maiores redes de IRC têm sido tradicionalmente agrupadas como as "quatro grandes (big four)",[25][26][27][28] uma designação para redes que encabeçam as estatísticas. As quatro grandes redes mudam periodicamente, mas devido à natureza comunitária do IRC, há um grande número de outras redes para os usuários escolherem.

Historicamente, as "quatro grandes" eram:[25][26][27]

O IRC atingiu 6 milhões de usuários simultâneos em 2001, 10 milhões de usuários em 2003 e caiu para 371 mil em 2018.[carece de fontes?]

Em outubro de 2018, as maiores redes de IRC são:

  • freenode - cerca de 90 mil usuários nos horários de pico,
  • IRCnet - cerca de 30 mil usuários nas horas de pico,
  • EFnet - cerca de 18 mil usuários em horários de pico,
  • Undernet - cerca de 17 mil usuários nos horários de pico,
  • QuakeNet - cerca de 15 mil usuários em horários de pico,
  • Rizon - cerca de 14 mil usuários nos horários de pico,
  • OFTC - cerca de 13 mil usuários nos horários de pico e
  • DALnet - cerca de 8 mil usuários nos horários de pico.

Hoje, as 100 principais redes IRC têm cerca de aproximadamente 370 mil usuários conectados nos horários de pico.[29]

Linha do tempo

Linha do tempo dos principais servidores:

  • EFnet - de 1990 até o presente,
  • Undernet - de 1992 até o presente,
  • DALnet - de 1994 até o presente,
  • freenode - 1995 até o presente,
  • IRCnet - de 1996 até o presente,
  • QuakeNet - de 1997 até o presente
  • Comunidade de tecnologia aberta e livre - de 2001 até o presente,
  • Rizon - de 2002 até o presente e
  • Libera Chat - de 2021 até o presente.

Informação técnica

Uma captura de tela do HexChat, um cliente IRC para ambientes GTK.
Xaric, um cliente IRC baseado em texto, em uso no Mac OS X. São mostrados dois canais de IRC e uma conversa privada com o autor do software.

O IRC é um protocolo aberto que usa TCP[30] e, opcionalmente, TLS. Um servidor IRC pode se conectar a outros servidores IRC para expandir a rede IRC.[31] Os usuários acessam redes IRC conectando um cliente a um servidor.[32] Existem muitas implementações de cliente (como mIRC, HexChat e irssi) e implementações de servidor (por exemplo, o IRCd original). A maioria dos servidores IRC não exige que os usuários registrem uma conta, mas um apelido é necessário antes de se conectar.[33]

O IRC era originalmente um protocolo de texto simples[30] (embora posteriormente estendido) que, a pedido, foi atribuído a porta TCP 194 pela IANA.[34] No entanto, o padrão de fato sempre foi executar o IRC em TCP 6667[35] e números de porta próximos (por exemplo, portas TCP 6660-6669 e 7000)[36] para evitar ter que executar o software IRCd com privilégios de root.

O protocolo especificava que os caracteres eram de 8 bits, mas não especificava a codificação de caracteres que o texto deveria usar.[17] Isso pode causar problemas quando os usuários que usam clientes e (ou) plataformas diferentes desejam conversar.

Todos os protocolos IRC (cliente pra servidor) em uso hoje descendem do protocolo implementado na versão irc 2.4.0 do servidor IRC2 e documentado na RFC 1459. Desde a publicação da RFC 1459, os novos recursos na implementação do irc 2.10 levaram à publicação de vários documentos de protocolo revisados (RFC 2810, RFC 2811, RFC 2812 e RFC 2813). No entanto, essas alterações de protocolo não foram amplamente adotadas entre outras implementações.

Embora muitas especificações sobre o protocolo IRC tenham sido publicadas, não há uma especificação oficial, pois o protocolo permanece dinâmico. Praticamente nenhum cliente e muito poucos servidores confiam estritamente nas RFCs acima como referência.

A Microsoft fez uma extensão para o IRC em 1998 através do proprietário IRCX.[37] Posteriormente, eles pararam de distribuir software que suportasse o IRCX e desenvolveram o proprietário MSNP.

A estrutura padrão de uma rede de servidores IRC é uma árvore.[38] As mensagens são encaminhadas apenas para os ramos necessários da árvore, mas o estado da rede é enviado para cada servidor[39] e geralmente há um alto grau de confiança implícita entre os servidores. Essa arquitetura tem, no entanto, vários problemas. Um servidor mal-intencionado ou com comportamento inadequado pode causar grandes danos à rede[40] e quaisquer mudanças na estrutura, sejam intencionais ou resultado de condições na rede subjacente, requerem uma divisão de rede e junção de rede. Isso resulta em muito tráfego de rede, falsas mensagens (de entrada saída) para os usuários[41] e perda temporária de comunicação com os usuários nos servidores de divisão. Adicionar um servidor a uma grande rede significa uma grande carga de largura de banda em segundo plano na rede e uma grande carga de memória no servidor. Uma vez estabelecida, no entanto, cada mensagem para vários destinatários é entregue de maneira semelhante a multicast, o que significa que cada mensagem viaja por um link de rede exatamente uma vez.[42] Isso é um ponto forte em comparação aos protocolos 'não multicast', como o Simple Mail Transfer Protocol (SMTP) ou o Extensible Messaging and Presence Protocol (XMPP).

Um daemon IRC também pode ser usado em uma rede local (LAN). O IRC pode, portanto, ser usado para facilitar a comunicação entre as pessoas dentro da rede local (comunicação interna).[43][44]

Comandos e respostas

Ver artigo principal: Lista de comandos IRC

O IRC tem uma estrutura baseada em linha. Os clientes enviam mensagens de linha única para o servidor[45] recebem respostas para essas mensagens[46] e cópias de algumas mensagens enviadas por outros clientes. Na maioria dos clientes, os usuários podem inserir comandos prefixando-os com '/'. Dependendo do comando, eles podem ser manipulados inteiramente pelo cliente ou, geralmente para comandos que o cliente não reconhece, passados diretamente para o servidor (possivelmente com alguma modificação).

Devido à natureza do protocolo, os sistemas automatizados nem sempre emparelham corretamente um comando enviado com sua resposta com total confiabilidade e estão sujeitos a adivinhação.[47]

Canal

O meio básico de comunicação com um grupo de usuários em uma sessão de IRC estabelecida é através de um canal.[48] Canais em uma rede podem ser exibidos usando o comando LIST,[49] que lista todos os canais atualmente disponíveis que não têm os modos +s ou +p definidos nessa rede específica.

Os usuários podem ingressar em um canal usando o comando JOIN,[50] disponível na maioria dos clientes como /join #nome do canal. As mensagens enviadas aos canais associados são, então, retransmitidas à todos os outros usuários.[48]

Os canais que estão disponíveis em uma rede IRC inteira são prefixados com um '#', enquanto aqueles locais para um servidor usam '&'.[51] Outros tipos de canais menos comuns incluem canais '+' (canais modeless, sem operadores)[52] e canais '!' (uma forma de canal timestamped em redes normalmente sem timestamped.[53]

Modos

Usuários e canais podem ter "modos" que são representados por letras simples, que diferenciam maiúsculas de minúsculas[54] e são configurados usando o comando MODE.[55] Modos de usuário e modos de canal são separados e podem usar a mesma letra para significar coisas diferentes (por exemplo, o modo de usuário "i" é o modo invisível, enquanto o modo de canal "i" é o que define que apenas convidados podem ingressar no canal.[56]) Os modos são, geralmente, configurados ou não configurados usando o comando de modo que pega um alvo (usuário ou canal), um conjunto de modos para configurar (+) ou desconfigurar (-) e quaisquer parâmetros que os modos precisem.

Alguns modos de canal usam parâmetros e outros modos de canal se aplicam à um usuário em um canal ou adicionam ou removem uma máscara (por exemplo, uma máscara de proibição) de uma lista associada ao canal em vez de aplicar ao canal como um todo.[57] Os modos que se aplicam à usuários em um canal têm um símbolo associado que é usado para representar o modo nas respostas de nomes[58] (enviada aos clientes na primeira entrada em um canal[50] e no uso dos comandos de nomes) e, em muitos clientes, é usado também para representá-los na lista de usuários exibida pelo cliente em um canal ou para exibir um indicador próprio para os modos de um usuário.

A fim de analisar corretamente as mensagens do modo de entrada e rastrear o estado do canal, o cliente deve saber qual modo é de qual tipo e, para os modos que se aplicam a um usuário em um canal, qual símbolo vai com qual letra. Nas primeiras implementações do IRC, isso tinha que ser codificado no cliente. Mas agora, existe uma extensão padrão de fato para o protocolo chamado ISUPPORT que envia essas informações ao cliente no momento da conexão usando o 005 numérico.[59][60]

Há uma pequena falha de design no IRC em relação aos modos que se aplicam aos usuários nos canais: a mensagem de nomes usada para estabelecer o estado inicial do canal pode enviar apenas um modo por usuário no canal[58] mas vários desses modos podem ser definidos em um único usuário. Por exemplo, se um usuário mantém o status de operador (+o) e o status de voz (+v) em um canal, um novo cliente não será capaz de ver o modo com menos prioridade (ou seja, o de voz). Soluções alternativas para isso são possíveis no lado do cliente e do servidor mas nenhuma é amplamente implementada.

Modos do padrão (RFC 1459)

Modos de usuário
Letra Símbolo Descrição
i Invisível (não pode ser visto sem um canal comum ou sem saber o nome exato).
s Recebe avisos do servidor.
w Recebe wallops.[61]
o O usuário é um operador de IRC (ircop).
Modos de canal
Letra Símbolo Parâmetro(s) Descrição
o @ Nome do usuário afetado Operador de canal (pode alterar os modos do canal e expulsar usuários do canal, entre outras coisas).
s Canal secreto (não mostrado na lista de canais ou whois de usuário, exceto para usuários que já estão no canal).
p Canal privado (listado na lista de canais como prv de acordo com RFC 1459).
n Os usuários não podem enviar mensagens para o canal externamente.
m O canal é moderado (apenas aqueles que possuem status de operador de canal ou status de voz no canal podem enviar mensagens para ele).
i Apenas usuários com convites podem entrar no canal.
t Apenas operadores de canal podem mudar o tópico do canal.
l Número limite Limita o número de usuários que podem estar no canal (quando cheio, nenhum novo usuário pode entrar).
b Máscara de proibição (apelido!usuário@host com caracteres curinga permitidos) Bane máscaras de hosts do canal.
v + Nome do usuário afetado Concede status de voz ao usuário no canal (veja +m acima).
k Nova chave de canal Define uma chave de canal de forma que somente usuários que conheçam a chave possam entrar.

Muitos daemons e redes adicionaram modos extras ou modificaram o comportamento dos modos na lista acima.[62][63][64][65]

Operadores de canal

Um operador de canal é um cliente em um canal IRC que gerencia o canal. Operadores de canal de IRC podem ser facilmente vistos por um símbolo ou ícone próximo ao seu nome (varia de acordo com a implementação do cliente, normalmente um prefixo de símbolo "@", um círculo verde ou uma letra latina "+o" ou "o"). Na maioria das redes, um operador pode:

  • Chutar(expulsar) um usuário.
  • Banir um usuário.
  • Conceder a outro usuário o status de operador ou voz do canal IRC.
  • Alterar o tópico do canal IRC enquanto o modo de canal +t estiver definido.
  • Alterar os bloqueios do modo de canal IRC.

Operadores IRC

Também há usuários que mantêm direitos elevados em seu servidor local ou em toda a rede, são chamados de operadores IRC[66] e, às vezes, abreviados para IRCops ou Opers (não devem ser confundidos com operadores de canal). Como a implementação do IRCd varia, também variam os privilégios do operador de IRC no IRCd fornecido. A RFC 1459[66] afirma que os operadores de IRC são "um mal necessário" para manter um estado limpo da rede e, como tal, precisam ser capazes de desconectar e reconectar servidores. Além disso, para evitar que usuários mal-intencionados ou mesmo programas automatizados prejudiciais entrem no IRC, os operadores de IRC geralmente têm permissão para desconectar clientes e proibir completamente endereços IP ou sub-redes completas. Redes que transportam serviços geralmente permitem que seus operadores de IRC lidem com questões básicas de "propriedade" também. Outros direitos privilegiados podem incluir a anulação de proibições (ser capaz de entrar em canais que não teriam permissão para entrar se não fossem operadores), se promover a operador (sem ser operador do canal), auto-op e etc.

Máscara de host

Uma máscara de host é um identificador único de um cliente IRC conectado à um servidor IRC.[67][68] Servidores, serviços e outros clientes (incluindo bots) IRC podem usá-la para identificar uma sessão de IRC específica.

O formato de uma máscara de host é apelido!usuário@host. A máscara de host é semelhante, mas não deve ser confundida com, um endereço de e-mail.

A parte do apelido é o apelido escolhido pelo usuário e pode ser alterado durante a conexão. A parte do usuário é o nome de usuário relatado pelo protocolo ident no cliente.[69] Se o ident não estiver disponível no cliente, o nome de usuário especificado quando o cliente conectou-se é usado após ser prefixado com um til.[70]

A parte do host é o hostname do qual o cliente está se conectando. Se o endereço ''IP'' do cliente não puder ser resolvido para um hostname válido pelo servidor, ele (o endereço de IP) será usado em vez do nome do host.

Devido às implicações de privacidade de expor o endereço IP ou o nome de host de um cliente, alguns daemons IRC também fornecem recursos de privacidade como o InspIRCD ou o modo "+ x" do UnrealIRCd. Isto criptografa um endereço de IP do cliente ou mascara parte do nome do host de um cliente (tornando-o ilegível para usuários que não sejam IRCops). Os usuários também podem ter a opção de solicitar um "host virtual" (ou "vhost"), exibido na máscara de host para permitir maior anonimato. Algumas redes IRC, como a Freenode, os usam como "disfarces" para indicar que um usuário é afiliado a um grupo ou projeto.[71]

Esquema URI

Existem três esquemas URI reconhecidos para o IRC: irc, ircs, e irc6.[72] Quando suportados, eles permitem ligações de várias formas, incluindo: irc://<host>[:<porta>]/[<canal>[?<senha do canal>]] ircs://<host>[:<porta>]/[<canal>[?<senha do canal>]] irc6://<host>[:<porta>]/[<canal>[?<senha do canal>]] Os itens entre colchetes são opcionais para serem usados (se necessário) para se conectar ao host especificado (ou rede, se conhecido do cliente IRC) e ingressar no canal especificado.[73] Isso pode ser usado no próprio cliente ou em outro aplicativo (como um navegador da web). O URI padrão é irc. O irc6 especifica uma conexão a ser feita usando IPv6 e o ircs especifica uma conexão segura.

De acordo com a especificação, o usual símbolo hash (#) prefixado em nomes de canais que começam com um caractere alfanumérico permite que eles sejam omitidos. Algumas implementações (por exemplo, mIRC) farão isso "incondicionalmente", resultando em um (geralmente não intencional) extra (por exemplo, canal ##), se incluído na URL.

Algumas implementações permitem que vários canais sejam especificados (separados por vírgulas).[74]

Desafios

Os problemas no design original do IRC eram a quantidade de dados de estado compartilhados[75][76] sendo uma limitação em sua escalabilidade,[77] a ausência de identificações de usuário exclusivas levando ao problema de colisão de apelidos,[78] falta de proteção de divisões de redes por meio de roteamento cíclico,[79][80] a compensação em escalabilidade por causa das informações de presença do usuário em tempo real,[81] fraquezas do protocolo fornecendo uma plataforma para mau uso,[82] nenhuma passagem de mensagem transparente e otimizável[83] e ausência de criptografia.[84] Algumas dessas questões foram tratadas no "IRC moderno".

Ataques

Como as conexões IRC podem não ser criptografadas e normalmente se estendem por longos períodos, elas são um alvo atraente para ataques DoS/DDoS e hackers. Por causa disso, uma política de segurança cuidadosa é necessária para garantir que uma rede IRC não seja suscetível à um ataque como uma guerra para assumir o controle. As redes IRC também podem listar em "linha K" ou "linha G" usuários ou servidores que tenham um efeito prejudicial.

Alguns servidores IRC suportam conexões SSL/TLS para fins de segurança. Isso ajuda a interromper o uso de programas analisadores de pacotes para obter as senhas de usuários de IRC, mas tem pouco uso além desse escopo devido à natureza pública dos canais de IRC. As conexões SSL requerem suporte ao cliente e ao servidor (que pode exigir que o usuário instale binários SSL e patches ou módulos específicos do cliente IRC em seus computadores). Algumas redes também usam SSL para conexões servidor a servidor e fornecem um sinalizador de canal especial (como +S) para permitir apenas usuários conectados por SSL no canal, enquanto proíbe a identificação do operador em texto não criptografado, para melhor utilizar as vantagens que o SSL oferece.[85][86]

O IRC serviu como um primeiro laboratório para muitos tipos de ataques na internet, como o uso de inacessíveis falsas mensagens ICMP para quebrar as conexões IRC baseadas no TCP (nuking) para incomodar os usuários ou facilitar assumir o controle (takeover).

Prevenção de mau uso

Uma das questões técnicas mais controversas em torno das implementações de IRC, que sobrevive até hoje, é o mérito dos protocolos "nick/channel delay vs. timestamp". Ambos os métodos existem para resolver o problema de ataques de negação de serviço, mas têm abordagens muito diferentes. O problema com o protocolo IRC original implementado era que, quando dois servidores se dividiam e se juntavam, os dois lados da rede simplesmente fundiam seus canais. Se um usuário entrarasse em um servidor "dividido", em um canal (que existia do outro lado da rede) vazio e obtesse o status de operador, ele se tornaria um operador de canal do canal "combinado" após o término do netsplit. Se um usuário pegasse um apelido que existia do outro lado da rede, o servidor "mataria" os dois usuários ao reingressarem (ou seja, "colisão de apelidos"). Isso era freqüentemente usado para "matar em massa" todos os usuários em um canal, criando canais "opless" (onde nenhum operador estava presente para lidar com o mau uso). Além de causar problemas dentro do IRC, isso encorajou as pessoas à conduzirem ataques de negação de serviço contra servidores IRC para causar netsplits (dos quais elas, então, se aproveitariam para mau uso).

Predefinição:Anchor

As estratégias de nick delay e channel delay visam prevenir mau uso (atrasando reconexões e renomeações). Depois que um usuário termina a sessão e o apelido fica disponível, ou um canal deixa de existir porque todos os seus usuários partiram (como freqüentemente acontece durante uma divisão de rede), o servidor não permite que usuário algum use aquele apelido ou entre naquele canal, até que um certo período de tempo (o "atraso") tenha passado. A ideia por trás disso é que, mesmo que ocorra uma divisão de rede, é inútil para os usuários "mal-intencionados" porque eles não podem pegar o apelido ou obter status de operador em um canal por meio da vulnerabilidade anteriormente mencionada (portanto, a colisão de um apelido ou a "fusão" de um canal não pode acontecer). Até certo ponto, isso é inconveniente para os usuários legítimos, que podem ser "forçados (ou induzidos)" à usar, brevemente, um nome (apelido) diferente após o retorno (anexar um sublinhado é prática comum nesses casos).

O protocolo timestamp é uma alternativa, aos atrasos de apelido/canal, que resolve colisões usando a prioridade de timestamp. Cada apelido e canal na rede são atribuídos à um timestamp com a data e a hora em que foram criados. Quando ocorre um netsplit, dois usuários de cada lado são livres para usar o mesmo apelido ou canal, mas quando os dois lados são unidos, apenas um pode "sobreviver". No caso de apelidos, o usuário mais novo, de acordo com seu timestamp, é "morto". Quando um canal colide, os membros (usuários no canal) são mesclados, mas os operadores de canal no lado "perdedor" da divisão perdem seu status de operador de canal.

O TS (timestamp) é um protocolo muito mais complicado do que o ND (nick delay)/CD (channel delay), tanto em design como em implementação. Apesar de ter passado por várias revisões, algumas implementações ainda têm problemas com "dessincronização" (onde dois servidores na mesma rede discordam sobre o estado atual da rede), permitindo muita clemência no que seria permitido pelo lado "perdedor". Sob os protocolos TS originais, por exemplo, não havia proteção contra usuários definindo banimentos ou outros modos no canal perdedor (que seriam então mesclados na fusão quando a divisão (netsplit) terminasse, mesmo que os usuários que configuraram esses modos perdessem seus status de operador de canal). Alguns servidores IRC modernos baseados em TS também incorporaram alguma forma de ND/CD, além da marcação de tempo, em uma tentativa de conter ainda mais o mau uso.

A maioria das redes hoje usa a abordagem de carimbo de data/hora. Os desacordos de "TS versus ND/CD" fizeram com que vários servidores se separassem da EFnet e formassem os mais novos IRCnets. Após a divisão, a EFnet mudou para um protocolo TS, enquanto a IRCnet optou pelo ND/CD.

Em versões recentes do ircd IRCnet, bem como ircds usando o protocolo TS6 (incluindo Charybdis), o ND foi estendido/substituído por um mecanismo chamado SAVE. Este mecanismo atribui um identificador exclusivo à cada cliente (ao se conectar à um servidor IRC). Este ID começa com um número, é proibido em apelidos (nicknames) (embora alguns ircds, nomeadamente IRCnet e InspIRCd, permitam que os clientes usem o próprio UID como apelido).

Se dois clientes com o mesmo apelido se juntam de lados diferentes de um netsplit ("colisão de apelidos"), o primeiro servidor a ver esta colisão "força ambos" os clientes à mudarem seu apelido (nickname) para seu UID( evitando assim que ambos os clientes sejam desconectados). Na IRCnet, o apelido também ficará bloqueado por algum tempo (ND) para evitar que ambos os clientes voltem ao apelido original, colidindo novamente.

Clientes

Software cliente

O software cliente existe para vários sistemas operacionais ou pacotes de software, bem como jogos baseados na web ou internos. Muitos clientes diferentes estão disponíveis para os vários sistemas operacionais, incluindo Windows, Unix e Linux, Mac OS X e sistemas operacionais móveis (tais como iOS e Android). No Windows, mIRC é um dos clientes mais populares.[87]

Alguns programas extensíveis através de plug-ins também servem como plataformas para clientes IRC. Por exemplo, um cliente chamado ERC, escrito inteiramente em Emacs Lisp, está incluído na versão 22.3 do Emacs. Portanto, qualquer plataforma que pode executar o Emacs pode executar o ERC.

Vários navegadores têm clientes IRC integrados (como o Opera versões 12.18 e anteriores[88] e o complemento ChatZilla para Mozilla Firefox (56 e anteriores) incluído como um componente integrado do SeaMonkey). Clientes baseados na Web, como Mibbit e KiwiIRC de código aberto, podem ser executados na maioria dos navegadores.

Jogos como War§ow,[89] Unreal tournament (até o Unreal tournament 2004),[90] Uplink,[91] jogos baseados em Spring engine, 0 A.D. e ZDaemon têm o IRC incluído.[92]

A interface de chat do Ustream é IRC com autenticação personalizada,[93] bem como a do Twitch (anteriormente Justin.tv).[94][95]

Bots

Ver artigo principal: Robô de IRC

Um uso típico de bots no IRC é o de fornecer serviços ou funcionalidades específicas dentro de um canal, como hospedar um jogo baseado em chat ou fornecer notificações de eventos externos. No entanto, alguns bots IRC são usados para lançar ataques maliciosos, como negação de serviço, spamming ou exploração.[96]

Bouncer

Ver artigo principal: BNC (software)

Um programa que é executado como um daemon em um servidor e funciona como um proxy persistente é conhecido como BNC ou bouncer. O objetivo é manter uma conexão com um servidor IRC, atuando como um retransmissor entre o servidor e o cliente, ou simplesmente atuar como um proxy. Caso o cliente perca a conectividade de rede, o BNC pode permanecer conectado e arquivar todo o tráfego para entrega posterior, permitindo ao usuário retomar sua sessão de IRC sem interromper sua conexão com o servidor.[97]

Além disso, como forma de obter um efeito semelhante ao do bouncer, um cliente IRC, normalmente baseado em texto (como o Irssi por exemplo), pode ser executado em um servidor sempre ativo ao qual o usuário se conecta via SSH. Isso também permite que dispositivos que têm apenas a funcionalidade ssh, mas nenhum cliente de IRC real instalado, se conectem ao IRC e permite o compartilhamento de sessões de IRC.[98]

Para evitar que o cliente IRC feche quando a conexão ssh for fechada, o cliente pode ser executado dentro de um terminal multiplexador, como GNU Screen ou tmux, mantendo-se assim constantemente ligado à(s) rede(s) IRC, podendo registar as conversações nos canais de interesse do utilizador e manter a presença nos canais na rede. Modelado a partir dessa configuração, em 2004 um cliente IRC seguindo o modelo cliente-servidor, chamado Smuxi, foi lançado.[99][100]

Mecanismos de pesquisa

Existem vários motores de busca disponíveis para ajudar o usuário a encontrar o que procura no IRC.[101][102] Geralmente, o mecanismo de pesquisa consiste em duas partes, um "back-end" (ou "spider/crawler") e um "mecanismo de pesquisa" "front-end".

O back-end (spider /webcrawler) é o cavalo de batalha do mecanismo de pesquisa. É responsável por rastrear servidores IRC para indexar as informações enviadas por eles. As informações indexadas, geralmente, consistem apenas no texto do canal (texto que é exibido publicamente em canais públicos).

O "mecanismo de busca" front-end é a interface do usuário para o banco de dados. Ele fornece aos usuários uma maneira de pesquisar o banco de dados de informações indexadas para recuperar os dados que estão procurando. Esses mecanismos de pesquisa front-end também podem ser codificados em várias linguagens de programação.

A maioria dos mecanismos de pesquisa tem seu próprio spider, que é o único aplicativo responsável por rastrear o IRC e indexar os próprios dados; entretanto, outros são indexadores "baseados no usuário". Os últimos contam com os usuários para instalarem seu "complemento" em seu cliente IRC; o add-on é o que envia as informações de canal de quaisquer canais em que o usuário esteja ao banco de dados.

Muitos usuários implementaram seus próprios motores de busca ad hoc usando os recursos de registro embutidos em muitos clientes IRC. Esses mecanismos de pesquisa são geralmente implementados como bots e dedicados a um determinado canal ou grupo de canais associados.

Codificação de caracteres

O IRC ainda carece de uma única convenção padrão globalmente aceita para transmitir caracteres fora do repertório ASCII de 7 bits. Os servidores IRC normalmente transferem mensagens de um cliente para outro cliente como sequências de bytes, sem nenhuma interpretação ou recodificação de caracteres. O protocolo IRC (ao contrário, por exemplo, do MIME ou HTTP) carece de mecanismos para anunciar e negociar opções de codificação de caracteres. Isso colocou a responsabilidade de escolher o codec de caractere apropriado no cliente. Na prática, os canais de IRC têm usado amplamente as mesmas codificações de caracteres que também foram usadas pelos sistemas operacionais (em particular os derivados Unix) nas respectivas comunidades linguísticas:

  • Era de 7 bits: Nos primeiros dias do IRC, especialmente entre os usuários de escandinavo e língua finlandesa, as variantes nacionais de ISO 646 eram dominantes como codificação de caracteres. Estes codificam caracteres (não ASCII) como Ä, Ö, Å, ä, ö, e å nas posições de código 0x5B, 0x5C, 0x5D, 0x7B, 0x7C e 0x7D (ASCII: [, \, ], {, | e }). É por isso que esses códigos são sempre permitidos em apelidos. De acordo com a RFC 1459, "{", "|" e "}" em apelidos devem ser tratados, respectivamente, como equivalente (em minúsculas) de "[", "\" e "]".[17] No final da década de 1990, o uso de codificações de 7 bits desapareceu em favor do ISO 8859-1 e tais mapeamentos de equivalência foram retirados de alguns daemons IRC.
  • Era de 8 bits: Desde o início dos anos 1990, codificações de 8 bits como ISO 8859-1 tornaram-se comumente usadas para idiomas europeus. Os usuários russos podiam escolher KOI8-R, ISO 8859-5 e Windows-1251, e desde cerca de 2000, as redes IRC russas modernas convertem entre essas diferentes codificações comumente usadas do script cirílico.
  • Era multibyte: Por muito tempo, os canais IRC do leste asiático com scripts logográficos na China, Japão e Coreia têm usado codificações multibyte, como EUC ou ISO-2022-JP. Com a migração comum de ISO 8859 para UTF-8 em plataformas Linux e Unix desde cerca de 2002, o UTF-8 tornou-se um substituto cada vez mais popular para muitas das codificações de 8 bits usadas anteriormente em canais europeus. Alguns clientes de IRC agora são capazes de ler mensagens em ISO 8859-1 ou UTF-8 no mesmo canal, detectando heuristicamente qual codificação é usada. A mudança para UTF-8 começou em particular no IRC de língua finlandesa (Merkistö (em finlandês)).

Hoje, a codificação UTF-8 de Unicode/ISO/IEC 10646 seria a candidata mais provável para uma única codificação de caracteres padrão futura para todas as comunicações IRC, se tal padrão já relaxou a restrição de tamanho de mensagem de 510 bytes. O UTF-8 é compatível com o ASCII e cobre o superconjunto de todos os outros conjuntos de caracteres codificados padrões comumente usados.

Compartilhamento de arquivos

Muito parecido com o convencional compartilhamento de arquivos P2P, os usuários podem criar servidores de arquivos que lhes permitem compartilhar arquivos uns com os outros usando bots ou scripts personalizados para seu cliente. Freqüentemente, os usuários se agrupam para distribuir warez por meio de uma rede de bots IRC.[103]

Tecnicamente, o IRC não fornece mecanismos de transferência de arquivo. O compartilhamento de arquivos é implementado pelos "clientes" IRC, normalmente usando o protocolo DCC, no qual as transferências de arquivos são negociadas por meio da troca de mensagens privadas entre clientes. A grande maioria dos clientes de IRC oferece suporte para transferências de arquivos DCC, daí a visão de que o compartilhamento de arquivos é um recurso integral do IRC.[104] O uso comum desse protocolo, entretanto, às vezes também causa spam de DCC. Os comandos DCC também têm sido usados para explorar clientes vulneráveis para executar uma ação, como desconectar do servidor ou sair do cliente.

Ver também

Referências

  1. Jarkko Oikarinen; Darren Reed (maio de 1993). «RFC 1459, Protocolo IRC» (em English). Consultado em 12 de junho de 2021 
  2. «Servidores IRC - sumário» (em English). irc.netsplit.de. Consultado em 21 de julho de 2021. Arquivado do original em 22 de abril de 2011 
  3. «Redes IRC - Top 100» (em English). irc.netsplit.de. Consultado em 21 de julho de 2021 
  4. «Redes IRC - em ordem alfabética». netsplit.de (em English). 2020. Consultado em 21 de julho de 2021 
  5. «Redes IRC - Top 100». netsplit.de. 2020. Consultado em 21 de julho de 2021 
  6. 6,0 6,1 «Protocolo IRC - Introdução § 1» (em English). p. 4. doi:10.17487/RFC1459. Consultado em 21 de julho de 2021 
  7. «Protocolo IRC - Um para muitos § 3.2» (em English). p. 11. doi:10.17487/RFC1459. Consultado em 21 de julho de 2021 
  8. «IRC: Arquitetura - Comunicação um para um § 5.1» (em English). p. 5. doi:10.17487/RFC1459. Consultado em 21 de julho de 2021 
  9. Rollo, Troy. «Descrição do protocolo DCC» (em English). irchelp.org. Consultado em 21 de julho de 2021 
  10. Wang, Wallace (25 de outubro de 2004). «Mensagens instantâneas e salas de chat online: Internet Relay Chat (IRC. Roube este livro de compartilhamento de arquivos (em English) 1ª ed. São Francisco (Califórnia): no starch press. pp. 61 à 67. ISBN 978-1-59327-050-6 
  11. «Canal IRC SAGE» (em English). Sage - Grupo de interesse especial USENIX para administradores de sistemas. Consultado em 21 de julho de 2021. Arquivado do original em 7 de fevereiro de 2012 
  12. 12,00 12,01 12,02 12,03 12,04 12,05 12,06 12,07 12,08 12,09 12,10 Stenberg, Daniel (29 de março de 2011). «História do IRC (Internet relay chat (em English). Consultado em 21 de julho de 2021. Eu não experimentei tudo isso. Encontrei informações em vários lugares e recebi informações de várias pessoas para escrever isto. As pessoas que me ajudaram com isso incluem: Greg "wumpus" Lindahl, Vesa "vesa" Ruokonen, James Ng, Tuomas Heino, Richard (águia na undernet), Ari Lemmke 
  13. Oikarinen, Jarkko. «IRC de fundação» (em English). Consultado em 21 de julho de 2021 
  14. «Transcrições do IRC da época da tentativa de golpe de estado soviético de 1991» (em English). Chapel Hill (Carolina do Norte): ibiblio. Consultado em 21 de julho de 2021. Cópia arquivada em 28 de junho de 2009 
  15. «Registros IRC de eventos da Guerra do Golfo» (em English). Chapel Hill (Carolina do Norte): ibiblio. Consultado em 21 de julho de 2021 
  16. «Registros dos principais eventos na comunidade online» (em English). Chapel Hill (Carolina do Norte): ibiblio. Consultado em 21 de julho de 2021 
  17. 17,0 17,1 17,2 Jarkko Oikarinen; Darren Reed (maio de 1993). «Protocolo IRC - Códigos de caracteres (seção 2.2)» (em English). p. 7. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 25 de julho de 2021 
  18. Engen, Vegard (maio de 2000). «A grande divisão» (em English). irc.org. Consultado em 22 de julho de 2021 
  19. «Modos de canal». Wiki de documentação UnrealIRCd (em English). Consultado em 23 de julho de 2021 
  20. «Camuflagem». Wiki de documentação UnrealIRCd (em English). Consultado em 23 de julho de 2021 
  21. «Monitor aberto de proxy Blitzed» (em English). O monitor aberto de proxy fornecido pela rede IRC Blitzed foi desligado... O banco de dados era tão grande que é quase impossível para a equipe fazer backup ou encontrar um novo local para continuar o serviço. Somado a isso, a maioria dos membros da equipe não tem mais tempo para manter o serviço funcionando. 
  22. «IRCv3» (em English). Grupo de trabalho IRCv3. 2016. Consultado em 24 de julho de 2021. O grupo de trabalho IRCv3 é uma coleção de autores de software cliente e servidor de IRC trabalhando para aprimorar, manter e padronizar o protocolo IRC usando extensões compatíveis com versões anteriores. 
  23. «Redes - IRCv3» (em English). 2019. Consultado em 24 de julho de 2021 
  24. «netsplit.de - Top 10» (em English). Consultado em 24 de julho de 2021 
  25. 25,0 25,1 Charalabidis, Alex (15 de dezembro de 1999). «IRCing no Macintosh: Ircle». O livro do IRC: o guia definitivo para o Internet relay chat 1ª ed. São Francisco, Califórnia: no starch press. p. 61. ISBN 978-1-886411-29-6. Em grandes redes como as quatro grandes (EFnet, IRCnet, Undernet e DALnet) tentar listar os milhares de canais com o Ircle sempre faz com que você se desconecte devido à enxurrada de informações. Enquanto que com outros clientes é possível gerenciar o feito se estiver em uma conexão ethernet direta. 
  26. 26,0 26,1 Jones, Steve, ed. (10 de dezembro de 2002). «Internet relay chat». Enciclopédia de novas mídias: uma referência essencial para comunicação e tecnologia (em English) 1ª ed. Thousand Oaks, Califórnia: Publicações SAGE. p. 257. ISBN 978-0-7619-2382-4. Hoje existem centenas de redes IRC independentes, mas as "quatro grandes" são EFNet, UnderNet, DALnet e IRCnet. 
  27. 27,0 27,1 Rittner, Don (3 de março de 1999). O livro do iMac (em English) 1ª ed. Scottsdale, Arizona: Grupo Coriolis. p. 215. ISBN 978-1-57610-429-3. Existem várias redes grandes: EFnet, UnderNET, DALnet e IRCnet constituem as quatro grandes. 
  28. Turban, Efraim; Leidner, Dorothy; McLean, Ephraim; Wetherbe, James (7 de fevereiro de 2005). «Comunicação». Tecnologia da informação para gestão: transformando as organizações na economia digital (em English) 5ª ed. Hoboken (Nova Jérsei), Nova Jérsei: John Wiley & Sons. pp. 106 e 107. ISBN 978-0-471-70522-2. As maiores redes têm sido tradicionalmente agrupadas como as "quatro grandes": EFNet, IrcNet, QuakeNet e UnderNet. 
  29. «Redes IRC - Top 100». irc.netsplit.de. netsplit.de. Consultado em 25 de julho de 2021 
  30. 30,0 30,1 Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Introduction (section 1)» [Protocolo IRC - Introdução (seção 1)] (em English). IETF. p. 4. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  31. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Server (section 1.1)» [Protocolo IRC - Servidores (seção 1.1)] (em English). IETF. p. 4. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  32. Kalt, C. (abril de 2000). «IRC: Architecture - Clients (section 2.2)» [Arquitetura IRC - Clientes (seção 2.2)] (em English). IETF. p. 3. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 5 de abril de 2021 
  33. Oikarinen, J.; Reed, D. (maio de 2021). «IRC protocol - Clients (section 1.2)» [Protocolo IRC - Clientes (seção 1.2)] (em English). IETF. p. 5. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  34. «Port numbers» [Números de porta] (em English). Marina del Rey, California: Internet Assigned Numbers Authority. 6 de abril de 2011. Consultado em 5 de abril de 2021 
  35. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Connect message (section 4.3.5)» [Protocolo IRC - Mensagem de conexão (seção 4.3.5)] (em English). IETF. p. 29. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  36. Lucas, Mark; Singh, Abhishek; Cantrell, Chris (5 de outubro de 2006). «Defining a firewall - Definindo um firewall». In: Henmi, Anne. Firewall policies and VPN configurations [Políticas de firewall e configurações de VPN] (em English). Rockland, Massachusetts: Syngress Publishing. p. 93. ISBN 978-1-59749-088-7 
  37. Abraham, Dalen (junho de 1998). «Extensions to the IRC protocol» [Extensões para o protocolo IRC] (em English). IETF. Consultado em 6 de abril de 2021 
  38. Kalt, C. (abril de 2000). «IRC: Architecture (section 3)» [IRC : Arquitetura (seção 3)] (em English). IETF. pp. 3 e 4. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  39. Kalt, C. (abril de 2000). «IRC: Architecture - Introduction (section 1)» [IRC : Arquitetura - Introdução (seção 1)] (em English). IETF. p. 2. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  40. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Algorithms (section 9.3)» [Protocolo IRC - Algoritmos (seção 9.3)] (em English). IETF. p. 64. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 6 de abril de 2021 
  41. Kalt, C. (abril de 2000). «IRC: Architecture - Network congestion (section 6.3)» [IRC : Arquitetura - Congestionamento de rede (seção 6.3)] (em English). IETF. pp. 7 e 8. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  42. Kalt, C. (abril de 2000). «IRC: Architecture - To a channel (section 5.2.1)» [IRC : Arquitetura - Pra um canal (seção 5.2.1)] (em English). IETF. pp. 5 e 6. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  43. «IRC daemons for LAN». Consultado em 2 de outubro de 2014 
  44. «Running an own IRC server». Consultado em 2 de outubro de 2014 
  45. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Message format in 'pseudo' BNF (section 2.3.1)» [Protocolo IRC - Formato de mensagem em 'pseudo' BNF (seção 2.3.1)] (em English). IETF. p. 8. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 6 de abril de 2021 
  46. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Numeric replies (section 2.4)» [Protocolo IRC - Respostas numéricas (seção 2.4)] (em English). IETF. p. 10. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 6 de abril de 2021 
  47. Cormack, Shane Mc. «IRC list modes – List mode extension showing pair confusion for lists» [Modos de lista de IRC - extensão do modo de lista mostrando confusão de pares para listas] (em English). Dataforce's blog. Consultado em 15 de abril de 2021 
  48. 48,0 48,1 Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - To a group (channel) (section 3.2.2)» [Protocolo IRC - Para um grupo (canal) (seção 3.2.2)] (em English). IETF. p. 11. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 15 de abril de 2021 
  49. Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - List message (section 4.2.6)» [Protocolo IRC - Mensagem de lista (seção 4.2.6)] (em English). IETF. p. 24. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 15 de abril de 2021 
  50. 50,0 50,1 Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Join message (section 4.2.1)» [Protocolo IRC - Mensagem de adesão (seção 4.2.1)] (em English). IETF. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 16 de abril de 2021 
  51. Kalt, C. (abril de 2000). «IRC: Channel management - Channel scope (section 2.2)» [IRC: Gerenciamento de canal - escopo do canal (seção 2.2)] (em English). IETF. pp. 3 e 4. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  52. Kalt, C. (abril de 2000). «IRC: Channel management - Channel properties (section 2.3)» [IRC: Gerenciamento de canal - Propriedades do canal (seção 2.3)] (em English). IETF. p. 4. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  53. Kalt, C. (abril de 2000). «IRC: Channel management - Channel lifetime (section 3)» [IRC: Gerenciamento de canal - Tempo de vida do canal (seção 3)] (em English). IETF. p. 5. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  54. Kalt, C. (abril de 2000). «IRC: Channel management - Channel modes (section 4)» [IRC: Gerenciamento de canal - Modos de canal (seção 4)] (em English). IETF. p. 7. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  55. Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Mode message (section 4.2.3)» [Protocolo IRC - Mensagem de modo (seção 4.2.3)] (em English). IETF. p. 21. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 16 de abril de 2021 
  56. Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Channel modes (section 4.2.3.1)» [Protocolo IRC - Modos de canal (seção 4.2.3.1)] (em English). IETF. pp. 21 e 22. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 16 de abril de 2021 
  57. Kalt, C. (abril de 2000). «IRC: Channel management - Channel access control (section 4.3)» [IRC: Gerenciamento de canal - Controle de acesso ao canal (seção 4.3)] (em English). IETF. pp. 10 e 11. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 17 de abril de 2021 
  58. 58,0 58,1 Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Command responses: 353 RPL_NAMREPLY» [Protocolo IRC - Respostas de comando: 353 RPL_NAMREPLY] (em English). IETF. p. 51. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 17 de abril de 2021 
  59. Roeckx, Kurt (14 de outubro de 2004). «The 005 numeric: ISUPPORT». irc.org. Consultado em 10 de abril de 2011 
  60. Brocklesby, Edward (setembro de 2002). «IRC RPL_ISUPPORT numeric definition (I-D draft-brocklesby-irc-isupport-03)» [Definição numérica IRC RPL_ISUPPORT (I-D draft-brocklesby-irc-isupport-03)]. IETF. Consultado em 17 de abril de 2021 
  61. Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Operwall message (section 5.6)» [Protocolo IRC - Mensagem operwall (seção 5.6)] (em English). IETF. p. 41. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 17 de abril de 2021 
  62. Butcher, Simon (12 de janeiro de 2005). «IRC user modes list». alien.net.au. Consultado em 10 de abril de 2011 
  63. Butcher, Simon (12 de janeiro de 2005). «IRC channel modes list». alien.net.au. Consultado em 10 de abril de 2011 
  64. Butcher, Simon (12 de janeiro de 2005). «IRC server modes list». alien.net.au. Consultado em 10 de abril de 2011 
  65. Olsen, Tommy. «IRCd modes». webtoman.com. Consultado em 10 de abril de 2011. Cópia arquivada em 15 de outubro de 2011 
  66. 66,0 66,1 Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Operators (section 1.2.1)» [Protocolo IRC - Operadores (seção 1.2.1)] (em English). IETF. p. 5. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 19 de abril de 2021 
  67. Thiedeke, Udo (23 de setembro de 2003). «Nicola Döring, Alexander Schestag». Virtuelle gruppen: charakteristika und problemdimensionen [Grupos virtuais: características e dimensões do problema] (em Deutsch) 2 ed. [S.l.]: Springer VS. pp. 314, 337. ISBN 978-3-531-33372-4. Consultado em 20 de abril de 2021 
  68. Rogers, Russ (13 de janeiro de 2004). «The mind of terror». In: Devost, Matthew G. Hackeando uma rede terrorista: a ameaça silenciosa de canais secretos 1 ed. Rockland, Massachusetts: Syngress Publishing. p. 10. ISBN 978-1-928994-98-5. Consultado em 20 de abril de 2021 
  69. Petersen, Julie K., ed. (29 de maio de 2002). «Internet relay chat». The telecommunications illustrated dictionary [O dicionário ilustrado de telecomunicações] 2 ed. [S.l.]: CRC Press. p. 500. ISBN 978-0-8493-1173-4. Consultado em 20 de abril de 2021 
  70. «Frequently-asked questions» [Perguntas frequentes] (em English). Freenode. Consultado em 20 de abril de 2021. Cópia arquivada em 26 de abril de 2010 
  71. «IRC/Cloaks» (em English). Meta-wiki. Consultado em 20 de abril de 2021 
  72. «Uniform resource identifier (URI) schemes» [Esquemas URI (identificador de recurso uniforme)] (em English). Internet Assigned Numbers Authority. Consultado em 20 de abril de 2021 
  73. Butcher, Simon (janeiro de 2003). «URI schemes for IRC entities» [Esquemas URI para entidades IRC] (em English). IETF. Consultado em 20 de abril de 2021 
  74. «node-irc». npm (em English). Consultado em 20 de abril de 2021 
  75. Reed, D. (maio de 1992). «A discussion on computer network conferencing - Size (section 2.5.1)» [Uma discussão sobre conferência em rede de computadores - Tamanho (seção 2.5.1)] (em English). IETF. pp. 5 e 6. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  76. Kalt, C. (abril de 2000). «IRC: Architecture - Scalability section 6.1)» [IRC: Arquitetura - Escalabilidade seção 6.1)] (em English). IETF. p. 7. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 19 de abril de 2021 
  77. Predefinição:Harvnb 1.2.1 Growth - Crescimento
  78. Reed, D. (maio de 1992). «A discussion on computer network conferencing - User identification (section 5.4.1)» [Uma discussão sobre conferência em rede de computadores - Identificação do usuário (seção 5.4.1)] (em English). IETF. p. 10. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  79. Reed, D. (maio de 1992). «A discussion on computer network conferencing - Trees and cycles (section 5.4.2)» [Uma discussão sobre conferência de rede de computadores - Árvores e ciclos (seção 5.4.2)] (em English). IETF. p. 10. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  80. Predefinição:Harvnb 1.2.2 Network failures - Falhas de rede
  81. Reed, D. (maio de 1992). «A discussion on computer network conferencing - State information problems (section 2.1)» [Uma discussão sobre conferência de rede de computadores - Problemas de informação de estado (seção 2.1)] (em English). IETF. p. 4. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  82. Predefinição:Harvnb 1.2.3 Sociological and security aspects - Aspectos sociológicos e de segurança
  83. Reed, D. (maio de 1992). «A discussion on computer network conferencing - Message passing (section 5.2.1)» [Uma discussão sobre conferência em rede de computadores - passagem de mensagens (seção 5.2.1)] (em English). IETF. p. 7. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  84. Reed, D. (maio de 1992). «A discussion on computer network conferencing - Conference security (5.2.4)» [Uma discussão sobre conferência em rede de computadores - segurança de conferência (5.2.4)] (em English). IETF. p. 8. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  85. «Getting help on EsperNet» [Obtendo ajuda na EsperNet] (em English). The EsperNet IRC network. Consultado em 20 de abril de 2021 
  86. brandon (18 de maio de 2010). «New feature: SSL for users» [Novo recurso: SSL para usuários] (em English). DALnet. Consultado em 20 de abril de 2021 
  87. Smith, Roderick W. (8 de abril de 2000). «A internet: usando o IRC para obter ajuda». Manual de configuração de inicialização múltipla. Col: Handbook series (em English). Upper Saddle River, Nova Jérsei: Que Publishing. p. 289. ISBN 978-0-7897-2283-6. Consultado em 20 de abril de 2021. O mIRC é um dos clientes IRC mais populares do Windows. 
  88. «Opera browser wiki: IRC client» [Wiki do navegador Opera: cliente IRC] (em English). Consultado em 20 de abril de 2021. Arquivado do original em 17 de março de 2011 
  89. «Warsow wiki: IRC module» [Wiki Warsow: módulo IRC] (em English). Consultado em 20 de abril de 2021. Arquivado do original em 25 de abril de 2011 
  90. Guenter, Daniel (21 de junho de 2004). «UT2004 review» [Análise UT2004] (em English). BCCHardware. Consultado em 20 de abril de 2021 
  91. «The ultimate uplink guide» [O melhor guia Uplink] (em English). Consultado em 20 de abril de 2021 
  92. «ZDaemon – The doom wiki: other utilities» [ZDaemon - The doom wiki: outros utilitários] (em English). Consultado em 20 de abril de 2021 
  93. «How to setup [sic] an IRC client to connect and login [sic] to Ustream» [Como configurar [sic] um cliente IRC para conectar e fazer login [sic] para Ustream]. Ustream-Helpers. 29 de janeiro de 2012. Consultado em 20 de abril de 2021 [ligação inativa] 
  94. Mauldor (20 de junho de 2010). «Ustream vs. Justin.tv». LiquidSilver. Consultado em 20 de abril de 2021 [ligação inativa] 
  95. «Twitch IRC». Twitch help center (em English). 7 de abril de 2017. Consultado em 20 de abril de 2021 [ligação inativa] 
  96. Canavan, John. «The evolution of malicious IRC bots» [A evolução dos bots IRC maliciosos] (PDF). Symantec (em English). Symantec security response. Consultado em 20 de abril de 2021. Cópia arquivada (PDF) em 10 de outubro de 2017 
  97. «psyBNC Readme» [Leia-me psyBNC] (em English). psybnc.at. Consultado em 20 de abril de 2021 
  98. Carey, Chris (18 de julho de 2009). «IRC with irssi-proxy + screen» [IRC com irssi-proxy + tela] (em English). chriscarey.com. Consultado em 20 de abril de 2021 
  99. «Detachable frontend (core rewrite) / UML / Windows Port (kicking glade)» (em English). smuxi.org. 25 de dezembro de 2004. Consultado em 20 de abril de 2021 
  100. «About Smuxi» [Sobre o Smuxi] (em English). smuxi.org. Consultado em 20 de abril de 2021 
  101. Mutton, Paul (27 de julho de 2004). «Users and channels - Usuários e canais». IRC hacks [Hacks IRC] (em English) 1 ed. Sebastopol, California: O'Reilly Media. pp. 44 à 46. ISBN 978-0-596-00687-7 
  102. Wang, Wallace (25 de outubro de 2004). «Instant messaging and online chat rooms: internet relay chat (IRCarquivo ) - Mensagens instantâneas e salas de bate-papo online: internet relay chat (IRCarquivo)». Steal this file sharing book [Roube este livro de compartilhamento de arquivos] (em English) 1 ed. San Francisco, California: No Starch Press. pp. 65 à 67. ISBN 978-1-59327-050-6 
  103. Vamosi, Robert (8 de maio de 2002). «Pirated movies: now playing on a server near you» [Filmes piratas: reproduzindo agora em um servidor perto de você]. ZDNet (em English). Consultado em 21 de abril de 2021 
  104. Sasaki, Darla (4 de abril de 2002). «IRC 101: What is it & how do i use it?» [IRC 101: O que é e como devo usá-lo?] (em English). Macobserver.com. Consultado em 21 de abril de 2021 

Ligações externas

Commons
O Commons possui imagens e outros ficheiros sobre Internet Relay Chat
Wikilivros
O Wikilivros tem um livro chamado Internet Relay Chat

talvez você goste