Internet Relay Chat

Ajustar Compartir Imprimir Citar
El primer servidor IRC, tolsun.oulu.fi, un servidor Sun-3 en pantalla cerca del centro informático de la Universidad de Oulu

Internet Relay Chat (IRC) es un sistema de chat basado en texto para mensajería instantánea. IRC está diseñado para la comunicación grupal en foros de discusión, llamados canales, pero también permite la comunicación uno a uno a través de mensajes privados, así como el chat y la transferencia de datos, incluido el intercambio de archivos.

Internet Relay Chat se implementa como un protocolo de capa de aplicación para facilitar la comunicación en forma de texto. El proceso de chat funciona en un modelo de red cliente-servidor. Los usuarios se conectan mediante un cliente, que puede ser una aplicación web, un programa de escritorio independiente o integrado en parte de un programa más grande, a un servidor IRC, que puede ser parte de una red IRC más grande. Los ejemplos de programas utilizados para conectarse incluyen Mibbit, IRCCloud, KiwiIRC y mIRC.

El uso de IRC ha disminuido constantemente desde 2003, perdiendo el 60 por ciento de sus usuarios. En abril de 2011, las 100 principales redes de IRC atendían a más de medio millón de usuarios a la vez.

Historia

IRC fue creado por Jarkko Oikarinen en agosto de 1988 para reemplazar un programa llamado MUT (MultiUser Talk) en un BBS llamado OuluBox en la Universidad de Oulu en Finlandia, donde trabajaba en el Departamento de Ciencias de Procesamiento de la Información. Jarkko tenía la intención de ampliar el software BBS que administraba, para permitir noticias al estilo de Usenet, debates en tiempo real y características similares de BBS. La primera parte que implementó fue la parte del chat, que hizo con partes prestadas escritas por sus amigos Jyrki Kuoppala y Jukka Pihl. La primera red IRC se ejecutaba en un único servidor llamado tolsun.oulu.fi. Oikarinen se inspiró en un sistema de chat conocido como Bitnet Relay, que operaba en BITNET.

Jyrki Kuoppala presionó a Oikarinen para que le pidiera a la Universidad de Oulu que liberara el código IRC para que también pudiera ejecutarse fuera de Oulu, y después de que finalmente lo liberaron, Jyrki Kuoppala inmediatamente instaló otro servidor. Esta fue la primera "red IRC". Oikarinen hizo que algunos amigos de la Universidad de Helsinki y la Universidad de Tampere comenzaran a ejecutar servidores IRC cuando su número de usuarios aumentó y pronto le siguieron otras universidades. En ese momento, Oikarinen se dio cuenta de que el resto de las funciones de BBS probablemente no encajarían en su programa.

Oikarinen se puso en contacto con personas de la Universidad de Denver y la Universidad Estatal de Oregón. Tenían su propia red IRC funcionando y querían conectarse a la red finlandesa. Obtuvieron el programa de uno de los amigos de Oikarinen, Vijay Subramaniam, la primera persona no finlandesa en usar IRC. Luego, IRC creció y se usó en toda la red nacional finlandesa, FUNET, y luego se conectó a Nordunet, la rama escandinava de Internet. En noviembre de 1988, IRC se había extendido por Internet y, a mediados de 1989, había unos 40 servidores en todo el mundo.

EFnet

En agosto de 1990, tuvo lugar el primer gran desacuerdo en el mundo del IRC. El "A-net" (Anarchy net) incluía un servidor llamado eris.berkeley.edu. Todo estaba abierto, no requería contraseñas y no tenía límite en el número de conexiones. Como Greg 'wumpus' Lindahl explica: "Tenía una línea de servidor comodín, por lo que la gente estaba conectando servidores y nick-colisionando a todo el mundo". La "Eris Free Network", EFnet, convirtió a la máquina eris en la primera en recibir Q-line (Q de cuarentena) del IRC. En wumpus' palabras de nuevo: "Eris se negó a eliminar esa línea, así que formé EFnet. No fue mucha pelea; Conseguí que todos los centros se unieran, y casi todos los demás se dejaron llevar." A-net se formó con los servidores eris, mientras que EFnet se formó con los servidores que no son eris. El historial mostró que la mayoría de los servidores y usuarios optaron por EFnet. Una vez que A-net se disolvió, el nombre EFnet perdió sentido y una vez más fue la única red IRC.

Por esa época, IRC se utilizó para informar sobre el intento de golpe de estado soviético de 1991 durante un apagón mediático. Anteriormente se usó de manera similar durante la Guerra del Golfo. Los registros de chat de estos y otros eventos se guardan en el archivo de ibiblio.

Horquilla inferior

