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.
XMPP décentralisé tel qu'on le voit actuellement, c'est quelques serveurs gérés par des geeks qui hébergent les comptes de quelques personnes proches (bureau, amis, asso...). Le fait que les admins de ces serveurs ait un contrôle total sur les comptes (données, relations, mot de passe) pose quand même soucis dans le cas d'une généralisation du principe. Confierez vous l'hébergement et le transfert de vos photos coquines à votre ami geek?
Si tu n'as pas confiances, tu changes de serveur, ou mieux tu montes le tiens propre.
Et c'est la raison pour laquelle le chiffrage de bout en bout est dans les priorité: pour que même les administrateur du serveur ne puissent savoir le contenu de ce que tu échanges (mais pas contre, ils sauront avec qui tu l'échanges).
Certes, on peut chiffrer de bout en bout mais ca ne protège pas de l'usurpation d'identité et quid des messages hors ligne?
Le chiffrage permet aussi de vérifier l'identité, et c'est aussi géré de manière native en XMPP (par les serveurs), contrairement au réseau courriel traditionnel par exemple. Je ne vois pas le problème à chiffrer un message hors ligne.
Là je n'ai pas trop le temps de lire ton billet, mais j'y jetterai un œil ce soir
Ce qui le rend plus difficile à comprendre c'est que:
il se concentre pas uniquement sur la messagerie instantanée, parce XMPP ne fait pas que ça. Tu peux faire comme dit dans l'entretien des choses comme du partage de fichier, communiquer avec le réseau courriel traditionnel, ou (bientôt) organiser des évenements
et
il est multi-interfaces. Donc tu peux avoir un site web à la Jappix, MOVIM, ou comme le truc tout bleu ou le truc avec un +, mais aussi un client de bureau à la gajim ou psi, un truc texte à la Poezio, de la ligne de commande, etc. Mais ça reste un même client.
je faisais pas mal de Python, et je ne voulais pas perdre la main en C++
je voulais montrer qu'on peut faire une interface en autre chose que Python
Ça faisait longtemps que ça me démangeais de me mettre à Qt, notamment parce que je suis KDEiste, et que je peux vouloir patcher une appli KDE un jour, et C++ est son langage de prédilection.
SàT est un client XMPP au même titre que Gajim ou Psi. Ce qui le rend plus difficile à comprendre c'est que:
il se concentre pas uniquement sur la messagerie instantanée, parce XMPP ne fait pas que ça. Tu peux faire comme dit dans l'entretien des choses comme du partage de fichier, communiquer avec le réseau courriel traditionnel, ou (bientôt) organiser des évenements
OpenStreetMap peut être utilisé à plusieurs niveau dans un client XMPP. Dans un premier temps, il sera utilisé pour l'organisation d’événements: pointer l'endroit d'un rendez-vous par exemple.
XSF c'est la XMPP Software Foundation, la fondation qui gère l'évolution du protocole XMPP, je t'invite à lire la page wikipédia ou le wiki de jabberfr pour plus d'infos.
Jingle c'est une extension au protocole XMPP, qui permet de faire des sessions Peer 2 Peer. C'est notamment utilisé pour les vidéo conférences, mais pas seulement (on peut s'en servir pour transférer des fichiers, ou n'importe quelles données en fait).
PubSub c'est pour Publish/Subscribe, publications/inscriptions. Si tu fais du développement, c'est comme un pattern observeur/observable en beaucoup plus puissant. En gros ça permet d'émettre des infos, et à des gens de s'abonner à ces informations, mais avec gestion de droits et tout. Un flux RSS/Atom fait ça, sauf que là on parle d'un truc beaucoup plus générique, et bien plus puissant. Tu peux par exemple t'en servir pour transmettre une arborescence de fichiers à copier
Mais c'est vrai que tous ces termes ne sont pas évidents à comprendre, un glossaire ne serait pas de trop.
Principalement parce que je voulais apprendre Twisted et me perfectionner en Python. Telepathy existait quand j'ai commencé (mais n'était pas encore aussi populaire), et j'y ai songé un temps mais j'ai rapidement écarté.
Ensuite je voulais me focaliser sur XMPP, et ce n'est qu'une partie de Telepathy. Certes qui peut le plus peut le moins, mais ça voulait dire un risque que l'architecture soit parfois plus générique que ne l'aurait été un framework purement XMPP (mais je ne connais pas l'archi de Telepathy, donc peut être que je me trompe).
Corrige moi si je me trompe, mais Telepathy permet de faire des clients séparés tandis que SàT est un seul et même client.(tout est commun: l'historique, les paramètres, les profils, les plugins, etc).
Enfin, en plus du côté « je voulais apprendre Twisted », ça me permet aussi d'orienter le projet vraiment comme je le souhaite, et de bien connaître son fonctionnement. Par exemple avec SàT, je peux remplacer D-Bus par un autre IPC de manière quasi transparente (le code D-Bus est généré depuis un fichier .ini, et le reste de l'appli n'a pas vraiment « conscience » de parler avec du D-Bus, il me suffit de modifier le générateur pour gérer un autre IPC), est-ce que c'est possible avec Telepathy ?
Euh... Et SàT qui se fait un peu systématiquement oublier (pourtant DLFP est un des seuls site où j'en parle régulièrement). Là où c'est fort, c'est qu'edhelas et moi avons fait nos conférences à la suite aux JDLL, et Jappix et SàT étaient voisins aux RMLL.
Oui enfin sauf que dans 1984, ce qui permet de changer les versions historiques des faits en permanence, c'est la centralisation poussée à l'extrême (et le fait que les anciennes versions deviennent illégales).
Wikipédia a un historique, et chacun peut copier la base et vérifier qu'elle n'a pas été modifiée entre temps; et comme pointé dans un autre commentaire, le transfert peut être sécurisé. Bref le modèle de 1984 est inapplicable à Wikipédia.
Bref, et au contraire justement, Wikipédia a un modèle qui permet d'éviter, ou au moins de limiter les modifications historiques, ou les zones d'ombres que l'on observe parfois dans les encyclopédies classiques ou les manuels scolaires.
Et en plus Wikipédia cite ses sources la plupart du temps (et si elles manquent c'est indiqué).
[^] # 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.
[^] # 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é à 3.
Si tu n'as pas confiances, tu changes de serveur, ou mieux tu montes le tiens propre.
Et c'est la raison pour laquelle le chiffrage de bout en bout est dans les priorité: pour que même les administrateur du serveur ne puissent savoir le contenu de ce que tu échanges (mais pas contre, ils sauront avec qui tu l'échanges).
Le chiffrage permet aussi de vérifier l'identité, et c'est aussi géré de manière native en XMPP (par les serveurs), contrairement au réseau courriel traditionnel par exemple. Je ne vois pas le problème à chiffrer un message hors ligne.
Là je n'ai pas trop le temps de lire ton billet, mais j'y jetterai un œil ce soir
[^] # Re: Je suis perdu !
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é à 6.
oups, dsl il manquait une partie:
Ce qui le rend plus difficile à comprendre c'est que:
et
voilà, après je détaillais les termes demandés :)
[^] # Re: Bellaciao
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é à 6.
Merci :)
L'interface en C++ c'est pour plusieurs raisons:
je faisais pas mal de Python, et je ne voulais pas perdre la main en C++
je voulais montrer qu'on peut faire une interface en autre chose que Python
Ça faisait longtemps que ça me démangeais de me mettre à Qt, notamment parce que je suis KDEiste, et que je peux vouloir patcher une appli KDE un jour, et C++ est son langage de prédilection.
[^] # Re: Je suis perdu !
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é à 10.
SàT est un client XMPP au même titre que Gajim ou Psi. Ce qui le rend plus difficile à comprendre c'est que:
il se concentre pas uniquement sur la messagerie instantanée, parce XMPP ne fait pas que ça. Tu peux faire comme dit dans l'entretien des choses comme du partage de fichier, communiquer avec le réseau courriel traditionnel, ou (bientôt) organiser des évenements
OpenStreetMap peut être utilisé à plusieurs niveau dans un client XMPP. Dans un premier temps, il sera utilisé pour l'organisation d’événements: pointer l'endroit d'un rendez-vous par exemple.
XSF c'est la XMPP Software Foundation, la fondation qui gère l'évolution du protocole XMPP, je t'invite à lire la page wikipédia ou le wiki de jabberfr pour plus d'infos.
Jingle c'est une extension au protocole XMPP, qui permet de faire des sessions Peer 2 Peer. C'est notamment utilisé pour les vidéo conférences, mais pas seulement (on peut s'en servir pour transférer des fichiers, ou n'importe quelles données en fait).
PubSub c'est pour Publish/Subscribe, publications/inscriptions. Si tu fais du développement, c'est comme un pattern observeur/observable en beaucoup plus puissant. En gros ça permet d'émettre des infos, et à des gens de s'abonner à ces informations, mais avec gestion de droits et tout. Un flux RSS/Atom fait ça, sauf que là on parle d'un truc beaucoup plus générique, et bien plus puissant. Tu peux par exemple t'en servir pour transmettre une arborescence de fichiers à copier
Mais c'est vrai que tous ces termes ne sont pas évidents à comprendre, un glossaire ne serait pas de trop.
[^] # Re: SàT
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Movim. Évalué à 3.
Principalement parce que je voulais apprendre Twisted et me perfectionner en Python. Telepathy existait quand j'ai commencé (mais n'était pas encore aussi populaire), et j'y ai songé un temps mais j'ai rapidement écarté.
Ensuite je voulais me focaliser sur XMPP, et ce n'est qu'une partie de Telepathy. Certes qui peut le plus peut le moins, mais ça voulait dire un risque que l'architecture soit parfois plus générique que ne l'aurait été un framework purement XMPP (mais je ne connais pas l'archi de Telepathy, donc peut être que je me trompe).
Corrige moi si je me trompe, mais Telepathy permet de faire des clients séparés tandis que SàT est un seul et même client.(tout est commun: l'historique, les paramètres, les profils, les plugins, etc).
Enfin, en plus du côté « je voulais apprendre Twisted », ça me permet aussi d'orienter le projet vraiment comme je le souhaite, et de bien connaître son fonctionnement. Par exemple avec SàT, je peux remplacer D-Bus par un autre IPC de manière quasi transparente (le code D-Bus est généré depuis un fichier .ini, et le reste de l'appli n'a pas vraiment « conscience » de parler avec du D-Bus, il me suffit de modifier le générateur pour gérer un autre IPC), est-ce que c'est possible avec Telepathy ?
[^] # Re: Mmmmh...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Movim. Évalué à 7.
Euh... Et SàT qui se fait un peu systématiquement oublier (pourtant DLFP est un des seuls site où j'en parle régulièrement). Là où c'est fort, c'est qu'edhelas et moi avons fait nos conférences à la suite aux JDLL, et Jappix et SàT étaient voisins aux RMLL.
[^] # Re: 1984 et Wikipedia
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal La mort de Knol est annoncée. Évalué à 8.
Oui enfin sauf que dans 1984, ce qui permet de changer les versions historiques des faits en permanence, c'est la centralisation poussée à l'extrême (et le fait que les anciennes versions deviennent illégales).
Wikipédia a un historique, et chacun peut copier la base et vérifier qu'elle n'a pas été modifiée entre temps; et comme pointé dans un autre commentaire, le transfert peut être sécurisé. Bref le modèle de 1984 est inapplicable à Wikipédia.
Bref, et au contraire justement, Wikipédia a un modèle qui permet d'éviter, ou au moins de limiter les modifications historiques, ou les zones d'ombres que l'on observe parfois dans les encyclopédies classiques ou les manuels scolaires.
Et en plus Wikipédia cite ses sources la plupart du temps (et si elles manquent c'est indiqué).