Internet Relay Chat

Origem: Wikipédia, a enciclopédia livre.
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).[2] 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),[3] as 100 principais redes IRC serviam mais de meio milhão de usuários.[4] Em junho de 2021, existiam 481 diferentes redes IRC conhecidas por estarem operando.[5] 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.[6]

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.[7] O IRC é projetado principalmente para comunicação em grupo (em fóruns de discussões chamados de canais)[8] mas também permite comunicação um-para-um por meio de mensagens privadas,[9] bem como bate-papo e transferência de dados[10] (incluindo compartilhamento de arquivos).[11]

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

História[editar | editar código-fonte]

Desenvolvimento[editar | editar código-fonte]

O IRC foi escrito pelo programador finlandês Jarkko Oikarinen em 1988 na Universidade de Oulu na Finlândia.[13] O trabalho começou em agosto daquele ano e o objetivo era criar um sistema de teletexto comunitário que utilizasse 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[14] entre usuários que tinham acesso à Internet em Universidades do Oriente Médio.

Expansão[editar | editar código-fonte]

Com a abertura comercial da Internet ao grande público em 1993, ao longo da década de 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[editar | editar código-fonte]

O IRC se tornou o principal meio de bate-papo na Internet no final dos anos 1990 e início da década de 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 provocassem 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 possuía uma linguagem de scripts 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 enquetes 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.

Decadência[editar | editar código-fonte]

Xaric, um console baseado no IRC. São mostrados dois canais de IRC e uma conversa privada com o autor do software

A decadência do IRC começou por volta de 2003[15] quando os 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 Messenger foi ganhando espaço pois permitia conversas em vídeo por webcams 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.[16]

O lançamento da rede social Orkut foi o golpe final para as redes de IRC brasileiras. Os usuários do Orkut se reuniam em comunidades que possuíam fóruns e neles organizavam sistemas de chat nos tópicos.

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 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.

Reascensão[editar | editar código-fonte]

Em dias atuais o IRC está disponível por meio da plataforma web IRC, clientes de web IRC que fornecem serviços online como: LightIRC; Mibbits; kiwiIRC entre outros, permitindo que usuários adentrem ao sistema IRC por meio de acesso à web (internet), mediante navegador (browser), que pode ser incorporada a sites via iframe, o que vem aumentando gradativamente usuários no IRC. Redes brasileiras como a BrasIRC, vIRCio, VirtuaLife, sVipCHAT entre outras, tem feito uso dessa plataforma fornecendo webchat para diversos sites. 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.

Informação técnica[editar | editar código-fonte]

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[17] e, opcionalmente, TLS. Um servidor IRC pode se conectar a outros servidores IRC para expandir a rede IRC.[18] Os usuários acessam redes IRC conectando um cliente a um servidor.[19] 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.[20]

O IRC era originalmente um protocolo de texto simples[17] (embora posteriormente estendido) que, a pedido, foi atribuído a porta TCP 194 pela IANA.[21] No entanto, o padrão de fato sempre foi executar o IRC em TCP 6667[22] e números de porta próximos (por exemplo, portas TCP 6660-6669 e 7000)[23] 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.[24] 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.[25] 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.[26] As mensagens são encaminhadas apenas para os ramos necessários da árvore, mas o estado da rede é enviado para cada servidor[27] 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[28] 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[29] 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.[30] 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).[31][32]

Comandos e respostas[editar | editar código-fonte]

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[33] recebem respostas para essas mensagens[34] 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.[35]

Canal[editar | editar código-fonte]

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.[36] Canais em uma rede podem ser exibidos usando o comando LIST,[37] 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,[38] 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.[36]

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

Modos[editar | editar código-fonte]

Usuários e canais podem ter "modos" que são representados por letras simples, que diferenciam maiúsculas de minúsculas[42] e são configurados usando o comando MODE.[43] 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.[44]) 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.[45] 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[46] (enviada aos clientes na primeira entrada em um canal[38] 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.[47][48]

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[46] 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)[editar | editar código-fonte]

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.[49]
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.[50][51][52][53]