Otro esfuerzo de bifurcación, el primero que marcó una diferencia duradera, fue iniciado por "Wildthang" en los Estados Unidos en octubre de 1992. (Se bifurcó la versión 2.8.10 de EFnet ircd). Estaba destinado a ser solo una red de prueba para desarrollar bots, pero rápidamente se convirtió en una red 'para amigos y sus amigos'. En Europa y Canadá se estaba trabajando en una nueva red separada y en diciembre los servidores franceses se conectaron a los canadienses, y a finales de mes, la red francesa y canadiense se conectó a la de EE. UU., formando la red que luego vino que se llamará "The Undernet".

Los "intrusos" quería llevar a ircd más lejos en un intento de hacer que usara menos ancho de banda y tratar de resolver el caos de canales (netsplits y adquisiciones) que EFnet comenzó a sufrir. Para este último propósito, Undernet implementó marcas de tiempo, nuevas rutas y ofreció CService, un programa que permitía a los usuarios registrar canales y luego intentaba protegerlos de los alborotadores. La primera lista de servidores presentada, del 15 de febrero de 1993, incluye servidores de EE. UU., Canadá, Francia, Croacia y Japón. El 15 de agosto, el nuevo récord de conteo de usuarios se estableció en 57 usuarios.

En mayo de 1993, se publicó RFC 1459 y se detalla un protocolo simple para la operación cliente/servidor, canales, conversaciones de uno a uno y de uno a muchos. Cabe destacar que un número significativo de extensiones como CTCP, colores y formatos no están incluidos en las especificaciones del protocolo, ni tampoco la codificación de caracteres, lo que llevó a divergencias en varias implementaciones de servidores y clientes. La implementación del software varió significativamente de una red a otra, cada red implementó sus propias políticas y estándares en sus propias bases de código.

Horquilla DALnet

Durante el verano de 1994, Undernet se bifurcó. La nueva red se llamó DALnet (llamada así por su fundador: dalvenjah), formada para un mejor servicio al usuario y más protecciones para el usuario y el canal. Uno de los cambios más significativos en DALnet fue el uso de apodos más largos (el límite ircd original era de 9 letras). Las modificaciones de DALnet ircd fueron realizadas por Alexei "Lefler" Kosut. Por lo tanto, DALnet se basó en el servidor ircd de Undernet, aunque los pioneros de DALnet abandonaron EFnet. Según James Ng, la gente inicial de DALnet estaba 'opera en #StarTrek enferma por las constantes divisiones/retrasos/adquisiciones/etc'.

DALnet rápidamente ofreció WallOps globales (mensajes de IRCop que pueden ver los usuarios que son +w (/mode NickName +w)), apodos más largos, apodos Q:Lined (apodos que no se pueden usar, es decir, ChanServ, IRCop, NickServ, etc.), K:Lines globales (prohibición de una persona o un dominio completo de un servidor o de toda la red), comunicaciones IRCop únicamente: GlobOps, modo +H que muestra que un IRCop es un "helpop" etc. Gran parte de las nuevas funciones de DALnet fueron escritas a principios de 1995 por Brian "Morpher" Smith y permite a los usuarios poseer apodos, controlar canales, enviar notas y más.

Bifurcación IRCnet

En julio de 1996, después de meses de guerras y discusiones en la lista de correo, hubo otra división debido al desacuerdo sobre cómo debería evolucionar el desarrollo del ircd. En particular, el "Europeo" (la mayoría de esos servidores estaban en Europa) el lado que más tarde se autodenominó IRCnet abogó por los retrasos en los nicks y los canales, mientras que el lado de EFnet abogó por las marcas de tiempo. También hubo desacuerdos sobre las políticas: el lado europeo había comenzado a establecer un conjunto de reglas que ordenaban lo que los IRCops podían y no podían hacer, un punto de vista al que se oponía el lado estadounidense.

La mayoría (no todos) de los servidores de IRCnet estaban en Europa, mientras que la mayoría de los servidores de EFnet estaban en EE. UU. Este evento también se conoce como "The Great Split" en muchas sociedades IRC. Desde agosto de 1998, EFnet ha crecido y superado el número de usuarios que tenía entonces. En el otoño (norte) del año 2000, EFnet tenía unos 50.000 usuarios e IRCnet 70.000.

IRC moderna

(feminine)

IRC ha cambiado mucho durante su vida en Internet. El nuevo software de servidor ha agregado una multitud de características nuevas.

A partir de 2016, un nuevo esfuerzo de estandarización está en marcha bajo un grupo de trabajo llamado IRCv3, que se enfoca en funciones de cliente más avanzadas como notificaciones instantáneas, mejor soporte de historial y seguridad mejorada. A partir de 2019, ninguna de las principales redes de IRC ha adoptado por completo el estándar propuesto.

