Internet Relay Chat

protocolo para conversação e mensagens na Internet em tempo real
(Redirecionado de IRC)
 Nota: Para outros significados, veja IRC (desambiguação).

O IRC (Internet Relay Chat) é um sistema de chat baseado em texto para mensagem instantânea. O IRC é projetado para comunicação em grupo em fóruns de discussão, chamados canais,[1] mas também permite comunicação um-a-um via mensagens privadas[2], bem como chat e transferência de dados (DCC),[3] incluindo compartilhamento de arquivos.[4]

Internet Relay Chat
Protocolo de comunicação
AbreviaçãoIRC
PropósitoMensagens instantâneas
DesenvolvedorJarkko Oikarinen
Introduçãoagosto de 1988; há 37 anos
InfluênciaIRCv3 (grupo de trabalho de processo de padrões)
Camada OSICamada de aplicação
Portas6667, 6697
RFC1459
O primeiro servidor de IRC, tolsun.oulu.fi, um servidor Sun-3 em exibição perto do centro de computação da Universidade de Oulu

O Internet Relay Chat é implementado como um protocolo de camada de aplicação para facilitar a comunicação em forma de texto. O processo de chat funciona em um modelo de rede cliente-servidor. Os usuários se conectam, usando um cliente — que pode ser uma aplicação web, um programa de desktop autônomo ou embutido em parte de um programa maior — a um servidor de IRC, que pode fazer parte de uma rede de IRC maior. Exemplos de formas usadas para se conectar incluem os programas Mibbit, KiwiIRC e mIRC.

O uso do IRC tem diminuído constantemente desde 2003, perdendo 60% de seus usuários até 2012.[5] Em abril de 2026, as 100 principais redes de IRC atendiam mais de 162.000 usuários simultâneos.[6]

História

editar

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 da Computação. Jarkko pretendia estender o software de BBS que administrava, para permitir notícias no estilo Usenet, discussões em tempo real e recursos de BBS semelhantes. A primeira parte que ele implementou foi a parte de chat, que fez com partes emprestadas escritas por seus amigos Jyrki Kuoppala e Jukka Pihl. A primeira rede de IRC estava rodando em um único servidor chamado tolsun.oulu.fi.[7] Oikarinen buscou inspiração em um sistema de chat conhecido como Bitnet Relay, que operava na BITNET.[8]

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, após finalmente conseguirem o lançamento, Jyrki Kuoppala instalou imediatamente outro servidor. Esta foi a primeira "rede IRC". Oikarinen conseguiu que alguns amigos na Universidade de Tecnologia de Helsinque e na Universidade de Tecnologia de Tampere[8] começassem a rodar servidores de IRC quando o número de usuários aumentou, e outras universidades logo seguiram o exemplo. Nessa época, Oikarinen percebeu que o restante dos recursos de BBS provavelmente não caberia em seu programa.[7]

Oikarinen contatou pessoas na Universidade de Denver e na Universidade Estadual do Oregon. Eles tinham sua própria rede de IRC funcionando e queriam se conectar à rede finlandesa. Eles obtiveram o programa de um dos amigos de Oikarinen, Vijay Subramaniam — a primeira pessoa não finlandesa a usar o IRC. O IRC então cresceu e passou a ser usado em toda a rede nacional finlandesa — FUNET — e depois se conectou à NORDUnet, o braço escandinavo da Internet. Em novembro de 1988, o IRC havia se espalhado pela Internet e, no meio de 1989, havia cerca de 40 servidores em todo o mundo.[7]

Em agosto de 1990, ocorreu o primeiro grande desentendimento no mundo do IRC. A "A-net" (Anarchy net) incluía um servidor chamado eris.berkeley.edu. Era totalmente aberta, não exigia senhas e não tinha limite de conexões. Como Greg "wumpus" Lindahl explica:[9] "tinha uma linha de servidor curinga, então as pessoas estavam conectando servidores e causando conflitos de apelidos (nick-colliding) com todos". A "Eris Free Network", EFnet, tornou a máquina eris a primeira a ser colocada em Q-lined (Q de quarentena) do IRC. Nas palavras de wumpus novamente:[9] "A Eris se recusou a remover aquela linha, então eu formei a EFnet. Não foi muito uma luta; consegui que todos os hubs se juntassem e quase todos os outros foram levados junto." A A-net foi formada com os servidores eris, enquanto a EFnet foi formada com os servidores não-eris. A história mostrou que a maioria dos servidores e usuários foi com a EFnet. Uma vez que a A-net se dissolveu, o nome EFnet tornou-se sem sentido e, mais uma vez, era a única e exclusiva rede de IRC.[7]

Por volta dessa época, o IRC foi usado para relatar a Tentativa de golpe de Estado na União Soviética em 1991 durante um Blecaute de mídia.[10] Anteriormente, havia sido usado de maneira semelhante durante a Guerra do Golfo.[11] Logs de chat desses e outros eventos são mantidos no arquivo ibiblio.[12]

Bifurcação da Undernet

editar

Outro esforço de bifurcação (fork), o primeiro que fez uma diferença duradoura, foi iniciado por "Wildthang" nos Estados Unidos em outubro de 1992. (Ele bifurcou a versão 2.8.10 do ircd da EFnet). Era para ser apenas uma rede de teste para desenvolver bots, mas rapidamente cresceu para uma rede "para amigos e amigos deles". Na Europa e no Canadá, uma nova rede separada estava sendo trabalhada e, em dezembro, os servidores franceses se conectaram aos canadenses; até o final do mês, a rede franco-canadense estava conectada à dos EUA, formando a rede que mais tarde viria a ser chamada de "Undernet".[7]

Os "undernetters" queriam levar o ircd adiante em uma tentativa de fazê-lo usar menos largura de banda e tentar resolver o caos nos canais (netsplits e tomadas de controle) que a EFnet começou a sofrer. Para este último propósito, a Undernet implementou carimbos de data/hora (timestamps), novo roteamento e ofereceu o CService — um programa que permitia aos usuários registrar canais e tentava protegê-los de criadores de problemas. A primeira lista de servidores apresentada, de 15 de fevereiro de 1993, incluía servidores dos EUA, Canadá, França, Croácia e Japão. Em 15 de agosto, o novo recorde de contagem de usuários foi estabelecido em 57 usuários.[7]

Em maio de 1993, o RFC 1459[13] foi publicado e detalha um protocolo simples para operação cliente/servidor, canais, conversas um-a-um e um-para-muitos.[7] Um número significativo de extensões como CTCP, cores e formatos não estão incluídos nas especificações do protocolo, nem a codificação de caracteres,[14] o que levou várias implementações de servidores e clientes a divergirem. A implementação do software variou significativamente de uma rede para outra, com cada rede implementando suas próprias políticas e padrões em suas próprias bases de código.

Bifurcação da DALnet

editar

