En très gros, une archi centralisée est plus simple sur le plan technique (sauf pour cas particuliers comme la montée en charge), mais pose des problèmes de gouvernance, gestion des données, etc.
Ring est une architecture entièrement P2P, c'est à dire sans serveur central (je n'ai pas regardé le détail, mais c'est ce que j'en ai compris). Ça a ses avantages, mais ses inconvénients aussi : le client doit faire le boulot du serveur, ce qui impacte la bande passante, la charge processeur – et donc la durée de vie de la batterie sur appareils portatifs –, etc. Le problème mentionné ici (pas de message hors ligne) est une des conséquences de cette archi (on pourrait y remédier avec des serveurs intermédiaires, des super nœuds ou autre, mais ça complique beaucoup et demande là encore des ressources).
XMPP est une architecture « hybride » (décentralisée avec possibilité de faire du P2P, voire d'être entièrement en P2P – sans serveur –), ce qui donne une grande souplesse.
Ring a l'air intéressant sur le papier, il faudrait que je trouve le temps de le tester. J'ai l'impression qu'on peut le rapprocher de Retroshare.
pour l'audio/vidéo avec XMPP, tu peux regarder du côté de Jitsi (dont c'est la fonctionnalité principale), et Movim l'implémente également. Pour SàT c'est prévu pour la 0.8 (pas la version à venir, la suivante, mais j'espère pouvoir augmenter le rythme des sorties après le gros chantier qu'à été la 0.7).
Le TURN n'est pas obligatoire, c'est juste utilisé si les autres cartouches n'ont pas fonctionné pour établir la connexion P2P.
Sinon je n'ai pas encore essayé Ring même si j'en ai entendu parlé depuis longtemps, il faudra que je teste ça.
Bonjour et bravo pour ce travail et superbe outil !
Est-ce que G'MIC serait utilisable dans un logiciel non spécialisé traitement d'image, je pense notamment à l'application de filtres rapides pour des photos (sur téléphone par exemple) sans ouvrir un logiciel lourd ? Je n'ai pas regardé le code/la taille générale des bibliothèques, est-ce lourd à embarquer ?
D'autre part je me demandais si ça pouvait être utilisé pour générer un Diaporama vidéo (par exemple en donnant un effet photo papier, ou vieux film) ?
On l'utilise aussi pour Salut à Toi, et j'apprécie beaucoup que l'équipe est accessible (on les retrouve sur des réseaux libres, ou dans les communautés libres en général, ici notamment), et l’anonymat (qui fait que ce sont vraiment des dons, et pas des achats cachés ou du sponsoring).
Pour ma part je pourrais déjà, mon opérateur me permet d'avoir mon numéro en SIP. Enfin pour les appels sortant, pour la réception ça n'est pas possible (là du coup la redirection du tél est intéressante).
Je connais et j'ai vaguement utilisé quelques fois comme passerelle SMS. Le côté modulaire est super, mais il y a plusieurs choses qui me chagrinent :
c'est pas simple à mettre en place pour quelqu'un pas technophile (application principale + extension(s), configuration du compte, etc.)
ça sous exploite XMPP. Il se comporte plus comme un bot que comme une entité XMPP, j'aurais aimé voir des commandes ad-hoc plutôt que des trucs à taper à la main, une séparation propre des commandes et du texte (pas 2 espaces, des espaces de noms XML dédiés)
j'aurais aimé que ça se comporte comme une passerelle, pour intégration invisible côté client (avec par exemple [numero]@tel.[monserver.tld] pour joindre mes contacts).
MAM serait top pour avoir les archives SMS côté serveur
là ça demande de travailler sur une XEP, mais une découverte/configuration automatique sur réseau local faciliterait grandement les choses
En comparaison, kde connect est loin devant (facile à installer, détection automatique sur réseau local, utilisation intégrée à KDE).
Ça reste un super projet, qui a une architecture bien pensée et qui a un gros potentiel. J'espère qu'il va continuer sur sa lancée. À terme ça serait génial qu'on puisse intégrer ça dans nos clients.
Dans un pays anglophone, on lui répondrait de suite que c'est nom commun, pas protégeable pour le coup.
T'es sûr de ton coup ? Parce qu'il y a quand même un bon paquet de boîtes pas si petites qui ont des noms que je qualifierai de plutôt communs de fruits, de parties de maisons qui permettent de faire passer la lumière, de guerrières de la mythologie, de trombinoscope, et j'en passe.
(tiens j'ai inversé l'URL et le texte clair dans mon précédent message)
J'ai déjà été en contact avec un dév de Diaspora qui a contribué à ActivityPub (Jason), mais je pense que les 2 protocoles sont partis pour vivre leur vie séparément (je vois mal comment on peut faire pour collaborer à ce point, les technos sont assez différentes).
Il est surtout important de faire des passerelles, les différents réseaux libres doivent pouvoir communiquer ensemble. Si j'avais de quoi dégager du temps je serais déjà dessus, mais avec mon rythme actuelle, il va falloir attendre un peu.
Là je t'avoue que je n'en sais pas grand chose. Au niveau XMPP ça se passe entre l'IETF pour les RFCs de base (et des choses bas niveau comme https://tools.ietf.org/html/rfc7395) et la XSF qui a autorité sur les extensions (les fameuses XEPs). Je ne connais pas les liens exacts entre W3C et IETF.
Ce qui m'intéresse c'est d'avoir un standard libre et relativement bien fait, et j'espère que ça ne se tire pas dans les pattes volontairement (avoir la main sur un standard donne un pouvoir, c'est pour ça qu'il faut faire très attention à ce qu'on utilise).
ActivityPub ré-invente la roue en refaisant ce que fait déjà XMPP depuis longtemps, et c'est fort dommage, du coup on se retrouve avec un standard de plus alors qu'on aurait pu unir nos efforts.
Cette remarque faite, j'ai jeté un œil au protocole, et je pense qu'il serait assez facile de faire une passerelle XMPP, et du coup les sites communiqueraient ensemble au prix de ressources supplémentaires (faire des passerelles a un coût par rapport à une communication native, même si a priori je ne pense pas que ça serait énorme dans ce cas). Aussi si plusieurs sites suivent ActivityPub, ça simplifierait le travail (un seul protocole supplémentaire à gérer).
En tout cas j'aimerais faire une passerelle ActivityPub, mais il faudrait pour cela que la version ait suffisamment de succès pour que j'ai de l'aide sur le développement.
Dernière petite note: je trouve vraiment dommage d'inclure les notions de « like » et « followers » dans la base du protocole, c'est vraiment se calquer sur ce qui a été imposé par les réseaux propriétaires.
Libervia inclus un serveur HTTP, donc ça serait intéressant de prendre ça en compte à ce niveau aussi, mais c'est à voir bien plus tard.
Oui côté serveur XMPP et service Pubsub ça serait très intéressant aussi. Il y a déjà eu un peu de travail dessus dans le passé au niveau des salons de discussions (avec distributed MUC et federated MUC). Disons que ça n'est pas la priorité à l'heure actuelle, mais ça pourrait en devenir une dans le futur, surtout si on arrive à transformer l'essai avec le version à venir et qu'on a un peu d'aide (pour mémoire: je suis le seul développeur actif pour le moment).
Est-ce qu'il y a une notion de redondance, haute-disponibilité ? Si un site ("service"?) tombe que se passe t-il?
Pas pour le moment, le framework en est à son début, on verra en fonction des besoins/demandes/ressources disponibles. Il ne se destine, pour le moment du moins, pas à des sites qui ont besoin de haute disponibilité : il y a besoin de maturité, tests en production, etc. avant ça.
J'aimerais bien intégrer ces notions à XMPP même pour commencer, en particulier à Pubsub.
Vraiment super d'utiliser XMPP pour autre chose que de la messagerie instantanée, et de le montrer. Tes articles sont super didactiques en plus. J'ai hâte d'en lire d'autres :)
Goffi, avec tout le respect que j'ai pour toi et crois-moi ou non, en attendant avec impatience de voir sat-pubsub et Libervia sur Yunohost, je dois te répondre que tu te contredis:
il n'y a aucun problème à ne pas être d'accord, j'aime bien discuter ;)
La technologie Web « WebRTC » hérite et s'inspire de ce travail.
L'API webRTC s'appuie sur des standards existants comme STUN, ICE, TURN, DTLS ou encore SRTP, technologies en parties issues du projet libjingle.
mais jingle sert à la gestion du signal (« signaling »), là où webRTC gère la gestion des périphériques, les filtres très difficiles à faire comme l'annulation d'écho et le flux, ils sont complémentaires, cf. la XEP que j'ai mentionné dans mon commentaire.
Gajim et Pidgin, par exemples, ont implémenté Jingle-vv, et ça ne marche pas avec WebRTC!
Jingle peut fonctionner avec WebRTC, mais également sans. On choisi le transport.
Je ne reproche pas que le standard évolue. Ce que je reproche, c'est ça: […]
je comprends que c'est frustrant vue de l'extérieur. Mais 4 ans ce n'est pas énorme du tout pour un standard (regarde côté technos web le temps que ça prend avec les énormes équipes qui sont dessus pour les implémentations), et Jingle est complètement d'actualité et je ne vois aucune raison que ça change dans un futur proche. Le problème ce sont les clients : la plupart des clients publics actifs sont des projets faits sur le temps libre, pas d'équipe payées, et du coup ça prend du temps. Je pense qu'il est difficilement d'imaginer le boulot que c'est, et chaque client a ses priorités. Ça fait longtemps que j'aimerais bien implémenter le vidéo par exemple, mais j'ai préféré travailler sur d'autre choses avant (même une vidéo en WebRTC one2one je pourrais la faire assez vite, en quelques jours je pense, mais ça serait quelques jours pris sur autre chose). Jitsi lui a mis la vidéo en priorité et a des dévs salariés : là ça tourne.
Il y a aussi beaucoup de client non public, XMPP est très utilisé en entreprise (on ne le soupçonne pas jusqu'à ce qu'on s'en rende compte dans les meetings et salons). Je l'ai déjà vu utiliser pour surveiller du trafic de tramway, pour du monitoring, je sais que c'est utilisé pour des communications satellites ou dans de la haute sécurité, mais ce n'est pas visible du public.
MIX, la prometteuse prochaine génération de salon, "arrive bientôt" depuis déjà 1an.
On prend la même recette qui fait fuir les utilisateurs et on recommence?
À ma connaissance, MIX n'est une priorité pour aucun projet actif actuel. C'est dans les cartons et ça avance à son rythme mais MUC tourne correctement pour le moment. Moi même je pense que ça va être une grosse avancée, mais que ça n'est pas indispensable à l'heure actuelle (Pubsub est nettement plus intéressant à court terme à mon avis).
Donc le standard, ça va être d'en avoir 2??
oui, même plus que 2.
Pour faire un standard, il faut prendre des décisions, même difficiles, même si ça veut dire que certaines choses ne seront pas optimales, même si ça veut dire sacrifier des possibilités.
Ça sera très probablement OMEMO qui sera utilisé par la plupart des clients. C'est au client de prendre les décisions pour simplifier la vie à l'utilisateur en fonction de son cas d'usage, et l'utilisateur n'a pas forcément besoin de savoir qu'il y a plusieurs méthodes. Qu'il y ait d'autres méthodes disponibles ne pose pas de problème si c'est bien géré par le client.
C'est dingue non? Une équipe trouve des ressources et suscite un gros enthousiasme chez un nombre d'utilisateurs non négligeable, se fait réclamer pour une implémentation dans un projet d'OS pour téléphone Libre, en utilisant les technos XMPP alors que les projets XMPP galèrent à trouver des contributeurs et n'ont que très peu de financement.
Ça devrait faire réfléchir, non?
Matrix ils sont issus de la même boîte et ont eu un gros financement permettant d'avoir des salariés à plein temps pendant plusieurs mois, c'est énorme et change complètement la donne. Tu fais la même chose avec n'importe quel protocole correct tu arrives à un résultat similaire. Ils sont très bons en marketing aussi, et ont les moyens (ils ont réussi à avoir un stand au Fosdem la première fois que je les ai vu + conf de 1 h avec alors qu'ils étaient inconnus, et faisaient le show avec un robot radiocommandé), et visiblement les contacts (gageons que l’association avec Purism ne s'est pas faite sur la simple visite du site). Tant mieux pour eux.
Je pense qu'un projet comme Movim, vu l'énergie, la stabilité et le résultat actuel a de quoi décoller, mais il y a aussi un facteur chance et réseau de connaissances. On verra ce que ça va donner.
Pour SàT c'est un cas très particulier, puisqu'on a se coupe volontairement de certaines sources qui pourraient nous aider (Fb, Twitter ou Github par exemple), et qu'on ne veut pas du modèle startup ou d'actionnaires : on a un projet politique.
On a aussi fait certains mauvais choix (on aurait dû faire des versions utilisables plus tôt plutôt que préparer une version « grand public » depuis des années), et on ne sait pas communiquer correctement (je vois régulièrement des projets apparaître qui font ce qu'on fait déjà ou ce qu'on pourrait faire facilement, et qui repartent de zéro, l'exemple actuel c'est les événements qui sont implémentés chez nous et qui vont être refaits de zéro chez Framasoft, et des cas comme ça j'en ai vu passer des tas).
Donc étonnés pas vraiment, et réfléchir on le fait (crois moi c'est souvent difficile moralement et physiquement non seulement pour ceux qui ont choisi de faire ça, mais pour l'entourage également).
Je t'invite à lire le parlons XMPP expliquant Jingle parce que tu n'as visiblement pas du tout compris comment ça fonctionne. WebRTC ne remplace pas Jingle il s'utilise avec, et il n'est certainement obsolète (ah la manie de toujours vouloir tout jeter).
Il n'y a toujours pas non plus de consensus autour du chiffrage bout-à-bout (OX? OMEMO?).
Il n'y a pas à choisir l'un ou l'autre, les 2 ont des propriétés différentes, et les 2 sont à garder.
Purism choisit Matrix/Riot pour le client messagerie/voix/vidéo + chiffrage bout-à-bout, parce que tout ce qu'ils veulent est déjà là.
Tout est tellement déjà là que la voix et la vidéo c'est Jitsi, et donc XMPP et Jingle (ils ont été les chercher dans la poubelle).
As tu regardé du côté de Jitsi ? Il fait déjà la partage d'écran, il peut servir de base. Je ne sais pas s'il peut être facilement extensible, mais ça vaut le coup d'y jeter un œil. Le Jitsi videobridge est une option pour diffuser la vidéo à plusieurs utilisateurs.
Je pense qu'il y a quand même beaucoup de boulot, même si tu trouves une bonne base. Tout ce qui touche à la vidéo peut prendre facilement du temps, surtout si tu veux bien sécuriser ça. Jette un œil aux bibliothèques disponibles pour voir celles qui gèrent Jingle.
J'aurais pu te conseiller SàT sur lequel je travaille, mais on ne fait pas encore de vidéo et ça ne sera pas la cas avant la prochaine sortie, donc plusieurs mois. Par contre on gère déjà chiffrement, commandes, et Jingle (mais par pour la vidéo encore).
Il me semblait bien que JabberFr autorisait les nom de domaines perso, mais j'ai demandé confirmation pour être sûr, voilà ce qu'on m'a répondu :
Faut juste nous contacter pour nous communiquer le nom de domaine, et faire pointer un CNAME (ou un SRV, mais du coup le certificat ne sera pas valide parce qu’on utilise Let’s Encrypt).
Et bien sûr, une adresse email de contact.
le(s) compte(s) utilisateur à créer (ça n'utilise pas les comptes UNIX).
jette un œil au modules mod_auth_* sur https://modules.prosody.im/ qui permettent d'avoir des méthodes alternatives pour utiliser des comptes existants (il y a notamment un module PAM, à tester).
Les mots de passe sont en clair par défaut sur Prosody, mais on peut les hasher, c'est expliqué sur leur site : http://prosody.im/doc/plain_or_hashed
Pour OpenPGP j'ai expliqué plus haut (la 0027 est à éviter, mais il y a une version moderne et propre, appelée OX).
Les différents chiffrements ont différentes propriétés, j'ai commencé à écrire un article pour expliquer ça, mais je n'ai pas eu le temps de le finir. En gros OTR ne permet de communiquer qu'avec un seul appareil, OMEMO le permet et gère la confidentialité persistance et OX gère plusieurs appareils sans la confidentialité persistante (mais du coup permet d'avoir les archives sur le serveur). Après c'est le rôle du client de rentre ces notions le plus simple et pratique possible pour l'utilisateur, sans sacrifier la sécurité.
Prosody il vaut mieux utiliser la version à jour. Si tu es sur Debian ou dérivée, tu as un dépôt officiel avec les versions à jour, c'est expliqué sur la doc officielle. C'est très facile à installer.
sont des pré-requis : il faut utiliser OMEMO (PGP est déprécié, et OTR ne permet pas 2., cf mes autres commentaires).
Petite correction, PGP n'est pas déprécié, c'est la XEP historique (c.-à-d. qui a été implémentée au début et qui n'a pas fait l'objet d'un processus normal de standardisation, mais qui décrit un état de fait) qui l'est. La version moderne, propre et sécurisée s'appelle OX, c'est la XEP-0373.
Pour le reste je lis les commentaires, beaucoup de critiques sont justifiées, pas toutes.
Il faut toutefois garder à l'esprit, comme cela a été dit par ailleurs, que la plupart des projets sont développés sur le temps libre, et que chaque fonctionnalité prend un temps fou.
Par exemple dans notre cas (SàT), c'est actuellement un seul développeur actif (moi, avec 1 jour/semaine dédié au projet, et 4 à un boulot salarié qui n'a rien à voir).
Pour donner des exemples : au moment d'implémenter le chiffrement de bout en bout l'état de l'art était OTR, ce qui a désormais changé (il est question bien sûr d'implémenter OMEMO et OX, mais je ne peux pas tout faire en même temps). Une implémentation dans notre cas et dans le cas particulier du chiffrement de bout en bout signifie en fait 2 implémentations : une dans le backend pour les plupart des frontaux, et une en javascript pour le frontal web. De même la vidéo est prévue depuis longtemps, et la base est déjà faite (jingle), mais il y a eu d'autre priorités qui devaient passer avant, surtout qu'il existe déjà des solutions satisfaisantes compatibles (Jitsi).
Movim c'est principalement un seul dév également, Gajim c'est du même ordre, Conversations c'est un seul dév mais à temps plein (il en vit), etc. Matrix de son côté à eu un budget conséquent avec une dizaine de salariés à temps plein (sauf erreur), forcément ça aide à avoir une solution plus léchée.
Un des objectifs de SàT (l'asso) est de développer une activité économique pour que déjà je puisse me salarier, puis si possible embaucher du monde, mais nous voulons faire ça selon nos principes éthiques/politiques et évoluer vers une coopérative à terme (SCOP ou similaire) en autogestion. Si nous y arrivons, ça changera complètement la donne (et ma vie, puisque c'est un investissement sur mon temps qu'il est je pense difficile d'imaginer).
oui même inquiétude (j'ai écris la même chose plus bas avant de voir ton message).
Pour le recyclage j'avais vu il y a 2/3 ans des systèmes qui broyaient le plastique et le recompressait pour ré-utiliser une partie des déchets (je n'ai pas le lien sous la main mais ça doit se retrouver assez facilement), c'est mieux mais pas génial (toujours une perte, plastique recyclé évidemment de moins bonne qualité, et énergie nécessaire pour la transformation).
Est-ce qu'il y a des imprimantes libres qui travaillent en usinant du bois par exemple ? Ou utilisant d'autres matériaux moins nocifs que les plastiques ?
j'avais acheté une Smartrap suite à ton journal d'il y a 3 ans, et j'en étais très content (mais ça demande du calibrage). Je m'en étais servi pour refaire une pièce manquante sur un lave vaisselle (avec FreeCAD qui est super, il mériterait une dépêche tuto), plus pour le fun parce que je savais que ça n'allait pas tenir avec la chaleur, mais la pièce fonctionnait (tout comme une vis au final qui elle tient la chaleur).
Là j'ai toujours l'imprimante mais elle est démontée suite à un déménagement, et je n'ai vraiment pas le temps de la remettre en état à l'heure actuelle (puis au final, j'ai pas grand chose d'important à imprimer).
Mais du coup je me demande pourquoi tu en as racheté une ? L'idée n'était pas qu'on puisse réparer et faire évoluer cette imprimante en imprimant les nouvelles pièces ? Quel intérêt d'en prendre une autre ? Imprimer plus d'un coup ? Autre ?
C'est génial pour ce que ça ouvre au niveau créativité ou réparations etc., mais par contre je suis un peu inquiet des conséquences écologiques, il est assez prévisible qu'on va voir exploser des impressions plastiques plus ou moins inutiles qui finiront pour beaucoup à la poubelle.
# centralisé/décentralisé/P2P/Hybride
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Ring, un logiciel de communication universel. Évalué à 9.
J'en profite pour placer un article que j'avais écrit il y a 2 ans pour expliquer la différence entre centralisé/décentralisé etc. : centralisé, décentralisé, P2P, mais c'est quoi tout ça ?.
En très gros, une archi centralisée est plus simple sur le plan technique (sauf pour cas particuliers comme la montée en charge), mais pose des problèmes de gouvernance, gestion des données, etc.
Ring est une architecture entièrement P2P, c'est à dire sans serveur central (je n'ai pas regardé le détail, mais c'est ce que j'en ai compris). Ça a ses avantages, mais ses inconvénients aussi : le client doit faire le boulot du serveur, ce qui impacte la bande passante, la charge processeur – et donc la durée de vie de la batterie sur appareils portatifs –, etc. Le problème mentionné ici (pas de message hors ligne) est une des conséquences de cette archi (on pourrait y remédier avec des serveurs intermédiaires, des super nœuds ou autre, mais ça complique beaucoup et demande là encore des ressources).
XMPP est une architecture « hybride » (décentralisée avec possibilité de faire du P2P, voire d'être entièrement en P2P – sans serveur –), ce qui donne une grande souplesse.
Ring a l'air intéressant sur le papier, il faudrait que je trouve le temps de le tester. J'ai l'impression qu'on peut le rapprocher de Retroshare.
[^] # Re: Intéressant !
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Ring, un logiciel de communication universel. Évalué à 5.
Salut,
pour l'audio/vidéo avec XMPP, tu peux regarder du côté de Jitsi (dont c'est la fonctionnalité principale), et Movim l'implémente également. Pour SàT c'est prévu pour la 0.8 (pas la version à venir, la suivante, mais j'espère pouvoir augmenter le rythme des sorties après le gros chantier qu'à été la 0.7).
Le TURN n'est pas obligatoire, c'est juste utilisé si les autres cartouches n'ont pas fonctionné pour établir la connexion P2P.
Sinon je n'ai pas encore essayé Ring même si j'en ai entendu parlé depuis longtemps, il faudra que je teste ça.
# Est-ce utilisable pour des filtres légers ?
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche G’MIC : 2.2, v’là les filtres !. Évalué à 2.
Bonjour et bravo pour ce travail et superbe outil !
Est-ce que G'MIC serait utilisable dans un logiciel non spécialisé traitement d'image, je pense notamment à l'application de filtres rapides pour des photos (sur téléphone par exemple) sans ouvrir un logiciel lourd ? Je n'ai pas regardé le code/la taille générale des bibliothèques, est-ce lourd à embarquer ?
D'autre part je me demandais si ça pouvait être utilisé pour générer un Diaporama vidéo (par exemple en donnant un effet photo papier, ou vieux film) ?
merci
[^] # Re: Retour d'expérience
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche La deuxième année de Liberapay. Évalué à 10.
On l'utilise aussi pour Salut à Toi, et j'apprécie beaucoup que l'équipe est accessible (on les retrouve sur des réseaux libres, ou dans les communautés libres en général, ici notamment), et l’anonymat (qui fait que ce sont vraiment des dons, et pas des achats cachés ou du sponsoring).
J'espère voir l'intégration d'XMPP dans les comptes externes arriver bientôt :).
[^] # Re: XMPP pas assez exploité
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Le Projet MAXS: Modular Android XMPP Suite. Évalué à 5.
Pour ma part je pourrais déjà, mon opérateur me permet d'avoir mon numéro en SIP. Enfin pour les appels sortant, pour la réception ça n'est pas possible (là du coup la redirection du tél est intéressante).
# XMPP pas assez exploité
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Le Projet MAXS: Modular Android XMPP Suite. Évalué à 10.
Je connais et j'ai vaguement utilisé quelques fois comme passerelle SMS. Le côté modulaire est super, mais il y a plusieurs choses qui me chagrinent :
En comparaison, kde connect est loin devant (facile à installer, détection automatique sur réseau local, utilisation intégrée à KDE).
Ça reste un super projet, qui a une architecture bien pensée et qui a un gros potentiel. J'espère qu'il va continuer sur sa lancée. À terme ça serait génial qu'on puisse intégrer ça dans nos clients.
[^] # Re: Avant, l'affaire des "annu"
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Free-electrons se fait attaquer en justice par Free, et change de nom. Évalué à 10.
T'es sûr de ton coup ? Parce qu'il y a quand même un bon paquet de boîtes pas si petites qui ont des noms que je qualifierai de plutôt communs de fruits, de parties de maisons qui permettent de faire passer la lumière, de guerrières de la mythologie, de trombinoscope, et j'en passe.
[^] # Re: A propos des accès aux banques
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 4.
Et ils l'utilisent en production pendant ce temps donc ? Ça ne me semble pas très compatible avec l'AGPL cette histoire.
[^] # Re: Interopérabilité avec le Social Web ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 1.
s/actuelle/actuel/
[^] # Re: Interopérabilité avec le Social Web ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 4.
(tiens j'ai inversé l'URL et le texte clair dans mon précédent message)
J'ai déjà été en contact avec un dév de Diaspora qui a contribué à ActivityPub (Jason), mais je pense que les 2 protocoles sont partis pour vivre leur vie séparément (je vois mal comment on peut faire pour collaborer à ce point, les technos sont assez différentes).
Il est surtout important de faire des passerelles, les différents réseaux libres doivent pouvoir communiquer ensemble. Si j'avais de quoi dégager du temps je serais déjà dessus, mais avec mon rythme actuelle, il va falloir attendre un peu.
[^] # Re: Interopérabilité avec le Social Web ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 5.
Là je t'avoue que je n'en sais pas grand chose. Au niveau XMPP ça se passe entre l'IETF pour les RFCs de base (et des choses bas niveau comme https://tools.ietf.org/html/rfc7395) et la XSF qui a autorité sur les extensions (les fameuses XEPs). Je ne connais pas les liens exacts entre W3C et IETF.
Ce qui m'intéresse c'est d'avoir un standard libre et relativement bien fait, et j'espère que ça ne se tire pas dans les pattes volontairement (avoir la main sur un standard donne un pouvoir, c'est pour ça qu'il faut faire très attention à ce qu'on utilise).
[^] # Re: Interopérabilité avec le Social Web ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 9. Dernière modification le 28 janvier 2018 à 14:36.
ActivityPub ré-invente la roue en refaisant ce que fait déjà XMPP depuis longtemps, et c'est fort dommage, du coup on se retrouve avec un standard de plus alors qu'on aurait pu unir nos efforts.
Cette remarque faite, j'ai jeté un œil au protocole, et je pense qu'il serait assez facile de faire une passerelle XMPP, et du coup les sites communiqueraient ensemble au prix de ressources supplémentaires (faire des passerelles a un coût par rapport à une communication native, même si a priori je ne pense pas que ça serait énorme dans ce cas). Aussi si plusieurs sites suivent ActivityPub, ça simplifierait le travail (un seul protocole supplémentaire à gérer).
En tout cas j'aimerais faire une passerelle ActivityPub, mais il faudrait pour cela que la version ait suffisamment de succès pour que j'ai de l'aide sur le développement.
Dernière petite note: je trouve vraiment dommage d'inclure les notions de « like » et « followers » dans la base du protocole, c'est vraiment se calquer sur ce qui a été imposé par les réseaux propriétaires.
[^] # Re: des exemples?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 6. Dernière modification le 26 janvier 2018 à 12:43.
Libervia inclus un serveur HTTP, donc ça serait intéressant de prendre ça en compte à ce niveau aussi, mais c'est à voir bien plus tard.
Oui côté serveur XMPP et service Pubsub ça serait très intéressant aussi. Il y a déjà eu un peu de travail dessus dans le passé au niveau des salons de discussions (avec distributed MUC et federated MUC). Disons que ça n'est pas la priorité à l'heure actuelle, mais ça pourrait en devenir une dans le futur, surtout si on arrive à transformer l'essai avec le version à venir et qu'on a un peu d'aide (pour mémoire: je suis le seul développeur actif pour le moment).
[^] # Re: des exemples?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Construisez un web décentralisé avec Salut à Toi et XMPP !. Évalué à 5. Dernière modification le 26 janvier 2018 à 12:19.
oui, mon blog, c'est à dire l'interface web de SàT. Tu peux voir le code sur repos.goffi.org (en particulier la partie pages servers et les modèles correspondant.
Pas pour le moment, le framework en est à son début, on verra en fonction des besoins/demandes/ressources disponibles. Il ne se destine, pour le moment du moins, pas à des sites qui ont besoin de haute disponibilité : il y a besoin de maturité, tests en production, etc. avant ça.
J'aimerais bien intégrer ces notions à XMPP même pour commencer, en particulier à Pubsub.
# Spectrum2
Posté par Goffi (site web personnel, Mastodon) . En réponse au message Connecteurs Whatsapp / fb messenger XMPP. Évalué à 2.
Spectrum2 permet d'utiliser libpurple et ses greffons, du coup jette un œil à https://developer.pidgin.im/wiki/ThirdPartyPlugins et à http://spectrum.im/documentation/backends/libpurple.html pour voir ce qui peut t'intéresser. Je n'utilise pas moi même, je ne peux pas t'aider plus que ça.
# super
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Errol: Envoyer automatiquement des fichiers avec XMPP. Évalué à 10.
Vraiment super d'utiliser XMPP pour autre chose que de la messagerie instantanée, et de le montrer. Tes articles sont super didactiques en plus. J'ai hâte d'en lire d'autres :)
[^] # Re: Mouaif
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Campagne de financement d’eelo pour un smartphone respectueux de la vie privée. Évalué à 4.
il n'y a aucun problème à ne pas être d'accord, j'aime bien discuter ;)
J'ai écris cette phrase suite à ce que j'ai lu sur le sujet sur Wikipédia :
mais jingle sert à la gestion du signal (« signaling »), là où webRTC gère la gestion des périphériques, les filtres très difficiles à faire comme l'annulation d'écho et le flux, ils sont complémentaires, cf. la XEP que j'ai mentionné dans mon commentaire.
Jingle peut fonctionner avec WebRTC, mais également sans. On choisi le transport.
je comprends que c'est frustrant vue de l'extérieur. Mais 4 ans ce n'est pas énorme du tout pour un standard (regarde côté technos web le temps que ça prend avec les énormes équipes qui sont dessus pour les implémentations), et Jingle est complètement d'actualité et je ne vois aucune raison que ça change dans un futur proche. Le problème ce sont les clients : la plupart des clients publics actifs sont des projets faits sur le temps libre, pas d'équipe payées, et du coup ça prend du temps. Je pense qu'il est difficilement d'imaginer le boulot que c'est, et chaque client a ses priorités. Ça fait longtemps que j'aimerais bien implémenter le vidéo par exemple, mais j'ai préféré travailler sur d'autre choses avant (même une vidéo en WebRTC one2one je pourrais la faire assez vite, en quelques jours je pense, mais ça serait quelques jours pris sur autre chose). Jitsi lui a mis la vidéo en priorité et a des dévs salariés : là ça tourne.
Il y a aussi beaucoup de client non public, XMPP est très utilisé en entreprise (on ne le soupçonne pas jusqu'à ce qu'on s'en rende compte dans les meetings et salons). Je l'ai déjà vu utiliser pour surveiller du trafic de tramway, pour du monitoring, je sais que c'est utilisé pour des communications satellites ou dans de la haute sécurité, mais ce n'est pas visible du public.
À ma connaissance, MIX n'est une priorité pour aucun projet actif actuel. C'est dans les cartons et ça avance à son rythme mais MUC tourne correctement pour le moment. Moi même je pense que ça va être une grosse avancée, mais que ça n'est pas indispensable à l'heure actuelle (Pubsub est nettement plus intéressant à court terme à mon avis).
oui, même plus que 2.
Ça sera très probablement OMEMO qui sera utilisé par la plupart des clients. C'est au client de prendre les décisions pour simplifier la vie à l'utilisateur en fonction de son cas d'usage, et l'utilisateur n'a pas forcément besoin de savoir qu'il y a plusieurs méthodes. Qu'il y ait d'autres méthodes disponibles ne pose pas de problème si c'est bien géré par le client.
Matrix ils sont issus de la même boîte et ont eu un gros financement permettant d'avoir des salariés à plein temps pendant plusieurs mois, c'est énorme et change complètement la donne. Tu fais la même chose avec n'importe quel protocole correct tu arrives à un résultat similaire. Ils sont très bons en marketing aussi, et ont les moyens (ils ont réussi à avoir un stand au Fosdem la première fois que je les ai vu + conf de 1 h avec alors qu'ils étaient inconnus, et faisaient le show avec un robot radiocommandé), et visiblement les contacts (gageons que l’association avec Purism ne s'est pas faite sur la simple visite du site). Tant mieux pour eux.
Je pense qu'un projet comme Movim, vu l'énergie, la stabilité et le résultat actuel a de quoi décoller, mais il y a aussi un facteur chance et réseau de connaissances. On verra ce que ça va donner.
Pour SàT c'est un cas très particulier, puisqu'on a se coupe volontairement de certaines sources qui pourraient nous aider (Fb, Twitter ou Github par exemple), et qu'on ne veut pas du modèle startup ou d'actionnaires : on a un projet politique.
On a aussi fait certains mauvais choix (on aurait dû faire des versions utilisables plus tôt plutôt que préparer une version « grand public » depuis des années), et on ne sait pas communiquer correctement (je vois régulièrement des projets apparaître qui font ce qu'on fait déjà ou ce qu'on pourrait faire facilement, et qui repartent de zéro, l'exemple actuel c'est les événements qui sont implémentés chez nous et qui vont être refaits de zéro chez Framasoft, et des cas comme ça j'en ai vu passer des tas).
Donc étonnés pas vraiment, et réfléchir on le fait (crois moi c'est souvent difficile moralement et physiquement non seulement pour ceux qui ont choisi de faire ça, mais pour l'entourage également).
[^] # Re: Mouaif
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Campagne de financement d’eelo pour un smartphone respectueux de la vie privée. Évalué à 3.
Je t'invite à lire le parlons XMPP expliquant Jingle parce que tu n'as visiblement pas du tout compris comment ça fonctionne. WebRTC ne remplace pas Jingle il s'utilise avec, et il n'est certainement obsolète (ah la manie de toujours vouloir tout jeter).
Il n'y a pas à choisir l'un ou l'autre, les 2 ont des propriétés différentes, et les 2 sont à garder.
Tout est tellement déjà là que la voix et la vidéo c'est Jitsi, et donc XMPP et Jingle (ils ont été les chercher dans la poubelle).
[^] # Re: XMPP, ou pas
Posté par Goffi (site web personnel, Mastodon) . En réponse au message Utiliser XMPP pour un logiciel réseau. Évalué à 3.
sur un réseau local, du broadcast serait sans doute plus approprié pour une diffusion de vidéo, comme dit par ailleurs.
Si tu veux que ça fonctionne à distance, alors oui XMPP pourrait être utilisé, notamment via Jingle (cf. https://linuxfr.org/users/goffi/journaux/parlons-xmpp-episode-10-copie-de-fichiers-et-jingle-suite), et son chiffrement.
As tu regardé du côté de Jitsi ? Il fait déjà la partage d'écran, il peut servir de base. Je ne sais pas s'il peut être facilement extensible, mais ça vaut le coup d'y jeter un œil. Le Jitsi videobridge est une option pour diffuser la vidéo à plusieurs utilisateurs.
Je pense qu'il y a quand même beaucoup de boulot, même si tu trouves une bonne base. Tout ce qui touche à la vidéo peut prendre facilement du temps, surtout si tu veux bien sécuriser ça. Jette un œil aux bibliothèques disponibles pour voir celles qui gèrent Jingle.
J'aurais pu te conseiller SàT sur lequel je travaille, mais on ne fait pas encore de vidéo et ça ne sera pas la cas avant la prochaine sortie, donc plusieurs mois. Par contre on gère déjà chiffrement, commandes, et Jingle (mais par pour la vidéo encore).
Bon courage !
# Nom de domaine perso avec Jabber Fr
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Retour d’expérience (et tuto) XMPP. Évalué à 4.
Il me semblait bien que JabberFr autorisait les nom de domaines perso, mais j'ai demandé confirmation pour être sûr, voilà ce qu'on m'a répondu :
[^] # Re: Pas convaincu
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Retour d’expérience (et tuto) XMPP. Évalué à 4.
jette un œil au modules
mod_auth_*sur https://modules.prosody.im/ qui permettent d'avoir des méthodes alternatives pour utiliser des comptes existants (il y a notamment un module PAM, à tester).[^] # Re: Pas convaincu
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Retour d’expérience (et tuto) XMPP. Évalué à 3.
Les mots de passe sont en clair par défaut sur Prosody, mais on peut les hasher, c'est expliqué sur leur site : http://prosody.im/doc/plain_or_hashed
Pour OpenPGP j'ai expliqué plus haut (la 0027 est à éviter, mais il y a une version moderne et propre, appelée OX).
Les différents chiffrements ont différentes propriétés, j'ai commencé à écrire un article pour expliquer ça, mais je n'ai pas eu le temps de le finir. En gros OTR ne permet de communiquer qu'avec un seul appareil, OMEMO le permet et gère la confidentialité persistance et OX gère plusieurs appareils sans la confidentialité persistante (mais du coup permet d'avoir les archives sur le serveur). Après c'est le rôle du client de rentre ces notions le plus simple et pratique possible pour l'utilisateur, sans sacrifier la sécurité.
Prosody il vaut mieux utiliser la version à jour. Si tu es sur Debian ou dérivée, tu as un dépôt officiel avec les versions à jour, c'est expliqué sur la doc officielle. C'est très facile à installer.
[^] # Re: Rester loin d'XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Retour d’expérience (et tuto) XMPP. Évalué à 10.
Petite correction, PGP n'est pas déprécié, c'est la XEP historique (c.-à-d. qui a été implémentée au début et qui n'a pas fait l'objet d'un processus normal de standardisation, mais qui décrit un état de fait) qui l'est. La version moderne, propre et sécurisée s'appelle OX, c'est la XEP-0373.
Pour le reste je lis les commentaires, beaucoup de critiques sont justifiées, pas toutes.
Il faut toutefois garder à l'esprit, comme cela a été dit par ailleurs, que la plupart des projets sont développés sur le temps libre, et que chaque fonctionnalité prend un temps fou.
Par exemple dans notre cas (SàT), c'est actuellement un seul développeur actif (moi, avec 1 jour/semaine dédié au projet, et 4 à un boulot salarié qui n'a rien à voir).
Pour donner des exemples : au moment d'implémenter le chiffrement de bout en bout l'état de l'art était OTR, ce qui a désormais changé (il est question bien sûr d'implémenter OMEMO et OX, mais je ne peux pas tout faire en même temps). Une implémentation dans notre cas et dans le cas particulier du chiffrement de bout en bout signifie en fait 2 implémentations : une dans le backend pour les plupart des frontaux, et une en javascript pour le frontal web. De même la vidéo est prévue depuis longtemps, et la base est déjà faite (jingle), mais il y a eu d'autre priorités qui devaient passer avant, surtout qu'il existe déjà des solutions satisfaisantes compatibles (Jitsi).
Movim c'est principalement un seul dév également, Gajim c'est du même ordre, Conversations c'est un seul dév mais à temps plein (il en vit), etc. Matrix de son côté à eu un budget conséquent avec une dizaine de salariés à temps plein (sauf erreur), forcément ça aide à avoir une solution plus léchée.
Un des objectifs de SàT (l'asso) est de développer une activité économique pour que déjà je puisse me salarier, puis si possible embaucher du monde, mais nous voulons faire ça selon nos principes éthiques/politiques et évoluer vers une coopérative à terme (SCOP ou similaire) en autogestion. Si nous y arrivons, ça changera complètement la donne (et ma vie, puisque c'est un investissement sur mon temps qu'il est je pense difficile d'imaginer).
[^] # Re: Quelle(s) solution(s) pour les "déchets" ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal J'ai acheté une imprimante 3D (presque open source) à 150€. Évalué à 4.
oui même inquiétude (j'ai écris la même chose plus bas avant de voir ton message).
Pour le recyclage j'avais vu il y a 2/3 ans des systèmes qui broyaient le plastique et le recompressait pour ré-utiliser une partie des déchets (je n'ai pas le lien sous la main mais ça doit se retrouver assez facilement), c'est mieux mais pas génial (toujours une perte, plastique recyclé évidemment de moins bonne qualité, et énergie nécessaire pour la transformation).
Est-ce qu'il y a des imprimantes libres qui travaillent en usinant du bois par exemple ? Ou utilisant d'autres matériaux moins nocifs que les plastiques ?
# Pour avoir changé ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal J'ai acheté une imprimante 3D (presque open source) à 150€. Évalué à 5.
Salut,
j'avais acheté une Smartrap suite à ton journal d'il y a 3 ans, et j'en étais très content (mais ça demande du calibrage). Je m'en étais servi pour refaire une pièce manquante sur un lave vaisselle (avec FreeCAD qui est super, il mériterait une dépêche tuto), plus pour le fun parce que je savais que ça n'allait pas tenir avec la chaleur, mais la pièce fonctionnait (tout comme une vis au final qui elle tient la chaleur).
Là j'ai toujours l'imprimante mais elle est démontée suite à un déménagement, et je n'ai vraiment pas le temps de la remettre en état à l'heure actuelle (puis au final, j'ai pas grand chose d'important à imprimer).
Mais du coup je me demande pourquoi tu en as racheté une ? L'idée n'était pas qu'on puisse réparer et faire évoluer cette imprimante en imprimant les nouvelles pièces ? Quel intérêt d'en prendre une autre ? Imprimer plus d'un coup ? Autre ?
C'est génial pour ce que ça ouvre au niveau créativité ou réparations etc., mais par contre je suis un peu inquiet des conséquences écologiques, il est assez prévisible qu'on va voir exploser des impressions plastiques plus ou moins inutiles qui finiront pour beaucoup à la poubelle.