Goffi a écrit 1537 commentaires

La XEP-0070 est déjà implémentée dans SàT (et notamment utilisable via Cagou l'interface Android/bureau), on a même pas mal communiqué autour de cette XEP pour la faire connaître.

Mais elle permet uniquement de s'assurer de qui est un contact (on entre son identifiant, et on vérifie que la personne qui se connecte a accès au compte indiqué), pas de publier à la place de la personne. Pour ça, il faut soit que la personne sur un serveur externe ait un client capable d'utiliser la fonctionnalités voulue (ici les tickets), soit qu'il y ait une connexion via un système sans transmission de mot de passe, par exemple via OAuth.

Effectivement c'est peu. Mais ce n'est pas forcément leur seule source de revenus

Liberapay, les cotisations et les (rares) dons sont nos seules sources de revenues, c'est indiqué dans nos assemblées générales (cf. la dernière par exemple).

Pour ce qui est des déplacement (par exemple pour venir au POSS d'où j'écris), l'hébergement, le matériel, etc. C'est de notre poche, et on se fait parfois rembourser par l'association.

Merci !

Il y a bien sûr encore du boulot pour arriver au même niveau de confort que les grosses plateformes, mais c'est déjà utilisable en l'état, et ça peut aller vite si un peu de monde suit.

Les applications vont bien au delà du rapport de bogues, on peut mettre les champs qu'on veut dans les tickets, et les merge-requests sont un exemple d'utilisation.

Il est aussi facile de faire des automatisations (étant basé sur pubsub, chaque nouveau ticket envoie une notification par exemple), et j'aimerais bien ajouter un système d'intégration continue (des tests automatisés) qui nous seraient bien utiles pour le développement de SàT.

J'espère aussi trouver du monde pour avancer sur le développement, si des développeurs python passent par là :)

Bon allez, je vais quand même placer Primitivus, notre frontal TUI (console), puisqu'il s'inspire de Vim et est modal, donc pour tout ce qui touche à la messagerie (soit directement en XMPP, soit via des passerelles).

Pour l'édition j'ai testé le mode Evil, cherchant à me remettre à Emacs alors que je ne l'ai pas utilisé depuis à peu près 10 ans. C'est pas mal, mais on est quand même très loin du confort de vim quand on y est habitué (des trucs tout bêtes comme C-a C-x pour incrémenter/décrémenter ne fonctionnent pas de base – mais je crois que c'est possible avec une extension –, et évidemment des commandes comme :mksession ne sont pas disponibles). Il faudra que je m'y penche un peu plus, mais je n'ai pas trop le temps en ce moment. Mon objectif est principalement d'utiliser le org-mode qui a l'air vraiment super, et éventuellement d'interfacer SàT avec.

Sinon j'ai fait un commentaire dans un journal précédent avec quelques alternatives à Pentadactyl/Vimperator.

pour les pages d'extensions (et certainement about:config) je crois que c'est une limitation des webextensions. Par contre pour le nouvel onglet, vim-vixen indique dans la note de sortie de la 0.5 (sortie il y a quelques jours) qu'il est désormais actif dans about:blank, cf. https://addons.mozilla.org/en-US/firefox/addon/vim-vixen/

Un peu hors sujet mais pas tellement, j'utilise depuis des années Pentadactyl, une extension qui permet d'avoir un comportement à la Vim, en rendant Firefox modal, en supprimant (optionnellement) la barre de navigation et d'outil, et surtout en rendant le navigateur très facile à utiliser au clavier (une fois qu'on a pris les habitude, c'est très très pratique d'ouvrir une page en faisant un simple "o" ou "O" pour ouvrir dans un nouvel onglet).
Bien que le paquet n'était plus mis à jour sur le dépôt d'extensions de Firefox, je continuais à l'utiliser avec des astuces (changement de version maximale à la main) ou des build qu'on trouvait par-ci par-là, mais la fin de XUL annonce la fin définitive de cette extension.

Du coup j'ai cherché des équivalents (pour l'instant je continue d'utiliser sur ESR), et je me suis arrêté sur 3 options, ça peut peut-être intéresser du monde:

• vim-vixen: il me semble le plus prometteur, très réactif (plus que Pentadactyl), il est activement développé et a déjà les raccourcis de base. Il ne me manque que les quick marks (et je ne suis pas le seul) pour que je sois à l'aise.

• tridactyl: qui cherche à refaire Pentadactyl/Vimperator en webextension. Ça n'est pas encore dispo (enfin il y a des builds de test que je n'ai pas essayé), mais c'est très actif. À surveiller de près.

