Ce que j'ai remarqué avec le projet Movim, sur lequel je m'amuse depuis 2008, c'est la relative stabilité de son architecture en grande partie explicable par l'utilisation exclusive du protocole de communication XMPP et cela dès le début du développement.

Depuis quelques années déjà je n'ai cessé de répéter et de défendre la vision que j'ai d'un "vrai" réseau social et en quoi Movim apporte une solution pérenne et compatible avec celle-ci.

Le plus grand souci avec cette architecture, c'est d'avoir à ré-expliquer des concepts de base qui peuvent se retrouver dans de nombreux autres projets informatiques et qui, de façon surprenante, ne trouvent pas d'écho lorsqu'il s'agit de les mettre en pratique sur les réseaux sociaux.

La décentralisation n'est pas le cœur du problème

Le premier point qui revient souvent lorsque je parle de Movim c'est le coté décentralisé du réseau. Aspect que nous retrouvons également sur des réseaux comme Diaspora*, l'email ou le Web. Mais ce qui m'embête ici c'est que l'idée même d'avoir un réseau (qu'il soit social, ou pas) décentralisé n'est que l'un des effets d'un autre point que j'estime bien plus important: la standardisation.

Tout comme la construction d'un réseau de chemin de fer ne peut pas se faire si la forme et l'écartement des rails n'est pas la même entre les gares, l'utilisation des standards pour formaliser et documenter la structure des échanges est nécessaire.

Quand je parle ici de réseau décentralisé je ne donne pas de structure particulière à celui-ci. Je fais uniquement référence au fait qu'un réseau décentralisé s'oppose aux architectures centralisées (no shit!) où la totalité des informations se trouvent en un point (logique ou physique) bien précis et où l'intégralité des utilisateurs viennent se greffer pour accéder et participer aux échanges. Prenez la taille et la forme que vous voulez, tant que ça n'est pas centralisé ça me va.

Lorsqu'on construit un nouveau réseau, définir la structure des échanges qui vont y transiter fait partie des points à prioriser absolument, et cela dès le tout début du projet. Il faut définir la structure et le comportement de tous les acteurs de ce réseau en poussant ces standards, non pas uniquement entre les serveurs (si nous avons un réseau plutôt a-centré), mais aussi avec les échanges avec les clients.

Vouloir à tout prix décentraliser sans donner les moyens aux développeurs tiers de pouvoir s'interconnecter sans soucis avec l'intégralité des autres nœuds n'est que perte de temps.

Movim n'est qu'un client

Tout est dans le titre, Movim n'est qu'un client du réseau XMPP. Tout comme pour l'email, vous n'écrivez pas directement vos courriels sur le serveur sur lequel ils sont hébergés (ou alors en passant par une interface comme un webmail). Dans tous les cas nous aurons le même schéma : un client qui se connecte à son serveur mail et qui offre une interface à celui-ci.

Et c'est ici le plus gros problème du projet Diaspora*, le client est aussi le serveur, si bien que l'on ne peut que difficilement faire évoluer l'un sans faire évoluer l’autre. De plus, tout projet tiers qui souhaiterait interagir avec le réseau Diaspora* devra le faire en passant par leur propre projet.

Les APIs ne sont jamais une solution

J'ai une petite phrase que je sors souvent pour ça. Les API sont les protocoles des paresseux. Pourquoi ? Car lors de la définition d'un protocole (standard) il n'est jamais question de tenir compte des spécificités techniques ou architecturales du/des serveur(s) et/ou du/des client(s). Il faut définir quelque chose d'universel, de passe partout et qui pourra être amélioré par tous. Je ne vais pas vous mentir, cela est long et difficile. Il faut se mettre d'accord, faire des compromis, continuellement échanger pour tenir compte des évolutions du réseau, de la sécurité, des comportements, des habitudes des utilisateurs… mais tout nouvel entrant aura lui aussi la possibilité d'apporter sa pierre à l'édifice en implémentant et en améliorant le protocole existant.

Une API est ainsi beaucoup plus simple et rapide à écrire, avec très souvent un résultat beaucoup plus adapté à l'utilisation que souhaite en faire son auteur. Mais quid des autres projets, des autres utilisateurs ? Si je souhaite créer un nouveau projet qui serait pleinement compatible avec Diaspora* et que ceux-ci décident de changer la structure de leurs échanges, comment m'assurer que je pourrais rester compatible avec eux ?

Certes, pour le projet Diaspora* il existe des une librairie qui peut être réutilisée dans d'autres projets et de la documentation sur comment fonctionnent les échanges mais ceux-ci sont bien souvent adaptés au moment où les évolutions apparaissent dans le projet.

Imaginons que je souhaite pousser mon projet de serveur plus loin et que je décide de me mettre d'accord avec les développeurs de Diaspora* sur la création d'une documentation stable et où toute modification devra être discutée et approuvée par les deux partis. Je suis en train de créer un protocole.

De plus une API va systématiquement créer un déséquilibre entre ses créateurs et ses "consommateurs" (ce qui sera encore plus prononcé si le fonctionnement de celle-ci est fermé).

Et donc ?

Movim n'est qu'un client, tous les échanges qui sont fait avec le réseau sont définis dans les RFC et les nombreuses extensions du protocole XMPP. Architecturalement Movim ne stocke rien. Tout comme pour le réseau email, tout est sur les serveurs et le client va juste s'y connecter et, à la limite, créer un peu de cache pour éviter d'avoir à recharger les mêmes informations plusieurs fois.

Le cœur du fonctionnement de Movim est là, les informations étant ici "cachées" dans une base de données SQL. Movim n'est donc pas dépendant d'un serveur XMPP particulier. Ici tout comportement particulier venant d'un client ou d'un serveur est vu comme un non respect du standard et est donc considéré comme un bug.

L'ensemble des fonctionnalités proposées par Movim peuvent donc être faites par un autre client qui respecterait les mêmes standards, tout comme pour l'email (avec Thunderbird ou Outlook par exemple) ou le Web (entre Chrome, Firefox…). Ce n'est qu'une interface Web à ce réseau. Toutes les informations gérées par Movim (à l'exception de quelques unes relatives au serveur sur lequel Movim est installé) comme les profils (avatars, vcards…), les messages (ainsi que leur historique), les préférences, les favoris, les billets… sont publiées et gérées par XMPP.

Vous pouvez essayer et tronquer les tables post, message, contact ou presence de la base de données, tout sera resynchronisé avec le serveur XMPP au bout de quelques temps (certaines récupérations de données nécessitent une action de l'utilisateur).

Pourquoi cette architecture est elle viable ?

Car un projet ça vit, ça meurt, un protocole c'est gravé dans le marbre (ou des RFC). Une architecture décentralisée orchestrée par un protocole standard ne possède que peu de relations de force entre ses différentes entités. Si demain un serveur et/ou client XMPP venait à disparaitre, il n'impacterait que peu le réseau existant qui trouverait alors d'autres alternatives à celui-ci, tout en conservant ses habitudes.

D'un point de vue sécurité c'est également beaucoup plus respectable de travailler tous ensemble sur une façon d'échanger les choses et d'ainsi avoir plusieurs dizaines (centaines) de pair de yeux pour trouver le maximum de failles possibles. L'hétérogénéité du parc applicatif utilisant un réseau comme XMPP étant aussi un merveilleux moyen d'éviter des attaques de grande ampleur (la multitude de langages, systèmes, applications complexifiant grandement la tâche). Notez tout de même qu'il y a toujours possibilité de trouver une faille de sécurité au sein même du protocole.

tl;dr

La décentralisation c'est le bien mais sans standardisation ça ne sert pas à grand chose. Donc des standards (comme XMPP), mangez-en.