Le messager de tout

Tous les messagers existants ont leurs avantages et leurs inconvénients, mais chacun tire la couverture sur le côté en raison d'une incompatibilité avec les autres - et les utilisateurs en souffrent.

XMPP pourrait devenir une norme unique, mais contrairement au courrier électronique, il est apparu relativement tard et n'a pas réussi à gagner suffisamment d'audience pour que les entreprises ne puissent pas déjà le refuser. Après tout, ils ont rapidement réalisé que sans retenir le public dans leur propre écosystème, il n'y avait pas grand-chose à gagner. Et d'ailleurs, je dois admettre que XMPP avait suffisamment de lacunes en raison de l'abondance d'extensions, dont beaucoup, malgré leur importance, sont restées à l'état expérimental, et certaines se sont dupliquées complètement.

Ayant vécu dans le «nouveau monde merveilleux» d'une douzaine de messageries instantanées dans le smartphone, et ayant ressenti toutes les lacunes de cet état de fait, nous sommes enfin prêts pour quelque chose de nouveau.

Et oui, nous avons besoin d'une nouvelle norme!

Un excellent Future Messenger satisfait aux exigences suivantes: assurer la fiabilité, la sécurité, grâce au développement ouvert et à la décentralisation, la portabilité (multiplateforme), le multi-protocole (la possibilité de se connecter à d'autres réseaux de communication) et la convivialité.

Pourquoi tout est-il si mauvais?

Mais d'abord, découvrons pourquoi tout le monde ne passe à aucun messager centralisé == déjà populaire, que ce soit une WhatsApp conditionnelle ou, par exemple, Telegram, qui a une audience considérable en Russie.

Bien sûr, la construction centralisée permet aux propriétaires de gagner plus d'argent, et donc non seulement de payer pour le développement, mais aussi d'investir des sommes importantes dans la publicité et même la glorification de fonctions pratiquement absentes , telles que la sécurité des services, par exemple. Cependant, en même temps, le propriétaire peut soudainement décider de fermer le service, le tracteur pour déplacer le câble du centre de données, ou tout simplement un messager peut être interdit sur le territoire d'un certain pays. Pas nécessairement pour des raisons politiques, peut-être, et à la demande des titulaires de droits d'auteur conditionnels, il peut y avoir de nombreuses raisons. C'est bien si, malgré la taille insignifiante du marché, Telegram continue de travailler en Russie avec un succès variable, mais cela est dû aux comptes personnels du propriétaire, et en cas de blocage du même WhatsApp, Facebook a peu de chances d'investir massivement pour contourner les verrous.

Il est difficile de parler immédiatement pour tous les messagers centralisés, rassemblant sous un seul peigne. Il y a un mal absolu avec un client, un serveur et un protocole propriétaires qui ne fonctionnent que sur quelques-unes des plates-formes les plus populaires et n'ont aucun cryptage. Il y a aussi une bonté relative, par exemple, le messager Signal, qui est entièrement ouvert, mais les serveurs ne prennent pas en charge le mode fédéré, c'est pourquoi tout le monde dépend du serveur central avec toutes les conséquences qui en découlent. Ici, la classification doit être effectuée selon un principe différent, mais cela dépasse le cadre de cet article.

Eh bien, pourquoi ne pas passer à quelque chose de fédéral. Par exemple, la même matrice. Je ne parlerai pas de HTTP Long Polling, de la faible résilience du serveur et de la geekiness explicite de l'interface client - toutes ces tâches sont résolubles, bien que non triviales (au niveau mondial, cela ne change rien). J'aime que les développeurs prennent en compte l'expérience de XMPP et développent des spécifications communes au lieu d'un tas de XEP indépendants, mais ce n'est qu'un des inconvénients de XMPP. Un autre problème est l'appareil classique du réseau fédéral, lorsque nous sommes obligés de choisir un serveur et de faire confiance à son propriétaire pour s'assurer que le serveur fonctionne et ne le fermera pas. Et en cas de nouvelle panne du centre de données, nous serons coupés du monde, ne pouvant plus communiquer avec le compte précédent sur un autre serveur. Même si vous créez un nouveau compte, et que vous lui transférez la liste de vos contacts depuis l'ancien serveur, lors de la communication, vous devrez en quelque sorte confirmer à nouveau que c'est bien vous, et non pas quelqu'un qui vous présente.

Dans ce cas, peut-être abandonner complètement le serveur? Il existe un certain nombre de messageries instantanées basées sur une technologie sans serveur. Un cas particulier ici est le populaire Firechat dans les cercles étroits, qui utilise un réseau maillé d'appareils wifi et bluetooth pour communiquer avec les utilisateurs. Ce messager fonctionne vraiment bien lorsque tous les utilisateurs sont concentrés, par exemple, sur la zone. Mais c'est une situation assez spécifique, et même si nous imaginons une situation où chaque habitant de la planète installe une application, cela crée beaucoup d'autres problèmes, des ruptures de réseau maillé par les signes géographiques et la vitesse des échanges de messages avec des utilisateurs distants, à la quantité de données stockées nécessaires sur les appareils. Mais, probablement, ce messager est assommé de la masse totale et dans notre comparaison est superflu. Il est plus expérimental que centré sur l'utilisateur.

Il existe également des projets tels que Tox essayant d'implémenter un messager p2p. Cette approche vous permet de ne pas vous soucier de la sécurité du serveur, et il est presque impossible de bloquer un tel messager. Tox a beaucoup de problèmes, mais c'est un projet très intéressant avec sa propre niche. Cela n'a aucun sens d'énumérer les inconvénients spécifiques de Tox, car le projet se développe et malgré le fait que les services p2p sont beaucoup plus difficiles à développer, si vous définissez une telle tâche, vous pouvez trouver différentes architectures intéressantes pour construire un tel réseau: avec ses propres avantages et inconvénients, différentes exigences pour la largeur du canal Internet et la quantité d'espace sur l'appareil, avec des super-nœuds, une connexion simultanée à partir de différents appareils et même la remise de messages hors ligne. Mais la redondance du trafic sera toujours importante par rapport à l'architecture client-serveur et la décharge accrue de la batterie sur les appareils mobiles en raison de la nécessité de maintenir constamment un grand nombre de connexions et de divers calculs.

Ainsi, bien que le p2p soit une technologie intéressante, il se révélera inefficace si, par exemple, l'envoi de vos coordonnées aux sauveteurs, se trouvant quelque part sur un arbre de la taïga avec presque aucune connexion Internet et 1% de charge de batterie.

Comment y remédier?

Par conséquent, je veux introduire une architecture client-serveur hybride qui a pris le meilleur des approches existantes et a évité leurs inconvénients.

Ainsi, pour que notre messager disposant des ressources minimales nécessaires fonctionne sur les appareils mobiles, nous utiliserons le modèle client-serveur, où le maximum d'opérations informatiques et de ressources exigeantes en trafic sont concentrées sur les serveurs, et côté client, les données sont décryptées et affichées pour l'utilisateur.

Adressage

Chaque utilisateur reçoit son adresse au format E-Mail, ou XMPP, c'est-à-dire pseudo @ domaine. Mais contrairement aux services susmentionnés, la spécification d'un domaine ne porte pas le même rôle d'adresse important dans cette architecture.

Les domaines sont plus susceptibles d'être utilisés comme registraires de surnoms pour exclure la possibilité que tous les surnoms existants puissent être occupés intentionnellement ou non.

Les domaines coûtent de l'argent sur Internet, ce qui n'empêche pas l'enregistrement de masse, mais réduit considérablement sa portée. Dans les services centralisés, l'accès se fait souvent via un lien vers un téléphone mobile, ce qui n'est pas non plus un facteur exclusif, mais les cartes SIM ne sont pas non plus prises des airs! Et à cet égard, en passant, je me demande comment ils vont lutter contre cela dans https://toxme.io/ - un service pour Tox qui vous permet d'associer des touches longues à un surnom court. Je ne vois aucune raison pour laquelle ils ne peuvent pas être spammés avec des milliards de surnoms indésirables.
En outre, le domaine peut avoir un sens pour divers comptes pour la maison et le travail. Ou pour organiser un réseau d'entreprise interne.

Du point de vue de l'utilisateur, pour écrire à quelqu'un, vous devez connaître son identifiant complet ou sa clé publique.

Du point de vue du logiciel serveur, si un utilisateur est demandé pour son empreinte digitale, le serveur recherche dans sa table la connexion qui lui est associée, s'il est demandé immédiatement pour la connexion, respectivement, cette étape est ignorée. Ensuite, la connexion et l'adresse du serveur auquel le compte est actuellement délégué sont effectuées. S'il n'y a pas de telles entrées, il est considéré que le compte indiqué après @ dans la connexion est responsable du compte.

Profil utilisateur

L'application cliente stocke un profil utilisateur représentant:

• Connexion utilisateur complète
• Liste des serveurs de sauvegarde
• Clé d'utilisateur publique et privée
• Informations de profil telles que la liste de contacts, les paramètres de chat et le profil utilisateur

Les clés publiques de chaque utilisateur sont réparties entre chacun des serveurs du réseau fédéré. L'utilisateur peut se connecter à n'importe lequel des serveurs, car l'authentification n'utilise pas un hachage de mot de passe stocké dans la base de données du serveur, mais la clé privée d'un utilisateur.

La procédure d'autorisation est la suivante: le serveur envoie au client un ensemble aléatoire de données chiffrées avec la clé publique du client, le client déchiffre avec sa clé privée et envoie un hachage des données déchiffrées au serveur. Si les hachages de données correspondent, le serveur autorisera l'utilisateur. Dans le même temps, si l'utilisateur a modifié pour la dernière fois le serveur auquel la connexion est établie, tous les serveurs du réseau fédéré sont informés du nouvel emplacement de l'utilisateur.

L'absence de la nécessité de se souvenir du mot de passe (cependant, le client vous permet de crypter la clé privée) simplifie à la fois l'interaction avec le messager et crée le risque de perdre vos clés. Pour éviter cela, il est recommandé de les dupliquer sur d'autres appareils utilisateurs. Rien n'empêche de discuter sous le même compte de plusieurs appareils en même temps, la seule limitation est qu'ils doivent tous être connectés au même serveur, sinon l'architecture deviendra trop confuse. Mais ce n'est guère un gros inconvénient.

Module complémentaire pour les navigateurs

Pour de nombreux produits, le point faible est une application web. Et cette solution, bien sûr, présente de nombreux inconvénients. Un tel chat ne sera pas téléchargé pendant que vous êtes hors ligne, vous devrez alors attendre un téléchargement complet, et l'adresse peut être bloquée, ou le serveur peut se bloquer. Tri manuel des adresses - je ne voudrais pas particulièrement.

Et l'option n'est pas encore exclue qu'un attaquant piratera une application Web et intégrera du code qui fusionnera toutes vos données - même après que l'autre partie de l'application les ait décryptées pour vous, et que vous ne le sachiez même pas.

À cet égard, je propose d'abandonner l'application Web en tant que telle et de proposer l'installation d'un module complémentaire pour le navigateur, dans lequel tous ces défauts sont par définition absents.

De plus, l'absence de nécessité pour les propriétaires des serveurs de configuration du client Web d'abaisser le seuil d'entrée pour la création de leur serveur. Chaque foyer a son propre serveur!

Les transports

Qui a besoin d'un messager avec lequel il n'y a personne avec qui communiquer? Il existe des projets intéressants de messagers inhabituels, mais le problème du manque d'audience ne leur permet pas de gagner au moins une certaine popularité. En conséquence, le plus souvent, les messagers avec un large public gagnent encore plus d'audience, et les messagers instantanés avec un petit public le perdent. Et le plus souvent, cette situation ne peut que modifier des investissements importants dans la publicité.
Eh bien, en plus, cet état de fait nécessite l'installation d'un autre messager, lorsque vous avez un besoin urgent de contacter quelqu'un qui n'est pas sur d'autres réseaux.

Par conséquent, le serveur doit prendre en charge le fonctionnement des transports vers des réseaux tiers.
Si l'utilisateur spécifie les données à connecter à ses comptes dans d'autres messageries instantanées, il verra les personnes des réseaux qu'il a connectés dans ses contacts.
La connexion à des réseaux tiers est établie côté serveur et, dans le client, les contacts sont affichés comme les plus ordinaires, avec des différences minimales - par exemple, l'icône du réseau d'où l'utilisateur vient est affichée.

Comme inconvénient, il devient nécessaire de faire confiance au serveur avec ses données pour se connecter à des réseaux tiers. Tout le monde n'est pas prêt à déléguer son autorité à un serveur tiers, vous devez donc encourager la création de vos propres serveurs de toutes les manières.

Cryptographie

Bien sûr, un périphérique réseau décentralisé ne parvient pas à se passer du cryptage de toutes les données transmises, car nous ne pouvons pas être sûrs que même dans le serveur qui nous est confié, une sorte de signet qui fusionne toutes les données n'est pas intégrée.
Auparavant, il était déjà indiqué que la paire de clés de l'utilisateur est utilisée pour l'autorisation, tous les messages envoyés à d'autres utilisateurs sont également signés avec la clé privée de l'expéditeur et sont cryptés avec la clé publique du destinataire.

Il n'y a rien de nouveau ici, des outils de cryptage GPG standard sont utilisés.
Le problème de cryptage dans les groupes n'a pas encore été résolu, mais vous pouvez probablement utiliser le mécanisme utilisé dans Signal.

Ce qui a déjà été fait

Pour le moment, nous avons déjà créé un serveur en Python utilisant Tornado, qui implémente les fonctions de base du messager, il y a une version web légèrement figée qui devrait être convertie en un ajout pour le navigateur, il y a une bibliothèque à Rust, sur la base de laquelle le client fonctionne avec une interface QML.

La connexion au serveur est effectuée à l'aide de WebSockets, dans lesquels les données sont sérialisées par défaut au format binaire de représentation des données CBOR, mais lors de l'établissement d'une connexion WebSockets, il est possible de demander un format différent, par exemple protobuf.

Je considère également qu'il est important de noter que le client utilise une division en une liste de chats, triée par date des derniers messages, largement utilisée dans les messageries instantanées modernes, et une liste traditionnelle, avec le tri des contacts en catégories. Avec l'utilisation active du messager, vous devez interagir avec un grand nombre de chats et il devient difficile de les rechercher dans un ordre de liste en constante évolution. Dans le même Telegram résout partiellement le problème d'épingler les chats sélectionnés en haut de la liste, mais ce n'est qu'une solution temporaire au problème.

→ Voici les référentiels qui contiennent nos idées