Operadores de canal[editar | editar código-fonte]

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[editar | editar código-fonte]

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[54] 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[54] 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[editar | editar código-fonte]

Uma máscara de host é um identificador único de um cliente IRC conectado à um servidor IRC.[55][56] 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.[57] 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.[58]

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.[59]

Esquema URI[editar | editar código-fonte]

Existem três esquemas URI reconhecidos para o IRC: irc, ircs, e irc6.[60] 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.[61] 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).[62]

Desafios[editar | editar código-fonte]

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

Ataques[editar | editar código-fonte]

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.[73][74]

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[editar | editar código-fonte]

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).

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[editar | editar código-fonte]

Software cliente[editar | editar código-fonte]

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.[75]

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[76] 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,[77] Unreal tournament (até o Unreal tournament 2004),[78] Uplink,[79] jogos baseados em Spring engine, 0 A.D. e ZDaemon têm o IRC incluído.[80]

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

Bots[editar | editar código-fonte]

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.[84]

Bouncer[editar | editar código-fonte]

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.[85]

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.[86]

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.[87][88]

Mecanismos de pesquisa[editar | editar código-fonte]

Existem vários motores de busca disponíveis para ajudar o usuário a encontrar o que procura no IRC.[89][90] 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[editar | editar código-fonte]

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 "]".[91] 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[editar | editar código-fonte]

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.[92]

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.[93] 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[editar | editar código-fonte]

