Journal Mastodon, le réseau social qui monte ?

Posté par (page perso) . Licence CC by-sa
34
6
avr.
2017

Chers journaleux,

Connaissez-vous Mastodon.social ?

Mastodon is a free, open-source social network. A decentralized alternative to commercial platforms, it avoids the risks of a single company monopolizing your communication. Pick a server that you trust — whichever you choose, you can interact with everyone else. Anyone can run their own Mastodon instance and participate in the social network seamlessly.

Titre de l'image

Qu'est ce que ça vaut ?

Je n'ai pas encore pu consacré beaucoup de temps à étudier cela moi-même. Mais déjà, il y a de nombreux article dans le « flux principale » (“mainstream”) :

  • Le Monde.fr : Le réseau social Mastodon, un « Twitter plus proche de l’esprit originel »par ici ;
  • L'avenir.net : À la découverte de Mastodon, le clone décentralisé de Twitterpar ici

Personnellement, formaté par les hackers des années 80 et 90, je me méfie des réseaux de communication centralisés et obscures ; et j'ai même littéralement peur du pouvoir et de l'emprise que représentent Facebook et Twitter. Alors, Mastodon, décentralisé ? serait-ce enfin la réponse d'authentiques hackers, réellement satisfaisante d'un point de vue éthique ?

