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é).
qui octroie tes droits d'auteur à ton entreprise, par défaut
C'est ce que j'ai entendu aussi, mais même pour des projets faits en dehors des heures de travail ? Ça me parait assez fou quand même.
Bon en tout cas merci pour vos réponses, je pense en avoir assez pour faire une lettre, je verrai ça tranquillement ce week-end.
Bon de toute façon ils m'ont l'air très réglo dans cette boîte, je ne m’inquiète pas, mais c'est juste histoire d'être tranquille.
Bon après en avoir discuté avec mes employeurs, il sont d'accord pour me signer un papier, il faut juste que je le rédige moi. N'ayant aucune connaissance juridique, si vous avez une piste ou un modèle que je pourrais trouver quelque part, c'est parfait.
J'ai dit non concurrence parce que c'est celle qui m'a fait tilter. Je fais le logiciel sur mon temps libre, ce n'est donc pas une activité professionnelle.
La cessation des droits peut joueur sur quelque chose fait sur mon temps libre, donc en dehors des heures de travail ? Ça me paraîtrait fou si c'était le cas.
Je vais leur demander une autorisation écrite; il n'y a pas de problème avec mes employeurs, je veux juste être sûr de pouvoir toujours continuer à travailler tranquillement sur mon projet et le diffuser.
Je pense qu'il y a aussi le problème qu'ils s'en prennent régulièrement plein la tête (faut voir les commentaires parfois odieux quand le serveur est en panne, alors qu'ils se bougent et que le temps pour réparer est souvent dû à des problèmes indépendants de leurs volontés, comme en ce moment), et probablement que la vie des premiers admins évolue et qu'ils ont peut être moins de temps à consacrer à l'assoce (enfin aux, parce que l'APINC et jabberfr c'est 2 trucs différents).
Je pense qu'il serait plus intéressant de proposer de l'aide, ou adhérer.
Et la communauté jabber a ses défauts, ses prises de becs etc (comme partout), mais elle est bien sympa, je rentre juste des JDLL à Lyon, et j'ai pu rencontrer plusieurs réguliers du salon jabberfr, c'était très bon enfant (et merci pour l'hébergement, le sac de couchage, les infos, les encouragement, et - surtout - les discussions et rigolades).
Pi on sent un désintéressement général de XMPP depuis quelques années, alors qu'il y a un renouveau ces derniers temps, et que ça bouge bien.
ah ben en fait non, sur le salon que j'ai cité ce sont les admins de jabberfr.org, et ce ne sont pas les mêmes que les admins de l'hébergement apinc, désolé pour l'erreur.
C'est dommage que la dépêche soit si courte, il y a beaucoup à dire dessus.
Je ne connaissais les EFL que de nom, et je m'y suis récemment mis pour des raisons professionnelles. Et bien je les trouve vraiment excellentes. Il y a de très bonnes idées comme:
les fichiers edje qui décrivent l'interface, et permettent d'avoir un fichier compilé unique qui contient tout le thème, y compris les images. Les thèmes permettent de changer radicalement l'apparence de l'application
pas de vectoriel, tout utilise des images bitmap. La qualité graphique ne s'en ressent pas, mais au niveau rapidité ça n'a rien à voir
Le canvas est stateful, le mieux pour comprendre l'intérêt est de lire leur tutoriel (en gros si on dessine un rectangle et qu'on veut le faire bouger, au lieur d'effacer le canvas et en redessiner un autre comme on ferait dans la plupart des toolkits, on lui dit juste de se déplacer.
Elementary permet de coder en utilisant des widgets de haut niveau, tout en gardant la main sur edje ou evas, de plus bas niveau
Ce n'est pas juste pour faire des interface, il y a un framework complet qui s'occupe de choses comme D-Bus ou la gestion réseau, à l'instar de Gtk et Qt
c'est rapide ! Je veux dire très, très rapide: c'est impressionnant à voir tourner (j'ai pu comparer une genlist avec une liste gtk, c'est impressionnant la différence de ressenti)
bon j'ai pas trop le temps pour en écrire plus, mais ça vaut vraiment le coup de s'y mettre, suivez les tutos du site, allez sur IRC, et vous pouvez vous lancer avec l'excellent tuto en français sur developpez.com: http://louis-du-verdier.developpez.com/efl/debuter/
Ce que tu appelles les cercles ce sont les groupes XMPP, et c'est géré par tous les clients puisque dans le protocole de base.
Les flux, les billets, et messages divers sont stockés sur les serveurs, il faut juste un client qui gère le protocole en particulier (pour les messages, c'est le cas de tous, pour le microblogage, c'est au cas par cas, et c'est en train d'évoluer). Mais sinon ça n'en privilégie pas un en particulier, il suffit que le client et le serveur se comprennent.
D'après ce que j'ai compris, les messages instantanés vont passer par XMPP pour Diaspora (ils ont probablement dû penser que XMPP ce n'était que ça, cf mon commentaire plus haut), et du coup ça ne poserait pas de problème particulier (mais uniquement pour la messagerie instantanée). Pour les protocoles non XMPP, on utilise des « transports », qui permettent de traduire le protocole externe en XMPP et vice-versa.
Donc en gros tu peux avoir un parc informatique dans une université basé sur MOVIM, mais qui est (au choix des admins) soit fermé et interne à l'univesité, soit ouvert au monde extérieur. Dans ce dernier cas, il peux communiquer avec un Jappix sur un serveur jabber.fr, ou avec un SàT sur un serveur libervia.org. Les microblogages et divers messages passeront de l'un à l'autre sans aucun soucis.
Exporter/importer un profil c'est faisable, mais le fait que tes contacts n'aient rien à mettre à jour, ça pose des problèmes de sécurité: comment être certain que c'est toi qui a un autre profil ailleurs, et que ce n'est pas quelqu'un qui cherche à prendre ton identité ? Ceci dit, avec un peu de cryptographie, il doit y avoir moyen de s'en sortir, c'est une idée à creuser.
Quoi qu'il en soit, je ne pense pas que ce soit possible à l'heure actuelle, du moins pas en tout automatique.
PS: en regardant rapidement, en XMPP il y a 2 extensions (au moins) sur ce sujet, dont une refusée (XEP-0015), et une autre qui est deferred (c'est à dire qui n'a pas bougé depuis au moins 12 mois), la XEP-0283. Cette dernière précise d'ailleurs qu'il ne faut pas faire les choses automatiquement (4. Security Considerations). Bon j'ai regardé vraiment en diagonale, y'en a peut être d'autres.
En fait je pense qu'il n'est pas forcément nécessaire d'absolument refuser d'utiliser les réseaux propriétaires tels que facebook, g+, twitter etc, surtout qu'il est aisé de ne poster que sur l'un, et de dupliquer l'information sur les autres. Ça permet de toucher plus de monde. Après, c'est vrai que si c'est pour s'inscrire et ne se connecter qu'avec des amis, ça peut être lourd d'avoir à gérer plusieurs réseaux pour rencontrer les mêmes personnes.
L'information se duplique oui, après tout dépend l'utilisation qui est faite. Si c'est pour le partage de photos privées ou semi-privées, ou parler de choses intimes, la duplication n'est pas une bonne chose. Si c'est pour un usage informatif, à la identi.ca, ou comme semble être utilisé actuellement G+, c'est un peu moins gênant (mais ça peut quand même, et ça fourni quand même beaucoup d'informations sur les opinions et les centres d'intérêt). Il y a aussi le problème des licences (par ex. sous identi.ca tout est sous CC By - sauf si on paye -) qui peuvent être gênant.
Promis, j'essaye SàT dès que possible :) (note : pour AUR, ça serait bien de rajouter la mention complète "salut à toi" pour le retrouver plus facilement)
Pour maintenant, vaut peut être mieux attendre la prochaine version (la dernière release n'a plus grand chose à voir avec la version de dév)...
# 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é).
[^] # Re: Papier à signer
Posté par Goffi (site web personnel, Mastodon) . En réponse au message Contrat de travail et projet perso. Évalué à 2.
C'est ce que j'ai entendu aussi, mais même pour des projets faits en dehors des heures de travail ? Ça me parait assez fou quand même.
Bon en tout cas merci pour vos réponses, je pense en avoir assez pour faire une lettre, je verrai ça tranquillement ce week-end.
Bon de toute façon ils m'ont l'air très réglo dans cette boîte, je ne m’inquiète pas, mais c'est juste histoire d'être tranquille.
# Papier à signer
Posté par Goffi (site web personnel, Mastodon) . En réponse au message Contrat de travail et projet perso. Évalué à 2.
Bon après en avoir discuté avec mes employeurs, il sont d'accord pour me signer un papier, il faut juste que je le rédige moi. N'ayant aucune connaissance juridique, si vous avez une piste ou un modèle que je pourrais trouver quelque part, c'est parfait.
Merci pour vos réponses.
[^] # Re: C'est pas la clause de non concurrence
Posté par Goffi (site web personnel, Mastodon) . En réponse au message Contrat de travail et projet perso. Évalué à 2.
J'ai dit non concurrence parce que c'est celle qui m'a fait tilter. Je fais le logiciel sur mon temps libre, ce n'est donc pas une activité professionnelle.
La cessation des droits peut joueur sur quelque chose fait sur mon temps libre, donc en dehors des heures de travail ? Ça me paraîtrait fou si c'était le cas.
Je vais leur demander une autorisation écrite; il n'y a pas de problème avec mes employeurs, je veux juste être sûr de pouvoir toujours continuer à travailler tranquillement sur mon projet et le diffuser.
[^] # Re: Rôle communautaire...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Des nouvelles de l'APINC?. Évalué à 6.
Je pense qu'il y a aussi le problème qu'ils s'en prennent régulièrement plein la tête (faut voir les commentaires parfois odieux quand le serveur est en panne, alors qu'ils se bougent et que le temps pour réparer est souvent dû à des problèmes indépendants de leurs volontés, comme en ce moment), et probablement que la vie des premiers admins évolue et qu'ils ont peut être moins de temps à consacrer à l'assoce (enfin aux, parce que l'APINC et jabberfr c'est 2 trucs différents).
Je pense qu'il serait plus intéressant de proposer de l'aide, ou adhérer.
Et la communauté jabber a ses défauts, ses prises de becs etc (comme partout), mais elle est bien sympa, je rentre juste des JDLL à Lyon, et j'ai pu rencontrer plusieurs réguliers du salon jabberfr, c'était très bon enfant (et merci pour l'hébergement, le sac de couchage, les infos, les encouragement, et - surtout - les discussions et rigolades).
Pi on sent un désintéressement général de XMPP depuis quelques années, alors qu'il y a un renouveau ces derniers temps, et que ça bouge bien.
[^] # Re: C'est en cours
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Des nouvelles de l'APINC?. Évalué à 3.
ah ben en fait non, sur le salon que j'ai cité ce sont les admins de jabberfr.org, et ce ne sont pas les mêmes que les admins de l'hébergement apinc, désolé pour l'erreur.
# C'est en cours
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Des nouvelles de l'APINC?. Évalué à 2.
Il suffit des lire les liens, le dépannage est en cours: http://suivi.apinc.org/
Sinon les admins sont souvent dispos sur le salon MUC jabberfr@chat.jabberfr.org
# Dommage que la dépêche soit un peu courte
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche EFL 1.1 alpha. Évalué à 10.
C'est dommage que la dépêche soit si courte, il y a beaucoup à dire dessus.
Je ne connaissais les EFL que de nom, et je m'y suis récemment mis pour des raisons professionnelles. Et bien je les trouve vraiment excellentes. Il y a de très bonnes idées comme:
les fichiers edje qui décrivent l'interface, et permettent d'avoir un fichier compilé unique qui contient tout le thème, y compris les images. Les thèmes permettent de changer radicalement l'apparence de l'application
pas de vectoriel, tout utilise des images bitmap. La qualité graphique ne s'en ressent pas, mais au niveau rapidité ça n'a rien à voir
Le canvas est stateful, le mieux pour comprendre l'intérêt est de lire leur tutoriel (en gros si on dessine un rectangle et qu'on veut le faire bouger, au lieur d'effacer le canvas et en redessiner un autre comme on ferait dans la plupart des toolkits, on lui dit juste de se déplacer.
Elementary permet de coder en utilisant des widgets de haut niveau, tout en gardant la main sur edje ou evas, de plus bas niveau
Ce n'est pas juste pour faire des interface, il y a un framework complet qui s'occupe de choses comme D-Bus ou la gestion réseau, à l'instar de Gtk et Qt
c'est rapide ! Je veux dire très, très rapide: c'est impressionnant à voir tourner (j'ai pu comparer une genlist avec une liste gtk, c'est impressionnant la différence de ressenti)
bon j'ai pas trop le temps pour en écrire plus, mais ça vaut vraiment le coup de s'y mettre, suivez les tutos du site, allez sur IRC, et vous pouvez vous lancer avec l'excellent tuto en français sur developpez.com: http://louis-du-verdier.developpez.com/efl/debuter/
# :(
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Jappix recrute !. Évalué à 6.
:(. Quand je pense qu'on était voisins aux Reumeuleuleuh
Bon dommage que Valérian quitte la partie en tout cas, bonne continuation à lui (et à Jappix).
[^] # Re: « Machin est bronsonisé »
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Robert Lamoureux bronsonisé. Évalué à 8.
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Diaspora . Évalué à 4.
Ce que tu appelles les cercles ce sont les groupes XMPP, et c'est géré par tous les clients puisque dans le protocole de base.
Les flux, les billets, et messages divers sont stockés sur les serveurs, il faut juste un client qui gère le protocole en particulier (pour les messages, c'est le cas de tous, pour le microblogage, c'est au cas par cas, et c'est en train d'évoluer). Mais sinon ça n'en privilégie pas un en particulier, il suffit que le client et le serveur se comprennent.
D'après ce que j'ai compris, les messages instantanés vont passer par XMPP pour Diaspora (ils ont probablement dû penser que XMPP ce n'était que ça, cf mon commentaire plus haut), et du coup ça ne poserait pas de problème particulier (mais uniquement pour la messagerie instantanée). Pour les protocoles non XMPP, on utilise des « transports », qui permettent de traduire le protocole externe en XMPP et vice-versa.
Donc en gros tu peux avoir un parc informatique dans une université basé sur MOVIM, mais qui est (au choix des admins) soit fermé et interne à l'univesité, soit ouvert au monde extérieur. Dans ce dernier cas, il peux communiquer avec un Jappix sur un serveur jabber.fr, ou avec un SàT sur un serveur libervia.org. Les microblogages et divers messages passeront de l'un à l'autre sans aucun soucis.
[^] # Re: J'aimerai pouvoir migrer mon profil d'une instance à une autre
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Diaspora . Évalué à 4.
Exporter/importer un profil c'est faisable, mais le fait que tes contacts n'aient rien à mettre à jour, ça pose des problèmes de sécurité: comment être certain que c'est toi qui a un autre profil ailleurs, et que ce n'est pas quelqu'un qui cherche à prendre ton identité ? Ceci dit, avec un peu de cryptographie, il doit y avoir moyen de s'en sortir, c'est une idée à creuser.
Quoi qu'il en soit, je ne pense pas que ce soit possible à l'heure actuelle, du moins pas en tout automatique.
PS: en regardant rapidement, en XMPP il y a 2 extensions (au moins) sur ce sujet, dont une refusée (XEP-0015), et une autre qui est deferred (c'est à dire qui n'a pas bougé depuis au moins 12 mois), la XEP-0283. Cette dernière précise d'ailleurs qu'il ne faut pas faire les choses automatiquement (4. Security Considerations). Bon j'ai regardé vraiment en diagonale, y'en a peut être d'autres.
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Diaspora . Évalué à 3.
L'information se duplique oui, après tout dépend l'utilisation qui est faite. Si c'est pour le partage de photos privées ou semi-privées, ou parler de choses intimes, la duplication n'est pas une bonne chose. Si c'est pour un usage informatif, à la identi.ca, ou comme semble être utilisé actuellement G+, c'est un peu moins gênant (mais ça peut quand même, et ça fourni quand même beaucoup d'informations sur les opinions et les centres d'intérêt). Il y a aussi le problème des licences (par ex. sous identi.ca tout est sous CC By - sauf si on paye -) qui peuvent être gênant.
Pour maintenant, vaut peut être mieux attendre la prochaine version (la dernière release n'a plus grand chose à voir avec la version de dév)...