Les webextensions ne permettent pas pour le moment de reproduire toutes les fonctionnalités, la 3ème option que j'ai commencé à tester c'est un navigateur indépendant construit directement pour être utilisable à la Vim.

• qutebrowser qui est basé sur Qt (avec QtWebEngine ou QtWebKit pour le rendu). C'est bien fait et réactif, on est tout de suite à l'aise. Les marque pages sont moins pratiques que les quickmarks de Pentadactyl, mais sinon on s'y retrouve. Par contre le moteur (par défaut) est loin derrière Firefox, au niveau du CSS par exemple, les grilles (grid) ne sont pas gérées correctement.

Voilà, si ça peut servir à d'autres…

Cette histoire de contrepartie est intéressante, surtout avec le libre. Il y a déjà une contrepartie : l'œuvre fournie (code, graphisme, animation, texte ou autre) qui l'est pour tout le monde.
Et c'est aussi de la gestion : on a fait une petite campagne de financement collaboratif sur Arizuka pour notre interface Android, et on avait évité les choses physiques pour différentes raisons, mais notamment ne pas avoir à gérer des envois ; mais même sans ça, c'est du temps à gérer, de l'énergie, etc. qui est perdu pour le développement lui-même.

Après mettre un nom quelque part c'est autre chose. D'un côté une contribution financière est une contribution au même titre que qu'un patch, et nous citons bien ceux contribuent au code ou aux médias. D'un autre côté, et dans notre cas particulier, nous nous sommes engagés à ne pas faire de publicité et autant pour un particulier ça ne pose a priori pas de problème, autant pour une entreprise ça devient de la publicité en contrepartie, et donc on parle de sponsors, plus de dons.

Du coup j'aime beaucoup Liberapay parce que c'est du vrai don pour soutenir, pas un achat ou échange déguisé (*). Dans le libre en particulier la contrepartie est déjà là, et pour tout le monde, et ça permet aux gens soutenus de se concentrer vraiment sur ce qu'ils veulent faire. Ça correspond à la boîte de dons qu'on laisse sur un salon.

Ceci dit, je comprends que c'est frustrant pour les donateurs, et je pense qu'il serait pas mal que Liberapay ait une section pour indiquer ce qu'on fait avec les sous reçus, ou pour indiquer l'avancement pour montrer que les sous servent à quelque chose (d'un autre côté on a déjà les blogs officiels pour indiquer ça), même si c'est juste payer une bière pour garder le moral.

(*) je note quand même qu'on n'a pas du tout eu ce sentiment avec notre campagne de financement collaboratif : on a eu des dons parfois gros, et on eu l'impression que c'était vraiment pour soutenir (on a parfois eu des mots d'encouragement très agréables), d'ailleurs il y a des contreparties qui n'ont même pas encore été réclamées.

Salut,

déjà félicitations pour cette sortie, Mongoose IM a l'air de bien avancer.
Est-ce que votre client Mangosta est destiné à rester un logiciel de démo, ou vous comptez à terme en faire un logiciel utilisable au quotidien au même titre que des Conversation ou Movim (ou SàT bientôt) ?

Aussi est-ce que ces logiciels communiquent via XMPP ou via l'API REST (en d'autres termes : est-ce que ce sont des clients XMPP indépendants du serveur, ou des clients Mongoose IM, donc liés à celui-ci ?)

En tout cas c'est super de voir un projet de plus s'intéresser au blogage via XMPP et à ce qui tourne autour.

On se voit au POSS :)

Je pense que oui, en tout cas pour l'instant.

j'ai répondu en dessous, mais je re-précise: SàT n'est nécessaire qu'à la publication pour un groupe, à la lecture c'est transparent.

