Ma vision d’un vrai web social Part 4 : The ultimate solution : un webmail social

Il est recommandé d’avoir lu les parties une, deux et trois avant de lire cet article.

Tl;dr : Il est possible de répondre aux trois problèmes précédemment évoqués tout en gardant les fonctionnalités d’un réseau social et le tout, très simplement. Il s’agit de rajouter une interface par dessus un serveur mail. Les e-mails sont en effet décentralisés, fonctionnent très bien et permettent toutes sortes d’interactions. Couplé à Persona pour se connecter partout en gérant ses identités, et à un Gravatar amélioré pour lier son email à un profil, on a la solution ultime :p

Alors, où en sommes-nous ? J’avais proposé dans la partie 1 la possibilité de pré-installer la solution que l’on imagine dans cette série d’articles dans les boxes des particuliers, en leur fournissant l’outil comme le FAI leur fourni déjà des adresses e-mails. Cela permet à la fois de toucher les gens rapidement en leur fournissant une solution clef en main, et à la fois de sécuriser leurs données en les laissant à portée de main.

J’avais expliqué dans la partie 2 les problèmes que présentaient pour moi les réseaux sociaux actuels, qui enferment le contenu et les échanges à un unique endroit souvent clos, et ce même pour les réseaux sociaux Libres et décentralisés.

La partie 3 nous a permis de voir que les listes de contacts dans les réseaux sociaux n’étaient pas une bonne solution au problème de séparation des identités, puisque nous y publions toujours avec le même nom (qu’il soit réel ou que ce soit un pseudonyme), ce qui permettait un recoupement facile. Nous avons de plus observé que nos identités sur Internet étaient souvent reliées à une adresse mail, et que les personnes dans nos listes des réseaux sociaux correspondaient à notre liste de contact de chacune de nos adresses.

Alors, avec tout ça, qu’est-ce qu’on fait ?

Et bien, voici une solution qui semble assez simple d’après moi, et qui permet de gérer toutes ces problématiques à la fois, tout en gardant les fonctionnalités de base d’un réseau social.

La solution, d’après moi, c’est simplement un webmail amélioré. Imaginez, une interface depuis laquelle vous gérez vos différentes identités, chacune une adresse mail. Ceux qui ne s’y intéressent pas n’auraient qu’une adresse et ne verraient pas la différence avec un réseau social classique. Mais pour les autres…

Regardons d’abord dans les rouages. Vous recevez un mail dont vous êtes l’unique destinataire : c’est un message privé. Vous voulez poster un message sur votre « mur » à plein de gens : un e-mail où ils sont tous en cc. Vous souhaitez en mentionner deux dedans ? Ceux là seront en destinataire. Vous voulez joindre une image, une vidéo, des documents… ? Les e-mails acceptent n’importe quel type de pièce jointe. Vous souhaitez commenter un message posté ? Il suffit de répondre à l’e-mail initial. La réponse est vide ? C’est considéré comme un « j’aime ». Repartager ? Il suffit de transférer l’e-mail aux nouvelles personnes. Rien empêche d’ajouter en plus un petit serveur XMPP derrière, et nous avons un tchat.

Et en plus : Une couche de sécurité supplémentaire, vous voulez être sûr de qui parle ? Il est possible de signer facilement un e-mail. Vous voulez que personne n’intercepte ce que vous dîtes ? Il est tout aussi facile de le chiffrer.

Mais surtout : le smtp et l’imap sont des protocoles ultra utilisés ! Leur spécification est bien établie, tout le monde les connait, donc n’importe qui peut faire son interface par dessus ces messages, il n’y aura aucun problème. Et puis, on sait qu’ils marchent, ce qui n’est vraiment pas le cas des protocoles de réseaux sociaux actuels… Le mieux, dans tout ça, c’est donc que tout ce que je viens de vous décrire existe déjà !! Il suffit juste de faire une interface graphique comme GMail par exemple, mais qui au lieu de vous afficher les messages à la suite comme une conversation, vous affiche le premier message comme un poste, et les autres comme des commentaires. Votre boite de réception devient votre flux, et votre boite de messages envoyés devient votre profil (ou mur).


Il suffit de faire l’interface. C’est tout.
(c’est tellement simple que j’en suis scié. Franchement, un projet aussi puissant avec aussi peu de travail à réaliser ?)

