Diaspora et Friendica : commentaires sur les protocoles

Depuis quelques temps, le projet Friendica (anciennement Friendika, donc) dépense une énergie folle pour se rendre compatible avec le porte-étendard des réseaux sociaux acentrés libres : j’ai nommé Diaspora.

Quand je dis « le projet Friendica« , je devrais plutôt dire son concepteur. Ce dernier progresse bien, mais il a récemment posté un témoignage assez éclairant sur le protocole employé par Diaspora. Avec sa permission, je me permets de poster ici ma modeste traduction. Pour le contexte, l’original est ici, et s’inscrit dans une conversation sur les actuelles limites de l’interopérabilité entre les deux réseaux.

Vous pourriez trouver cela amusant. Ou pas…

Il y a deux couches, dans le protocole Diaspora, qui valent le coup d’être mentionnées. Le transport « physique » est globalement du Salmon, un protocole connu. La charge utile, en revanche, est propriétaire.

Il y a plusieurs mois, j’ai mis en lumière le fait que la variante de Salmon utilisée par Diaspora était complètement déficiente, et ce de plusieurs manières. John Panzer et moi avons eu un grand moment de « mékeskifon?! » quand je lui ai montré leur œuvre. John Panzer est un ami, ainsi qu’un ancien collègue, et il a écrit le protocole Salmon.

Pour pouvoir recréer la signature [de manière compatible avec Diaspora, ndt], il faut connaître la longueur de ligne utilisée dans l’implémentation Ruby de base64, et insérer des fins de ligne aux endroits adéquats. Différents algorithmes de base64 implémentés sur différentes plateformes auront des longueurs de lignes différentes.

Les signatures « magiques » de Salmon ont été précisément conçues pour éviter ce problème. En fait, c’est même leur raison d’être, et c’est ce qui les rend « magiques »… elles permettent des signatures indépendantes de la plateforme.

La réponse de Diaspora (Ilya semble avoir été le « mec du protocole » dans l’équipe) a été de réparer la plupart des violations de protocole – seulement après que je leur ai indiquées et expliqué l’importance de suivre les spécifications à la lettre.

Quand leur proposition de correctif est sortie, il est apparu évident qu’Ilya ne maîtrisait pas vraiment les espaces de noms XML. Nous avons échangé quelques courriels, et j’ai pu lui suggérer une couche de transport qui ferait ce qu’il souhaitait sans pour autant violenter les espaces de noms. Il a suivi mes suggestions.

Aussi, pour l’instant, la couche de transport de Diaspora suit complètement ma spécification, après ingénierie inverse de l’horrible bordel qu’elle était initialement. Je trouve cela plutôt amusant.

L’autre couche correspond aux « vrais » messages, aussi appelés charge utile [payload, ndt]. C’est ce sur quoi je me suis battu ces derniers mois. Au lieu d’utiliser un truc classique à base d’Atom/ActivityStreams pour échanger de l’information, chaque type de données possède son propre format avec son propre algorithme pour calculer la validité de la signature. Collectées par Ruby, ce qui fait que même les développeurs ne savent pas exactement quelles données sont signées.

Mais quand on cherche fonctionner en mode « fédéré », on a besoin de savoir quelles données sont signées pour pouvoir les répliquer.

Personne n’a jamais documenté cela, parce que je présume que personne ne le comprend vraiment.

Ironie du sort, je suis probablement la personne vivante la plus au fait du protocole utilisé par Diaspora à l’heure actuelle, puisque j’en ai conçu la couche de transport. Et que j’ai eu à étudier dans le détail chaque type de message pour comprendre ce qui était réellement signé. (Aux débuts, tout cela était signé avec l’algorithme de hachage SHA-0, qui a été déclaré obsolète vers 1992/1993.) Avec le même OID ASN.1 que l’algorithme SHA-1. J’ai passé des semaines à essayer de comprendre ce qui se passait à coups d’ingénierie inverse sur les paquets signés. Et j’ai fini par comprendre qu’en fait, ils utilisaient juste le mauvais algorithme de hachage.

J’envisage sérieusement de documenter le protocole de Diaspora sous forme d’eBook payant, et de m’en servir pour financer le développement de Friendica.

Comments are disabled for this post