Hasta junio de 2021, hay 481 redes de IRC diferentes en funcionamiento, de las cuales Libera Chat, de código abierto, fundada en mayo de 2021, tiene la mayor cantidad de usuarios, con 20 374 canales en 26 servidores; entre ellas, las 100 principales redes IRC comparten más de 100 mil canales que operan en alrededor de mil servidores.

Después de su época dorada durante la década de 1990 y principios de la de 2000 (240.000 usuarios en QuakeNet en 2004), IRC ha experimentado un descenso significativo, perdiendo alrededor del 60 % de los usuarios entre 2003 y 2012, y los usuarios se están mudando a nuevas plataformas de redes sociales como Facebook. o Twitter, sino también a plataformas abiertas como XMPP, que se desarrolló en 1999. Ciertas redes como Freenode no han seguido la tendencia general y su tamaño se ha más que cuadriplicado durante el mismo período. Sin embargo, Freenode, que en 2016 tenía alrededor de 90.000 usuarios, desde entonces ha disminuido a unos 9.300 usuarios.

Las redes de IRC más grandes se han agrupado tradicionalmente como los 'Cuatro Grandes', una designación para las redes que encabezan las estadísticas. Las redes Big Four cambian periódicamente, pero debido a la naturaleza comunitaria de IRC, hay una gran cantidad de otras redes para que los usuarios elijan.

Históricamente, los "Cuatro Grandes" Somos:

IRC alcanzó 6 millones de usuarios simultáneos en 2001 y 10 millones de usuarios en 2003, cayendo a 371k en 2018.

A partir de enero de 2022, las redes de IRC más grandes son:

Las 100 principales redes de IRC tienen alrededor de 228 000 usuarios conectados en las horas pico.

Cronología

Cronología de los principales servidores:

Información técnica

Una captura de pantalla de HexChat, un cliente de IRC para entornos GTK
Irssi, un cliente de IRC basado en texto

IRC es un protocolo abierto que utiliza TCP y, opcionalmente, TLS. Un servidor IRC puede conectarse a otros servidores IRC para expandir la red IRC. Los usuarios acceden a las redes IRC conectando un cliente a un servidor. Hay muchas implementaciones de clientes, como mIRC, HexChat e irssi, e implementaciones de servidores, p. el IRC original. La mayoría de los servidores de IRC no requieren que los usuarios registren una cuenta, pero se requiere un apodo antes de conectarse.

IRC era originalmente un protocolo de texto sin formato (aunque luego se amplió), al que IANA le asignó el puerto 194/TCP a pedido. Sin embargo, el estándar de facto siempre ha sido ejecutar IRC en 6667/TCP y números de puerto cercanos (por ejemplo, puertos TCP 6660–6669, 7000) para evitar tener que ejecutar el software IRCd con privilegios de raíz.

El protocolo especificaba que los caracteres eran de 8 bits, pero no especificaba la codificación de caracteres que se suponía que debía utilizar el texto. Esto puede causar problemas cuando los usuarios que usan diferentes clientes y/o diferentes plataformas quieren conversar.

Todos los protocolos IRC de cliente a servidor que se usan hoy en día descienden del protocolo implementado en la versión irc2.4.0 del servidor IRC2 y documentado en RFC 1459. Desde que se publicó RFC 1459, las nuevas funciones en irc2. La implementación de 10 llevó a la publicación de varios documentos de protocolo revisados (RFC 2810, RFC 2811, RFC 2812 y RFC 2813); sin embargo, estos cambios de protocolo no se han adoptado ampliamente entre otras implementaciones.

Aunque se han publicado muchas especificaciones sobre el protocolo IRC, no existe una especificación oficial, ya que el protocolo sigue siendo dinámico. Prácticamente ningún cliente y muy pocos servidores confían estrictamente en los RFC anteriores como referencia.

Microsoft hizo una extensión para IRC en 1998 a través del IRCX patentado. Más tarde dejaron de distribuir software compatible con IRCX y, en cambio, desarrollaron el MSNP patentado.

La estructura estándar de una red de servidores IRC es un árbol. Los mensajes se enrutan solo a lo largo de las ramas necesarias del árbol, pero el estado de la red se envía a cada servidor y, en general, existe un alto grado de confianza implícita entre los servidores. Sin embargo, esta arquitectura tiene una serie de problemas. Un servidor malintencionado o que se comporta mal puede causar un daño importante a la red y cualquier cambio en la estructura, ya sea intencional o como resultado de las condiciones en la red subyacente, requiere una división de red y una unión de red. Esto da como resultado una gran cantidad de tráfico en la red y mensajes falsos para salir o unirse a los usuarios y una pérdida temporal de comunicación con los usuarios en los servidores divididos. Agregar un servidor a una red grande significa una gran carga de ancho de banda en segundo plano en la red y una gran carga de memoria en el servidor. Sin embargo, una vez establecido, cada mensaje a múltiples destinatarios se entrega de manera similar a la multidifusión, lo que significa que cada mensaje viaja por un enlace de red exactamente una vez. Esta es una fortaleza en comparación con los protocolos que no son de multidifusión, como el Protocolo simple de transferencia de correo (SMTP) o el Protocolo extensible de mensajería y presencia (XMPP).

