j'avais regardé vite fait pour implémenter les norloges avec les threads, ça ne peut pas marcher parce qu'il n'y a qu'un parent possible pour un thread. Par contre je pense que c'est parfaitement implémentable avec les références maintenant.
Il n'y a pas que côté client que ça chauffe en ce moment, il y a eu des progrès énormes ces dernières années sur appareils portables (téléphone en particulier), chiffrement, et surtout MIX (qui va remplacer MUC pour les discussions de groupe et qui annonce de nombreuses possibilités très intéressantes).
Du côté des bibliothèques aussi, avec Smack (Java) ou Sleekxmpp/Slixmpp.
Côté clients il y a aussi Yaxim et Xabber qui reprennent du poil de la bête, et en moins grand public Poezio continue son chemin.
je ne l'ai testé qu'avec mon propre blog où j'étais le seul auteur. Si ça ne fonctionne pas, n'hésite pas à ouvrir un ticket sur https://bugs.goffi.org pour qu'on voit ce qu'on peut faire.
Dans ce tuto c'est expliqué à travers le conteneur Docker parce que c'était la suite des tutos précédents, mais dans ton cas il vaut mieux récupérer jp en natif (dispo sur Debian ou Arch par exemple, je ne suis pas 100% certains que ces versions permettent l'import Dotclear mais il me semble que oui).
Quand je dis c'est possible avec SàT, ça ne veut pas dire qu'il faut utiliser SàT pour afficher ton blog ensuite hein, c'est du XMPP et tu peux donc l'utiliser aussi avec Movim.
Arff les adresses d'exemple sont encore de la forme "nom@hébergeur" alors que salut@louise ou coucou@goffi serait tellement plus swag et plus "internet décentralisé" ;-)
C'est un serveur de test uniquement sur la machine, ceux qui installent peuvent utiliser ce qu'il veulent :).
Mais sinon comme je te l'avais déjà dit dans le journal que tu cites, la remarque est intéressante/pertinente.
C'est une bonne surprise de voir la publication en dépêche, et avec les corrections faites (j'avais fait quelques corrections sur mon blog que je n'ai pas eu le courage de reporter sur le journal, et je vois que c'est corrigé ici).
Tu as raison, et ça a aussi été abordé dans une A.G., il a été question un moment d'utiliser Libervia pour tout, et de faire Libervia web, Libervia desktop, Libervia cli, etc.
Ce n'est pour le moment pas une solution satisfaisante pour plusieurs raisons : déjà il peut y avoir plusieurs interface web/cli/etc., ensuite les noms n'ont pas été choisis aux hasard et ça chagrinerait de les passer à la trappe, et puis ça permet de différencier des choses différentes.
« Salut à Toi » (le projet dans l'ensemble) est au final plus une base pour créer des outils cohérents, et les frontaux sont les interfaces de ces outils.
Pour faciliter le lien, on précise maintenant systématiquement (SàT) dans les noms.
Il faut voir aussi que le nom « Salut à Toi » est un pied de nez au choix quasi systématique d'un nom court, qui sonne bien, de préférence anglophone, insipide et facile à retenir, en plus de la référence aux Bérus et d'un nom qui colle bien pour un outil de communication. Note que je n'ai rien contre les noms anglophones ou faciles à retenir, c'est juste le « quasi systématique » qui est ennuyant. La graphie en montagne russe (qui n'est d'ailleurs pas dans le titre de la chanson) couplé à la présence de l'accent sont un petit plus amusant. L'accent a d'ailleurs déjà permis de lever des bogues de mauvaise gestion unicode.
Le seul petit regret que j'ai sur ce nom, c'est qu'on m'a déjà dit qu'on pensait que le projet était réservé aux francophone.
Tout ça mis à part, ça serait bien oui de simplifier pour ne pas perdre les gens qui s'intéressent au projet.
Faites une pause dans les "features/XEP/56 UI", offrez un couple backend/frontend solid. Cagou peut attendre.
Le développement de plusieurs frontaux permet de tester et améliorer l'architecture.
C'est déjà dur de faire entendre autre chose que Whatsapp et facebook mais dire aujourd'hui "dans le libre on a une alternative" en présentant le projet tel quel, c'est s'exposer au rejet pur et simple.
C'est encore trop tôt pour présenter SàT comme une alternative (la version à venir est justement prévue pour être la première qu'on puisse vraiment proposer au grand public). D'autre part on n'est pas la seule alternative, Movim, Xabber, Conversations peuvent être proposés également.
sauf que celui que tu connais n'est peut-être pas celui qui sera utilisé. Et JS plus que tout autre écosystème demande une mise à jour permanente, et potentiellement des refactoring ou changements d'outils (je sais qu'on est vendredi).
Je risque moins d'apprendre Brython. D'où moins de coups de mains possibles, que vous déplorez.
Si tu souhaites contribuer à SàT, il vaut mieux avoir des notions de Python (c'est un « tu » général vu que tu en as déjà). À partir de là, tu sais utiliser Brython ou Pyjamas.
et bim, redirection vers un papier xmpp ! Je me dis "c'est forcément technique et trop dur pour 20min par ci par là". Réponse très technique.
Le tuto lié ne parle de XEP, tu peux commencer par là pour jouer un peu.
Après implémenter une fonctionnalité XMPP, ça passe 9 fois sur 10 par une XEP, ça peut sembler difficile quand on n'en a jamais fait, mais en pratique ça ne l'est pas : ça explique juste précisément ce qu'il faut faire. Regarde celle là par exemple, tu verras que ça n'est pas si compliqué: XEP-0245.
Puis je parle aussi de CSS, de traduction, d'ouvrir la liste de tickets pour en choisir un, etc.
vous préférez avancer que rendre les contributions + faciles. Ok.
Il ne faut pas exagérer non plus, les contributions ne sont pas difficiles. Mercurial n'est pas plus compliqué que GIT (c'est même plus simple), et si vraiment ça pose problème on peut même s'en sortir avec un envoi du code par courriel ou XMPP, les rapports de bogue ne sont pas non plus compliqués à faire (on accepte même ceux en Français si nécessaire).
argument pour des tickets d'une forge, type gitlab :)
quelqu'un qui disparaît je ne vois pas trop ce que ça va changer dans une forge. Enfin de toute façon Gitlab n'est pas exclus, et il nous manque un outil de revue de code c'est vrai.
et j'oubliais dans les choses à faire (mais c'est chiant et je le ferai sûrement moi même): les tests ! On a utilisé par le passé un buildbot, mais la couverture est à revoir, ainsi que le système de tests, c'est le chantier que je comptais faire pendant la phase de bêta et que les fonctionnalités seront gelées.
ce serait super. Votre employeur est-il ok pour vous passer à temps partiel ? J'aimerais y arriver aussi, sans nécessairement une compensation de salaire. Je serais tellement content ! La compensation aurait du sens pour un temps long dédié au logiciel, à mon avis.
Ce sont des choses à négocier, mais vu le temps que ça prend sur ma vie, il va falloir trouver une solution et celle là semble la plus réaliste à l'heure actuelle.
y a-t-il une liste de tâches faciles ? pas vu sur votre bugzilla.
À une époque on avait fait une TODO list sur le wiki, mais avec le faible nombre de contributions et l'évolution constante du projet, on n'a pas maintenu. Le plus simple est de venir sur notre salon XMPP (sat@chat.jabberfr.org) pour en discuter.
Il y a quelques XEPs qui seraient sympa à implémenter (par exemple blocking command serait assez trivial à faire), ça se passe côté backend et il y a un tuto écrit ici: écrire un greffon pour SàT.
On peut aussi faire de l'amélioration de CSS (on va réécrire Libervia pour la 0.8, mais ça serait pas mal de rafraîchir), du thème (je viens de commencer à réécrire le système de thèmes pour le blog statique), de la traduction, ou prendre un bug qui semble abordable dans la liste.
Mais je trouve que vous ne rendez pas la chose facile: hg, bugzilla et pas github/gitlab et un gestionnaire de tickets plus moderne.
Mercurial est utilisé depuis le début du projet, et bugzilla est là depuis longtemps aussi, c'est toujours utilisé parce que ça fait le boulot et que changer demande du temps qu'on consacre plutôt au code de SàT.
On a abordé l'utilisation de Gitlab/Github dans la dernière A.G. (celle dont je parle dans le journal si je ne m'abuse, du coup le résumé doit être dans ce compte-rendu), ainsi que d'implémenter l'authentification XMPP dans Bugzilla pour éviter d'avoir à créer un compte. Github a été écarté par cohérence, Gitlab reste une option.
Cependant on a toutes les briques pour faire notre propre outil de rapport de bogues basé sur XMPP maintenant (et donc décentralisé), c'est en gros une version spécialisé du blogage qu'on gère déjà (en tout cas dans notre cas pas besoin de plus, du moins pour le moment), et ça permet d'avoir un cas concret, c'est a priori ce qui va être fait dans un futur que j'espère proche.
Et il y aura une difficulté en plus si vous utilisez comme je vous en ai entendu parler, brython ou un truc du genre à la place d'un framework JS.
Brython ne sera utilisé que pour l'interface Web, et devrait être beaucoup plus simple à installer que Pyjamas que nous utilisons actuellement. Ce n'est pas plus compliqué qu'apprendre un framework JS (même plutôt plus simple vu qu'on ne change pas de langage), et ça ne sera de toute façon pas utilisé pour les pages statiques.
Certes, l'image docker simplifie l'installation. Mais surtout je trouve que vous restez très techniques et que vous ne parlez pas bien aux potentiels utilisateurs, dont je suis aussi (surtout?).
Effectivement on a parfois un problème de communication, il ne faut pas hésiter à nous le dire et à nous demander si quelque chose n'est pas clair. C'est difficile de ne pas être technique quand on a la tête dans le code à longueur de temps, en plus sur linuxfr j'ai tendance à aller plus dans les détails qu'ailleurs.
Et le thème CSS… a besoin d'un contributeur ou contributrice :S
Oui, d'ailleurs quelqu'un était venu proposer un thème CSS pour le blog statique sympa comme tout, je voulais l'intégrer mais depuis on ne le voit plus sur le salon :(. Sinon Libervia va être réécrit pour la version 0.8 (pas celle à venir, la suivante), et il va y avoir un gros coup de rafraîchissement graphique au passage.
Nous y avons ouvert un compte pour SàT après en avoir discuté en A.G., bien que nous n'ayons pas encore vraiment commencé à utiliser et communiquer dessus (ça va venir). Nous apprécions beaucoup le côté éthique et impliqué dans le libre.
Je tiens aussi à vous remercier pour votre super réactivité, j'ai demandé la gestion des liens xmpp:, et ça a été intégré en quelques jours.
Tiens petite question pratique. Nous nous sommes ajouté à la communauté « libre à toi », parce que nous nous connaissons et avons des valeurs communes, mais la page de la communauté indique « Êtes-vous un contributeur dans la communauté libratoi ? », ce qui n'est pas le cas. Le rôle des communautés c'est d'indiqué des liens/affinités ou des personnes qui participe activement à un projet ?
Bon courage, vraiment content de voir un service comme ça se développer.
La question est très bonne, et vu de l'extérieur ça peut sembler surprenant, mais en y regardant de plus près ça n'est pas très difficile à comprendre.
Il y a déjà – et surtout – un budget bien plus important pour Matrix, et des développeurs (je ne sais pas combien, mais à vu de nez quelques uns) qui y travaillent à plein temps. C'est une très grosse boîte derrière Matrix (Amdocs). En comparaison, la plupart des clients se font sur le temps libre : Gajim c'est principalement une personne qui a peu de temps libre, Movim c'est principalement 1 seule personne aussi, pour SàT on a été temporairement 2 à plein temps (donc une grosse partie a été utilisée pour participer à des événement), mais c'est actuellement 1 seule personne sur son temps libre (moi), et on peut dire la même chose de la plupart des projets actifs (si ce n'est tous pour les clients libres, pour les serveurs c'est un peu différent).
Conversations fait figure d'exception avec 1 (seule !) personne qui arrive à être à plein temps dessus, et ça se sent dans le soin apporté dans les détails et la com', et qui contribue à son succès.
D'autre part il y a un choix du tout web en effet, et les technologies ont énormément évolué ces dernières années. La vidéo-conférence était un défi technique à la naissance de Jingle, aujourd'hui WebRTC gère toute la complexité. Je me souviens à la conf Matrix que j'avais vu au Fosdem des applaudissement nourris pour la vidéo alors que ce n'est qu'une mise en place de WebRTC, il y a aujourd'hui des très petits projets qui arrivent à faire de même.
Il faut bien se rendre compte de la complexité d'une vidéo-conférence, ce n'est pas juste envoyer un flux à un participant, il faut gérer les débits variables, annuler l'écho, gérer les codecs, adapter la transmission aux conditions, etc. Tout ceci est devenu presque trivial en web grâce aux développements de Google ou Mozilla.
Par contre sur bureau c'est toujours très compliqué, donc ça explique les difficultés des clients non web (pour notre part on met ça de côté pour le moment par exemple). Des clients s'appuyant sur des outils avancés comme Gajim avec Gstreamer, ou dont c'est une fonctionnalité principale comme Jitsi s'en sortent mais ça reste un boulot bien plus important que sur le web.
Pourquoi ne pas faire pareil pour les clients XMPP webs ? Et bien ils le font justement, Movim gère la vidéo dans le version de dév, Jappix (qui n'est plus maintenu) le faisait également, et probablement d'autres. Quand nous nous y intéresserons dans SàT, il est fort probablement que nous implémenterons en premier dans Libervia (frontal web) avec WebRTC.
Ce que j'affirme est tout de même à prendre avec des pincettes : je n'ai pas encore travaillé moi même sur la visio-conférence, aussi mon ressenti n'est peut-être pas juste.
Même en dehors de la vidéo, il y a beaucoup de problèmes qui sont plus simples aujourd'hui à gérer parce qu'il y a plus d'outils et bibliothèques disponibles, parce qu'on a plus d'outil de messageries existants dont on peut s'inspirer.
Ensuite les objectifs peuvent être différents. Pour Whatsapp le but principal évident était (et est toujours) de monétiser. Pour Matrix, je pense que c'est assez clairement le but aussi à moyen ou long terme. Ces choix font mettre les moyens et les priorités dans l'esthétique, les fonctionnalités populaires et le marketing, et on se retrouve avec X applications qui font peu ou prou la même chose et se ressemblent fortement, et qui plaisent parce que les gens s'y retrouvent.
Selon les projets, les objectifs peuvent être très différents (j'allais élaborer un peu là dessus, mais je manque de temps donc je vais finir ce message sur cette remarque).
le transfert de fichier est possible via Jingle, mais pas avec plusieurs destinataires en même temps.
C'est HTTP upload qui est utilisé dans ce cas (avec apparemment un chiffrement spécifique à Conversations dans certains cas).
Ce tableau est d'ailleurs incorrect, puisqu'il n'y a pas de méthode de transfert de fichier standard à l'heure actuelle avec OMEMO (il est plus ou moins au même point que OX de ce côté, avec une protoXEP en plus mais non officielle).
bon je rectifie, j'avais mal compris. Le fichier est envoyé normalement sur le HTTP upload, mais la clef de déchiffrement est mise dans la partie « fragment » (après le « # ») de l'URL. Du coup pas besoin d'un HTTP upload spécifique, et les clients qui gèrent ça vont avoir le fichier, pour les autres il sera illisible.
Le chiffrement de point à point (client <==> serveur <==> MUC (conversations de groupes) <==> autres serveurs <==> autres clients) est effectivement obligatoire dans XMPP depuis plusieurs années. Le chiffrement de bout en bout est principalement utile si tu n'as pas confiance en l'un des entités entre toi et ton/tes contact(s) (donc ton serveur, le service MUC, et un des serveurs de tes correspondants).
Dans le cas par exemple ou tu communiques avec un ou des proches sur le serveur que tu gères toi même (avec le service MUC très probablement sur la même machine), le chiffrement de bout en bout n'est pas utile.
HTTP upload qui stocke le fichier en clair sur le service (mais la transmission est chiffrée via HTTPS), et il n'y pas (encore) de méthode (standard du moins) pour chiffrer le fichier.
Apparemment il utiliserait une méthode de chiffrement avec clef dans l'URL, le problème est que ça n'est pas standard et ça demande un HTTP upload spécifique, ça ne marchera donc pas avec n'importe quel serveur.
Conversation -> Conversation (en clair et OMEMO, 1@1 ou multi: OK)
t'es en train de dire que Conversations est capable d'envoyer un message chiffré à plusieurs personnes en même temps ? T'es certain de ce que tu dis ?
Parce qu'à l'heure actuelle, tu peux utiliser Jingle (avec l'utilisation d'OMEMO – ce qui n'est pas standard pour le moment – comme je l'ai expliqué plus bas), mais ça n'est possible qu'entre 2 contacts, ou HTTP upload qui stocke le fichier en clair sur le service (mais la transmission est chiffrée via HTTPS), et il n'y pas (encore) de méthode (standard du moins) pour chiffrer le fichier.
Du coup je suis très étonné par ce que tu dis, est-ce que j'ai mal compris ou est-ce que tu dis bien qu'il est possible de chiffrer un fichier pour plusieurs destinataires en même temps ? Si oui ça marche pour gros et petits ? Tu fais comment (je testerai pour être sûr) ?
Gajim -> Conversation (non)
Gajim gère HTTP upload donc il est possible de partager un fichier, mais je veux bien que ça ne fonctionne pas avec Jingle vu que Gajim utilise une version obsolète (et conversation ne gère probablement pas Stream Initiation, ce qui n'est pas plus mal).
Il y a eu une petite tension entre Matrix et la communauté XMPP l'année dernière (et un peu l'année d'avant), parce que pour se faire connaître ils se sont mis sur un angle d'attaque très agressif envers XMPP, que ce soit dans les interventions (par exemple au FOSDEM il y a 2 ans, là où j'ai entendu parler d'eux la première fois d'ailleurs) ou par écrit.
Le problème n'est pas tant la critique en soit, c'est aussi qu'ils ont propagé un certains nombre de fausses vérités, notamment sur leur FAQ (qui n'est d'ailleurs toujours pas terrible même si c'est mieux) au point que la communauté a dû répondre, par exemple avec cette page (ainsi que des réponses sur différents réseaux).
À ça s'ajoute des gens (a priori des groupies, même si on ne sait pas trop si c'est des gens impliqués dans le projet ou pas) qui font de la propagande systématiquement pour Matrix dès qu'un article un peu visible parle de XMPP (en particulier sur hackernews ou reddit, mais on a vu des remarques désagréables même ici). Là encore pas vraiment un problème de parler d'un projet, mais quand c'est sous pour insinuer que XMPP est dépassé (ce qui est faux) et que l'herbe est plus verte chez eux, forcément à force c'est fatiguant.
Enfin bref, maintenant que Matrix est plus connu ça s'est un peu calmé, et c'est préférable de voir qu'il est possible de collaborer.
OMEMO a été basé historiquement sur libsignal, et la première proposition de XEP a été faite avec.
Cette proposition a été rejetée parce que :
la seule implémentation était une bibliothèque copyleft
ça n'était pas standardisé
il y avait des risques juridiques
De leur côté, les gens de Matrix ont développé Olm, standardisé et sans les problèmes mentionnés, il a donc été retenu pour une nouvelle proposition de OMEMO, cette fois acceptée.
Un exemple où Matrix et XMPP peuvent collaborer, une relation un peu plus seine que ce qu'on a vu l'année dernière.
Seulement il y a un « standard » de fait avec la première version de OMEMO (pas celle de la XEP donc), car c'est celle utilisée par Conversations et tout le monde veut être compatible avec.
De son côté, Conversations est bloqué pour passer à Olm parce qu'il n'y a pas encore de bibliothèque Java.
Les nouvelles implémentations partent actuellement toutes sur la version brouillon à cause de ce standard de fait, mais il ne devrait pas être difficile de passer d'une version à l'autre une fois que tout le reste est en place (interface utilisateur, gestion des messages chiffrés, autre XEPs nécessaires à l'utilisation, etc). Il est aussi tout à fait possible de fournir les 2 versions en même temps, mais aucun client ne le fait à l'heure actuelle.
Autre changement, une documentation de Double Ratchet a été mise dans le domaine public entre temps, donc il est possible de repasser à une implémentation basée dessus. J'ai suivi cette partie de loin, mais je sais qu'il est question d'en discuter au XMPP summit qui aura lieu ce week-end.
Tout ça va rapidement se stabiliser, il y a une petite excitation sur le sujet en ce moment , mais d'ici quelques mois ça devrait être stable.
Le téléversement de photos fonctionne avec Gajim, Conversation (je ne sais pas pour ChatSecure) et avec une bonne partie des clients activement développés. Le problème est que sauf si tu maîtrises ton propre serveur (ou si tu fais confiance aux admins), tu ne sais pas qui peut voir ces photos, combien de temps c'est stocké, et tu ne peux pas les supprimer (ce qui est – me semble-t-il – le cas sur la plupart des plateforme de messagerie, XMPP ou pas, si vous avez des contre-exemples je veux bien des infos).
L'envoi en pair à pair est disponible au moins sur Gajim, je pense que Conversations implémente Jingle et ChatSecure je ne sais pas. Gajim malheureusement utilise une ancienne version du protocole.
Plus d'infos sur l'envoi en pair à pair dans les épisode 9 et épisode 10 de parlons XMPP.
Pour le chiffrement des fichiers en pair à pair, je crois que Conversations utilise une méthode non standard avec OMEMO (proposée à la standardisation mais pas retenue), et il n'y a pas encore de méthode standard (il y a une méthode utilisant TLS qui devrait avoir un numéro officiel mais qui semble perdue).
Enfin pour l'envoi avancé (sous forme d'album), il y a des extensions permettant un début d'implémentation, mais rien de concret à ma connaissance. Ça devrait être un de nos chevaux de bataille pour 2017 avec SàT.
[^] # Re: Une première...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Rencontre XMPP/Jabber par JabberFR, mardi 28 mars 2017 à 19 h à Paris. Évalué à 4. Dernière modification le 23 mars 2017 à 20:34.
j'avais regardé vite fait pour implémenter les norloges avec les threads, ça ne peut pas marcher parce qu'il n'y a qu'un parent possible pour un thread. Par contre je pense que c'est parfaitement implémentable avec les références maintenant.
[^] # Re: Une première...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Rencontre XMPP/Jabber par JabberFR, mardi 28 mars 2017 à 19 h à Paris. Évalué à 6.
Merci pour les encouragements :)
Movim et SàT sont tous les 2 antérieurs à Jappix.
Il n'y a pas que côté client que ça chauffe en ce moment, il y a eu des progrès énormes ces dernières années sur appareils portables (téléphone en particulier), chiffrement, et surtout MIX (qui va remplacer MUC pour les discussions de groupe et qui annonce de nombreuses possibilités très intéressantes).
Du côté des bibliothèques aussi, avec Smack (Java) ou Sleekxmpp/Slixmpp.
Côté clients il y a aussi Yaxim et Xabber qui reprennent du poil de la bête, et en moins grand public Poezio continue son chemin.
[^] # Re: L'appli .rpm n'est pas disponible
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 4.
Toute la question est de savoir si on met un Gnou ou un Manchot.
[^] # Re: Bravo !
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 2.
je ne l'ai testé qu'avec mon propre blog où j'étais le seul auteur. Si ça ne fonctionne pas, n'hésite pas à ouvrir un ticket sur https://bugs.goffi.org pour qu'on voit ce qu'on peut faire.
[^] # Re: Bravo !
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Movim 0.11 — Tuttle. Évalué à 5. Dernière modification le 21 mars 2017 à 10:36.
Salut,
déjà un grand bravo à Edhelas pour cette release, super boulot !
je peux répondre à cette question:
C'est possible avec SàT, on peut importer depuis Dotclear et Dokuwiki à l'heure actuelle, et c'est expliqué là: https://goffi.org/blog/goffi/544798f9-52cb-468d-9547-263d1a2a8c0d
Dans ce tuto c'est expliqué à travers le conteneur Docker parce que c'était la suite des tutos précédents, mais dans ton cas il vaut mieux récupérer jp en natif (dispo sur Debian ou Arch par exemple, je ne suis pas 100% certains que ces versions permettent l'import Dotclear mais il me semble que oui).
Quand je dis c'est possible avec SàT, ça ne veut pas dire qu'il faut utiliser SàT pour afficher ton blog ensuite hein, c'est du XMPP et tu peux donc l'utiliser aussi avec Movim.
# Ça existe déjà
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2. Dernière modification le 28 février 2017 à 10:40.
On peut déjà trouver des plans de montage pour des téléphones pas si basiques que ça utilisant des Arduino ou autre.
Exemple: http://www.instructables.com/id/ArduinoPhone/
Plus haut le PiPhone a été cité également.
Je serais curieux de voir ce que ça donne à l'usage, y'a des gens ici qui ont essayé ?
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 1.
Sont quand même couillons chez Google, ils ont créé tout un système d'IPC alors que ça ne sert à rien sur Android, c'est bien connu.
Sont quand même couillons tous ces gens qui utilisent les autotools, cmake, scons, ant, etc.
[^] # Re: Petit sondage : pensez-vous que CloudFlare va de faire Dawinizer ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Oh, la belle prise (chez CloudFlare). Évalué à 6.
non, il voulait dire "brownsonisé" (avec un 'z')
[^] # Re: salut@toi
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 4.
C'est un serveur de test uniquement sur la machine, ceux qui installent peuvent utiliser ce qu'il veulent :).
Mais sinon comme je te l'avais déjà dit dans le journal que tu cites, la remarque est intéressante/pertinente.
# merci
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 6.
C'est une bonne surprise de voir la publication en dépêche, et avec les corrections faites (j'avais fait quelques corrections sur mon blog que je n'ai pas eu le courage de reporter sur le journal, et je vois que c'est corrigé ici).
Merci :)
[^] # Re: Cagou, Libervia, JP... STOP!
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 3.
Tu as raison, et ça a aussi été abordé dans une A.G., il a été question un moment d'utiliser Libervia pour tout, et de faire Libervia web, Libervia desktop, Libervia cli, etc.
Ce n'est pour le moment pas une solution satisfaisante pour plusieurs raisons : déjà il peut y avoir plusieurs interface web/cli/etc., ensuite les noms n'ont pas été choisis aux hasard et ça chagrinerait de les passer à la trappe, et puis ça permet de différencier des choses différentes.
« Salut à Toi » (le projet dans l'ensemble) est au final plus une base pour créer des outils cohérents, et les frontaux sont les interfaces de ces outils.
Pour faciliter le lien, on précise maintenant systématiquement
(SàT)dans les noms.Il faut voir aussi que le nom « Salut à Toi » est un pied de nez au choix quasi systématique d'un nom court, qui sonne bien, de préférence anglophone, insipide et facile à retenir, en plus de la référence aux Bérus et d'un nom qui colle bien pour un outil de communication. Note que je n'ai rien contre les noms anglophones ou faciles à retenir, c'est juste le « quasi systématique » qui est ennuyant. La graphie en montagne russe (qui n'est d'ailleurs pas dans le titre de la chanson) couplé à la présence de l'accent sont un petit plus amusant. L'accent a d'ailleurs déjà permis de lever des bogues de mauvaise gestion unicode.
Le seul petit regret que j'ai sur ce nom, c'est qu'on m'a déjà dit qu'on pensait que le projet était réservé aux francophone.
Tout ça mis à part, ça serait bien oui de simplifier pour ne pas perdre les gens qui s'intéressent au projet.
Le développement de plusieurs frontaux permet de tester et améliorer l'architecture.
C'est encore trop tôt pour présenter SàT comme une alternative (la version à venir est justement prévue pour être la première qu'on puisse vraiment proposer au grand public). D'autre part on n'est pas la seule alternative, Movim, Xabber, Conversations peuvent être proposés également.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 3.
sauf que celui que tu connais n'est peut-être pas celui qui sera utilisé. Et JS plus que tout autre écosystème demande une mise à jour permanente, et potentiellement des refactoring ou changements d'outils (je sais qu'on est vendredi).
Si tu souhaites contribuer à SàT, il vaut mieux avoir des notions de Python (c'est un « tu » général vu que tu en as déjà). À partir de là, tu sais utiliser Brython ou Pyjamas.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 4.
Le tuto lié ne parle de XEP, tu peux commencer par là pour jouer un peu.
Après implémenter une fonctionnalité XMPP, ça passe 9 fois sur 10 par une XEP, ça peut sembler difficile quand on n'en a jamais fait, mais en pratique ça ne l'est pas : ça explique juste précisément ce qu'il faut faire. Regarde celle là par exemple, tu verras que ça n'est pas si compliqué: XEP-0245.
Puis je parle aussi de CSS, de traduction, d'ouvrir la liste de tickets pour en choisir un, etc.
Il ne faut pas exagérer non plus, les contributions ne sont pas difficiles. Mercurial n'est pas plus compliqué que GIT (c'est même plus simple), et si vraiment ça pose problème on peut même s'en sortir avec un envoi du code par courriel ou XMPP, les rapports de bogue ne sont pas non plus compliqués à faire (on accepte même ceux en Français si nécessaire).
quelqu'un qui disparaît je ne vois pas trop ce que ça va changer dans une forge. Enfin de toute façon Gitlab n'est pas exclus, et il nous manque un outil de revue de code c'est vrai.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 3.
et j'oubliais dans les choses à faire (mais c'est chiant et je le ferai sûrement moi même): les tests ! On a utilisé par le passé un buildbot, mais la couverture est à revoir, ainsi que le système de tests, c'est le chantier que je comptais faire pendant la phase de bêta et que les fonctionnalités seront gelées.
[^] # Re: Divers
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Salut à Toi sur bureau et Android (Cagou), état des lieux. Évalué à 5.
salut,
Ce sont des choses à négocier, mais vu le temps que ça prend sur ma vie, il va falloir trouver une solution et celle là semble la plus réaliste à l'heure actuelle.
À une époque on avait fait une TODO list sur le wiki, mais avec le faible nombre de contributions et l'évolution constante du projet, on n'a pas maintenu. Le plus simple est de venir sur notre salon XMPP (sat@chat.jabberfr.org) pour en discuter.
Il y a quelques XEPs qui seraient sympa à implémenter (par exemple blocking command serait assez trivial à faire), ça se passe côté backend et il y a un tuto écrit ici: écrire un greffon pour SàT.
On peut aussi faire de l'amélioration de CSS (on va réécrire Libervia pour la 0.8, mais ça serait pas mal de rafraîchir), du thème (je viens de commencer à réécrire le système de thèmes pour le blog statique), de la traduction, ou prendre un bug qui semble abordable dans la liste.
Mercurial est utilisé depuis le début du projet, et bugzilla est là depuis longtemps aussi, c'est toujours utilisé parce que ça fait le boulot et que changer demande du temps qu'on consacre plutôt au code de SàT.
On a abordé l'utilisation de Gitlab/Github dans la dernière A.G. (celle dont je parle dans le journal si je ne m'abuse, du coup le résumé doit être dans ce compte-rendu), ainsi que d'implémenter l'authentification XMPP dans Bugzilla pour éviter d'avoir à créer un compte. Github a été écarté par cohérence, Gitlab reste une option.
Cependant on a toutes les briques pour faire notre propre outil de rapport de bogues basé sur XMPP maintenant (et donc décentralisé), c'est en gros une version spécialisé du blogage qu'on gère déjà (en tout cas dans notre cas pas besoin de plus, du moins pour le moment), et ça permet d'avoir un cas concret, c'est a priori ce qui va être fait dans un futur que j'espère proche.
Brython ne sera utilisé que pour l'interface Web, et devrait être beaucoup plus simple à installer que Pyjamas que nous utilisons actuellement. Ce n'est pas plus compliqué qu'apprendre un framework JS (même plutôt plus simple vu qu'on ne change pas de langage), et ça ne sera de toute façon pas utilisé pour les pages statiques.
Effectivement on a parfois un problème de communication, il ne faut pas hésiter à nous le dire et à nous demander si quelque chose n'est pas clair. C'est difficile de ne pas être technique quand on a la tête dans le code à longueur de temps, en plus sur linuxfr j'ai tendance à aller plus dans les détails qu'ailleurs.
Oui, d'ailleurs quelqu'un était venu proposer un thème CSS pour le blog statique sympa comme tout, je voulais l'intégrer mais depuis on ne le voit plus sur le salon :(. Sinon Libervia va être réécrit pour la version 0.8 (pas celle à venir, la suivante), et il va y avoir un gros coup de rafraîchissement graphique au passage.
merci !
# Réactif et super esprit
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal La première année de Liberapay. Évalué à 4.
Nous y avons ouvert un compte pour SàT après en avoir discuté en A.G., bien que nous n'ayons pas encore vraiment commencé à utiliser et communiquer dessus (ça va venir). Nous apprécions beaucoup le côté éthique et impliqué dans le libre.
Je tiens aussi à vous remercier pour votre super réactivité, j'ai demandé la gestion des liens
xmpp:, et ça a été intégré en quelques jours.Tiens petite question pratique. Nous nous sommes ajouté à la communauté « libre à toi », parce que nous nous connaissons et avons des valeurs communes, mais la page de la communauté indique « Êtes-vous un contributeur dans la communauté libratoi ? », ce qui n'est pas le cas. Le rôle des communautés c'est d'indiqué des liens/affinités ou des personnes qui participe activement à un projet ?
Bon courage, vraiment content de voir un service comme ça se développer.
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 4.
La question est très bonne, et vu de l'extérieur ça peut sembler surprenant, mais en y regardant de plus près ça n'est pas très difficile à comprendre.
Il y a déjà – et surtout – un budget bien plus important pour Matrix, et des développeurs (je ne sais pas combien, mais à vu de nez quelques uns) qui y travaillent à plein temps. C'est une très grosse boîte derrière Matrix (Amdocs). En comparaison, la plupart des clients se font sur le temps libre : Gajim c'est principalement une personne qui a peu de temps libre, Movim c'est principalement 1 seule personne aussi, pour SàT on a été temporairement 2 à plein temps (donc une grosse partie a été utilisée pour participer à des événement), mais c'est actuellement 1 seule personne sur son temps libre (moi), et on peut dire la même chose de la plupart des projets actifs (si ce n'est tous pour les clients libres, pour les serveurs c'est un peu différent).
Conversations fait figure d'exception avec 1 (seule !) personne qui arrive à être à plein temps dessus, et ça se sent dans le soin apporté dans les détails et la com', et qui contribue à son succès.
D'autre part il y a un choix du tout web en effet, et les technologies ont énormément évolué ces dernières années. La vidéo-conférence était un défi technique à la naissance de Jingle, aujourd'hui WebRTC gère toute la complexité. Je me souviens à la conf Matrix que j'avais vu au Fosdem des applaudissement nourris pour la vidéo alors que ce n'est qu'une mise en place de WebRTC, il y a aujourd'hui des très petits projets qui arrivent à faire de même.
Il faut bien se rendre compte de la complexité d'une vidéo-conférence, ce n'est pas juste envoyer un flux à un participant, il faut gérer les débits variables, annuler l'écho, gérer les codecs, adapter la transmission aux conditions, etc. Tout ceci est devenu presque trivial en web grâce aux développements de Google ou Mozilla.
Par contre sur bureau c'est toujours très compliqué, donc ça explique les difficultés des clients non web (pour notre part on met ça de côté pour le moment par exemple). Des clients s'appuyant sur des outils avancés comme Gajim avec Gstreamer, ou dont c'est une fonctionnalité principale comme Jitsi s'en sortent mais ça reste un boulot bien plus important que sur le web.
Pourquoi ne pas faire pareil pour les clients XMPP webs ? Et bien ils le font justement, Movim gère la vidéo dans le version de dév, Jappix (qui n'est plus maintenu) le faisait également, et probablement d'autres. Quand nous nous y intéresserons dans SàT, il est fort probablement que nous implémenterons en premier dans Libervia (frontal web) avec WebRTC.
Ce que j'affirme est tout de même à prendre avec des pincettes : je n'ai pas encore travaillé moi même sur la visio-conférence, aussi mon ressenti n'est peut-être pas juste.
Même en dehors de la vidéo, il y a beaucoup de problèmes qui sont plus simples aujourd'hui à gérer parce qu'il y a plus d'outils et bibliothèques disponibles, parce qu'on a plus d'outil de messageries existants dont on peut s'inspirer.
Ensuite les objectifs peuvent être différents. Pour Whatsapp le but principal évident était (et est toujours) de monétiser. Pour Matrix, je pense que c'est assez clairement le but aussi à moyen ou long terme. Ces choix font mettre les moyens et les priorités dans l'esthétique, les fonctionnalités populaires et le marketing, et on se retrouve avec X applications qui font peu ou prou la même chose et se ressemblent fortement, et qui plaisent parce que les gens s'y retrouvent.
Selon les projets, les objectifs peuvent être très différents (j'allais élaborer un peu là dessus, mais je manque de temps donc je vais finir ce message sur cette remarque).
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
le transfert de fichier est possible via Jingle, mais pas avec plusieurs destinataires en même temps.
C'est HTTP upload qui est utilisé dans ce cas (avec apparemment un chiffrement spécifique à Conversations dans certains cas).
Ce tableau est d'ailleurs incorrect, puisqu'il n'y a pas de méthode de transfert de fichier standard à l'heure actuelle avec OMEMO (il est plus ou moins au même point que OX de ce côté, avec une protoXEP en plus mais non officielle).
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
bon je rectifie, j'avais mal compris. Le fichier est envoyé normalement sur le HTTP upload, mais la clef de déchiffrement est mise dans la partie « fragment » (après le « # ») de l'URL. Du coup pas besoin d'un HTTP upload spécifique, et les clients qui gèrent ça vont avoir le fichier, pour les autres il sera illisible.
[^] # Re: Chiffrement de conversations
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
Le chiffrement de point à point (
client <==> serveur <==> MUC (conversations de groupes) <==> autres serveurs <==> autres clients) est effectivement obligatoire dans XMPP depuis plusieurs années. Le chiffrement de bout en bout est principalement utile si tu n'as pas confiance en l'un des entités entre toi et ton/tes contact(s) (donc ton serveur, le service MUC, et un des serveurs de tes correspondants).Dans le cas par exemple ou tu communiques avec un ou des proches sur le serveur que tu gères toi même (avec le service MUC très probablement sur la même machine), le chiffrement de bout en bout n'est pas utile.
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
Apparemment il utiliserait une méthode de chiffrement avec clef dans l'URL, le problème est que ça n'est pas standard et ça demande un HTTP upload spécifique, ça ne marchera donc pas avec n'importe quel serveur.
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
t'es en train de dire que Conversations est capable d'envoyer un message chiffré à plusieurs personnes en même temps ? T'es certain de ce que tu dis ?
Parce qu'à l'heure actuelle, tu peux utiliser Jingle (avec l'utilisation d'OMEMO – ce qui n'est pas standard pour le moment – comme je l'ai expliqué plus bas), mais ça n'est possible qu'entre 2 contacts, ou HTTP upload qui stocke le fichier en clair sur le service (mais la transmission est chiffrée via HTTPS), et il n'y pas (encore) de méthode (standard du moins) pour chiffrer le fichier.
Du coup je suis très étonné par ce que tu dis, est-ce que j'ai mal compris ou est-ce que tu dis bien qu'il est possible de chiffrer un fichier pour plusieurs destinataires en même temps ? Si oui ça marche pour gros et petits ? Tu fais comment (je testerai pour être sûr) ?
Gajim gère HTTP upload donc il est possible de partager un fichier, mais je veux bien que ça ne fonctionne pas avec Jingle vu que Gajim utilise une version obsolète (et conversation ne gère probablement pas Stream Initiation, ce qui n'est pas plus mal).
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 3.
J'ai fait une belle faute surtout (saine) :)
Il y a eu une petite tension entre Matrix et la communauté XMPP l'année dernière (et un peu l'année d'avant), parce que pour se faire connaître ils se sont mis sur un angle d'attaque très agressif envers XMPP, que ce soit dans les interventions (par exemple au FOSDEM il y a 2 ans, là où j'ai entendu parler d'eux la première fois d'ailleurs) ou par écrit.
Le problème n'est pas tant la critique en soit, c'est aussi qu'ils ont propagé un certains nombre de fausses vérités, notamment sur leur FAQ (qui n'est d'ailleurs toujours pas terrible même si c'est mieux) au point que la communauté a dû répondre, par exemple avec cette page (ainsi que des réponses sur différents réseaux).
À ça s'ajoute des gens (a priori des groupies, même si on ne sait pas trop si c'est des gens impliqués dans le projet ou pas) qui font de la propagande systématiquement pour Matrix dès qu'un article un peu visible parle de XMPP (en particulier sur hackernews ou reddit, mais on a vu des remarques désagréables même ici). Là encore pas vraiment un problème de parler d'un projet, mais quand c'est sous pour insinuer que XMPP est dépassé (ce qui est faux) et que l'herbe est plus verte chez eux, forcément à force c'est fatiguant.
Enfin bref, maintenant que Matrix est plus connu ça s'est un peu calmé, et c'est préférable de voir qu'il est possible de collaborer.
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 7. Dernière modification le 26 janvier 2017 à 16:54.
OMEMO a été basé historiquement sur libsignal, et la première proposition de XEP a été faite avec.
Cette proposition a été rejetée parce que :
De leur côté, les gens de Matrix ont développé Olm, standardisé et sans les problèmes mentionnés, il a donc été retenu pour une nouvelle proposition de OMEMO, cette fois acceptée.
Un exemple où Matrix et XMPP peuvent collaborer, une relation un peu plus seine que ce qu'on a vu l'année dernière.
Seulement il y a un « standard » de fait avec la première version de OMEMO (pas celle de la XEP donc), car c'est celle utilisée par Conversations et tout le monde veut être compatible avec.
De son côté, Conversations est bloqué pour passer à Olm parce qu'il n'y a pas encore de bibliothèque Java.
Les nouvelles implémentations partent actuellement toutes sur la version brouillon à cause de ce standard de fait, mais il ne devrait pas être difficile de passer d'une version à l'autre une fois que tout le reste est en place (interface utilisateur, gestion des messages chiffrés, autre XEPs nécessaires à l'utilisation, etc). Il est aussi tout à fait possible de fournir les 2 versions en même temps, mais aucun client ne le fait à l'heure actuelle.
Autre changement, une documentation de Double Ratchet a été mise dans le domaine public entre temps, donc il est possible de repasser à une implémentation basée dessus. J'ai suivi cette partie de loin, mais je sais qu'il est question d'en discuter au XMPP summit qui aura lieu ce week-end.
Tout ça va rapidement se stabiliser, il y a une petite excitation sur le sujet en ce moment , mais d'ici quelques mois ça devrait être stable.
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche ChatSecure 4.0 ronronne et adopte OMEMO . Évalué à 8.
ça dépend de ce que tu entends par là.
Le téléversement de photos fonctionne avec Gajim, Conversation (je ne sais pas pour ChatSecure) et avec une bonne partie des clients activement développés. Le problème est que sauf si tu maîtrises ton propre serveur (ou si tu fais confiance aux admins), tu ne sais pas qui peut voir ces photos, combien de temps c'est stocké, et tu ne peux pas les supprimer (ce qui est – me semble-t-il – le cas sur la plupart des plateforme de messagerie, XMPP ou pas, si vous avez des contre-exemples je veux bien des infos).
L'envoi en pair à pair est disponible au moins sur Gajim, je pense que Conversations implémente Jingle et ChatSecure je ne sais pas. Gajim malheureusement utilise une ancienne version du protocole.
Plus d'infos sur l'envoi en pair à pair dans les épisode 9 et épisode 10 de parlons XMPP.
Pour le chiffrement des fichiers en pair à pair, je crois que Conversations utilise une méthode non standard avec OMEMO (proposée à la standardisation mais pas retenue), et il n'y a pas encore de méthode standard (il y a une méthode utilisant TLS qui devrait avoir un numéro officiel mais qui semble perdue).
Enfin pour l'envoi avancé (sous forme d'album), il y a des extensions permettant un début d'implémentation, mais rien de concret à ma connaissance. Ça devrait être un de nos chevaux de bataille pour 2017 avec SàT.