Goffi est un visiteur assidu de LinuxFr.org, mais saviez-vous qu'il développe la constellation de logicels « Salut à Toi » ? Savez-vous ce que c'est ?
LinuxFR.org : T'es qui toi ?
Sur le papier : Jérôme Poisson, aka Goffi
En pratique : difficile de se décrire. Disons que j'aime l'informatique depuis tout petit, plus pour le côté « ouah on peut faire des choses avec » que pour le côté « geek ». J'aime voyager - et surtout les rencontres qui vont avec - refaire le monde toute la nuit autour d'une bonne bière, la politique, les cultures et pensées alternatives.
LinuxFR.org : C'est quoi SàT ? Qu'est-ce que ça fait, et comment ?
C'est un client XMPP. Dit comme cela, ça fait peur (enfin peut être pas sur DLFP, mais chez les gens avec moins de barbe, c'est le cas). En gros c'est un logiciel de communication Libre, Décentralisé, Fédéré et Standard.
Ça permet de faire des tas de choses : de la messagerie - instantanée ou « lourde » -, du partage de fichiers, des jeux, du microblogage (ou du blogage moins micro), de l'organisation d'évènements, etc. Il y a certaines choses qui ne sont pas encore faisables au moment où j'écris, comme l'organisation d'évènements, mais c'est prévu assez rapidement.
Une des grosses particularités de SàT est qu'il est multi-interfaces. En clair, le cœur du logiciel est dans un démon, et on peut utiliser des interfaces diverses vraiment adaptées à un cas particulier : pour le moment il en existe :
- une de bureau (Wix, basée sur WxWidget),
- une en console (Primitivus),
- une en ligne de commande (jp),
- une web (Libervia),
- et j'en ai commencé une autre de bureau en Qt (Bellaciao) qui est encore au stade embryonnaire.
On peut imaginer des interfaces adaptées à un petit écran, ou à des handicaps (j'aimerais faire une interface pour aveugles), ou à n'importe quoi.
Tout ça forme un seul et même client, ce qui signifie un historique commun, des profils et paramètres communs etc. Une phrase tapée apparaît sur toutes les interfaces en même temps, on peut ainsi commencer une discussion sur Wix, le fermer et utiliser Primitivus pour la finir.
LinuxFR.org : C'est sous quelle(s) licence(s) ?
Le cœur et la plupart des interfaces sont en GPL v3, l'interface Web (Libervia) est en AGPL v3, les widgets que j'ai faits pour Primitivus ont été séparés dans un projet annexe (urwid-satext) sous licence LGPL v3, les données sont en Creative Common By-SA.
J'envisage de passer le cœur en AGPL v3.
LinuxFR.org : C'est développé autour de quelles « technos » ?
Beaucoup :)
Tout le cœur est en Python et utilise l'excellent framework Twisted, ainsi que son extension spécifique à XMPP Wokkel. La communication entre les interfaces et le démon est faite via D-Bus, mais il est tout à fait possible d'utiliser autre chose
Wix utilise WxWidgets. Primitivus utilise Urwid, une bibliothèque bien pensée pour faire des interfaces console type ncurses - ça peut d'ailleurs utiliser ncurses en backend, mais ce n'est pas le cas pour Primitivus.
Bellaciao utilise Qt, c'est la première interface codée avec autre chose que Python (C++).
Libervia utilise un autre outil qui gagne à être connu : Pyjamas. C'est un port des GWT en Python, et ça se compose de deux projets principaux : un compilateur Python => Javascript, et une bibliothèque de widgets pour faire l'interface. Du coup même l'interface web est codée 100 % en Python.
D'autres technos sont utilisées au cas par cas comme BeautifulSoup ou Pyfeed.
LinuxFR.org : Ça se compare à quoi de libre ou proprio ?
À tous les clients XMPP :) J'ai découvert par hasard qu'un autre projet avait eu la même idée d'un client multi-interfaces : aMSN2.
LinuxFR.org : C'est quoi les tueries de ce soft ?
Évidemment, il y a le côté multi-interface mais j'en ai suffisamment parlé.
SàT utilise un système d'extensions : la base ne fait... que la base, et on installe les fonctionnalités qui nous intéressent (conversation à plusieurs, transfert de fichiers, microblogage, jeux, voire des choses qui n'ont rien à voir avec XMPP). Les extensions sont côté démon, donc communes à toutes les interfaces.
Les permissions sont basées sur les groupes du roster : vous pouvez ne microbloguer qu'avec le groupe « amis du caillou » par exemple. La même chose est prévue pour le partage de fichiers, ou les autres formes de partage.
Une de ces extensions permet d'utiliser n'importe quel client courriel pour lire/envoyer ses messages XMPP, et comme XMPP permet via les transports de communiquer avec d'autres protocoles, vous pouvez utiliser votre client courriel pour envoyer des messages n'importe où. Je crois fermement que XMPP est un excellent candidat pour remplacer à terme le réseau courriel traditionnel.
Globalement, le projet veut utiliser XMPP pour ce qu'il est, c'est-à-dire bien plus que de la simple messagerie instantanée. Par exemple, on peut utiliser SàT pour envoyer la sortie d'un pipe en ligne de commande vers un contact. Une vidéo sur mon blog montre comment utiliser ça pour streamer la bande annonce de Sintel.
Mais la plus importante « tuerie de ce soft », c'est clairement son contrat social : il pose les bases idéologiques du projet, et veut permettre à l'utilisateur de se réapproprier ses communications, sa vie numérique.
LinuxFR.org : Y a-t-il un business-model autour ?
Loin, très loin de moi cette idée. Je ne dis pas que je n'aimerais pas gagner ma vie un jour en travaillant sur le projet, mais je ne veux certainement pas faire du « business », je ne veux pas que l'argent soit un but. Le but est avant tout idéologique : nous sommes à un moment critique dans l'histoire d'Internet, et il est urgent de mettre en place des moyens de communiquer qui ne sont pas contrôlé/contrôlables par des entreprises ou des états.
Je m'intéresse beaucoup à l'autogestion, et j'ai en projet de créer - à terme - une association autogérée autour de SàT. S'il y avait en plus possibilité de permettre à quelques personnes de gagner leur vie, ce serait idéal; mais dans ce cas il y aurait toujours le contrat social, et il serait hors de question de faire de la publicité ou de la vente d'informations pour arriver à cette fin.
LinuxFR.org : Quels sont les déploiements publics ou privés (dont vous pouvez parler) les plus significatifs ?
Le projet est encore trop instable pour être utilisable par un public non averti. Cependant il a atteint un point critique, et je compte lancer très bientôt une nouvelle version (0.3) et un site basé sur l'interface web, qui permettra d'utiliser le projet sans installation. Mon but est de faire une intégration continue des améliorations et des retours afin de sortir une version 0.4 la plus stable possible.
LinuxFR.org : Vous êtes combien de contributeurs ?
Pour le code, je suis l'unique développeur depuis le début. J'ai eu l'été dernier l'aide très précieuse d'Adrien Vigneron (Raiden) qui a travaillé sur l'apparence de l'interface web et sur les graphismes d'un jeu de Quiz en préparation. Il n'est désormais plus trop disponible, mais j'espère vraiment pouvoir retravailler avec lui dans le futur.
Quelques personnes se sont intéressées au code, mais le ticket d'entrée est assez élevé, ne serait-ce que par l'utilisation de Twisted, et ça demande pas mal d'investissement, donc jusqu'ici rien ne s'est concrétisé par des contributions (à une correction de bogue près).
LinuxFR.org : Comment est né le projet ? Comment a-t-il évolué ? Quels sont les faits marquants ?
Au début j'avais surtout envie de me lancer dans un gros projet pour améliorer mes compétences avec Python, apprendre Twisted, et comme je n'avais pas trouvé de client XMPP qui me convenait complètement, je me suis lancé là dedans.
Mais le plus dur ce n'est pas de commencer, c'est de continuer. Comme je l'ai dit plus haut, je m'intéresse beaucoup à la politique, et cela s'est immédiatement senti dans le projet : ce qui m'a permis de tenir sur la longueur, c'est cette envie et ce besoin d'avoir une alternative aux grand aspirateurs du web, cette nécessité de reprendre le contrôle sur nos vies numériques, privées ou publiques, et donc sur nos vies tout court.
Il a évolué grâce à mes rencontres : j'ai développé pas mal en étant sur les routes, et voir l'usage que les gens ont d'Internet, ou discuter des problèmes actuels m'ont souvent motivé, parfois inspiré.
Dans les faits marquants, on peut citer le premier stand aux RMLL, la première conf aux JDLL (mal préparée, désolé pour ceux qui y étaient), les encouragements, les gens qui n'y croient pas - paradoxalement ça motive -, dans la même veine les gens qui pensent que le logiciel libre est un jouet de geeks.
LinuxFR.org : Quels problèmes avez-vous rencontrés ?
L'électricité et un réseau décent ne sont pas toujours faciles à trouver dans l'outback australien :)
LinuxFR.org : Quelle est votre roadmap ?
Lancer la 0.3 et le site si possible avant la fin de l'année.
Dans les priorités à court terme (quelques semaines) il y a :
- améliorer le microblogage, travailler sur le standard
- le partage de fichiers (on peut transférer un fichier pour le moment, mais je parle là de partage indirect)
- les outils d'organisation d'évènements
- l'intégration d'OpenStreetMap
Dans le moyen terme (quelques mois) :
- le chiffrement de bout en bout (prévu pour la 0.4)
- les paquets pour les distributions
- une interface FUSE
- les ports sur d'autres plateformes (Maemo, Android, Zin, Mac, etc.)
- quelques fonctionnalités sympas que j'ai dans les cartons
Et bien sûr, beaucoup de débogage, améliorer tant que possible la sécurité et les tests, finir les choses à moitié finies, etc.
LinuxFR.org : Quelle est votre relation avec la XSF ?
Je ne suis pas à la XSF, mais la communauté XMPP/Jabber est une grande famille, et je suis parfois en contact avec certains de ses membres. Par exemple Ralph Meijer, qui est l'auteur de Wokkel, ou Neustradamus qui fait beaucoup pour que les développeurs discutent entre eux et donnent des retours sur les standards.
Sinon j'ai discuté un peu du protocole pour le microblogage sur une des listes de diffusion de la XSF, et j'espère pouvoir trouver le temps de contribuer réellement aux standards.
LinuxFR.org : Quelles sont les relations avec les autres développeurs de clients ? Et de serveurs ? Menez-vous des tests d'interopérabilité ?
J'ai des contacts avec les auteurs d'autres clients comme Jappix, ou MOVIM (j'ai rencontré Edhelas aux JDLL, il y a peu), de temps en temps je dois discuter avec les équipes des serveurs pour des questions techniques. J'ai rencontré aussi une partie de l'équipe de Jitsi aux RMLL qui était très sympa.
Les relations sont bonnes, et je tiens à ce que nos projets soient vus comme des alternatives, pas des concurrents.
Une note aussi pour la communauté JabberFr (et pour l'APINC), avec qui je discute souvent, qui encourage, et dont j'ai rencontré une partie aux JDLL.
Pour l'interopérabilité, je n'ai malheureusement pas suffisamment de temps pour faire des tests, je teste quasiment tout le temps avec les mêmes clients (Gajim, Psi et Kopete).
LinuxFR.org : La voix et vidéo dans SàT, c'est prévu ?
Oui mais dans... pfiiiiouuuu... au moins.
LinuxFR.org : Pourquoi Jingle peine-t-il à décoller sur XMPP ?
Je trouve que ça marche plutôt pas mal moi : il y a de plus en plus de clients qui le gèrent. Je recommande notamment Jitsi, anciennement SIP Communicator, qui est très prometteur.
LinuxFR.org : Dans la même veine, PubSub et PEP peinent encore plus à décoller : est-ce parce que c'est plus difficile à appréhender ? Qu'est-ce qui est implémenté dans SàT ?
PubSub n'est pas visible parce qu'il n'est pas mis en avant par les clients populaires qui se concentrent sur la messagerie instantanée. Mais j'ai vu plusieurs projets qui l'utilisent pour faire, par exemple, des moteurs de blog. C'est à la base du microblogage, et nous sommes plusieurs projets à travailler dessus en ce moment.
SàT utilise PubSub et PEP pour le microblogage donc, mais il y a de fortes chances que le partage de fichiers se base aussi dessus, ainsi que tout un tas de choses comme par exemple des jeux. C'est une technologie qui va probablement monter en puissance dans les années à venir.
En revanche, côté serveur ce n'est pas encore évident, le support est souvent incomplet, voire inexistant. Les deux meilleures implémentations que je connaisse sont celle de EjabberD et d'OpenFire, et c'est en cours d'implémentation chez Prosody. Je ne sais pas ce qu'il en est de serveurs comme Tigase.
LinuxFR.org : On a beaucoup parlé de fonctionnalités « sociales » dans XMPP, mais celui-ci est social par défaut... Des initiatives comme Jappix et Movim, ou encore OneSocialWeb ou BuddyCloud ont été lancées, ont fait parler, mais rien de tout cela ne semble réellement « prendre » à ce stade : qu'est-ce que vous implémentez dans SàT ?
« Réseau Social » est un terme pompeux purement marketing, au même titre que Web 2.0. Les réseaux dit « sociaux » n'ont rien apporté qui n'existait déjà. Donc oui XMPP permet de faire tout ce qui est fait dans les sites populaires du moment, et bien plus encore. (NdM. : voir la page ReseauxSociaux)
Jappix a son petit succès, MOVIM commence à être sympa, OneSocialWeb je ne sais pas trop où ils en sont, et BuddyCloud s'éloignent un peu des standards (ils font leur propre protocole de microblogage), ce qui n'est pas forcément une bonne idée. Je pense que pour le moment aucun n'est suffisamment fini, ou n'a de fonctionnalité suffisamment originale (une killer feature quoi) pour exploser d'un coup, mais sur le long terme il y a une chance.
Il y a une prise de conscience des dangers qu'il y a à utiliser des services centralisés pour toutes les communications, mais qui est beaucoup trop faible au regard de l'ampleur du problème : il faut déjà jouer là-dessus, et expliquer autour de soi que l'ont peut utiliser des alternatives, et qu'il est important de le faire.
XMPP est à mon avis le seul protocole qui est aujourd'hui capable de faire face aux plus gros : non seulement il est libre, standard, décentralisé, et fédéré, mais en plus il a déjà une structure autour de lui, un important parc existant, 10 ans d'expérience, il est extensible, et il a des atouts pratiques comme un identifiant qui ressemble à une adresse courriel.
Il faut que ces projets prennent, que ce soit SàT ou un autre (ou mieux : SàT et des autres), il faut absolument que ça prenne : ce n'est plus une question de faire face à un protocole privateur comme il y a 10 ans, c'est devenu une question essentielle dans l'avenir de la société. Est-ce que l'on veut laisser aux générations suivantes un Internet contrôlé par quelques grandes multinationales, qui peuvent lire leur communications les plus intimes, ou censurer ce qui ne leur plaît pas, est-ce qu'on veut que leur souvenirs soient archivés dans une ferme de serveurs quelque part ; ou est-ce qu'on veut leur laisser les outils pour se former leur propre vie, leur propre opinion, et créer la société qu'ils désirent ?
LinuxFR.org : Merci beaucoup !
Merci à toi, ainsi qu'à toute l'équipe derrière DLFP qui fait un super boulot depuis des années.
Aller plus loin
- Salut à Toi (520 clics)
- Tag « SàT » sur LinuxFr.org (59 clics)
# Niveau de langage
Posté par BFG . Évalué à 5.
C'est proprement ridicule d'écrire ça, même à l'oral personne n'utiliserait ce genre de formule...
[^] # Re: Niveau de langage
Posté par CrEv (site web personnel) . Évalué à 10.
Sérieux ?
Personne ne dirait "C'est quoi SàT ?" ? On ne doit pas parler aux mêmes personnes alors...
[^] # Re: Niveau de langage
Posté par walken . Évalué à 1.
T'es qui toi, en effet, c'est déplaisant, pas très polie, c'est laid tout court...
Par contre, C'est quoi SàT ??? Où est le problème ? La question aurais du être " Qu'est-ce que c'est SàT, le logiciel que tu à crée, celui que tu code depuis x temps et qui utilise le protocole XMPP... ?
Arrête de "niaiser"..
[^] # Re: Niveau de langage
Posté par Maclag . Évalué à 10.
"Peux-tu nous dire ce qu'est ce SàT, ce client XMPP en mode client-serveur aux multiples interfaces Wxwidgets, ncurses, web et autres à venir, qui permet de discuter, échanger des fichiers, faire du microblogage, des jeux et plein d'autres choses encore sur lequel tu bosses seul tout en parcourant le monde et que tu as présenté ici plusieurs fois?
-Euh... hmm... Oui! Je peux le dire!!
-Merci!"
Cet entretien vous a été proposé par Linuxfr, département langages de haut niveau.
[^] # Re: Niveau de langage
Posté par walken . Évalué à -7.
très pertinent, ça mérite un 10/10.
Alors, je t'invite au bordel. C'est moi qui l'offre.
# Je suis perdu !
Posté par bat13 . Évalué à 3.
J'ai tout lu, je traine souvent sur linuxfr, mais pourtant, je ne comprends pas grand'chose à SàT.
Et notamment, je ne vois pas le rapport entre la messagerie instantanée et OpenStreetMap.
Et je ne parle pas de XSF, Jingle, PubSub, ...
J'ai l'impression de jouer au business loto :(
[^] # Re: Je suis perdu !
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ah non, pas au business loto, plutôt au loto geek…
[^] # Re: Je suis perdu !
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 2.
Dans xmpp on peut partager sa localisation (voir http://xmpp.org/extensions/xep-0080.html ) (il y a des clients qui affichent les contacts sur une carte mais c'est pas très répandu).
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: Je suis perdu !
Posté par Goffi (site web personnel, Mastodon) . É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: Je suis perdu !
Posté par Goffi (site web personnel, Mastodon) . É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: Je suis perdu !
Posté par Maclag . Évalué à 4.
J'ajoute friture, et... et... et KAMOULOX!
J'ai gagné! :)
(Désolé)
----------> [ ]
[^] # Re: Je suis perdu !
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
OpenStreetMap ok, je comprends pourquoi tu es perdu (la liaison avec XMPP n'est pas triviale), par contre XSF, Jingle et PubSub sont très fréquemment associés à XMPP, pour peu qu'on s'y intéresse un minimum....
# Bellaciao
Posté par qpad . Évalué à 4.
Salut,
Bravo pour le projet !
Question bête : pourquoi Bellaciao en Qt/c++ et pas PyQt (ou PySide) si le reste du projet est en python ?
[^] # Re: Bellaciao
Posté par Goffi (site web personnel, Mastodon) . É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.
# réseau social libre
Posté par tuxicoman (site web personnel) . Évalué à 3.
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?
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?
Bref, le concept même de serveur lié à XMPP n'est il pas le problème ? Voir http://tuxicoman.jesuislibre.net/2011/07/mon-idee-de-reseau-social-libre-et-decentralise.html
[^] # Re: réseau social libre
Posté par Goffi (site web personnel, Mastodon) . É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: réseau social libre
Posté par tuxicoman (site web personnel) . Évalué à 1. Dernière modification le 01 décembre 2011 à 18:30.
En fait, je parlais d'usurpation d'identité par quelqu'un faisant un man-in-the-middle du serveur (un admin du serveur ou un gouvernement/organisme de surveillance ayant les moyens d'usurper le certificat du serveur).
[^] # Re: réseau social libre
Posté par Goffi (site web personnel, Mastodon) . É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 BFG . Évalué à 1.
OTR doit être utilisé avec attention, car des modules de serveurs XMPP savent déjà se mettre au milieu.
[^] # Re: réseau social libre
Posté par Goffi (site web personnel, Mastodon) . É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: réseau social libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Comme j'utilise Retroshare depuis un moment, je vais essayé de donner quelques précisions:
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.
Ce n'est pas obligatoire. Retroshare gère des messages/forums/partages de fichiers asynchrones.
Tout à fait! C'est malheureusement impossible de faire un système de nommage décentralisé sans se taper des identifiants de 3m de long.
Ca ne s'applique pas à Retroshare où tout est à la fois client et serveur.
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 :-(
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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: réseau social libre
Posté par Goffi (site web personnel, Mastodon) . É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: réseau social libre
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pour bien comparer, il faut distinguer trois cas:
Aujourd'hui Retroshare en tant que service n'existe pas, tous les reproches qui lui sont fait en découle.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: réseau social libre
Posté par tuxicoman (site web personnel) . Évalué à 2.
Installer un serveur Jabber est problématique.
Il faut une machine qui tourne H24
L'installation d'un logiciel genre ejabberd n'est pas à la portée du non-geek
Tu es dépendant d'un nom de domaine.
Après, si cette gestion technique peut-être faite par quelqu'un d'autre (pote geek, association, serveur communautaire, entreprise... comme pour les serveurs mail) sans nuire à ma vie privée, ca me va. Cela impose le chiffrement/authentification de bout en bout par défaut des messages, des messages hors ligne, du transfert de fichiers, et de la visioconf.
Reste une question, imaginons que je me serve de XMPP comme support de communication moderne (fait office d'email, messagerie instantanée, microblog...), Qui héberge mes données? Si XMPP propose le serveur, ca pose la question de la confidentialité de ces données, de la propriété des données (le serveur peut il etre attaqué pour partage de fichiers illégaux par exemple) et du coût de l'espace de stockage nécessaire pour plusieurs membres. (je considère que le rapatriement des données personnelles sur le poste de l'utilisateur est facile car on parle de serveurs sympa :)
[^] # Re: réseau social libre
Posté par Maclag . Évalué à 2.
Parce que confier tout ça à Google, Facebook et autre, ça te semble vachement moins risqué?
Voyons voir:
-les admins qui bossent chez Google et FB peuvent faire tout ce que tu viens de dire, c'est pas parce qu'ils ne sont pas dans tes relations qu'ils ne sont pas des geeks ayant des potes ; ta seule sécurité ici c'est qu'ils ne te connaissent pas et donc ont peu de chance de s'intéresser à tes contenus en particulier
-les crackers seront certainement plus fiers de cracker Facebook que ton serveur perso avec 6 membres et 15photos, donc peut-être que ton serveur est moins sécurisé (en est-tu sûr? on ne sait pas comment sont faits les serveurs FB!) mais il est aussi moins intéressant ; crois-tu être à l'abri de ce genre d'intrusion qui mettrait tes photos coquines en accès libre et bien référencée sur un gros site?
-les admins autant que les intrus peuvent usurper ton identité, je ne vois pas en quoi c'est plus difficile chez FB que sur un serveur privé
-un serveur avec peu d'utilisateur géré par un geek peut aussi avoir ses avantages: ton pote geek sait très bien que tu ne te connectes jamais depuis la Chine puis de la Russie en moins de 4h ; Facebook s'en bat les reins
-enfin, tu pourras toujours dire que si FB et Google jouent au con, ils vont perdre des millions d'utilisateurs... ou pas, grâce à une bonne campagne de comm', le Geek indélicat ne perdra QUE ses amis et sa réputation dans son entourage ; finalement je ne sais pas ce qu'il y gagne
Enfin: il n'y a que moi qui trouve tordue l'idée d'aller mettre des photos coquines qu'on veut absolument garder en privé sur un réseau SOCIAL? Si c'est pour les envoyer à une personne, je les envoie par mail, chiffré au besoin. Aucun serveur au monde n'est 100% sécurisé. Mettre les photos sur ce serveur, c'est jouer au con de toute façon: si ce n'est pas une erreur côté gestion du serveur ou une intrusion malhonnête, ça peut être une fausse manœuvre de ta part.
[^] # Re: réseau social libre
Posté par tuxicoman (site web personnel) . Évalué à 2.
je pense que tu m'as mal compris.
Jamais je n'utiliserai Gmail ou Facebook pour toutes les raisons que tu as citées. On est ici dans un débat sur une alternative qui résolvent ces problèmes. Et visiblement, passer d'un gros serveur à pleins de petits serveurs fédérés ne résout pas ces problèmes, ca les réduit uniquement comme le dit ta conclusion.
Lis mon article cité en lien.
(ps: le mail non chiffré c'est 0 intimité dans l'échange sauf peut être que le serveur n'est pas censé en garder le contenu.)
# Un serveur client d'un autre serveur...
Posté par Maclag . Évalué à 5.
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.
De nos jours, et sur nos protocoles hautement connectés, il y a de moins en moins de différence entre un démon et un serveur (enfin si, mais... vous me suivez, non??).
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?
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...).
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.
Du coup, le jeu est cohérent pour tous les joueurs qui jouent sur le même serveur, l'interface est gérée côté client, pas de souci genre "ncurses peut pas afficher ce sale PNG!!"
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?
[^] # Re: Un serveur client d'un autre serveur...
Posté par Goffi (site web personnel, Mastodon) . É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
# Le "pipe": ça tue!
Posté par Maclag . Évalué à 2.
J'ai regardé la vidéo qui montre le pipe en ligne de commande.
C'est impressionnant de simplicité, et je me dis que ça doit être facile à ajouter dans une interface graphique "clickodrome" pour n'importe quel utilisateur.
Petite question:
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.
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!).
[^] # Re: Le "pipe": ça tue!
Posté par Goffi (site web personnel, Mastodon) . É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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.