Referências

  1. Jarkko Oikarinen; Darren Reed (maio de 1993). «RFC 1459, IRC protocol» [RFC 1459, Protocolo IRC] (em inglês). Consultado em 12 de junho de 2021 
  2. Erro de citação: Etiqueta <ref> inválida; não foi fornecido texto para as refs de nome pingdom
  3. «IRC servers – summary» [Servidores IRC - sumário] (em inglês). irc.netsplit.de. Consultado em 21 de julho de 2021. Arquivado do original em 22 de abril de 2011 
  4. «IRC networks – Top 100» [Redes IRC - Top 100] (em inglês). irc.netsplit.de. Consultado em 21 de julho de 2021 
  5. «IRC networks - in alphabetical order» [Redes IRC - em ordem alfabética]. netsplit.de (em inglês). 2020. Consultado em 21 de julho de 2021 
  6. «IRC networks - Top 100» [Redes IRC - Top 100]. netsplit.de. 2020. Consultado em 21 de julho de 2021 
  7. «IRC protocol - Introduction § 1» [Protocolo IRC - Introdução] (em inglês). p. 4. doi:10.17487/RFC1459. Consultado em 21 de julho de 2021 
  8. «IRC protocol - One-to-many § 3.2» [Protocolo IRC - Um para muitos] (em inglês). p. 11. doi:10.17487/RFC1459. Consultado em 21 de julho de 2021 
  9. «IRC: Architecture - One-to-one communication § 5.1» [IRC: Arquitetura - Comunicação um para um] (em inglês). p. 5. doi:10.17487/RFC1459. Consultado em 21 de julho de 2021 
  10. Rollo, Troy. «A description of the DCC protocol» [Descrição do protocolo DCC] (em inglês). irchelp.org. Consultado em 21 de julho de 2021 
  11. Wang, Wallace (25 de outubro de 2004). «Mensagens instantâneas e salas de chat online: Internet Relay Chat (IRC. Steal this file sharing book [Roube este livro de compartilhamento de arquivos] (em inglês) 1ª ed. São Francisco (Califórnia): No Starch Press. pp. 61 à 67. ISBN 978-1-59327-050-6 
  12. «SAGE IRC channel» [Canal IRC SAGE] (em inglês). 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 
  13. «History of IRC (Internet Relay Chat)». daniel.haxx.se. Consultado em 19 de fevereiro de 2011 
  14. «Index of /pub/academic/communications/logs/Gulf-War». www.ibiblio.org. Consultado em 19 de fevereiro de 2011 
  15. «IRC is dead, long live IRC» (em inglês). pingdom. 24 de Abril de 2012. Consultado em 20 de Agosto de 2017. Cópia arquivada em 15 de agosto de 2017 
  16. Sabryna Esmeraldo (30 de Janeiro de 2017). «Relembre o que mais faz falta da internet dos anos 1990 e 2000». O Povo. Consultado em 20 de Agosto de 2017 
  17. a b Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Introduction (section 1)» [Protocolo IRC - Introdução (seção 1)] (em inglês). IETF. p. 4. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  18. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Server (section 1.1)» [Protocolo IRC - Servidores (seção 1.1)] (em inglês). IETF. p. 4. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  19. Kalt, C. (abril de 2000). «IRC: Architecture - Clients (section 2.2)» [Arquitetura IRC - Clientes (seção 2.2)] (em inglês). IETF. p. 3. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 5 de abril de 2021 
  20. Oikarinen, J.; Reed, D. (maio de 2021). «IRC protocol - Clients (section 1.2)» [Protocolo IRC - Clientes (seção 1.2)] (em inglês). IETF. p. 5. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  21. «Port numbers» [Números de porta] (em inglês). Marina del Rey, California: Internet Assigned Numbers Authority. 6 de abril de 2011 
  22. 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 inglês). IETF. p. 29. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  23. 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 inglês). Rockland, Massachusetts: Syngress Publishing. p. 93. ISBN 978-1-59749-088-7 
  24. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Character codes (section 2.2)» [Protocolo IRC - Códigos de caracteres (seção 2.2)] (em inglês). IETF. p. 7. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 5 de abril de 2021 
  25. Abraham, Dalen (junho de 1998). «Extensions to the IRC protocol» [Extensões para o protocolo IRC] (em inglês). IETF. Consultado em 6 de abril de 2021 
  26. Kalt, C. (abril de 2000). «IRC: Architecture (section 3)» [IRC : Arquitetura (seção 3)] (em inglês). IETF. pp. 3 e 4. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  27. Kalt, C. (abril de 2000). «IRC: Architecture - Introduction (section 1)» [IRC : Arquitetura - Introdução (seção 1)] (em inglês). IETF. p. 2. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  28. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Algorithms (section 9.3)» [Protocolo IRC - Algoritmos (seção 9.3)] (em inglês). IETF. p. 64. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 6 de abril de 2021 
  29. Kalt, C. (abril de 2000). «IRC: Architecture - Network congestion (section 6.3)» [IRC : Arquitetura - Congestionamento de rede (seção 6.3)] (em inglês). IETF. pp. 7 e 8. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  30. 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 inglês). IETF. pp. 5 e 6. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 6 de abril de 2021 
  31. «IRC daemons for LAN». Consultado em 2 de outubro de 2014 
  32. «Running an own IRC server». Consultado em 2 de outubro de 2014 
  33. 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 inglês). IETF. p. 8. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 6 de abril de 2021 
  34. Oikarinen, J.; Reed, D. (maio de 1993). «IRC protocol - Numeric replies (section 2.4)» [Protocolo IRC - Respostas numéricas (seção 2.4)] (em inglês). IETF. p. 10. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 6 de abril de 2021 
  35. 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 inglês). Dataforce's blog. Consultado em 15 de abril de 2021 
  36. a b 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 inglês). IETF. p. 11. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 15 de abril de 2021 
  37. 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 inglês). IETF. p. 24. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 15 de abril de 2021 
  38. a b 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 inglês). IETF. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 16 de abril de 2021 
  39. 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 inglês). IETF. pp. 3 e 4. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  40. 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 inglês). IETF. p. 4. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  41. 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 inglês). IETF. p. 5. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  42. Kalt, C. (abril de 2000). «IRC: Channel management - Channel modes (section 4)» [IRC: Gerenciamento de canal - Modos de canal (seção 4)] (em inglês). IETF. p. 7. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 16 de abril de 2021 
  43. 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 inglês). IETF. p. 21. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 16 de abril de 2021 
  44. 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 inglês). IETF. pp. 21 e 22. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 16 de abril de 2021 
  45. 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 inglês). IETF. pp. 10 e 11. RFC 2811Acessível livremente. doi:10.17487/RFC2811. Consultado em 17 de abril de 2021 
  46. a b Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Command responses: 353 RPL_NAMREPLY» [Protocolo IRC - Respostas de comando: 353 RPL_NAMREPLY] (em inglês). IETF. p. 51. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 17 de abril de 2021 
  47. Roeckx, Kurt (14 de outubro de 2004). «The 005 numeric: ISUPPORT». irc.org. Consultado em 10 de abril de 2011 
  48. 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 
  49. Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Operwall message (section 5.6)» [Protocolo IRC - Mensagem operwall (seção 5.6)] (em inglês). IETF. p. 41. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 17 de abril de 2021 
  50. Butcher, Simon (12 de janeiro de 2005). «IRC user modes list». alien.net.au. Consultado em 10 de abril de 2011 
  51. Butcher, Simon (12 de janeiro de 2005). «IRC channel modes list». alien.net.au. Consultado em 10 de abril de 2011 
  52. Butcher, Simon (12 de janeiro de 2005). «IRC server modes list». alien.net.au. Consultado em 10 de abril de 2011 
  53. Olsen, Tommy. «IRCd modes». webtoman.com. Consultado em 10 de abril de 2011. Cópia arquivada em 15 de outubro de 2011 
  54. a b Oikarinen, J.; Reed, D. (maio de 1993). «IRC Protocol - Operators (section 1.2.1)» [Protocolo IRC - Operadores (seção 1.2.1)] (em inglês). IETF. p. 5. RFC 1459Acessível livremente. doi:10.17487/RFC1459. Consultado em 19 de abril de 2021 
  55. 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 alemão) 2 ed. [S.l.]: Springer VS. pp. 314, 337. ISBN 978-3-531-33372-4. Consultado em 20 de abril de 2021 
  56. Rogers, Russ (13 de janeiro de 2004). «The mind of terror». In: Devost, Matthew G. Hacking a terror network: the silent threat of covert channels [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 
  57. 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 
  58. «Frequently-asked questions» [Perguntas frequentes] (em inglês). Freenode. Consultado em 20 de abril de 2021. Cópia arquivada em 26 de abril de 2010 
  59. «IRC/Cloaks» (em inglês). Meta-wiki. Consultado em 20 de abril de 2021 
  60. «Uniform resource identifier (URI) schemes» [Esquemas URI (identificador de recurso uniforme)] (em inglês). Internet Assigned Numbers Authority. Consultado em 20 de abril de 2021 
  61. Butcher, Simon (janeiro de 2003). «URI schemes for IRC entities» [Esquemas URI para entidades IRC] (em inglês). IETF. Consultado em 20 de abril de 2021 
  62. «node-irc». npm (em inglês). Consultado em 20 de abril de 2021 
  63. 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 inglês). IETF. pp. 5 e 6. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  64. Kalt, C. (abril de 2000). «IRC: Architecture - Scalability section 6.1)» [IRC: Arquitetura - Escalabilidade seção 6.1)] (em inglês). IETF. p. 7. RFC 2810Acessível livremente. doi:10.17487/RFC2810. Consultado em 19 de abril de 2021 
  65. Loesch 2003 1.2.1 Growth - Crescimento
  66. 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 inglês). IETF. p. 10. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  67. 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 inglês). IETF. p. 10. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  68. Loesch 2003 1.2.2 Network failures - Falhas de rede
  69. 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 inglês). IETF. p. 4. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  70. Loesch 2003 1.2.3 Sociological and security aspects - Aspectos sociológicos e de segurança
  71. 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 inglês). IETF. p. 7. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  72. 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 inglês). IETF. p. 8. RFC 1324Acessível livremente. doi:10.17487/RFC1324. Consultado em 19 de abril de 2021 
  73. «Getting help on EsperNet» [Obtendo ajuda na EsperNet] (em inglês). The EsperNet IRC network. Consultado em 20 de abril de 2021 
  74. brandon (18 de maio de 2010). «New feature: SSL for users» [Novo recurso: SSL para usuários] (em inglês). DALnet. Consultado em 20 de abril de 2021 
  75. Smith, Roderick W. (8 de abril de 2000). «The internet: Using IRC to get help - A internet: usando o IRC para obter ajuda». The multi-boot configuration handbook [Manual de configuração de inicialização múltipla]. Col: Handbook series (em inglês). Upper Saddle River, New Jersey: Que Publishing. p. 289. ISBN 978-0-7897-2283-6. Consultado em 20 de abril de 2021. mIRC is one of the most popular Windows IRC clients - mIRC é um dos clientes IRC mais populares do Windows. 
  76. «Opera browser wiki: IRC client» [Wiki do navegador Opera: cliente IRC] (em inglês). Consultado em 20 de abril de 2021. Arquivado do original em 17 de março de 2011 
  77. «Warsow wiki: IRC module» [Wiki Warsow: módulo IRC] (em inglês). Consultado em 20 de abril de 2021. Arquivado do original em 25 de abril de 2011 
  78. Guenter, Daniel (21 de junho de 2004). «UT2004 review» [Análise UT2004] (em inglês). BCCHardware. Consultado em 20 de abril de 2021 
  79. «The ultimate uplink guide» [O melhor guia Uplink] (em inglês). Consultado em 20 de abril de 2021 
  80. «ZDaemon – The doom wiki: other utilities» [ZDaemon - The doom wiki: outros utilitários] (em inglês). Consultado em 20 de abril de 2021 
  81. «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] 
  82. Mauldor (20 de junho de 2010). «Ustream vs. Justin.tv». LiquidSilver. Consultado em 20 de abril de 2021 [ligação inativa] 
  83. «Twitch IRC». Twitch help center (em inglês). 7 de abril de 2017. Consultado em 20 de abril de 2021 [ligação inativa] 
  84. Canavan, John. «The evolution of malicious IRC bots» [A evolução dos bots IRC maliciosos] (PDF). Symantec (em inglês). Symantec security response. Consultado em 20 de abril de 2021. Cópia arquivada (PDF) em 10 de outubro de 2017 
  85. «psyBNC Readme» [Leia-me psyBNC] (em inglês). psybnc.at. Consultado em 20 de abril de 2021 
  86. Carey, Chris (18 de julho de 2009). «IRC with irssi-proxy + screen» [IRC com irssi-proxy + tela] (em inglês). chriscarey.com. Consultado em 20 de abril de 2021 
  87. «Detachable frontend (core rewrite) / UML / Windows Port (kicking glade)» (em inglês). smuxi.org. 25 de dezembro de 2004. Consultado em 20 de abril de 2021 
  88. «About Smuxi» [Sobre o Smuxi] (em inglês). smuxi.org. Consultado em 20 de abril de 2021 
  89. Mutton, Paul (27 de julho de 2004). «Users and channels - Usuários e canais». IRC hacks [Hacks IRC] (em inglês) 1 ed. Sebastopol, California: O'Reilly Media. pp. 44 à 46. ISBN 978-0-596-00687-7 
  90. 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 inglês) 1 ed. San Francisco, California: No Starch Press. pp. 65 à 67. ISBN 978-1-59327-050-6 
  91. Erro de citação: Etiqueta <ref> inválida; não foi fornecido texto para as refs de nome rfc 1459 2.2 character codes
  92. 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 inglês). Consultado em 21 de abril de 2021 
  93. 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 inglês). Macobserver.com. Consultado em 21 de abril de 2021 

Ligações externas[editar | editar código-fonte]

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