IRC (Internet Relay Chat)

Internet Relay Chat o IRC, en español chats retransmitidos por internet 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 IRC. La "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 explica Greg "wumpus" Lindahl: "tenía una línea de servidor comodín, por lo que la gente conectaba servidores y chocaba con todos". La "Red libre de Eris", EFnet, convirtió a la máquina eris en la primera en ser Q-lineada (Q para cuarentena) del IRC. En palabras de wumpus otra vez: "Eris se negó a eliminar esa línea, así que formé EFnet. No fue una gran 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.

Alrededor de ese tiempo, 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 sumergida

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 "undernetters" querían llevar ircd más allá 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 uno a uno y 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 varias implementaciones de servidores y clientes a divergir. 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). Alexei "Lefler" Kosut realizó modificaciones de DALnet ircd. Por lo tanto, DALnet se basó en el servidor ircd de Undernet, aunque los pioneros de DALnet abandonaron EFnet. Según James Ng, las personas iniciales de DALnet estaban "operaciones en #StarTrek enfermas por las constantes divisiones/retrasos/adquisiciones/etc".

DALnet ofreció rápidamente 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), solo comunicaciones IRCop: 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 sobre la lista de correo, hubo otra división debido al desacuerdo sobre cómo debería evolucionar el desarrollo del ircd. En particular, el lado "europeo" (la mayoría de esos servidores estaban en Europa) 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: la parte europea había comenzado a establecer un conjunto de reglas que indicaban lo que los IRCops podían y no podían hacer, un punto de vista al que se oponía la parte 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 los EE. UU. Este evento también se conoce como "La gran división" en muchas sociedades de 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 moderno

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

• Servicios: bots operados en red para facilitar el registro de apodos y canales, envío de mensajes para usuarios fuera de línea y funciones de operador de red.
• Modos adicionales: mientras que el sistema IRC original usaba un conjunto de modos estándar de usuario y canal, los nuevos servidores agregan muchos modos nuevos para funciones como eliminar códigos de color del texto u ocultar la máscara de host de un usuario ("encubrimiento") para protegerlo de la denegación. -ataques de servicio.
• Detección de proxy: la mayoría de los servidores modernos admiten la detección de usuarios que intentan conectarse a través de un servidor proxy inseguro (mal configurado o explotado), al que luego se le puede negar una conexión. Varias redes utilizan este software de detección de proxy, aunque esa lista de proxies en tiempo real ya no existe desde principios de 2006.
• Comandos adicionales: los nuevos comandos pueden ser cosas como comandos abreviados para enviar comandos a los servicios, comandos solo para operadores de red para manipular la máscara de host de un usuario.
• Cifrado: para el tramo cliente-servidor de la conexión, se puede usar TLS (los mensajes dejan de ser seguros una vez que se transmiten a otros usuarios en conexiones estándar, pero dificulta la escucha o las escuchas telefónicas de las sesiones de IRC de un individuo). Para la comunicación de cliente a cliente, se puede utilizar SDCC (Secure DCC).
• Protocolo de conexión: IRC se puede conectar a través de IPv4, la versión anterior del Protocolo de Internet, o mediante IPv6, el estándar actual del protocolo.

A partir de 2016, se está realizando un nuevo esfuerzo de estandarización 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.

A junio de 2021, se sabe que están operando 481 redes IRC diferentes, 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), el IRC ha experimentado un descenso significativo, perdiendo alrededor del 60 % de los usuarios entre 2003 y 2012, y los usuarios se han trasladado 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 cuadruplicado 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" fueron:

• EFnet
• IRCnet
• Undernet
• DALnet

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:

• Libera Chat: alrededor de 48,7 mil usuarios en las horas pico
• OFTC: alrededor de 19.400 usuarios en las horas pico
• IRCnet: alrededor de 17,9 mil usuarios en las horas pico
• Undernet: alrededor de 13.400 usuarios en las horas pico
• Rizon: alrededor de 10.500 usuarios en las horas pico
• EFnet: alrededor de 10.400 usuarios en las horas pico
• Freenode: alrededor de 9.300 usuarios en las horas pico
• QuakeNet: alrededor de 8400 usuarios en las horas pico
• DALnet: alrededor de 7900 usuarios en las horas pico

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:

