Présentation du protocole fédéré

Parley propose un réseau de messagerie instantanée sans serveur central. Chaque utilisateur déploie une instance liée à son domaine (ex. alice@foo.com sur foo.com). Les instances se découvrent via DNS et des documents d’identité standard, puis échangent des messages signés sur HTTPS. Le protocole expose l’ensemble du réseau à des clients IRC classiques (irssi, WeeChat, Textual) sans nécessiter de plugin. Les identités sont présentées sous forme d’adresses e‑mail, ce qui permet d’utiliser les commandes IRC habituelles : /msg alice@foo.com hi fonctionne même si les deux serveurs ne se sont jamais rencontrés auparavant.

Mécanisme de résolution des mentions

Avant la mise à jour, la fonction namesAccount considérait tout nick isolé comme une mention, même lorsqu’il était suivi d’un deux‑points. Ainsi, dans une salle contenant bob@foo.com et bob@bar.com, le texte bob: lunch? déclenchait une notification sur les deux comptes. Le correctif introduit le principe « read‑as‑the‑sender‑was‑shown » (R189) : un nom complet bob:bar.com désigne toujours bob@bar.com, tandis qu’un nick nu bob ne désigne que l’utilisateur local de l’expéditeur. Le texte bar à l’intérieur de alice:bar.com ne correspond à aucun compte. Cette logique repose sur la lecture du champ s.peers dans la fonction pushConsidered, protégée par le mutex s.mu déjà détenu par les appelants.

a notification was pushed to /bar.com/bob and should not have been

Le test TestOnlyTheBobThatWasMeantIsPushed crée deux instances avec un bob chacune et vérifie que chaque ligne ne pousse qu’une notification vers le compte explicitement nommé. Le même scénario est couvert par TestANameMeansWhoTheSenderWasShown, qui valide le comportement case‑by‑case.

Tests et validation

Le pipeline CI exécute make test avec l’option -race, garantissant l’absence de conditions de concurrence. Le test d’intégration a réussi dix fois consécutives, confirmant la stabilité du nouveau mécanisme. L’outil bte check parley.bt ne signale aucune erreur et conserve les sept avertissements déjà présents sur la branche principale, ce qui indique que la modification n’a pas introduit de régressions syntaxiques.

Limites et perspectives

Le projet reste un proof‑of‑concept : il fonctionne avec des clients IRC standards, mais il n’est pas encore durci contre les attaques réseau. La documentation mentionne explicitement que le démon n’a pas été testé dans un environnement Docker, ce qui limite la reproductibilité des déploiements automatisés. De plus, la prise en charge des tags IRCv3 (server‑time, message‑tags, echo‑message, multi‑prefix, setname) est fournie, mais aucune évaluation de performance n’est fournie pour les scénarios à grande échelle. Les contributeurs devront donc renforcer la sécurité TLS, ajouter des contrôles d’accès granulaire et mesurer la latence de la fédération avant une mise en production.