Quatre erreurs de conception logiciel que Diaspora doit corriger. Vite.
Simon Tenant de la société buddycloud a écrit début Décembre un article très intéressant à propos de Diaspora. Je vous en propose ici une traduction.
Diaspora m’a toujours paru comme un projet hype et intéressant mais mon travail sur les channels de buddycloud m’a tenu occupé. Alors, quand un ami développeur m’a fait remarquer qu’il avait forké le code de Diaspora et qu’un ami investisseur m’a demandé mon avis sur le projet, j’ai enfilé mon costume fanboy-proof et j’ai plongé pour voir ce que le buzz donnait. Cela avait-il un sens d’interconnecter Diaspora avec les channels de buddycloud?
Ma première réaction a été du genre : « Il manque quelque chose ici, cela n’a pas de sens ». Tout ce tapage et cet argent et c’est tout?
J’ai donc attendu une semaine avant de commenter et inspecter le projet avec davantage d’attention. Mon sentiment au sujet de certaines de leurs décisions n’a pas changé pour autant. En fait, c’est devenu encore plus « wtf? » Peut-être auront-ils énormément de succès, mais ce n’est pas cette voie que j’emprunterai pour la conception d’un réseau sociale décentralisé.
Avertissement : Il est très facile de critiquer. Je le fais car j’ai déjà du résoudre plusieurs problèmes similaire sur les channels de buddyclouds et j’ai naturellement le sentiment qu’ils sont mieux que les Aspects de Diaspora. J’adorerais me tromper.
Voici les 4 erreurs de conception que Diaspora* devrait corriger et qui les aideraient à devenir une plateforme grand public :
1. Coder avant de concevoir (Diaspora devrait séparer le code du protocole)
La plus grosse erreur et sans doute la plus difficile à corriger a posteriori est le manque d’architecture système globale.
J’étais curieux de savoir comment ils avaient résolu le problème de fédération des serveurs. Plus précisément, comment un serveur se connecte à un autre serveur, comment chaque serveur sait qu’il parle à un serveur légitime, comment les serveurs assurent des communications sécurisées, comment les serveurs traitent les communications, etc. C’est un problème facile à résoudre rapidement mais aussi un problème très difficile à résoudre correctement. En effet, certains systèmes fédérés ne l’ont jamais bien résolu (regardez l’usurpation de relais SMTP encore de nos jours).
J’ai vraiment dû creuser pour trouver toute sorte de documentations utiles sur l’architecture (la plus utile est https://github.com/diaspora/diaspora/wiki/Security-Architecture-Proposal)
Réponse courte : Ce n’est toujours pas résolu
Réponse longue : En fait, quand vous regardez la documentation, il y a très peu de conception d’architecture et à chaque fois que j’ai posé la question on m’a répondu « Lis le code » ou « C’est toujours une question ouverte ».
WTF? Ai-je raté quelque chose? L’architecture de votre système va influencer de nombreuses autres régions du code et pourtant c’est une « question ouverte »! « Nous allons construire ce projet en Rails et battre Facebook » n’est pas une architecture. « Nous allons signer les messages avec PGP et utiliser SSL » n’est pas une architecture. Mais il semble y avoir quelques personnes avec de bons conseils sur la liste de diffusion. Diaspora devrait suivre les conseils de ce post:
Tout cela doit être planifié et défini comme une structure qui évolue de manière contrôlée. Un « hackathon » de 4 mois, ce n’est pas la bonne façon de faire. Vous avez 200k $. Offrez-en à quelqu’un qui a travaillé sur un morceau de Wave pour qu’il vous donne des conseils et que vous fassiez les choses correctement.
Vous pourriez rétorquer « mais la fédération de serveur n’est qu’une petite partie d’un réseau social ». Non, la conception de votre fédération aura une incidence sur l’adressage des utilisateurs (@nom ou nom@exemple.com), le routage des messages, la sécurité et même la conception de l’interface (est-ce conçue pour des réponses instantanées ou est-ce plus statique?). Donc, vraiment, Diaspora devraient régler ce problème en priorité.
Les concepteurs de Diaspora devraient s’éloigner de leurs consoles Rails et MongoDB hyper-cool et décrire l’architecture d’ensemble avant de traiter des fonctionnalités comme l’upload de photos. L’avantage est qu’ils créeront ainsi un écosystème de Seeds Diaspora dans de nombreuses langues. Chez buddycloud nous avons passé beaucoup de temps à fixer le protocole et l’architecture – dont le bénéfice est que des projets indépendants travaillent sur les serveurs et sur les clients.
2. Essayer de réinventer Facebook (Diaspora devrait innover sur des caractéristiques différentes, ne pas essayer de rattraper)
S’il vous plaît n’essayez pas de rattraper Facebook. Ne sous-estimez jamais les réticences des utilisateurs au changement. Facebook a dépensé beaucoup d’argent pour construire des fonctionnalités que les consommateurs apprécient et qui les enferment dedans (partage de photos). Les utilisateurs sont paresseux. Ma mère est paresseuse. Elle ne va pas quitter Facebook et installer un nouveau réseau social de sitôt.
Diaspora devrait se concentrer sur des domaines qui n’ont pas encore été résolu. Les domaines dans lesquels ils peuvent être différents et meilleurs que Facebook. Ensuite, les utilisateurs migreront pour des fonctionnalités spécifiques. Peut-être que ce sera pour la vie privée, mais dans ce cas, votre marché n’est pas la population générale (malheureusement).
Essayer d’imiter l’hébergement de photo de Facebook? Passez votre chemin. D’autres services ont résolu ceci également et certains très bien. Si l’hébergement de photos est vraiment important, faites le plus tard (après que vous ayez fait votre conception architecturale).
Peut-être se concentrer davantage sur une utilisation mobile et une localisation plus sûre (nous le faisons). Ce sont des zones de croissance que Facebook n’a pas encore bien résolu.
3. Construction d’un nouveau graphe social (Diaspora devrait accrocher les groupes d’amis déjà existant)
Rappelez vous pourquoi ma mère n’est pas sur Diaspora : Aucun de ses amis n’est sur Diaspora.
Il n’y a rien de pire que de commencer sur un nouveau réseau social et d’avoir à reconstruire une liste d’amis. Bien que cela soit faisable, c’est un grand obstacle pour les j’essaye-pas-chaque-nouveau-service-qui-débarque.
Diaspora devrait réfléchir à la façon dont ils peuvent concevoir leurs produits à travers un réseau existant d’amis. Peut-être en utilisant les réseaux sociaux existants ou les réseaux de messageries instantanées.
Une chose que nous faisons chez buddycloud, c’est que votre page personnelle est calqué sur votre liste (la liste de vos contacts). Cela donne au noob un pré-graphe de construction sociale dont certains ont déjà une configuration de channel. Bien que cela puisse ne pas sembler important, n’oubliez pas que chaque utilisateur de Gmail est également un utilisateur XMPP qui donne un énorme coup de pouce initial à quelqu’un qui essaie le client.
4. Construire un produit (Diaspora devrait concevoir un protocole, construire un outil et favoriser un ecosystème qui permet à d’autres de s’intégrer)
Diaspora essaie de se concentrer sur la construction du graph social, du serveur et de l’interface client. C’est beaucoup!
Les réseaux sociaux deviennent envahissants. Chaque produit aura bientôt, ou a déjà, sa propre version de réseau social intégré, souvent offert par une API Facebook connect. Donnez aux développeurs une alternative à l’utilisation de l’API Facebooks (peut-être même utiliser des URL similaires?)
Une autre approche que Diaspora pourrait essayer serait de ne pas tenter de maintenir un graphe social et, à la place, construire leurs logiciels à travers des produit sociaux pré-existant. Presque toutes les apps pour nouveaux sites ont le concept d’amis ou de personnes que vous suivez. Diaspora pourrait obtenir beaucoup de succès en donnant à ces auteurs le code de l’application qu’ils puissent intégrer facilement et ainsi rendre leur site « diaspora-aware ».
Diaspora devrait donner les moyens à chacun de créer sa propre version de réseau social autour de la plate-forme Diaspora. En effet, peut-être qu’ils ne devraient même pas livrer de client et laisser l’imagination des développeurs se mettre en concurrence en créant les implémentations.
Félicitation à Diaspora
Il est facile d’être critique et je mets quiconque au défi de résoudre le problème du réseau social décentralisé. Diaspora a fait un très bon travail en attirant l’attention du public sur les alternatives à Facebook. Même le tout petit buddycloud a été mentionnés grâce à eux. Merci!
Les utilisateurs ont besoin de savoir qu’il existe des alternatives. Mon souci, c’est que le tapage peut aussi se retourner contre vous quand vous n’avez pas quelque chose à livrer ou s’il n’y a pas une grande valeur-ajouter par rapport aux solutions existantes.
Je suis impatient de voir une documentation sur l’architecture pour que je puisse voir comment nous pourrons y intégrer les buddycloud channels. Mieux vaut encore sauver beaucoup de temps et construire ceci sur XMPP.
Buddycloud est une petite entreprise, proche des Alpes, en Allemagne. Ils ont conçu le projet buddycloud pour eux même et le mettent à disposition de chacun.
Vous pouvez les suivre sur Twitter, leur Blog, Flickr et Facebook
