Journal Généralisation de la décentralisation & XMPP ?

Posté par (page perso) .
Tags : aucun
10
20
nov.
2010
Hello,

Il y a, dans le monde du libre, quelques services centralisés qui n'ont pas encore de réels équivalents décentralisés. Et la décentralisation, ça me passionne justement !

Un de ces services très populaire est le gravatar : un simple serveur qui associe une adresse mail à un jpg qui peut vous servir d'avatar un peu partout.


Dès le début de gravatar, j'avais imaginé le même principe décentralisé en utilisant l'avatar de l'adresse Jabber de la personne. Le javatar. J'ai même fait, à l'époque, une petite appli PHP à qui affiche l'avatar Jabber de n'importe quelle adresse qu'on lui passe en paramètre.

(Bien que je n'ai jamais rien rendu public, le nom est tellement logique qu'il est utilisé pour ce même usage : http://wiki.jabberfr.org/Javatar )

Le problème de la solution actuelle est qu'il faut que la personne accepte un contact XMPP, un bot. Et l'utilisateur doit accepter un bot pour chaque service qui veut voir son avatar ! Ce n'est de plus pas généralisable à d'autres services décentralisés (par exemple un Flattr décentralisé).


Le problème est donc le suivant : étant donné une adresse XMPP de type user@server.net, comment déterminer le serveur que l'utilisateur utilise pour le service X.

De cette manière, un script pour démander : quel est le javatar de user@server.net ? Réponse : "http://javatar.server.net/images/user_server.net.jpg" (par exemple)
(cela permettrait même une rétrocompatibilité avec Gravatar)

Quelle est l'adresse de microblogging de user@server.net ? Réponse : "http://identi.ca/user"

Comment envoyer des bitcoins à user@server.net ? Réponse : "http://bitcoin-server/web-api/user"



Y'a-t-il un mécanisme qui permettrait ce genre de choses en XMPP ? Genre Pubsub ? Il est évident que la réponse doit être identique que l'utilisateur soit en ligne ou pas !


Bref, un tel mécanisme permettrait à chaque utilisateur de gérer de manière centralisée sa décentralisation sur le web et permettrait à de nombreux services de se contenter de l'adresse XMPP d'un utilisateur pour accéder à des tas de services.

Ceci est bien entendu une "tempète dans le cerveau", j'aimerais avoir vos idées, vos retours.
  • # vCard

    Posté par . Évalué à 7.

    Ce n'est pas le genre d'information qu'on met dans la même vCard ?

    Pour l'avatar c'est flagrant, pour les autres, ce ne serait pas étonnant !
    • [^] # Re: vCard

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

      Est-ce que la Vcard est extensible pour supporter des champs arbitraires ?

      Est-ce que également elle peut contenir des champs par défaut ? Je pense par exemple au fait que, par défaut, les utilisateurs de fritalk.com pourrait utiliser le serveur avatar.fritalk.com pour leurs avatars (mais pourraient le changer si ils le veulent)
      • [^] # Re: vCard

        Posté par . Évalué à 5.

        http://www.ietf.org/rfc/rfc2426.txt

        3.8 Extended Types

        The types defined by this document can be extended with private types
        using the non-standard, private values mechanism defined in [RFC
        2045]. Non-standard, private types with a name starting with "X-" may
        be defined bilaterally between two cooperating agents without outside
        registration or standardization.


        Tu peux aussi jeter un coup d'œil à cette page:
        http://www.axschema.org/types/

        Depending on the time of day, the French go either way.

  • # Déjà pris

    Posté par . Évalué à 2.

    « Javatar » existe déjà. C'est le nom d'un film du même réalisateur que celui ci [http://jz10.java.no/mediaplayer/JavaZoneTrailer.flv].

    Knowing the syntax of Java does not make someone a software engineer.

    • [^] # Re: Déjà pris

      Posté par . Évalué à 8.

      En plus le nom n'est pas tellement logique, javatar, ça fait avatar d'un développeur java ou javascript, mais pas d'un utilisateur jabber.
      Là, ça serait plutôt jabbatar.
  • # OpenID & pavatar

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

    Juste une balise meta a mettre sur ta page OpenID:

    http://pavatar.com/
    • [^] # Re: OpenID & pavatar

      Posté par . Évalué à 7.

      Effectivement, pourquoi utiliser xmpp, alors que OpenID semble plus dédié a faire ce que tu décris : gérer une identité numérique.
      Tant qu'a faire, autant essayer d'utiliser les bon outils décentralisés.
    • [^] # Re: OpenID & pavatar

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

      C'est pas lié à OpenID, même si ça se marie bien avec. Enfin bref je trouve que c'est la solution idéale, très simple à mettre en œuvre.

      DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Théoriquement, ça devrait déjà être possible

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

    Salut,

    tout dépend de comment sont implémentés les avatars actuellement.
    Il existe pour l'instant 3 (je pense pas plus, mais qui sait?.. on a tellement de doublons) spécifications pour les avatars XMPP:

    - ceux basés sur une requête spécifique (IQ-based, XEP-0008), historiquement. Mais cette méthode n'est plus considérée comme valide et obsolète (ce qui ne signifie pas qu'il n'y a pas quelques implémentations qui l'utilisent encore peut-être).
    Ta demande est-être possible avec cette XEP mais je ne creuse pas, cette spéc est très limitée et inintéressante.

    - ceux basés sur les vcards (XEP-0153), méthode très répandue et la spéc est considéré comme active (la seule spéc avatar active), bien qu'historique également (donc potentiellement supplantable).

    Cette spéc te permet déjà de faire ce que tu souhaites puisque la spéc vcard (XEP-0054) précise bien dans les considérations de sécurité que la vcard est visible par le monde entier. Il n'y a pas de notion de droits sur une vcard donc ton bot XMPP peut demander la vcard de n'importe qui et *n'a pas besoin de demander à être inscrit dans ses contacts!*

    - ceux basés sur PEP, donc PubSub (XEP-0084). Son statut est en "brouillon", mais c'est le seul considéré comme en état de standardisation. En gros ça se bagarre avec la XEP vcard pour savoir qui l'emporte.

    Là aussi c'est possible puisque PubSub a un système de droits élaborés, contrairement à vcard qui est "visible par le monde entier". Donc un utilisateur peut théoriquement décider à qui il montre ses infos publiés au cas par cas (ça peut être seulement à ses contacts, voire seulement à un groupe de contacts, par une liste de JID, à tout le monde, ou même sur demande que l'utilisateur reçoit puis valide ou refuse ensuite). Évidemment les clients gèrent très mal, voire pas du tout pour tous ceux que j'ai vu, ce genre de droits sur les nœuds Pubsub ou PEP, et il ne demandent jamais ce genre d'infos. Donc cela dépend probablement de l'implémentation du client et du serveur, cad quels droits par défaut ils mettent en créant un nœud. Étant donné ce que j'avais vu à l'époque de tests sur PubSub (mais mes derniers tests remontent bien à un an ou plus maintenant), y a de fortes chances que les droits par défaut soient souvent publiques, malheureusement (je dis "malheureusement" de manière générale, par contre le nœud avatar, je pense que "publique" peut être une bonne valeur par défaut, mais il faudrait quand même que l'utilisateur puisse changer cette valeur s'il le souhaite).
    Mais heureusement par contre pour toi qui peut sûrement récupérer les avatar PEP de cette façon.

    Pour conclure, je pense que tu n'auras pas de problème pour faire ce que tu veux. Par contre tu peux voir que les avatars Jabber sont un peu un bordel pour l'instant et que théoriquement, un même utilisateur pourrait avoir 3 avatars différents selon la technologie choisie pour la récupérer.
    Bye.

    Jehan

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Théoriquement, ça devrait déjà être possible

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

      P.S.: les avatars PEP ont un autre gros avantage (en plus de garantir la vie privée de certains s'ils ne souhaitent pas rendre leur avatar publique, ce qui est leur droit, non?), c'est que ton bot peut (il "peut", mais n'est pas obligé et peut se contenter de demander l'avatar une seule fois) aussi s'inscrire au nœud PEP publique de l'avatar (ce n'est pas une inscription à la présence de l'utilisateur, il ne devient pas contact), de sorte qu'à chaque fois que le nœud est mis à jour (nouvel avatar), il envoie l'information à tous les inscrits. Donc lors de sa prochaine connexion, ton bot peut mettre à jour l'avatar de l'utilisateur sur ton site web.

      C'est même beaucoup mieux qu'une inscription à la présence puisque c'est la seule information dont ton bot a besoin. Avec une inscription présence, cela génère plein d'information inutile sur le réseau (la présence elle-même déjà, que ton bot envoie et qu'il reçoit de tous les contacts, puis toute information relative, comme des "découvertes" de fonctionnalités faites par les contacts du bot à celui-ci, ou bien la liste de leur propre fonctionnalité qu'ils envoient potentiellement pro-activement, etc.).
      Là, aucun échange superflu, uniquement la nouvelle information nécessaire, SI et QUAND l'avatar change, et seulement à ce moment là.

      C'est de là que vient le nom PubSub: "Publish-Subscribe" (Publier-S'inscrire).

      Perso j'irais avec une implémentation là dessus si j'étais toi (mais je suis pas sûr que ce soit l'implémentation choisie par la plupart des clients à l'heure actuelle).

      Enfin bon vcard marche aussi parfaitement pour ton use case, seulement il n'y aura pas de mise à jour pro-active (si jamais tu veux savoir si un avatar est mis à jour et que tu n'as pas d'inscription présence, tu dois redemander).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Vive la roue

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

    Ru réinventes la roue.

    Déjà il existe pavatar et favatar, qui tous les deux ont tenté d'éviter le point unique de gravatar.

    Si tu acceptes d'utiliser une URI comme identifiant et pas simplement un user@host tu as aussi FOAF qui peut permettre de jouer à tout ça et qui est déjà représenter une identité.


    Sinon, dans une optique plus générique vu que tu ouvres aussi à d'autres choses que les avatars, tu as web-finger et le .well-known qui permettent de référencer ce genre de choses à partir d'une URI ou d'un user@host.


    Après côté "description de services" tu as les enregistrements SRV des DNS qui sont là pour ça. Ce n'est pas utilisable par monsieur tout le monde sur sa page web, mais en même temps XMPP non plus : dans les deux cas soit tu utilises un service hébergé existant soit tu as probablement la main pour toucher tes DNS.


    Le pire c'est que je suis certain que j'en oublie, alors surtout ne te lances pas dans "yet another method for".
  • # autre décentralisation

    Posté par . Évalué à 2.

    moi une décentralisation que j'attends depuis un moment est celle des marques-pages !

    Parce que oui, les services de synchro au final ils en font quoi de mes marques pages ? Quelqu'un s'est déjà fait un tel service ?
    • [^] # Re: autre décentralisation

      Posté par . Évalué à 2.

      Si tu utilises firefox, tu as sync: https://wiki.mozilla.org/Labs/Weave/Sync/1.0/Setup

      Depending on the time of day, the French go either way.

    • [^] # Re: autre décentralisation

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

      certaines extensions firefox supportent l'utilisation de ftp privé : SyncPlaces par exemple
    • [^] # Re: autre décentralisation

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

      Salut,

      j'avais fait un plugin pour Firefox (doit y avoir 2 ans, waw le temps passe!) qui stocke justement les marques pages sur un nœud pubsub de son compte Jabber (cf. XEP-0048 bien que celle-ci mérite une bonne réécriture, que je prévoyais également en même temps de compléter le plugin). Mais ce plugin est resté à un stade très expérimental (il est très mal intégré à Firefox, pour l'instant c'est tout juste un "proof of concept" basique, fonctionnel mais pas du tout utilisable avec plaisir) parce que je n'ai jamais pris le temps d'aller plus loin, bien que j'ai encore envie d'y revenir dès que je le veux.

      En gros, les marques pages sont stockées sur son serveur XMPP (qui est donc décentralisé, on peut même avoir son propre serveur si on veut contrôle total), et est privé. Mais PubSub étant ce qu'il est avec son système de droit, on doit aussi pouvoir avoir des nœuds publiques ou semi-publiques (comme je dis plus haut: on choisit à qui on partage au cas par cas, ou bien par groupe de contact, ou à tout le monde, etc.) pour partager ses marques pages, de sorte que si quelqu'un change ses marques pages publiques et que j'y suis inscrit, la liste serait automatiquement mise à jour dans mon navigateur. Etc.

      Aussi vous l'aurez compris, je ne suis pas d'accord avec les gens plus haut qui pensent que XMPP n'est pas du tout adapté pour ce genre de choses.

      Bye.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: autre décentralisation

        Posté par . Évalué à 1.

        Que veux-tu, tout le monde n’a pas des heures de conseils en XMPP à vendre. :p

        Depending on the time of day, the French go either way.

        • [^] # Re: autre décentralisation

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

          Salut,

          dois-je comprendre de ta réponse que tu penses que je trouve que XMPP est bon pour plein de choses parce que je souhaite ensuite me vendre dans la foulée comme consultant ou quelque chose du genre? Donc en gros que même si je ne croyais pas en XMPP, je le "vendrais" tout de même, pour ensuite pouvoir me vendre moi-même?

          Alors outre le fait que quelqu'un pourrait trouver cela insultant (mais t'as de la chance, je ne suis pas susceptible), je tiens juste à préciser que je ne suis pas "consultant XMPP" (ni consultant tout court), et que je ne travaille (j'entends ici "travailler" dans le sens où je gagne ma vie) pas dans le milieu XMPP (bien que ça peut m'intéresser bien évidemment, mais je ne cherche pas plus que ça).

          Ma "seule" relation avec XMPP est que j'y "travaille" (cette fois dans le sens "j'y passe du temps") sur mon temps libre, à la fois en développement perso de logiciel Libre, et aussi sur l'amélioration des RFCs IETF associées et des XEPs.

          Donc si je promeus XMPP, c'est vraiment parce que j'y crois, et non pas pour des raisons vénales.
          Bye.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: autre décentralisation

            Posté par . Évalué à 3.

            Houla, loin de moi l’idée d’insinuer que ta ferveur pour XMPP était purement motivée par le lucre. Ce n’était qu’une boutade, d’où le smiley! Je te prie de bien vouloir accepter mes excuses, même si tu n’as pas mal pris ma remarque.

            Depending on the time of day, the French go either way.

    • [^] # Re: autre décentralisation

      Posté par . Évalué à 2.

      Perso j'utilise SemanticScuttle qui marche pas mal du tout (un delicious like en PHP). Par contre, j'avais commencé à essayer de le rendre OStatus-compliant, et c'est un peu au point mort pour l'instant.
  • # Mais c'est un annuaire qu'il faut !

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

    Étonnamment de ma part, je vais dire qu'un annuaire LDAP me semble la méthode adaptée à ce genre de chose. Le protocole ainsi que l'API est standardisé dans les RFC, les classes d'objets pour ce genre d'application est disponible (inetOrgPerson), les enregistrements DNS pour indiquer où se trouve le serveur LDAP sont disponibles, la délégation fait partie intégrante du protocole (donc facile à décentralisé), le support applicatif est déjà bien présent, la base de donnée pour un serveur LDAP est optimisée pour la recherche et la lecture, ...

    En gros c'est un protocole multi-plateforme, souple, orienté annuaire, reconnu et ouvert. Pas besoin d'étendre des schémas XML, de modifier des serveurs X ou Y, d'attendre sur un nouveau standard, ...

    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Mais c'est un annuaire qu'il faut !

      Posté par . Évalué à 4.

      Vous avez un numéro de music-hall avec jehan? :D
      Le but de gravatar, est de fournir une image qui sera dans la plus part des cas, affichée sur un site internet.
      Je ne suis un expert ni en XMPP, ni en LDAP (au passage, ta discussion avec je ne sais plus qui dans je ne sais plus quel thread, était fort intéressante et instructive), mais j’aimerais vous faire remarquer que beaucoup de sites hébergeant des forums tournent sur des LAMP super limités en termes de bibliothèques php installées, et souvent il ne faut pas compter sur la présence de libxmpp-php ou bien php5-ldap. Mais je raconte peut-être de grosses bêtises.

      Depending on the time of day, the French go either way.

      • [^] # Re: Mais c'est un annuaire qu'il faut !

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

        Vous avez un numéro de music-hall avec jehan? :D
        Toutes ces informations sont disponibles dans un annuaire LDAP :-)

        Ben c'est simple, les hébergeurs ne fournissant pas la librairie LDAP pour PHP doivent être brûler vif sur la place publique, ressuscité pour être re-brûler et finir leur au-delà en enfer (soit héberger facebook sur MS-DOS avec le support .NET).

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: Mais c'est un annuaire qu'il faut !

          Posté par . Évalué à 1.


          .NET 4.0 nécessitant toutes les précédentes versions, cela va de soi.
        • [^] # Re: Mais c'est un annuaire qu'il faut !

          Posté par . Évalué à 2.

          Et j’accède à l’annuaire LDAP via XMPP? Hmm, LDAP through XMPP on IPoAC...

          Depending on the time of day, the French go either way.

          • [^] # Re: Mais c'est un annuaire qu'il faut !

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

            Aaaah, tu voulais un protocole "to rule them all". Dans cas c'est HTTP.

            Non sérieux, XMPP ne me semble pas être un protocole d'annuaire, bon tu peux toujours faire des passerelles XMPP->LDAP, il y'a même https://secure.wikimedia.org/wikipedia/en/wiki/Directory_Ser(...) (et oui même les protocoles d'annuaire n'ont pas résisté à la vague XML).

            Tu peux toujours essayer de bricoler un protocole de présence et d'échange de message pour en faire un protocole d'annuaire ou tu peux utiliser un protocole d'annuaire. Moi je préfère utiliser le protocole adapté plutôt que d'adapter le protocole utilisé. Question d'éviter de réinventer la roue, rester dans des standards et favoriser l'interopérabilité.

            Je trouve triste cette volonté de vouloir refaire un protocole à tout faire, on a déjà HTTP, XMPP ne vaincra pas !

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

            • [^] # Re: Mais c'est un annuaire qu'il faut !

              Posté par . Évalué à 2.

              Je ne suis pas un tenant du XMPP bon à tout, contrairement a un petit groupe qui traine dans les parages, et qui voudrait faire de XMPP le nouveau XML, mais je n’en dirais pas plus, car ils sont infiltrés partout et je crains pour ma vie... (selon mes ex, je crains tout court)

              Quel est l’intérêt du DSML, par rapport au LDIF, en dehors du XML (et pour certains ce n’est pas un avantage)?

              Et je te suis à 1000%, XMPP ne passera pas par moi! (que les plus vieux expliquent aux plus jeunes)

              Heu, sinon, je ne sais pas si tu es au courant, mais tu as un ticket en attente de traitement dans les forums. : )
              http://linuxfr.org/forums/16/29405.html

              Depending on the time of day, the French go either way.

              • [^] # Re: Mais c'est un annuaire qu'il faut !

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

                Quel est l’intérêt du DSML, par rapport au LDIF, en dehors du XML (et pour certains ce n’est pas un avantage)?
                J'en sais rien, je n'y vois aucun, mais il y certainement des développeurs Java qui avait besoin de XMLiser les annuaires.

                Heu, sinon, je ne sais pas si tu es au courant, mais tu as un ticket en attente de traitement dans les forums. : )
                http://linuxfr.org/forums/16/29405.html


                Ouais je suis pas fan des forums parce que généralement tu demandes un complément d'information et comme c'est trop compliquer à te répondre, au lieu de dire "j'ai pas compris", ils ignorent ta réponse et c'est vexant et du coups j'ai arrêté les forums.
                De toutes façons RTFM (je vais aller voir le ticket, si je peux répondre RTFM).

                "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Suivre le flux des commentaires

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