• EFnet, 1990 al presente
• Undernet, 1992 al presente
• DALnet, 1994 al presente
• freenode, 1995 al presente
• IRCnet, 1996 al presente
• QuakeNet, 1997 al presente
• Comunidad Tecnológica Abierta y Libre, 2001 al presente
• Rizón, 2002 al presente
• Libera Chat, 2021 al presente

Información técnica

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, por ejemplo, el IRCd 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 la implementación irc2.10 llevaron 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 propietario IRCX. 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 de red y mensajes falsos para salir/unirse a los usuarios.y pérdida temporal de comunicación con los usuarios en los servidores de división. 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).

Un demonio IRC también se puede utilizar 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 prefijándolos con un '/'. 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 comunicación 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 LIST de IRC, 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 IRC tienen el prefijo '#', mientras que los locales de un servidor usan '&'. Otros tipos de canales menos comunes incluyen canales '+', canales 'sin modelo' 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 representados por letras individuales que distinguen entre mayúsculas y minúsculas y se configuran mediante 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 para invitados). un objetivo (usuario o canal), un conjunto de modos para configurar (+) o desactivar (-) 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 mensaje del cliente. 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 solo usuario. 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)

Carta	Símbolo	Descripción
i		Invisible: no se puede ver sin un canal común o sin saber el nombre exacto
s		Recibe avisos del servidor
w		Recibe golpes
o		El usuario es un operador de IRC (ircop)

Carta	Símbolo	Parámetros	Descripción
o	@	Nombre del usuario afectado	Operador de canal: puede cambiar los modos del canal y expulsar a los usuarios del canal, entre otras cosas.
s			Canal secreto: no se muestra en la lista de canales ni en el usuario whois, excepto para los usuarios que ya están en el canal.
pags			Canal privado: aparece en la lista de canales como "prv" según RFC 1459
norte			Los usuarios no pueden enviar mensajes al canal de forma externa
metro			El canal está moderado (solo aquellos que tienen un operador de canal o un estado de voz en el canal pueden enviarle mensajes)
i			Solo los usuarios con invitaciones pueden ingresar al canal.
t			Solo los operadores del canal pueden cambiar el tema del canal.
yo		número límite	Limita la cantidad de usuarios que pueden estar en el canal (cuando está lleno, no pueden unirse nuevos usuarios)
b		Máscara de prohibición (nick!user@host con comodines permitidos)	Prohíbe las máscaras de host del canal
v	+	Nombre del usuario afectado	Da un estado de voz de usuario en el canal (ver +m arriba)
k		Nueva clave de canal	Establece una clave de canal de modo que solo los usuarios que conocen la clave pueden ingresar

Muchos demonios y redes han agregado modos adicionales o han modificado el comportamiento de los modos en la lista anterior.

Operadores de canal

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:

• Patear a un usuario.
• Prohibir a un usuario.
• Otorgue a otro usuario el estado de operador del canal IRC o el estado de voz del canal IRC.
• Cambie el tema del canal IRC mientras el modo de canal +t está configurado.
• Cambie los bloqueos del modo de canal IRC.

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 1459afirma que los operadores de IRC son "un mal necesario" para mantener un estado limpio de la red y, como tales, 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 asuntos básicos de "propiedad". 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 en los que 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 apodo 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 de 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 el modo "+x" de UnrealIRCd. 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 "capas" para indicar que un usuario está afiliado a un grupo o proyecto.

Esquema URI

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

irc://<host>[:<puerto>]/[<canal>[?<canal_palabra clave>]]
ircs://<host>[:<puerto>]/[<canal>[?<canal_palabra clave>]]
irc6://<host>[:<puerto>]/[<canal>[?<canal_palabra clave>]]