Tu veux dire qu'il faut nécessairement que les autres membres du "groupe" auquel est destiné le billet utilisent aussi SaT ?

Non. SàT et SàT Pubsub ont deux fonctionnalités non encore standardisées qui permettent ça:

• une modèle d'accès supplémentaire, publisher-roster qui indique qu'on donne accès à un ou plusieurs groupes de la liste de contacts (roster) de celui qui publie
• la possibilité de faire des permissions par éléments (items), qui est un billet dans le cas du blog. Normalement Pubsub ne permet de le faire qu'on niveau du nœud (autrement dit, le flux complet des billets).

En gros ça veut dire que tu peux dire « je veux que ce billet de blog ne soit visible que par les gens de mon groupe bouchot dans la liste de contacts. Il faut utiliser SàT pour publier de cette façon, mais à la lecture c'est totalement transparent pour le client en face : si la personne est dans le groupe désigné, elle verra le billet, sinon non.

En ce qui concerne je vais laisser Edhelas compléter ou corriger si nécessaire, mais ce qui est appelé « publié publiquement » indique que ça va apparaître sur les blogs accessibles par les moteurs de recherche (c.-à-d. aux gens non connectés dans Movim). C'est juste un drapeau spécifique à Movim, le billet reste accessible par n'importe quel client pubsub (puisqu'il garde un accès ouvert (open)).

J'aimerais aussi voir la vidéo dans SàT (et je compte le faire tôt ou tard), mais encore une fois je suis actuellement seul sur le dév. Je suis en train de chercher à améliorer les choses (je travaille notamment sur des outils pour faciliter la collaboration), mais il faut qu'on voit les priorités, et pour le moment il y a déjà plusieurs gros chantiers en cours (gestionnaire d'événements, gestionnaire de tickets, framework web et interface bureau/Android). Bien sûr si j'arrive à être à plein temps dans les années à venir, ça va nettement s'améliorer.

Parce que Jingle et WebRTC ne font pas la même chose. Jingle c'est la mise en relation/gestion de la session (le signal), webRTC c'est la gestion des périphériques, des filtres (annulation d'écho par exemple), et de du flux. Les 2 sont complémentaires et fonctionnent ensemble, c'est pas l'un ou l'autre.

Et Jingle fonctionne très bien, qui a dit le contraire ? Je t'invite à lire l'article que j'ai écrit sur le sujet pour que ça soit un peu plus clair dans ton esprit.

Si tu relis mon commentaire, tu verras que la tâche sur le web n'est pas trop compliquée (pour quelque chose de base et grâce à WebRTC), mais que sur les autres plateformes ce n'est pas aussi évident (la question parle de smartphone, je suppose qu'elle parle d'application native), et que dans tous les cas si on veut un truc qui fonctionne bien ça demande beaucoup de tests, et ce n'est pas dans nos priorités principales actuelles vu nos ressources (un dév sur le temps libre) et vu que certains projets font déjà ça correctement (Jitsi).

Jingle est souvent implémenté (il est implémenté sur SàT et donc dispo sur Cagou notre interface Android par exemple), mais ce n'est qu'une partie de ce qui est nécessaire (nous l'implémentons pour la copie de fichiers par exemple).

Je ne sais pas pour les autres, mais pour nous la visio-conférence est mise de côté pour le moment parce que c'est un gros boulot, qui demande beaucoup de tests, et que nous avons déjà beaucoup de pain sur la planche. C'est prévu, mais en priorité moyenne. Sur le web la tâche est nettement facilitée par WebRTC, une visio de base est presque triviale avec ça maintenant.

Pour utiliser la même techno sur bureau ou téléphone, il faut regarder comment c'est possible (sur bureau GNUnux je pense qu'avec GStreamer/Phonon ça doit être jouable, avec Kivy je ne sais pas, certainement en faisant des appels Java à l'API Android ça doit pouvoir se faire, ou avec la solution un peu crados d'une webview, mais ça n'est probablement pas simple).

Ça demande d'étudier bien les différentes possibilités et d'avoir du temps. Si j'étais à plein temps ça serait certainement possible, au moins via l'interface web, depuis longtemps…

D'autre part, les priorités sont peut-être différentes selon les projets. Jitsi marche déjà bien pour la vidéo, c'est pas un gros problème de l'utiliser à côté d'ici à ce qu'on ait notre propre implémentation.

C'est complètement faux, vous lisez trop vite et/ou pas assez. XMPP sait gérer le multi-appareils depuis le début (avec les ressources), et a un système de priorités.

Le système de priorité n'est pas pratique et porte à confusion, la plupart des implémentations (mais pas toutes) envoyaient le message à tous les appareils quand les priorités étaient égales. Avec le temps et la prolifération des appareils (il est beaucoup plus courant qu'avant d'avoir plusieurs appareils, rien qu'avec le téléphone et l'ordinateur de bureau), ce système s'est montré inefficace, d'où la sortie d'une extension pour corriger ça, ce qui est la façon de faire chez XMPP. À l'époque XMPP était un des seuls protocoles à gérer plusieurs appareils, et la plupart des autres logiciels (pour ne pas dire tous) se déconnectaient si on se connectait depuis un autre endroit.

L'extension en question est bien faite, elle permet notamment d'indiquer qu'il ne faut pas copier un message si nécessaire (par exemple dans le cas d'OTR), et elle ne date pas de 2017 mais de 2010 (première version publique le 3 mai 2010). Il est possible de le faire avec Prosody (qui n'est qu'une des implémentation d'un serveur XMPP) depuis 6 ans. La seule chose qui a changé est que le module qui le permet (mod_carbons) est maintenant un module installé d'office, et c'est clairement indiqué dans l'annonce. Donc ça n'est certainement une fonctionnalité apparue en 2017.

Dans le même ordre d'idées il y a Wikidébats, présent notamment à la fête de l'huma.

J'attends d'avoir un peu de recul pour me faire une idée sur ce genre de choses. Ça peut sembler une bonne idée de regrouper les arguments, sauf que ça va nettement dépendre de la population qui fréquence le site, du contexte du moment (époque notamment, comment prendre en compte l'évolution de l'opinion générale selon les événements ?), de l’acharnement/ de certains à éditer/rééditer, etc.

Des arguments nécessitent souvent un contexte et de longues réflexions pour êtres entendus, plus qu'un simple paragraphe sanctionné d'un d'accord/pas d'accord puisse donner. Quand on voit un sujet délicat comme « Dieu existe-t-il », la partie « pour » n'a pratiquement que des « pour » (pouce bleu) et des « objection » (main levée orange qui semble neutre) au premier niveau, tandis que la partie « contre » n'a pratiquement des « contre » (pouce rouge vers le bas qui semble montrer une opposition ferme) et des « objection » au premier niveau.

D'un autre côté, c'est un outil, et si c'est pris comme tel et pas comme source unique de réflexion, ça peut être intéressant (j'avais d'ailleurs déjà songé à faire un outil de ce style, c'est une idée visiblement dans l'air du temps).

Bref, à voir avec le temps, et à ne pas utiliser comme source unique de réflexion.

C'est très à la mode de critiquer le côté modulaire de XMPP alors que c'est au contraire son grand point fort.

Tous les protocoles qu'on utilise ou presque évoluent, y compris ceux qu'on utilise actuellement: HTTP et HTML et Javascript. Il y a des fonctionnalités qui évoluent, qui sont améliorées, abandonnées, etc. C'est le cycle de vie de pratiquement tout ce qui touche à l'informatique.

Sur HTML/Javscript les fonctionnalités sont testées dans le navigateur, souvent de manière assez crade (on teste si une méthode existe pour javascript par exemple, avant on testait carrément le nom du navigateur ce qui était très, très moche). C'est sans doute moins visible de nos jours parce que les butineurs ont de grosses équipes et sont mis à jour très vite (et je suppose que sur ce site la plupart des visiteurs ont des butineurs récents), et aussi parce qu'il y a des « polyfills », ces rouleaux de papier adhésif pour essayer de faire marcher des fonctionnalités un peu partout.

Sur XMPP c'est fait proprement (annonce des fonctionnalités, découverte, négociation, espaces de nommage, etc), je ne vois pas trop ce qu'il y a à critiquer de ce côté.

D'autre part il y a de nombreux logiciels qui utilisent XMPP, avec des anciennetés, des objectifs, des équipes et moyens différents, et donc des implémentation différentes. C'est normal que des fonctionnalités ne soient pas disponibles partout, et ça fonctionne tout de même (et on peut même encore utiliser un client qui a été écrit il y a 10 ans sur le réseau, même s'il n'a pas été maintenu).

Aussi je dois avoir beaucoup de chance parce que les fonctionnalités que j'utilise sont souvent implémentées. Je ne contrôle même pas tous mes serveurs (mon compte principal est sur jabber.fr que je n'administre pas, même si je peux demander quelque chose aux admins si j'en ai besoin), et bien évidement je n'ai aucun contrôle sur le client que la personne utilise en face.

Alors bien sûr si vous prenez comme étalon un trucs très récent et en cours de standardisation comme OMEMO, forcément ça n'est pas partout pour tout un tas de raison (débats sur les spécifications, certains n'en veulent pas, dans certains cas comme le web ça n'est pas trivial, etc.), mais c'est déjà présent dans un bon nombre de clients.

Et pour des tas de fonctionnalités, il n'y a pas besoin que ça soit implémenté partout. Le blog par exemple, rien n'empêche d'utiliser Gajim ou Xabber qui ne l'implémentent pas, et d'avoir Movim sur le web.

Mais j'ai toujours autant de mal avec XMPP. Un protocole de messagerie instantanée open-source multi-serveur est primordial, et de par son ancienneté, XMPP s'est fait une belle place (limitée bien sûr, par rapport aux messageries fermées Facebook/Hangout/Skype/…).

ce n'est pas que de la messagerie instantanée, c'est beaucoup plus large que ça.

Seulement, à chaque fois que je regarde ce qui est disponible comme serveurs/clients, je me trouve confronté à son plus grand inconvénient : savoir quel serveur et quel client prend en compte chaque extension.

Ça complique bien sûr, mais c'est aussi l'intérêt : tu as le choix et surtout des outils adaptés à des cas particuliers. C'est un peu comme pour les courriels, tu as le choix entre des dizaines/centaines de clients, mais ils fonctionnent tous ensemble.

D'un autre côté, si tu regardes en dehors de XMPP pour la messagerie aujourd'hui c'est pire : tu as le choix entre des dizaines/centaines de logiciels, mais qui ne fonctionnent pas ensemble la plupart du temps.

Après si tu ne veux pas t'embêter, tu as des solutions tout en un (client + serveur), je crois qu'OpenFire et MongooseIM vont dans ce sens.

Au final, j'en retire toujours la même impression (peut être fausse, ce n'est qu'une impression) : que XMPP est un protocole open-source fragmenté.

« fragmenté » n'est pas le mot qui convient, c'est un protocole qui a de nombreuses implémentations, mais elle fonctionnent ensemble.

Existe-t-il un site qui répertorie tous les serveurs/clients les plus connus/utilisés, avec leurs fonctionnalités, sous forme d'un tableau, et à jour ?

Wikipédia en effet, également https://xmpp.org/software/clients.html, https://xmpp.org/software/servers.html ou encore https://www.zash.se/xmpp-features.html. Mais ça n'est pas super simple pour un nouveau venu et ces tableaux sont difficiles à lire/utiliser, il y a des améliorations à faire dessus c'est évident.

Ces évolutions (en particulier la gestion native des WebSockets) permettent-elles d'utiliser prosody pour faire tourner un client web comme Movim ?

Movim peut fonctionner avec Prosody, mais il sera en mode « dégradé » : la fonctionnalité qui manque principalement est la persistance des données en PubSub (le problème est pour la partie blog : les billets ne seront pas conservés après un redémarrage du serveur).

Le composant que nous développons pour SàT, SàT Pubsub mentionné plus haut, permet la persistance et fonctionne avec Prosody, donc il règle ce problème mais il faut attendre la sortie d'une version stable (enfin c'est utilisable en l'état, mais pas trivial à installer).

Par ailleurs, Aeris m'avait indiqué lors d'un bref échange sur Twitter qu'un outils à la Mastodon, avec des flux publics, ne pouvait pas fonctionner à base de XMPP. Qu'en pensez-vous ?

c'est des conneries.

On a déjà des flux publics, et côté blog mis à part XMPP a depuis longtemps montré qu'il était capable de tenir de très forte charges, notamment avec des serveurs comme Ejabberd. Mais bon, c'est pas la première fois et sans doute pas la dernière qu'on lit n'importe quoi à propos de XMPP.

jp a été pas mal amélioré sur ce point dans la version de dév, mais la 0.6.1 le permettait déjà. Tu as un tuto sur mon blog si tu veux, sinon jp blog --help et jp pubsub --help devraient te permettre de t'en sortir, ou alors viens sur le salon de SàT je peux t'aider.

Oui c'est ce que font OMEMO et OX (OpenPGP fait correctement), c'est d'ailleurs le principal intérêt par rapport à OTR.

Si l'implémentation est faite correctement (en suivant les recommandations de la XEP), le message n'est pas copié (seul le destinataire aura le message).

Si ça n'est pas fait correctement, le message chiffré sera copié, et ignoré par les appareils qui ne peuvent pas le lire, donc un peu de bande passante/processeur utilisés pour rien.

Je pense que la plupart des clients actuels sont dans le premier cas (donc le message n'est pas copié inutilement).

Beaucoup de serveur de cette liste sont bien placés. En revanche, seul conversations.im est compatible pour le chiffrage ONEMO pour un contact hors ligne. Cette fonctionnalité est-elle disponible avec ejabberd? Est-ce un chantier en cours? Il me semble que ce sera implémenté par mod_pep_plus mais il n'y a pas encore beaucoup d'activité.

je viens de jeter un œil au code qui teste ça, ça teste uniquement la présence de la fonctionnalité #publish-options et ça me semble un peu curieux voire trompeur. Cette fonctionnalité permet de configurer un nœud Pubsub à sa création. En d'autres termes et dans le cas présent, ça permet d'autoriser des gens qui ne sont pas dans la liste de contacts (roster) à accéder aux infos OMEMO (clef publique je suppose) au moment où on créé le nœud, c'est à dire l'endroit où sont enregistrées ces infos.

Sauf que si cette fonctionnalité n'est pas présente, il est tout à fait possible de faire la configuration dans un deuxième temps (avec une autre requête XMPP), c'est juste un peu moins efficace.

Bref, je ne vois pas l'intérêt ce test, ou alors j'ai loupé quelque chose.

La fonctionnalité #publish-options ne semble pas pas présente dans ejabberd (je viens de tester sur pubsub.movim.eu), et je ne sais pas pour mod_pep_plus (utilisant SàT pubsub, je ne suis pas le développement du composant interne de très près).

Pour Goffi: tu as développé le composant sat_pubsub qui se substitue au pubsub interne du serveur. Est-ce que ce composant est toujours utile?

Oui, et je pense qu'il sera toujours (longtemps du moins) utile et pas que pour Prosody, je dois écrire un billet de blog sur le sujet depuis un moment mais je manque de temps. En gros Pubsub c'est plus ou moins la base de donnée de XMPP (ou plutôt une interface standard pour les bases de données), et c'est un composant complexe à écrire. Les implémentations serveurs sont inégales, et quand une fonctionnalité apparaît, on est dépendant du bon vouloir/des possibilités des équipe de dév et du cycle de sortie des serveurs pour en profiter.

Avec SàT Pubsub, on a un composant générique et indépendant, on est sûrs d'avoir tout ce qu'on veut (si ça manque on implémente nous même) et il peut fonctionner potentiellement partout.

Qu'apporte-t-il de plus par rapport aux autres implémentations?

Outre ce que j'ai dit plus haut, je crois que c'est la seule implémentation libre actuelle qui implémente MAM qui permet notamment la recherche, il implémente l'attribut publisher (qui permet de vérifier qui a publié un élément), RSM (résultats par pages), a la persistance, les modèles d'accès open, presence, et whitelist (cf. l'épisode 8 de Parlons XMPP), et d'autre bricoles. Il est testé en permanence avec un client qui fait du blog, donc adapté à ça.

En plus de ces fonctionnalités, c'est aussi un terrain d'expérimentation avec notamment un accès spécifique publisher-roster qui couplé aux permissions fines permet d'avoir des éléments (billets de blog par exemple) réservés à un groupe (fonctionnalités appelée par ailleurs « cercles » ou « aspects »), et depuis récemment des « schémas de nœud » qui permettent entre autre de contrôler ce que les gens peuvent publier. Là aussi je dois écrire un billet sur le sujet, et je compte proposer ceci à la standardisation (quand j'aurai du temps là encore :-/ ).

Pour le 3ème point, je pense que Link Mauve ou mathieui pourront te répondre.

Je trouve XMPP très intéressant et je m'en sert au quotidien mais c'est vrai qu'il n'est pas toujours facile de trouver l'information pour faire des choses modernes. Cela semble changer et j'espère bien pouvoir expérimenter ces nouvelles possibilités prochainement.

Oui c'est vrai, et il y a un travail fait par différents acteurs pour améliorer ça, espérons que ça porte les fruits rapidement.

Sinon, à titre personnel, je trouve l’ambiance sur les salons officiels de SàT, Movim, JabberFR très conviviale et on y apprend souvent des choses intéressantes.

:).

La fois de trop j'ai décidé de basculer vers autre chose, à savoir prosody. Beaucoup plus sympa à administrer, mais : il faut plein de modules pour avoir des fonctionnalités, modules qui ne sont pas utilisables avec la version stable, du coup il faut se palucher une compilation locale depuis les sources. Je pense notamment à ce qui est mis en avant dans le journal, à savoir l'historique partagé, côté serveur. Il y avait aussi le stockage des mots de passe utilisateur, en clair dans des fichiers texte. Il y avait de la doc pour basculer vers autre chose, mais c'est/c'était le réglage de base.

Ben tu vas être content, la nouvelle version stable avec l'historique côté serveur (MAM) vient de sortir : https://blog.prosody.im/prosody-0-10-0-released/

Tu interprètes un peu, je n'ai pas que j'étais contre un service commercial (qui n'est d'ailleurs pas incompatible avec des associations, ni avec un système éthique). J'ai dit que je préfère de loin voir des solutions locales au maximum à des gros services nationaux/multinationaux. Et local ne veut pas dire pas sérieux ou de mauvaise qualité. Au contraire, je préfère pouvoir voir quelqu'un physiquement si nécessaire.

Ce serait peut-être un excellent argument de vente: "notre contrat d'utilisateur interdit explicitement et formellement l'exploitation de vos données personnelles et nous nous engageons à ne pas placer de publicité sur notre client officiel".
Ça pète quand même plus que les habituels
"Assurez-vous de bien lire le contrat de 152 pages en petits caractères avant de cliquer sur le bouton "Accepter le contrat". Votre formulaire d'inscription sera déclaré périmé dans 3min24. J'espère que vous lisez vite…"

On n'a pas écrit ça comme « argument de vente », mais https://salut-a-toi.org/social_contract.html

Regarde Matrix et Riot: un immense succès et presque tous les utilisateurs sur le même serveur officiel. Les serveurs persos, locaux, associatifs, ils arrivent après, quand la mayonnaise a pris.

« un immense succès » tu t'emballes un peu. Ils ont fait un marketing agressif qui a fonctionné auprès d'un public technique, et ils ont une application qui visiblement est léchée (pas testé moi même encore), mais de là à appeler ça « un immense succès » j'attends de voir.

Et puis, encore une fois: si tu veux te financer avec ça, il te faut la manne. Si tu ne comptes que sur les dons, ça fait mal, mais tu es alors en concurrence directe avec toutes les associations que tu souhaites voir devenir hébergeurs.

Non je ne compte pas que sur les dons (du moins pas à l'heure actuelle), et je pense qu'il y a de la place pour tout le monde (y'a pas non plus foule d'associations qui proposent des hébergements de service libres, et quand ça arrivera je serai content).