También se puede usar un demonio IRC en una red de área local (LAN). Por lo tanto, IRC se puede utilizar para facilitar la comunicación entre personas dentro de la red de área local (comunicación interna).

Comandos y respuestas

IRC tiene una estructura basada en líneas. Los clientes envían mensajes de una sola línea al servidor, reciben respuestas a esos mensajes y reciben copias de algunos mensajes enviados por otros clientes. En la mayoría de los clientes, los usuarios pueden ingresar comandos con el prefijo '/'. Dependiendo del comando, estos pueden ser manejados completamente por el cliente o (generalmente para los comandos que el cliente no reconoce) pasados directamente al servidor, posiblemente con alguna modificación.

Debido a la naturaleza del protocolo, los sistemas automatizados no siempre pueden emparejar correctamente un comando enviado con su respuesta con total confiabilidad y están sujetos a conjeturas.

Canales

El medio básico de comunicarse con un grupo de usuarios en una sesión de IRC establecida es a través de un canal. Los canales en una red se pueden mostrar usando el comando IRC LIST, que enumera todos los canales actualmente disponibles que no tienen los modos +s o +p configurados, en esa red en particular.

Los usuarios pueden unirse a un canal usando el comando JOIN, en la mayoría de los clientes disponible como /join #channelname. Los mensajes enviados a los canales unidos luego se retransmiten a todos los demás usuarios.

Los canales que están disponibles en toda una red de IRC tienen el prefijo '#', mientras que los canales locales de un servidor usan '&'. Otros tipos de canales menos comunes incluyen '+' canales: 'sin modelo' canales sin operadores—y '!' canales, una forma de canal con marca de tiempo en redes normalmente sin marca de tiempo.

Modos

Los usuarios y los canales pueden tener modos que se representan con letras individuales que distinguen entre mayúsculas y minúsculas y se configuran con el comando MODE. Los modos de usuario y los modos de canal están separados y pueden usar la misma letra para significar cosas diferentes (por ejemplo, el modo de usuario 'i' es un modo invisible mientras que el modo de canal 'i' es solo por invitación). Los modos son por lo general, se arma y desarma usando el comando de modo que toma un objetivo (usuario o canal), un conjunto de modos para armar (+) o desarmar (-) y cualquier parámetro que necesiten los modos.

Algunos modos de canal toman parámetros y otros modos de canal se aplican a un usuario en un canal o agregan o eliminan una máscara (por ejemplo, una máscara de prohibición) de una lista asociada con el canal en lugar de aplicar al canal como un todo. Los modos que se aplican a los usuarios en un canal tienen un símbolo asociado que se usa para representar el modo en las respuestas de nombres (enviadas a los clientes al unirse por primera vez a un canal y usar el comando de nombres) y en muchos clientes también se usa para representarlo en el cliente. #39;s muestra la lista de usuarios en un canal o para mostrar un indicador propio para los modos de un usuario.

Para analizar correctamente los mensajes de modo entrantes y rastrear el estado del canal, el cliente debe saber qué modo es de qué tipo y para los modos que se aplican a un usuario en un canal, qué símbolo va con qué letra. En las primeras implementaciones de IRC, esto tenía que estar codificado en el cliente, pero ahora hay una extensión estándar de facto para el protocolo llamada ISUPPORT que envía esta información al cliente en el momento de la conexión usando el número 005.

Hay una pequeña falla de diseño en IRC con respecto a los modos que se aplican a los usuarios en los canales: el mensaje de nombres que se usa para establecer el estado inicial del canal solo puede enviar uno de esos modos por usuario en el canal, pero se pueden establecer múltiples modos en un mismo canal. usuario unico. Por ejemplo, si un usuario tiene el estado de operador (+o) y el estado de voz (+v) en un canal, un nuevo cliente no podrá ver el modo con menos prioridad (es decir, voz). Las soluciones alternativas para esto son posibles tanto en el lado del cliente como en el del servidor, pero ninguna está ampliamente implementada.

Modos estándar (RFC 1459)