Durante o verão de 1994, a própria Undernet foi bifurcada. A nova rede foi chamada DALnet (nomeada após seu fundador: dalvenjah), formada para um melhor serviço ao usuário e mais proteções de usuários e canais. Uma das mudanças mais significativas na DALnet foi o uso de apelidos (nicknames) mais longos (o limite original do ircd era de 9 letras). As modificações no ircd da DALnet foram feitas por Alexei "Lefler" Kosut. A DALnet baseou-se, portanto, no servidor ircd da Undernet, embora os pioneiros da DALnet fossem desertores da EFnet. De acordo com James Ng, as pessoas iniciais da DALnet eram "operadores no #StarTrek fartos dos constantes splits/lags/takeovers/etc".[7]

A DALnet rapidamente ofereceu WallOps globais (mensagens de IRCop que podem ser vistas por usuários que estão +w (/mode NickName +w)), apelidos mais longos, apelidos em Q:Lined (apelidos que não podem ser usados, como ChanServ, IRCop, NickServ, etc.), K:Lines globais (banimento de uma pessoa ou um domínio inteiro de um servidor ou de toda a rede), comunicações exclusivas para IRCops: GlobOps, modo +H mostrando que um IRCop é um "helpop", etc. Muitas das novas funções da DALnet foram escritas no início de 1995 por Brian "Morpher" Smith e permitem que os usuários possuam apelidos, controlem canais, enviem memorandos e muito mais.[7]

Bifurcação da IRCnet

editar

Em julho de 1996, após meses de guerras de mensagens e discussões na lista de e-mail, houve mais uma divisão devido ao desentendimento em como o desenvolvimento do ircd deveria evoluir. Notavelmente, o lado "europeu" (a maioria daqueles servidores estava na Europa), que mais tarde se autodenominou IRCnet, defendia atrasos de apelidos e canais, enquanto o lado da EFnet defendia carimbos de data/hora (timestamps).[7] Também houve divergências sobre políticas: o lado europeu começou a estabelecer um conjunto de regras direcionando o que os IRCops podiam ou não fazer, um ponto de vista oposto pelo lado dos EUA.[15]

A maioria (não todos) dos servidores da IRCnet estava na Europa, enquanto a maioria dos servidores da EFnet estava nos EUA. Este evento também é conhecido como "A Grande Divisão" em muitas sociedades de 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) do ano 2000, a EFnet tinha cerca de 50.000 usuários e a IRCnet 70.000.[7]

IRC Moderno

editar

O IRC mudou muito ao longo de sua vida na Internet. Novos softwares de servidor adicionaram uma infinidade de novos recursos.

  • Serviços: Bots operados pela 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 original de IRC usava um conjunto de modos de usuário e canal padrão, novos servidores adicionam muitos novos modos para recursos como remover códigos de cores do texto,[16] ou ocultar o hostmask de um usuário ("cloaking") para proteção contra ataques de negação de serviço.[17]
  • Detecção de proxy: A maioria dos servidores modernos suporta a detecção de usuários que tentam se conectar através de um servidor proxy inseguro (mal configurado ou explorado), cuja conexão pode então ser negada. Este software de detecção de proxy é usado por várias redes, embora essa lista de proxies em tempo real esteja extinta desde o início de 2006.[18]
  • Comandos adicionais: Novos comandos podem ser coisas como comandos de atalho para enviar ordens aos Serviços, até comandos exclusivos para operadores de rede para manipular o hostmask de um usuário.[carece de fontes?]
  • Encriptação: Para o trecho da conexão cliente-servidor, o TLS pode ser usado (as mensagens deixam de ser seguras uma vez que são retransmitidas para outros usuários em conexões padrão, mas isso dificulta a interceptação ou escuta das sessões de IRC de um indivíduo). Para comunicação cliente-a-cliente, o SDCC (DCC Seguro) pode ser usado.[carece de fontes?]
  • Protocolo de conexão: O IRC pode ser conectado tanto via IPv4 quanto IPv6.

Desde 2016, um novo esforço de padronização está em andamento sob um grupo de trabalho chamado IRCv3, que se concentra em recursos de cliente mais avançados, como notificações instantâneas, melhor suporte a histórico e segurança aprimorada.[19] Desde 2019, nenhuma das principais redes de IRC adotou totalmente o padrão proposto.[20]

Desde junho de 2021 (2021 -06) existem 481 redes de IRC diferentes conhecidas em operação,[21] das quais a rede de código aberto Libera Chat, fundada em maio de 2021, possui o maior número de usuários, com 20.374 canais em 26 servidores; entre elas, as 100 principais redes de IRC compartilham mais de 100 mil canais operando em cerca de mil servidores.[22]

Após sua era de ouro durante os anos 1990 e início dos anos 2000 (240.000 usuários na QuakeNet em 2004), o IRC viu um declínio significativo, perdendo cerca de 60% dos usuários entre 2003 e 2012, com usuários mudando para plataformas de mídia social como Facebook ou Twitter,[5] mas também para plataformas abertas como o XMPP, que foi 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.[5] No entanto, a Freenode, que em 2016 tinha cerca de 90.000 usuários, desde então declinou para cerca de 9.300 usuários.[23]

As maiores redes de IRC têm sido tradicionalmente agrupadas como as "Quatro Grandes" (Big Four)[24][25][26][27]—uma designação para redes que lideram as estatísticas. As Quatro Grandes 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" foram:[24][25][26]

O IRC atingiu 6 milhões de usuários simultâneos em 2001 e 10 milhões de usuários em 2004–2005, caindo para cerca de 350 mil em 2021.[carece de fontes?]

Em dezembro de 2025, as 5 principais redes de IRC têm uma participação total de cerca de 88.000 usuários por dia, com as redes de IRC restantes tendo menos de 10.000 usuários por dia cada uma. Existem cerca de 35 redes com pelo menos 1.000 usuários por dia.[28]

Cronologia

editar

Cronologia das principais redes:

Informações técnicas

editar
Uma captura de tela do HexChat, um cliente de IRC para ambientes GTK
Irssi, um cliente de IRC baseado em texto

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

