reliable discord client irc daemon
1.0.0
Tabla de contenido
Descripción
ADVERTENCIA
Características
Limitaciones
Uso
Información de la función miscal
Consejos y trucos aleatorios
Campo de golf
Más información sobre el bloqueo de clientes de terceros
API e notas de implementación
RDIRCD es un demonio que permite usar una cuenta de discordia personal a través de un cliente IRC.
Traduce todos los chats privados y canales públicos/hilos en "servidores de discordia" en canales en un servidor IRC que crea y que puede conectarse con el uso de un cliente IRC regular, en lugar de un navegador o aplicación de electrones.
"Confiable" está en el nombre porque uno de los objetivos iniciales era hacer que confirme la entrega de mensajes y notificar sobre cualquier problema en ese sentido, que faltaba algo en otros clientes similares en ese momento.
Hay un canal IRC para hablar sobre la cosa: únase a #RDircd en Libera.Chat.
IRC URL: IRCS: //irc.libera.chat/rdircd (GitHub se niega a hacer ircs: // enlaces)
Consulte también la sección de enlaces a continuación para obtener una lista raramente actualizada de otros clientes alternativos.
URL de repositorio:
El último tiene git-notas con la lista de TODO y tal en la referencia predeterminada para aquellos.
Si bien no llamaría a esta aplicación un "bot" o "automatización de cuentas de usuario estándar", la intención aquí no es publicar ningún mensaje automatizado ni raspar, bastante seguro de que el personal de discordia considera que todos los clientes de terceros de terceros sean "bots" para que los admiradores sean separados por cada cano de discordia de Bot vs, que sean los cuentas API), que se encuentren en cada cuento de discordia, en cada cuenta de discordia, en cada cuenta de Connected, que se conecta, se debe ser separado por cada vez en cada cuenta de Connected. para un usuario aleatorio que no es de administración.
Esta aplicación no se presenta como un "bot" y no usa puntos finales específicos de BOT, por lo que usarla puede resultar en la terminación de la cuenta si se descubre.
Consulte también más información sobre la sección de bloqueo de clientes de terceros a continuación.
¡Te han advertido! :)
El pedido y entrega de mensajes salientes confiables, con notificaciones explícitas para cuestiones detectadas de cualquier tipo.
Soporte para canales públicos y privados, pedidos de canales, hilos, foros, excepto para crear cualquiera nueva de estos.
Canales de captura por servir y globales para rastrear la actividad general.
Alias/renombres de nombre local configurables, bloques de mensajes salientes/reemplazos, filtrado regexp para mensajes recibidos.
Soporte para la reconfiguración limitada de tiempo de ejecución a través del canal #rdircd.control.
Discordia simple y consistente a IRC Guild/Channel/User Name Translation.
Ninguno de estos cambiará después de la reconexión, el canal o la reorganización del servidor, etc., la traducción es principalmente determinista y no depende de otros nombres.
Traducción para menciones de discordia, respuestas, archivos adjuntos, pegatinas y emojis en MSG entrantes, otros eventos, anotaciones básicas para algunos enlaces integrados.
Soporte limitado para la traducción de las menciones y emojis del usuario de Discord en mensajes, ediciones y deleciones enviadas.
Los comandos de accesibles de fácil acceso a través de/topic (/t) en cualquier canal, por ejemplo, "/T log 2h" para mostrar las últimas 2 horas de acumulación de acumulación o "/T log 2019-01-08" para volcar la cartera de pedidos desde ese punto hasta el presente, obteniendo múltiples lotes si es necesario.
Sin embargo, los mensajes enviados a través de otros medios (por ejemplo) se transmitirán a IRC, sin embargo, tal vez provenga de una diferencia de Diff, si el nombre de IRC no coincide con la traducción de discordia a Nick.
Soporte/uso completo de Unicode en todas partes.
El protocolo IRC se implementa a partir de documentos IRCV3, pero no usa ninguna cosa que no sea RFC, por lo que debe ser compatible con cualquier cliente antiguo. Envolvente TLS opcional.
Opciones extensas de registro de protocolo y depuración, algunas accesibles en tiempo de ejecución a través del canal #rdircd.debug.
Script Python3 único que solo requiere el módulo AIOHTTP, trivial para ejecutar o implementar en cualquier lugar.
Se ejecuta en una huella de memoria relativamente estable de ~ 40 m en AMD64, que probablemente sea más que, por ejemplo, Bitlbee-Discord, pero mejor que esas pestañas de navegador con fugas.
Fácil de ajustar y depurar sin reconstrucciones, GDB, óxido y demás.
Solo las menciones de usuario y los emojis enviados desde IRC se traducen en etiquetas de discordia (si están habilitadas y con algunas peculiaridades, ver a continuación), no canales, roles, calcomanías, componentes, etc.
No hay soporte para enviar archivos adjuntos o incrustaciones de cualquier tipo: use WebUI para eso, no IRC.
Sin embargo, Discord anota automáticamente los enlaces, por lo que publicar medios es tan simple como eso.
No se admiten acciones específicas de discordia más allá de todo tipo de lectura y envío de mensajes a los canales existentes, es decir, no crear cuentas o canales en discordia, administrar roles, invitaciones, prohibiciones, tiempos de espera, etc., use webui, armonía o bots de discordia adecuados.
No es compatible crear nuevos chats privados e hilos de canal/foro.
Para los chats privados, puede ser incluso peligroso apoyar: vea más información sobre la sección de bloqueo de clientes de terceros a continuación para más detalles.
No rastrea la presencia del usuario (en línea, fuera de línea, AFK, juego de juego, etc.) en absoluto.
No emita eventos de unión /piezas del usuario y maneja IRC /nombres de una manera muy simple, solo enumeran a Nicks que usaron el canal desde el inicio de la aplicación y dentro de IRC-Names TimeOut (1 día de forma predeterminada).
Ignora completamente todas las cosas que no son de texto en general (por ejemplo, voz, perfiles de usuario, biblioteca de juegos, tienda, listas de amigos, etc.).
Discord rastrea el lado del servidor "Read_State", que no se usa aquí de ninguna manera: la repetición de la historia de activación solo se realiza manualmente (/t comandos en Chans), por lo que a veces puede ser fácil de perder en las reconexiones silenciosas.
No admite el modo de autenticación multifactor de discordia, pero la autenticación de token manual probablemente puede funcionar alrededor de eso; vea la nota en Captchas a continuación.
Los comandos de corte (para bots) no son compatibles de ninguna manera especial, pero probablemente aún pueda enviarlos, si el cliente IRC lo pasará.
No es lo más fácil de usar, aunque probablemente igual que el propio IRC.
Solo lo ejecuto en Linux, por lo que es poco probable que "solo funcione" en OSX/Windows, pero idk.
Implementación ad-hoc personalizada de Discord e IRC, que no se beneficia de ningún tipo de exposición y prueba en PYPI y dicha compatibilidad de WRT, errores y cascos.
Parece estar en contra de las pautas de Discord para usarlo; consulte la sección de advertencia anterior para obtener más detalles.
En la plataforma OpenBSD, cuando se utiliza password-hash= , también podría necesitar instalar el módulo Scrypt por separado (a través de pkg_add py3-scrypt ), ya que el puerto de Python no parece tener hashlib.scrypt en su stdlib.
La forma más simple podría ser usar el paquete para/desde su distribución de Linux, si está disponible.
Paquetes de distribución actualmente conocidos (a partir de 2020-05-17):
También hay un DockerFile y Docker-Compose.yml por ejecutar esto en un Docker/Podman o en algún otro entorno contenedorizado compatible con OCI.
(Consulte también ReadMe.Docker-Permissions.MD Doc para obtener información sobre problemas de acceso común con los))
Debe ser fácil de instalar un script y sus pocas dependencias manualmente, como se describe en el resto de esta sección a continuación.
En Debian/Ubuntu, la instalación de dependencias se puede hacer con este comando:
# apt install --no-install-recommends python3-minimal python3-aiohttp
Otras distribuciones de Linux probablemente también tengan paquetes similares, y recomendaría tratar de usarlos como una primera opción, de modo que obtengan actualizaciones y para evitar una carga de mantenimiento local adicional, y solo retroceso a la instalación de módulos a través de "PIP" si eso falla.
En cualquier distribución arbitraria con Python (Python3) instalada, utilizando PIP/VenV para instalar el módulo AIOHTTP (y sus DEPS) para que el directorio de inicio del usuario "RDIRCD" no privilegiado pueda funcionar (que también se usa para ejecutar RDIRCD en el siguiente ejemplo a continuación), pero ignora esto si ya lo ha instalado a través de OS Package Manager o tal:
root # useradd -m rdircd
root # su - rdircd
## Option 1: use venv to install dependencies into "_venv" dir
rdircd % python3 -m venv _venv
rdircd % ./_venv/bin/pip install aiohttp
## Option 2: install pip (if missing) and use it directly
rdircd % python3 -m ensurepip --user
rdircd % python3 -m pip install --user aiohttp
Si tiene/usa PIPX (por ejemplo, de Repos de distribución), se puede usar para ejecutar aplicaciones de Python como esta y dependencias automáticas de mantenimiento automático, solo "Pipx ejecutar" el script principal: pipx run rdircd --help -sin necesidad de tocar Venv o Pip en absoluto (Pipx lo hará "debajo del capó").
Después de que se instalen los requisitos anteriores, el script en sí se puede obtener de este repositorio y ejecutar así:
## Ignore "useradd" if you've already created a user when running "pip" above
root # useradd -m rdircd
root # su - rdircd
## If using "venv" install example above - load its env vars
# Or alternatively run script via "./_venv/bin/python rdircd ..." command line
rdircd % source ./_venv/bin/activate
rdircd % curl -OL 'https://raw.githubusercontent.com/mk-fg/reliable-discord-client-irc-daemon/master/rdircd{,.unicode-emojis.txt.gz}'
rdircd % chmod +x rdircd
## Use "pipx run rdircd ..." here and below, if using pipx instead of pip/venv/distro-pkgs
rdircd % ./rdircd --help
...to test if it runs...
rdircd % ./rdircd --conf-dump-defaults
...for a full list of all supported options with some comments...
...alternatively, to create rdircd.ini template: ./rdircd -c rdircd.ini --conf-init
rdircd % nano rdircd.ini
...see below for configuration file info/example...
rdircd % ./rdircd --debug -c rdircd.ini
...drop --debug and use init system for a regular daemon...
Para configurar Daemon/Script para ejecutarse en el arranque del sistema operativo, el archivo de la unidad RDircd.Service Systemd se puede usar en la mayoría de los entornos de Linux (editar ExecStart = Opciones y rutas allí), o de lo contrario probablemente a través de Script Init.d, o tal vez en la sesión de "pantalla" como una última opción AD-HOC de resort. Asegúrese de que se ejecute como un usuario "rDircd" creado en fragmento arriba, no como root.
Para actualizar el script más tarde, si es necesario, reemplácelo con una última versión, por ejemplo, a través de la descarga de descarga con un comando CURL arriba, Git-Pull en el clon de reposio, docker-compose up --build , actualización del paquete del sistema operativo o de alguna otra manera, generalmente relacionado con la forma en que se instaló en primer lugar.
Cree un archivo de configuración con Discord and IRCD Auth Credentials en ~/.rdircd.ini (ver todos --conf... opta WRT estas):
[irc]
password = hunter2
[auth]
email = [email protected]
password = discord-passwordNota: La contraseña de IRC se puede omitir, pero asegúrese de firewall ese puerto desde todo en el sistema (o tal vez hacerlo de todos modos).
Sin embargo, si establece la contraseña, tal vez no use IRC password= Opción como arriba, y use password-hash= y -H/--conf-pw-scrypt para generarla en su lugar. De cualquier manera, asegúrese de usar esa contraseña al configurar también la conexión a este servidor en el cliente IRC.
Iniciar Daemon RDircd: ./rdircd --debug
Conecte el cliente IRC a "Localhost: 6667" - Puerto y puerto predeterminado de escuchar/enlace.
(Consulte ./rdircd --conf-dump-defaults o las opciones correspondientes de CLI -i/--irc-bind / -s/--irc-tls-pem-file para enlace en diferentes host/puerto y envoltura de zócalo TLS, para conexiones no locales)
Use el comando IRC /list para ver los canales para todos los servidores /gremios de discordia unidos:
Channel Users Topic
------- ----- -----
#rdircd.control 1 rdircd: control channel, type "help" for more info
#rdircd.debug 1 rdircd: debug logging channel, read-only
#rdircd.monitor 1 rdircd: read-only catch-all channel with messages from everywhere
#rdircd.leftover 1 rdircd: read-only channel for any discord messages in channels ...
#rdircd.voice 1 rdircd: read-only voice-chat notifications from all discords/channels
#rdircd.monitor.jvpp 1 rdircd: read-only catch-all channel for discord [ Server-A ]
#rdircd.leftover.jvpp 1 rdircd: read-only msgs for non-joined channels of discord [ Server-A ]
...
#me.chat.SomeUser 1 me: private chat - SomeUser
#me.chat.x2s456gl0t 3 me: private chat - some-other-user, another-user, user3
#jvpp.announcements 1 Server-A: Please keep this channel unmuted
#jvpp.info 1 Server-A:
#jvpp.rules 1 Server-A:
#jvpp.welcome 1 Server-A: Mute unless you like notification spam
...
#axsd.intro 1 Server-B: Server info and welcomes.
#axsd.offtopic 1 Server-B: Anything goes. Civility is expected.
Notas sobre la información aquí:
/j #axsd.offtopic ( /join ) Como lo haría con el IRC regular para ver /publicar los mensajes allí.
Los canales se unen/piezas en el lado IRC no afectan la discordia de ninguna manera.
Ejecutar /topic (a menudo funciona como /t ) IRC-Command para mostrar más información sobre comandos específicos de canal, EG /t log para obtener y reproducir retraso en el último evento antes del último apagado de RDIRCD, /t log list a List en lista de todas las marcas de tiempo de actividad que RDIRCD rastrea, o /t log 2h para obtener el registro del canal de descarga /volcado para /desde el tiempo específico (sampe /span) (ISO8601 o un releguado simple.
Los comandos de control/configuración de Daemon están disponibles en el canal #rdircd.control, #rdircd.debug Chan se puede utilizar para ajustar varios registros e inspeccionar el estado y los protocolos de Daemon más de cerca, envíe "ayuda" allí para enumerar los comandos disponibles.
Para obtener un amplio esquema de varios ajustes de configuración compatibles, consulte rdircd.defaults.ini archivo (salida de ./rdircd --conf-dump-defaults ) y más sobre usos particulares de los siguientes.
Aquí se recopilan notas sobre varias características opcionales y menos obvias.
Consulte la sección "Uso" para obtener una información más general.
Se pueden especificar múltiples archivos INI con la opción -c , anulando mutuamente en secuencia.
El último se actualizará WRT [State], token = y cosas de tiempo de ejecución similares, así como cualquier valor establecido a través de #rdircd.control Channel comandos, por lo que puede ser útil especificar una configuración persistente con autores y opciones, y separar (inicialmente vacío) para dicho estado dinámico.
Eg ./rdircd -c config.ini -c state.ini lo hará.
--conf-dump se puede agregar a la impresión que resultó ser ensamblado a partir de todos estos.
--conf-dump-defaults se puede usar para enumerar todas las opciones y sus valores predeterminados.
Las actualizaciones frecuentes de la marca de tiempo del estado se realizan en el lugar (pequeños valores de longitud fija), pero verificando ctime antes de las escrituras, por lo que debería ser seguro editar cualquiera de estos archivos manualmente en cualquier momento de todos modos.
Enviar suspiro al comando script o "recargar" en el canal de control debe cargar y aplicar valores de todos los archivos de configuración en el mismo orden. Tenga en cuenta que dicha operación no restablecerá los valores en los archivos a sus valores predeterminados, solo aplique cosas explícitamente establecidas allí en la parte superior de la configuración actual.
Todos los chats en RDIRCD (y Discord) son un canal .
IRC /Q, /Query y /Msg no se pueden usar de manera típica de IRC.
Para hablar en cualquier chat privado, únase a un canal como #me.chat. <sserername>, que se comporta como cualquier otro canal Discord/RDircd.
Actualmente no hay forma de crear nuevos chats privados desde RDIRCD, usar otros clientes o WebUI para eso (o pedirle a alguien que se comunique con usted primero), pero una vez que se crea el canal de chat privado, también se puede usar en RDIRCD.
Consulte también canales de unión automática y /o /unir, por ejemplo, #rdircd.leftover.me canal para monitorear los mensajes privados de manera confiable, si es necesario.
En todos los canales IRC que representan un canal de discordia (envío /topic (o /t - taquigrafía para que a menudo compatible en clientes IRC), que debería imprimir información actualizada en todos los comandos específicos del canal, como los:
/t info : muestre información interna del gremio/canal, como IDS y tales para renomos.
Debe imprimir el nombre exacto del canal en Discord (sin renombros locales o traducción de discordia a Circ que RDIRCD lo haga), su tema, tipo, etc., entre otras cosas.
/t info {user-name...} - Información de consulta sobre el nombre de usuario (o parte de él) en esta discordia.
Por ejemplo, /t info joe137 buscará al usuario joe137 en un servidor de discordia al que pertenece el canal, imprimiendo información sobre ellos, como sus diversos nombres de discordia.
/t log [state] - historial de reproducción desde el punto "estado" (último RDIRCD pare de forma predeterminada).
/t log (igual que /t log 1 ) se puede usar, por ejemplo, después de que RDIRCD reinicie para consultar la discordia para cualquier mensaje que se haya publicado después de que se detuviera, y antes de que comenzara de nuevo (más cualquier otro desde entonces).
O /t log 0 para verificar el historial desde el último MSG que RDIRCD ha visto, para los casos en que Discord /Network es Flakey y algo podría haberse perdido de esa manera.
(donde estos números 1 y 0 se refieren a las marcas de tiempo guardadas de la salida /t log list , almacenados /actualizados en [state] en el archivo INI)
También se puede usar con un tiempo absoluto o relativo, por ejemplo /t log 15m para solicitar /repetir el historial del canal en los últimos 15 minutos, o /t log 2019-01-08 12:30 para reproducir el historial desde ese tiempo específico de Locid-Local (a menos que la zona horaria también se especifique allí).
Just /t o /topic en cualquier canal Proxy Discord enumerará más comandos y más información sobre cómo usarlos.
El último mensaje enviado a un canal de discordia se puede editar utilizando el comando SED-replacio como s/hoogle/google/ para arreglar un error tipográfico o modificar rápidamente/volver a palabras/aclarar esa última línea.
O //del se puede usar para eliminarlo - consulte la sección "Ediciones rápidas/eliminar" a continuación.
@silent Prefix-Command in Menses puede suprimir las notificaciones de los usuarios al respecto (también explicadas a continuación en algún lugar).
En canales especiales como #rdircd.control y #rdircd.debug: envíe h o help .
Pueden tener una lista algo larga de comandos compatibles, por ejemplo, aquí hay algunos de los comandos para #rdircd.control:
status (o st ) se puede usar para verificar las info de discordia y conexión IRC.
Los comandos connect / disconnect (o on / off ) se pueden usar para controlar manualmente la conexión de discordia, por ejemplo, para un uso más único, o para suprimir temporalmente las advertencias de Conn fallidas mientras la red local está baja de esa manera.
set irc-disable-reacts-msgs yes -Notificaciones de reacción de discordia de Temp Temp (usando el comando set ).
O set -s irc-disable-reacts-msgs yes para hacerlo permanente ( -s/--save el indicador para guardar el valor en el archivo de configuración INI), o simple set sin parámetros para ver todas las opciones de configuración general y sus valores.
rx Block mee6 bot-noise = (?i)^<MEE6> -Templock todos los mensajes de mee6 bot.
(Consulte la sección sobre este filtrado a continuación, o más ejemplos de tales cosas en consejos y trucos)
... y hay más de ellos: escriba help allí para obtener información actualizada completa.
#rdircd.monitor se puede usar para ver la actividad de todos los servidores conectados: recibe todos los mensajes, prefijados por el nombre del canal IRC relevante.
#rdircd.monitor.Guild (donde "Guild" es un hash o alias, ver arriba) es un canal similar de captura similar para un servidor/gremio de discordia específico.
#rdircd.monitor.me puede ser útil, por ejemplo, para monitorear los chats y mensajes privados para la cuenta de Discord (ver también el ejemplo de canales de unión automática).
#rdircd.leftover y similares #rdircd.leftover.guild Los canales son como canales de monitor, pero omita mensajes desde cualquier canal que el cliente IRC haya unido, incluido EG /join #rdircd.leftover.game-x "sobrantes" de cualquier manera).
#rdircd.voice es un canal similar a #rdircd.monitor, pero solo captura los avisos de eventos de chat de voz, para poder rastrearlos de manera oportuna.
Estos canales pueden ignorarse si no se necesitan, o deshabilitar por completo configurando EG chan-monitor en un valor vacío en la sección de archivo de configuración [IRC] INI. Por ejemplo, los canales de actividad de voz por disco de Discord están a discapacitados predeterminados allí.
El archivo de configuración también tiene la sección [Unmonitor] para una lista opcional de nombres de canal para ignorar en los canales de monitor/sobrantes, por ejemplo:
[unmonitor]
# All filters are applied to channel names and are case-insensitive
Ignore this particular " bot-commands " channel = game-X.bot-commands
skip forum threads in " game-X " guild = glob:game-X.forum.=*
" wordle " threads in any guild (and chans ending in .wordle) = glob:*.wordle
Don ' t show threads in any forum-like channels = re:^[^.]+ . (forum|discuss) . =.*
disregard all voice-chat stuff = glob:*.vc Las claves (como en parte antes "=") en dicha sección de configuración se ignoran, y pueden ser cualquier cosa, por ejemplo, comentarios que explican los patrones (como en el ejemplo anterior), mientras que los valores son nombres de canales exactos (con discordia prefijo, #-prefix opcional) o un "global"/"re:"--refijado global/patrón de regexp (patrón de lámpara de shell o python regexps), escrito de <some-key/comment> = glob:<wildcard-pattern> o <some-key/comment> = re:<regexp-pattern> Líneas-Ver ejemplos justo arriba.
Los nombres de los canales coincidentes por esos filtros se eliminarán de los canales de monitor, por lo que esto se puede usar para definir una lista de cosas spam que no le importan y que no quiere ver ni siquiera allí.
El comando "Unmonitor" (o "um") en #rdircd.control puede agregar/eliminar dichos filtros sobre la marcha en cualquier momento. Consulte también la opción de configuración match-counters para realizar un seguimiento de si las reglas específicas todavía son necesarias/utilizadas.
Los mensajes en los canales de monitor se limitan a una longitud/líneas específicas, para evitar inundaciones excesivas en MSG largos y/o múltiples. Los parámetros de "Len-Monitor" y "Len-Monitor-Lines" en la sección de configuración [IRC] se pueden usar para controlar estos límites, consulte "./rdircd --Conf-Dump-Defaults" para sus valores predeterminados. También hay opciones para cambiar el formato de nombre de los canales de monitor.
En IRC, todos tienen un nombre, pero ese no es el caso con Discord, donde cada usuario puede tener los siguientes nombres:
login - Discord "Nombre de usuario", identificando exclusivamente a cada usuario.display - "Nombre de pantalla" establecido por el usuario en la configuración de la cuenta de Discord, no es único.nick : "apodos" de servidor y amigo, establecido en la configuración del servidor de discordia, no siempre por usted. login es un concepto más cercano a los apodos de IRC, ya que es globalmente único, consistente, corto, ascii-solo, y puede usarse estableciendo name-preference-order = login en la sección [Discord] (no el valor predeterminado).
Los clientes oficiales de Discord muestran otros nombres primero, por lo que la opción name-preference-order predeterminada al valor nick display login , que utiliza los apodos específicos de Discord/Friend primero, si es que hay alguno, que vuelva al nombre de formato gratuito que el usuario establece en la configuración de la cuenta, y su nombre de inicio de sesión de lo contrario.
Otras cosas en apodos elegantes del uso del usuario que IRC no permite que también se reemplacen con caracteres unicode comunes, espacios con puntos medios "·", por ejemplo, o <> corchetes IRC-Nick comunes con flechas de Unicode. Las mechas largas de discordia están truncadas.
No hay notificaciones de IRC sobre los usuarios que cambian su pantalla específica de discordia/Nick-Names en este momento, y no tienen que ser únicos, lo que podría dificultar saber quién es quién, si siguen cambiando Nicks por cualquier razón.
Todo esto es configurable a través de la configuración de archivos INI (o en el canal #rdircd.control), por lo que si se vuelve demasiado tonto y enloquecedor, establezca name-preference-order = login para usar muelles únicos y amigables con IRC para todos.
El comando IRC /who OMS o /topic info puede ayudar a traducir entre estos nombres, por ejemplo /t info john1234 se puede usar para imprimir información para ese nombre /inicio de sesión en el búfer del canal, que debe incluir a todos los usuarios con coincidencia parcial de ese nombre en ese discordia específica, mientras que las búsquedas de comandos de la /who todas las discords unidas.
(más como "renombres" que "alias", ya que los viejos nombres no continúan funcionando para estos)
Se puede definir en el archivo de configuración para reemplazar los prefijos de discordia basados en hash o los nombres de los canales del servidor con algo más legible/memorable o significativo para usted:
[renames]
guild.jvpp = game-x
guild.sn3y = log-bot
guild.sn3y.chan-fmt = logs/{name}.log
chan.some-long-and-weird-name = weird
chan.@ 710035588048224269 = general-subs
user.noname123 = my-pal-bob
user.@ 123980071029577864 = joeEsto debería:
Convierta EG #jvpp.info en #game-x.info-Lettersoup Guild-id a un prefijo más significativo. Esto se aplicará a todos los canales en esa discordia: renombres "Gremio".
Cambie el formato de los nombres de los canales de la discordia "SN3Y" de algo como #sn3y.debug a #logs/debug.log - Cambio de formato de nombre del canal.
La plantilla de formato utiliza la sintaxis de Python Str.Format con "Nombre" (nombre del canal) y "Prefijo" (prefijo del gremio) será "Bot de registro" en este ejemplo) valores. El formato predeterminado es {prefix}.{name} .
Esta opción de formato no afecta los nombres de monitor/canal sobrante (por ejemplo, #rdircd.monitor.log-bot o #rdircd.leftover.game-x)-consulte opciones "Chan-monitor-Guild" y "Chan-Leftover-Guild" en la sección [IRC] para cambiar eso.
Cambie el nombre de ese canal largo para tener un nombre más corto (prefijo del gremio de retención) - renombres "Chan".
Tenga en cuenta que esto afecta a todos los gremios donde existe dicho nombre del canal, y el nombre de la fuente debe estar en formato IRC, igual que In /List, y está RFC1459-Casapped (igual que en IRC).
Cambiar el nombre del canal con ID = 710035588048224269 a "Memes" (Retener el prefijo del gremio) - "CHAN" se renombra usando la especificación de @Channel -ID.
Ese largo identificador de canal de discordia (también llamado "copo de nieve") se puede encontrar escribiendo /t info de comando de tema en el canal IRC correspondiente, y se puede usar para referirse a ese canal específico, es decir, renombrar este #General en este servidor de discordia en lugar de renombrar todos los canales #generales en todas partes.
Esto es especialmente útil cuando dos canales tienen el mismo nombre exacto dentro de la misma discordia, y normalmente se asignará .<id-hash> sufijos no descriptivos.
Cambie el nombre de los usuarios de pareja, referenciados por su nombre de usuario e ID de discordia.
/t info <nick-or-part-of-it> Command in Discord Channel o similar /who IRC-Command puede ayudar a buscar ID de discordia, como las que se usan allí.
Actualmente, solo se implementan tipos de cambio de nombre enumerados, para los prefijos y canales de discordia, pero también hay opciones en la sección [IRC] para establecer nombres para el sistema/monitor/sobrantes y los canales de chat privado-"Chan-Sys", "Chan-Private", "Chan-monitor" y tal (ver "./rdirccd -Conf-Dump-defaults".
Establezca chan-monitor-guild = {prefix} allí, por ejemplo, para que el canal #Game-X sea atrapado para todos los mensajes en esa discordia, sin longitud predeterminada #rdircd.monitor.* Prefix.
Los mensajes privados de Discord crean y se publican en canales en el servidor/gremio "ME", igual que en Discord WebUI, y pueden interactuarse de la misma manera que cualquier otro gremio/canales (Lista, unión/parte, MSG de envío/RECV, etc.).
Únase a #rdircd.monitor.me (o #rdircd.monitor, vea arriba) para obtener todos los nuevos msgs/chats allí, así como notificaciones de cambio de relación (solicitudes/agentes/eliminaciones) como avisos.
Aceptar solicitudes de amistad y agregar/eliminarlas se puede hacer a través de Discord WebUI regular y no se implementa en este cliente de ninguna manera especial.
Consulte también la sección de canales de unión automática a continuación para obtener una manera fácil de aparecer nuevos chats privados en el cliente IRC a través de invitaciones.
"Threads" es una característica de discordia, que permite a los usuarios que no sean administradores crean subcaneos ad-hoc transitorios en cualquier momento para un tema específico, que se relajan automáticamente ("archivados") después de un tiempo de espera de inactividad relativamente cortos (como un día).
Los canales de "foro" de Discord son básicamente canales, donde las personas solo pueden crear y hablar en los TEAD, con la lista de aquellos que reemplazan la charla de canal predeterminada.
Todos los hilos no arqueados deben mostrarse en la lista de canales RDIRCD como un canal IRC regular, con nombres como #GG.General. = VOT5.lets.
Hay varias opciones sobre cómo ver e interactuar con los subprocesos del canal principal (principalmente en la sección [Discord], ver--Conf-Dump-Defaults Salida):
[irc]
thread-chan-name-len = 30
[discord]
thread-id-prefix = =
thread-msgs-in-parent-chan = yes
thread-msgs-in-parent-chan-monitor = no
thread-msgs-in-parent-chan-full-prefix = no
thread-redirect-prefixed-responses-from-parent-chan = yes
...Pero incluso con todos estos discapacitados, se debe enviar una notificación simple al canal cuando se inician los hilos, de modo que uno no los extrañe por completo.
No hay soporte para crear nuevos hilos de IRC, desanimar los viejos o administrarlos de otra manera, y unir el canal de hilos en IRC en realidad no "une el hilo" en la interfaz de usuario de Discord (fijándola bajo el nombre del canal), pero publicar cualquier cosa que debería hacer eso automáticamente.
La configuración de "Chan-Auto-Join-Re" en la sección [IRC] permite especificar regexp para que coincida con el nombre del canal (sin # prefijo) para unir automáticamente cuando los mensajes aparecen en ellos.
Por ejemplo, para unir automáticamente cualquier canal #me.* (Mensajes directos), se puede usar el valor de expresión regular (sintaxis "re" python):
[irc]
chan-auto-join-re = ^me. O para que el cliente IRC se une a todos los canales, use chan-auto-join-re = .
El valor vacío para esta opción (predeterminado) no coincidirá con nada.
Esto se puede usar como una alternativa para rastrear cosas nuevas a través de #rdircd.monitor/restos de canales.
Este registro se puede ajustar en tiempo de ejecución utilizando el comando "Establecer" en el canal #rdircd.control, igual que cualquier otro valor, por ejemplo, habilitar/deshabilitar temporalmente esta característica para discords o canales específicos.
Las menciones son @username etiquetas en Discord, diseñadas para alertar a alguien para que el mensaje directo.
Con la configuración predeterminada, cuando ves EG <Galaxy?·Brain> Hi! Y quiero responder destacándolos, enviar Hey @galaxy and welcome probablemente debería funcionar. También puede usar su Nick IRC completo, para estar seguro.
Cómo funciona: si RDIRCD coincide con msg-mention-re Regexp Conf-option contra algo en un mensaje que se envía (por ejemplo, @galaxy @-mention anterior), que sería tratado como una "mención", que se combina de manera única y se traduce en una mención de discordia en el mensaje enviado, o devuelve un aviso de error (con Nicks que coinciden con esa mención ambigüemente, si en algún).
El valor predeterminado para él debería verse así:
[discord]
msg-mention-re = (?:^|s)(@)(?P<nick>[^s, ; @+!]+) Que coincidiría con cualquier mención @nick en líneas enviada separada por el espacio o la puntuación en las líneas enviadas.
REGEXP (Python "Re" Syntax) debe haber llamado grupo "Nick" con una cadena de búsqueda Nick/Nombre de @ , que será reemplazado por la etiqueta de mención de discordia, y todos los demás grupos de captura (es decir, sin ?:
Regexp predeterminado anterior aún debe permitir enviar EG @something para que aparezca no iluminado en WebApp (y sin debido a Markdown), ya que no coincidirá con (?:^|s) parte debido a esa prefijo de barra de invernada.
Como otro ejemplo, para tener reflejos clásicos de estilo IRC al comienzo de la línea, se puede usar regexp como este:
msg-mention-re = ^(?P<nick>S+)(:)(?:s|$)
Y debería traducir, por ejemplo mk-fg: some msg en @mk-fg some msg (con @-part siendo mencionado). El espacio final se incluye en Regexp allí para evitar que los enlaces de URL coincidan.
Para identificar el usuario de Discord Discord, el grupo "Nick" se utilizará de las siguientes maneras:
La coincidencia insensible a los casos contra todos los nombres IRC relacionados con el gremio recientes (autores de mensajes, reacciones, usuarios de canales privados, etc.). La opción de configuración de user-mention-cache-timeout Controla el tiempo de espera "reciente".
Busque la finalización de nombre único por prefijo, igual que Discord en WebUI para el autor de autocompleto después de que se escriba @.
Si no se encontrará una coincidencia en caché o una notificación única, se emitirá un aviso de error y no se enviará el mensaje.
Tal comportamiento estricto está diseñado para evitar cualquier traducción errónea involuntaria, y destacar que la persona incorrecta generalmente solo debería ser posible a través de la falta de ortografía.
La opción relacionada de msg-mention-re-ignore (regexp para que coincida con la captura completa del patrón anterior) también se puede usar para omitir algunas cosas que no se tratan de ser tratadas como tales, que de otro modo serían recogidas por First REGEXP, eliminando a los grupos capturados de ellos también, lo que puede usarse para que EG no se escape.
Tenga en cuenta que las listas de usuarios de Discord pueden ser bastante masivas (500k+ usuarios), no están divididos por canal, y no están destinados a ser recogidos previamente por el cliente, solo consultan para completar o piezas visibles, lo que no se asigna bien a IRC, de ahí toda esta magia.
Regexp similar está configurado para emojis por disco:
msg-emoji-re = (?:^|s)(:)(?P<emoji>w+)(:)(?=[^w]|$)
Donde, por ejemplo I use :Arch: btw de IRC coincidirá con ese RegExp, busca/reemplazará el grupo "emoji" allí usando los emojis de esta discordia (insensible a la caja), y lo enviará traducido como I use ? btw , o returación de un aviso de error si dicho emoji no está disponible en esa discordia y no en una lista de unicode genéricos.
Establezca msg-mention-re / msg-emoji-re en un valor vacío para deshabilitar tales traducciones.
Similar a las menciones del usuario de Discord anteriormente, hay una opción REGEXP especial que coincide con los comandos para interpretarse como edición o eliminación del último mensaje enviado a este canal.
REGEXPS predeterminado se ve como esto (verificar--Conf-Dump-Defaults Jic):
[discord]
msg-edit-re = ^s*s(?P<sep>[/|:])(?P<aaa>.*)(? P =sep)(?P<bbb>.*)(? P =sep)s*$
msg-del-re = ^s*//dels*$ Coinciden con las líneas de enmienda de seguimiento de SED/Perl/IRC como s/spam/ham/ y //del Line, que nunca se enviará a Discord, solo se usa como comandos internos.
( s|/some/path|/other/path| y s:cat /dev/input/mouse0 | hexdump:hexdump </dev/input/mouse0: las sintaxis también están permitidas por edición predeterminada-regexp, al igual que con SED, para un manejo más fácil de cosas comunes como rutas, que pueden tener estos caracteres en ellos)
Ambos comandos coincididos con estos funcionan en el último mensaje enviado por RDIRCD al mismo canal de discordia, con //del simplemente eliminando ese último mensaje y editar la ejecución de Python re.sub () (PCRE-LIKE) REGEXP-REplaced Función en él.
"msg-edit-re" regexp option value matching sed-like command must have named "aaa" and "bbb" groups in it, which will be used as pattern and replacement args to re.sub(), respectively.
If edit doesn't seem to alter last-sent message in any way, it gets discarded, and also generates IRC notice response, to signal that replacement didn't work.
Successful edit/deletion should also be signaled as usual by discord, with [edit] or such prefix (configurable under [irc] section).
Any older-than-last messages can be edited through Discord WebUI - this client only tracks last one for easy quick follow-up oops-fixes, nothing more than that.
Somewhat similar to quick edits/deletes above, "msg-flag-silent-re" option is there to match/remove "@silent" prefix in messages (by default), which disables sending discord push notifications for it, same as with the official client.
That and similar message flags on incoming messages are not represented in any way, as they don't seem to be relevant for an irc client anyway.
Config can have a [send-replacements] section to block or regexp-replace parts of messages sent (by you) from IRC on per-discord basis.
This can be used to add discord-specific tags, unicode shorthands, emojis, stickers, block/replace specific links or maybe even words/language before proxying msg to discord.
Here's how it can look in the ini file(s):
[send-replacements]
*. unicode-smiley = (^| ):)( |$) -> 1?2
*. twitter-to-nitter = ^(https?://)((mobile|www).)?twitter.com(/.*)?$ -> 1nitter.ir4
guildx.never-mention-rust! = (?i)brustb -> <block!>
guildx.localize-color-word = bcolor(ed|iS+)b -> colour1 Where each key has the form of discord-prefix> "." comment , with a special * prefix to apply rule to all discords, while values are regexp " -> " <replacement_or_action with one special <block!> action-value to block sending msg with error-notice on regexp match. "comment" part of the key can be any arbitrary unique string.
So when sending eg test :) msg on IRC, discord will get test ? .
Same as with other regex-using options, regexps have python "re" module syntax, applied via re.sub() function, using raw strings from config value as-is, without any special escapes or interpretations.
Replacements are applied in the same order as specified, but with * keys preceding per-discord ones, and before processing to add discord tags, so anything like @username that can normally be typed in messages can be used there too.
#rdircd.control channel has "repl" command to edit these rules on-the-fly.
If you join #rdircd.monitor channel, see - for example - a message like this:
<helper-bot> #pub.welcomes :: Welcome!
...and think "don't want to see messages like that again!" - config files' [recv-regexp-filters] section or corresponding "rx" command in #rdircd.control channel can help.
Depending on what "messages like that" means, here are some ways to filter those out:
[recv-regexp-filters]
discard msgs from this bot = ^<helper-bot>
ignore all msgs in that channel of that discord = ^S+ # pub.welcomes ::
drop all msgs from " pub " discord = ^S+ # pub.
no messages from # welcomes channels of any discord pls = ^S+ #w+.welcomes ::
never see " Welcome! " message-text again!!! = ^S+ # S+ :: Welcome!$
some combination of the above = (?i)^<helper-bot> # w+.welcomes ::
...(tweak eg last example on regex101.com for more hands-on understanding)
Lines in that section have the usual <key> = <regexp> form, where <key> part can be anything (eg comment to explain regexp, like in examples above), and <regexp> value is a regular expression to match against the message in <user> #discord.channel-name :: message text format like that helper-bot msg presented above, and same as can be seen in monitor-channels.
Any message received from discord will be matched against all regexps in order, stopping and discarding the message everywhere on first (any) match. So it might be a good idea to write as precise patterns as possible, to avoid them matching anything else and dropping unrelated messages accidentally.
Same as with some other conf options, basic knowledge of regular expressions might be needed to use such filters - here's a link to nice tutorial on those (though there are 100s of such tutorials on the web).
Particular regexps here use PCRE-like python re syntax, with re.DOTALL flag set ( . matches newlines in multiline messages). I'd also recommend commonly adding (?i) case-insensitive-match flag, as IRC nicks and channel names ignore character case and can be displayed in misleading/inprecise ways in the client.
More random examples of [recv-regexp-filters], incl. more advanced CNF weirdness:
[recv-regexp-filters]
disregard wordle thread there = ^S+ # pub.general.=w8mk.wordle ::
ignore " wordle " threads everywhere = ^S+ # S+.=w{4}.wordle ::
activity-level bots are annoying = (?i) advanced to level d+[ !]
gif replies of YY in ZZ = (?i)^<YY> # ZZ.S+ :: (-- re:[^n]+n)?[att] .*/imaged.gif?
; ; Advanced stuff: connect multiple regexps via CNF logic (Conjunctive Normal Form)
; ; If key starts with "∧ " (conjunction symbol), it's AND'ed with previous regexp
; ; ¬ (negation) in that prefix inverts the logic, so e.g. "∧¬ ..." is "and not ..."
; ; Disjunction (∨) is the default behavior and doesn't need the (implied) prefix
; ; Any complex logical expression can be converted to such CNF form -
; ; - use calculators like https://www.dcode.fr/boolean-expressions-calculator
Drop welcome msgs in welcome-chans = (?i)^S+ # w+.S*welcomeS* :: .*bwelcomeb.*
∧ but only if they have an exclaimation mark in them somewhere = :: .*!
∧¬ and not from this specific " lut " discord-prefix = ^S+ # lut.
Most channels here are not relevant = ^S+ # myc.
∧¬ except these ones = ^S+ # myc.(announcements|changelog|forum)[. ]
∨ but skip github CI logs there = ^<github> # myc.Pretty much anything can be matched with clever regexps, so CNF-logic stuff like in last examples is seldom useful, but might still be simpler than expressing arbitrary ordering or negation in regexps.
See also match-counters config option to keep track of whether specific rule(s) are still needed/being-used.
Mostly useful for debugging - /who command can resolve specified ID (eg channel_id from protocol logs) to a channel/user/guild info:
/who #123456 - find/describe channel with id=123456./who %123456 - server/guild id info./who @123456 - user id lookup.All above ID values are unique across Discord service within their type.
/who @John·Mastodon - user IRC nick or name/login lookup.
Queries all joined discords for that name, and can return multiple results for same or similar non-unique names. Can be useful to check exact nick/display/login names corresponding to an IRC name, or other user info.
/who *665560022562111489 - translate discord snowflake-id to date/time.
Results of all these commands should be dumped into a server buffer (not into channels), regardless of where they were issued from.
In irc channels corresponding to ones on discord, /topic info command (often works as shortened /t info in clients too) can be used to print more information about linked discord channel and its server/guild.
/t info <username> can also print info on user in that discord (unlike /who @<username> which looks the name up in all connected discords), for example /t info john will print info for anyone with "john" in the name.
Usernames in these queries can match exact irc name or discord username, in which case that result is returned, or otherwise more general server-side lookup is made, which can return matches in any type of discord name(s) (see People's names on discord for more info on those).
Discord name translation is "mostly" deterministic due to one exception - channels with same (casemapped) IRC name within same server/guild, which discord allows for.
When there is a conflict, chan names are suffixed by .<id-hash> (see chan-dedup-* config options), to allow using both channels through IRC. Renaming conflicting channels on Discord will rename IRC chans to remove no-longer-necessary suffixes as well. Such renames affect thread-channels too.
Note that when channels are renamed (including name conflicts), IRC notice lines about it are always issued in affected channels, and any relevant monitor/leftover channels, topic should be changed to reflect that old-name channel is no longer useful, and posting msgs there should emit immediate warnings about it.
Discord CDN URLs for attachments can end up being quite long with same host, long discord/channel IDs in there, then actual filename, and ?ex=...&is=...&hm=... trail of CDN parameters after that.
Many Linux IRC clients run in Terminal Emulators though, which often support OSC 8 terminal hyperlink standard, so can display clickable links in a much more compact and readable form.
For example, this attachment URL to a Discord CDN:
https://cdn.discordapp.com/attachments/1183893786254905414/1206216641877377024/20240211_My_Cat_Photo.jpg?ex=65db33c9&is=65c8bec9&hm=9c1dbecbfb2f9edf2302ec078f5e62fffa7f8c2f32e5cd6e3563ae25d8a356e1&
Can be displayed in a terminal like this instead: 20240211_My_Cat_Photo.jpg
Ie same as how one would see hyperlinks displayed in a browser.
This is disabled by default, but if you use terminal IRC client that might support those, set terminal-links = yes option in config file or via set command in an #rdircd.control channel to try it out.
Adjacent terminal-links-re and terminal-links-tpl options can be used to control which part of the link to display as its visible name, which terminal-specific escape characters to use, and such customization.
Discord has voice channels, where in addition to text people can talk verbally, share camera or screen capture (aka streaming, screen sharing). IRC protocol does not support anything like this of course, but it can be useful to get notified when someone starts talking, to hop into different discord client (eg open it in a browser), and use these channels from there.
All IRC channels corresponding to discord voice chats automatically get .vc suffix (unless renamed), and get notice messages about voice activity in there, but limited to following events, to avoid being too spammy:
voice-notify-after-inactivity timeout of inactivity (ie since previous voice-status notification there), default = 20 minutes. And with additional rate-limit set by voice-notify-rate-limit-tbf value, to notify about up to 5 events in a row, but otherwise no more often than once in 5 minutes ("token bucket algorithm" is technically how this limit is implemented/works).
If description above sounds confusing, here's config tweaks to remove all limits on voice-activity event notifications - try those, and maybe re-read this section later if they get too spammy (maybe never!):
[discord]
voice-notify-after-inactivity = 0
voice-notify-rate-limit-tbf = 0#rdircd.voice monitor-channel(s) can also be used to only track voice-chat notifications across discords/channels, potentially filtered via "um" command in #rdircd.control or [unmonitor] in ini config(s).
IRC convention is to treat mention of a nickname as a "highlight" - a more notification-worthy event than a regular channel message, so it might be useful if messages in private channels did always highlight the nick for IRC client.
prefix-all-private option can be used for that:
[irc]
prefix-all-private = mynick: Might also be necessary to either join monitor/leftover channels or setup auto-joining channels for new PMs to be received by IRC client at all.
Private chats are not implemented via direct IRC messages for various practical reasons, ie to have everything work via channels, because it works that way on the discord side, they can have multiple users, to list those easily, to query topic/history/etc there, and such stuff.
There is a similar prefix-all option, to add prefix to all messages, if prefix-all-private doesn't go far enough.
By default, [discord] msg-ack=yes enables sending (delayed) ACKs for received messages in private chats, so that discord counts those as read and doesn't send an email notification about them. This can be disabled or adjusted in config file.
Messages blocked by eg [recv-regexp-filters] or received when there are no IRC clients connected don't count.
If IRC client supports IRCv3 typing notifications and has these enabled, rdircd will forward those from discord users/channels by default, which can be disabled by setting typing-interval = 0 in [irc] configuration section, or interval/timeout values can be adjusted there to work better for IRC app.
Separate typing-send-enabled option controls whether typing notifications from IRC are sent to a discord channel. It is disabled by default for privacy reasons, and likely needs to be explicitly enabled in IRC client as well.
Any IRCv3 features like that typing stuff can also be disabled via ircv3-caps option, eg if there're problems with them in rdircd or client.
This should happen by default when discord gateway responds with op=9 "invalid session" event to an authentication attempt, not reconnecting after that, as presumably it'd fail in the same way anyway.
This would normally mean that authentication with the discord server has failed, but on (quite frequent) discord service disruptions, gateway also returns that opcode for all logins after some timeout, presumably using it as a fallback when failing to access auth backends.
This can get annoying fast, as one'd have to manually force reconnection when discord itself is in limbo.
If auth data is supposed to be correct, can be fixed by setting ws-reconnect-on-auth-fail = yes option in [discord] ini section, which will force client to keep reconnecting regardless.
Don't know why or when it happens, but was reported by some users in this and other similar discord clients - see issue-1 here and links in there.
Fix is same as with bitlbee-discord - login via browser, maybe from the same IP Address, and put auth token extracted from this browser into configuration ini file's [auth] section, eg:
[auth]
token = ...See "Usage" in README of bitlbee-discord (scroll down on that link) for how to extract this token from various browsers.
Note that you can use multiple configuration files (see -c/--conf option) to specify this token via separate file, generated in whatever fashion, in addition to main one.
Extra token-manual = yes option can be added in that section to never try to request, update or refresh this token automatically in any way. Dunno if this option is needed, or if such captcha-login is only required once, and later automatic token requests/updates might work (maybe leave note on issue-1 if you'll test it one way or the other).
Never encountered this problem myself so far.
Most likely source of that should be missing handling for some new/uncommon discord events, or maybe a bug in the code somewhere - either can be reported as a github issue.
To get more information on the issue (so that report won't be unhelpful "don't work"), following things can be monitored and/or enabled:
Standard error stream (stderr) of the script when problem occurs and whether it crashes (unlikely).
If rdircd is run as a systemd service, eg journalctl -au rdircd should normally capture its output, but there are other ways to enable logs listed just below.
rdircd shouldn't normally ever crash, as it handles any errors within its own loop and just reconnects or whatever, but obviously bugs happen - there gotta be some python traceback printed to stderr on these.
Find a way to reproduce the issue.
When something weird happens, it's most useful to check whether it can be traced to some specific discord and event there (eg some new feature being used), or something specific you did at the time, and check whether same thing happens again on repeating that.
That's very useful to know, as then problem can be reproduced with any kind of extra logging and debugging aids enabled until it's perfectly clear what's going on there, or maybe how to avoid it, if fixing is not an option atm.
Join #rdircd.debug channel - any warnings/errors should be logged there.
Send "help" (or "h") msg to it to see a bunch of extra controls over it.
Sending "level debug" (or "d") there for example will enable verbose debug logging to that channel (can be disabled again via "level warning"/"w"), but it might be easier to use log files for that - see below.
Enable debug and protocol logs to files.
In any loaded rdircd ini file(s), add [debug] section with options like these:
[debug]
log-file = /var/log/rdircd/debug.log
proto-log-shared = no
proto-log-file = /var/log/rdircd/proto.log /var/log/rdircd dir in this example should be created and accessible only to running rdircd and ideally nothing else, eg creating it as: install -m700 -o rdircd -d /var/log/rdircd
Such opts should enable those auto-rotating log files, which will have a lot of very information about everything happening with the daemon at any time.
Both of these can also be enabled/controlled and/or queried at runtime from #rdircd.debug chan.
proto-log-shared option (defaults to "yes") and be used to send discord/irc protocol logging to same log-file or #rdircd.debug channel, but it might be easier to have two separate logs, as in example above.
Log file size and rotation count can be set via log-file-size , log-file-count , proto-log-file-size , proto-log-file-count options - run rdircd --conf-dump-defaults to see all those and their default values (rdircd.defaults.ini has some recent-ish copy too).
When running with protocol logs repeatedly or over long time, proto-log-filter-ws option can be handy to filter-out spammy uninteresting events there, like GUILD_MEMBER_LIST_UPDATE.
Note that these files will contain all sorts of sensitive information - from auth data to all chats and contacts - so should probably not be posted or shared freely on the internet in-full or as-is, but can definitely help to identify/fix any problems.
Running /version IRC-command should at least print something like host 351 mk-fg 22.05.1 rdircd rdircd discord-to-irc bridge on the first line, which is definitely useful to report, if it's not the latest one in this git repo.
Generally if an issue is easy to reproduce (eg "I send message X anywhere and get this error"), it can be reported without digging much deeper for more info, as presumably anyone debugging it should be able to do that as well, but maybe info above can still be helpful to identify any of the more non-obvious problems, or maybe give an idea where to look at for fixing or working around these.
Some configuration tweaks that I use, or mentioned in #rdircd on IRC and such.
Feel free to suggest any other lifehacks to add here.
Normally rdircd uses these long strange "#rdircd.monitor" channel name templates, as well as unnecessary "#me.chat." prefixes, instead of this:
#DMs
#@some-friend
#@some-friend+other-friend+more-ppl
#rdircd
#rdircd.rest
#rdircd.voice
#rdircd.control
#rdircd.debug
#minecraft
#minecraft.general
#minecraft.modding
#minecraft.rest
Use these lines in any loaded ini config file to make it work like that:
[irc]
chan-monitor = rdircd
chan-leftover = rdircd.rest
chan-monitor-guild = {prefix}
chan-leftover-guild = {prefix}.rest
chan-private = {names}
[renames]
guild.me = DMs
guild.me.chan-fmt = @{name}What these options do, in the same order: rename "#rdircd.monitor" to "#rdircd", set names for all discord-specific monitor channels to just "{prefix}" (eg "#dm" or "#minecraft"), set private-chat channels to use people's name(s) without "chat." prefix, rename default "me" guild (private chats) to "DMs", use simpler @ + name format for any channels there.
Defaults are that way to try to be more explicit and descriptive, but once you know what all these channels are for, can easily rename them to something shorter/nicer and more convenient for yourself.
When message is edited, you normally get something like [edit] new msg text , but it can be ✍️ new msg text or new msg text instead:
[irc]
prefix-edit =
prefix-embed = ?.{}
prefix-attachment = ?️
prefix-uis =
prefix-interact = ?
prefix-poll = ?️.{} Note the "space and backslash" at the end in these options, which is to preserve trailing spaces in values, from both text editors that strip those and configuration file parser (which ignores any leading/trailing spaces, unless punctuated by backslash). prefix-embed and poll values need {} placeholder for where to put short id/tag.
Alternatively, set-command like set irc-prefix-edit '✍️ ' can be used in #rdircd.control to configure and tweak this stuff on-the-fly (or -s/--save into config too).
Unless OSC 8 hyperlinks for terminal IRC clients option is enabled, attachments normally are just a long link with a filename buried in there:
<user> ?️ https://cdn.discordapp.com/attachments/813633048368761786/1313964897464246919/cat-pic.jpg?ex=674e6959&is=674d17d9&hm=2519bb427b1392bce87a0749ed664520d25493e509b8272170a66512f9e143d2&
But same OSC8-formatting feature can be used to get a bit more readable version for eg GUI IRC clients:
<user> ?️ cat-pic.jpg LCak :: https://cdn.discordapp.com/attachments/813633048368761786/1313964897464246919/cat-pic.jpg?ex=674e6959&is=674d17d9&hm=2519bb427b1392bce87a0749ed664520d25493e509b8272170a66512f9e143d2&
Using config like this:
[discord]
terminal-links = yes
terminal-links-emojis = no
terminal-links-tpl = {name} :: {url}("LCak" bit at the end of "cat-pic.jpg LCak" is hash of the link, so that it's possible to tell different "image.jpg" attachments apart at a glance)
Using discord through IRC can be a bit noisy due to edits or spammy notifications ending up in various monitor/leftover channels or other un-irc-like features, which rdircd can help mitigate to some degree, but often doesn't by default, as it's hard to know what other people actually care about.
Here are some random commands to try out in #rdircd.control channel:
um Noise from any bot-channels = re:.bots?(-.*)?$
um Ignore welcome chans = glob:*.welcomes
um Disregard all voice-chat events = glob:*.vc
um Memes belong in a circus = glob:*.memes
um Make food channels opt-in = glob:*.food
um Internet "politics" can get really spammy = glob:*.politic*
um There're probably better places for porn = glob:*.nsfw
rx MEE6 bot-noise anywhere = (?i)^<MEE6>
rx THX discord: people spamming edits = (?i)^<(person1|person2)> #THX.S+ :: [edit]
rx NSC: don't care about deletes = ^S+ #NSC.S+ :: --- message was deleted ::
rx NSC/THX: disable reactions here = ^S+ #(NSC|THX).S+ :: --- reacts:
Enable rule-hit counters to check whether these rules are still relevant later:
set discord-match-counters '1d 2d 4d 1w 2w 1mo 2mo runtime'
With these enabled, running um or rx should show [ rule hits: ... ] under each rule, if there's anything to show (but reset on rdircd restarts!), otherwise it's probably safe to drop unused rules to keep lists more tidy.
Disable "reacts" noise everywhere: set irc-disable-reacts-msgs yes
Remove long, confusing and silly nicknames full of unicode junk:
set discord-name-preference-order 'login'
If even ascii logins of specific users get annoying, use [renames] in config to change those locally (see Local Name Aliases section for more info):
[renames]
user.somereallylongandsillyloginbecausewhynot = bob
user.@ 374984273184829999 = andy Keep threads only as channels, and in #rdircd.leftover.* and such:
set discord-thread-msgs-in-parent-chan no
Don't show voice-chats or "monitor" channels on the /list :
set irc-chan-voice '' set irc-chan-monitor ''
All of these examples are not persistent, just to try them out and see, but all commands used there support -s flag to save changed values to last .ini config file, or it can be done manually as well, if any of these are useful to keep around.
There is a good and well-maintained list of alternative clients here:
There are many alt-clients these days, with a lot of churn among them, and dedicated lists like that are probably best way to discover those.
As mentioned in the "WARNING" section above, Bot vs User Accounts section in API docs seem to prohibit people using third-party clients, same as Discord Community Guidelines. Also maybe against their Discord Developer Terms of Service, but dunno if those apply if you're just using the alt-client.
I did ask discord staff for clarification on the matter, and got this response around Nov 2020:
Is third-party discord client that uses same API as webapp, that does not have any kind of meaningful automation beyond what official discord app has, will be considered a "self-bot" or "user-bot"?
Ie are absolutely all third-party clients not using Bot API in violation of discord ToS, period?
Or does that "self-bot" or "user-bot" language applies only to a specific sub-class of clients that are intended to automate client/user behavior, beyond just allowing a person to connect and chat on discord normally?
Discord does not allow any form of third party client, and using a client like this can result in your account being disabled. Our API documentation explicitly states that a bot account is required to use our API: "Automating normal user accounts (generally called "self-bots") outside of the OAuth2/bot API is forbidden, and can result in an account termination if found."
Another thing you might want to keep in mind, is that apparently it's also considered to be responsibility of discord admins to enforce its Terms of Service, or - presumably - be at risk of whole guild/community being shut down.
Got clarification on this issue in the same email (Nov 2020):
Are discord server admins under obligation to not just follow discord Terms of Service themselves (obviously), but also enforce them within the server to the best of their knowledge?
Ie if discord server admin knows that some user is in violation of the ToS, are they considered to be under obligation to either report them to discord staff or take action to remove (ban) them from the server?
Should failing to do so (ie not taking action on known ToS violation) result in discord server (and maybe admins' account) termination or some similar punitive action, according to current discord ToS or internal policies?
Server owners and admin are responsible for moderating their servers in accordance with our Terms of Service and Community Guidelines. If content that violates our Terms or Guidelines is posted in your server, it is your responsibility to moderate it appropriately.
So unless something changes or I misread discord staff position, using this client can get your discord account terminated, and discord admins seem to have responsibility to ban/report its usage, if they are aware of it.
Few other datapoints and anecdotes on the subject:
Don't think Discord's "Terms of Service" document explicitly covers third-party client usage, but "Discord Community Guidelines" kinda does, if you consider this client to be "self-bot" or "user-bot" at least.
Only thing that matters in practice is likely the actual staff and specific server admins' position and actions on this matter, as of course it's a private platform/communities and everything is up to their discretion.
Unrelated to this client, one person received following warning (2020-01-30) after being reported (by another user) for mentioning that they're using BetterDiscord (which is/was mostly just a custom css theme at the time, afaik):
In September 2021 there was a bunch of issues with people using different third-party clients being asked to reset their passwords daily due to "suspicious activity", raised here in issue-18 (check out other links there too), which seem to have gone away within a week.
At least one person in that issue thread also reported being asked for phone account verification for roughly same reason about a week after that, so maybe "suspicious activity" triggering for 3p clients haven't really gone away.
Cordless client developer's acc apparently got blocked for ToS violation when initiating private chats. This client doesn't have such functionality, but maybe one should be more careful with private chats anyway, as that seem to be a major spam vector, so is more likely to be heavily-monitored, I think.
In the #rdircd IRC channel, a person mentioned that their discord account got some anti-spam mechanism enabled on it, disallowing to log-in without providing a phone number and SMS challenge (and services like Google Voice don't work there), immediately after they've initiated private chat with someone in Ripcord client.
"I contacted support at the time and they just responded that they can't undo the phone number requirement once it has been engaged"
It also seems like Ripcord currently might be trying to mimic official client way more closely than rdircd script here does (where latter even sends "client"/"User-Agent" fields as "rdircd" and appears that way under Devices in User Settings webui), and such similarity might look like Terms of Service violation to Discord (modifying official client), instead of Community Guidelines violation (third-party client), but obviously it's just a guess on my part as to whether it matters.
There are also some HN comments clarifying Discord staff position in a thread here, though none of the above should probably be taken as definitive, since third-party and even support staff's responses can be wrong/misleading or outdated, and such treatment can likely change anytime and in any direction, without explicit indication.
Note: only using this API here, only going by public info, can be wrong, and would appreciate any updates/suggestions/corrections via open issues.
Last updated: 2024-11-26
Discord API docs don't seem to cover "full-featured client" use-case, likely because such use of its API is explicitly not supported, and is against their rules/guidelines (see WARNING section above for details).
It's possible that more recent official OpenAPI spec in discord/discord-api-spec repo has a more complete documentation though.
Discord API protocol changes between versions, which are documented on Change Log page of the API docs.
Code has API number hardcoded as DiscordSession.api_ver, which has to be bumped there manually after updating it to handle new features as necessary.
Auth uses undocumented /api/auth/login endpoint for getting "token" value for email/password, which is not OAuth2 token and is usable for all other endpoints (eg POST URLs, Gateway, etc) without any prefix in HTTP Authorization header.
Found it being used in other clients, and dunno if there's any other way to authorize non-bot on eg Gateway websocket - only documented auth is OAuth2, and it doesn't seem to allow that.
Being apparently undocumented and available since the beginning, guess it might be heavily deprecated by now and go away at any point in the future.
There are some unofficial docs for officially-undocumented APIs and quirks:
Sent message delivery confirmation is done by matching unique "nonce" value in MESSAGE_CREATE event from gateway websocket with one sent out to REST API.
All messages are sent out in strict sequence (via one queue), waiting on confirmation for each one in order, aborting rest of the queue if first one fails/times-out to be delivered, with notices for each failed/discarded msg.
This is done to ensure that all messages either arrive in the same strict order they've been sent or not posted at all.
Discord message-posting API has enforce_nonce parameter (since 2024-02-12), which allows to retry posting messages safely from duplication, but at the moment retries are only performed here on API rate-limiting.
Fetching list of users for discord channel or even guild does not seem to be well-supported or intended by the API design.
There are multiple opcodes that allow doing that in a limited way, none of which work well for large discords (eg 10k+ users).
request_guild_members (8) doesn't return any results, request_sync (12) doesn't work, request_sync_chan (14) can be used to request small slice of the list, but only one at a time (disconnects on concurrent requests).
Latter is intended to only keep part of userlist that is visible synced in the client, doesn't support proper paging through whole thing, and only gets updates for last-requested part with indexes in it - basically "I'm in this guild/channel, what should I see?" request from the client.
Some events on gateway websocket are undocumented, maybe due to lag of docs behind implementation, or due to them not being deemed that useful to bots, idk.
Discord allows channels and users to have exactly same visible name, which is not a big deal for users (due to one-way translation), but still disambiguated irc-side.
Discord emojis like :smile: are handled in multiple different ways:
Looked up among unicode emoji names that work in all discords and translated to a unicode character, eg :smile: to
Can be found in current discord's custom emojis and replaced by a message formatting tag for it, like :debian: to a tag like <:debian:12345> , which discord clients will display as debian logo in a linux-related discord.
If user has Discord Nitro subscription, custom emoji from any discord works in any other discord as well.
rdircd doesn't handle last Nitro case at all (looks-up custom emojis in one discord), while first two cases are distinguished from each other via rdircd.unicode-emojis.txt.gz file (optional/configurable), which has list of all non-custom emojis (~6k of them), pulled from Discord WebUI using extract-unicode-emojis-from-js.py script.
If generic emojis stop working in the future (incorrectly treated as if they're discord-custom ones), due to renames or new additions, that script can be used to update the list of them easily.
Gateway websocket can use zlib compression (and zstd in non-browser apps), which makes inspecting protocol in browser devtools a bit inconvenient.
gw-ws-har-decode.py helper script in this repo can be used to decompress/decode websocket messages saved from chromium-engine browser devtools (pass -h/--help option for info on how to do it).
Run ./rdircd --test for info on some extra development/testing helper commands.
dev-cmds = yes under [debug] also enables some runtime helpers in #rdircd.control.
Adding support for initiating private chats might be a bad idea, as Cordless dev apparently got banned for that, and since these seem to be main spam vector, so more monitoring and anomaly detection is likely done there, leading to potentially higher risk for users.