Modos de usuario
Carta Signatura Descripción
iInvisible—no se puede ver sin un canal común o sabiendo el nombre exacto
sRecibe avisos del servidor
wRecibe linops
oEl usuario es un operador IRC (ircop)
Modos de canales
Carta Signatura Parámetro(s) Descripción
o@ Nombre del usuario afectado Operador de canales - puede cambiar los modos de canal y echar a los usuarios del canal entre otras cosas
sCanal secreto - no se muestra en la lista de canales o usuario whois excepto a los usuarios ya en el canal
pCanal privado: lista en lista de canales como "prv" según RFC 1459
nLos usuarios no pueden enviar mensajes al canal externamente
mEl canal es moderado (sólo aquellos que tienen el operador de canal o el estado de voz en el canal pueden enviar mensajes a él)
iSólo los usuarios con invitaciones pueden entrar en el canal.
tSólo los operadores de canales pueden cambiar el tema del canal.
lNúmero de límite Limita el número de usuarios capaces de estar en el canal (cuando esté lleno, no se pueden unir nuevos usuarios)
bBan mask (nick!user@host con comodines permitidos) Bans hostmasks del canal
v+ Nombre del usuario afectado Da un estado de voz de usuario en el canal (ver +m arriba)
kNueva clave de canal Establece una clave de canal tal que sólo los usuarios que conocen la clave pueden entrar

Muchos demonios y redes agregaron modos adicionales o modificaron el comportamiento de los modos en la lista anterior.

Operadores de canales

Un operador de canal es un cliente en un canal IRC que administra el canal. Los operadores de canales de IRC se pueden ver fácilmente con un símbolo o ícono junto a su nombre (varía según la implementación del cliente, comúnmente un prefijo de símbolo "@", un círculo verde o una letra latina "+ o"/"o"). En la mayoría de las redes, un operador puede:

Operadores de IRC

También hay usuarios que mantienen derechos elevados en su servidor local o en toda la red; estos se denominan operadores de IRC, a veces abreviados como IRCops u Operadores (que no deben confundirse con los operadores de canales). A medida que varía la implementación del IRCd, también lo hacen los privilegios del operador del IRC en el IRCd dado. RFC 1459 afirma que los operadores de IRC son "un mal necesario" para mantener un estado limpio de la red y, como tal, deben poder desconectar y volver a conectar los servidores. Además, para evitar que usuarios maliciosos o incluso programas automatizados dañinos ingresen a IRC, los operadores de IRC generalmente pueden desconectar clientes y prohibir completamente las direcciones IP o subredes completas. Las redes que transportan servicios (NickServ et al.) generalmente permiten que sus operadores de IRC también manejen la "propiedad" básica; asuntos. Otros derechos privilegiados pueden incluir la anulación de prohibiciones de canales (poder unirse a canales a los que no se les permitiría unirse, si no estuvieran operados), poder operarse en canales donde no podrían hacerlo sin ser operados, ser operados automáticamente en los canales siempre y así sucesivamente.

Máscaras de host

Una máscara de host es un identificador único de un cliente IRC conectado a un servidor IRC. Los servidores, servicios y otros clientes de IRC, incluidos los bots, pueden usarlo para identificar una sesión de IRC específica.

El formato de una máscara de host es nick!user@host. La máscara de host tiene un aspecto similar, pero no debe confundirse con una dirección de correo electrónico.

La parte del nick es el nick elegido por el usuario y se puede cambiar mientras está conectado. La parte del usuario es el nombre de usuario informado por ident en el cliente. Si ident no está disponible en el cliente, el nombre de usuario especificado cuando el cliente se conectó se usa después de tener un prefijo con una tilde.

La parte del host es el nombre del host desde el que se conecta el cliente. Si el servidor no puede resolver la dirección IP del cliente en un nombre de host válido, se utiliza en lugar del nombre de host.

Debido a las implicaciones de privacidad de exponer la dirección IP o el nombre de host de un cliente, algunos demonios de IRC también brindan funciones de privacidad, como InspIRCd o UnrealIRCd's "+x" modo. Esto reduce la dirección IP de un cliente o enmascara parte del nombre de host de un cliente, haciéndolo ilegible para otros usuarios que no sean IRCops. Los usuarios también pueden tener la opción de solicitar un "host virtual" (o "vhost"), que se mostrará en la máscara de host para permitir un mayor anonimato. Algunas redes de IRC, como Libera Chat o Freenode, las usan como "encubrimiento" para indicar que un usuario está afiliado a un grupo o proyecto.

Esquema de URI

Hay tres esquemas provisionales de identificadores uniformes de recursos (URI) para Internet Relay Chat: irc, ircs y irc6. Cuando son compatibles, permiten hipervínculos de varias formas, incluidos 

irc:// signhost confidencial[: consignaport título]/[traducido manualmente]
ircs:// efectuahost confidencial[: hiciera referencia]/[secciónchannel] [?
irc6:// efectuahost confidencial[: indicaport título]/[traducido] [traducido]:

(donde los elementos encerrados entre corchetes ([,]) son opcionales) para usarse (si es necesario) para conectarse al host especificado (o red, si el cliente de IRC lo conoce) y unirse al canal especificado. (Esto se puede usar dentro del propio cliente o desde otra aplicación, como un navegador web). irc es el URI predeterminado, irc6 especifica una conexión que se realizará mediante IPv6 e ircs especifica una conexión segura.