O IRC era originalmente um protocolo de texto simples[13] (embora posteriormente estendido), ao qual, mediante solicitação, foi atribuída a porta 194/TCP pela IANA.[34] No entanto, o padrão de facto sempre foi rodar o IRC na porta 6667/TCP[35] e números de porta próximos (por exemplo, portas TCP 6660–6669, 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.[14] Isso pode causar problemas quando usuários que utilizam clientes e/ou plataformas diferentes desejam conversar.

Todos os protocolos IRC cliente-servidor em uso hoje descendem do protocolo implementado na versão irc2.4.0 do servidor IRC2 e documentado no RFC 1459. Desde que o RFC 1459 foi publicado, os novos recursos na implementação do irc2.10 levaram à publicação de vários documentos de protocolo revisados (RFC 2810, RFC 2811, RFC 2812 e RFC 2813); no entanto, essas mudanças de protocolo não foram amplamente adotadas entre outras implementações.[carece de fontes?]

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 dependem estritamente dos RFCs acima como referência.[carece de fontes?]

A Microsoft fez uma extensão para o IRC em 1998 via o proprietário IRCX.[37] Mais tarde, eles pararam de distribuir software que suportava IRCX, desenvolvendo em seu lugar o proprietário Microsoft Notification Protocol (MSNP).

A estrutura padrão de uma rede de servidores IRC é uma árvore.[38] As mensagens são roteadas apenas pelos ramos necessários da árvore, mas o estado da rede é enviado para todos os servidores[39] e geralmente há um alto grau de confiança implícita entre os servidores. No entanto, essa arquitetura apresenta vários problemas. Um servidor com comportamento inadequado ou malicioso pode causar grandes danos à rede[40] e quaisquer mudanças na estrutura, sejam intencionais ou resultado de condições na rede subjacente, exigem um net-split e um net-join. Isso resulta em muito tráfego de rede e mensagens falsas de saída/entrada (quit/join) para os usuários[41] e perda temporária de comunicação para os usuários nos servidores em divisão. Adicionar um servidor a uma rede grande significa uma grande carga de largura de banda de fundo na rede e uma grande carga de memória no servidor. Uma vez estabelecido, no entanto, cada mensagem para vários destinatários é entregue de forma semelhante ao multicast, o que significa que cada mensagem percorre um link de rede exatamente uma vez.[42] Esta é uma força em comparação com protocolos que não são multicast, como o Simple Mail Transfer Protocol (SMTP)[carece de fontes?] ou o Extensible Messaging and Presence Protocol (XMPP)[carece de fontes?].

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

Comandos e respostas

editar

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

Devido à natureza do protocolo, sistemas automatizados nem sempre conseguem emparelhar corretamente um comando enviado com sua resposta com total confiabilidade e estão sujeitos a suposições.[48]

Canais

editar

O meio básico de comunicação para um grupo de usuários em uma sessão de IRC estabelecida é através de um canal.[49] Canais em uma rede podem ser visualizados usando o comando IRC LIST,[50] que lista todos os canais atualmente disponíveis que não possuem os modos +s ou +p configurados naquela rede específica.

Usuários podem entrar (join) em um canal usando o comando JOIN,[51] disponível na maioria dos clientes como /join #nome-do-canal. Mensagens enviadas para os canais acessados são então retransmitidas para todos os outros usuários.[49]

Canais disponíveis em toda a rede IRC são prefixados com um '#', enquanto aqueles locais a um servidor usam '&'.[52] Outros tipos de canais menos comuns incluem canais '+' — canais 'sem modos' e sem operadores[53] — e canais '!', uma forma de canal com timestamp (registro de data/hora) em redes que normalmente não utilizam timestamps.[54]

Usuários e canais podem ter modos que são representados por letras individuais sensíveis a maiúsculas e minúsculas (case-sensitive)[55] e são configurados usando o comando MODE.[56] Os modos de usuário e os modos de canal são separados e podem usar a mesma letra para significar coisas diferentes (ex: o modo de usuário "i" é o modo invisível, enquanto o modo de canal "i" é apenas para convidados).[57]) Os modos geralmente são ativados e desativados usando o comando mode que recebe um alvo (usuário ou canal), um conjunto de modos para ativar (+) ou desativar (-) e quaisquer parâmetros que os modos necessitem.

Alguns modos de canal recebem parâmetros e outros modos de canal se aplicam a um usuário em um canal ou adicionam/removem uma máscara (ex: uma máscara de banimento) de uma lista associada ao canal, em vez de se aplicarem ao canal como um todo.[58] Modos que se aplicam a usuários em um canal possuem um símbolo associado que é usado para representar o modo em respostas de nomes (names replies)[59] (enviadas aos clientes ao entrar pela primeira vez em um canal[51] e ao usar o comando names) e, em muitos clientes, também são usados para representá-lo na lista de usuários exibida no canal ou para mostrar um indicador próprio para os modos de um usuário.

Para analisar corretamente as mensagens de modo recebidas 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 corresponde a qual letra. Nas primeiras implementações do IRC, isso precisava ser codificado diretamente no cliente (hard-coded), mas agora existe uma extensão de padrão de fato para o protocolo chamada ISUPPORT, que envia essas informações ao cliente no momento da conexão usando o numérico 005.[60][61]

Existe uma pequena falha de design no IRC em relação aos modos que se aplicam a usuários em canais: a mensagem de nomes usada para estabelecer o estado inicial do canal só pode enviar um desses modos por usuário no canal,[59] mas múltiplos modos podem ser configurados em um único usuário. Por exemplo, se um usuário possui tanto o status de operador (+o) quanto o status de voz (+v) em um canal, um novo cliente não conseguirá ver o modo com menor prioridade (ex: voz). Soluções alternativas para isso são possíveis tanto no lado do cliente quanto no servidor; uma solução comum é usar a extensão "multi-prefix" do IRCv3.[62]

Modos Padrão (RFC 1459)

editar
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 notificações do servidor
w Recebe wallops[63]
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 modos de canal e expulsar (kick) usuários do canal, entre outras coisas
s Canal secreto — não mostrado na lista de canais ou no whois de usuários, exceto para usuários que já estão no canal
p Canal privado — listado na lista de canais como "prv" de acordo com a RFC 1459
n Usuários não podem enviar mensagens para o canal externamente
m Canal moderado (apenas aqueles que possuem status de operador ou voz no canal podem enviar mensagens para ele)
i Apenas usuários com convites podem entrar no canal.
t Apenas operadores de canal podem alterar 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 banimento (nick!user@host com curingas permitidos) Bane hostmasks do canal
v + Nome do usuário afetado Dá a um usuário o status de voz no canal (veja +m acima)
k Nova chave de canal Define uma chave (senha) para o canal, de modo que apenas 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.[64][65][66][67]

Operadores de canal

editar

Um operador de canal é um cliente em um canal de IRC que gerencia o canal. Operadores de canal de IRC podem ser facilmente identificados pelo símbolo ou ícone ao lado de seu nome (varia conforme a implementação do cliente, comumente um prefixo "@", um círculo verde ou uma letra latina "+o"/"o"). Na maioria das redes, um operador pode:

  • Expulsar (kick) um usuário.
  • Banir um usuário.
  • Dar status de Operador de Canal ou status de Voz de Canal a outro usuário.
  • Alterar o tópico do canal de IRC enquanto o modo +t estiver ativo.
  • Alterar as travas (locks) de Modos de Canal.

Operadores

editar

Existem também usuários que mantêm direitos elevados em seu servidor local ou em toda a rede; estes são chamados de operadores de IRC,[68] às vezes abreviados para IRCops ou Opers (não confundir com operadores de canal). Como a implementação do IRCd varia, os privilégios do operador de IRC no IRCd em questão também variam. A RFC 1459[68] 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 programas automatizados prejudiciais entrem no IRC, os operadores de IRC geralmente têm permissão para desconectar clientes e banir completamente endereços IP ou sub-redes inteiras. Redes que possuem serviços (NickServ et al.) geralmente permitem que seus operadores de IRC também lidem com questões básicas de "propriedade". Outros direitos privilegiados podem incluir ignorar banimentos de canais (podendo entrar em canais onde não seriam permitidos se não fossem opers), dar status de operador a si mesmos em canais onde não conseguiriam sem ser opers, receber status de operador automaticamente sempre, e assim por diante.

