reliable discord client irc daemon
1.0.0
Table des matières
Description
AVERTISSEMENT
Caractéristiques
Limites
Usage
Informations sur la fonctionn
Conseils et astuces aléatoires
Links
Plus d'informations sur le blocage des clients tiers
API et notes de mise en œuvre
RDRICD est un démon qui permet d'utiliser un compte Personal Discord via un client IRC.
Il traduit tous les chats privés et canaux / threads publics sur "Discord Serveurs" en canaux d'un serveur IRC qu'il crée et que vous pouvez vous connecter à l'utilisation du client IRC ordinaire, au lieu d'un navigateur ou d'une application électronique.
"fiable" est dans le nom car l'un des objectifs initiaux était de le faire confirmer la livraison de messages et de notifier tout problème à cet égard, qui manquait quelque peu dans d'autres clients similaires à l'époque.
Il y a une chaîne IRC pour parler de la chose - rejoignez #RDRICCD sur Libera.Chat.
URL IRC: IRCS: //IRC.LIBERA.CHAT/RRIRCD (GitHub refuse de fabriquer IRCS: // Links)
Voir aussi la section des liens ci-dessous pour une liste rarement mise à jour d'autres clients alternatifs.
URL du référentiel:
Le dernier a des notes git avec la liste TODO et telles à la référence par défaut pour celles-ci.
Bien que je n'appellerais pas cette application un "bot" ou "" automatiser les comptes d'utilisateurs standard "- l'intention ici n'est pas de publier de messages automatisés ou de gratter quoi que ce soit - le personnel de Discord considère que tous les clients tiers sont des" bots ", et les oblige à utiliser l'API spéciale de deuxième classe (voir Bot vs Comptes d'utilisateur sur tous les documents API), où chaque compte est approuvé par les admis un utilisateur aléatoire non-administration.
Cette application ne se présente pas comme un "bot" et n'utilise pas de points de terminaison spécifiques au bot, donc l'utiliser peut entraîner une terminaison de compte si elle est découverte.
Voir également plus d'informations sur la section de blocage des clients tiers ci-dessous.
Vous avez été averti! :)
Commande et livraison de messages sortants fiables, avec des notifications explicites pour les problèmes détectés de toute nature.
Prise en charge des canaux privés et publics, de la commande de canaux, des threads, des forums, sauf pour en créer de nouveaux.
Per-Server et Global Catch-All-All pour suivre l'activité générale.
Alias / renoms du nom local configurable, blocs / remplacements de messages sortants, filtrage regexp pour les messages reçus.
Prise en charge de la reconfiguration limitée de l'exécution via le canal # rdircd.Control.
Discord simple et cohérent vers la traduction de la Guilde / Channel / du nom d'utilisateur IRC.
Aucun de ces éléments ne changera après la reconnexion, le remaniement des canaux ou du serveur, etc. - La traduction est principalement déterministe et ne dépend pas d'autres noms.
Traduction des mentions de discorde, réponses, pièces jointes, autocollants et emojis dans les MSG entrants, autres événements, annotations de base pour certains liens intégrés.
Prise en charge limitée pour la traduction des mentions et des emojis de l'utilisateur Discord dans les messages envoyés, les modifications et les suppressions.
Commandes de backlog facilement accessibles via / topic (/ t) dans n'importe quel canal, par exemple "/ t log 2h" pour afficher les 2 dernières heures de backlog ou "/ t journal 2019-01-08" pour vider le backlog à partir de ce point sur le présent, récupérant en plusieurs lots si nécessaire.
Les messages envoyés via d'autres moyens (par exemple le navigateur) seront également relayés sur IRC, provenant peut-être d'un Nick Diff, si le nom IRC ne correspond pas à la traduction de Nick Discord-IR.
Prise en charge / utilisation Unicode complète partout.
Le protocole IRC est mis en œuvre à partir des documents IRCV3, mais n'utilise aucun truc non-RFC, il devrait donc être compatible avec les anciens clients. Emballage TLS en option.
Protocole étendu et options de journalisation de débogage, certaines accessibles au moment de l'exécution via le canal # rdircd.debug.
Script unique Python3 qui ne nécessite que le module AIOHTTP, trivial pour exécuter ou déployer n'importe où.
Exécute une empreinte de mémoire relativement stable ~ 40 m sur AMD64, ce qui est probablement plus que par exemple BitlBee-Discord, mais mieux que ces onglets de navigateur qui fuient.
Facile à modifier et à déboguer sans reconstruction, GDB, Rust et autres.
Seuls les mentions d'utilisateurs et les emojis envoyés à partir de l'IRC sont traduits en balises Discord (si activées et avec quelques bizarreries, voir ci-dessous) - pas des canaux, des rôles, des autocollants, des composants, etc.
Aucune prise en charge de l'envoi de pièces jointes ou d'incorporces d'aucune sorte - utilisez webui pour cela, pas IRC.
La discorde annote automatiquement les liens, donc la publication des supports est aussi simple que cela.
Aucune action spécifique à la discorde au-delà de toutes sortes de messages de lecture et d'envoi à des canaux existants n'est pris en charge - c'est-à-dire pas de création de comptes ou de canaux sur la discorde, gérer les rôles, invitations, interdictions, délais d'attente, etc. - utilisez webui, harmonie ou approprié les robots de discorde.
La création de nouveaux discussions privées et de threads Channel / Forum n'est pas prise en charge.
Pour les chats privés, il pourrait être encore dangereux de soutenir - voir plus d'informations sur la section de blocage des clients tiers ci-dessous pour plus de détails.
Ne suit pas du tout la présence des utilisateurs (en ligne, hors ligne, AFK, jeu, etc.).
N'émet pas de jointures / parties de l'utilisateur et gère les noms IRC / des noms de manière très simple, répertoriant uniquement Nicks qui a utilisé la chaîne depuis le démarrage de l'APP et dans IRC-Names-Timeout (1 jour par défaut).
Ignore complètement tous les trucs non-texte en général (par exemple la voix, les profils d'utilisateurs, la bibliothèque de jeux, le magasin, les listes d'amis, etc.).
Discord suit le côté du serveur "read_state", qui n'est utilisé ici de quelque manière que ce soit - le déclenchement de l'historique est fait uniquement manuellement (/ T commandes en Chans), il peut donc parfois être facile à manquer sur les reconnexes silencieuses.
Ne prend pas en charge le mode d'authentification multifactor Discord, mais l'authentification manuelle peut probablement contourner cela - voir la note sur les captchas ci-dessous.
Les commandes de slash (pour les bots) ne sont pas prises en charge de manière particulière, mais vous pouvez probablement les envoyer, si le client IRC les passera.
Pas la chose la plus conviviale, mais probablement la même que l'IRC elle-même.
Je l'exécute uniquement sur Linux, il est donc peu probable que "fonctionne" sur OSX / Windows, mais IDK.
Implémentation ad hoc personnalisée de Discord et IRC, ne bénéficiant de aucun type d'exposition et de tests sur le PYPI et une telle compatibilité WRT, des bogues et des cas d'angle.
Semblent être contraires aux directives Discord pour l'utiliser - voir la section d'avertissement ci-dessus pour plus de détails.
Sur la plate-forme OpenBSD, lors de l'utilisation de IRC password-hash= encodés Scrypt, peut également avoir besoin d'installer le module Scrypt séparément (via EG pkg_add py3-scrypt ), car le port Python ne semble pas y avoir de hashlib.scrypt dans son stdlib.
Le moyen le plus simple pourrait être d'utiliser un package pour / depuis votre distribution Linux, s'il est disponible.
Packages de distribution actuellement connus (à partir de 2020-05-17):
Il y a aussi un dockerfile et docker-compose.yml pour l'exécuter dans un Docker / Podman ou un autre environnement conteneurisé compatible OCI.
(Voir aussi readme.docker-permissions.md doc pour plus d'informations sur les problèmes d'accès commun avec ceux-ci)
Devrait être facile d'installer un script et ses quelques dépendances manuellement, comme décrit dans le reste de cette section ci-dessous.
Sur Debian / Ubuntu, l'installation des dépendances peut être effectuée avec cette seule commande:
# apt install --no-install-recommends python3-minimal python3-aiohttp
D'autres distros Linux ont probablement également des packages similaires, et je recommanderais d'essayer de les utiliser comme première option, afin qu'ils obtiennent des mises à jour et pour éviter le fardeau de maintenance local supplémentaire, et uniquement le report pour installer les modules via "PIP" en cas d'échec.
Sur n'importe quelle distribution arbitraire avec Python (Python3) installé, en utilisant PIP / VENV pour installer le module AIOHTTP (et ses DEG) à un DIR à domicile de l'utilisateur "RDRICD" sans privilégié (qui vous est également utilisé pour exécuter RDIRCD dans l'exemple suivant ci-dessous), mais ignorer cela si vous l'avez déjà installé via le gestionnaire de packages OS ou tel:
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 vous avez / utilisez PIPX (par exemple à partir de repos de distribution), il peut être utilisé pour exécuter des applications Python comme celle-ci et les dépendances automatique-message - juste "Pipx Run" le script principal: pipx run rdircd --help - sans avoir besoin de toucher Venv ou Pip du tout (Pipx le fera "sous le capuchon").
Une fois les exigences ci-dessus installées, le script lui-même peut être récupéré à partir de ce référentiel et s'exécuter comme ceci:
## 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...
Pour la configuration de Daemon / Script à exécuter sur le démarrage du système d'exploitation, le fichier unitaire RDRICD.Service SystemD peut être utilisé dans la plupart des environnements Linux (modifier EXECTSTART = Options et chemins là-bas), ou autrement via le script init.d, ou peut-être dans la session "Screen" en tant que dernière option ad hoc. Assurez-vous qu'il s'exécute en tant qu'utilisateur "RDRICD" créé dans l'extrait ci-dessus, pas comme root.
Pour mettre à jour le script ultérieur, si nécessaire, remplacez-le par une dernière version, par exemple via le téléchargement re-bas par une commande curl ci-dessus, Git-Pull sur le clone Repo, docker-compose up --build , mise à jour du package OS, ou d'une autre manière, généralement lié à la façon dont il a été installé en premier lieu.
Créer un fichier de configuration avec Discord et Ircd Autal Identials dans ~ / .RDRICD.ini (voir tout --conf... opts wrt ces):
[irc]
password = hunter2
[auth]
email = [email protected]
password = discord-passwordRemarque: le mot de passe IRC peut être omis, mais assurez-vous de faire du feu à feu à tout ce qui dans le système (ou peut-être le faire de toute façon).
Si vous définissez le mot de passe cependant, n'utilisez peut-être pas l'option IRC password= comme ci-dessus, et utilisez password-hash= et -H/--conf-pw-scrypt pour le générer à la place. Quoi qu'il en soit, assurez-vous d'utiliser ce mot de passe lors de la configuration également de la connexion à ce serveur dans le client IRC.
Démarrer le démon RDRICD: ./rdircd --debug
Connectez le client IRC à "LocalHost: 6667" - Écouter par défaut / lier l'hôte et le port.
(Voir ./rdircd --conf-dump-defaults ou CLI -i/--irc-bind / -s/--irc-tls-pem-file pour se lier sur différents emballages hôte / port et tls socket, pour les connexions non locales))
Utilisez la commande IRC /list pour voir les canaux pour tous les serveurs / guildes Discord:
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.
Notes sur les informations ici:
/j #axsd.offtopic ( /join ) comme vous le faites avec l'IRC ordinaire pour voir / publier des msgs là-bas.
Les jointures de canaux / pièces du côté IRC n'affectent en aucune façon la discorde.
Exécuter /topic (fonctionne souvent comme /t ) IRC Command pour afficher plus d'informations sur les commandes spécifiques aux canaux, /t log pour récupérer et rejouer le carnet de commandes à partir du dernier événement avant le dernier arrêt RDRICD, /t log list pour répertorier tous les horodatages de l'activité que les pistes RDRICD, OR /t log 2h pour récupérer / Dump Channel Log pour / à partir de l'heure spécifique (Span / Span) (ISO8601 ou un format simple).
Les commandes Daemon Control / Config sont disponibles dans le canal # RDRICD.Control, # RDRICD.DEBUG CHAN peut être utilisé pour modifier diverses journalisations et inspecter l'état de démon et les protocoles plus étroitement, envoyez "l'aide" pour répertorier les commandes disponibles.
Pour un plan large de divers paramètres de configuration pris en charge, voir RDRICD.defaults.ini (Sortie de ./rdircd --conf-dump-defaults ), et plus sur des utilisations particulières de celles ci-dessous.
Des notes sur diverses fonctionnalités facultatives et moins évidentes sont collectées ici.
Voir la section "Utilisation" pour une information plus générale.
Plusieurs fichiers INI peuvent être spécifiés avec l'option -c , sachant mutuellement en séquence.
Le dernier sera mis à jour WRT [State], Token = et des trucs d'exécution similaires, ainsi que toutes les valeurs définies via # RDRICD.Contrôle des commandes de canaux, il peut donc être utile de spécifier une configuration persistante avec l'authentification et des options, et séparer (initialement vide) un à un tel état dynamique.
Eg ./rdircd -c config.ini -c state.ini le fera.
--conf-dump peut être ajouté pour imprimer INI résultant de tous ces éléments.
--conf-dump-defaults le drapeau peut être utilisé pour répertorier toutes les options et leurs valeurs par défaut.
Les mises à jour fréquentes de l'état d'état sont effectuées en place (petites valeurs de longueur fixe), mais vérifier le ctime avant les écritures, il devrait donc être sûr de modifier tout ces fichiers à tout moment.
L'envoi de sighup à la commande Script ou "Recharger" dans le canal de contrôle devrait charger et appliquer des valeurs de tous les fichiers de configuration dans le même ordre. Notez qu'une telle opération ne réinitialise aucune valeur manquante dans les fichiers à leurs valeurs par défaut, appliquez uniquement les choses qui y sont explicitement définies en haut de la configuration actuelle.
Tous les chats dans RDRICD (et Discord) sont un canal .
Les IRC / Q, / Query et / MSG ne peuvent pas être utilisés de manière typique de l'IRC.
Pour parler dans n'importe quel chat privé, rejoignez une chaîne comme # me.chat. <Nom d'utilisateur>, qui se comporte comme tous les autres canaux Discord / RDird.
Il n'y a actuellement aucun moyen de créer de nouveaux chats privés à partir de RDRICD, d'utiliser d'autres clients ou webui pour cela (ou demander à quelqu'un de vous contacter en premier), mais une fois le canal de chat privé créé, il peut également être utilisé dans RDRICD.
Voir également les canaux automatique et / ou / jointer par exemple # rdircd.leftover.me canal pour surveiller les messages privés de manière fiable, si nécessaire.
Dans tous les canaux IRC représentant un canal Discord - Send /topic (OR /t - raccourci pour qu'il soit souvent pris en charge dans les clients IRC) - qui devrait imprimer des informations à jour sur toutes les commandes spécifiques aux canaux, comme celles-ci:
/t info - Affichez certaines informations internes de guilde / canal, comme les ID et autres pour les renommés.
Devrait imprimer le nom de canal exact sur Discord (sans renoms locaux ou traduction de discorde à IRC que fait RDRICD), son sujet, son type, etc., entre autres.
/t info {user-name...} - Informations de requête sur le nom d'utilisateur (ou une partie de celui-ci) dans cette discorde.
Par exemple, /t info joe137 recherchera l'utilisateur joe137 sur un serveur de discorde à qui appartient, en imprimant des informations à leur sujet, comme leurs différents noms de discorde.
/t log [state] - Historique de la relecture depuis le point "State" (dernier RDRICD STOP par défaut).
/t log (identique /t log 1 ) peut être utilisé, par exemple après le redémarrage de RDRICD pour interroger la discorde pour tous les messages qui auraient pu être affichés après son arrêt, et avant qu'il ne soit recommencé (plus d'autres personnes depuis lors).
Ou /t log 0 pour vérifier l'historique depuis le dernier MSG que RDRICD a vu, pour les cas où la discorde / le réseau est floconneuse et que quelque chose aurait pu être perdu de cette façon.
(Lorsque ces numéros 1 et 0 se réfèrent aux horodatages enregistrés de la sortie /t log list , stocké / mis à jour sous [state] dans le fichier INI)
Il peut également être utilisé avec un temps absolu ou relatif, par exemple /t log 15m pour demander / rejouer l'historique des canaux dans les 15 dernières minutes, ou /t log 2019-01-08 12:30 pour rejouer l'historique depuis ce temps spécifique RDRICD-local (sauf si le fuseau horaire y est spécifié également).
Just /t ou /topic dans n'importe quel canal de proxy Discord répertoriera plus de ces commandes et plus d'informations sur la façon de les utiliser.
Le dernier message envoyé à un canal Discord peut être modifié à l'aide de la commande SED-Replacement comme s/hoogle/google/ pour corriger une faute de frappe ou amender rapidement / reformuler / clarifier cette dernière ligne.
Ou //del peut être utilisée pour le supprimer - voir la section "Modifications / supprimer" rapide ci-dessous.
@silent Prefix Command dans les messages peut supprimer les notifications utilisateur à ce sujet (également expliqué ci-dessous quelque part).
Dans des canaux spéciaux comme # rdrICD.Control et # rDRICD.debug: Envoyez h ou help .
Ils peuvent avoir une liste quelque peu longue des commandes prises en charge, par exemple, voici certaines des commandes pour # rDRICD.Control:
status (ou st ) peut être utilisé pour vérifier les infos Discord et IRC.
Les commandes connect / disconnect (ou on / off ) peuvent être utilisées pour contrôler manuellement la connexion Discord, par exemple pour une utilisation plus unique, ou pour supprimer temporairement les avertissements de Conn échoués pendant que le réseau local est en baisse de cette façon.
set irc-disable-reacts-msgs yes - Temps-Discord Reaction Notifications (Utilisation de la commande set ).
Ou set -s irc-disable-reacts-msgs yes pour le rendre permanent ( -s/--save l'indicateur pour enregistrer la valeur dans le fichier de configuration ini), ou set simple sans paramètres pour voir toutes les options de configuration générales et leurs valeurs.
rx Block mee6 bot-noise = (?i)^<MEE6> - Temper tous les messages de mee6 bot.
(Voir la section sur ce filtrage ci-dessous, ou plus d'exemples de tels trucs sous des conseils et trics)
... Et il y en a plus - Tapez help là-bas pour des informations complètes à jour.
# RDIRCD.Monitor peut être utilisé pour voir l'activité à partir de tous les serveurs connectés - obtient tous les messages, préfixés par le nom du canal IRC pertinent.
# rdircd.monitor.guild (où "Guild" est un hachage ou un alias, voir ci-dessus) est un canal couvert similaire pour un serveur / guilde Discord spécifique.
# rdircd.monitor.me peut être utile, par exemple, pour surveiller les chats et les messages privés pour le compte Discord (voir également l'exemple des canaux automatique).
# RDRICD.LeftOver et similaires # rordcd.leftover.GUILD Les canaux sont comme les canaux de moniteur, mais sautez les messages à partir de tous les canaux que le client IRC a rejoints, y compris par exemple /join #rdircd.leftover.game-x Les "restes" de quelque manière que ce soit).
# rDircd.Voice est un canal similaire à # rDRICD.Monitor, mais ne capture des notifications des événements de chat vocale, pour pouvoir suivre ceux en temps opportun.
Ces canaux peuvent être ignorés s'ils ne sont pas nécessaires, ou entièrement désactivés en définissant EG chan-monitor à une valeur vide sous [IRC] INI Config-File section. Par exemple, les canaux de l'activité vocale par rapport sont handicapés par défaut.
Le fichier de configuration dispose également de la section [Unmonitor] pour une liste facultative des noms de canal à ignorer dans les canaux Monitor / Reste, par exemple:
[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 Les touches (comme en partie avant "=") dans une telle section de configuration sont ignorées, et peuvent être n'importe quoi, par exemple, des commentaires expliquant les modèles (comme dans l'exemple ci-dessus), tandis que les valeurs sont soit des noms de canal exacts (avec préfixe Discord, en option # -prefix), ou un "glob:" / "re:" - préfixe glob / regexp motif (globs-like ou python regexps), écrit comme <quelque chose de manière shell ou python regexPS), écrite comme <some-key/comment> = glob:<wildcard-pattern> ou <some-key/comment> = re:<regexp-pattern> - Voir Exemples juste ci-dessus.
Les noms de canaux correspondants par ces filtres seront supprimés des canaux de moniteur, donc cela peut être utilisé pour définir une liste de choses spamnales qui ne vous soucient pas et qui ne veulent pas y voir même.
La commande "Unmonitor" (ou "um") dans # rdircd.Control peut ajouter / supprimer ces filtres à la volée à tout moment. Voir également l'option de configuration match-counters pour suivre si des règles spécifiques sont toujours nécessaires / utilisées.
Les messages dans les canaux de moniteur sont limités à une longueur / lignes spécifiques, pour éviter les inondations excessives par des msgs longs et / ou multi-lignes. Les paramètres "Len-Monitor" et "Len-Monitor-lines" dans la section de configuration [IRC] peuvent être utilisés pour contrôler ces limites, voir "./rlircd --conf-dump-defaults" Sortie pour leurs valeurs par défaut. Il existe également des options pour modifier le format de nom des canaux de moniteur.
Sur l'IRC, tout le monde a un nom, mais ce n'est pas le cas avec Discord, où chaque utilisateur peut avoir des noms suivants:
login - Discord «nom d'utilisateur», identifiant uniquement chaque utilisateur.display - "Nom d'affichage" Défini par l'utilisateur dans les paramètres du compte Discord, pas unique.nick - serveur et «surnoms», défini dans les paramètres du serveur Discord, pas toujours par vous. login est le concept le plus proche des surnoms IRC, car il est à l'échelle mondiale, cohérente, courte, ASCII-only, et peut être utilisée en définissant l'option name-preference-order = login dans la section [Discord] (pas par défaut).
Les clients officiels Discord affichent d'abord les autres noms, c'est pourquoi l'option name-preference-order est par défaut de la valeur nick display login , qui utilise d'abord les surnoms spécifiques à Discord / Friend, le cas échéant, le nom de format libre que l'utilisateur définit les paramètres de compte et leur nom de connexion autrement.
D'autres choses dans des surnoms de sophistime pour l'utilisateur que l'IRC ne permettent pas également d'être remplacés par des caractères Unicode communs, des espaces avec des points moyens "·" par exemple, ou <> des supports IRC-Nick communs avec des flèches Unicode. De longues entailles de discorde sont tronquées.
Il n'y a pas de notifications IRC sur les utilisateurs qui modifient leur affichage / Nick-Names spécifiques à la discorde, et ils n'ont pas à être uniques, ce qui pourrait rendre difficile de dire qui est-qui, s'ils continuent de changer de entaille pour une raison quelconque.
Tout cela est configurable via des paramètres de fichiers INI (ou dans # rdrcd.Control Channel), donc s'il devient trop idiot et exaspérant, définissez name-preference-order = login pour utiliser des entailles uniques et respectueuses d'IRC uniques pour tout le monde.
La commande IRC /who ou /topic info peut aider à traduire entre ces noms, par exemple /t info john1234 peut être utilisé pour imprimer des informations pour ce nom / connexion dans le tampon de canal, qui devrait inclure tous les utilisateurs avec une correspondance partielle de ce nom sur cette discorde spécifique, While /who Commandes recherche toutes les discordes jointes.
(Plus comme "renoms" que "alias", car les anciens noms ne continuent pas à fonctionner pour ceux-ci)
Peut être défini dans le fichier de configuration pour remplacer les préfixes de discorde basés sur le hachage ou les noms de canaux serveur par quelque chose de plus lisible / mémorable ou significatif pour vous:
[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 = joeCela devrait:
Tournez par exemple # jvpp.info en # game-x.info - Lettersoup guild-id en préfixe plus significatif. Cela s'appliquera à tous les canaux de cette discorde - "guilde" renoms.
Changez le format pour les noms de canaux de la discorde "sn3y" de quelque chose comme # sn3y.debug en # logs / debug.log - modification du format de nom de canal.
Le modèle de format utilise la syntaxe python str.format avec "nom" (nom de canal) et "préfixe" (préfixe de guilde - sera des valeurs "log-bot" dans cet exemple). Le format par défaut est {prefix}.{name} .
Cette option de format n'affecte pas le (s) nom (s) de canal du moniteur / restes (par exemple RDircd.Monitor.log-bot ou # rdircd.leftover.game-x) - voir "Chan-Monitor-Guild" et "Chan-leftover-Guild" sous la section [IRC] pour changer cela.
Renommez ce canal long pour avoir un nom plus court (conservation de la préfixe de guilde) - "chan" renoms.
Notez que cela affecte toutes les guildes où un tel nom de canal existe, et le nom de la source doit être au format IRC, comme dans / liste, et est RFC1459-CASEMPAP (comme sur IRC).
Renommer le canal avec id = 710035588048224269 à "Memes" (préfixe de guilde de retenue) - "Chan" renoms à l'aide de la spécification @ canal-id spec.
Cet identifiant de canal de discorde long (également appelé "Snowflake") peut être trouvé en tapant /t info à la commande dans le canal IRC correspondant, et peut être utilisé pour se référer à ce canal spécifique, c'est-à-dire en renommant celui-ci #Général sur ce serveur de discorde au lieu de renommer tous les canaux #Généraux partout.
Ceci est particulièrement utile lorsque deux canaux ont le même nom exact dans la même discorde, et normalement seront attribués .<id-hash> Suffixes non descriptifs.
Renommer les utilisateurs de couple, référencés par leur nom d'utilisateur Discord et leur ID.
/t info <nick-or-part-of-it> dans Discord Channel ou similaire /who -command peut aider à rechercher des identifiants discords, comme ceux qui y sont utilisés.
Actuellement, seuls les types de renommer sont implémentés, pour les préfixes et les canaux Discord, mais il existe également des options sous [IRC] pour définir des noms pour les canaux système / moniteur / restes et chats privés - "Chan-Sys", "Chan-Prive", "Chan-Monitor" et tels (voir "./rdircd - Outpied-Contel-Default-Default).
Définissez chan-monitor-guild = {prefix} Là, par exemple, pour que # game-x canal soit catch-tout pour tous les messages de cette discorde, sans par défaut # RDRICD.Monitor. * Prefix.
Discord Private Messages Créer et être publié sur les canaux dans le serveur "ME" / Guilde, comme ils le font dans Discord Webui, et peuvent être interagi de la même manière que n'importe quelle autre guilde / canaux (liste, jointure / partie, envoi / RECV MSGS, etc.).
Rejoignez # rDircd.Monitor.me (ou # rDRICD.Monitor, voir ci-dessus) pour y obtenir tous les nouveaux msgs / chats, ainsi que les notifications de changement de relation (Demandes d'amis / ajouts / supprimer) comme avis.
Accepter les demandes d'amis et l'ajout / les supprimer peut être effectué via Discord WebUI régulier et n'est pas implémenté dans ce client de manière particulière.
Voir également la section des canaux automatique ci-dessous pour un moyen facile de faire ressortir de nouveaux chats privés dans le client IRC via Invite.
"Threads" est une fonctionnalité Discord, permettant aux utilisateurs non-trafiquants de créer des sous-canaux ad hoc transitoires à tout moment pour un sujet spécifique, qui est en train de cacher automatiquement ("archivé") après un délai d'inactivité relativement short (comme un jour).
Les canaux Discord "Forum" sont essentiellement des canaux, où les gens ne peuvent créer et parler que dans les theads, avec la liste de ceux qui remplacent les bavardages par défaut.
Tous les threads non archivés doivent être affichés dans la liste des canaux RDRICD en tant que canaux IRC réguliers, avec des noms comme # GG.General. = VOT5.lets · Discuter · Stuff, étendre le nom de Chan Parent avec le thread ID TAG ("= VOT5" dans cet exemple) et un nom de thread éventuellement tronqué (voir "Thread-Chan-Name-Len" Config Option).
Il existe plusieurs options pour voir et interagir avec les threads du canal parent (principalement dans la section [Discord], voir - Conf-Dump-Defaults Sortie):
[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
...Mais même avec tous ces handicapés, un simple avis doit être envoyé à la chaîne lorsque les fils sont démarrés, de sorte que l'on ne les manquera pas entièrement.
Il n'y a pas de prise en charge de la création de nouveaux threads à partir de l'IRC, des anciens désarchivants ou de la gestion autrement, et rejoindre le canal de thread dans IRC ne "rejoigne pas le thread" dans Discord UI (l'entraîner sous le nom du canal), mais la publication de tout devrait le faire automatiquement.
Le paramètre "Chan-Auto-Join-Re" dans la section [IRC] permet de spécifier Regexp pour faire correspondre le nom de la chaîne (sans préfixe #) pour s'auto-jointer lorsque des messages y apparaissent.
Par exemple, pour automatiquement joigner n'importe quel # me.
[irc]
chan-auto-join-re = ^me. Ou pour que le client IRC ait automatiquement joué tous les canaux, utilisez chan-auto-join-re = .
La valeur vide de cette option (par défaut) ne correspondra à rien.
Cela peut être utilisé comme alternative au suivi de nouvelles choses via # rDRICD.Monitor / Leftover.
Ce regexp peut être modifié au moment de l'exécution à l'aide de la commande "set" dans le canal # rdircd.Control, identique à toutes les autres valeurs, par exemple, par exemple, activer / désactiver cette fonction pour des discordes ou canaux spécifiques.
Les mentions sont des balises @username sur Discord, conçues pour alerter quelqu'un sur un message direct.
Avec la configuration par défaut, lorsque vous voyez par exemple <Galaxy?·Brain> Hi! Et je veux répondre à les mettre en évidence, envoyer Hey @galaxy and welcome devrait probablement fonctionner. Peut également utiliser leur Nick IRC complet, pour être sûr.
Comment cela fonctionne: si RDRICD correspond à la confusion msg-mention-re Regexp contre quelque chose dans un message envoyé (par exemple @galaxy @ -metion ci-dessus), qui serait traité comme une "mention", qui est soit unique et traduit en disque, une discours dans le message envoyé, ou renvoie un préavis d'erreur (avec des entailles qui correspondent qui mentionnent ambigu, si le message envoyé).
La valeur par défaut pour cela devrait ressembler à ceci:
[discord]
msg-mention-re = (?:^|s)(@)(?P<nick>[^s, ; @+!]+) Qui correspondrait à toute mention @nick à l'espace ou à la ponctuation en forme de mot dans les lignes envoyées.
Regexp (Python "RE" Syntax) doit avoir nommé le groupe "Nick" avec Nick / Username Lookup String, qui sera remplacé par la balise de mention Discord, et tous les autres groupes de capture (c'est-à-dire sans ?: Seront supprimés (comme @ dans ci-dessus regexp).
Le regexp par défaut ci-dessus devrait toujours permettre d'envoyer par exemple @something pour apparaître non-highlighted dans webApp (et sans en raison de Markdown), car il ne sera pas égalé par (?:^|s) partie due à ce préfixe de barre oblique inverse.
Comme autre exemple, pour avoir des points forts de style IRC classiques au début de la ligne, Regexp comme celui-ci peut être utilisé:
msg-mention-re = ^(?P<nick>S+)(:)(?:s|$)
Et devrait traduire par exemple mk-fg: some msg dans @mk-fg some msg (avec @ -part étant mentionné-tag). L'espace de fuite est inclus dans le regexp pour éviter de faire correspondre les liens d'URL.
Pour ID Spécifique utilisateur Discord, le groupe "Nick" sera utilisé de manière suivante:
Correspondance insensible à la cas contre tous les noms IRC récents de guilde (auteurs de messages, réactions, utilisateurs de canaux privés, etc.). user-mention-cache-timeout Config Option Controls "récent" Timeout.
Recherchez l'achèvement du nom unique par préfixe, comme Discord fait dans webui pour l'achèvement automatique après @ est typé.
Si aucune correspondance mise en cache ou unique trouvée - un avis d'erreur ne sera émis et le message non envoyé.
Un tel comportement strict est conçu pour éviter toute traduction involontaire, et mettre en évidence la mauvaise personne ne devrait généralement être possible que par mal orthographié.
L'option msg-mention-re-ignore (regexp pour correspondre à la pleine capture du motif ci-dessus) peut également être utilisée pour ignorer certaines choses non référencées en étant traitées comme telles, qui auraient autrement été capturées par le premier regexp, ce qui leur a également capturé des groupes, ce qui peut être utilisé pour annuler le fait que vous échappez.
Notez que les listes d'utilisateurs Discord peuvent être assez massives (500k + utilisateurs), ne sont pas divisées par la chaîne et ne sont pas destinées à être prédéfinies par le client, interrogées uniquement pour les compléments ou les pièces visibles, qui ne mappent pas bien pour l'IRC, donc toute cette magie.
Le regexp similaire est configuré pour les emojis par disque:
msg-emoji-re = (?:^|s)(:)(?P<emoji>w+)(:)(?=[^w]|$)
Où, par exemple I use :Arch: btw de IRC correspondra à ce groupe regexp, recherchez / remplacez le groupe "emoji" en utilisant les emojis de cette discorde (insensible à la casse), et soit l'envoyez traduit comme I use ? btw , ou RETOUR RETOUR AVIS si ces emoji ne sont pas disponibles dans cette discorde et non sur une liste de celles génériques Unicode.
Définissez msg-mention-re / msg-emoji-re à une valeur vide pour désactiver ces traductions.
Semblable à Discord User mentions ci-dessus, il existe une option spéciale regexp qui correspond aux commandes à interpréter comme modifier ou la suppression du dernier message envoyé à ce canal.
Les regexps par défaut ressemblent à ceci (vérifiez --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*$ Ils correspondent aux lignes d'amendement de suivi SED / Perl / IRC comme s/spam/ham/ , et //del , qui ne sera jamais envoyée à Discord, uniquement utilisée comme commandes internes.
( s|/some/path|/other/path| et s:cat /dev/input/mouse0 | hexdump:hexdump </dev/input/mouse0: Les syntaxes sont également autorisées par défaut Edit-Regexp, tout comme avec SED, pour une gestion plus facile de choses communes comme des chemins, ce qui peut y avoir ces caractères)
Les deux commandes correspondent à celles-ci fonctionnent sur le dernier message envoyé par RDRICD au même canal Discord, avec //del en supprimant simplement ce dernier message, et modifiez l'exécution de Python re.sub () (pcre-like) RegExp-Replacement Fonction.
"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.