Mais allons encore plus loin. Car si cela résout facilement le premier problème (il n’est pas bien dur d’avoir un serveur mail à la maison) et le troisième (il suffit que l’interface permettent de gérer plusieurs adresses mails et les contacts qui vont avec), cela ne répond pas au deuxième problème : ne pas enfermer le contenu.

Ah, c’est ce que vous croyez ? Et bien non ! Puisque sur chaque blog, forum, sur chaque site en général où l’on laisse un message, on utilise… son adresse mail. Et paf ! Nous voici à nouveau avec la possibilité de gérer facilement son identité. Couplons à ça deux choses.

La première, c’est Persona (anciennement BrowserID), une technologie by the Mozilla Foundation, qui permet de relier son navigateur à des adresses mails. En un clic, on se connecte donc sur un site, juste en choisissant l’adresse mail que l’on veut utiliser, sans avoir à rentrer de mot de passe ! Bien plus puissant qu’OpenID à mes yeux. Ici aussi, le travail est fait. Il n’y a rien de plus à développer. Par contre, il faut encore que les sites implémentent cette technologie, ce qui est loin d’être le cas pour l’instant.

La deuxième, c’est tout simplement améliorer un peu notre identité. Sur l’exemple de Gravatar, qui relie notre email à une image de profil, alors automatiquement affichée lorsqu’on commente, on pourrait relier un profil un peu plus complet, qui serait sur notre serveur. Une image, mais aussi une date de naissance, une citation… Toutes les informations que l’on peut vouloir relier à son profil ! Bien sûr, chaque adresse mail a un profil différent ! (Le principe de séparation, rappelez-vous !)

Résumons donc ce qu’il faut faire pour que ce magnifique (et véritable) réseau social soit en place : un serveur mail, couplé à un XMPP si on veut un tchat, un gravatar évolué pour gérer un profil, et si on veut peaufiner, une simple page serveur capable de répondre à une requête BrowserID (si on ne veut pas déléguer ça à Mozilla). Par dessus ça, une interface qui permet de gérer le tout.

Conclusion : dans les rouages, presque tout existe. Il suffit de coder une interface par dessus ça, et le tour est joué. Ça semble tellement simple que j’ai presque envie de m’y mettre maintenant.

Je sais pas si vous le saviez, mais le projet Diaspora*, qui capotait un peu, viens de devenir communautaire. J’ai bien envie de leur montrer tout ça, savoir ce qu’ils en pensent. Je doute qu’ils lâchent tout ce qu’ils ont fait pour complètement changer leur approche, mais, entre nous, je pense qu’ils auraient à y gagner.

Edit : Comme on y arrive toujours mieux à plusieurs, je viens d’ouvrir un pad pour réfléchir ensemble à la manière dont ce projet pourrait prendre forme. Je vous invite donc à participer là-bas si vous souhaitez approfondir l’idée.