Bref, je propose de centraliser ici toutes sortes d'information à propos de ce Mastodon, des avis, expériences, opinions, alternatives ? etc. :)

  • # Ça ne scalera pas

    Posté par (page perso) . Évalué à 10 (+18/-5).

    Alors, Mastodon, décentralisé ? serait-ce enfin la réponse d'authentiques hackers, réellement satisfaisante d'un point de vue éthique ?

    D'un point de vue éthique, probablement.

    D'un point de vue technique, j'ai des doutes. L'instance principale croule déjà sous le nombre d'utilisateurs (pourtant pas encore super nombreux, une gouttelette de vapeur par rapport à celui de Twitter).

    Et là, on pense de suite : 1) faudrait avoir plus de serveurs pour cette instance, 2) faudrait multiplier le nombre d'instances.

    Sauf que non. ça ne va pas être vraiment possible.

    1) qui dit plus de serveurs pour une même instance, dit plus de boulots, plus de maintenance, plus de coûts pour la location des VM/machines bare-metal/ce que vous voulez, plus de coût pour la bande passante etc.. Et je ne parle pas des moyens humains pour faire la modération, dont il faut forcément augmenter le nombre si il y a de plus en plus d'utilisateurs.

    D'où vont venir les moyens humains, et surtout financier, pour encaisser le nombre grandissant d'utilisateurs ?

    On pourrait rendre payant l'utilisation, mais alors c'est mort, face à la gratuité, les performances et la stabilité de Twitter.

    2) la multiplication du nombre d'instances, propre à l'aspect décentralisé de la chose, pose plusieurs problèmes. Déjà, plus d'instances nécessite de consommer plus de bande passante et processeur pour la synchronisation entre instances. Donc ce problème rejoint le problème 1).

    Ensuite, cela pose le problème des identités évoqués dans un article dont j'ai perdu l'URL : c'est bien beau d'avoir sa propre instance ou s'abonner sur une instance particulière, mais le jour où l'instance ferme ou que l'on veuille "déménager" vers une autre instance, actuellement on perd tous ses followers/following et autres infos de compte. On repart de zéro, parce que le "login" est lié au nom de l'instance. Probablement que ça pourrait être résolu avec des fonctions d'export/import, ou en changeant la manière dont est forgé le login, mais pas sûr…

    Bref, Mastodon, ça peut fonctionner, mais ça restera confidentiel parce que ça ne scalera pas. Ça restera un truc de geek quoi. Twitter n'a pas de quoi s'inquiéter.

    • [^] # Re: Ça ne scalera pas

      Posté par . Évalué à 5 (+4/-0). Dernière modification le 06/04/17 à 13:11.

      D'un point de vue technique, j'ai des doutes. L'instance principale croule déjà sous le nombre d'utilisateurs (pourtant pas encore super nombreux, une gouttelette de vapeur par rapport à celui de Twitter).

      Oui mais l'intérêt c'est pas justement que tout le monde n'aille pas sur l'instance principale ?

      2) la multiplication du nombre d'instances, propre à l'aspect décentralisé de la chose, pose plusieurs problèmes. Déjà, plus d'instances nécessite de consommer plus de bande passante et processeur pour la synchronisation entre instances. Donc ce problème rejoint le problème 1).

      Je n'ai pas regardé les détails techniques mais je penses que c'est un truc qui fonctionne plus à la façon de l'email ou XMPP, donc des serveurs qui causent entre eux au besoin.

      • [^] # Re: Ça ne scalera pas

        Posté par (page perso) . Évalué à 4 (+2/-0).

        Oui mais l'intérêt c'est pas justement que tout le monde n'aille pas sur l'instance principale ?

        Oui mais cela pose les problèmes que j'explique en 2)

        donc des serveurs qui causent entre eux au besoin.

        Oui, mais justement, plus il y a de serveurs, plus il y a de "causeries" donc, nécessitent plus de matos, de bande passante etc…

        On pourrait comparer ça aux serveurs mails, sauf que dans un réseau social il y a plus d'échange à mon avis, entre les "likes", les notifications, les retweets etc… Faut supporter la charge.

        Ou alors, peut-être qu'en ayant le plus de monde possible qui ait sa propre instance, avec donc un nombre limité de user par instance, ça pourrait fonctionner.

    • [^] # Re: Ça ne scalera pas

      Posté par (page perso) . Évalué à 5 (+5/-0). Dernière modification le 06/04/17 à 13:13.

      Pour préciser ta réponse,

      c'est bien beau d'avoir sa propre instance ou s'abonner sur une instance particulière, mais le jour où l'instance ferme ou que l'on veuille "déménager" vers une autre instance, actuellement on perd tous ses followers/following et autres infos de compte.

      C'est en partie faux : on peut exporter un compte, on perdra ses "followers". Les following seront portés.

      Pour les problèmes que tu relèves sur la multiplication des instances, de bande passante, de synchronisation, de scalabilité, je pense que cela peut être comparable aux mails. Rien n'empêche un google-like de monter une énorme instance pour monnayer tes données, comme ils l'ont fait pour les mails.

      Je ne sais pas en quelle mesure ce réseau social va prendre, mais ça fait longtemps qu'un réseau social "éthique" n'a pas un démarrage aussi fulgurant, et c'est déjà pas mal ! ;)

      • [^] # Re: Ça ne scalera pas

        Posté par . Évalué à 4 (+4/-1).

        : on peut exporter un compte, on perdra ses "followers". Les following seront portés.

        les abonnés ne sont pas prévenu ? ca veut dire quoi les following seront portés ?

        ca ressemble quand même à un fail. ce qui fait la valeur d'un compte, c'est justement son audience.

        • [^] # Re: Ça ne scalera pas

          Posté par . Évalué à 3 (+2/-0).

          ca ressemble quand même à un fail. ce qui fait la valeur d'un compte, c'est justement son audience.

          Un compte c'est une paire (user,instance) d'après ce que j'ai compris, du coup, changeant d'instance, c'est plus le même compte.

          Après, je suppose que ce serait une fonctionnalité chouette et implémentable de notifier ses follower d'un changement de quoi que ce soit, et qu'il puissent valider en un clic.

        • [^] # Re: Ça ne scalera pas

          Posté par . Évalué à 7 (+4/-0).

          ca veut dire quoi les following seront portés ?

          Tu continuera à suivre les comptes qui t'intéressent, mais tu ne sera plus suivi.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Ça ne scalera pas

            Posté par (page perso) . Évalué à -3 (+7/-12). Dernière modification le 07/04/17 à 08:17.

            OK. Note : quand je change de login sur Twitter, je garde mes followers, les mentions sont redirigées etc…
            Donc fail, c'est plié si une des choses les plus important n'est pas géré.

            Un jour, les geeks comprendront que ce qui n'est pas important pour eux peut être important pour les utilisateurs (et donc ce qui fait la forcer des mastodontes centralisés) surtout pour du décentralisé qui fait que les serveurs meurent plus facilement (imaginons-nous que si tu éteins un serveur de mail ton nom de domaine et donc ton adresse email meurt avec?).

            • [^] # Re: Ça ne scalera pas

              Posté par (page perso) . Évalué à 3 (+4/-2). Dernière modification le 07/04/17 à 13:58.

              Déjà, on parle de changer de serveur, pas de login.

              Quand tu changes de boite mail, tu l'indiques à tes contacts, et réciproquement. Tu fais peut être des réponses automatiques.
              Ben chez mastodon, c'est pareil.

              Si ton hébergeur éteint ton serveur de mail, tu perdras tes mails. C'est la même confiance que tu dois avoir en ton serveur mastodon.

              • [^] # Re: Ça ne scalera pas

                Posté par (page perso) . Évalué à 1 (+5/-6). Dernière modification le 07/04/17 à 14:19.

                Déjà, on parle de changer de serveur, pas de login.

                J'ai changé plusieurs fois d'hébergeur mail, jamais perdu de mails, et personne à contacter car je n'ai pas changé d'adresse mail (le nom de domaine m'appartenant).
                est-ce que je peux faire la même chose avec mastodon de manière pas trop compliquée, et surtout sans rien perdre d'important comme les gens qui me suivent? Pour les mails, les hébergeurs "biens" (il y en a pas trop car en fait moins de gens utilisent les mails, certes) font "changez vos DNS, puis entrez serveur/login/pass précédents, on fait le transfert de tout et vous pourrez résilier", j'attends la même chose du décentralisé sinon je reste sur le gros centralisé.

                Disons que ta remarque "mais tu ne sera plus suivi." semblait sous-entendre que ce n'était pas bien grave, c'est ce qui m'a fait tiquer, vaut mieux ne pas le dire comme ça et dire comment ça va se passer en cas de déménagement, car ça laisse penser "on s'en fout" assez négatif.

              • [^] # Re: Ça ne scalera pas

                Posté par . Évalué à 1 (+0/-0).

                On peut changer de serveur sans changer de login ? J'en doute fortement (mais j'ai peut-être tort).

      • [^] # Re: Ça ne scalera pas

        Posté par . Évalué à 2 (+1/-0).

        C'est en partie faux : on peut exporter un compte, on perdra ses "followers". Les following seront portés.

        https://github.com/tootsuite/mastodon/issues/177

    • [^] # Re: Ça ne scalera pas

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Ma réflexion a légèrement muri, suite à la lecture de l'article de Numerama et d'autres commentaires sur ce journal.

      Cela ne pourra fonctionner que si il y a un maximum d'instance fédérée, c'est à dire avec une répartition la plus grand possible des utilisateurs.

      Je me demande en fait si je ne vais pas monter ma propre instance sur mon VPS, mais n'y avoir que mon compte et éventuellement ceux de proches (pas d'inscriptions publique donc, mais reste tout de même fédérés aux autres mastodon).

      Ce qui donne :

      • liberté de parole, de ligne éditoriale etc : je dis ce que je veux, mes messages ne sont pas censurés, en tout cas pas de mon instance
      • peu d'inscrits, donc je limite les besoins en terme de puissance et bande passante.

      Reste que, bien sûr, ce modèle a ses limites : seul les geeks pourront avoir leurs propres instances (ou les structures associatives ou commerciales). L'utilisateur lambda n'a pour le moment que la possibilité de s'inscrire sur une instance "publique". On verra à l'avenir si cette limite volera en éclat.

    • [^] # Re: Ça ne scalera pas

      Posté par . Évalué à 4 (+3/-0). Dernière modification le 06/04/17 à 15:38.

      1) qui dit plus de serveurs pour une même instance, dit plus de boulots, plus de maintenance, plus de coûts pour la location des VM/machines bare-metal/ce que vous voulez, plus de coût pour la bande passante etc..

      Ni plus ni moins que n'importe quel autre service… Des centaines de milliers d'institutions font tourner leur petite instance de mail, leur petite instance de serveur http, leur petite instance de voip ou n'importe quoi d'autre…

      Et je ne parle pas des moyens humains pour faire la modération, dont il faut forcément augmenter le nombre si il y a de plus en plus d'utilisateurs.

      On parle d'une applications distribuée, de petites/moyenne instances. Les ressources humaines nécessaire à l'entretient du réseau grandit mécaniquement en même temps que le réseau.

      2) la multiplication du nombre d'instances, propre à l'aspect décentralisé de la chose, pose plusieurs problèmes.

      Voyons ça…

      Déjà, plus d'instances nécessite de consommer plus de bande passante

      Non, au contraire. Plus d'instance autorise à profiter des effets de cache, de la localité, etc. ça consomme MOINS de bande passante. D'ailleurs, tous les gros services web font ça, ils ont des data center partout dans le monde, et les utilisateurs sont rattachés aux instances proches d'eux.

      et processeur pour la synchronisation entre instances.

      Oui, ya des coûts de synchronisation, mais ils sont inévitables… C'est vrai pour toutes toutes application distribuée
      Mais, c'est pas un problème, le temps CPU c'est pas cher, on parle d'une charge très faible.

      Bref… Désolé de le dire un peu sèchement mais… N'importe quoi… pour le point 1 comme pour le 2.

      ajout : nos posts se sont croisés, (celui daté de 15h22), je raye

      ajout ajout : Oui… Quand on parle de synchronisation, c'est de la synchronisation paresseuse et opportuniste, c'est ça qui permet de gagner.

      • [^] # Re: Ça ne scalera pas

        Posté par . Évalué à 6 (+3/-0).

        Non, au contraire. Plus d'instance autorise à profiter des effets de cache, de la localité, etc. ça consomme MOINS de bande passante. D'ailleurs, tous les gros services web font ça, ils ont des data center partout dans le monde, et les utilisateurs sont rattachés aux instances proches d'eux.

        Ce qui n'a rien à voir. Google.com c'est un énorme cluster qui est distribué sur la planète. D'un point de vu architecture ça n'a rien à voir avec un réseau pair à pair.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Ça ne scalera pas

          Posté par . Évalué à 2 (+1/-0).

          Ce qui n'a rien à voir. Google.com c'est un énorme cluster qui est distribué sur la planète. D'un point de vu architecture ça n'a rien à voir avec un réseau pair à pair.

          C'est quoi la différence entre un cluster et un réseau pair à pair ? (à part que les utilisateurs finaux ne sont pas dans le cluster)

          • [^] # Re: Ça ne scalera pas

            Posté par . Évalué à 5 (+2/-0).

            Quand on parle de cluster, on pense généralement à une ensemble de machines qui sont derrière un répartiteur de charge (un reverse HTTP, DNS ou autre,…). Les machines d'un cluster se synchronisent de manière plus ou moins efficace, mais elles le font.

            Un réseau paire chaque nœud est un point d'entrée dans le système et il n'y a pas de synchronisation. Ce n'est pas possible parce qu'on a beaucoup plus de machines (mais bien moins puissantes - en FLOPS comme en bande passante -) et que le réseau est dynamique. Tu va avoir des nœuds qui vont apparaître et disparaître avant d'avoir eu le temps de faire la moindre synchronisation.

            Dans les architectures tu vois bien la différence sur l'utilisation d'un logiciel de découverte de service, comme zookeeper. Les cluster élastiques (dont on ajoute ou supprime des nœuds en fonction de la charge) utilisent ce genre de logiciels qui font une topologie du réseau là où en réseau paire à paire, il n'y a pas de garant de la topologie du réseau (certain n'ont pas de topologie pour d'autres c'est le fonctionnement même du réseau qui lui donne une architecture - comme pour la DHT). Les clusters offrent des garanties bien plus fortes (avec des techniques comme les horloges de Lamport).

            Bien sûr c'est la dichotomie que je prends, certains en auront une un peu différentes ce qui rangeras certains systèmes un peu limite paire à paire ou non.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Ça ne scalera pas

      Posté par . Évalué à 5 (+2/-0).

      2) la multiplication du nombre d'instances, propre à l'aspect décentralisé de la chose, pose plusieurs problèmes. Déjà, plus d'instances nécessite de consommer plus de bande passante et processeur pour la synchronisation entre instances. Donc ce problème rejoint le problème 1).

      J'ose espérer qu'ils n'ont pas envisagé de faire de la synchronisation. Le coté décentralisé, c'est aussi que l'information (ou l'état) n'est pas centralisée. Donc tu ne communique qu'avec ceux qui te suivent et ceux que tu suit.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Ça ne scalera pas

        Posté par (page perso) . Évalué à 2 (+0/-0).

        oui mais si il y a peu d'instances et beaucoup d'utilisateurs sur chacune d'elles, les instances sont constamment en train de s'envoyer des messages.

        • [^] # Re: Ça ne scalera pas

          Posté par . Évalué à 1 (+0/-0).

          oui mais si il y a peu d'instances et beaucoup d'utilisateurs sur chacune d'elles, les instances sont constamment en train de s'envoyer des messages.

          Ce que tu perd en coût de communication entre les instances, tu le gagne en coût de communication entre les clients et leur instance. Ça équilibre le réseau, ça augmente sa résilience… C'est tout l’intérêt du peer to peer.

          Regarde la carte des data center de google par exemple :

          carte datacenter google
          http://royal.pingdom.com/2008/04/11/map-of-all-google-data-center-locations/

          On devine qu'il y a énormément de trafique entre les data center états-uniens et européens par exemple, mais au total, ça fait moins de trafique que si s'il n'y avait qu'un data center aux États-unis. Typiquement, grâce à ça, chaque donnée peut ne traverser l'atlantique qu'une seule fois. Les données sont stockées au plus prés de ceux qui veulent y accéder.

        • [^] # Re: Ça ne scalera pas

          Posté par . Évalué à 3 (+0/-0).

          oui mais si il y a peu d'instances

          C'est donc l'inverse de ce que tu disais.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Ça ne scalera pas

      Posté par . Évalué à 0 (+0/-0).

      On pourrait rendre payant l'utilisation, mais alors c'est mort, face à la gratuité, les performances et la stabilité de Twitter.

      Il y a pas qu'une seule manière de se faire payer. C'est pas Reddit qui fonctionne par don? (pas sûr de moi mais je traîne pas trop dessus).

      • [^] # Re: Ça ne scalera pas

        Posté par . Évalué à 3 (+1/-0).

        Il y a de la publicité sur Reddit, ainsi que des comptes "Gold" payants avec des fonctionnalités supplémentaires

    • [^] # Re: Ça ne scalera pas -- Qu'est-ce qui scale?

      Posté par . Évalué à 7 (+4/-0).

      Je ne suis pas du tout expert, alors je ne vais pas argumenter sur la pertinence de tes propos, mais ça me permet d'enchaîner sur une question qui me semble fondamentale quand on envisage une alternative décentralisée aux réseaux sociaux actuels:

      Quelles sont les solutions aujourd'hui qui pourraient tenir 1 milliard d'utilisateurs répartis sur plusieurs serveurs? On imagine qu'il faut permettre la cohabitation de géants qui gèrent des centaines de millions d'utilisateurs avec des serveurs perso.

      Pour illustrer mon propos, je pense aux choses suivantes:

      -La fédération sur Diaspora, c'est franchement pas ça. On ne peut pas faire de recherche ce qui se passe sur les autres serveurs. Ça encourage fortement la centralisation vers le plus gros et le plus actif.

      -Matrix semble très bon pour les salons robustes répartis sur plusieurs serveurs, au prix de fortes ressources: je lis qu'on doit déjà prévoir 2Go de RAM de cache pour rejoindre les plus gros salons. Qu'est-ce que ça serait si un utilisateur sur son VPS rejoignait le salon fan-club de Lady Gaga??

      -XMPP: Il reste beaucoup de boulot autour de la partie réseau social. A-t-on assez de recul pour dire que ça tiendrait?

      Faut voir qu'on n'est plus à l'époque du mail: les réseaux sociaux, c'est plusieurs ordres de grandeur au-dessus des emails en termes de traffic. C'est quand la dernière fois que vous avez envoyé une vidéo ou même un "simple" album photo par mail?

    • [^] # Re: Ça ne scalera pas

      Posté par . Évalué à 5 (+3/-0).

      Ensuite, cela pose le problème des identités évoqués dans un article dont j'ai perdu l'URL : c'est bien beau d'avoir sa propre instance ou s'abonner sur une instance particulière, mais le jour où l'instance ferme ou que l'on veuille "déménager" vers une autre instance, actuellement on perd tous ses followers/following et autres infos de compte. On repart de zéro, parce que le "login" est lié au nom de l'instance.

      Oui, c'est ni plus ni moins que les problèmes liés au mail:
      un compte @ un domaine

      si le domaine ferme, tu perds ton compte et ton identité. Par contre, tu gardes tes followings (ton carnet d'adresse). On peut effectivement rêver que tout le monde soit sur le même domaine (twitter.com), mais on a d'autres problèmes (centralisation, censure, etc..)

      Le monde est un éternel recommencement, mais là, on réinvente le mail avec une partie "publique" du concept. Ce que j'écris, je le poste à tout le monde (public), et les abonnées le reçoivent : C'est exactement comme une mailing list en fait, quel concept génial \o/

      Donc bon, la décentralisation n'est pas un problème :)

      • [^] # Re: Ça ne scalera pas

        Posté par . Évalué à 5 (+2/-0).

        Tu crois vraiment que Twitter et Facebook ne sont rien de plus que des mailing-lists?

        Tu es en train de nous refaire le coup du "si une fonctionnalité vous manque, vous n'en avez pas besoin parce que moi je n'en ai pas besoin!".

        • [^] # Re: Ça ne scalera pas

          Posté par . Évalué à 3 (+1/-0).

          À noter que les gens qui aident au développement de Mastodon se posent la question de la migration transparente — voir ici. Ils séparent le problème en deux :

          1. Comment migrer de façon transparente un compte d'une instance à l'autre ? Il y a une partie facile (migrer ceux que « je » suis ou ai bloqués), et une partie plus complexe (faire en sorte que ceux qui me suivent n'aient rien à faire).
          2. Comment migrer les données liées (les messages) émis depuis une instance donnée. C'est plus compliqué, et à mon avis, le seul moyen de le faire est de permettre l'export de ces données. Cependant, dans le fil que j'ai lié, quelqu'un donnait le cas d'un hypothétique robot spammeur qui en profiterait pour flooder plusieurs serveurs grâce à cela pour aller plus vite…

          Bref. La migration de l'identité est quelque chose de faisable (mais apparemment le protocole initial, OSocial) pourrait avoir besoin d'une extension pour permettre une telle chose. La migration des messages, c'est plus dur, sauf si c'est « ton » instance.

          • [^] # Re: Ça ne scalera pas

            Posté par (page perso) . Évalué à 3 (+1/-0).

            À noter que les gens qui aident au développement de Mastodon se posent la question de la migration transparente

            Ils pourraient jeter un coup d’oeil à ce que fait Friendica, qui permet ça depuis ses débuts…

      • [^] # Re: Ça ne scalera pas

        Posté par (page perso) . Évalué à 3 (+4/-3). Dernière modification le 07/04/17 à 14:29.

        si le domaine ferme, tu perds ton compte et ton identité.

        Que se passe-t-il si le domaine ne ferme pas (en tous cas tout de suite)? Le monde a évolué, les besoins plus forts.
        Perso j'attendrais du décentralisé et avec des followers, que l'instance qui gère le nom qui va mourir informe les followers de la nouvelle adresse, je ne suis plus en 1990.

        Alors certes pas forcément dans les premiers mois d'un projet, mais si la problématique n'est pas prise en compte, si c'est un problème de décentralisation (car le centralisé le gère quand je change de nom).

    • [^] # Re: Ça ne scalera pas

      Posté par (page perso) . Évalué à 1 (+0/-0). Dernière modification le 08/04/17 à 02:52.

      Ensuite, cela pose le problème des identités évoqués dans un article dont j'ai perdu l'URL : c'est bien beau d'avoir sa propre instance ou s'abonner sur une instance particulière, mais le jour où l'instance ferme ou que l'on veuille "déménager" vers une autre instance, actuellement on perd tous ses followers/following et autres infos de compte. On repart de zéro, parce que le "login" est lié au nom de l'instance. Probablement que ça pourrait être résolu avec des fonctions d'export/import, ou en changeant la manière dont est forgé le login, mais pas sûr…

      Il est probable que tu fasses référence à mon article :

      salut@toto — salutation, règle éditoriale et nom sur Internet

      une version plus courte, qui met l'accent sur d'autres points :

      Mon Retour de PSESHSF : DNS & Minitel

      Il y a aussi la vidéo de la présentation (20min) de mon article à Pas Sage en Seine :

      https://www.youtube.com/watch?v=RIAv48OTYIA

      Oui je trouve que Mastodon reste aveugle aux problèmes posés par l'utilisation d'une adresse username@hébergeur. En gros cette forme d'adresse correspond à la situation où la portabilité du numéro de téléphone n'existait pas. Quand on changeait d'opérateur on perdait notre numéro. Si la portabilité du numéro de téléphone n'existait pas, Free Mobile n'aurait jamais pu exister. Je propose d'utiliser une adresse de la forme salutation@nom (indépendante de l'hébergeur).

      Mais ce problème ne se résout pas en développant un énième réseau social (XMPP, Ostatut, Diaspora, etc.) mais en automatisant et simplifiant la gestion des enregistrement DNS (ou du Gnu Name System) : il faudrait que je puisse autoriser facilement un hébergeur à écrire dans mes zones DNS (avec validation etc.). Bref que ça devienne accessible aux Michu-Morizeau.

  • # Twister: une alternative à l'alternative

    Posté par . Évalué à 4 (+3/-0).

    Il y a quelques temps déjà j'étais tombé sur twister mais je n'ai aucune idée de ce que ça vaut. Ça ressemble -de ce que j'en sais- à Twitter, mais en décentralisé, un peu comme Mastodon.

    • [^] # Re: Twister: une alternative à l'alternative

      Posté par . Évalué à 2 (+2/-0).

      L’avantage de Twister est d’être effectivement décentralisé (P2P) là où Mastodon suis un modèle de fédération, par contre ce n’est pas aussi simple que de lancer l’url dans un navigateur, il y a un client à installer, du coup c’est assez peu utilisé.

  • # Numerama : Pourquoi nous avons créé notre instance Mastodon

    Posté par (page perso) . Évalué à 6 (+5/-0).

    Numerama a son instance Mastodon. Ce n'était pas très compliqué à mettre en place et nous pensons que c'est bon pour notre média et pour le web. Petites explications.

    lire la suite par ici

    • [^] # Re: Numerama : Pourquoi nous avons créé notre instance Mastodon

      Posté par . Évalué à 4 (+2/-0).

      L'article est bien fichu. La conclusion est limpide sur l'intérêt d'un réseau social centralisé.

      • [^] # Re: Numerama : Pourquoi nous avons créé notre instance Mastodon

        Posté par . Évalué à 4 (+1/-0).

        Certes, mais j'allais demander outre le hype, pourquoi une instance Mastodon et pas XMPP ou Diaspora?
        Ils essaient de s'en défendre, mais ils sont carrément dans l'effet hype, là!

        Enfin, si ça permet de faire décoller les réseaux sociaux Libres, c'est tout bon!

        • [^] # Re: Numerama : Pourquoi nous avons créé notre instance Mastodon

          Posté par . Évalué à 1 (+1/-2).

          Certes, mais j'allais demander outre le hype, pourquoi une instance Mastodon et pas XMPP ou Diaspora?

          Pour paraphraser un autre article (dont je ne retrouve pas le lien, désolé) : parce que si GNU Social existe depuis un bail, Mastodon est le premier système qui soit raisonnablement facile à utiliser, et qui propose une interface moderne, ergonomique, et suffisamment réactive. Bref, un truc qui a un look « pro » tout en assurant les fonctionnalités que tout le monde attend de Twitt^W d'un service de micro-blogging.

        • [^] # Re: Numerama : Pourquoi nous avons créé notre instance Mastodon

          Posté par . Évalué à 4 (+2/-0).

          Un réseau social, c'est fait par les gens, pas par l'outil. Là, les gens ont décidé en masse d'aller sur Mastodon (peut-être par attrait de l'outil, mais ça ne fait pas tout c'est évident). Donc ils suivent la mouvance, c'est tout.

          Moi aussi je suis sur Mastodon, et pas sur Diaspora. Pourquoi ? Bin je connais du monde sur Mastodon, et pas sur Diaspora.

          • [^] # Re: Numerama : Pourquoi nous avons créé notre instance Mastodon

            Posté par (page perso) . Évalué à 3 (+1/-0).

            Moi aussi je suis sur Mastodon, et pas sur Diaspora. Pourquoi ? Bin je connais du monde sur Mastodon, et pas sur Diaspora.

            Et ce ne serait pas plus chouette de ne pas avoir à se soucier de savoir sur quel réseau décentralisé sont les gens ? D’être sur un réseau décentralisé et de pouvoir suivre qui on veut, même s’ils sont sur un réseau « concurrent » ? Si tu n’étais pas obligé d’être sur le même réseau que tous tes contacts ?

            C’est exactement ce que permet Friendica, qui s’efforce de prendre en charge les protocoles utilisés par les autres réseaux décentralisés (OStatus et Diaspora) en plus de son propre protocole (DFRN).

  • # du bon et du moins bon

    Posté par (page perso) . Évalué à 10 (+14/-1).

    Salut,

    m'intéressant de près à ce genre de logiciels, j'ai testé un peu.

    Déjà ça n'est pas nouveau, ça se base sur un protocole existant et documenté (ostatus/GNU Social), ce qui est un très bon point. À l'usage je n'aime pas trop (je trouve ça trop compliqué pour un utilisateur lambda, et ça manque de fonctionnalités pour un utilisateur avancé), mais les gens s'y retrouvent parce que ça ressemble à TweetDeck (ce qui ne fonctionne qu'avec un public restreint). C'est propre et y'a des petits animations agréables.

    Je trouve le besoin de créer un nouveau vocabulaire pour se différencier à chaque fois non seulement ridicule mais aussi perturbant (« pouet » ou « toot » pour billet/publication)

    C'est toujours une bonne chose d'avoir un peu d'attention sur un projet libre., même si je trouve que l'excitation est un peu exagérée (faire peur à Twitter c'est juste bon pour les titres chocs, faut avoir un minimum le sens des proportions du moins à l'heure actuelle).

    Après ce que je regrette, comme pratiquement à chaque fois, c'est qu'il y ait une excitation sur une simple base visuelle/technique (de loin, on évalue principalement le côté libre et décentralisé), sans s’inquiéter de toute la partie politiques (gouvernance, fonctionnalités et leur disposition, public présent, etc).

    J'ai développé un peu ce point sur seenthis: https://seenthis.net/messages/585190#message586271

    À l'heure actuelle je ne crois pas trop à son succès sur le long terme, si ce n'est avec le réseau GNU Social déjà existant (ce qui est déjà pas mal).

    • [^] # Re: du bon et du moins bon

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Déjà ça n'est pas nouveau, ça se base sur un protocole existant et documenté (ostatus/GNU Social)

      Oui, et beaucoup de gens semblent avoir du mal à comprendre ce point. Tout le monde parle d’un « nouveau réseau social » ou du « réseau Mastodon », alors que le réseau social sous-jacent n’est autre que le réseau basé sur le protocole OStatus, qui ne date quand même pas d’hier.

      • [^] # Re: du bon et du moins bon

        Posté par . Évalué à 8 (+5/-0).

        Oui, et beaucoup de gens semblent avoir du mal à comprendre ce point. Tout le monde parle d’un « nouveau réseau social » ou du « réseau Mastodon », alors que le réseau social sous-jacent n’est autre que le réseau basé sur le protocole OStatus, qui ne date quand même pas d’hier.

        Le protocole n'est qu'un outil dont l'utilisateur final se fiche complètement.
        Ici, c'est Libre et décentralisé, c'est tout ce qui l'intéresse.

        Si tu ne me crois pas, regarde l'intérêt fulgurant qu'il y a eu pour Matrix alors que c'est un énième protocole.

        Ils auraient fait un client XMPP/Pubsub avec exactement la même interface que ça aurait eu autant de succès.

      • [^] # Re: du bon et du moins bon

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Il y a le réseau technique et d'infrastructure, c'est ostatus/GNU Social. Et par-dessus, il y a le réseau social, qui est composé non pas de machines, mais de gens qui discutent. Donc, ça me semble justifié de parler d'un nouveau réseau social, même s'il utilise des protocoles et une implémentation déjà existants.

        • [^] # Re: du bon et du moins bon

          Posté par (page perso) . Évalué à 4 (+3/-1).

          Donc, ça me semble justifié de parler d'un nouveau réseau social, même s'il utilise des protocoles et une implémentation déjà existants.

          Ben non, parce que c’est le même réseau. Les utilisateurs de GNU Social, de Friendica, de Mastodon peuvent tous se suivre et se parler entre eux, indépendamment de l’implémentation que leur instance utilise.

          À moins que les utilisateurs de Mastodon décident sciemment de ne pas adresser la parole aux utilisateurs situés sur des instances non-Mastodon…

    • [^] # Re: du bon et du moins bon

      Posté par . Évalué à 10 (+7/-0).

      Après ce que je regrette, comme pratiquement à chaque fois, c'est qu'il y ait une excitation sur une simple base visuelle/technique (de loin, on évalue principalement le côté libre et décentralisé), sans s’inquiéter de toute la partie politiques (gouvernance, fonctionnalités et leur disposition, public présent, etc).

      Écoute, quelqu'un de vraiment très très proche de moi que je ne balancerai pas choisit ses voitures sur leur design et leur couleur. Si je parle de consommation d'essence, accessoires, performance, ben je parle dans le vide. Tout le monde ne s'intéresse pas aux voitures. Et quand on ne s'y intéresse pas, il ne reste que la perception basique: beau, confortable, etc.

      Et bien là c'est exactement la même chose. Le design, l'interface, c'est la première chose que l'utilisateur qui veut juste utiliser regarde.
      De même que "pouet" ou autre, c'est du marketing, parce que ça fait plus cool que "billet" ou "publication". Ça contribue à attirer des utilisateurs.
      Où est le mal là-dedans?

      C'est beau? C'est simple à utiliser? Et bien c'est prêt pour le grand public.
      C'est techniquement une merveille mais c'est moche à souhait? Condamné à rester entre geeks!

      À la fin, le but d'un dév de réseau social, c'est quoi? Faire un super outil mais peut-être moche, ou attirer le plus d'utilisateurs possible?
      Je dirais les 2! Du coup il faut investir autant sous le capôt que sur le design.

      • [^] # Re: du bon et du moins bon

        Posté par (page perso) . Évalué à 5 (+3/-0). Dernière modification le 07/04/17 à 08:37.

        Écoute, quelqu'un de vraiment très très proche de moi que je ne balancerai pas choisit ses voitures sur leur design et leur couleur. Si je parle de consommation d'essence, accessoires, performance, ben je parle dans le vide. Tout le monde ne s'intéresse pas aux voitures. Et quand on ne s'y intéresse pas, il ne reste que la perception basique: beau, confortable, etc.

        Oui enfin c'est avec ce genre de raisonnement que les gens votent pour des candidats beaux, confortables, etc.
        (le parallèle est très douteux, mais je le trouvais amusant).

        Plus sérieusement je n'ai jamais dit que beau et simple à utiliser n'étaient pas de bonnes choses, c'est même une question d'accessibilité (pour la simplicité tout du moins).
        Ce qui me chagrine, c'est que dans tout l'enthousiasme actuel, et qui concerne quand même une population à dominante technique (on parle des lecteurs de hacker news, numérama, etc tout de même, même s'il y a eu quelques article après coup sur des médias généralistes), personne ne semble s’inquiéter des questions politiques autour. Et là je cite parce que c'est flagrant, mais c'est le cas à chaque truc à la mode, les seuls critères sont est-ce que c'est libre ? Est-ce que c'est décentralisé ? Est-ce qu'il y a du monde ? est-ce que c'est beau ? Est-ce que c'est chiffré ? C'est déjà une bonne base, mais je regrette que ça s'arrête là.

        Et ça va sans doute te paraître bizarre vu mon historique, mais je me moque du protocole en dessous sur le plan purement technique, par contre je m'inquiète qu'il soit standard (et donc documenté), et non contrôlé par une grosse entité, ce qui est le cas ici).

        Ceci mis de côté, je suis très content que les projecteurs soient sur un projet libre, et que ça amène un peu du monde sur GNU Social, et je compte utiliser si ça tient sur la durée (je le fais déjà d'ailleurs, et j'étais sur GNU Social avant), voire faire une passerelle XMPP.

        • [^] # Re: du bon et du moins bon

          Posté par . Évalué à 8 (+5/-0).

          Ce qui me chagrine, c'est que dans tout l'enthousiasme actuel, et qui concerne quand même une population à dominante technique (on parle des lecteurs de hacker news, numérama, etc tout de même, même s'il y a eu quelques article après coup sur des médias généralistes), personne ne semble s’inquiéter des questions politiques autour. Et là je cite parce que c'est flagrant, mais c'est le cas à chaque truc à la mode, les seuls critères sont est-ce que c'est libre ? Est-ce que c'est décentralisé ? Est-ce qu'il y a du monde ? est-ce que c'est beau ? Est-ce que c'est chiffré ? C'est déjà une bonne base, mais je regrette que ça s'arrête là.

          Je pense que tu en demandes trop. Enfin, je ne vais pas te demander de renier tes principes et je les respecte, mais d'un point de vue pragmatique:
          -Les solutions Libres et décentralisées sont pour l'instant ratatinées par les géants centralisés proprio.
          -Aucune solution Libre et décentralisée ne semble sortir de la masse grouillante des diverses applis qui semble s'étaler sans cesse plutôt que se focaliser sur UN champion.

          Arrivé là, même si je comprends tes inquiétudes, je préfère voir émerger un champion imparfait qui pour une fois a une chance de faire la différence plutôt qu'une solution parfaite qui reste confidentielle.

          Pour moi, tant que c'est Libre et décentralisé, on peut toujours corriger les problèmes. Mais je préfèrerais carrément un Mastodon qui commence à modifier le protocole dans leur coin sans consulter personne en le publiant (évidemment) pour que les autres implémentations puissent le suivre et profiter de son succès, plutôt que le statut quo: 99.9% de mes contacts sont toujours sur Twitter et FB!

  • # Pour qu'il reste décentralisé, ne vous entassez pas :P

    Posté par . Évalué à 5 (+5/-0).

    Petit rappel, pour ceux qui voudraient s'inscrire, c'est un réseau décentralisé et donc basé sur de multiples instances. Pour profiter de ces avantages, évitez si possible de vous inscrire toujours sur la même grosse instance, ça reviens à recentraliser et à fragiliser le système ('l’instance devient coûteuse, surchargée, en cas d'attaque une plus grosse partie du réseau tombe,…).

    Regardez donc la liste, qui ne cesse de grandir: https://instances.mastodon.xyz/

    (on me murmure dans l'oreillette que les chatons sont sur le coup ! (du mastodonte :)

  • # Matrix ?

    Posté par . Évalué à 2 (+1/-1).

    Matrix paraît équivalent: https://matrix.org/ à essayer sur https://matrix.org/docs/projects/client/riot.html, il existe aussi des clients terminal, iOs, Android.

  • # Libre, vraiment ?

    Posté par (page perso) . Évalué à -2 (+2/-5).

    Je n'ai vu nul part qu'il était possible d'accéder au contenu diffusé par Mastodon sans y être inscrit.
    Peut-on vraiment parler de liberté quand pour pouvoir accéder au contenu il faut s'être authentifié ?
    On peut comprendre qu'il faille se connecter pour poster (encore que…), mais pas pour pouvoir lire.

    Personnellement je refuse d'avoir à gérer un n-ième compte sur un n-ième service qui, sur le fond, n'apporte pas grand chose à ce qu'apportait Usenet il y a déjà… 35 ans !

  • # Sysadmin nightmare

    Posté par . Évalué à 0 (+14/-16).

    Requirements :
    Ruby
    Node.js

    Ok je ne cherche même pas à lire la suite.

    • [^] # Re: Sysadmin nightmare

      Posté par (page perso) . Évalué à 1 (+7/-8).

      Ce qu'il y a de bien dans l'univers c'est l'équilibre ; en l’occurrence la suite ne cherche pas à te connaitre non plus.
      C'est bien, la vie dans l'instantané de ton passé que tu as décrété comme optimum absolu ? Tu penses quoi de la Tour Eiffel, c'est une horreur qu'il faudra vite démonter ?

      • [^] # Re: Sysadmin nightmare

        Posté par . Évalué à -9 (+2/-13).

        Vu que tu n'as rien d'intéressant à dire, tu peux t'abstenir.

        • [^] # Re: Sysadmin nightmare

          Posté par . Évalué à 3 (+5/-4).

          Parce que ton post était intéressant, peut-être ?!

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Sysadmin nightmare

            Posté par . Évalué à 4 (+5/-3).

            Vous faites un concours ? :o

            splash!

          • [^] # Re: Sysadmin nightmare

            Posté par (page perso) . Évalué à -2 (+4/-8).

            Attends, c'est super intéressant, Monsieur refuse du code qui utilise "tel techno haram" (comme s'il connaissait et comprenait intimement tout le code "pré-Ruby" qui tourne sur son ordi, sérieux…).

            Le point positif c'est qu'on a qu'à attendre que ces vieux cons disparaissent (physiquement dans le cimetière le plus proche, ou numériquement parce que IPv6 doit sûrement être trop hype pour eux, ou que sais-je) pour ne vraiment plus s'en soucier :-)

            • [^] # Re: Sysadmin nightmare

              Posté par . Évalué à 1 (+1/-2). Dernière modification le 07/04/17 à 09:18.

              Mon commentaire était en au moins en rapport avec l'actualité, contrairement au tiens qui visiblement n'a pas d'autre objectif que se foutre de ma gueule. Si ça t'amuse je t'en prie, tu peux continuer. J'ai passé l'âge de me bagarrer sur le web surtout pour savoir qui a raison ou qui maîtrise le mieux les attaques personnelles.

              • [^] # Re: Sysadmin nightmare

                Posté par . Évalué à 6 (+3/-0).

                Ton commentaire manquait d'explication. Il y a une difficulté particulière à maintenir en prod ce genre de stack ?
                Je sais qu'il y a des gens qui galèrent à gérer les gems ruby, mais je n'y ai jamais eu affaire.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Sysadmin nightmare

                  Posté par . Évalué à 2 (+0/-0).

                  De ce que j'en sais ce n'est pas pire que des modules perl, php, python ou des librairies pour java.

                • [^] # Re: Sysadmin nightmare

                  Posté par . Évalué à 2 (+0/-0).

                  C’est une question de perspectives. Si tu veux installer les dépendances niveau système, oui là ça devient plus galère, encore plus si tu veux passer par le gestionnaire de paquets de ta distrib (là ça devient quasi-impossible à moins de ne faire que ça). Si tu peux te satisfaire « les dépendances gérées par gem/composer font partie du code shippé par les devs, c’est pas mon boulot de sysadmin de gérer ça », aucun souci.

            • [^] # Re: Sysadmin nightmare

              Posté par (page perso) . Évalué à 6 (+4/-0). Dernière modification le 07/04/17 à 09:44.

              Le point positif c'est qu'on a qu'à attendre que ces vieux cons disparaissent (physiquement dans le cimetière le plus proche

              Espérer la mort de son interlocuteur, c'est élégant…

              Sans forcément rejoindre l'avis extrême de MTux, il faut dire aussi que nodejs (je ne prononce pas pour Ruby que je ne connais que mal) ne m'excite mais alors plus du tout depuis que j'ai découvert de vraies technos taillées pour le backend (comme Elixir).

              De là à ne pas utiliser un logiciel parce qu'il est fait en "…", d'un point de vue utilisateur, je préfère le juger pour ce qu'il propose comme résultat final et expérience.

    • [^] # Re: Sysadmin nightmare

      Posté par (page perso) . Évalué à 6 (+4/-0).

      Le source est ouvert, le protocole décrit, et personne n’empêche quelqu’un qui aurait du temps d’en refaire une implémentation dans la techno de son choix. Un volontaire pour Go par exemple ?

  • # Protocole?

    Posté par (page perso) . Évalué à 2 (+0/-0).

    Je lis partout que Mastodon utilise un protocole ouvert et documenté. Où se trouve cette documentation? Je ne trouve que des bribes…

    http://devnewton.bci.im

    • [^] # Re: Protocole?

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Il s’agit du protocole OStatus (avec apparemment quelques extensions non-standard).

      En fait, c’est un assemblage d’une série de protocoles :

      • Atom comme base ;
      • PubSubHubbub pour le modèle souscription/diffusion (permettant de pousser une nouvelle entrée Atom vers les souscripteurs) ;
      • Atom Activity Streams, une extension du format Atom permettant de représenter une « activité » sur le réseau social (par exemple, le fait qu’Alice aime le dernier post de Bob) ;
      • Salmon pour l’unification des discussions (en gros, faire en sorte que des messages apparaissent comme faisant partie de la même discussion même s’ils proviennent d’instances différentes) ;
      • WebFinger pour découvrir les utilisateurs.
      • [^] # Re: Protocole?

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Cet assemblage est très flou pour moi. Comment faire une implémentation compatible avec celle de Mastodon (à part faire de l'ingénierie inverse)?

        http://devnewton.bci.im

        • [^] # Re: Protocole?

          Posté par (page perso) . Évalué à 1 (+0/-1).

          Comment faire une implémentation compatible avec celle de Mastodon (à part faire de l'ingénierie inverse)?

          Étudier le code source des implémentations existantes ? GNU Social, Friendica, Mastodon… ce sont tous des logiciels libres.

          • [^] # Re: Protocole?

            Posté par (page perso) . Évalué à 5 (+3/-0).

            à part faire de l'ingénierie inverse

            :-)

            http://devnewton.bci.im

            • [^] # Re: Protocole?

              Posté par (page perso) . Évalué à 3 (+1/-0).

              Je me trompe peut-être (ce n’est pas mon rayon), mais je pensais que l’ingénierie inverse ou rétro-ingénierie, c’est quand tu n’as pas accès au code source, et que tu en es réduit à devoir observer le fonctionnement d’un programme pour en déduire sa logique (en particulier, dans le cas de programmes réseau, en observant les messages échangés sur le réseau).

              Par exemple, il m’est arrivé d’utiliser le code source de GnuPG pour mieux comprendre certains détails du standard OpenPGP que je ne trouvais, à la lecture du RFC, pas très clair. Est-ce de l’ingénierie inverse ?

              • [^] # Re: Protocole?

                Posté par (page perso) . Évalué à 4 (+2/-0).

                Ce n'est pas parce que tu as le plan d'un meuble Ikea que cela suffit pour le monter comprendre comment il est fait :-)

                http://devnewton.bci.im

              • [^] # Re: Protocole?

                Posté par (page perso) . Évalué à 4 (+2/-0).

                L'ingénierie inverse, c'est le fait d'aller à contre courant du cycle de développement normal: partir d'un binaire pour écrire le code source correspondant, mais aussi partir du code source pour écrire la spécification qui va avec.

  • # Alternative à Facebook

    Posté par . Évalué à -1 (+0/-1).

    Il y en a un nouveau que j'ai découvert. C'est un concurrent Français de facebook. Selon les infos que j'ai vu sur le site, les serveurs sont en France et il n'utilise pas les données des membres.

    C'est https://facedebooc.fr

  • # Discord ?

    Posté par . Évalué à 1 (+1/-0).

    Discord a des fonctions de partage blog, chat, comme les autres et en plus fait office de talk…
    bref, que pense le libre de cet outils ?

    https://discordapp.com

    je trouve le fonctionnement assez génial, mais je ne comprend pas trop où sont stockées les données que l'on partage ^

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.