Libravatar — fin du service ou début du renouveau

Posté par (page perso) . Édité par Davy Defaud, Benoît Sibaud, ZeroHeure et Trollnad Dump. Modéré par Nÿco. Licence CC by-sa.
Tags :
22
7
mai
2018
Technologie

Qu’est‐ce que Libravatar ?
Le projet Libravatar permet de mettre à disposition de vos services un avatar unique pour l’ensemble de vos comptes. Il ne s’agit rien de plus que du même service proposé par Gravatar sans la couche Wordpress et avec la possibilité d’auto‐hébergement.

L’ensemble se compose des technologies suivantes :

  • PostgreSQL ;
  • Django ;
  • Python (2.7).

Logo de Libravatar

Tous les services ne sont pas compatibles Libravatar, mais quand ils sont compatibles Gravatar, la plupart du temps, une petite demande d’intégration Git (pull‐request) et cela peut le devenir car la méthode est la même. En effet, cela se base sur votre adresse de courriel et l’utilisation de hash.

Exemple d’image renvoyée en cas d’absence d’avatar

Il y a un mois un nouvel article est apparu sur la page du projet, celui‐ci concerne l’arrêt du service pour ses utilisateurs utilisant l’instance de Libravatar. Le fondateur François Marier explique sur son blog les raisons qui le poussent à arrêter le service dont voici la liste :

  • le manque d’implémentation dans les bibliothèques et greffons du DNS FEDERATION pour la décentralisation du service ;
  • peu de nouvelles instances auto‐hébergées ont vu le jour ;
  • le manque de contributeurs dans le code (aucune demande d’intégration Git sur leur dépôt GitHub) ;
  • la difficulté de délégation de tâches quand il faut être root pour la majeure partie des tâches ;
  • la difficulté de maintenir la pile logicielle lors des mises à jour des versions des outils.

Exemple d’image renvoyée en cas d’absence d’avatar défini