{29} Thoughts on “Ma vision d’un vrai web social Part 4 : The ultimate solution : un webmail social

  1. J’ajoute ma modeste participation à cette vision du web social (« vrai » est trop pompeux pour ma modeste personne) que je trouve simplement très intéressante ; il est un protocole dont la place est à mon avis ici bien trop réduite : XMPP, cantonné à des prestations de tchat. Ce protocole peut, techniquement, permettre le stockage d’informations, de flux propagés …, à l’instar de Jappix (la plateforme, pas le mini), Movim ou, projet que je voudrais souligner pour les promesses qu’il tient (et qui me donnent envie de m’y consacrer quand mon emploi du temps me le permettra un peu plus) BoddyCloud. En outre, XMPP peut, selon les modules qu’on lui ajoute (donc selon ejabber, prosody, etc), gérer les flux RSS, reprendre une messagerie différée (exit le mail), … Pour le protocole, faut-il vraiment plus ? Dans mon esprit, la puissance de ce dernier liée à une approche de décentralisation telle que Persona peut donner quelque chose de réellement efficace et attrayant, mais horriblement chiant à propager quand les hébergeurs traditionnels ne proposent à peu près que du PHP et rarement un serveur XMPP.

    • Je suis d’accord avec toi, XMPP semble une solution à étudier pour les réseaux sociaux. Je laisserai Marien te répondre plus en détail, il a pas mal étudié comment il fonctionnait.

      Pour autant, l’intérêt de la solution que je propose, c’est qu’il n’y a rien à écrire au niveau du protocole. Et donc que deux personnes ayant déjà une boite mail Free et Orange par exemple, peuvent très bien se retrouver dans un « réseau social » sans avoir à créer de compte, ni quoi que ce soit.

      Et tout le monde peut participer, tous les sites, sans avoir à étudier le fonctionnement d’un protocole, comment ceci ou cela a été implémenté avec XMPP…

      Mais je reste d’accord avec toi, ce protocole est très puissant.

      (Ps : désolé de la réponse tardive, ton commentaire était perdu dans le filtre à spam..)

  2. « Une image, mais aussi une date de naissance, une citation… Toutes les informations que l’on peut vouloir relier à son profil ! Bien sûr, chaque adresse mail a un profil différent ! »
    XMPP fait ça, avec movim par exemple ou jappix. Donc fusionner une adresse mail avec XMPP, ca serai plus sympa.

  3. Hi,

    from what I understand, this sounds like an interesting approach (it kind of reminds me of Thimbl (http://thimbl.net)). But my french is so poor, that I don’t understand half of the text.

    Could you please at least provide the tl;dr in English? I would appreciate it very much.

    Thanks and greetings,

    Malte

    • I think make an English version of this article, because I want to submit it to the Diaspora developer. (We never know…)

      I have to work more on the idea first, this is only a draft.

      (In a word, the idea is to use email instead of a http protocol, because the mail is easy to install, very efficient and already decentralized. So I’d like to build an interface like webmail but social oriented.)

    • We already have something really awesome and underestimated : SMTP. Think about it. E-mails are completely decentralized. And the protocol is really old, really mature. It is easy to put security on it with S-Mime or PGP. And… everyone already has an e-mail address. And with Mozilla Persona, log in is really easy.

      So, why don’t we built something on an e-mail server ? Just an interface. Kind of webmail. Just a different way to display e-mails. Think about it. Private message ? A simple mail. Message to an aspect ? Everyone in the aspect is in « cc ». Want to mention someone on the message ? He is in « to ». Want to share images, or anything else ? In attachment. Reshare ? This is forward. Your stream is your reception folder, your profile, the send folder.

      Everything already exists. Everything works well. You can talk to everyone in the world, everyone has an email. And if he doesn’t use the social interface, he can read the e-mail correctly, he just doesn’t have a beautiful display. You can talk to EVERYONE.

      It would be easy to install, too. Because it is only an interface.

      The only problem I see is that e-mails send cannot be edited or deleted, so, this can not be implemented in the « network », but if the users understand that this is just a better way to display e-mails, they will understand that they can’t delete them after sending.

  4. L’idée est intéressante mais j’y vois pas mal de « failles » (comprendre : je ne vois pas comment ça pourrait marcher à cause de ça).

    J’ai retenu pour le moment :

    – Comment envisages-tu de poster un message à l’intention d’un groupe de personnes tout en mentionnant d’autres personnes (ou un groupe réduit des premières) ? Je me dis qu’on pourrait utiliser les copies mais ça fait un peu bidouille je trouve…

    – Comment contrôles-tu tes données ? Une fois un mail envoyé, il ne peut pas être supprimé ! Or je veux pouvoir supprimer mes posts et commentaires si bon me semble.

    – Comment publies-t-on des articles publics ? Impossible d’envoyer un email à toute la planète !

    – Ta solution génère ÉNORMÉMENT de courriels (1 pour chaque post/commentaire pour chaque destinataire) ! Je sais bien que dans la majorité des cas les emails sont légers mais si tu commences à poster de gros articles et/ou à avoir beaucoup de commentaires, tu vas rapidement remplir ton disque !

    Je déduis de mes propres propos que ce qui me chagrine principalement ici, c’est la réplication des données ! Tu souhaitais toi-même qu’un post soit à un seul endroit or, avec les emails, c’est complètement l’inverse.

    • Comment envisages-tu de poster un message à l’intention d’un groupe de personnes tout en mentionnant d’autres personnes (ou un groupe réduit des premières) ? Je me dis qu’on pourrait utiliser les copies mais ça fait un peu bidouille je trouve…

      C’est ce que j’ai dit, c’est mal formulé ? Quand il y a que des champs « Pour », c’est un message privé, quand on parle en « public » les gens sont en cc, et si on mentionne des gens dedans, ils passent en « pour »

    • Comment contrôles-tu tes données ? Une fois un mail envoyé, il ne peut pas être supprimé ! Or je veux pouvoir supprimer mes posts et commentaires si bon me semble.

      Je ne sais pas encore comment faire, c’est vrai. Ni pour l’édition d’ailleurs (qui manque beaucoup aux réseaux sociaux je trouve.) Pour autant, un simple mail pour dire que tu supprimes quelque chose, c’est techniquement tout à fait réalisable.

    • Comment publies-t-on des articles publics ? Impossible d’envoyer un email à toute la planète !

      Je rajouterai une simple case « public » qui aura pour effet de rendre ce mail accessible sur l’interface pour les personnes non logguées. Pour autant, je suis d’accord, il faut y réfléchir.

    • Ta solution génère ÉNORMÉMENT de courriels (1 pour chaque post/commentaire pour chaque destinataire) ! Je sais bien que dans la majorité des cas les emails sont légers mais si tu commences à poster de gros articles et/ou à avoir beaucoup de commentaires, tu vas rapidement remplir ton disque !

      C’est déjà le cas dans toutes les boites mails actuelles. Un mail, c’est très léger. Niveau charge réseau, ce n’est vraiment pas un problème à l’heure où les gens regardent youtube en 1080p. Et de toute manière, quand t’as un message à faire passer, il faut le faire, que ce soit par mail ou par http.

      Niveau stockage, effectivement, ça fait beaucoup de chose, mais je ne pense pas que ce soit plus lourd que ce qui se fait actuellement dans les réseaux sociaux.

      Pour autant, on est d’accord, le but était d’aller chercher l’information sur le serveur de l’autre, pas de la dupliquer chez soit, et tel qu’il est proposé, le système à ce problème..

  5. Salut, j’étais super emballé mais c’est vrai que les points soulevés par taratatach sont assez refroidissant, enfin disons qu’ils font réfléchir…

    Pour supprimer définitivement un message, il faudrait pouvoir accéder à l’endroit où il est stocké, donc il faut tout stocker à un même endroit, donc on revient sur un système centralisé… (on ne va quand même pas aller supprimer les mails sur les machines de nos contacts Oo’)
    Du coup on se retrouve avec une duplication des données à la freenet, une fois un freesite mis en ligne (un mail envoyé), plus personne ne peut le supprimer (ou en tout cas, il faut que tout le monde le fasse pour que ce soit efficace), ici c’est un peu la même chose avec les mails, ça à ses avantages mais aussi un certain nombre d’inconvénients…
    Par contre je n’ai pas compris l’idée pour rendre un message public 🙁

    Le problème du poids est à réévaluer je pense, en admettant que les quantités de données transitant sont équivalentes à celles des réseaux actuels, c’est une taille gigantesque. Mais si on considère que l’on a à « charger » que les données de ses contacts, ça baisse quand même drastiquement la charge ! Les serveurs de facebook doivent être considérables, mais en même temps, mes 50 amis facebook au complet ne combleront sûrement pas mon disque dur… Surtout si on peut limiter l’historique de mails aux « 7 derniers jours » ou bien aux « 200 derniers mail » voire à « 5go de données »…

    Dites moi si je m’emballe 🙂

    • donc il faut tout stocker à un même endroit, donc on revient sur un système centralisé…

      Ce n’est pas parce qu’il faut tout stocker au même endroit un contact que le réseau est centralisé, bien au contraire.

    • Cette duplication est un problème. Mais le vrai problème, c’est que je ne me suis pas exprimé clairement sur la manière dont je voyais la chose.

      Il faut imaginer que la boite de réception est le flux (stream) et la boite des messages envoyés le profil (ou mur).

      Donc les messages que l’on écrit sont affichés sur notre profil (notre boite de messages envoyés ne doit pas être vidé), et s’affiche dans le flux des destinataires (leur boite de réception).

      Mais il est vraiment rare de remonter de plus de 250 messages dans son flux. On peut donc sans hésiter dire que l’on supprime les messages à partir du 251ème. Il est vrai que si on veut remonter plus, on se retrouve avec un réel problème, car on ne peut pas envoyer une requête spéciale aux gens demandant de nous renvoyer leur message (même s’ils l’ont) car on ne peut pas savoir qui nous avait écrit…

      Pour moi, cette limite des 250 messages (nombres au hasard) doit donc être réglable par l’utilisateur. Et l’administrateur fixera un quota maximum, comme pour les boites mails.

      • Mais à partir du moment où le main est envoyé, il est dupliqué sur les machines de nos contacts, donc comment éviter cela ? Je suis d’accord sur la limite de messages (cela est un plus niveau vie privée également), mais cela ne règle pas le problème de la duplication, j’ai du mal à te suivre…

      • De plus, il me semble qu’une fois les 250 messages atteints, il n’est même pas envisageable de remonter plus loin, en fait si je choisit de garder mes 10 derniers envois sur mon ordi, ok je ne verrais que les 10 derniers, mais si mes contacts gardent 500 messages de leur flux, il auront un sacré historique de mes envois, donc je ne maitriserais aucunement mes données… enfin il me semble ?

        • Oui oui, c’est totalement le problème soulevé ici : Une fois qu’un mail est envoyé, il est envoyé, on ne peut rien y faire, ni l’éditer ni le supprimer. On peut juste en renvoyer un autre disant « ce n’est pas ce que je voulais dire » et demandant la suppression du premier, mais là, ça veut dire qu’on rajoute une couche sur le protocole de mail initial.

          • Salut, j’ai pas eu le temps d’éclaircir mes propos sur les autres messages, mais un stockage sur un système de fichier type ZFS (btrfs pour ubuntu) gérant la déduplication pourrait être intéressant pour cette boite de réception, non?
            D’autant que la partition surveillée par script, agrandie à chaud, et que les différentes versions et qu’une correction d’un mail passé ne serait alors plus qu’une nouvelle version du fichier (le zfs permet l’accès à toutes les versions intermédiaires d’un fichier.)

            A creuser peut être? (après au travers d’un système mail je vois pas ce que ça peut donner, mais la dédup est déjà un avantage certain!)

            Bon WE

          • C’est une bonne idée de déléguer ça au système de fichier, mais ça implique que les boites mails soient sur le même serveur, donc on perd la décentralisation.. (sauf si tu vois le moyen de faire ça entre deux serveurs différents, et là, on a le jackpot, mais sinon…)

  6. Salut!

    J’ai bien aimé ce que j’ai lu ici 🙂

    Concernant la question comment contrôles-tu tes données ?
    Je me disais justement que ce qu’il manquait était une notion proche du blog sur le même concept que la boite mail auto-hébergé que tu développes. Ainsi une personne peut produire des documents de taille plus ou moins raisonnable pour un mail et ne publier que son lien vers le blog.
    Il y a forcément un risque de saturation en cas de trop grand nbre de consultations, peut être qu’un système de duplication vers des serveurs externes toujours décentralisés et maintenus par les dons de la communauté serait faisable. Le tout peut être géré automatiquement, si le nbre de connexion dépassent la moitié des capacités (par exemple) alors on transfert sur le serveur commun l’article… Ou encore une personne qui ‘aime’ ou ‘repartage’ devient à son tour serveur, mais alors comment gérer le flux?
    Le Web n’est pas mon domaine de compétences en info, donc je dis probablement des bêtises, mais si ça peut donner des idées :p

    En attendant, merci pour ces articles 🙂

    • La taille maximum d’un e-mail dépend du fournisseur mais varie entre 5mo et 25mo. Autrement dit, si l’article en question ne contient que du texte, je pense que ton blogueur peut parler un moment 🙂

      S’il veut mettre des images, le mieux est de mettre de lien externe, comme ça il ne l’alourdit pas !

      Je ne comprends pas par contre l’intérêt de publier sur une plateforme séparée, je n’ai pas tout saisi…

      • Salut!

        ça fait un bail, j’avais un peu oublier le sujet ^^’

        Bon, je me récapitule :
        1. Héberger ses données sur un espace dédié toujours en ligne (Box, NAS, serveur).
        2. Une gestion de permissions à la Linux rwx-rwx-rwx en lien direct à la gestion des contacts (on retrouve ainsi la notion public/groupe/contact).
        3. Un système de fichier genre BTRFS ou ZFS supportant d’être étendu à chaud. Nécessite la possibilité d’étendre vers le disque d’un serveur distant au travers du réseau. (ça je ne sais pas si c’est possible)
        4. Une belle couche applicative ou interface web pour une présentation configurable des contenu.

        Ainsi lorsque j’ajoute un contact, je lui donne des accès sur les fichiers que je définis. Pour le repartager, il doit donc récupéré le fichier sur son propre serveur pour le mettre à disposition de ces contacts.

        Si je poste un statut facebookien du genre « cette fraise était bonne » au niveau du serveur de fichier cela reviendrait a créer un fichier texte et en diffuser le lien à mes contacts ou groupe concerné.
        La consultation de mon « profil » reviendrait à lire à distance le contenu des différents liens pour les utilisateurs ayant les droits nécessaires.
        L’idée est qu’en arrière plan les différents contenu d’un fil actualité provienne des serveurs respectifs de chaque contact. Pour fonctionner les serveurs de fichiers de mes contacts devraient idéalement se « clusteriser » à la connexion au réseau (ou à l’application qui gère le réseau social) en conservant les droits définis par le propriétaire du serveur.

        Comme précédemment je pense être un peu juste techniquement sur ce que j’avance, cela peut être fantaisiste techniquement parlant! N’hésitez pas à me demander des précisions si mes propos manquent de clarté!

          • Salut!

            Oui c’est ça, la base de donnée ne serait qu’un annuaire de contact. Les droits et partages de contenu seraient gérés depuis les droits du système de fichier.

            C’est standard et permet un niveau de sécurité important. En base de donnée on est obligé de refaire une couche sécu du côté de la base pour protéger les données hébergés. La, qq’un pourrait récupérer tout l’annuaire de contacts ‘central’ que cela ne l’aiderait pas à accéder au contenu (sauf à se faire passer pour un contact réel, ce qui relève de la vigilance de l’utilisateur).

  7. La plateforme publique avait pour but de permettre une redondance pour un contenu public ‘lourd’ afin d’éviter de saturer la connexion hôte

    S’il veut mettre des images, le mieux est de mettre de lien externe, comme ça il ne l’alourdit pas !

    Cette phrase m’a fait penser à autres choses :
    C’est exactement cela que je pense qu’il faut éviter. Un des gros problèmes des réseaux type FB c’est qu’avec la technologie de reconnaissance faciale qu’ils développent actuellement le « tag » devient quasiment obsolète, une belle photo de vacances peut en dire plus qu’une longue biographie…
    Donc le stockage externe d’une image me parait moyen puisqu’il faut alors refaire tout le travail d’épluchage des conditions utilisateurs qui, dès qu’on centralise un peu les données peuvent devenir hautement mutagènes (voir l’évolution de celle de FB….)

    Ici la question n’est pas de diffuser une information public, mais bien de garder une information privée dans la sphère privée.

    Partant de là il est tout de même possible que je partage mes vidéos de mariage ‘de cérémonie’ avec la famille, celles de ‘fin de soirée’ avec les amis. Comment autrement qu’en gardant la main dessus pour être sur que seuls les personnes « habilités » y ai accès?
    L’idée était globalement de dupliquer le document sur un ou plusieurs serveurs du groupe habilité et de rediriger en fonction de l’affluence afin d’éviter une saturation de la connexion hote tout en permettant sa distribution.

    Le propriétaire peut alors choisir de permettre aux membres du groupe de repartager le document en dehors du groupe habilité.

    Je suis pas sur d’être clair encore, il va peut être falloir que je prenne le temps de digérer tout ça pour le reformuler proprement 😉 , d’ici ce soir ou demain.

    • Lien externe ne signifie pas service externe 🙂
      On peut très bien dire que quand quelqu’un poste un message avec une image, au lieu de joindre l’image à l’email envoyé pour ce message, l’image soit hébergée sur le serveur où il y a les mails de l’expéditeur, et dans l’e-mail envoyé, il n’y a plus qu’un lien vers cette image. Cela évite de surcharger tous les serveurs en dupliquant l’image autant de fois qu’il y a de destinataire, et le contrôle sur l’image est gardée (si on ne veut plus la partager, on peut la supprimer facilement puisqu’elle est sur notre serveur, alors qu’on perd le contrôle avec la pièce jointe.)

  8. Pour la publication publique il me semble qu’on se heurte à un problème de taille :
    imaginez que je publie un super post de la mort, il est en mode public. 2000 personnes ont leur mot à dire (sur facebook par exemple c’est très courant), je vais recevoir 2000 mails dans ma boite ? Et chaque commentateur également ? On va vite saturer et son espace et son serveur !
    Alors certes, dans les 2 voires 3 premières années il est très peu probable de voire ce genre de problèmes, mais pensons-y…
    Une idée de solution ?

    • L’email n’est pas un problème particulier dans le cas que tu décris ici. En effet, sur Diaspora, si 2000 personnes commentent ton message, tu vas aussi devoir stocker les 2000 commentaires dans ton serveur. La forme de stockage de Diaspora est peut-être moins lourde que celle d’un e-mail (à voir ?) mais au final, c’est toujours une ligne de plus dans la base de donnée sur ton serveur. Donc en effet, en cas de fort trafic, il faut un serveur costaud. Facebook s’en sort parce qu’ils ont des centaines de serveurs, mais eux aussi sont obligés de stocker le contenu…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>