Según la especificación, el símbolo de almohadilla habitual (#) se antepondrá a los nombres de los canales que comienzan con un carácter alfanumérico, lo que permite omitirlo. Algunas implementaciones (por ejemplo, mIRC) lo harán incondicionalmente, lo que dará como resultado un extra (por lo general no deseado) (por ejemplo, ##canal), si se incluye en la URL.

Algunas implementaciones permiten especificar múltiples canales, separados por comas.

Desafíos

Los problemas en el diseño original de IRC eran que la cantidad de datos de estado compartidos era una limitación en su escalabilidad, la ausencia de identificaciones de usuario únicas que conducían al problema de la colisión de apodos, la falta de protección contra divisiones de red mediante enrutamiento cíclico, el comercio -off en la escalabilidad por el bien de la información de presencia del usuario en tiempo real, las debilidades del protocolo proporcionan una plataforma para el abuso, sin paso de mensajes transparente y optimizable, y sin cifrado. Algunos de estos problemas se han abordado en Modern IRC.

Ataques

Debido a que las conexiones IRC pueden no estar encriptadas y, por lo general, abarcan largos períodos de tiempo, son un objetivo atractivo para los piratas informáticos y los atacantes DoS/DDoS. Debido a esto, es necesaria una política de seguridad cuidadosa para garantizar que una red IRC no sea susceptible a un ataque como una guerra de adquisición. Las redes IRC también pueden tener usuarios o servidores K-line o G-line que tengan un efecto dañino.

Algunos servidores IRC admiten conexiones SSL/TLS por motivos de seguridad. Esto ayuda a detener el uso de programas rastreadores de paquetes para obtener las contraseñas de los usuarios de IRC, pero tiene poca utilidad más allá de este alcance debido a la naturaleza pública de los canales de IRC. Las conexiones SSL requieren compatibilidad tanto con el cliente como con el servidor (lo que puede requerir que el usuario instale archivos binarios SSL y parches o módulos específicos del cliente IRC en sus computadoras). Algunas redes también usan SSL para las conexiones de servidor a servidor y proporcionan un indicador de canal especial (como +S) para permitir solo a los usuarios conectados a SSL en el canal, mientras que no permite la identificación del operador en texto claro., para aprovechar mejor las ventajas que proporciona SSL.

IRC sirvió como un laboratorio inicial para muchos tipos de ataques de Internet, como el uso de mensajes ICMP inalcanzables falsos para romper las conexiones IRC basadas en TCP (armas nucleares) para molestar a los usuarios o facilitar adquisiciones.

Prevención del abuso

Uno de los problemas técnicos más polémicos en torno a las implementaciones de IRC, que sobrevive hasta el día de hoy, es el mérito de "Nick/Channel Delay" vs. "Marca de tiempo" protocolos Ambos métodos existen para resolver el problema de los ataques de denegación de servicio, pero adoptan enfoques muy diferentes. El problema con el protocolo IRC original implementado era que cuando dos servidores se dividían y volvían a unirse, los dos lados de la red simplemente fusionaban sus canales. Si un usuario pudiera unirse en un "split" servidor, donde un canal que existía en el otro lado de la red estaba vacío y ganaba el estatus de operador, se convertiría en un operador de canal del "combinado" canal después de que finalizó el netsplit; si un usuario tomaba un apodo que existía en el otro lado de la red, el servidor mataría a ambos usuarios al volver a unirse (una "colisión de nick"). A menudo se abusaba de esto para "matar en masa" todos los usuarios en un canal, creando así "opless" canales en los que no había operadores presentes para hacer frente a los abusos. Además de causar problemas dentro de IRC, esto alentó a las personas a realizar ataques de denegación de servicio contra los servidores de IRC para causar netsplits, de los que luego abusarían.

Las estrategias nick delay (ND) y channel delay (CD) tienen como objetivo prevenir el abuso al retrasar las reconexiones y los cambios de nombre. Después de que un usuario cierra la sesión y el apodo está disponible, o un canal deja de existir porque todos sus usuarios se separaron (como sucede a menudo durante un netsplit), el servidor no permitirá que ningún usuario use ese apodo o se una a ese canal, hasta que pase cierto tiempo. transcurrido un período de tiempo (el retraso). La idea detrás de esto es que incluso si ocurre una división de red, es inútil para un abusador porque no puede tomar el apodo ni obtener el estado de operador en un canal y, por lo tanto, no hay colisión de un apodo o "fusión" de un canal puede ocurrir. Hasta cierto punto, esto incomoda a los usuarios legítimos, que podrían verse obligados a usar brevemente un nombre diferente después de volver a unirse (es popular agregar un guión bajo).

El protocolo de marca de tiempo es una alternativa a los retrasos de nick/canal que resuelve las colisiones usando la prioridad de marca de tiempo. A cada apodo y canal de la red se le asigna una marca de tiempo: la fecha y la hora en que se creó. Cuando se produce un netsplit, dos usuarios de cada lado pueden usar el mismo apodo o canal, pero cuando se unen los dos lados, solo uno puede sobrevivir. En el caso de los apodos, el usuario más nuevo, según su TS, muere; cuando un canal colisiona, los miembros (usuarios del canal) se fusionan, pero los operadores del canal en el "perdedor" lado de la división pierden su estatus de operador de canal.

TS es un protocolo mucho más complicado que ND/CD, tanto en diseño como en implementación y, a pesar de haber pasado por varias revisiones, algunas implementaciones todavía tienen problemas con las "desincronizaciones" (donde dos servidores en la misma red no están de acuerdo sobre el estado actual de la red), y permitir demasiada clemencia en lo que estaba permitido por el "perder" lado. Bajo los protocolos originales de TS, por ejemplo, no había protección contra los usuarios que establecían prohibiciones u otros modos en el canal perdedor que luego se fusionarían cuando la división se reincorporara, aunque los usuarios que habían establecido esos modos perdieron su estado de operador de canal. Algunos servidores IRC modernos basados en TS también han incorporado alguna forma de ND y/o CD además de la marca de tiempo en un intento de frenar aún más el abuso.

Actualmente, la mayoría de las redes utilizan el enfoque de sellado de tiempo. Los desacuerdos entre la marca de tiempo y el ND/CD hicieron que varios servidores se separaran de EFnet y formaran la nueva IRCnet. Después de la división, EFnet pasó a un protocolo TS, mientras que IRCnet usó ND/CD.

En las versiones recientes del ircd de IRCnet, así como en los ircd que usan el protocolo TS6 (incluido Charybdis), ND se ha ampliado/reemplazado por un mecanismo llamado SAVE. Este mecanismo asigna a cada cliente un UID al conectarse a un servidor IRC. Esta ID comienza con un número, que está prohibido en los nicks (aunque algunos ircd, a saber, IRCnet e InspIRCd, permiten a los clientes cambiar a su propia UID como nick).

Si dos clientes con el mismo apodo se unen desde diferentes lados de un netsplit ("colisión de nick"), el primer servidor que vea esta colisión obligará a ambos clientes a cambiar su nick a su UID, evitando así que ambos clientes se desconecten. En IRCnet, el apodo también se bloqueará durante algún tiempo (ND) para evitar que ambos clientes vuelvan a cambiar al apodo original y, por lo tanto, vuelvan a chocar.

Clientes

Software de cliente

Esquema de una red IRC con clientes normales (verde), bots (azul) y bouncers (orange)

Existe software de cliente para varios sistemas operativos o paquetes de software, así como para juegos internos o basados en la web. Muchos clientes diferentes están disponibles para los distintos sistemas operativos, incluidos Windows, Unix y Linux, macOS y sistemas operativos móviles (como iOS y Android). En Windows, mIRC es uno de los clientes más populares.

Algunos programas que son extensibles a través de complementos también sirven como plataformas para clientes IRC. Por ejemplo, un cliente llamado ERC, escrito completamente en Emacs Lisp, está incluido en la versión 22.3 de Emacs. Por lo tanto, cualquier plataforma que pueda ejecutar Emacs puede ejecutar ERC.

Varios navegadores web tienen clientes IRC integrados, como Opera (versión 12.18 y anterior) y el complemento ChatZilla para Mozilla Firefox (para Firefox 56 y anterior; incluido como componente integrado de SeaMonkey). Los clientes basados en web, como Mibbit y KiwiIRC de código abierto, pueden ejecutarse en la mayoría de los navegadores.

Juegos como War§ow, Unreal Tournament (hasta Unreal Tournament 2004), Uplink, Spring Engine, 0 A.D. y ZDaemon han incluido IRC.

La interfaz de chat de Ustream es IRC con autenticación personalizada, así como la de Twitch (antes Justin.tv).

Botes

Un uso típico de los bots en IRC es proporcionar servicios de IRC o funciones específicas dentro de un canal, como alojar un juego basado en chat o proporcionar notificaciones de eventos externos. Sin embargo, algunos bots de IRC se utilizan para lanzar ataques maliciosos como denegación de servicio, spam o explotación.

Rebotador

Un programa que se ejecuta como un demonio en un servidor y funciona como un proxy persistente se conoce como BNC o bouncer. El propósito es mantener una conexión con un servidor IRC, actuando como un repetidor entre el servidor y el cliente, o simplemente actuar como un proxy. Si el cliente pierde la conectividad de la red, el BNC puede permanecer conectado y archivar todo el tráfico para su entrega posterior, lo que permite al usuario reanudar su sesión de IRC sin interrumpir su conexión con el servidor.

Además, como una forma de obtener un efecto tipo bouncer, se puede ejecutar un cliente IRC (normalmente basado en texto, por ejemplo, Irssi) en un servidor siempre activo al que el usuario se conecta a través de ssh. Esto también permite que los dispositivos que solo tienen la funcionalidad ssh, pero que no tienen instalado un cliente de IRC real, se conecten al IRC y permite compartir sesiones de IRC.

Para evitar que el cliente de IRC se cierre cuando se cierra la conexión ssh, el cliente puede ejecutarse dentro de un multiplexor de terminal como GNU Screen o tmux, permaneciendo así conectado a la(s) red(es) de IRC constantemente y pudiendo registrar conversaciones en los canales que le interese al usuario, o para mantener la presencia de un canal en la red. Siguiendo el modelo de esta configuración, en 2004 se lanzó un cliente IRC que seguía al cliente-servidor, llamado Smuxi.

Motores de búsqueda

Existen numerosos motores de búsqueda disponibles para ayudar al usuario a encontrar lo que busca en IRC. Generalmente, el motor de búsqueda consta de dos partes, un "back-end" (o "spider/crawler") y un "motor de búsqueda" frontal.

El back-end (spider/webcrawler) es el caballo de batalla del motor de búsqueda. Es responsable de rastrear los servidores IRC para indexar la información que se envía a través de ellos. La información que se indexa generalmente consiste únicamente en el texto del canal (texto que se muestra públicamente en los canales públicos). El método de almacenamiento suele ser algún tipo de base de datos relacional, como MySQL u Oracle.

El "motor de búsqueda" es la interfaz de usuario de la base de datos. Proporciona a los usuarios una forma de buscar en la base de datos de información indexada para recuperar los datos que están buscando. Estos motores de búsqueda front-end también se pueden codificar en numerosos lenguajes de programación.

La mayoría de los motores de búsqueda tienen su propia araña, que es una única aplicación responsable de rastrear el IRC e indexar los datos; sin embargo, otros están "basados en el usuario" indexadores. Estos últimos confían en que los usuarios instalen su "complemento" a su cliente de IRC; el complemento es lo que envía a la base de datos la información del canal de cualquier canal en el que se encuentre el usuario.

Muchos usuarios han implementado sus propios motores de búsqueda ad hoc utilizando las funciones de registro integradas en muchos clientes de IRC. Estos motores de búsqueda generalmente se implementan como bots y se dedican a un canal en particular o a un grupo de canales asociados.

Codificación de caracteres

IRC todavía carece de una única convención estándar globalmente aceptada sobre cómo transmitir caracteres fuera del repertorio ASCII de 7 bits. Los servidores IRC normalmente transfieren mensajes de un cliente a otro cliente como secuencias de bytes, sin ninguna interpretación o recodificación de caracteres. El protocolo IRC (a diferencia de, por ejemplo, MIME o HTTP) carece de mecanismos para anunciar y negociar opciones de codificación de caracteres. Esto ha puesto la responsabilidad de elegir el códec de caracteres apropiado en el cliente. En la práctica, los canales de IRC han utilizado en gran medida las mismas codificaciones de caracteres que también utilizaron los sistemas operativos (en particular, los derivados de Unix) en las respectivas comunidades lingüísticas:

Hoy en día, la codificación UTF-8 de Unicode/ISO 10646 sería el competidor más probable para una futura codificación de caracteres estándar única para todas las comunicaciones IRC, si tal estándar alguna vez relajara la restricción de tamaño de mensaje de 510 bytes. UTF-8 es compatible con ASCII y cubre el superconjunto de todos los demás estándares de conjuntos de caracteres codificados de uso común.

Compartir archivos

Al igual que el uso compartido de archivos P2P convencional, los usuarios pueden crear servidores de archivos que les permitan compartir archivos entre ellos mediante el uso de bots o secuencias de comandos de IRC personalizados para su cliente de IRC. A menudo, los usuarios se agrupan para distribuir warez a través de una red de bots de IRC.

Técnicamente, IRC no proporciona ningún mecanismo de transferencia de archivos; El uso compartido de archivos lo implementan los clientes de IRC, normalmente utilizando el protocolo Direct Client-to-Client (DCC), en el que las transferencias de archivos se negocian mediante el intercambio de mensajes privados entre clientes. La gran mayoría de los clientes de IRC cuentan con soporte para transferencias de archivos DCC, de ahí la opinión de que compartir archivos es una característica integral de IRC. Sin embargo, el uso común de este protocolo a veces también genera spam DCC. Los comandos DCC también se han utilizado para explotar clientes vulnerables y realizar una acción como desconectarse del servidor o salir del cliente.