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.
Journal Généralisation de la décentralisation & XMPP ?
20
nov.
2010
![http://javatar.server.net/images/user_server.net.jpg"](http://javatar.server.net/images/user_server.net.jpg"){kind=link}
# vCard
Posté par Victor . Évalué à 7.
Pour l'avatar c'est flagrant, pour les autres, ce ne serait pas étonnant !
[^] # Re: vCard
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
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)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: vCard
Posté par Frank-N-Furter . Évalué à 5.
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 Niniryoku . Évalué à 2.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Déjà pris
Posté par imr . Évalué à 8.
Là, ça serait plutôt jabbatar.
[^] # Re: Déjà pris
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
[^] # Re: Déjà pris
Posté par syntaxerror . Évalué à 1.
# OpenID & pavatar
Posté par Mildred (site web personnel) . Évalué à 8.
http://pavatar.com/
[^] # Re: OpenID & pavatar
Posté par Nicolas Deveaud . Évalué à 7.
Tant qu'a faire, autant essayer d'utiliser les bon outils décentralisés.
[^] # Re: OpenID & pavatar
Posté par DLFP est mort . Évalué à 4.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Théoriquement, ça devrait déjà être possible
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
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 Jehan (site web personnel, Mastodon) . Évalué à 4.
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 Éric (site web personnel) . Évalué à 4.
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".
[^] # Re: Vive la roue
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
well-known, je ne connais pas non plus mais je n'arrive pas à trouver sur Google ;-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Vive la roue
Posté par Éric (site web personnel) . Évalué à 3.
Voir http://code.google.com/p/webfinger/wiki/WebFingerProtocol , http://tools.ietf.org/html/draft-hammer-hostmeta-05#section-(...) , http://hueniverse.com/2009/03/the-discovery-protocol-stack/ et http://hueniverse.com/2009/09/implementing-webfinger/
[^] # Re: Vive la roue
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
C'est exactement ce que je cherchais ! Merci 1000x
Mes livres CC By-SA : https://ploum.net/livres.html
# autre décentralisation
Posté par stopspam . Évalué à 2.
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 Frank-N-Furter . Évalué à 2.
Depending on the time of day, the French go either way.
[^] # Re: autre décentralisation
Posté par dj_ (site web personnel) . Évalué à 2.
[^] # Re: autre décentralisation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
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 Frank-N-Furter . Évalué à 1.
Depending on the time of day, the French go either way.
[^] # Re: autre décentralisation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
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 Frank-N-Furter . Évalué à 3.
Depending on the time of day, the French go either way.
[^] # Re: autre décentralisation
Posté par Larry Cow . Évalué à 2.
# Mais c'est un annuaire qu'il faut !
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
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 Frank-N-Furter . Évalué à 4.
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 Etienne Bagnoud (site web personnel) . Évalué à 4.
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 daimrod . É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 Frank-N-Furter . Évalué à 2.
Depending on the time of day, the French go either way.
[^] # Re: Mais c'est un annuaire qu'il faut !
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
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 Frank-N-Furter . É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)?
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 Etienne Bagnoud (site web personnel) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.