Hostmasks

editar

Uma hostmask é um identificador único de um cliente de IRC conectado a um servidor de IRC.[69][70] Servidores de IRC, serviços e outros clientes, incluindo bots, podem usá-la para identificar uma sessão específica de IRC.

O formato de uma hostmask é nick!user@host. A hostmask parece similar a um endereço de e-mail, mas não deve ser confundida com um, sendo distinguida pelo "!" para indicar o apelido (Nick) e o nome de usuário.

A parte "nick" é o apelido escolhido pelo usuário e pode ser alterado enquanto estiver conectado. A parte "user" é o nome de usuário relatado pelo protocolo ident no cliente.[71] Se o ident não estiver disponível no cliente, o nome de usuário especificado quando o cliente se conectou é usado após ser prefixado com um til (~).[72]

A parte "host" é o nome da máquina de onde 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 será usado no lugar do hostname.

Devido às implicações de privacidade de expor o endereço IP ou o hostname de um cliente, alguns daemons de IRC também fornecem recursos de privacidade, como o modo "+x" do InspIRCd ou UnrealIRCd. Isso realiza um hash do endereço IP do cliente ou oculta parte do hostname do cliente, tornando-o ilegível para outros usuários que não sejam IRCops. Os usuários também podem ter a opção de solicitar um "host virtual" (ou "vhost"), a ser exibido na hostmask para permitir maior anonimato. Algumas redes de IRC, como Libera Chat ou Freenode, usam esses recursos como "cloaks" (capas) para indicar que um usuário é afiliado a um grupo ou projeto.[73]

Esquema de URI

editar

Existem três esquemas de identificador uniforme de recursos (URI) provisoriamente reconhecidos para Internet Relay Chat: irc, ircs, e irc6.[74] Quando suportados, eles permitem hiperlinks de várias formas, incluindo:

irc://<host>[:<port>]/[<channel>[?<channel_keyword>]]
ircs://<host>[:<port>]/[<channel>[?<channel_keyword>]]
irc6://<host>[:<port>]/[<channel>[?<channel_keyword>]]

(onde os itens entre colchetes ([,]) são opcionais) para serem usados para (se necessário) conectar ao host especificado (ou rede, se conhecida pelo cliente IRC) e entrar no canal especificado.[75] (Isso pode ser usado dentro do próprio cliente ou a partir de outra aplicação, como um navegador Web). irc é o URI padrão, irc6 especifica uma conexão a ser feita usando IPv6, e ircs especifica uma conexão segura.

