Ça m'étonne de n'en avoir encore rien lu ici alors que d'ordinaire, je ne suis pas celui qui suit les actualités de Matrix de si près.
D'après les récentes informations relayées par NextInpact, mais aussi un peu partout dans les médias, comme ici, dans le Monde Informatique, l'État français compte se doter d'ici cet été de son propre système de messagerie instantanée.
Et ce service sera basé sur Matrix/Riot!
De ce que je comprends le choix s'est fait sur les critères suivants:
- indépendance vis-à-vis de toute entreprise, ça nécessite donc un système décentralisé
- messagerie, voix et vidéo
- apparemment multiplateforme, vu que j'ai cru voir passer (oui, ça c'est de l'info solide) des références au soutien du projet dans les activités Riot-Mobile
- chiffrement bout-à-bout
C'est évidemment un formidable coup de pub pour Matrix, Riot et New Vector, la société montée pour poursuivre le développement du projet.
On ne peut que se féliciter de voir un système Libre et décentralisé réaliser une telle percée.
Et apparemment d'autres administrations seraient également intéressées: Pays-Bas et Canada, pour ne pas les nommer.
Tout ça pourrait bien faire boule de neige.
Cela dit, ce succès m'inquiète légèrement aussi, en raison d'un grief que j'ai depuis presque le début contre le protocole lui-même: les salons et tout le trafic sont répliqués sur les serveurs de chaque participant, ce qui permettrait à un salon de survivre si le serveur qui l'a vu naître tombait, mais ce qui entraîne aussi des charges monstrueuses pour les serveurs légers dès qu'un salon devient trop fréquenté.
Conséquence: un "petit" serveur est de facto exclu des salons les plus populaires, et c'est assez pénible pour tous ceux qui sont auto-hébergés ou disposent d'un serveur personnel.
Cette situation pourrait s'améliorer grandement avec l'arrivée de Dendrite, le nouveau serveur écrit en Go qui remplacerait l'unique serveur de production actuel Synapse, écrit en Python.
À suivre!
# IRC
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
L'équipe de développement de Matrix n'utilise pas Matrix, mais IRC. Ça en dit long sur la qualité de la solution…
https://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-irc
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: IRC
Posté par feth . Évalué à 5.
Je trouve aussi qu'il est difficile de faire plus efficace qu'IRC une fois que le pas est franchi, et matrix / slack / mattermost ont l'avantage de faire moins peur.
[^] # Re: IRC
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
On ne le répètera jamais assez, mais le top de l'efficacité pour incuber l'excellence par messagerie de groupe, c'est https://linuxfr.org/board
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: IRC
Posté par THE_ALF_ . Évalué à 10.
Difficile de ne pas sortir ça :)
[^] # Re: IRC
Posté par gnumdk (site web personnel) . Évalué à 6.
Je ne suis pas sur de comment on doit comprendre cela.
Peut être plutôt qu'ils utilisent la passerelle IRC afin de communiquer entre eux plutôt que directement utiliser un "Channel" Matrix.
En effet, difficile d'aider les nouveaux venus directement sur Matrix si ils n'arrivent pas à s'y connecter ;)
Perso, j'ai découvert dernièrement https://github.com/dino/dino qui est un client XMPP permettant le chiffrement en utilisant le protocole de chiffrement de signal. Bon, par contre, il faut que l'utilisateur distant soit sous Dino aussi.
[^] # Re: IRC
Posté par seveso . Évalué à 7.
En fait Dino supporte le chiffrement bout-en-bout avec d'autres clients XMPP du moment qu'ils implémentent OMEMO.
Aujourd'hui ça inclut notamment Gajim sur PC (Window/Linux), Conversations sur Android, Chatsecure sur iOS.
[^] # Re: IRC
Posté par Amandine . Évalué à 4.
Cela vient surtout du fait qu’on n’a pas mis à jour nos FAQ depuis le lancement de Matrix en 2014 :) Je peux assurer que Matrix avec Riot est aujourd’hui notre principal moyen de communication. Si il arrive à certains d’utiliser IRC parfois c’est pour principalement coordonner l’operationnel lorsque le serveur Matrix.org est tombé.
[^] # Re: IRC
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Pourquoi ne pas mettre un serveur matrix de secours?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Coquilles
Posté par showtime . Évalué à 4.
chiffrage => chiffrement (https://fr.wikipedia.org/wiki/Chiffrement)
exclus => exclu
[^] # Re: Coquilles
Posté par Maclag . Évalué à 4.
Effectivemage!
Si un modérateur voulait bien corriger…
[^] # Re: Coquilles
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Corrigé, merci.
# Risques ?
Posté par showtime . Évalué à 0.
Autant je trouve que c'est une idée géniale de vouloir s'affranchir des logiciels étrangers / propriétaires / centralisés, autant je me dis que ça a l'air trop beau pour être vrai et je me questionne sur le conflit d'intérêt évident du gouvernement.
Quels sont donc selon vous les risques que soient introduites des backdoors ?
Et donc que les conversations des utilisateurs ne soient pas si confidentielles que ça…
Quelle confiance le citoyen lambda doit-il accorder dans une telle solution ?
Mais tout, il paraît que c'est l'armée américaine qui a développé Tor…
[^] # Re: Risques ?
Posté par Maclag . Évalué à 5.
Bon, j'ai mis les réserves dont je parlais plus haut sur Matrix, mais celui-là, je doute que ce soit un vrai problème:
Tant que le code des serveurs et clients est Libre, il suffit d'utiliser d'autres serveurs que celui de l'Etat, et d'autres clients que celui qu'ils distribuent.
En fait, si le chiffrement bout-à-bout est en place, on peut même tolérer une incertitude sur le serveur. Dans les faits, ça revient à un Whatsapp public: ils sauraient toujours qui parle à qui, quand et combien de temps.
Donc moi je garde mon serveur perso (avec les limites expliquées ci-dessus).
C'est tout l'avantage de la solution Libre et décentralisée.
[^] # Re: Risques ?
Posté par ckyl . Évalué à 5.
En même temps c'est pas comme si tu avais eu le choix ;)
Toutes les sources que j'ai vu parlent bien d'un développement & infra maison pour les besoins maison. Celui d'une partie de l'état français d'assurer la confidentialité de ses échanges.
Pas de devenir éditeur logiciel ou fournisseur SaaS pour ses citoyens.
[^] # Re: Risques ?
Posté par Maclag . Évalué à 3.
Reformulons:
Supposant que le serveur et client soient mis à disposition du public, voudrais-je remplacer le serveur que j'ai en place aujourd'hui?
La réponse est non. Je garde celui que j'ai, le Synapse officiel, jusqu'à ce que Dendrite soit proposé sur Yunohost.
[^] # Re: Risques ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6.
Ouaip et il paraitrait même que c'est aussi à l'armée américaine qu'on doit Internet…
[^] # Re: Risques ?
Posté par Yth (Mastodon) . Évalué à 7.
Oui, d'ailleurs Louis Pouzin est un alias pour John Paul Smith, officier de l'armée américaine, infiltré en France pour donner le change pendant qu'il contribuait aux fondations de ce qui allait devenir internet.
[^] # Re: Risques ?
Posté par reynum (site web personnel) . Évalué à 3. Dernière modification le 20 juillet 2018 à 16:00.
Internet tel qu'on le connais, pas directement mais la structure en toile d'araignée (résistante à la perte d'un nœud) oui, et il me semble qu'un protocole bas niveau (peut être ARP ou IP) aussi mais le reste non.
kentoc'h mervel eget bezan saotred
[^] # Re: Risques ?
Posté par flan (site web personnel) . Évalué à 6.
quel conflit d'intérêt ?
L'État a besoin d'une messagerie interne qu'il maîtrise réellement et le met donc en place, en s'appuyant logiquement sur un composant qui ne lui coûte rien ou presque plutôt que de réinventer la roue.
Maintenant, ça ne coûte rien de le mettre à disposition de n'importe qui, donc autant le faire, mais il ne faut pas oublier que ce n'est absolument pas le but premier de la manœuvre.
[^] # Re: Risques ?
Posté par dinomasque . Évalué à 8.
L'état Français a besoin d'une solution de communication confidentielle et dans le même temps a besoin de briser la confidentialité des échanges pour ses activités de surveillance.
BeOS le faisait il y a 20 ans !
[^] # Re: Risques ?
Posté par Misc (site web personnel) . Évalué à 4.
Mais, je suis le seul à comprendre que ça va être un truc par le gouvernement, pour le gouvernement ? Genre, pourquoi ça serait connecté sur le réseau public, ou accessible par les citoyens ?
J'ai pas accès au PABX d'un ministère, je vois pas en quoi ça serait différent à ce niveau.
[^] # Re: Risques ?
Posté par flan (site web personnel) . Évalué à 3.
C’est pourtant ce qui a été expliqué.
Cela dit, ils ont peut-être voulu dire que le serveur (au sens code source) serait disponible.
# Pas tant de ressources
Posté par dani . Évalué à 2.
Pour utiliser Matrix depuis quelques mois, il ne faut pas tant de ressources que ça pour joindre les plus gros salons. Une VM avec 3Go de RAM, 2vCPU, et quelques Go de stockage pour la BDD et c'est bon. Certes, c'est plus que pour du Jabber, mais ça reste accessible à presque n'importe qui. Par contre, il faut déployer un serveur postgresql. SQLite3 lui ne suit pas
[^] # Re: Pas tant de ressources
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10.
Personnellement, pour héberger un "simple" salon de chat, je trouve ça déjà beaucoup… Mais c'est certainement parce que je suis psycho-rigide et trop vieux.
Ou alors, c'est parce que j'aime pas trop Python, c'est selon.
D'ailleurs, sur ce dernier point, je trouve que coder un serveur réseau complet en Python s'approche plus du masochisme qu'autre chose et que du coup, j'ai toujours très peur pour la maintenance du-dit serveur.
[^] # Re: Pas tant de ressources
Posté par barmic . Évalué à 6.
twistted est fait pour ça. Qu'est-ce qui te dérange en python pour ça ? (d'ailleurs c'est quoi un serveur réseau complet ?)
Le réseau est tout de même relativement simple à tester et on peut souvent trouver des tests de conformité totalement indépendant de ton langage.
[^] # Re: Pas tant de ressources
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 24 avril 2018 à 17:34.
Ce qui me dérange, c'est plus Python tout court.
Personnellement, on a un code Python en maintenance évolutive dont même le concepteur initial a du mal à retrouver tous les tenants et aboutissants et la personne a qui j'ai confié la maintenance et dont c'est le premier développement en Python galère et peste contre le langage.
Pour moi, Python, c'est très bien pour coder un petit truc sur le pouce mais ça devient vite l'horreur passé plusieurs milliers de lignes de code et plusieurs années.
Après, on va me parler de tests unitaires et tutti quanti mais là, une application fortement interfacée avec l'extérieur via des micros et qui charge des modèles de langues de plusieurs gigas en RAM, c'est juste très chiant à automatiser.
Alors, ne nous méprenons pas, cela n'est que mon point de vue.
Certes mais il reste que ma confiance en Python quand je lance un programme reste très limitée et c'est pas les stacktrace qui apparaissent silencieusement dans la console qui me rassurent :)
Je préfèrerai être plus confiant dès le démarrage sans me dire que je vais avoir le droit à un :
C'est pour ça que je préfère les langages compilés.
[^] # Re: Pas tant de ressources
Posté par barmic . Évalué à 10.
C'est plus que ça. C'est une extrapolation à partir d'un bout d’expérience personnel. J'ai des amis qui travaillent sur du code ADA et dont la maintenance est en enfer quotidien. Chaque nouvelle fonctionnalité est une plaie à ajouter. Est-ce que pour autant je viens t'expliquer qu'ADA est un langage qui de mon point de vu est affreux à maintenir ?
Il y a suffisamment de projets en python d'envergure pour que je n'ai même pas à argumenter en quoi tu es biaisé. Il y a des projets bien plus grands que tout ce que n'importe qui ici pourra coder dans sa vie qui sont écrit en python et qui s'en portent pas si mal. Ils ont en plus la particularité d'accueillir de tout comme contributeurs.
Moi aussi j'aime le typage le plus expressif possible et je rechigne à utiliser des langages dont le typage est dynamique (pire s'ils sont faiblement typés), mais pourquoi est-ce que j'irais expliquer à d'autres ce comment est-ce qu'ils devraient faire ou ne pas faire les choses ? Ou même les juger ?
[^] # Re: Pas tant de ressources
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Je n'en doute absolument pas et je n'ai jamais dit que cela serait forcément mieux en Ada. Une fois de plus, il s'agit de mon point de vue basé sur mon expérience.
Dommage, je ne pense pas être si obtus au point de ne pas pouvoir comprendre ce que tu pourrais argumenter.
En dehors de ça, le biais, c'est assez naturel quand on donne un avis basé sur sa propre expérience.
Personnellement, si je n'ai pas l'expérience, je ne donne pas mon avis.
Des exemples ? C'est juste pour ma culture personnelle, n'y vois aucune agression.
Donc, cela m'interdit de dire que je préfèrerai pour des raisons de performances et de maintenance que cela fait dans un autre langage ?
Alors oui, je sais rien ne m'empêche d'en coder un en C++/Ada/Ocaml/Java… Non Java, c'est un mauvais exemple :D
[^] # Re: Pas tant de ressources
Posté par barmic . Évalué à 5.
Un peu quand même quand tu juge un langage à partir d'un projet unique et d'une expérience unique.
Le problème n'est pas d'en avoir ou pas : on en a tous. Ce qui est bien c'est de le savoir et de le prendre en compte.
Prends une quelconque vidéo faite pour nous montrer comment les américains sont bêtes. La première réaction peut très bien être que trouver qu'ils sont stupides, mais on peut essayer de réfléchir 3 minutes avant de republier la vidéo sur le réseau social de ton choix avec le commentaire « LOL sont trop cons ! ».
Je ne sais pas dans quelle partie est-ce que google search et youtube utilisent python.
En cherchant un peu je vois que 80% du backend de spotify est en python, qu'Amazon s'en sert pour le calcul de recommandation ou Facebook pour la manipulation d'images.
Après tu as des projets open source :
Ça commence à faire un paquet de lignes de code :)
Du tout, mais ce n'est pas ce que tu as dis.
[^] # Re: Pas tant de ressources
Posté par Victor STINNER (site web personnel) . Évalué à 7.
OpenStack tout court. Càd plusieurs millions de ligne de code.
https://www.openhub.net/p/openstack
"In a Nutshell, OpenStack has had 942,125 commits made by 10,764 contributors representing 9,105,385 lines of code"
75% de Python
[^] # Re: Pas tant de ressources
Posté par Olivier . Évalué à 7.
N’importe quoi.
Le projet dont tu parles est un bordel difficile à maintenir, et c’est la faute à Python ?
On peut pondre un projet merdique avec des stacktraces dégueulasses dans tous les langages…
Après, on peut préférer un langage compilé, mais c’est une autre affaire.
[^] # Re: Pas tant de ressources
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Merci
Sans problème, d'ailleurs, le langage n'est que la concrétisation d'une conception qui peut effectivement être de merde.
Voilà, en fait, c'est ça, je préfère les langages compilés et verbeux mais je le dis depuis le début que ce n'est que mon avis.
[^] # Re: Pas tant de ressources
Posté par Albert_ . Évalué à 1. Dernière modification le 25 avril 2018 à 10:12.
Ah is ils avaient utilise haskell/C++/lisp et que le nouveau dev soit fan de Java ou C# cela aurait beaucoup plus simple…
J'adore la critique sur le language quand je vois plus un probleme de methode de dev et de recrutement… Mettre un novice du langage comme mainteneur du logiciel c'est un peu … ose je vais dire.
[^] # Re: Pas tant de ressources
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 0.
Non mais au moins, C++ approche plus de garde-fous mais c'est ma préférence pour les angages compilés qui parle.
Méthode de développement ? Je n'ai pas parlé de la méthode développement utilisé donc je me demande comment tu peux juger la façon dont le développement est géré.
Quant au recrutement, si on ne recrute que des gens expérimentés, ça laisse pas beaucoup de place aux jeunes alors franchement, que justement, sur un projet en maintenance évolutive, c'est un poil moins grave de mettre le pied à l'étrier à un junior.
[^] # Re: Pas tant de ressources
Posté par Albert_ . Évalué à 5. Dernière modification le 25 avril 2018 à 10:43.
mais bon au dessus, tu as ecris:
Apres tu me permettras de totalement extrapole sur la methode:
et je vais rajouter:
Les etudes recentes (meme par les concepteurs de ces methodes) montrent que le code "agile" et bien souvent non maintenable…
Cela depend de comment tu programmes, perso je vois plus de garde fous en Python dans mon domaine que en C++ et vu comment tu peux faire de 15 facons differentes un truc en C++, je trouve cela bien plus problematique pour transferer la maintenance a quelqu'un et je parle par experience.
Donc la je vois et je me repette plus un probleme de facon de developper (je ne critique pas, je constate parfois tu n'as pas le choix vu les contraintes) et de casting pour le nouveau dev (il y a des jeunes gradues qui apprennent python ca j'en suis sur et certain).
[^] # Re: Pas tant de ressources
Posté par barmic . Évalué à 3.
Ça c'est discutable. Tu peux faire n'importe quoi de la mémoire en C++ sans jamais faire lever le moindre sourcil à ton compilateur. Tu peux avoir de jolies attaques par buffer overflow sans jamais avoir eu le moindre warning.
Parce qu'on ne développe pas en R de la même façon qu'en assembleur. Quand on choisi un langage il vaut probablement mieux embrasser ce langage et donc prendre en compte les méthodes de la communauté de ce langage. Par exemple quand tu parle de C++ tu considère probablement que les gars vont forcément utiliser les pointeurs intelligents et la RAII. C'est loin d'être automatique.
[^] # Re: Pas tant de ressources
Posté par feth . Évalué à 2.
Je me permets de citer pour qu'on relise, tellement c'est poétique
[^] # Re: Pas tant de ressources
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Merci de reconnaitre mon âme de poète :D
[^] # Re: Pas tant de ressources
Posté par feth . Évalué à 3.
As-tu pensé à envoyer la sortie de ton script dans festival ?
$ python3 monapp.py | festival --tts
[^] # Re: Pas tant de ressources
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
Ça foutrait trop le bordel dans la synthèse vocale existante mais je vais essayer de penser à trapper les exceptions au plus haut pour les envoyer au bout de code qui va bien 😀
Vu qu'on gère la concurrence, ça sera plus propre 😉
[^] # Re: Pas tant de ressources
Posté par Amandine . Évalué à 7.
Oui comme mentionné ci-dessous, Synapse est un proto qui a évolué en produit. A l’époque (Il y a 4 ans) on cherchais un langage relativement mature et avec une communauté assez grande (plus probablement des besoins techniques qui m’échappent, mais je peux me renseigner). La mauvaise nouvelle c’est qu’on voit bien sur matrix.org les limites de support de la charge. La bonne nouvelle c’est qu’on a un serveur 2ème génération en GoLang en développement, mais il ne sera pas prêt avant quelques mois, donc on est en train de faire énormément d’améliorations de performance et Synapse devient bien plus productif.
[^] # Re: Pas tant de ressources
Posté par Maclag . Évalué à 10.
Pour comparer:
Avec 2Go de RAM, 1 CPU à 1core, et 500Go de stockage, je fais tourner un serveur XMPP qui me permet d'accéder à n'importe quel salon XMPP
et mon serveur mail (+webmail, bien entendu)
et mon serveur Nextcloud
et d'autres petits services que j'ajoute et j'enlève au gré de mes essais et humeurs
(Merci à Yunohost de rendre toutes ces tâches triviales!)
et j'utilise juste une partie des ressources!
Alors je pense qu'il n'y a pas de miracle à attendre pour l'espace de stockage (ça dépend des salons et de leur "volume", ça ne dépend pas du serveur), je pense qu'il y a moyen de faire mieux au niveau des ressources.
Synapse est écrit en Python et c'est le prototype. Je ne doute pas qu'il y a une marge de progression.
Mais pour te situer: nombre d'auto-hébergés ont des listes de service similaires à la mienne, et font rentrer tout ça sur un Raspberry Pi!
Si Matrix avait l'option de participer à un salon sans dupliquer intégralement le salon sur son serveur, ça serait quand même beaucoup plus accessible.
[^] # Re: Pas tant de ressources
Posté par 16aR . Évalué à -1.
Seulement, le gros problème de XMPP pour ma part, c'est le côté super random de la sauvegarde de l'historique (auquel je tiens, personnellement), problème réglé sur matrix.
Et c'est ça en moins à gérer/sauver/envoyer pour un terminal mobile, ce qui est aussi dans leur design il me semble.
[^] # Re: Pas tant de ressources
Posté par seveso . Évalué à 8.
Je ne crois pas que ce soit une fonctionnalité définie dans protocole XMPP ça. Peut-être fais-tu référence à des défauts d'implémentation alors. Dans ce cas je serais curieux d'apprendre comment matrix a résolu ce soucis (en ne codant aucun bug me diras-tu).
En tout cas sache que depuis quelques années les serveurs XMPP modernes supportent MAM (Message Archive Management). À l'usage c'est un peu l'équivalent des boites mail en IMAP : l'historique des échanges est stocké côté serveur. Ce qui fait que lorsque tu installes un nouveau client XMPP il sera capable de t'afficher l'historique de tes précédents échanges.
Et ça marche plutôt bien.
[^] # Re: Pas tant de ressources
Posté par dani . Évalué à 2.
Les spec que j'ai donné ne représentent pas la capacité nécessaire en continu. Mais elles permettent d'absorber le pic de charge quand un utilisateur joint un "gros" salon. Avec un plus petit dimensionnement ça va marcher aussi, le temps de jonction sera juste plus important. Ça reste accessible à pratiquement n'importe qui, c'est pas du tout réservé aux "gros".
[^] # Re: Pas tant de ressources
Posté par Yves (site web personnel) . Évalué à 7.
C’est énorme. Aucun R.Pi ou autre SBC (PC sur carte électronique) ne fournit ça à prix abordable. Perso, avec un UdooX86 à un peu plus de 100€, j’ai « juste » 2Go de RAM.
Sans compter qu’en auto-hébergement, la capacité du serveur est partagée en de multiples tâches (NAS, mail, web, chat, SGBD…)
[^] # Re: Pas tant de ressources
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pourquoi c'est si lourd de récupérer un gros salon?
Avec 100 personnes qui envoient 1000 messages de 100 octets dans une journée (soit un trafic délirant), ça fait moins de 10mo pour récupérer un historique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tant de ressources
Posté par dani . Évalué à 1.
Parce qu'il n'y a pas que les messages, il y a énormément de meta données aussi
[^] # Re: Pas tant de ressources
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le protocole doit être sacrément LOURD!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas tant de ressources
Posté par Albert_ . Évalué à 3.
Je ne connais pas matrix donc je vais surement dire une connerie mais si c'est un peu comme slack vu que tu peux joindre des documents comme des images, des pdf, des docx… les messages peuvent assez vite exploser en taille.
# État français
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à -4.
L’État_français, ça fait très Vichy…
[^] # Re: État français
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 9.
Effectivement, la pastille est dure à avaler :)
[^] # Re: État français
Posté par Maclag . Évalué à 7.
Ah, celle-là je ne l'avais pas vue venir.
Pour moi ça reste l'Etat Français. Ce n'est pas parce que le gouvernement de Vichy s'en est donné le nom que ça doit être un gros mot.
D'ailleurs, Vichy n'a pas changé de nom et on ne lynche pas les gens qui déclarent y vivre.
[^] # Re: État français
Posté par Larry Cow . Évalué à 4.
Même pas à coups de pastilles?
[^] # Re: État français
Posté par rdhlnn . Évalué à 4.
Surtout que cet "Etat Français" adopte Riot… Quel climat social ?
[^] # Re: État français
Posté par warwick . Évalué à 3.
Si tu as un passeport, il y est ecrit en page 32 que celui-ci est propriete de l’Etat francais.
[^] # Re: État français
Posté par claudex . Évalué à 6.
Pas sur le mien.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: État français
Posté par Larry Cow . Évalué à 10.
C'est le problème avec les contrefaçons… ;)
[^] # Re: État français
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Ah toi tu dois avoir la version avec les faisceaux sur la couverture ! Ça fait très fasciste tout ça.
ce commentaire est sous licence cc by 4 et précédentes
# Mouais
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Il y a eu un appel d'offre pour ça ?
Non, la décentralisation et la dépendance à une entreprise ne sont pas liés (sauf si on n'est pas dans du libre et que le seul serveur est géré par une entreprise). Si tu as un serveur IRC chez toi, tu n'es pas décentralisé mais tu n'es pas non plus dépendant d'une entreprise.
Et pour le coup, c'est justement un des gros problèmes que j'ai avec Matrix (avec leurs attaques gratuites de XMPP même si ça s'est un peu calmé), c'est à l'heure actuelle très dépendant d'une entreprise, il n'y a aucune implémentation alternative (à ma connaissance, corrigez moi si je me trompe), et bien qu'ils veulent en faire une association indépendante (si je me souviens bien), pour l'instant le protocole est aussi contrôlé par une seule entreprise. Autrement dit on est très loin du compte pour l'indépendance vis à vis de toute entreprise.
leur interface est jolie et apparemment complète (je n'utilise pas). Mais la vidéo c'est Jitsi (et donc XMPP) ou webRTC, du coup je me demande pourquoi Jitsi a été écarté vu qu'il rempli tous les critères.
Bref, c'est bien de voir le libre enfin pris en compte, mais je suis dubitatif pour le choix, et je me demande dans quelles conditions il a été pris. C'est dommage pour la communauté XMPP.
[^] # Re: Mouais
Posté par Maclag . Évalué à 10.
Je comprends que tu sois amer, mais en même temps c'est pas comme si il y avait des choses nouvelles dans les raisons qui ont fait adopter une solution Matrix plutôt que XMPP.
J'ai beaucoup de sympathie pour les projets XMPP, et je garde aussi mon serveur XMPP, et j'espère toujours voir débarquer SàT sur Yunohost.
Mais je pense que tu râles sur le mauvais forum.
Reprenons:
Bonne question. Perso, je n'en sais rien, mais:
-en bas d'une certaine somme, les appels d'offre ne sont pas obligatoires
-de ce que j'ai compris, le but est d'avoir le savoir-faire en interne, peut-être qu'ils embauchent des dévs et développent un fork interne: 0 dépense à l'extérieur
-peut-être aussi qu'ils ont abusé, ce ne serait pas la première fois qu'un gouvernement marche un peu sur les règles, mais par défaut je ne vais pas leur tomber dessus tout de suite
OK, j'utilise peut-être mal les mots. Je pensais "décentralisé" dans le sens le serveur n'est pas central et unique au monde. J'aurais dit décentralisé mais pas forcément fédéré, mais tu as compris l'idée: avoir son propre serveur
Indépendant d'une entreprise ça ne veut pas dire que tu "attends" l'entreprise. Ça veut dire que tu peux en changer si ça te chante.
Si New Vector pète un câble et que l'administration veut une nouvelle fonctionnalité, ils peuvent alors lancer un appel d'offre et établir un protocole fork de Matrix, un fork du serveur, un fork du client. Ils peuvent même rendre le tout public.
Je dirais que New Vector n'a pas vraiment intérêt à les froisser…
Ah, et j'ai cru comprendre qu'il y a un projet de serveur en Rust hors entreprise, mais faut voir ce que ça prendra pour "suivre" la cadence de New Vector sur leurs solutions de référence.
Il y a aussi des clients alternatifs, mais pareillement: aucun qui puisse suivre la cadence de Riot.
Oui, et? Du point de vue de l'utilisateur ou du sélectionneur de solution, ce qui compte c'est bien que la fonctionnalité soit présente. Même si ça prend des grands coups de XMPP.
Jitsi n'a pas de version Android (abandonnée depuis un moment) ni iOS. Pour le côté multi-plateforme, c'est raté.
Et c'est ce que j'ai écrit de nombreuses fois au sujet d'XMPP:
Absence d'un "champion" côté client qui satisfasse ces conditions:
-messagerie, salons, voix, vidéo
-multiplateformes
-le chiffrement bout-à-bout devient quasiment obligatoire en cette époque
Où en est XMPP?
-Absolument aucun client ne répond à ces critères malgré la plus grande ancienneté du protocole.
Le seul qui l'ait jamais fait, c'est Whatsapp, preuve que le protocole n'est pas le problème.
Il n'y a rien de mal à ça. Ce sont presque tous des projets persos. Mais tu ne peux pas demander aux utilisateurs de "vouloir" ce que tu développes. Ça marche dans l'autre sens: ils posent leurs besoins, et tu y réponds, ou pas!
Ici, toutes les combinaisons clients-serveurs XMPP sont "ou pas".
-Toujours pas de consensus sur le chiffrement bout-à-bout
Des implémentations à gauche à droite et toujours pas de standard pour un chiffrement bout-à-bout "moderne". Pour un écosystème qui se targue de mettre le standard au premier plan, c'est vraiment malheureux.
Et j'ai toujours l'impression que l'écosystème XMPP ne comprend pas le problème, surtout quand je lis des échanges sur l'inutilité du chiffrement bout-à-bout.
C'est le même symptôme que le Libre il y a 15ans "dis-moi de quoi tu as besoin, je te dirais pourquoi tu dois t'en passer!".
Le but de la XSF c'est visiblement d'avoir le "plus beau" standard. Les besoins des utilisateurs sont en bas de la pile des priorités.
Quand bien même il y aurait eu un appel d'offre, qui avait une solution à proposer qui n'implique pas de gros développements pour obtenir la liste initiale des requis?
Que tu aimes ou pas, Matrix/Riot propose déjà, là, maintenant, tout de suite, toutes des fonctionnalités.
Et c'est là-dessus que les outils sont choisis: pas sur ce qui pourrait être ou sera, mais sur ce qui est disponible.
Ils utilisent Jitsi-Meet pour avoir la vidéoconf de groupe plus vite. Et après? Ça fait une fonctionnalité de plus à peu de frais. J'appelle ça du pragmatisme.
Oui, c'est bien dommage.
Mais aujourd'hui encore: l'utilisateur a fait un choix pragmatique.
Combien de "défaites" faudra-t-il encore avant que la communauté XMPP se remette en question?
Pourquoi Matrix/Riot a suscité autant d'enthousiasme à ses débuts?
Ce n'est pas QUE grâce au marketing! Ils donnent aux utilisateurs ce qu'ils veulent!
Les utilisateurs ne veulent pas un standard, ils veulent une solution de communication instantanée.
Pourquoi l'État Français fait ce choix aujourd'hui?
Pour exactement les mêmes raisons: aucune alternative chez XMPP. Aucune! Même le standard ne permet pas encore de tout obtenir (chiffrement bout-à-bout).
Si tu veux que XMPP soit dans la course, connecte-toi sur le salon de la XSF, et pousse une bonne grosse gueulante en tant que développeur parce qu'il n'y a toujours pas de standard de chiffrement bout-à-bout pour les multiples clients XMPP, et ça devient franchement le bordel.
Ce sera un bon début.
Après, il faudra aussi se demander comment faire émerger un client qui répond à tous les besoins listés là-haut.
[^] # Re: Mouais
Posté par Frank-N-Furter . Évalué à 5.
Not a problem, dans 2/3 ans ça aboutira a un brouillon de XEP, entre-temps quelqu'un aura forkay
ProsodyMetronom pour commencer a bosser sur une implémentation, et quelqu'un bricolera quelque chose dans Conversations, pour tester. 3 ans plus tard, la XEP sera finalisée, un plug-in pour Prosodie sera écrit, il y aura des discussions pour l'intégrer à PSI, JITSI et ChatSecure, mais pour diverses raisons les différentes implémentations ne seront pas compatibles.Depending on the time of day, the French go either way.
[^] # Re: Mouais
Posté par Ytterbium . Évalué à 4.
C'est visiblement un projet développé en interne, donc pas besoin d'appel d'offre : ils ont juste pris l'une des solutions libres qu'ils avaient sous la main.
[^] # Re: Mouais
Posté par Misc (site web personnel) . Évalué à 4.
Et les appels d'offre, tu peux aussi faire ce que tu veux un peu.
Si tu dis "on a besoin d'une solution dont on a le code source qui implémente tel protocole", bah, oui, c'est un appel d'offre. La seule différence, c'est que tu va avoir 1 boite qui a développer le produit et 15 vautours (du genre, qui commence par les 3 premières lettres de Linux, et qui fini par ra).
[^] # Re: Mouais
Posté par jyes . Évalué à 9. Dernière modification le 27 avril 2018 à 10:22.
À moins qu’il s’agisse d’implémenter la politique agricole commune européenne, je ne vois pas pourquoi l’INRA répondrait à un tel appel d’offre. De plus, ils sont beaucoup plus proches des bovins que des vautours, à moins que la production animale en France n’ait beaucoup évolué récemment.
[^] # Re: Mouais
Posté par Maclag . Évalué à 3. Dernière modification le 27 avril 2018 à 13:17.
Je pense qu'il fait référence à une toute autre boite.
Mais ça m'étonne: Lincpa, ce sont des comptables américains, ils vont ramer pour développer une messagerie, surtout en Français!!
Edit: en plus ils doivent rajouter un r à leur nom…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.