(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 hash 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 resultará en un extra (generalmente 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 la cantidad de datos de estado compartidos que limitaban 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 por medio de enrutamiento cíclico, la compensación en escalabilidad en aras de la información de presencia del usuario en tiempo real, las debilidades del protocolo proporcionan una plataforma para el abuso, no hay paso de mensajes transparente y optimizable, y no hay encriptación. Algunos de estos problemas se han abordado en el IRC moderno.

Ataques

Debido a que las conexiones IRC pueden no estar cifradas y, por lo general, abarcan largos períodos de tiempo, son un objetivo atractivo para los atacantes DoS/DDoS y los piratas informáticos. 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 ofrece 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 las 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 los protocolos "Nick/Channel Delay" frente a "Timestamp". 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 a un servidor "dividido", donde un canal que existía en el otro lado de la red estaba vacío, y obtener el estado de operador, se convertiría en un operador de canal del canal "combinado" después de que finalice la división de red; 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 (un "

Las estrategias de demora de nick (ND) y demora de canal (CD) tienen como objetivo evitar 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 un cierto período de tiempo (la demora) ha pasado. 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 u obtener el estado de operador en un canal y, por lo tanto, no puede ocurrir una colisión de un apodo o una "fusión" de un canal. 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 utilizando la prioridad de marca de tiempo. A cada apodo y canal en 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 de canal del lado "perdedor" de la división pierden su condición 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 "desincronizaciones" (donde dos servidores en la misma red no están de acuerdo sobre el estado actual de la red). red), y permitir demasiada clemencia en lo que estaba permitido por el lado "perdedor". 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, a pesar de que 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.

La mayoría de las redes hoy en día 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 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 nick 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.

Clientela

Software de cliente

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 de 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, juegos basados ​​en Spring Engine, 0 AD y ZDaemon han incluido IRC.

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

Robots

Un uso típico de los bots en IRC es proporcionar servicios de IRC o una funcionalidad específica 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.

Bravucón

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 (típicamente 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 el usuario le interesa, 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.

Los 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" frontal 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 aplicación única responsable de rastrear el IRC e indexar los datos; sin embargo, otros son indexadores "basados ​​en el usuario". Estos últimos confían en que los usuarios instalen su "complemento" en su cliente 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:

• Era de 7 bits: en los primeros días de IRC, especialmente entre los usuarios de idiomas escandinavos y finlandeses, las variantes nacionales de ISO 646 eran las codificaciones de caracteres dominantes. Estos codifican caracteres que no son ASCII como Ä Ö Å ä ö å en las posiciones de código 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D (US-ASCII: [ ] { | }). Es por eso que estos códigos siempre se permiten en los apodos. Según RFC 1459, { | } en los apodos deben tratarse como equivalentes en minúsculas de [ ] respectivamente. A fines de la década de 1990, el uso de codificaciones de 7 bits había desaparecido en favor de ISO 8859-1, y tales asignaciones de equivalencia se eliminaron de algunos demonios IRC.
• Era de 8 bits: desde principios de la década de 1990, las codificaciones de 8 bits como ISO 8859-1 se han vuelto de uso común para los idiomas europeos. Los usuarios rusos tenían la opción de KOI8-R, ISO 8859-5 y CP1251, y desde aproximadamente el año 2000, las redes IRC rusas modernas convierten entre estas diferentes codificaciones comúnmente utilizadas del alfabeto cirílico.
• Era de varios bytes: durante mucho tiempo, los canales IRC de Asia oriental con guiones logográficos en China, Japón y Corea han estado utilizando codificaciones de varios bytes como EUC o ISO-2022-JP. Con la migración común de ISO 8859 a UTF-8 en plataformas Linux y Unix desde aproximadamente 2002, UTF-8 se ha convertido en un sustituto cada vez más popular para muchas de las codificaciones de 8 bits utilizadas anteriormente en los canales europeos. Algunos clientes de IRC ahora pueden leer mensajes en ISO 8859-1 o UTF-8 en el mismo canal, detectando automáticamente de forma heurística qué codificación se utiliza. El cambio a UTF-8 comenzó en particular en IRC de habla finlandesa (Merkistö (finlandés)).

Hoy en día, la codificación UTF-8 de Unicode/ISO 10646 sería el competidor más probable para una codificación de caracteres estándar futura ú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.

Compartición de archivos

Al igual que el intercambio de archivos P2P convencional, los usuarios pueden crear servidores de archivos que les permitan compartir archivos entre ellos mediante el uso de bots o scripts 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; Los clientes de IRC implementan el uso compartido de archivos, generalmente utilizando el protocolo Direct Client-to-Client (DCC), en el que las transferencias de archivos se negocian a través del 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.