De acordo com a especificação, o símbolo de hashtag comum (#) será prefixado aos nomes de canais que começam com um caractere alfanumérico — permitindo que ele seja omitido. Algumas implementações (por exemplo, mIRC) farão isso incondicionalmente, resultando em um caractere extra (geralmente não pretendido) (por exemplo, ##canal), se incluído na URL.

Algumas implementações permitem que múltiplos canais sejam especificados, separados por vírgulas.[76]

Desafios

editar

Problemas no design original do IRC incluíam a quantidade de dados de estado compartilhado[77][78] sendo uma limitação em sua escalabilidade,[79] a ausência de identificações únicas de usuário levando ao problema de colisão de apelidos (nicknames),[80] a falta de proteção contra netsplits por meio de roteamento cíclico,[81][82] a troca da escalabilidade em favor de informações de presença do usuário em tempo real,[83] fraquezas do protocolo servindo como plataforma para abusos,[84] falta de passagem de mensagens transparente e otimizável,[85] e a falta de criptografia.[86] Alguns desses problemas foram abordados no IRC Moderno.

Ataques

editar

Como as conexões de IRC podem não ser criptografadas e normalmente abrangem longos períodos de tempo, elas são um alvo atraente para atacantes 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 a um ataque, como uma guerra de tomada de controle (takeover). As redes de IRC também podem aplicar K-line ou G-line a usuários ou servidores que tenham um efeito prejudicial.

Alguns servidores de IRC suportam conexões SSL/TLS para fins de segurança. Isso ajuda a interromper o uso de programas farejadores de pacotes para obter as senhas dos usuários de IRC, mas tem pouco uso além desse escopo devido à natureza pública dos canais de IRC. Conexões SSL exigem suporte tanto do cliente quanto do servidor (o 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-para-servidor e fornecem uma flag de canal especial (como +S) para permitir apenas usuários conectados via SSL no canal, enquanto desabilitam a identificação de operador em texto simples, para melhor aproveitar as vantagens que o SSL oferece.[87][88]

O IRC serviu como um laboratório precoce para muitos tipos de ataques na Internet, como o uso de mensagens ICMP falsas de "inalcançável" para quebrar conexões IRC baseadas em TCP (nuking) para irritar usuários ou facilitar tomadas de controle.

Prevenção de abusos

editar

Uma das questões técnicas mais polêmicas em torno das implementações de IRC, que sobrevive até hoje, é o mérito dos protocolos de "Nick/Channel Delay" (Atraso de Nick/Canal) vs. "Timestamp" (Registro de data/hora). Ambos os métodos existem para resolver o problema de ataques de negação de serviço, mas adotam abordagens muito diferentes. O problema com o protocolo IRC original, conforme implementado, era que quando dois servidores se separavam e se reuniam, os dois lados da rede simplesmente fundiam seus canais. Se um usuário conseguisse entrar em um servidor "dividido" (split), onde um canal que existia no outro lado da rede estava vazio, e ganhasse 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 assumisse um apelido (nick) que existia no outro lado da rede, o servidor derrubaria ambos os usuários ao se reunir (uma "colisão de nick"). Isso era frequentemente usado para "matar em massa" todos os usuários de um canal, criando assim canais "sem op" (opless), onde nenhum operador estava presente para lidar com abusos. Além de causar problemas dentro do IRC, isso encorajava as pessoas a realizar ataques de negação de serviço contra servidores de IRC para causar netsplits, dos quais eles abusariam em seguida.

As estratégias de nick delay (ND) e channel delay (CD) visam prevenir abusos atrasando reconexões e renomeações. Após um usuário se desconectar e o apelido se tornar disponível, ou um canal deixar de existir porque todos os seus usuários saíram (como acontece frequentemente durante um netsplit), o servidor não permitirá que nenhum usuário use esse apelido ou entre nesse canal até que um certo período de tempo (o delay ou atraso) tenha passado. A ideia por trás disso é que, mesmo que ocorra um netsplit, ele é inútil para um abusador porque ele não pode assumir o apelido ou ganhar o status de operador em um canal e, portanto, nenhuma colisão de apelido ou "fusão" de canal pode ocorrer. Até certo ponto, isso incomoda usuários legítimos, que podem ser forçados a usar brevemente um nome diferente após retornar (adicionar um sublinhado _ é popular).

O protocolo de timestamp é uma alternativa aos atrasos de nick/canal que resolve colisões usando prioridade baseada em tempo. Cada apelido e canal na rede recebe um timestamp  a data e a hora em que foi criado. Quando ocorre um netsplit, dois usuários em 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 TS, é derrubado; quando um canal colide, os membros (usuários no canal) são fundidos, mas os operadores de canal no lado "perdedor" da divisão perdem seu status de operador de canal.

O TS é um protocolo muito mais complicado que o ND/CD, tanto em design quanto em implementação, e apesar de ter passado por várias revisões, algumas implementações ainda apresentam problemas com "desyncs" (dessincronização, onde dois servidores na mesma rede discordam sobre o estado atual da rede) e por permitir muita tolerância ao que era 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 fundidos quando a divisão se reunisse, mesmo que os usuários que definiram esses modos tivessem perdido o status de operador de canal. Alguns servidores de IRC baseados em TS modernos também incorporaram alguma forma de ND e/ou CD além do timestamping na tentativa de coibir ainda mais os abusos.

A maioria das redes hoje usa a abordagem de timestamping. As discordâncias entre timestamp versus ND/CD fizeram com que vários servidores se separassem da EFnet e formassem a mais nova IRCnet. Após a separação, a EFnet mudou para um protocolo TS, enquanto a IRCnet usou ND/CD.

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

Se dois clientes com o mesmo apelido entrarem de lados diferentes de um netsplit ("colisão de nick"), o primeiro servidor a ver essa colisão forçará ambos os clientes a mudarem seu nick para seu UID, salvando assim ambos os clientes de serem 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

Software de cliente

editar
Esquema de uma rede IRC com clientes normais (verde), bots (azul) e bouncers (laranja)

Existem softwares de cliente para vários sistemas operacionais ou pacotes de software, bem como baseados na web ou dentro de jogos. Muitos clientes diferentes estão disponíveis para os diversos sistemas operacionais, incluindo Windows, Unix e Linux, macOS e sistemas operacionais móveis (como iOS e Android). No Windows, o mIRC é um dos clientes mais populares.[89] Algumas distribuições Linux vêm com um cliente IRC pré-instalado, como o Linux Mint, que vem com o HexChat.

Alguns programas que são extensíveis por meio 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 v.22.3 do Emacs. Portanto, qualquer plataforma que possa rodar o Emacs pode rodar o ERC.

Vários navegadores web possuem clientes IRC integrados, tais como:

  • Opera costumava ter um cliente, mas não suporta mais IRC.
  • Complemento ChatZilla para Mozilla Firefox (para Firefox 56 e anteriores; incluído como um componente nativo do SeaMonkey).

Clientes baseados na web, como o Mibbit e o KiwiIRC de código aberto, podem rodar na maioria dos navegadores.

Jogos como War§ow,[90] Unreal Tournament (até o Unreal Tournament 2004),[91] Uplink,[92] jogos baseados na Spring Engine, 0 A.D. e ZDaemon incluíram IRC.[93]

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

Um uso típico de bots no IRC é fornecer serviços de IRC 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 de IRC são usados para lançar ataques maliciosos, como negação de serviço, spam ou exploração de vulnerabilidades.[97]

Bouncer

editar

Um programa que roda como um daemon em um servidor e funciona como um proxy persistente é conhecido como BNC ou bouncer. O propósito é manter uma conexão com um servidor de IRC, agindo como um retransmissor entre o servidor e o cliente, ou simplesmente para atuar como um proxy.[carece de fontes?] Caso o cliente perca a conectividade de rede, o BNC pode permanecer conectado e arquivar todo o tráfego para entrega posterior, permitindo que o usuário retome sua sessão de IRC sem interromper sua conexão com o servidor.[98]

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

Para evitar que o cliente IRC seja encerrado quando a conexão ssh for fechada, o cliente pode ser executado dentro de um multiplexador de terminal, como o GNU Screen ou tmux, permanecendo assim conectado às redes IRC constantemente e capaz de registrar conversas em canais de interesse do usuário, ou para manter a presença de um canal na rede. Modelado a partir dessa configuração, em 2004 foi lançado um cliente IRC seguindo o modelo cliente-servidor, chamado Smuxi.[100][101]

Mecanismos de busca

editar

Existem inúmeros mecanismos de busca disponíveis para auxiliar o usuário a encontrar o que procura no IRC.[102][103] Geralmente, o mecanismo de busca consiste em duas partes: um "back-end" (ou "spider/crawler") e um "mecanismo de busca" front-end.

O back-end (spider/webcrawler) é o motor de trabalho do mecanismo de busca. Ele é responsável por rastrear os servidores de IRC para indexar as informações enviadas por eles. As informações indexadas geralmente consistem apenas no texto do canal (texto exibido publicamente em canais públicos). O método de armazenamento costuma ser algum tipo de banco de dados relacional, como MySQL ou Oracle.[carece de fontes?]

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

A maioria dos mecanismos de busca possui seu próprio spider, que é uma aplicação única responsável por rastrear o IRC e indexar os dados por si só; no entanto, outros são indexadores "baseados no usuário". Estes últimos dependem de usuários que instalam um "add-on" (complemento) em seu cliente IRC; o add-on é o que envia ao banco de dados as informações dos canais em que o usuário estiver no momento.[carece de fontes?]

Muitos usuários implementaram seus próprios mecanismos de busca ad hoc usando os recursos de log (registro) integrados em muitos clientes IRC. Esses mecanismos de busca são geralmente implementados como bots e dedicados a um canal específico ou grupo de canais associados.

Codificação de caracteres

editar

O IRC ainda carece de uma única convenção padrão aceita globalmente para a transmissão de caracteres fora do repertório ASCII de 7 bits. Os servidores de IRC normalmente[necessário esclarecer] transferem mensagens de um cliente para outro apenas como sequências de bytes, sem qualquer interpretação ou recodificação de caracteres. O protocolo IRC (ao contrário de, por exemplo, 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 caracteres apropriado no cliente. Na prática, os canais de IRC usaram amplamente as mesmas codificações de caracteres que também eram usadas pelos sistemas operacionais (em particular derivados do Unix) nas respectivas comunidades linguísticas:

  • Era de 7 bits: Nos primórdios do IRC, especialmente entre usuários de línguas germânicas do norte e da língua finlandesa, variantes nacionais do ISO 646 eram as codificações de caracteres dominantes. Estas codificam caracteres não-ASCII como Ä Ö Å ä ö å em posições de código 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D (US-ASCII: [ \ ] { | }). É por isso que esses códigos são sempre permitidos em nicknames. De acordo com a RFC 1459, { | } em nicknames devem ser tratados como equivalentes em minúsculas de [ \ ], respectivamente.[14] 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 removidos de alguns daemons de IRC.
  • Era de 8 bits: Desde o início da década de 1990, codificações de 8 bits, como ISO 8859-1, tornaram-se comumente usadas para línguas europeias. Usuários russos tinham a escolha de KOI8-R, ISO 8859-5[carece de fontes?] e CP1251, e desde cerca de 2000, as redes russas modernas de IRC convertem entre essas diferentes codificações comumente usadas do alfabeto cirílico.
  • Era de múltiplos bytes: Por muito tempo, os canais de IRC do Leste Asiático com escritas logográficas na China, Japão e Coreia usaram codificações de múltiplos bytes, 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 IRC são agora capazes de ler mensagens tanto em ISO 8859-1 quanto em UTF-8 no mesmo canal, detectando heuristicamente qual codificação está sendo usada. A mudança para o UTF-8 começou em particular no IRC de língua finlandesa (Merkistö (Finlandês)).

Hoje, a codificação UTF-8 do Unicode/ISO 10646 seria a candidata mais provável para um único padrão futuro de codificação de caracteres para toda a comunicação IRC, se tal padrão algum dia relaxasse a restrição de tamanho de mensagem de 510 bytes. O UTF-8 é compatível com ASCII e cobre o superconjunto de todos os outros padrões de conjuntos de caracteres codificados comumente usados.

Compartilhamento de arquivos

editar

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

Tecnicamente, o IRC não fornece mecanismos de transferência de arquivos por si só; o compartilhamento de arquivos é implementado pelos clientes de IRC, normalmente usando o protocolo Direct Client-to-Client (DCC), no qual as transferências de arquivos são negociadas através da troca de mensagens privadas entre os clientes. A grande maioria dos clientes IRC possui suporte para transferências de arquivos DCC, daí a visão de que o compartilhamento de arquivos é um recurso integral do IRC.[105] O uso comum deste protocolo, no entanto, às vezes também causa spam de DCC. Comandos DCC também foram usados para explorar clientes vulneráveis e forçá-los a realizar ações como desconectar do servidor ou fechar o cliente.

Ver também

editar

Citações

editar
  1. https://www.rfc-editor.org/rfc/rfc1459#section-3.2 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 11. sec. 3.2. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  2. https://www.rfc-editor.org/rfc/rfc2810#section-5.1 |section-url= missing title (ajuda). Internet Relay Chat: Architecture. p. 5. sec. 5.1. doi:10.17487/RFC2810Acessível livremente. RFC 2810
  3. Rollo, Troy. «A Description of the DCC Protocol». IRCHelp.org. Consultado em 8 de abril de 2011
  4. Wang, Wallace (25 de outubro de 2004). «Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)». Steal this File Sharing Book 1st ed. San Francisco, Califórnia: No Starch Press. pp. 61–67. ISBN 978-1-59327-050-6
  5. 1 2 3 «O IRC está morto, longa vida ao IRC». Pingdom. 24 de abril de 2012. Consultado em 25 de abril de 2016. Cópia arquivada em 15 de agosto de 2017
  6. «Redes de IRC – Top 100». irc.netsplit.de. Consultado em 29 de março de 2026
  7. 1 2 3 4 5 6 7 8 9 10 11 Stenberg, Daniel. «História do IRC (Internet Relay Chat)». Consultado em 25 de abril de 2016. Eu não vivenciei tudo isso. Coletei 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 (eagle`s na undernet), Ari Lemmke
  8. 1 2 Oikarinen, Jarkko. «Fundando o IRC». mIRC. Consultado em 8 de abril de 2011. Cópia arquivada em 27 de abril de 2011
  9. 1 2 «História do IRC (Internet Relay Chat)». daniel.haxx.se. Consultado em 22 de julho de 2023
  10. «Transcrições de IRC da época da tentativa de golpe de Estado soviético de 1991». Chapel Hill, Carolina do Norte: ibiblio. Consultado em 8 de abril de 2011. Cópia arquivada em 28 de junho de 2009
  11. «Logs de IRC de eventos da Guerra do Golfo». Chapel Hill, Carolina do Norte: ibiblio. Consultado em 8 de abril de 2011
  12. «Logs de grandes eventos na comunidade online». Chapel Hill, Carolina do Norte: ibiblio. Consultado em 8 de abril de 2011
  13. 1 2 3 https://www.rfc-editor.org/rfc/rfc1459#section-1 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 4. sec. 1. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  14. 1 2 3 https://www.rfc-editor.org/rfc/rfc1459#section-2.2 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 7. sec. 2.2. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  15. Engen, Vegard (maio de 2000). «A Grande Divisão». IRC.org. Consultado em 25 de abril de 2016
  16. «Channel Modes». UnrealIRCd documentation wiki. Consultado em 6 de janeiro de 2018
  17. «Cloaking». UnrealIRCd documentation wiki. Consultado em 6 de janeiro de 2018
  18. «Blitzed Open Proxy Monitor Encerra Atividades». O Open Proxy Monitor que tem sido fornecido pela rede Blitzed IRC foi encerrado… 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. Além disso, a maioria dos membros da equipe não possui mais tempo para manter o serviço funcionando.
  19. «IRCv3». IRCv3 Working Group. 2016. Consultado em 25 de abril de 2016. O Grupo de Trabalho IRCv3 é uma coleção de autores de software de cliente e servidor de IRC trabalhando para aprimorar, manter e padronizar o protocolo IRC usando extensões compatíveis com versões anteriores.
  20. «Redes - IRCv3». 2019. Consultado em 9 de agosto de 2019
  21. «Redes de IRC - em ordem alfabética». netsplit.de. Consultado em 12 de janeiro de 2022
  22. «Redes de IRC - Top 100». netsplit.de. Consultado em 12 de janeiro de 2022
  23. «netsplit.de top 10». Consultado em 15 de janeiro de 2021
  24. 1 2 Charalabidis, Alex (15 de dezembro de 1999). «IRCing On The Macintosh: Ircle». The Book of IRC: The Ultimate Guide to Internet Relay Chat 1st ed. San 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 você desconectar devido ao fluxo de informações, enquanto outros clientes geralmente conseguem realizar o feito, se você estiver em uma conexão Ethernet direta.
  25. 1 2 Jones, Steve, ed. (10 de dezembro de 2002). «Internet Relay Chat». Encyclopedia of New Media: An Essential Reference to Communication and Technology 1st ed. Thousand Oaks, Califórnia: SAGE Publications. 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.
  26. 1 2 Rittner, Don (3 de março de 1999). The iMac Book 1st ed. Scottsdale, Arizona: Coriolis Group. p. 215. ISBN 978-1-57610-429-3. Existem várias redes grandes: EFnet, UnderNET, DALnet e IRCnet compõem as Quatro Grandes.
  27. Turban, Efraim; Leidner, Dorothy; McLean, Ephraim; Wetherbe, James (7 de fevereiro de 2005). «Comunicação». Information Technology for Management: Transforming Organizations in the Digital Economy 5th ed. Hoboken, Nova Jersey: John Wiley & Sons. pp. 106 – 107. ISBN 978-0-471-70522-2. As maiores redes foram tradicionalmente agrupadas como as "Quatro Grandes": EFNet, IrcNet, QuakeNet e UnderNet.
  28. «Redes de IRC – Top 100». irc.netsplit.de. netsplit.de. Consultado em 15 de janeiro de 2021
  29. «hackint Network Statistics». Netsplit.de. Consultado em 29 de março de 2026
  30. «HybridIRC Network Statistics». Netsplit.de. Consultado em 29 de março de 2026
  31. https://www.rfc-editor.org/rfc/rfc1459#section-1.1 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 4. sec. 1.1. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  32. https://www.rfc-editor.org/rfc/rfc2810#section-2.2 |section-url= missing title (ajuda). Internet Relay Chat: Architecture. p. 3. sec. 2.2. doi:10.17487/RFC2810Acessível livremente. RFC 2810
  33. https://www.rfc-editor.org/rfc/rfc1459#section-1.2 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 5. sec. 1.2. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  34. «Port Numbers». Marina del Rey, Califórnia: Internet Assigned Numbers Authority. 6 de abril de 2011. Consultado em 5 de abril de 2021
  35. https://www.rfc-editor.org/rfc/rfc1459#section-4.3.5 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 29. sec. 4.3.5. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  36. Lucas, Mark; Singh, Abhishek; Cantrell, Chris (5 de outubro de 2006). «Defining a Firewall». In: Henmi, Anne. Firewall Policies and VPN Configurations. Rockland, Massachusetts: Syngress Publishing. p. 93. ISBN 978-1-59749-088-7
  37. Abraham, Dalen (junho de 1998). Extensions to the Internet Relay Chat Protocol (IRCX). IETF. I-D draft-pfenning-irc-extensions-04. Consultado em 8 de abril de 2011
  38. https://www.rfc-editor.org/rfc/rfc2810#section-3 |section-url= missing title (ajuda). Internet Relay Chat: Architecture. pp. 3 – 4. sec. 3. doi:10.17487/RFC2810Acessível livremente. RFC 2810
  39. https://www.rfc-editor.org/rfc/rfc2810#section-1 |section-url= missing title (ajuda). Internet Relay Chat: Architecture. p. 2. sec. 1. doi:10.17487/RFC2810Acessível livremente. RFC 2810
  40. https://www.rfc-editor.org/rfc/rfc1459#section-9.3 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 64. sec. 9.3. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  41. https://www.rfc-editor.org/rfc/rfc2810#section-6.3 |section-url= missing title (ajuda). Internet Relay Chat: Architecture. pp. 7 – 8. sec. 6.3. doi:10.17487/RFC2810Acessível livremente. RFC 2810
  42. https://www.rfc-editor.org/rfc/rfc2810#section-5.2.1 |section-url= missing title (ajuda). Internet Relay Chat: Architecture. pp. 5 – 6. sec. 5.2.1. doi:10.17487/RFC2810Acessível livremente. RFC 2810
  43. «IRC daemons para LAN». Consultado em 2 de outubro de 2014. Cópia arquivada em 6 de outubro de 2014
  44. «Rodando seu próprio servidor IRC». Consultado em 2 de outubro de 2014. Cópia arquivada em 6 de outubro de 2014
  45. https://www.rfc-editor.org/rfc/rfc1459#section-2.3.1 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 8. sec. 2.3.1. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  46. https://www.rfc-editor.org/rfc/rfc1459#section-2.4 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 10. sec. 2.4. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  47. IRC Chat Rooms
  48. «IRC List Modes – Extensão de modo de lista mostrando confusão de pares para listas». 25 de novembro de 2009. Consultado em 8 de abril de 2011
  49. 1 2 https://www.rfc-editor.org/rfc/rfc1459#section-3.2.2 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 11. sec. 3.2.2. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  50. https://www.rfc-editor.org/rfc/rfc1459#section-4.2.6 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 24. sec. 4.2.6. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  51. 1 2 https://www.rfc-editor.org/rfc/rfc1459#section-4.2.1 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 19. sec. 4.2.1. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  52. https://www.rfc-editor.org/rfc/rfc2811#section-2.2 |section-url= missing title (ajuda). Internet Relay Chat: Channel Management. pp. 3 – 4. sec. 2.2. doi:10.17487/RFC2811Acessível livremente. RFC 2811
  53. https://www.rfc-editor.org/rfc/rfc2811#section-2.3 |section-url= missing title (ajuda). Internet Relay Chat: Channel Management. p. 4. sec. 2.3. doi:10.17487/RFC2811Acessível livremente. RFC 2811
  54. https://www.rfc-editor.org/rfc/rfc2811#section-3 |section-url= missing title (ajuda). Internet Relay Chat: Channel Management. p. 5. sec. 3. doi:10.17487/RFC2811Acessível livremente. RFC 2811
  55. https://www.rfc-editor.org/rfc/rfc2811#section-4 |section-url= missing title (ajuda). Internet Relay Chat: Channel Management. p. 7. sec. 4. doi:10.17487/RFC2811Acessível livremente. RFC 2811
  56. https://www.rfc-editor.org/rfc/rfc1459#section-4.2.3 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 21. sec. 4.2.3. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  57. https://www.rfc-editor.org/rfc/rfc1459#section-4.2.3.1 |section-url= missing title (ajuda). Internet Relay Chat Protocol. pp. 21 – 22. sec. 4.2.3.1. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  58. https://www.rfc-editor.org/rfc/rfc2811#section-4.3 |section-url= missing title (ajuda). Internet Relay Chat: Channel Management. pp. 10 – 11. sec. 4.3. doi:10.17487/RFC2811Acessível livremente. RFC 2811
  59. 1 2 https://www.rfc-editor.org/rfc/rfc1459#page-51 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 51. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  60. Roeckx, Kurt (14 de outubro de 2004). «The 005 numeric: ISUPPORT». irc.org. Consultado em 10 de abril de 2011
  61. Brocklesby, Edward (setembro de 2002). IRC RPL_ISUPPORT Numeric Definition. IETF. I-D draft-brocklesby-irc-isupport-03. Consultado em 10 de abril de 2011
  62. «'multi-prefix' Extension - IRCv3»
  63. https://www.rfc-editor.org/rfc/rfc1459#section-5.6 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 41. sec. 5.6. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  64. Butcher, Simon (12 de janeiro de 2005). «IRC User Modes List». alien.net.au. Consultado em 10 de abril de 2011
  65. Butcher, Simon (12 de janeiro de 2005). «IRC Channel Modes List». alien.net.au. Consultado em 10 de abril de 2011
  66. Butcher, Simon (12 de janeiro de 2005). «IRC Server Modes List». alien.net.au. Consultado em 10 de abril de 2011
  67. Olsen, Tommy. «IRCd Modes». webtoman.com. Consultado em 10 de abril de 2011. Cópia arquivada em 15 de outubro de 2011
  68. 1 2 https://www.rfc-editor.org/rfc/rfc1459#section-1.2.1 |section-url= missing title (ajuda). Internet Relay Chat Protocol. p. 5. sec. 1.2.1. doi:10.17487/RFC1459Acessível livremente. RFC 1459
  69. Döring, Nicola; Schestag, Alexander (23 de setembro de 2003). «Soziele Norman in virtuellen Gruppen: ein empirische Analyse am Beispiel ausghewähiter Chat-Channels». In: Thiedeke, Udo. Virtuelle Gruppen: Charakteristika und Problemdimensionen (em alemão) 2nd ed. [S.l.: s.n.] pp. 314, 337. ISBN 978-3-531-33372-4. Consultado em 30 de março de 2010
  70. Rogers, Russ (1 de dezembro de 2004). «The Mind of Terror». In: Devost, Matthew G. Hacking a Terror Network: The Silent Threat of Covert Channels 1st ed. Rockland, Massachusetts: Syngress Publishing. p. 10. ISBN 978-1-928994-98-5. Consultado em 30 de março de 2010
  71. Petersen, Julie K., ed. (29 de maio de 2002). «Internet Relay Chat». The Telecommunications Illustrated Dictionary 2nd ed. [S.l.]: CRC Press. p. 500. ISBN 978-0-8493-1173-4. Consultado em 30 de março de 2010
  72. «Frequently-Asked Questions». freenode. Consultado em 30 de março de 2010. Cópia arquivada em 26 de março de 2010
  73. «IRC/Cloaks». Meta-wiki. Consultado em 27 de novembro de 2011
  74. «Uniform Resource Identifier (URI) Schemes». Internet Assigned Numbers Authority. Consultado em 14 de outubro de 2012
  75. Butcher, Simon (janeiro de 2003). Uniform Resource Locator Schemes for Internet Relay Chat Entities. IETF. I-D draft-butcher-irc-url-04. Consultado em 10 de abril de 2011
  76. «node-irc». npm. 26 de janeiro de 2020. Consultado em 30 de julho de 2021
  77. https://www.rfc-editor.org/rfc/rfc1324#section-2.5.1 |section-url= missing title (ajuda). A Discussion on Computer Network Conferencing. pp. 5 – 6. sec. 2.5.1. doi:10.17487/RFC1324Acessível livremente. RFC 1324
  78. https://www.rfc-editor.org/rfc/rfc2810#section-6.1 |section-url= missing title (ajuda). Internet Relay Chat: Architecture. p. 7. sec. 6.1. doi:10.17487/RFC2810Acessível livremente. RFC 2810
  79. Loesch 2003 1.2.1 Growth
  80. https://www.rfc-editor.org/rfc/rfc1324#section-5.4.1 |section-url= missing title (ajuda). A Discussion on Computer Network Conferencing. p. 10. sec. 5.4.1. doi:10.17487/RFC1324Acessível livremente. RFC 1324
  81. https://www.rfc-editor.org/rfc/rfc1324#section-5.4.2 |section-url= missing title (ajuda). A Discussion on Computer Network Conferencing. p. 10. sec. 5.4.2. doi:10.17487/RFC1324Acessível livremente. RFC 1324
  82. Loesch 2003 1.2.2 Network failures
  83. https://www.rfc-editor.org/rfc/rfc1324#section-2.1 |section-url= missing title (ajuda). A Discussion on Computer Network Conferencing. p. 4. sec. 2.1. doi:10.17487/RFC1324Acessível livremente. RFC 1324
  84. Loesch 2003 1.2.3 Sociological and security aspects
  85. https://www.rfc-editor.org/rfc/rfc1324#section-5.2.1 |section-url= missing title (ajuda). A Discussion on Computer Network Conferencing. p. 7. sec. 5.2.1. doi:10.17487/RFC1324Acessível livremente. RFC 1324
  86. https://www.rfc-editor.org/rfc/rfc1324#section-5.2.4 |section-url= missing title (ajuda). A Discussion on Computer Network Conferencing. p. 8. sec. 5.2.4. doi:10.17487/RFC1324Acessível livremente. RFC 1324
  87. «Getting Help on EsperNet». The EsperNet IRC Network. Consultado em 31 de julho de 2012
  88. brandon (18 de maio de 2010). «New Feature: SSL For Users». DALnet. Consultado em 31 de julho de 2012
  89. Smith, Roderick W. (8 de abril de 2000). «The Internet: Using IRC to Get Help». The Multi-Boot Configuration Handbook. Col: Handbook Series. Upper Saddle River, New Jersey: Que Publishing. p. 289. ISBN 978-0-7897-2283-6. Consultado em 25 de julho de 2010. mIRC is one of the most popular Windows IRC clients.
  90. «Warsow Wiki: IRC Module». Consultado em 10 de abril de 2011. Cópia arquivada em 25 de abril de 2011
  91. Guenter, Daniel (21 de junho de 2004). «UT2004 Review». BCCHardware. Consultado em 10 de abril de 2011
  92. «The Ultimate Uplink Guide». Consultado em 10 de abril de 2011
  93. «ZDaemon – The Doom Wiki: Other utilities». Consultado em 10 de abril de 2011
  94. «How to setup [sic] an IRC client to connect and login [sic] to Ustream». Ustream-Helpers. 29 de janeiro de 2012. Consultado em 27 de abril de 2013. Cópia arquivada em 21 de março de 2013
  95. Mauldor (20 de junho de 2010). «Ustream vs. Justin.tv». LiquidSilver. Consultado em 13 de julho de 2011
  96. «Twitch IRC». Twitch Help Center. 7 de abril de 2017. Consultado em 30 de outubro de 2017. Cópia arquivada em 12 de fevereiro de 2019
  97. Canavan, John. «The Evolution of Malicious IRC Bots» (PDF). Symantec. Symantec Security Response. Cópia arquivada (PDF) em 15 de março de 2006
  98. «psyBNC Readme». psybnc.at. Consultado em 10 de abril de 2011
  99. Carey, Chris (18 de julho de 2009). «IRC with irssi-proxy + screen». chriscarey.com. Consultado em 10 de abril de 2011
  100. «Detachable Frontend (Core Rewrite) / UML / Windows Port (kicking Glade)». smuxi.org. 25 de dezembro de 2004. Consultado em 25 de julho de 2010. Cópia arquivada em 28 de julho de 2011
  101. «About Smuxi». smuxi.org. Consultado em 10 de abril de 2011
  102. Mutton, Paul (27 de julho de 2004). «Users and Channels». IRC Hacks 1st ed. Sebastopol, California: O'Reilly Media. pp. 44–46. ISBN 978-0-596-00687-7
  103. Wang, Wallace (25 de outubro de 2004). «Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)». Steal this File Sharing Book 1st ed. San Francisco, California: No Starch Press. pp. 65–67. ISBN 978-1-59327-050-6
  104. Vamosi, Robert (8 de maio de 2002). «Pirated movies: Now playing on a server near you». ZDNet. Consultado em 10 de abril de 2011
  105. Sasaki, Darla (4 de abril de 2002). «IRC 101: What Is It & How Do I Use It?». Macobserver.com. Consultado em 10 de abril de 2011. Cópia arquivada em 6 de janeiro de 2012

Bibliografia geral

editar

Leitura adicional

editar

Ligações externas

editar
O Commons possui uma categoria com imagens e outros ficheiros sobre Internet Relay Chat