Vous imaginez le merdier, si on sortait une fonctionnalité kikoolol de IRC tous les deux mois (genre, le salon IRC peut diffuser une musique d'ambiance
Par contre, ce qui me manque de l'Internet d'il y a 15 ans (ou plutôt, à la mode de y'a 15 ans), c'est de discuter via IRC ou NNTP, d'envoyer des fichiers via FTP, de diffuser des vidéos via ed2k, Kad, BitTorrent, MMS, RTMP, RTSP.. au lieu de faire tout ça via le Web, le Web, le Web, le Web, le Web et encore et toujours du Web
Alors qu'on pourrait faire tout ça avec XMPP, XMPP, XMPP, XMPP, XMPP et encore et toujours XMPP
Cependant, ces protocoles dérivés restent des protocoles dédiés à un programme, et non à une tâche. Salut à Toi et Jappix sont deux protocoles dérivés d'XMPP, mais ils ne sont (à ma connaissance extrêmement limitée) compatibles entre eux du point de vue des fonctionnalités relatives au réseau social. Peut-être un jour verra-t-on une une plus grande standardisation entre ces deux (ce n'est qu'un exemple).
Alors petite précision à ce sujet. On est, et on cherche à être compatibles entre nous au sujet de nouvelles fonctionnalités (celle qui me vient principalement en tête est le microblogage); et pour ce on s'appuie sur des XEP qui sont en cour d'élaboration, et qui ne sont donc pas encore des standards (Celle ci pour ceux que ça intéresse). La standardisation et donc la compatibilité entre client est un point important que nous ne voulons pas perdre.
Cependant, les fonctionnalités étant nouvelles, il y a aussi des expérimentation. Buddy Cloud par exemple élabore son propre protocole pour le microblogage. Je les ai rencontré au FOSDEM, ils envisagent la standardisation, mais à terme, le but est de tester avant dans leur coin, et de le proposer si c'est valable.
À ceci s'ajoutent les fonctionnalités qui ne sont pas standards. Salut à Toi par exemple propose la gestion des droits par groupes (ce que Google appelle les cercles, même si ça existait dans SàT avant que G+ ne soit publique). Étant à ma connaissance le seul projet basé sur XMPP à permettre ça (sinon Diaspora permet quelque chose de similaire que eux appellent aspects), ce n'est pas encore un standard. Mais je pense que ça la deviendra à terme. Pour le moment ça utilise une méthode bricolée qui ne fonctionne qu'avec Openfire, il est prévu de revoir ça très rapidement (c'est d'ailleurs ma prochaine chose dans ma TODO) pour que ça fonctionne de manière plus générique.
Donc pour résumer, oui on est standard et on ne fait pas de « sous protocole propriétaire »: le microblogage Jappix (ou MOVIM), est compatible avec celui de SàT.
Par contre il y a des différence sur les terrains expérimentaux, parce que justement c'est expérimental. Mais le but est pour la plupart des projet de standardiser les nouveauté. Seulement le processus de standardisation est long, et changer un protocole a des conséquences, c'est pour ça qu'il peut y avoir des différence entre un projet qui implémente une nouveauté, et la version standard (l'exemple le plus connu est celui de Jingle version Google qui diffère du Jingle standardisé: Google passe à la version standard, mais ça ne se fait pas en un claquement de doigts).
Le problème c'est pour le moment, on ne voit pas grand chose (enfin des parties de, des démos, mais c'est tout)
Si je ne me trompe pas, le site de transport présenté au FOSDEM dont j'ai parlé était en production. C'est aussi très utilisé dans le monde professionnel, ou dans le moteurs de certains sites, mais on ne le voit pas forcément.
Le nom ça a déjà été débattu par ailleurs (XMPP se rapproche de HTTP, jabber c'est plus le réseau global, enfin tout le monde n'est pas d'accord dessus,et perso ça me passe un peu au dessus de la tête). Pour l'audio/vidéo tu as essayé jitsi ? Perso j'ai eu quelques soucis avec, mais sinon c'est le plus prometteur actuellement
Le côté xml, c'est de la guerre de religion du même type que quand on parle de java ou emacs, et pareil ça me passe au dessus de la tête.
Après, pour le côté "microblogage" on va quand même dire que c'est presque de la messagerie, on ne communique pas directement mais à part ça...
À part ça il y a d'autres choses à faire, partage de fichiers par exemple, jeux, tout ce qui fait de la publication/souscription, streaming, etc. Le côté extensible permet d'ajouter n'importe quoi.
Si je ne me trompe, y'a pas aussi un soft pour de la supervision de machines virtuelles basé sur XMPP ?
Oui quelqu'un m'avait parlé d'un truc comme ça aux JDLL, et il y a eu un journal ou une dépêche ici même, là j'ai pas trop le temps de chercher, mais ça doit pas être dur à retrouver.
Ah mais non ne prends pas ça comme une attaque perso, c'est juste une remarque générale (surtout que j'ai déjà lu des articles de toi qui expliquaient que XMPP pouvaient être utilisé pour d'autre choses).
Mais XMPP est quasi systématiquement associé uniquement à messagerie instantanée, ce qui est fort dommage, c'est vraiment ne voir que la partie émergée de l'icerberg: le potentiel est encore très largement sous exploité. J'ai l'impression que c'est même le cas chez pas mal de dévs de la communauté XMPP elle même.
De la même manière, c'est dommage de ne toujours voir que Diaspora comme alternative à facebook, il y en a d'autres plus ou moins avancé, basée sur XMPP ou non, clone de FB et différentes, etc.
quelques ex.: MOVIM, Friendika, Newebe, Lorea, Retroshare, Jappix, etc.
Oui enfin ce que c'était au départ n'est pas vraiment le problème. C'est le extensible qui est important. Et ça coûte cher à XMPP que les gens pensent que ça ne fait que de la messagerie instantanée (exemple: Diaspora veut l'utiliser uniquement pour la messagerie, alors que ça pourrait être entièrement basé dessus).
En même temps, la messagerie de Facebook c'est du XMPP
MSN aussi, non ?
Je n'ai pas dit que ça ne faisait pas de messagerie instantanée, j'ai dit que c'était loin de ne faire que ça.
Ben en même temps, c'est un peu la seule chose qu'on en voit, non ? (et encore, serais-je tenté de dire...)
Euh non. Je ne parle même pas des éventuels projets multi-frontends qu'on peut voir, mais c'est déjà utilisé pour du microblogage, du partage de fichier, des sites de gestion de transport, de la vidéo conf, de l'envoi de sortie de pipe ( :p ), des moteurs de recherche temps réel, synchroniser des favoris, etc. Au FOSDEM par exemple on a pu voir des démonstrations de plusieurs des cas que je viens de citer.
Tu fais aussi confiance à ta distro et à ton butineur quand tu accèdes à ta banques, tu remplaces ces 2 là par les admins et les devs weboob. Dans tous les cas (distro, butineurs, weboob), tu peux vérifier par toi même si le code n'est pas malsain.
je ne suis pas abonné à ton blog (ni sur une adresse ni sur l'autre)
Bref, j'ai été (un peu) ennuyé par ce script qui m'a fait clignoter ton site tous les jours et qui ne traitait pas du sujet qui m'intéressait (XMPP), et je n'ai probablement pas été le seul.
Enfin c'est pas très grave, mais heureusement que tout le monde ne fait pas comme ça (bon en même temps le planet jabberfr est tellement désert en ce moment que ça ferait un peu d’animation).
Moi par exemple j'ai ajouté les touches accentuées françaises sur un clavier qwerty, sans perdre 2 des flêches du pavé directionnel comme sur le clavier officiel.
Il est vraiment grand temps que les clients de messagerie instantané libre soient améliorés pour faire du réseau social, en implémentant certaines extensions xmpp.
Tu sais, on n'est pas contre un coup de main si vous voulez que ça aille plus vite ;)
Ah oui impressionnant celui là, par contre le logiciel ne sera pas open source, et il y aura des brevets sur le matos.
L'avantage du reprap, c'est qu'on peut mettre des tas d'autres têtes: on a parlé du chocolat, mais il y a aussi des têtes pour faire de la découpe laser, de la soudure, des circuit imprimés (au laser aussi si d'après ce que j'ai vu), etc. Je suppose qu'il ne doit pas être beaucoup plus compliqué de faire faire le perçage d'un circuit imprimé au reprap. Ça devient très impressionnant ce qu'on peut faire.
Et toi journal, que partages-tu ou voudrais-tu partager avec tes voisins pour gratter des thunes ?
Un truc que j'ai vu dans plusieurs immeubles en Suisse, et que j'aimerais voir plus souvent: une machine à laver collective (pour l'immeuble, enfin par pour 25 étages non plus).
Y'a les jardins collectifs qui se font aussi.
Dans le même genre une excellente idée que j'ai vu chez quelqu'un qui m'a hébergé en Australie: avoir un seau sous la douche pour récupérer l'eau gaspillée quand on attend qu'elle chauffe. Le seau est ensuite utilisé dans les toilettes. D'ailleurs ça pourrait être généralisé à toute l'eau de la douche qui est à peine usée (et qui l'est avec du savon), et qui pourrait être réutilisée pour la chasse.
C'est pas qu'une question d'économie, c'est une question d'écologie aussi (et ça peut même devenir social dans certains cas). Vive la collectivisation :)
J'ai installé le logiciel, pris 5min pour le configurer et ça a marché. Difficile d'en dire autant avec un couple client/serveur XMPP.
Oui mais tu as déjà déjà des notions d'informatique. Et en plus faut voir les choses en pratique: quelqu'un de non initié utilisera dans un premier temps un serveur XMPP existant, et n'auras qu'à créer un compte comme il fait d'habitude. Avec Retroshare, même pour ne faire qu'esssayer, il y a de la configuration à faire, et ce n'est pas forcément trivial (j'ai essayé avec des gens qui avaient pourtant des notions d'informatique, ça a marché, mais ça a demandé quelques discussions - via jabber :D -, et de la configuration).
Ce n'est pas obligatoire. Retroshare gère des messages/forums/partages de fichiers asynchrones.
Mais ne les stocke pas à l'extérieur, si quelqu'un veut ton fichier à un moment précis (genre la photo d'un album), sa machine et la tienne doivent être allumées en même temps.
il est facile de créer un nouveau client compatible
complexité côté serveur
Ca ne s'applique pas à Retroshare où tout est à la fois client et serveur.
Je parlais de XMPP ici
Pour avoir différent client, XMPP utilise une standardisation sans implémentation de référence, Retroshare une implémentation de référence sans standardisation. Dans les deux cas, il manque quelquechose :-(
Il y a eu des implémentation de base (jabberd), maintenant côté serveur c'est plutôt ejabberd la référence, côté client probablement gajim et psi.
A condition de pouvoir atteindre ton serveur, XMPP a clairement l'avantage. Retroshare se débrouille bien avec les NAT, mais les proxys et firewalls nazis sont beaucoup plus difficiles à passer.
Rien qu'avec BOSH, c'est rare de na pas pouvoir passer un NAT/Firewall. Enfin ça c'est pour la connexion avec le serveur, pour le transfert de fichier ou le P2P, c'est parfois plus complexe (mais ça s'améliore grandement avec Jingle).
Dans tes exemples, la réception est lancée avant l'émission.
Si on ne le fait pas dans cet ordre, ça coince? J'aurais pensé que ça utilise une valeur de "time-out", mais apparemment tu reviens sur l'onglet réception pour le lancer avant.
Non c'est juste que j'ai une petite bricole à implémenter pour récupérer les envois en attente, et que ce n'est pas encore fait, ça sera fait avant la prochaine release.
Autre commentaire: tu dis que Jingle, pour toi, ce ne sera pas tout de suite. Pourtant, si SàT devait percer dans le grand public, ce serait un des principaux goulots d'étranglement à mon humble avis (qui n'est pas parole sacrée non plus hein!).
J'ai envie aussi de l'implémenter le plus vite possible, mais c'est un boulot vraiment considérable, et je suis seul pour le moment sur le dév, et j'ai d'autre priorités; mais ça viendra. Pour l'instant je vais me concentrer un temps sur l'interface web pour permettre de tester facilement et peut être de monter une équipe plus facilement. Mais j'ai d'autres fonctionnalités prévues à plus court terme qui devraient, AMHA, ps mal plaire.
Bon j'ai lu ton billet. J'ai déjà en projet d'implémenter une idée plus ou moins similaire à ce que tu présentes pour le chiffrement de bout en bout des fichiers, mais pas tout de suite tout de suite.
Maintenant pour revenir à ces histoire de décentralisé et de P2P. J'ai testé Retroshare, et j'aime beaucoup, seulement il a plusieurs défaut:
il est tout sauf user friendly, déjà échanger une clé GPG, tu oublies avec la plupart des gens (et encore moins quelqu'un que tu viens de rencontrer dans une soirée ou dans la rue)
le problème que tu cites est majeur: obligation de laisser les machines allumées, c'est impossible pour qui voyage un minimum (ta solution avec un stockage tiers est un peu du bricolage, c'est sympa mais par pour mr tout le monde)
une des raisons qui m'ont fait choisir XMPP, c'est que c'est un standard avant tout, ça veut dire qu'il est facile de créer un nouveau client compatible. En plus de ça, les concepts de base sont très bien pensés (extensibles, complexité côté serveur, fonctionnement de base simple est intuitif, etc). Est-ce que c'est le cas pour Retroshare (je n'en sais rien, c'est une vraie question) ? Parce qu'être dépendant d'une seule implémentation, c'est du suicide.
Le 100 % P2P (sans serveur intermédiaire) induit des difficultés notamment de routage des informations, qui se traduisent souvent par des lenteurs ou des lourdeurs des communications, ou des problèmes pour retrouver les IP des contacts. Sans parler des firewalls et autres joyeusetés dans les lieux publics ou autre. XMPP a une bonne solution intermédiaire en étant décentralisé avec des serveurs, et chiffrement en C2S (Client 2 Servers) et S2S (Server 2 Server), et peut - en prime - être étendu pour fonctionner sans serveur.
D'ailleurs c'est marrant, j'ai l'impression d'y voir le même débat qu'entre les microkernels et le kernel modulaire. Ceci dit encore une fois j'aime bien Retroshare, et je suis partisan de la décentralisation à fond, et donc du 100% P2P, jusque que je pense que XMPP est un meilleur compromis pour le moment, ça changera peut être dans le futur.
Si j'ai bien compris, SàT est à la base un démon qui fait client XMPP, sur lequel se connectent des backends (un mot Français pour traduire ça??) variés.
Presque, ce sont des frontends (interfaces) qui se connectent, et le démon est le backend
SàT ne serait donc pas un projet destiné à apporter à XMPP les fonctionnalités haut niveau que tu souhaitais et qui n'étaient pas implémentées de base?
Non, c'est bel est bien un client. Tu pourrais remplacer le couple démon/D-Bus par bibliothèque ça reviendrait au même.
Un serveur XMPP communique avec un client de manière faite pour le réseau, alors que le démon communique avec les interfaces en se considérant en local (même si ce serait techniquement possible d'avoir des interfaces à distance, mais c'est une autre histoire), des messages sont envoyés en permanence pour D-Bus, des signaux pour le moindre texte envoyé ou reçu. Le démon gère des choses qui n'ont rien à voir avec XMPP: par exemple les plugins peuvent fournir des UI génériques aux frontends, j'ai un plugin qui permet de lire/envoyer des messages couchsurfing, ou de se créer des serveurs IMAP/SMTP, ce n'est pas du tout le rôle du serveur XMPP de faire tout ça.
Pareil, le démon gère le stockage et la manipulation de l'historique, ou de ton roster.
SàT ne serait donc pas un projet destiné à apporter à XMPP les fonctionnalités haut niveau que tu souhaitais et qui n'étaient pas implémentées de base?
Les fonctionnalités que je désire et qui ne sont pas implémentées de base dans le serveur, c'est via des extensions au protocoles (des XEPs) que je les implémenterai (modulo la XEP est validée).
SàT est vraiment un client, il a juste une séparation forte entre la vue et le métier, ou entre la vue et le couple modèle/contrôleur dans un modèle MVC.
Parce que, par exemple, avoir la même conversation qui s'affiche partout, ça devrait être d'office dans XMPP (c'est le comportement qui me semblerait logique en mettant la même priorité à plusieurs clients en même temps ; mais bon, la logique, ça peut être subjectif...).
Une priorité positive égale ça pourrait envoyer (selon le serveur, ce n'est pas défini dans la RFC) à tous les clients connectés les messages que tu envoies, bref ce n'est pas ce qui se passe avec les interfaces de SàT. Mais ce n'est de toute façon pas le rôle du serveur de gérer ton historique. Par contre on peut envisager une XEP de synchronisation d'historique entre les clients (il me semblait qu'il y en avait une, mais en regardant apparemment de n'est pas le cas(*)).
Après, les jeux de Quiz, tout ça, c'est vrai que ça relève peut-être plus du client que du serveur, mais ça devrait pouvoir se faire de façon "générique": programmation en XMPP? On devrait avoir un environnement, une bibliothèque de fonctions haut niveau permettant de décrire un jeu, et pourquoi pas entrer ça dans des fichiers stockés sur le serveur qu'on télécharge dans le client XMPP.
J'aimerais bien proposer tout ça oui. Dans un premier temps une XEP générique pour les jeux de cartes, mais ça sera bon pour fournir un moyen de discuter et se mettre d'accord sur la gestion des règles, par pour tout le côté gestion du code du jeu. Après on peut aller jusqu'à faire un langage de description des jeux, on s'éloigne un peu de l'idée de base de XMPP que la complexité est côté serveur, mais c'est une possibilité que j'ai déjà envisagée (mais bon, y'a d'autres priorités pour le moment).
Bref! SàT peut-il être considéré comme une sur-couche haut niveau à XMPP que tu as choisi de séparer dans un démon?
Au final tu considères ça comme tu veux, ce n'est pas très important à mon sens :). Ce qui est important, c'est de garder une compatibilité avec les autres clients, et bien sûr de suivre tout le reste (être libre, protéger l'utilisateur, etc. Bref Le contrat social).
(*) Bon ben sur jabberfr on m'a redonné le numéro: la XEP-0136
Du coup ça fait sauter la protection offerte par les serveurs, mais tu as encore le chiffrement de bout en bout via GPG ou OTR, c'est d'ailleurs leur raison d'être un canal de communication dans lequel tu n'as pas confiance.
[^] # Re: Protocole et format de merde.
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Plus intéressant qu'Apple : Mozilla sort Collusion. Évalué à 5.
Le merdier avec IRC on n'imagine pas non, c'est pour ça qu'on les implémente avec XMPP: http://www.goffi.org/post/2012/02/02/Radio-collective
Alors qu'on pourrait faire tout ça avec XMPP, XMPP, XMPP, XMPP, XMPP et encore et toujours XMPP
:)
[^] # Re: Oublis
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Les journaux LinuxFr.org les mieux notés de la semaine 07/2012. Évalué à 6.
Faudrait utiliser weboob pour filter les journaux et rédiger automatiquement la dépêche touts les semaines :)
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal APPEL POUR ACTION : LES BOOBS ONT BESOIN DE VOUS *MAINTENANT*. Évalué à 4.
Alors petite précision à ce sujet. On est, et on cherche à être compatibles entre nous au sujet de nouvelles fonctionnalités (celle qui me vient principalement en tête est le microblogage); et pour ce on s'appuie sur des XEP qui sont en cour d'élaboration, et qui ne sont donc pas encore des standards (Celle ci pour ceux que ça intéresse). La standardisation et donc la compatibilité entre client est un point important que nous ne voulons pas perdre.
Cependant, les fonctionnalités étant nouvelles, il y a aussi des expérimentation. Buddy Cloud par exemple élabore son propre protocole pour le microblogage. Je les ai rencontré au FOSDEM, ils envisagent la standardisation, mais à terme, le but est de tester avant dans leur coin, et de le proposer si c'est valable.
À ceci s'ajoutent les fonctionnalités qui ne sont pas standards. Salut à Toi par exemple propose la gestion des droits par groupes (ce que Google appelle les cercles, même si ça existait dans SàT avant que G+ ne soit publique). Étant à ma connaissance le seul projet basé sur XMPP à permettre ça (sinon Diaspora permet quelque chose de similaire que eux appellent aspects), ce n'est pas encore un standard. Mais je pense que ça la deviendra à terme. Pour le moment ça utilise une méthode bricolée qui ne fonctionne qu'avec Openfire, il est prévu de revoir ça très rapidement (c'est d'ailleurs ma prochaine chose dans ma TODO) pour que ça fonctionne de manière plus générique.
Donc pour résumer, oui on est standard et on ne fait pas de « sous protocole propriétaire »: le microblogage Jappix (ou MOVIM), est compatible avec celui de SàT.
Par contre il y a des différence sur les terrains expérimentaux, parce que justement c'est expérimental. Mais le but est pour la plupart des projet de standardiser les nouveauté. Seulement le processus de standardisation est long, et changer un protocole a des conséquences, c'est pour ça qu'il peut y avoir des différence entre un projet qui implémente une nouveauté, et la version standard (l'exemple le plus connu est celui de Jingle version Google qui diffère du Jingle standardisé: Google passe à la version standard, mais ça ne se fait pas en un claquement de doigts).
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Un internet complètement décentralisé. Évalué à 2.
il faut parcourir les extensions ici: http://xmpp.org/xmpp-protocols/xmpp-extensions/
et on peut t'aider sur xmpp://jabberfr@chat.jabberfr.org ou sur une des mailing lists de la xsf
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Un internet complètement décentralisé. Évalué à 2.
Si je ne me trompe pas, le site de transport présenté au FOSDEM dont j'ai parlé était en production. C'est aussi très utilisé dans le monde professionnel, ou dans le moteurs de certains sites, mais on ne le voit pas forcément.
Le nom ça a déjà été débattu par ailleurs (XMPP se rapproche de HTTP, jabber c'est plus le réseau global, enfin tout le monde n'est pas d'accord dessus,et perso ça me passe un peu au dessus de la tête). Pour l'audio/vidéo tu as essayé jitsi ? Perso j'ai eu quelques soucis avec, mais sinon c'est le plus prometteur actuellement
Le côté xml, c'est de la guerre de religion du même type que quand on parle de java ou emacs, et pareil ça me passe au dessus de la tête.
À part ça il y a d'autres choses à faire, partage de fichiers par exemple, jeux, tout ce qui fait de la publication/souscription, streaming, etc. Le côté extensible permet d'ajouter n'importe quoi.
Oui quelqu'un m'avait parlé d'un truc comme ça aux JDLL, et il y a eu un journal ou une dépêche ici même, là j'ai pas trop le temps de chercher, mais ça doit pas être dur à retrouver.
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Un internet complètement décentralisé. Évalué à 3.
Ah mais non ne prends pas ça comme une attaque perso, c'est juste une remarque générale (surtout que j'ai déjà lu des articles de toi qui expliquaient que XMPP pouvaient être utilisé pour d'autre choses).
Mais XMPP est quasi systématiquement associé uniquement à messagerie instantanée, ce qui est fort dommage, c'est vraiment ne voir que la partie émergée de l'icerberg: le potentiel est encore très largement sous exploité. J'ai l'impression que c'est même le cas chez pas mal de dévs de la communauté XMPP elle même.
De la même manière, c'est dommage de ne toujours voir que Diaspora comme alternative à facebook, il y en a d'autres plus ou moins avancé, basée sur XMPP ou non, clone de FB et différentes, etc.
quelques ex.: MOVIM, Friendika, Newebe, Lorea, Retroshare, Jappix, etc.
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Un internet complètement décentralisé. Évalué à 2.
Oui enfin ce que c'était au départ n'est pas vraiment le problème. C'est le extensible qui est important. Et ça coûte cher à XMPP que les gens pensent que ça ne fait que de la messagerie instantanée (exemple: Diaspora veut l'utiliser uniquement pour la messagerie, alors que ça pourrait être entièrement basé dessus).
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Un internet complètement décentralisé. Évalué à 2.
Je n'ai pas dit que ça ne faisait pas de messagerie instantanée, j'ai dit que c'était loin de ne faire que ça.
Euh non. Je ne parle même pas des éventuels projets multi-frontends qu'on peut voir, mais c'est déjà utilisé pour du microblogage, du partage de fichier, des sites de gestion de transport, de la vidéo conf, de l'envoi de sortie de pipe ( :p ), des moteurs de recherche temps réel, synchroniser des favoris, etc. Au FOSDEM par exemple on a pu voir des démonstrations de plusieurs des cas que je viens de citer.
# XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Un internet complètement décentralisé. Évalué à 3.
XMPP remplace ICQ, MSN, Twitter, Facebook, etc...
Faut arrêter de n'associer XMPP qu'à la messagerie instantanée...
bon maintenant je vais lire la suite :)
[^] # Re: parodie forfait internet segmenté CDKEY
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Si même les gens normaux s'en rendent compte !. Évalué à 10.
C'est quand qu'on se faire un flashmob pour coller ça dans le métro ?
[^] # Re: Sécurité des backends
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Le Weboob nouveau est arrivé. Évalué à 5.
Tu fais aussi confiance à ta distro et à ton butineur quand tu accèdes à ta banques, tu remplaces ces 2 là par les admins et les devs weboob. Dans tous les cas (distro, butineurs, weboob), tu peux vérifier par toi même si le code n'est pas malsain.
# Copyleft
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Nouvelle version d'Unicode : la 6.1.0. Évalué à 8.
Et toujours pas de symbole copyleft :(
# Informaticiens
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Openpom 1.5.0. Évalué à 2.
Je ne vois pas pourquoi on dit que les informaticiens sont incompréhensibles, vraiment...
# planet JabberFr
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Migration d'URL et noyade sous l'information. Évalué à 2.
Juste pour info:
Bref, j'ai été (un peu) ennuyé par ce script qui m'a fait clignoter ton site tous les jours et qui ne traitait pas du sujet qui m'intéressait (XMPP), et je n'ai probablement pas été le seul.
Enfin c'est pas très grave, mais heureusement que tout le monde ne fait pas comme ça (bon en même temps le planet jabberfr est tellement désert en ce moment que ça ferait un peu d’animation).
[^] # Re: MaVie - N900
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Le téléphone portable idéal du libriste. Évalué à 2.
Tu peux réaffecter les touches du clavier: http://wiki.maemo.org/Remapping_keyboard
Moi par exemple j'ai ajouté les touches accentuées françaises sur un clavier qwerty, sans perdre 2 des flêches du pavé directionnel comme sur le clavier officiel.
PS: j'envisage un port de Salut à Toi sur le n900
[^] # Re: xmpp
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Twitter et les politiques de censure.. Évalué à 6.
Tu sais, on n'est pas contre un coup de main si vous voulez que ça aille plus vite ;)
[^] # Re: autre projet plus prometteur (amha)
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche La frénésie des imprimantes 3D. Évalué à 6.
Ah oui impressionnant celui là, par contre le logiciel ne sera pas open source, et il y aura des brevets sur le matos.
L'avantage du reprap, c'est qu'on peut mettre des tas d'autres têtes: on a parlé du chocolat, mais il y a aussi des têtes pour faire de la découpe laser, de la soudure, des circuit imprimés (au laser aussi si d'après ce que j'ai vu), etc. Je suppose qu'il ne doit pas être beaucoup plus compliqué de faire faire le perçage d'un circuit imprimé au reprap. Ça devient très impressionnant ce qu'on peut faire.
[^] # Re: Journal—Mutualiser ses abonnements en logement collectif
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mutualiser ses abonnements en logement collectif. Évalué à 3.
arf, tu m'as grillé de 3 min pour le même commentaire ;). Comme quoi, c'est le genre d'idée qui pourrait être populaire.
# Reprendre les bonnes idées
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mutualiser ses abonnements en logement collectif. Évalué à 6.
Un truc que j'ai vu dans plusieurs immeubles en Suisse, et que j'aimerais voir plus souvent: une machine à laver collective (pour l'immeuble, enfin par pour 25 étages non plus).
Y'a les jardins collectifs qui se font aussi.
Dans le même genre une excellente idée que j'ai vu chez quelqu'un qui m'a hébergé en Australie: avoir un seau sous la douche pour récupérer l'eau gaspillée quand on attend qu'elle chauffe. Le seau est ensuite utilisé dans les toilettes. D'ailleurs ça pourrait être généralisé à toute l'eau de la douche qui est à peine usée (et qui l'est avec du savon), et qui pourrait être réutilisée pour la chasse.
C'est pas qu'une question d'économie, c'est une question d'écologie aussi (et ça peut même devenir social dans certains cas). Vive la collectivisation :)
# Ah ah
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 10.
Ah ah ah ah. Tu t'es trompé de site (et de sujet) ;)
[^] # Re: réseau social libre
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 2.
Oui mais tu as déjà déjà des notions d'informatique. Et en plus faut voir les choses en pratique: quelqu'un de non initié utilisera dans un premier temps un serveur XMPP existant, et n'auras qu'à créer un compte comme il fait d'habitude. Avec Retroshare, même pour ne faire qu'esssayer, il y a de la configuration à faire, et ce n'est pas forcément trivial (j'ai essayé avec des gens qui avaient pourtant des notions d'informatique, ça a marché, mais ça a demandé quelques discussions - via jabber :D -, et de la configuration).
Mais ne les stocke pas à l'extérieur, si quelqu'un veut ton fichier à un moment précis (genre la photo d'un album), sa machine et la tienne doivent être allumées en même temps.
Je parlais de XMPP ici
Il y a eu des implémentation de base (jabberd), maintenant côté serveur c'est plutôt ejabberd la référence, côté client probablement gajim et psi.
Rien qu'avec BOSH, c'est rare de na pas pouvoir passer un NAT/Firewall. Enfin ça c'est pour la connexion avec le serveur, pour le transfert de fichier ou le P2P, c'est parfois plus complexe (mais ça s'améliore grandement avec Jingle).
[^] # Re: Le "pipe": ça tue!
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 2.
Non c'est juste que j'ai une petite bricole à implémenter pour récupérer les envois en attente, et que ce n'est pas encore fait, ça sera fait avant la prochaine release.
J'ai envie aussi de l'implémenter le plus vite possible, mais c'est un boulot vraiment considérable, et je suis seul pour le moment sur le dév, et j'ai d'autre priorités; mais ça viendra. Pour l'instant je vais me concentrer un temps sur l'interface web pour permettre de tester facilement et peut être de monter une équipe plus facilement. Mais j'ai d'autres fonctionnalités prévues à plus court terme qui devraient, AMHA, ps mal plaire.
[^] # Re: réseau social libre
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 4.
Bon j'ai lu ton billet. J'ai déjà en projet d'implémenter une idée plus ou moins similaire à ce que tu présentes pour le chiffrement de bout en bout des fichiers, mais pas tout de suite tout de suite.
Maintenant pour revenir à ces histoire de décentralisé et de P2P. J'ai testé Retroshare, et j'aime beaucoup, seulement il a plusieurs défaut:
il est tout sauf user friendly, déjà échanger une clé GPG, tu oublies avec la plupart des gens (et encore moins quelqu'un que tu viens de rencontrer dans une soirée ou dans la rue)
le problème que tu cites est majeur: obligation de laisser les machines allumées, c'est impossible pour qui voyage un minimum (ta solution avec un stockage tiers est un peu du bricolage, c'est sympa mais par pour mr tout le monde)
une des raisons qui m'ont fait choisir XMPP, c'est que c'est un standard avant tout, ça veut dire qu'il est facile de créer un nouveau client compatible. En plus de ça, les concepts de base sont très bien pensés (extensibles, complexité côté serveur, fonctionnement de base simple est intuitif, etc). Est-ce que c'est le cas pour Retroshare (je n'en sais rien, c'est une vraie question) ? Parce qu'être dépendant d'une seule implémentation, c'est du suicide.
Le 100 % P2P (sans serveur intermédiaire) induit des difficultés notamment de routage des informations, qui se traduisent souvent par des lenteurs ou des lourdeurs des communications, ou des problèmes pour retrouver les IP des contacts. Sans parler des firewalls et autres joyeusetés dans les lieux publics ou autre. XMPP a une bonne solution intermédiaire en étant décentralisé avec des serveurs, et chiffrement en C2S (Client 2 Servers) et S2S (Server 2 Server), et peut - en prime - être étendu pour fonctionner sans serveur.
D'ailleurs c'est marrant, j'ai l'impression d'y voir le même débat qu'entre les microkernels et le kernel modulaire. Ceci dit encore une fois j'aime bien Retroshare, et je suis partisan de la décentralisation à fond, et donc du 100% P2P, jusque que je pense que XMPP est un meilleur compromis pour le moment, ça changera peut être dans le futur.
[^] # Re: Un serveur client d'un autre serveur...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 3.
Presque, ce sont des frontends (interfaces) qui se connectent, et le démon est le backend
Non, c'est bel est bien un client. Tu pourrais remplacer le couple démon/D-Bus par bibliothèque ça reviendrait au même.
Un serveur XMPP communique avec un client de manière faite pour le réseau, alors que le démon communique avec les interfaces en se considérant en local (même si ce serait techniquement possible d'avoir des interfaces à distance, mais c'est une autre histoire), des messages sont envoyés en permanence pour D-Bus, des signaux pour le moindre texte envoyé ou reçu. Le démon gère des choses qui n'ont rien à voir avec XMPP: par exemple les plugins peuvent fournir des UI génériques aux frontends, j'ai un plugin qui permet de lire/envoyer des messages couchsurfing, ou de se créer des serveurs IMAP/SMTP, ce n'est pas du tout le rôle du serveur XMPP de faire tout ça.
Pareil, le démon gère le stockage et la manipulation de l'historique, ou de ton roster.
Les fonctionnalités que je désire et qui ne sont pas implémentées de base dans le serveur, c'est via des extensions au protocoles (des XEPs) que je les implémenterai (modulo la XEP est validée).
SàT est vraiment un client, il a juste une séparation forte entre la vue et le métier, ou entre la vue et le couple modèle/contrôleur dans un modèle MVC.
Une priorité positive égale ça pourrait envoyer (selon le serveur, ce n'est pas défini dans la RFC) à tous les clients connectés les messages que tu envoies, bref ce n'est pas ce qui se passe avec les interfaces de SàT. Mais ce n'est de toute façon pas le rôle du serveur de gérer ton historique. Par contre on peut envisager une XEP de synchronisation d'historique entre les clients (il me semblait qu'il y en avait une, mais en regardant apparemment de n'est pas le cas(*)).
J'aimerais bien proposer tout ça oui. Dans un premier temps une XEP générique pour les jeux de cartes, mais ça sera bon pour fournir un moyen de discuter et se mettre d'accord sur la gestion des règles, par pour tout le côté gestion du code du jeu. Après on peut aller jusqu'à faire un langage de description des jeux, on s'éloigne un peu de l'idée de base de XMPP que la complexité est côté serveur, mais c'est une possibilité que j'ai déjà envisagée (mais bon, y'a d'autres priorités pour le moment).
Au final tu considères ça comme tu veux, ce n'est pas très important à mon sens :). Ce qui est important, c'est de garder une compatibilité avec les autres clients, et bien sûr de suivre tout le reste (être libre, protéger l'utilisateur, etc. Bref Le contrat social).
(*) Bon ben sur jabberfr on m'a redonné le numéro: la XEP-0136
[^] # Re: réseau social libre
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 4.
Du coup ça fait sauter la protection offerte par les serveurs, mais tu as encore le chiffrement de bout en bout via GPG ou OTR, c'est d'ailleurs leur raison d'être un canal de communication dans lequel tu n'as pas confiance.