L'intention de citer les solutions actuellement pour le chiffrement de bout en bout est louable, mais ce journal me semble un peu confus, et surtout erroné !
OTR ne permet pas l'anonymat ! Tu confonds peut-être avec le « perfect forward secrecy » qui permet de ne pas compromettre les conversation antérieur si une clef est interceptée.
Il faut coupler à quelque chose comme TOR pour avoir un semblant d'anonymat.
Il est à noter qu'OTR permet de vérifier que votre correspondant est bien la personne à qui vous souhaitez parler (depuis la version 3).
ça aussi c'est faux, il est bien possible de vérifier l'identité de la personne avec OTR v2 par exemple, c'est juste qu'il faut utiliser des « fingerprint » (une séquence de caractères à vérifier), alors qu'avec la version 3 on peut utiliser une question sans passer par un canal extérieur.
Chat décentralisé (anonyme)
Les messageries (libres) classiques sont souvent décentralisées, tu parles de P2P là (d'ailleurs tu le précises). Là aussi l'anonymat est une chose séparée, même si certains cherchent à l'inclure nativement dans leur projet.
Bon ceci dit, c'est toujours bien de parler de tout ça, donc merci pour le journal :)
Tu peux le prendre comme ça. Tu peux aussi voir que je constate que tes choix ne correspondent pas à certaines de tes convictions — celle de vouloir « un système plus sécurisé » (en revanche, je n’ai rien à redire sur la conviction « je préfère un système communautaire ») — et que je ne me contente pas de te le faire remarquer mais je te propose aussi des alternatives pour corriger ça.
Mais je suis tout à fait OK pour qu'on me dise quand les choix ne sont pas bons, je suis juste très (peut être trop ?) sensible à la forme, et je n'aime pas qu'on me dise qu'on fait les trucs par facilité alors qu'on sait très bien qu'il suffirait de 5 min pour faire un certificat qui ne fasse pas d'avertissement et que justement on prend une autre solution, plus compliquée (c'est facile de faire un certificat CAcert, mais plus compliqué d'expliquer aux gens pourquoi il y a un message de sécurité) parce qu'elle nous semble mieux nous correspondre. Peut-être qu'on ne fait pas le bon choix, et on va en discuter.
Et je trouve très bien de regrouper sur un commentaire les liens pour qu'on voit facilement ce qu'on peut faire en plus, d'ailleurs ça serait utile d'en fait un journal/une dépêche (un peu comme les dépêches sécurité de Skhaen).
Bon passons pour ce point.
Maintenant ces solutions on va les étudier, et on va voir ce qu'il est possible de faire, mais on a aussi beaucoup d'autres choses sur le feu, et ça prend du temps ne serait-ce que de lire les journaux, puis les spécifications, puis chercher des implémentations ou les faire si besoin.
En attendant, choisir CAcert, au moins pour le motif « parce que c’est plus sécurisé » (encore une fois, je ne critique pas le choix motivé par l’aspect communautaire), c’est à la fois une solution de facilité et une fausse solution par-dessus le marché.
Ok pour le côté pas plus sécurisé (mais par pour le côté solution de facilité, enfin bref). Pour nous l'aspect communautaire est un point très important, essentiel même, donc le choix de CAcert reste justifié, mais la discussion n'est pas close.
Je ne sais pas quelles sont tes convictions, mais si tu n’apprécies pas le système actuel des CA, la solution n’est pas, à mon sens, de soutenir une CA alternative mais de soutenir une alternative aux CA.
CAcert ne fonctionne pas comme les autres, c'est pas juste un « CA qui a l'air un peu plus cool que les autres », c'est un système communautaire avec validation en se rencontrant physiquement, le web de confiance. Nos convictions, pour ce cas, c'est surtout favoriser le communautaire et avoir un système plus sécurisé.
Les choses dont tu parles sont des choses annexes, qui sont envisageables en plus, mais il faut aussi pouvoir gérer au niveau du temps disponible.
Alors, oui, ça demande un peu plus de boulot que simplement se tourner vers une CA qui a l’air un peu plus cool que les autres (mais qui malheureusement, en tant que CA, fait partie du problème, quand bien même elle serait mille fois plus digne de confiance que les autres). À voir maintenant ce que valent les « convictions »…
Par contre je ne suis pas super fan du ton que tu emploies. « ça demande un peu plus de boulot que simplement [bla bla bla] » ==> je crois que t'as pas idée du boulot qu'on a à essayer de bien faire les choses justement, et cette façon de tourner la phrase du genre on fait juste un truc à l'arrache pour se donner bonne conscience est légèrement vexante.
À voir maintenant ce que valent les « convictions »…
On n'est pas et ne sera jamais irréprochables, mais on essaye de faire au mieux avec les moyens qu'on a. Chaque chose à ajouter, c'est une quantité du boulot derrière, et on en a déjà pas mal, du boulot. Donc petit à petit on améliore ce qu'on peut, on écoute au maximum les commentaires, mais ça prend du temps et de l'énergie.
Bon déjà je (re)dis à mon tour un grand merci à toute l'équipe derrière ce site qui est la référence pour moi, autant au niveau de l'éthique que du contenu, et sites en langue anglaise compris.
Pour CAcert on est un peu embêtés, parce qu'on garde un certificat CAcert sur notre projet, et la FAQ de DLFP nous permettait de justifier ce choix. Maintenant on va se sentir un peu seuls, et la plupart des gens ne comprennent pas pourquoi ils voient un message d'avertissement en allant sur la démo de Libervia.
J'avais pourtant l'impression de revoir une activité de ce côté: présence d'un stand CAcert au Fosdem par exemple, il me semble avoir lu que Debian allait (ou a ?) ré-intégrer les certificats racine (pas trop le temps de vérifier ça maintenant, ni de risquer une mise à jour sur ma SID aujourd'hui).
Bref, on se pose sérieusement la question de garder CAcert ou pas, j'ai l'impression de trahir un (petit) peu nos convictions si on le fait, mais maintenant que même DLFP lâche le morceau, on se sent plus seuls.
Superbe en tout cas, et je suis impressionné par la qualité des images. Je n'ai aucune idée de ce qu'il faut pour filmer comme ça sous l'eau, mais t'as des notions ou une formation pour filmer dans ce milieu ?
Petit oubli, sauf erreur l'épisode 2 de Caminandes a également été produit par la fondation Blender, ce serait dommage de laisser de côté ce mignon lama: http://www.caminandes.com/ (l'épisode 1 a également été fait avec Blender et le tout est sous CC Attribution).
En tout cas c'est assez excitant de voir tout ça. J'ai revu récemment Tears of steel, c'est quand même très très impressionnant ce qu'on peut faire aujourd'hui (enfin en 2012 pour celui ci) avec du libre.
On voit aussi bien le problème du financement de ce genre d'œuvres, à rapprocher sans doute des difficultés pour le cinéma d'auteur.
C'est une radio qui laisse la parole à des courants très différents, et la partie informatique n'a rien à voir du tout avec le reste.
Symbiose passait notamment sur radio libertaire, dogmazic et radio larzac si je ne me trompe pas (si luc ou manu passent par ici, ils corrigeront sans doute).
À noter qu'une partie des animateurs a quitté radio ici et maintenant en mars dernier pour une raison que j'ignore, et ils sont en train de monter un espace parisien dédié au libre avec notamment une webradio: http://libre-a-toi.org/. Je suppose qu'il y aura une annonce ici au moment du lancement.
Sans vouloir nous mettre trop en avant, je pense qu'on est en plein dans ce que tu recherches (et Movim aussi sur certains points). Plus en détails:
Pourquoi est-ce que personne ne fait de la messagerie un peu plus poussée avec les fonctionnalités qu'on attendrait aujourd'hui (historique illimité, recherche, multi-appareils, chiffrement end-to-end, asynchronicité,…) ?
Si si, on fait ! historique illimité, recherche, multi-appareils c'est MAM + Message Carbons et les implémentations sont de plus en plus courantes.
Chiffrement de bout en bout c'est un peu plus compliqué parce qu'il n'y a pas de bonne solution avec XMPP (c'est une vieille marotte et il y a eu plusieurs tentatives, mais rien n'a encore été largement adopté). La seule solution un peu populaire c'est OTR, et elle n'est pas (encore) standardisée en XMPP ! C'est des bidouillages de l'utiliser, mais ça fonctionne tant bien que mal, d'ailleurs on l'implémente dans SàT (et même 2 fois parce qu'on a décidé de faire une implémentation dans le navigateur pour l'interface web). Asynchronicité c'est de base dans XMPP, quel est ton problème avec ?
XMPP a tout sur le papier pour remplacer SMTP et faire du chiffrement par défaut (dans la veine du point précédent); personne n'en fait rien…
Le chiffrement est de base dans XMPP et même obligatoire depuis plus d'un an. Et pour SMTP là encore on peut par dire qu'on ne fait rien: c'est un truc dont on parle depuis plus de 4 ans (lire ici), on a un serveur IMAP, un serveur SMTP et un stockage Maildir dans SàT, et on fera certainement une passerelle SMTP pas pour cette version mais pour la prochaine.
XMPP a tout sur le papier pour remplacer twitter, et j'ai pas vu de grand mouvements de ce côté là.
Il me semble que ce journal montre justement le contraire. Tu peux essayer Movim ou Jappix, ou la démo de Libervia pour voir ce qu'on peut déjà faire, mais il y a encore du boulot c'est sûr.
C'est parce que XMPP a pour philosophie de tout faire sur le serveur ce qui est une aberration immense à mon avis
L'idée de base c'était - je pense - de se dire qu'il y a moins besoin de serveurs différents que de clients différents, et donc de simplifier la vie des développeurs de clients. La philosophie est toujours valable: si tu veux utiliser juste la partie messagerie instantanée de XMPP, ou juste la partie messagerie style courriel, tu peux facilement. Si tu veux des choses avancée, il faut de toute façon souvent des implémentations côté serveur et client (MAM par exemple).
il n'y a pas besoin de demander l'autorisation à qui que ce soit pour tenter quelque chose
Ben les nouvelles XEPs vont justement sacrément faciliter les choses de ce côté maintenant.
Et la standardisation est un avantage énorme sur tout nouveau protocole, et à qui il faudra un temps fou (ça se compte en années) avant d'arriver au niveau de XMPP.
Nous ça faisait longtemps qu'on attendait d'être débloqué pour le microblogage, maintenant je ne vois plus rien de majeur qui va nous gêner, et je pense ne pas trop m'avancer en disant que l'utilisation et les fonctionnalités de XMPP vont exploser sous peu.
Pour moi ça n'aurait aucun intérêt d'utiliser XMPP si tout le monde était sur FB ou gtalk.
L'annonce de l'utilisation et de l'abandon de XMPP par FB ne m'a fait ni chaud ni froid (d'un point de vue perso je n'ai jamais vraiment utilisé, et d'un point de vue général ça ne change rien pour FB qui n'était pas fédéré, et pour Gtalk le seul intérêt est - ça marche encore - de pouvoir communiquer avec des gens dessus), et c'est à mon sens une grosse erreur de se faire héberger là bas de toute façon.
Non ce qui montre la vitalité de XMPP, c'est le nombre et le dynamisme des projets qui l'utilisent et des standards, et de ce côté j'ai plutôt tendance à penser que ça s'améliore.
Euh si ils avancent et ils sont bien maintenus (suffit d'aller sur le salon prosody pour voir comme c'est actif), c'est juste que les priorités ne sont pas forcément les mêmes que pour nous.
Et sinon un jour on va probablement implémenter un serveur aussi, ou du moins une partie de ce que fait le serveur, pour avoir quelque chose de complètement P2P/Distribué/ça_dépend_comment_vous_appelez_ça. Y'a pratiquement tout ce qu'il faut déjà avec les bibliothèques qu'on utilise, mais bon c'est vraiment pas pour tout de suite.
Et si je te comprends bien vous avez simplifié la façon de l'implémenter avec XMPP ?
Simplifier c'est pas le mot, disons qu'on n'est (enfin on sera dans quelques temps si tout va bien) plus bloqués par les possibilités des serveurs (dans le sens le logiciel, après il faut que les instances de ces logiciels activent ce qu'il faut).
Si c'est ça, peux-tu expliquer aux noobs comme moi ce qu'il faudrait mettre en place pour pouvoir l'utiliser ? (si c'est possible dès maintenant…)
Dès maintenant c'est possible d'utiliser des serveurs pour faire du microblogage de base, mais ça marche plus ou moins bien. Metronome (fork de Prosody) est le serveur recommandé par Movim et Jappix, Ejabberd avait des problèmes de performance à une époque mais sinon c'est à ma connaissance l'implémentation PubSub la plus complète des serveurs, Prosody dans le version stable ne stocke pas les billets sur le disque, OpenFire j'ai arrêté à un moment suite à un bogue très gênant, je ne sais pas où ça en est, et je ne sais pas trop l'état non plus de Tigase ou autre.
Si c'est ça, peux-tu expliquer aux noobs comme moi ce qu'il faudrait mettre en place pour pouvoir l'utiliser ? (si c'est possible dès maintenant…)
Il faut principalement activer le composant PEP, il faut suivre la documentation du serveur pour voir comment faire.
Peut-on utiliser un serveur jabber parmi ceux qui sont sur le wiki ou faut il un serveur sur lequel on a la main
La page que tu donnes cite des instances de serveurs, et du coup il faut voir au cas par cas ce qu'ils activent. Tu peux utiliser un client XMPP pour voir les fonctionnalités et la présence de « http://jabber.org/protocol/pubsub#publish » dans les fonctionnalités, et « (pubsub/pep) » dans les identités (désolé c'est un peu technique, mais c'est comme ça qu'on regarde si une fonctionnalités existe. Avec salut à toi il y a l'interface en ligne de commande pour tester ça, par exemple sur jabber.fr ça donne:
Pas de « http://jabber.org/protocol/pubsub#publish » ici ni de « (pubsub/pep) », ça n'est donc pas possible. Il faut alors soit avoir le main sur le serveur, soit contacter les admins.
(quelques commentaires du journal sont troublants et il me semble y lire que les choses peuvent se faire au niveau du client seulement ??? Ou je pige vraiment rien ?)
Il faut d'une part que des fonctionnalités soient activées sur le serveur (pep au minimum), et d'autre part que le client soit capable de gérer ça (une compatibilité XEP-0277 au minimum). XMPP a la grande force d'être extensible, mais ça rend son approche un petit peu plus compliquée parce que les fonctionnalités s'activent ou pas en fonction de ce que sait faire le serveur/client en face.
Bon maintenant je parlais ici de microblogage de base. À ça il faut ajouter Message Archive Management (MAM) et/ou Result Set Management (RSM) pour pouvoir accéder à des message anciens (plus que les 10 derniers par exemple). Ce sont d'autres fonctionnalités que le serveur doit implémenter, et à ma connaissance, ça n'est disponible nulle part.
Nous on a un composant qui gère tout ça, mais il n'était pas possible de le « brancher » sur le serveur avant. Maintenant c'est possible avec Prosody et bientôt sur d'autres serveurs j'espère (ça marche probablement avec Metronome aussi vu que c'est un fork de Prosody). Côté Prosody c'est expliqué sur les pages wiki des modules que j'ai écrit: https://code.google.com/p/prosody-modules/wiki/mod_privilege et https://code.google.com/p/prosody-modules/wiki/mod_delegation ). Mais notre composant est en cours d'adaptation à ces nouveautés, c'est bien avancé mais il va falloir encore patienter un (petit) peu.
On n'est ainsi plus limités par les serveurs.
Peut-on utiliser un client jabber classique ?
Rien n'empêche un client classique d'implémenter ça, mais à ma connaissance aucun ne travaille dessus. On aimerait bien en voir ! Côté Poezio (très bon client console), on en parle.
Je comprends que non (c'est ça ?). Quels sont les clients spécifiques qui implémentent ou implémenteraient ça ?
Pour l'instant les 3 seuls (sauf erreur) sont Jappix, Movim et SàT.
Mais si je comprends bien SÀT nécessite aussi un serveur web…
Non, c'est même le seul des 3 cités qui n'en a pas besoin: tu peux utiliser une interface non-web (c'est multi-interface), mais on vient de retirer l'interface de bureau parce qu'on va en écrire une nouvelle pour la version grand public (fin d'année), soit tu utilises le serveur web intégré avec Libervia. Il y a une image Docker qui permet de tester ça facilement: http://wiki.goffi.org/wiki/Docker/en (expérimentale, n'hésite pas venir demander de l'aide/dire ce qui ne va pas sur le salon XMPP de SàT: sat@chat.jabberfr.org).
mais aussi sélectif : microblogguer avec un groupe de personnes défini
Ça par contre seul SàT en est capable, mais ça n'est pas (encore) standard. On va essayer de standardiser ça dans le futur. C'est de toute façon compatible avec les implémentations classiques, et on construit tout autour de cette logique: partage de fichiers, accès au commandes internes, etc.
Voilà, j'espère que c'est plus clair, sinon n'hésite pas à demander des précisions.
C'est à peu près ça sauf que c'est le XEP-0355 (la XEP-0356 c'est les privilèges), et que l'autre n'est pas nécessaire.
En gros quand on demande un truc à un serveur, au lieu de le gérer directement (ou pas 'il ne connait pas le protocole), il délègue à une autre entité. Pour MUC, PubSub et une passerelle courriel ça ne change pas grand chose parce que c'était déjà possible de faire ça depuis un composant, pour PEP par contre c'est le seul moyen d'implémenter ça à l'extérieur (c'était notre motivation principale).
Ça peut être utilisé avec tout ce qui est réservé normalement au serveur. Par exemple ça pourrait être utilisé pour MAM (Message Archive Management, qui permet d'avoir l'historique des conversation géré par le serveur) pour que l'historique soit stocké à l'extérieur du serveur (ou tout simplement pour l'implémenter sur un serveur qui ne le gère pas).
Dans ce cas précis, la complexité sera dans un composant (ou entité) dédié, pas dans le client, donc ça ne perturbe pas trop cette philosophie.
Mais de manière générale, les clients gèrent de plus en plus de choses, et la complexité augmente: il est possible d'avoir du pubsub sur le client lui même si on veut, et pour l'audio vidéo c'est clairement le client qui gère le plus de choses.
Après c'est des possibilités, des fonctionnalités à implémenter ou non, un client de base qui ne ferait que de la messagerie peut toujours s'implémenter de façon très simple.
Effectivement, les XEPs ne sont pas spécifiques aux composants (même si ça leur est principalement destiné dans un premier temps)
Il y a bien une méthode « traditionnelle » historique (la XEP-0114) pour connecter des composant: c'est une sorte de client simplifié, et dans le conf du serveur on met un jid à associer et un mot de passe, et voilà.
Cette méthode est simple et peu moderne, mais a le mérite d'être répandue et fonctionnelle. La XEP-0225 est plus moderne (elle permet d'utiliser TLS par exemple), mais je ne pense pas que son adoption est aussi systématique dans les serveurs. Enfin je ne me suis jamais trop penché dessus, vu que pour l'instant la XEP-0114 nous convient. Mais je pense qu'à terme, la XEP-0114 va être dépréciée au profit de la XEP-0225 ou une plus récente, mais ça prend du temps (parce que ça marche en l'état, c'est un peu le même problème avec l'adoption de pubsub pour les signets (bookmarks)).
edit: pour être bien clair, les nouvelles XEPs n'ajoutent rien pour la connexion d'un composant (ce qui existait déjà comme tu l'as dit); elles leurs permettent d'avoir un accès privilégié aux serveurs de manière générique, et de gérer des fonctionnalités qui ne pouvaient pas l'être en dehors du serveur avant.
la spécification censée faire ce dont vous avez besoin est longue, complexe, imprécise et lourde à implémenter, donc inutilisable
j'ai dit longue et complexe (encore que le complexe résulte surtout de la longueur, le principe est simple), pas imprécise et encore moins inutilisable (on l'utilise tous les jours !).
vous avez donc créé deux spécifications plus simples, plus courtes et plus précises donc plus facilement implémentables en espérant que d'autres vous suivront.
On a écrit 2 spécifications (relativement faciles à implémenter) qui permettent de développer à l'extérieur des choses qui étaient réservées au serveur, autrement dit on décentralise le code.
ah au cas où c'est pas clair aussi, même si on n'a pas encore lancé la campagne, vous pouvez déjà adhérer si vous voulez soutenir le projet, même pour 0 € :)
En effet, contrairement à ce qu'on pense souvent, il est possible d'être salarié et membre du bureau en même temps et c'est ce qu'on souhaite faire.
Dans ce cas la gestion est intéressée et il n'y aucun avantage fiscal (encore une fois, c'est tout à fait normal). Et oui on sera le plus transparent possible, on a déjà essayé d'expliquer les choses clairement sur le site (n'hésitez pas à nous dire si ça n'est pas assez clair), et il suffit de nous rejoindre sur le salon XMPP de SàT (sat@chat.jabberfr.org) pour poser des questions.
Aussi on n'a pas de président/secrétaire/trésorier vu qu'on est en autogestion et donc sans hiérarchie. Ça surprend souvent les gens y compris dans l'administration, mais c'est tout à fait possible.
Dans l'idéal tout serait implémenté par tous les serveurs oui.
Mais en pratique les implémentations sont soit inexistantes, soit incomplètes, soit ont des problèmes de performances.
Alors pourquoi c'est comme ça ? La XEP-0060 et une XEP longue et complexe (c'est une des plus longues de XMPP), et de nombreuses choses sont optionnelles. Les implémentations sont souvent incomplètes pour une ou plusieurs de ces raisons:
beaucoup de serveurs et clients se concentrent plutôt sur la messagerie instantanée, même si je pense que c'est en train de changer
comme peu de clients utilisent pubsub de manière intensive, il y a peu de demandes pour améliorer les implémentations côté serveurs
beaucoup de choses optionnelles, donc même si on a une implémentation, on n'a pas forcément ce que l'ont souhaite
il y a des choses comme les signets (bookmarks ou XEP-0048) qui au départ n'utilisaient pas pubsub - qui n'existait pas - et qui ont ensuite été mises à jour pour utiliser pubsub. Comme la première implémentation marche, beaucoup ne voient pas de raison de changer.
et surtout c'est un gros boulot, un projet à part entière, il faut les ressources pour implémenter pubsub + le boulot déjà existant sur le serveur.
Bref à mon sens c'est beaucoup plus logique d'avoir ça comme composant extérieur complet, que comme un parent pauvre du serveur. Et si on veut améliorer l'implémentation d'un serveur ça peut aller, mais tous les serveurs avec les dizaines de langages et d'architectures utilisés, c'est plus compliqué.
D'autre part, nous bougeons beaucoup sur PubSub, et il peut y avoir de nouvelles XEPs à implémenter, qui mettront du temps à arriver dans les serveurs: avec la maîtrise du composant, on peut faire une implémentation immédiatement (et pour tous les serveurs !), la chaîne de développement est beaucoup plus rapide.
Dans notre cas particulier, nous avons une extension non standard (pour le moment) qui permet d'envoyer un message à un groupe uniquement: vu qu'il n'y a pas de XEP associée, aucune chance de voir ça dans un serveur. Là on peut tester et améliorer avant de proposer une XEP.
Enfin oui ces 2 XEPs sont beaucoup plus faciles à implémenter (il m'a fallu quelques jours pour Prosody alors que ce sont mes premiers modules pour ce serveur), regarde leur taille et compare à la XEP-0060 pour comprendre, et ça peut servir dans d'autres cas qu'un composant PEP/PubSub. D'autre part tout ce qui est nécessaire à faire un service PEP est obligatoire dans ces XEPs, alors que tout ce dont on a besoin dans PubSub ne l'est pas forcément. Donc si elles sont implémentées, on est sûr d'avoir ce qu'il faut.
Oui c'est un peu ça. Vous pouvez lire les statuts et le règlement intérieur pour mieux comprendre: les membres du bureau (un bureau collégial qui prend les décisions au consensus) sont les membres actifs, et ceux qui seront (on l'espère) salariés: si on a suffisamment de sous à terme et qu'on veut salarier quelqu'un d'autre, il sera membre du bureau.
Les adhérents n'ont aucun obligation de participation, même si on a une liste de diffusion pour les adhérents et qu'on aimerait les rencontrer régulièrement.
Nous avons choisi la forme associative pour plusieurs raisons: déjà c'est très facile à créer, d'autre part c'est assez souple pour s'organiser comme on le souhaite, ensuite le but non lucratif même s'il ne protège pas de tout évite au moins l'actionnariat (ce que nous voulions) et d'accumuler l'argent n'importe comment. Il y a aussi d'autres avantages: le don à une entreprise n'est pas possible ou très difficile alors que possible pour une association. Ici l'adhésion est une forme de soutien tout à fait légal (mais nous paieront des impôts dessus une fois salariés, ce qui est tout à fait normal).
Autre chose: il est très difficile de transférer le capital d'une association sauf vers une coopérative. Or nous envisageons la coopérative à terme.
Bref, vois l'association comme une façon de « tester » l'activité, et comme un cadre légal, et l'adhésion comme un moyen de nous soutenir.
Ah aussi je précise qu'on aimerait un don régulier, mais annuel: on a une fourchette de dons qui va de 0 à 100, mais on espère une moyenne de 10€/adhérent/an, autrement dit même pas un café par mois ! Nous ferons un rappel à chaque adhérent tous les ans (pas du spam, un rappel gentil :)), sans aucune obligation de redonner ou de donner le même montant (on peut donner 10 € un an et rester adhérent pour 0 € l'année suivante, ou ne plus être adhérent du tout).
Voilà, j'espère que c'est plus clair. Nous envisageons le financement participatif pour nous lancer également…
Oui c'est assez sympa de se dire qu'on va pouvoir discuter ensemble et faire un réseau plus large en dehors de la messagerie instantanée où c'était déjà le cas.
Je pense que d'autres projets vont suivre: du côté de Poezio (très bon client XMPP console pour ceux qui lisent), ils ont commencé à parler d'une implémentation du microblogage également, j'aimerais beaucoup voir ça dans Gajim aussi, mais la dernière fois que j'en ai parlé au dév principal (il y a plusieurs années tout de même), il n'en était pas question, ils voulaient se concentrer sur la messagerie/vidéo conf (ce qui est un choix tout à fait compréhensible).
Pour ceux qui lisent ce commentaire, il y a d'autres point sur lesquels on avance, notamment avec edhelas (et quelques autres personnes) on est en train d'essayer de revoir les signets (bookmarks).
Le statut varie suivant les pays mais en gros ça t'assure seulement que le "conseil d'administration" n'est pas rémunéré pour les tâches qui découlent de ce rôle (mis éventuellement dédommagé). Tu n'as pas d'actionnaires ou truc du genre. Les dons faits aux associations ouvrent souvent droit à des avantages fiscaux. Les clients des associations s'appellent des adhérents et doivent payer une cotisation.
C'est faux ça. Tu peux très bien te rémunérer en étant au conseil d'administration, c'est d'ailleurs ce qu'on espère faire avec « Salut à Toi ». Tu n'as effectivement pas d'actionnariat dans une association type loi 1901 et tu ne peux pas accumuler de l'argent dans le vide, il faut des projets. Bref tu ne peux pas faire n'importe quoi, et si l'association est dissoute, tu ne peux pas filer l'argent qu'elle a à n'importe qui et n'importe comment.
Les dons faits aux associations ouvrent souvent droit à des avantages fiscaux.
Dans des cas très particuliers (comme association d'intérêt général). Dans notre cas en se salariant en étant au conseil d'administration, nous aurons une « gestion intéressée » et serons soumis aux impôts divers au même titre qu'une entreprise classique, ce qui me semble tout à fait normal.
Il y a une loi qui est passée il y a un an environ sur l'économie sociale et solidaire, concernant surtout les coopératives il me semble, mais je n'ai pas encore regardé ça en détails.
Les clients des associations s'appellent des adhérents et doivent payer une cotisation.
Le paiement d'une cotisation n'est absolument pas obligatoire, ça dépend des statuts. Chez nous il ne l'est pas par exemple.
Maintenant tout le reste ben… Le conseil d'administration peut toujours nommer un directeur et lui verser la totalité des rentrées d'argent de l'association sous forme de salaire ou tout reverser à une société cotée en bourse en échange d'un bout de papier sur lequel est écrit "facture".
Je doute très fort que ce que tu dis soit possible en l'état. Après je ne suis pas spécialiste non plus, et il y a sûrement moyen de contourner l'esprit d'origine. Mais il y a un encadrement légal ça c'est sûr. Je suppose que beaucoup de choses se font pas manque de contrôles aussi…
Franchement le statut d'une structure ne présage en rien de ses activités.
Ça c'est plutôt vrai, ça ne donne qu'un cadre légal. L'entreprise ou assimilé est ce qu'on en fait derrière, et dans tous les cas il y a probablement moyen de contourner et détourner des choses tant qu'on n'est pas pris…
Ma boite est constitué d'associations, de SARL, de SCI etc… Et les associations n'ont pas un but plus humain que les SARL, juste un statut plus avantageux pour l'activité. Je suis salarié d'une association et on attend de moi que je fasse cracher nos "adhérents".
Statut différent, pas nécessairement plus ou moins avantageux. Le but non lucratif a un sens légal et ce n'est pas rien. Mais une SARL peux être bien plus éthique qu'une association selon la façon dont elle est dirigée.
Après but non lucratif ça ne veut pas dire ne pas se salarier, ça veut dire qu'amasser de l'argent n'est pas le but de l'entité.
Merci pour avoir relayé cet article intéressant et politique, qui sort un peu des dépêches AFP à peine réécrites habituelles.
On voit ici l'un des effets pervers et dangereux du développement d'internet, ou plutôt de son utilisation par certaines entreprises (parce qu'au final ce n'est pas internet le problème, mais bien l'utilisation par A. - et beaucoup d'autres ! - pour casser le droit du travail et profiter de la misère). Alors que d'un autre côté il y a des exemples superbes comme Wikipédia (qui a ses défauts, mais est globalement une réussite énorme).
Raison de plus pour boycotter cette multinationale et celles qui ont un comportement similaire.
# confus
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les solutions cryptographiques aujourd'hui : le simple et le compliqué. Évalué à 9.
L'intention de citer les solutions actuellement pour le chiffrement de bout en bout est louable, mais ce journal me semble un peu confus, et surtout erroné !
OTR ne permet pas l'anonymat ! Tu confonds peut-être avec le « perfect forward secrecy » qui permet de ne pas compromettre les conversation antérieur si une clef est interceptée.
Il faut coupler à quelque chose comme TOR pour avoir un semblant d'anonymat.
ça aussi c'est faux, il est bien possible de vérifier l'identité de la personne avec OTR v2 par exemple, c'est juste qu'il faut utiliser des « fingerprint » (une séquence de caractères à vérifier), alors qu'avec la version 3 on peut utiliser une question sans passer par un canal extérieur.
Les messageries (libres) classiques sont souvent décentralisées, tu parles de P2P là (d'ailleurs tu le précises). Là aussi l'anonymat est une chose séparée, même si certains cherchent à l'inclure nativement dans leur projet.
Bon ceci dit, c'est toujours bien de parler de tout ça, donc merci pour le journal :)
[^] # Re: CAcert
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quoi de neuf côté LinuxFr.org. Évalué à 4. Dernière modification le 06 juin 2015 à 14:10.
Mais je suis tout à fait OK pour qu'on me dise quand les choix ne sont pas bons, je suis juste très (peut être trop ?) sensible à la forme, et je n'aime pas qu'on me dise qu'on fait les trucs par facilité alors qu'on sait très bien qu'il suffirait de 5 min pour faire un certificat qui ne fasse pas d'avertissement et que justement on prend une autre solution, plus compliquée (c'est facile de faire un certificat CAcert, mais plus compliqué d'expliquer aux gens pourquoi il y a un message de sécurité) parce qu'elle nous semble mieux nous correspondre. Peut-être qu'on ne fait pas le bon choix, et on va en discuter.
Et je trouve très bien de regrouper sur un commentaire les liens pour qu'on voit facilement ce qu'on peut faire en plus, d'ailleurs ça serait utile d'en fait un journal/une dépêche (un peu comme les dépêches sécurité de Skhaen).
Bon passons pour ce point.
Maintenant ces solutions on va les étudier, et on va voir ce qu'il est possible de faire, mais on a aussi beaucoup d'autres choses sur le feu, et ça prend du temps ne serait-ce que de lire les journaux, puis les spécifications, puis chercher des implémentations ou les faire si besoin.
Ok pour le côté pas plus sécurisé (mais par pour le côté solution de facilité, enfin bref). Pour nous l'aspect communautaire est un point très important, essentiel même, donc le choix de CAcert reste justifié, mais la discussion n'est pas close.
[^] # Re: CAcert
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quoi de neuf côté LinuxFr.org. Évalué à 9.
CAcert ne fonctionne pas comme les autres, c'est pas juste un « CA qui a l'air un peu plus cool que les autres », c'est un système communautaire avec validation en se rencontrant physiquement, le web de confiance. Nos convictions, pour ce cas, c'est surtout favoriser le communautaire et avoir un système plus sécurisé.
Les choses dont tu parles sont des choses annexes, qui sont envisageables en plus, mais il faut aussi pouvoir gérer au niveau du temps disponible.
Par contre je ne suis pas super fan du ton que tu emploies. « ça demande un peu plus de boulot que simplement [bla bla bla] » ==> je crois que t'as pas idée du boulot qu'on a à essayer de bien faire les choses justement, et cette façon de tourner la phrase du genre on fait juste un truc à l'arrache pour se donner bonne conscience est légèrement vexante.
On n'est pas et ne sera jamais irréprochables, mais on essaye de faire au mieux avec les moyens qu'on a. Chaque chose à ajouter, c'est une quantité du boulot derrière, et on en a déjà pas mal, du boulot. Donc petit à petit on améliore ce qu'on peut, on écoute au maximum les commentaires, mais ça prend du temps et de l'énergie.
# CAcert
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Quoi de neuf côté LinuxFr.org. Évalué à 5.
Bon déjà je (re)dis à mon tour un grand merci à toute l'équipe derrière ce site qui est la référence pour moi, autant au niveau de l'éthique que du contenu, et sites en langue anglaise compris.
Pour CAcert on est un peu embêtés, parce qu'on garde un certificat CAcert sur notre projet, et la FAQ de DLFP nous permettait de justifier ce choix. Maintenant on va se sentir un peu seuls, et la plupart des gens ne comprennent pas pourquoi ils voient un message d'avertissement en allant sur la démo de Libervia.
J'avais pourtant l'impression de revoir une activité de ce côté: présence d'un stand CAcert au Fosdem par exemple, il me semble avoir lu que Debian allait (ou a ?) ré-intégrer les certificats racine (pas trop le temps de vérifier ça maintenant, ni de risquer une mise à jour sur ma SID aujourd'hui).
Bref, on se pose sérieusement la question de garder CAcert ou pas, j'ai l'impression de trahir un (petit) peu nos convictions si on le fait, mais maintenant que même DLFP lâche le morceau, on se sent plus seuls.
[^] # Re: Petit "documentaire" ...
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche 2015, l'année du cinéma libre ?. Évalué à 3.
Superbe en tout cas, et je suis impressionné par la qualité des images. Je n'ai aucune idée de ce qu'il faut pour filmer comme ça sous l'eau, mais t'as des notions ou une formation pour filmer dans ce milieu ?
# Caminandes
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche 2015, l'année du cinéma libre ?. Évalué à 7.
Petit oubli, sauf erreur l'épisode 2 de Caminandes a également été produit par la fondation Blender, ce serait dommage de laisser de côté ce mignon lama: http://www.caminandes.com/ (l'épisode 1 a également été fait avec Blender et le tout est sous CC Attribution).
En tout cas c'est assez excitant de voir tout ça. J'ai revu récemment Tears of steel, c'est quand même très très impressionnant ce qu'on peut faire aujourd'hui (enfin en 2012 pour celui ci) avec du libre.
On voit aussi bien le problème du financement de ce genre d'œuvres, à rapprocher sans doute des difficultés pour le cinéma d'auteur.
[^] # Re: Écoutable sur le web
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Émission Symbiose spécial Art Libre sur 95.2 FM à 14h: Pouhiou et ZeMarmot. Évalué à 2. Dernière modification le 02 juin 2015 à 10:32.
Salut,
on a eu les mêmes remarques l'année dernière quand on est passés à « hotline » sur cette même radio sur l'auto-hébergement: https://linuxfr.org/users/goffi/journaux/auto-hebergement-sur-radio-ici-et-maintenant . Tu peux y voir les différentes réponses sur ce fil: https://linuxfr.org/users/goffi/journaux/auto-hebergement-sur-radio-ici-et-maintenant#comment-1565927
C'est une radio qui laisse la parole à des courants très différents, et la partie informatique n'a rien à voir du tout avec le reste.
Symbiose passait notamment sur radio libertaire, dogmazic et radio larzac si je ne me trompe pas (si luc ou manu passent par ici, ils corrigeront sans doute).
À noter qu'une partie des animateurs a quitté radio ici et maintenant en mars dernier pour une raison que j'ignore, et ils sont en train de monter un espace parisien dédié au libre avec notamment une webradio: http://libre-a-toi.org/. Je suppose qu'il y aura une annonce ici au moment du lancement.
[^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 5.
Sans vouloir nous mettre trop en avant, je pense qu'on est en plein dans ce que tu recherches (et Movim aussi sur certains points). Plus en détails:
Si si, on fait ! historique illimité, recherche, multi-appareils c'est MAM + Message Carbons et les implémentations sont de plus en plus courantes.
Chiffrement de bout en bout c'est un peu plus compliqué parce qu'il n'y a pas de bonne solution avec XMPP (c'est une vieille marotte et il y a eu plusieurs tentatives, mais rien n'a encore été largement adopté). La seule solution un peu populaire c'est OTR, et elle n'est pas (encore) standardisée en XMPP ! C'est des bidouillages de l'utiliser, mais ça fonctionne tant bien que mal, d'ailleurs on l'implémente dans SàT (et même 2 fois parce qu'on a décidé de faire une implémentation dans le navigateur pour l'interface web). Asynchronicité c'est de base dans XMPP, quel est ton problème avec ?
Le chiffrement est de base dans XMPP et même obligatoire depuis plus d'un an. Et pour SMTP là encore on peut par dire qu'on ne fait rien: c'est un truc dont on parle depuis plus de 4 ans (lire ici), on a un serveur IMAP, un serveur SMTP et un stockage Maildir dans SàT, et on fera certainement une passerelle SMTP pas pour cette version mais pour la prochaine.
Il me semble que ce journal montre justement le contraire. Tu peux essayer Movim ou Jappix, ou la démo de Libervia pour voir ce qu'on peut déjà faire, mais il y a encore du boulot c'est sûr.
L'idée de base c'était - je pense - de se dire qu'il y a moins besoin de serveurs différents que de clients différents, et donc de simplifier la vie des développeurs de clients. La philosophie est toujours valable: si tu veux utiliser juste la partie messagerie instantanée de XMPP, ou juste la partie messagerie style courriel, tu peux facilement. Si tu veux des choses avancée, il faut de toute façon souvent des implémentations côté serveur et client (MAM par exemple).
Ben les nouvelles XEPs vont justement sacrément faciliter les choses de ce côté maintenant.
Et la standardisation est un avantage énorme sur tout nouveau protocole, et à qui il faudra un temps fou (ça se compte en années) avant d'arriver au niveau de XMPP.
Nous ça faisait longtemps qu'on attendait d'être débloqué pour le microblogage, maintenant je ne vois plus rien de majeur qui va nous gêner, et je pense ne pas trop m'avancer en disant que l'utilisation et les fonctionnalités de XMPP vont exploser sous peu.
[^] # Re: XMPP et messagerie instantanée, la donne est pourrie ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4.
Pour moi ça n'aurait aucun intérêt d'utiliser XMPP si tout le monde était sur FB ou gtalk.
L'annonce de l'utilisation et de l'abandon de XMPP par FB ne m'a fait ni chaud ni froid (d'un point de vue perso je n'ai jamais vraiment utilisé, et d'un point de vue général ça ne change rien pour FB qui n'était pas fédéré, et pour Gtalk le seul intérêt est - ça marche encore - de pouvoir communiquer avec des gens dessus), et c'est à mon sens une grosse erreur de se faire héberger là bas de toute façon.
Non ce qui montre la vitalité de XMPP, c'est le nombre et le dynamisme des projets qui l'utilisent et des standards, et de ce côté j'ai plutôt tendance à penser que ça s'améliore.
[^] # Re: Précisions pour les noobs ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
Euh si ils avancent et ils sont bien maintenus (suffit d'aller sur le salon prosody pour voir comme c'est actif), c'est juste que les priorités ne sont pas forcément les mêmes que pour nous.
Et sinon un jour on va probablement implémenter un serveur aussi, ou du moins une partie de ce que fait le serveur, pour avoir quelque chose de complètement P2P/Distribué/ça_dépend_comment_vous_appelez_ça. Y'a pratiquement tout ce qu'il faut déjà avec les bibliothèques qu'on utilise, mais bon c'est vraiment pas pour tout de suite.
[^] # Re: Précisions pour les noobs ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 5.
Salut,
Simplifier c'est pas le mot, disons qu'on n'est (enfin on sera dans quelques temps si tout va bien) plus bloqués par les possibilités des serveurs (dans le sens le logiciel, après il faut que les instances de ces logiciels activent ce qu'il faut).
Dès maintenant c'est possible d'utiliser des serveurs pour faire du microblogage de base, mais ça marche plus ou moins bien. Metronome (fork de Prosody) est le serveur recommandé par Movim et Jappix, Ejabberd avait des problèmes de performance à une époque mais sinon c'est à ma connaissance l'implémentation PubSub la plus complète des serveurs, Prosody dans le version stable ne stocke pas les billets sur le disque, OpenFire j'ai arrêté à un moment suite à un bogue très gênant, je ne sais pas où ça en est, et je ne sais pas trop l'état non plus de Tigase ou autre.
Il faut principalement activer le composant PEP, il faut suivre la documentation du serveur pour voir comment faire.
La page que tu donnes cite des instances de serveurs, et du coup il faut voir au cas par cas ce qu'ils activent. Tu peux utiliser un client XMPP pour voir les fonctionnalités et la présence de « http://jabber.org/protocol/pubsub#publish » dans les fonctionnalités, et « (pubsub/pep) » dans les identités (désolé c'est un peu technique, mais c'est comme ça qu'on regarde si une fonctionnalités existe. Avec salut à toi il y a l'interface en ligne de commande pour tester ça, par exemple sur jabber.fr ça donne:
Pas de « http://jabber.org/protocol/pubsub#publish » ici ni de « (pubsub/pep) », ça n'est donc pas possible. Il faut alors soit avoir le main sur le serveur, soit contacter les admins.
Il faut d'une part que des fonctionnalités soient activées sur le serveur (pep au minimum), et d'autre part que le client soit capable de gérer ça (une compatibilité XEP-0277 au minimum). XMPP a la grande force d'être extensible, mais ça rend son approche un petit peu plus compliquée parce que les fonctionnalités s'activent ou pas en fonction de ce que sait faire le serveur/client en face.
Bon maintenant je parlais ici de microblogage de base. À ça il faut ajouter Message Archive Management (MAM) et/ou Result Set Management (RSM) pour pouvoir accéder à des message anciens (plus que les 10 derniers par exemple). Ce sont d'autres fonctionnalités que le serveur doit implémenter, et à ma connaissance, ça n'est disponible nulle part.
Nous on a un composant qui gère tout ça, mais il n'était pas possible de le « brancher » sur le serveur avant. Maintenant c'est possible avec Prosody et bientôt sur d'autres serveurs j'espère (ça marche probablement avec Metronome aussi vu que c'est un fork de Prosody). Côté Prosody c'est expliqué sur les pages wiki des modules que j'ai écrit: https://code.google.com/p/prosody-modules/wiki/mod_privilege et https://code.google.com/p/prosody-modules/wiki/mod_delegation ). Mais notre composant est en cours d'adaptation à ces nouveautés, c'est bien avancé mais il va falloir encore patienter un (petit) peu.
On n'est ainsi plus limités par les serveurs.
Rien n'empêche un client classique d'implémenter ça, mais à ma connaissance aucun ne travaille dessus. On aimerait bien en voir ! Côté Poezio (très bon client console), on en parle.
Pour l'instant les 3 seuls (sauf erreur) sont Jappix, Movim et SàT.
Non, c'est même le seul des 3 cités qui n'en a pas besoin: tu peux utiliser une interface non-web (c'est multi-interface), mais on vient de retirer l'interface de bureau parce qu'on va en écrire une nouvelle pour la version grand public (fin d'année), soit tu utilises le serveur web intégré avec Libervia. Il y a une image Docker qui permet de tester ça facilement: http://wiki.goffi.org/wiki/Docker/en (expérimentale, n'hésite pas venir demander de l'aide/dire ce qui ne va pas sur le salon XMPP de SàT: sat@chat.jabberfr.org).
Ça par contre seul SàT en est capable, mais ça n'est pas (encore) standard. On va essayer de standardiser ça dans le futur. C'est de toute façon compatible avec les implémentations classiques, et on construit tout autour de cette logique: partage de fichiers, accès au commandes internes, etc.
Voilà, j'espère que c'est plus clair, sinon n'hésite pas à demander des précisions.
[^] # Re: Routeur XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 2.
seul le serveur a besoin d'un accès, pour le client c'est totalement transparent.
[^] # Re: Routeur XMPP
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
C'est à peu près ça sauf que c'est le XEP-0355 (la XEP-0356 c'est les privilèges), et que l'autre n'est pas nécessaire.
En gros quand on demande un truc à un serveur, au lieu de le gérer directement (ou pas 'il ne connait pas le protocole), il délègue à une autre entité. Pour MUC, PubSub et une passerelle courriel ça ne change pas grand chose parce que c'était déjà possible de faire ça depuis un composant, pour PEP par contre c'est le seul moyen d'implémenter ça à l'extérieur (c'était notre motivation principale).
Ça peut être utilisé avec tout ce qui est réservé normalement au serveur. Par exemple ça pourrait être utilisé pour MAM (Message Archive Management, qui permet d'avoir l'historique des conversation géré par le serveur) pour que l'historique soit stocké à l'extérieur du serveur (ou tout simplement pour l'implémenter sur un serveur qui ne le gère pas).
[^] # Re: serveurs et clients
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
Dans ce cas précis, la complexité sera dans un composant (ou entité) dédié, pas dans le client, donc ça ne perturbe pas trop cette philosophie.
Mais de manière générale, les clients gèrent de plus en plus de choses, et la complexité augmente: il est possible d'avoir du pubsub sur le client lui même si on veut, et pour l'audio vidéo c'est clairement le client qui gère le plus de choses.
Après c'est des possibilités, des fonctionnalités à implémenter ou non, un client de base qui ne ferait que de la messagerie peut toujours s'implémenter de façon très simple.
[^] # Re: Fusion avec XEP-0114
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3. Dernière modification le 27 mai 2015 à 17:45.
Effectivement, les XEPs ne sont pas spécifiques aux composants (même si ça leur est principalement destiné dans un premier temps)
Il y a bien une méthode « traditionnelle » historique (la XEP-0114) pour connecter des composant: c'est une sorte de client simplifié, et dans le conf du serveur on met un jid à associer et un mot de passe, et voilà.
Cette méthode est simple et peu moderne, mais a le mérite d'être répandue et fonctionnelle. La XEP-0225 est plus moderne (elle permet d'utiliser TLS par exemple), mais je ne pense pas que son adoption est aussi systématique dans les serveurs. Enfin je ne me suis jamais trop penché dessus, vu que pour l'instant la XEP-0114 nous convient. Mais je pense qu'à terme, la XEP-0114 va être dépréciée au profit de la XEP-0225 ou une plus récente, mais ça prend du temps (parce que ça marche en l'état, c'est un peu le même problème avec l'adoption de pubsub pour les signets (bookmarks)).
edit: pour être bien clair, les nouvelles XEPs n'ajoutent rien pour la connexion d'un composant (ce qui existait déjà comme tu l'as dit); elles leurs permettent d'avoir un accès privilégié aux serveurs de manière générique, et de gérer des fonctionnalités qui ne pouvaient pas l'être en dehors du serveur avant.
[^] # Re: Déplacer le problème ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4.
j'ai dit longue et complexe (encore que le complexe résulte surtout de la longueur, le principe est simple), pas imprécise et encore moins inutilisable (on l'utilise tous les jours !).
On a écrit 2 spécifications (relativement faciles à implémenter) qui permettent de développer à l'extérieur des choses qui étaient réservées au serveur, autrement dit on décentralise le code.
[^] # Re: Adhésions ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 3.
ah au cas où c'est pas clair aussi, même si on n'a pas encore lancé la campagne, vous pouvez déjà adhérer si vous voulez soutenir le projet, même pour 0 € :)
http://salut-a-toi.org/adhesion.html
[^] # Re: Adhésions ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4.
En effet, contrairement à ce qu'on pense souvent, il est possible d'être salarié et membre du bureau en même temps et c'est ce qu'on souhaite faire.
Dans ce cas la gestion est intéressée et il n'y aucun avantage fiscal (encore une fois, c'est tout à fait normal). Et oui on sera le plus transparent possible, on a déjà essayé d'expliquer les choses clairement sur le site (n'hésitez pas à nous dire si ça n'est pas assez clair), et il suffit de nous rejoindre sur le salon XMPP de SàT (sat@chat.jabberfr.org) pour poser des questions.
Aussi on n'a pas de président/secrétaire/trésorier vu qu'on est en autogestion et donc sans hiérarchie. Ça surprend souvent les gens y compris dans l'administration, mais c'est tout à fait possible.
[^] # Re: Déplacer le problème ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 10. Dernière modification le 27 mai 2015 à 11:30.
Dans l'idéal tout serait implémenté par tous les serveurs oui.
Mais en pratique les implémentations sont soit inexistantes, soit incomplètes, soit ont des problèmes de performances.
Alors pourquoi c'est comme ça ? La XEP-0060 et une XEP longue et complexe (c'est une des plus longues de XMPP), et de nombreuses choses sont optionnelles. Les implémentations sont souvent incomplètes pour une ou plusieurs de ces raisons:
beaucoup de serveurs et clients se concentrent plutôt sur la messagerie instantanée, même si je pense que c'est en train de changer
comme peu de clients utilisent pubsub de manière intensive, il y a peu de demandes pour améliorer les implémentations côté serveurs
beaucoup de choses optionnelles, donc même si on a une implémentation, on n'a pas forcément ce que l'ont souhaite
il y a des choses comme les signets (bookmarks ou XEP-0048) qui au départ n'utilisaient pas pubsub - qui n'existait pas - et qui ont ensuite été mises à jour pour utiliser pubsub. Comme la première implémentation marche, beaucoup ne voient pas de raison de changer.
et surtout c'est un gros boulot, un projet à part entière, il faut les ressources pour implémenter pubsub + le boulot déjà existant sur le serveur.
Bref à mon sens c'est beaucoup plus logique d'avoir ça comme composant extérieur complet, que comme un parent pauvre du serveur. Et si on veut améliorer l'implémentation d'un serveur ça peut aller, mais tous les serveurs avec les dizaines de langages et d'architectures utilisés, c'est plus compliqué.
D'autre part, nous bougeons beaucoup sur PubSub, et il peut y avoir de nouvelles XEPs à implémenter, qui mettront du temps à arriver dans les serveurs: avec la maîtrise du composant, on peut faire une implémentation immédiatement (et pour tous les serveurs !), la chaîne de développement est beaucoup plus rapide.
Dans notre cas particulier, nous avons une extension non standard (pour le moment) qui permet d'envoyer un message à un groupe uniquement: vu qu'il n'y a pas de XEP associée, aucune chance de voir ça dans un serveur. Là on peut tester et améliorer avant de proposer une XEP.
Enfin oui ces 2 XEPs sont beaucoup plus faciles à implémenter (il m'a fallu quelques jours pour Prosody alors que ce sont mes premiers modules pour ce serveur), regarde leur taille et compare à la XEP-0060 pour comprendre, et ça peut servir dans d'autres cas qu'un composant PEP/PubSub. D'autre part tout ce qui est nécessaire à faire un service PEP est obligatoire dans ces XEPs, alors que tout ce dont on a besoin dans PubSub ne l'est pas forcément. Donc si elles sont implémentées, on est sûr d'avoir ce qu'il faut.
[^] # Re: Adhésions ?
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 4.
Oui c'est un peu ça. Vous pouvez lire les statuts et le règlement intérieur pour mieux comprendre: les membres du bureau (un bureau collégial qui prend les décisions au consensus) sont les membres actifs, et ceux qui seront (on l'espère) salariés: si on a suffisamment de sous à terme et qu'on veut salarier quelqu'un d'autre, il sera membre du bureau.
Les adhérents n'ont aucun obligation de participation, même si on a une liste de diffusion pour les adhérents et qu'on aimerait les rencontrer régulièrement.
Nous avons choisi la forme associative pour plusieurs raisons: déjà c'est très facile à créer, d'autre part c'est assez souple pour s'organiser comme on le souhaite, ensuite le but non lucratif même s'il ne protège pas de tout évite au moins l'actionnariat (ce que nous voulions) et d'accumuler l'argent n'importe comment. Il y a aussi d'autres avantages: le don à une entreprise n'est pas possible ou très difficile alors que possible pour une association. Ici l'adhésion est une forme de soutien tout à fait légal (mais nous paieront des impôts dessus une fois salariés, ce qui est tout à fait normal).
Autre chose: il est très difficile de transférer le capital d'une association sauf vers une coopérative. Or nous envisageons la coopérative à terme.
Bref, vois l'association comme une façon de « tester » l'activité, et comme un cadre légal, et l'adhésion comme un moyen de nous soutenir.
Ah aussi je précise qu'on aimerait un don régulier, mais annuel: on a une fourchette de dons qui va de 0 à 100, mais on espère une moyenne de 10€/adhérent/an, autrement dit même pas un café par mois ! Nous ferons un rappel à chaque adhérent tous les ans (pas du spam, un rappel gentil :)), sans aucune obligation de redonner ou de donner le même montant (on peut donner 10 € un an et rester adhérent pour 0 € l'année suivante, ou ne plus être adhérent du tout).
Voilà, j'espère que c'est plus clair. Nous envisageons le financement participatif pour nous lancer également…
[^] # Re: Excellent travail
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 5.
Oui c'est assez sympa de se dire qu'on va pouvoir discuter ensemble et faire un réseau plus large en dehors de la messagerie instantanée où c'était déjà le cas.
Je pense que d'autres projets vont suivre: du côté de Poezio (très bon client XMPP console pour ceux qui lisent), ils ont commencé à parler d'une implémentation du microblogage également, j'aimerais beaucoup voir ça dans Gajim aussi, mais la dernière fois que j'en ai parlé au dév principal (il y a plusieurs années tout de même), il n'en était pas question, ils voulaient se concentrer sur la messagerie/vidéo conf (ce qui est un choix tout à fait compréhensible).
Pour ceux qui lisent ce commentaire, il y a d'autres point sur lesquels on avance, notamment avec edhelas (et quelques autres personnes) on est en train d'essayer de revoir les signets (bookmarks).
[^] # Re: Pourquoi
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal XMPP et (micro)blogage: la donne a changé. Évalué à 2.
C'était juste une explication comme ça, je ne pensais pas que ça valait le coup d'en faire une dépêche :).
Tiens pendant que je suis là, souliane me fait remarquer que
leur propre protocoles => leurs propres protocoles
si un modérateur pouvait corriger…
j'ai vu aussi une ou deux autres fautes/typos mais je ne sais plus où et je n'ai pas le courage de tout relire :)
[^] # Re: Plutôt bonne nouvelle en fait.
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal La publicité ciblée s'invite chez Firefox. Évalué à 4.
C'est faux ça. Tu peux très bien te rémunérer en étant au conseil d'administration, c'est d'ailleurs ce qu'on espère faire avec « Salut à Toi ». Tu n'as effectivement pas d'actionnariat dans une association type loi 1901 et tu ne peux pas accumuler de l'argent dans le vide, il faut des projets. Bref tu ne peux pas faire n'importe quoi, et si l'association est dissoute, tu ne peux pas filer l'argent qu'elle a à n'importe qui et n'importe comment.
Dans des cas très particuliers (comme association d'intérêt général). Dans notre cas en se salariant en étant au conseil d'administration, nous aurons une « gestion intéressée » et serons soumis aux impôts divers au même titre qu'une entreprise classique, ce qui me semble tout à fait normal.
Il y a une loi qui est passée il y a un an environ sur l'économie sociale et solidaire, concernant surtout les coopératives il me semble, mais je n'ai pas encore regardé ça en détails.
Le paiement d'une cotisation n'est absolument pas obligatoire, ça dépend des statuts. Chez nous il ne l'est pas par exemple.
Je doute très fort que ce que tu dis soit possible en l'état. Après je ne suis pas spécialiste non plus, et il y a sûrement moyen de contourner l'esprit d'origine. Mais il y a un encadrement légal ça c'est sûr. Je suppose que beaucoup de choses se font pas manque de contrôles aussi…
Ça c'est plutôt vrai, ça ne donne qu'un cadre légal. L'entreprise ou assimilé est ce qu'on en fait derrière, et dans tous les cas il y a probablement moyen de contourner et détourner des choses tant qu'on n'est pas pris…
Statut différent, pas nécessairement plus ou moins avantageux. Le but non lucratif a un sens légal et ce n'est pas rien. Mais une SARL peux être bien plus éthique qu'une association selon la façon dont elle est dirigée.
Après but non lucratif ça ne veut pas dire ne pas se salarier, ça veut dire qu'amasser de l'argent n'est pas le but de l'entité.
# [Libération.fr] Miracles et mirages du «crowdsourcing»
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Revue de presse de l'April pour la semaine 19 de l'année 2015. Évalué à 3.
Merci pour avoir relayé cet article intéressant et politique, qui sort un peu des dépêches AFP à peine réécrites habituelles.
On voit ici l'un des effets pervers et dangereux du développement d'internet, ou plutôt de son utilisation par certaines entreprises (parce qu'au final ce n'est pas internet le problème, mais bien l'utilisation par A. - et beaucoup d'autres ! - pour casser le droit du travail et profiter de la misère). Alors que d'un autre côté il y a des exemples superbes comme Wikipédia (qui a ses défauts, mais est globalement une réussite énorme).
Raison de plus pour boycotter cette multinationale et celles qui ont un comportement similaire.
# Gloup ! Gloup !
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Enfin une solution pour du café libre au boulot.. Évalué à 10.
Georges Le Gloupier travaille chez vous ?