À l’heure actuelle, il n’y a aucune autre alternative libre pour ce type de service, et même si une page de reprise existe, aucune annonce n’a encore été faite. Est‐ce la fin de ce service ou simplement le début de sa mutation ? Quelques acteurs ont déjà proposé leur aide dans la page Shutdown Coordination, nous pouvons citer actuellement :

  • Digital Ocean (sponsoring) ;
  • Zach, de MailCan ;
  • Clime, de Red hat avec un nouveau dépôt ;
  • Sadin, du projet Fedora (développement).
  • # Auto hébergement

    Posté par (page perso) . Évalué à 6.

    L'auto hébergement n'a pas beaucoup de sens avec ce projet selon moi. L'intérêt c'est que je mets mon avatar une fois dessus, et qu'ensuite ça fonctionne partout. Mais ça ne peut fonctionner que s'il y a une instance centrale sur laquelle tout le monde tape.

    Si héberge ma propre instance, alors quoi ? Je fais des PR sur tous les projets que j'utilise pour ajouter l'URL de mon instance ? Ça ne peut pas marcher.

    Une solution serait de fédérer les instances, mais on a alors un autre problème : comment garantir l'authenticité de l'information ? Si une instance me répond posséder les info concernant le mail X, une autre instance peut aussi prétendre la même chose. Qui a raison ? C'est un problème complexe, et c'est ce qui fait que dans le projet Matrix (communication décentralisée avec des serveurs fédérés) l'identity server (qui permet de mapper un mail ou numéro de téléphone à un utilisateur, pour retrouver ses contacts) est toujours centralisé (une seule instance fait foi).

    Une fois qu'on est arrivé à ce constat, vient le second problème : comment maintenir une instance pour toute la communauté ? Dès qu'elle va être un peu utilisée ça va demander des ressources humaines et financières qui sont peu accessibles à un ou plusieurs bénévoles. Framasoft pour rappel à (au moins) un administrateur système embauché à plein temps.

    Bref, la fin de ce projet m'inspire plein de réflexions concernant la viabilité de ces projets libres lancés par une personne dans son coin. J'apprécie l'initiative, mais la durée sur le long terme me paraît comprise.

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

    • [^] # Re: Auto hébergement

      Posté par (page perso) . Évalué à 9.

      Pour moi gravatar a inventé de toutes pièces ce besoin d’une instance centralisée.
      Il suffit de demander aux gens une URL au lieu d’une adresse mail et il n’y a plus aucun soucis à décentraliser l’hébergement de l’avatar.

      C’était notamment l’idée derrière pavatar https://github.com/pavatar/pavatar par exemple.

      • [^] # Re: Auto hébergement

        Posté par (page perso) . Évalué à 5.

        Il suffit de demander aux gens une URL au lieu d’une adresse mail et il n’y a plus aucun soucis à décentraliser l’hébergement de l’avatar.

        C'est bien tout le problème. La plupart des gens qui surfent sur le web ont au moins une adresse mail, mais rarement une url perso. Et si on leur demande d'en créer une juste pour avoir leur avatar centralisé… je doute que cela marche.

        • [^] # Re: Auto hébergement

          Posté par . Évalué à 3.

          En effet. Par contre, un mécanisme déterministe de transformation d'adresse email URL et des services qui jouent le jeu, ça peut le faire. Genre un .well-known et/ou SRV-record largement accepté, adjoint d'un service centralisé (ou répliqué) pour héberger les avatars des plus gros prestas de messagerie (qui ne sont pas près de jouer le jeu). De mémoire, c'était un peu ce que libravatar proposait, non?

          • [^] # Re: Auto hébergement

            Posté par . Évalué à 4.

            en plus simple: une adresse email dédiée qui retourne une réponse automatique contenant l'avatar en base64 à chaque fois qu'elle reçoit un courrier.

      • [^] # Re: Auto hébergement

        Posté par (page perso) . Évalué à 4.

        Et du coup injecter dans les pages des ressources venant de n’importe où ?

        • [^] # Re: Auto hébergement

          Posté par (page perso) . Évalué à 2.

          Au moment de la définition de l'URL, rien n'empêche à la soumission du formulaire (ou via un événement JavaScript) de vérifier l'image pointée par l'URL et d'en faire une copie en local (sur le site web). À chaque insertion de l'image, on peut utiliser la version en cache ou (s'il est jugé utile d'aller voir s'il y a une nouvelle version, potentiellement après un certain délais) refaire la vérification et mettre la nouvelle version en cache si nécessaire et qu'elle est valide.

    • [^] # Re: Auto hébergement

      Posté par (page perso) . Évalué à 3.

      Une solution serait de fédérer les instances, mais on a alors un autre problème : comment garantir l'authenticité de l'information ? Si une instance me répond posséder les info concernant le mail X, une autre instance peut aussi prétendre la même chose. Qui a raison ?

      Si je comprends bien leur API, cela est fait au niveau des DNS. Tous les utilisateurs d'un domaine pourraient spécifier quel serveur héberge leur avatar.
      Cela fonctionne bien dans un monde ou chacun a son petit serveur mail perso. Moins dans un ou tout le monde utilise gmail…

      • [^] # Re: Auto hébergement

        Posté par (page perso) . Évalué à 2.

        Je profite de te lire ici pour te proposer une interview : on n'a plus de dépêche Odoo depuis longtemps, c'est dommage. Une petite interview mêlant technique et fonctionel sur Odoo ça te dit ?

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # python 2.7 pourquoi ne pas passer en 3.7 ?

    Posté par . Évalué à 8.

    Bonjour,
    on est à la version 3.7 de python, sauf erreur la 2.7 date de Juillet 2010. Que des anciens projets restent en version 2 je peux comprendre mais les nouveaux…
    C'est juste pour en connaitre la raison.
    Merci

  • # XMPP et avatar

    Posté par (page perso) . Évalué à 4.

    À l’heure actuelle, il n’y a aucune autre alternative libre pour ce type de service

    XMPP, non ?

Suivre le flux des commentaires

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