Nous sommes heureux de vous annoncer la sortie de Salut à Toi, version 0.5. Nous nous sommes cette fois-ci concentrés sur la sécurité et le ré-usinage de certains mécanismes qui vont faciliter l'ajout de futures fonctionnalités et la maintenance.
Pour rappel SàT est un client XMPP multi-usages et multi-interfaces principalement développé en Python. Les interfaces les plus avancées sont Primitivus (console) et Libervia (web), Jp (ligne de commande) facilite les tâches d'administration, Wix (bureau/WxWidgets) est vouée à disparaître et sera remplacée par Bellaciao (bureau/Qt). Une interface pour Android est également prévue.
Sommaire
Sécurité
Un nouveau paramètre a été ajouté pour définir un mot de passe pour le profil SàT, qui est stocké haché dans la base de données. Sa version claire permet de sécuriser les autres mots de passe, dont celui du compte XMPP, qui sont eux chiffrés dans la base. Un schéma détaille comment tout ça fonctionne sur le wiki du projet : chiffrement.
Libervia supporte désormais le HTTPS. L'administrateur peut choisir quel(s) service(s) activer : HTTP, HTTPS ou les deux.
Vous pouvez utiliser OTR pour chiffrer de bout en bout vos discussions instantanées. L'interface en console Primitivus utilise la bibliothèque python potr tandis que Libervia s'appuie sur l'implémentation javascript otr.js. Ainsi, vos discussions chiffrées sur Libervia sont vraiment sécurisées puisque le chiffrement est effectuée directement par votre navigateur ; il faut par contre prévoir des ralentissements, surtout au lancement d'OTR.
Autres nouveautés
On notera :
- l'ajout des marque-pages de salons de discussion ;
- l'affichage des états dans les salons de discussion ;
- une meilleure intégration des commandes ad-hoc, permettant par exemple d'administrer le serveur depuis Primitivus ou Libervia;
- la possibilité de supprimer tous ses messages, modifier son mot de passe ou supprimer son compte depuis Libervia ;
- des menus contextuels sur les contacts et fenêtres de discussion ;
- quelques nouveautés concernant les pages de blogs statiques.
Ré-usinage
Il est important, pour un projet comme SàT (multi-interfaces), de veiller à remanier le code lorsqu'on lui trouve des défauts de conception ou bien qu'on imagine un nouveau mécanisme. Ont subi entre autre un ré-usinage pour davantage de souplesse ou de généricité :
- la découverte de services XMPP ;
- l'envoi et la réception de messages ;
- la gestion des commandes textuelles ;
- la gestion de la liste de contact ;
- l'organisation hiérarchique des constantes ;
- les raccourcis clavier de Primitivus ;
- l'arborescence des fichiers source de Libervia.
Ces modifications n’intéressent pas directement l'utilisateur mais elles nous facilitent la vie, et peut-être celles des personnes qui souhaiteraient plus tard nous filer un coup de main ! Il s'agit aussi de premiers pas pour amorcer le développement de l'interface pour téléphones portables et de nouvelles fonctionnalités.
Par ailleurs, nous misons toujours davantage sur XMLUI, le micro-format interne de description d'interface utilisateur que nous utilisons pour commander les frontaux depuis le backend. Désormais, les actions de l'utilisateur sont mieux intégrées et nous comptons améliorer le système, toujours davantage à chaque version.
Mais encore…
Le backend est maintenant distribué en tant que plugin pour Twisted et se lance par défaut en mode démon, tout comme Libervia. La séquence d'initialisation backend / frontaux a été améliorée, ceci corrige les problèmes qui pouvaient survenir lorsque SàT et Libervia étaient lancés depuis un script à peu d'intervalle. De plus, nous avons rajouté un fichier .service pour D-Bus, ce qui permet de lancer automatiquement le backend lorsqu'un frontal en a besoin.
Les chemins par défaut des fichiers utilisateurs respectent désormais les recommandations XDG : fichier de configuration dans ~/.config/sat, base de donnée et le reste dans ~/.local/share/sat. L'ancien fichier de configuration sera récupéré et éventuellement mis à jour.
Si l'adresse et le port du serveur XMPP sont laissés vides dans les paramètres de connexion, les bonnes valeurs peuvent être récupérées depuis un enregistrement DNS SRV qui correspond à la partie « domaine » du JID.
Un nouveau système de log fait son apparition, il est pleinement configurable et gère les couleurs, le formatage, le filtrage et le type de sortie (fichiers, mémoire…).
Aspect administratif
Nous avons déposé en préfecture les papiers pour la création de l'association « Salut à Toi »… cela a été accepté du premier coup, ce qui nous a agréablement surpris car le mode de fonctionnement de l'association est un peu particulier : direction collégiale, pas de président / secrétaire / trésorier mais deux co-administrateurs. Pour rappel, derrière ce projet il y a une volonté d'implication qui est incompatible avec l’exercice d'une autre activité professionnelle. Cela se traduit, pour les développeurs, par la nécessité de trouver une source de financement. Nous allons donc commencer à tester / adapter notre idée de modèle économique et ceci, bien entendu, dans le respect des engagements éthiques et moraux qui sont définis par notre contrat social.
Les adhésions à l'association sont notre source de financement privilégié ! Nous avons défini dans le règlement intérieur plusieurs montants de cotisation annuelle entre 10 et 100 euros, libre à chacun de choisir ce qu'il veut. Pour les personnes qui souhaiteraient nous soutenir sans pouvoir ou vouloir verser de contribution financière, c'est aussi possible : l'adhésion sans cotisation est prévue par le règlement intérieur. Comme ça, plus d'excuse ;-)
Il va par contre falloir attendre encore un peu avant que tout cela soit faisable par Internet. Nous allons ouvrir un compte en banque pour l'association et il faudra ensuite préparer un formulaire en ligne pour gérer les adhésions.
Rencontres
Nous étions présents cette année aux Journées du Logiciel Libre à Lyon, Pas Sage en Seine à Paris et aux Rencontres Mondiales du Logiciel Libre à Montpellier (voir les liens pour les vidéos des conférences). Nous avons pu rencontrer ou revoir quelques personnes grâce aux stands, et aux conférences de Goffi. Merci aux organisateurs de ces événements ainsi qu'à Reflets, qui a écrit un article sur SàT suite à la sortie de la dernière version, ce qui a permis de faire connaitre le projet à un plus large public.
Nous allons participer mercredi et jeudi prochain au « XMPP Summit » et à son hackaton qui se déroulent à Berlin. Serons notamment présents deux autres développeurs XMPP avec qui nous sommes en contact, dont Edhelas de Movim, et ensemble nous espérons pouvoir peser davantage pour faire standardiser de nouvelles extensions (notamment autour de Publish-Subscribe et pour le blogage) et encourager leurs implémentations.
Le samedi 27 septembre entre 14h et 17h30, Goffi participera à une émission de la radio « Ici et maintenant » enregistrée à Paris sur le thème de l'auto-hébergement. Il y a aura plusieurs autres invités dont deux développeurs de Jappix.
Nous souhaitons aussi organiser des rencontres au travers de l'association, au moins une fois par an sous forme d'assemblée générale ordinaire, et peut-être davantage. Le lieu et la date n'ont pas encore été discutés.
À noter aussi la création récente d'une liste de diffusion « users » pour les utilisateurs de SàT, qui vient compléter le salon de discussion et la liste de diffusion « dev ».
Et après ?
Nous souhaitons transférer nos propres blogs sur SàT. La version 0.6 se concentrera donc sur la fonctionnalité de blog (qui dans SàT est basée sur un système de permissions fines pour n'écrire qu'aux personnes de votre choix), le stockage d'images et l'implémentation des tags. Il s'agit de fonctionnalités essentielles et peut-être des derniers grands travaux avant la publication de la première version grand public, qui a pris un peu de retard et devrait être estampillée 0.7 ou 0.8.
Aller plus loin
- Site officiel (944 clics)
- Démo de Libervia (certificat via CaCert) (196 clics)
- Blog d'un développeur (57 clics)
- Wiki (38 clics)
- Listes de diffusion (14 clics)
- Changelog (15 clics)
- Article sur Reflets.info (44 clics)
- Vidéo à PSES 2014 (partie 1) (43 clics)
- Vidéo à PSES 2014 (partie 2) (17 clics)
- Vidéo aux RMLL 2014 (28 clics)
- JDLL (pas de vidéo) (14 clics)
- XMPP Summit 16 (25 clics)
- Radio « Ici et maintenant » (36 clics)
# Résumé
Posté par Anonyme . Évalué à 4.
Si je résume SàT par Groupware XMPP je dis une connerie ?
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
J'avoue ne jamais avoir trop compris tous ces termes. Mais si j'en crois la définition de Wikipédia: « type de logiciel qui permet à un groupe de personnes de partager des documents à distance pour favoriser le travail collaboratif. », on s'en rapproche oui, mais ça ne se résume pas à ça (ça ne sert pas qu'à travailler ;) ).
[^] # Re: Résumé
Posté par Anonyme . Évalué à 4.
je disais cela parce que "client XMPP multi-usages et multi-interfaces" ne me semble pas expliquer clairement quelles sont les applications de SàT: "groupware" parle un peu plus au deçaïdors pressés.
Tout ça pour dire qu'il aurait peut être fallu ajouter une liste des applications concrètes de SàT dans la dépêche.
J'en vois quelques unes évidentes, mais, manquant d'imagination, je passe certainement à coté des autres.
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Le problème c'est que c'est assez difficile à mettre dans une case, c'est très large.
C'est un client XMPP. C'est donc un outil de communication. Ça sert à communiquer, donc à faire plein de chose.
Quelques exemples:
discuter en temps réel avec une personne
discuter en temps réel avec un groupe de personnes
envoyer un fichier
envoyer un flux de données arbitraire à un contact
bloguer/microbloguer publiquement
bloquer/microbloguer avec un groupe restreint de personnes
communiquer avec des réseaux externes
diffuser/utiliser des menus génériques avec accès contrôler (par exemple un serveur peur autoriser des administrateurs à recevoir des statistiques, à redémarrer la machine, etc)
avoir une conversation chiffrée sans trace avec une personne (si votre correspondant ne sauvegarde pas lui-même), via OTR
faire une partie de Tarot
écouter des musiques en lecture synchronisée
utiliser un client courriel (MUA) pour lire ses messages XMPP
…
Non possible aujourd'hui, mais prévu pour le futur:
partager un groupe de fichiers
synchroniser des fichiers/répertoires
organiser des événements
…
Le tout sur différentes plateformes (web, console, bureau, etc).
[^] # Re: Résumé
Posté par voxmundix . Évalué à 2.
Ce projet pourrait avoir un bon rendu s'il fusionnait avec owncloud (qui dispose des options que SAT prévoit d'intégrer).
C'est un peu se qu'il manque a owncloud, de la communication, de la légèreté et certaines options (genre la lecture de musique directement intégré au navigateur, la fonction de microblog, etc)
[^] # Re: Résumé
Posté par Maclag . Évalué à 4.
Sans parler de fusion, parce que bon: les 2 projets sont différents, on peut souhaiter voir owncloud (ou cozycloud ou un autre) intégrer un outil de réseau social XMPP parmi ses applications.
Ça permettrait effectivement, comme tu le soulignes, de séparer proprement les différentes tâches suivant l'outil le plus adapté.
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
désolé pour les réponses tardives, mais on est actuellement au XMPP summit à Berlin, et donc peu disponibles. Owncloud a sa propre technologie, ça me semble difficile de fusionner.
[^] # Re: Résumé
Posté par Larry Cow . Évalué à 2.
Ils (OC) ont en revanche une intégration de client Jabber, via une extension.
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Sans regarder, je subodore que ça se limite à la messagerie instantanée de base, probablement via un jappix mini ou équivalent (qui est très bien pour ce que ça fait), ça n'est pas comparable à ce qu'on fait et je pense que l'intégration serait relativement compliquée.
Ce qui serait intéressant en revanche, sans parler de fusions de projets, c'est d'avoir une certaines d'intégration de l'un dans l'autre (pouvoir afficher la liste des fichier owncloud via un pubsub XMPP par exemple); mais bon on n'en est pas là pour le moment.
[^] # Re: Résumé
Posté par barmic . Évalué à 10.
C'est un vrai problème. A chaque fois que je vois un projet qui n'arrive pas à se définir lui même je pense à Google Wave et à son destin funeste. Il est difficile pour les gens de comprendre ce que tu fais si tu à toi même du mal à synthétiser simplement ce dont il s'agit.
Quand tu parle d'« envoyer un flux de données arbitraire à un contact », les gens qui comprennent de quoi il s'agit sont peu nombreux, ceux qui en ont besoin sont très rare donc c'est pas forcément la peine de le mettre en avant.
AMHA SàT est un logiciel de chat texte (vocal ? vidéo ?) et blog, le reste c'est de l'à coté (ajouter du chiffrement, envoyer un fichier, jouer à des jeux,…). Feu-MSN a toujours était décris comme un chat alors qu'il permettait aussi l'envoi de fichier et de jouer avec son interlocuteur.
Ça paraît probablement bête ce que je dis, mais ça aide clairement à donner de la visibilité à ton travail et ça pourrait t'éviter des coups de gueule.
Par ailleurs as-tu un endroit où on peut voir pour chaque fonctionnalité où est-ce que ça en est (XEP en cours ? implémentation coté client ou serveur ? etc) ? Toujours pareil ça permettrait d'améliorer la visibilité sur ton projet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Résumé
Posté par letsyl . Évalué à 3.
D'accord avec ce que tu dis, avec la nuance que SàT offre des fonctionnalités qui pourraient le démarquer d'un "simple" logiciel de chat.
Il faudrait presque pouvoir créer des "bundles" (ou simplement des paquets optionnels sur une distrib, par exemple sat-chat) pré-configurés pour des cas d'utilisation et donner un nom à ce bundle.
Par exemple, SàT serait adapté pour une utilisation comme réseau social d'entreprise (RSE). Seulement aucune boite n'ira regarder les fonctionnalités de SàT pour voir si ça peut convenir à son RSE.
Je prends cet exemple en particulier parce que la boite dans laquelle je travaille dépense une fortune chaque année pour un produit qui fait nativement moins de choses que SàT pour son RSE.
[^] # Re: Résumé
Posté par Maclag . Évalué à 5.
Que ce soit en simplifiant la description ou en proposant des bundles, il est clair que la description actuelle de SàT peut laisser perplexe le commun des mortels.
Mais je vais lui accorder volontiers le bénéfice du doute: comme le dit son auteur (enfin, maintenant vous êtes plusieurs, alors je ne veux vexer personne, mais Goffi restera dans ma tête son Papa pour un bout de temps): ils n'en sont pas encore à la première version grand publique.
J'espère que d'ici là, une communication adaptée au grand public aura été pensée également.
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Oui, mais on s'améliore sur ce point. Tu peux déjà voir les différences entre ma conf aux RMLL d'il y a 2 ans, et celle de cette année, ou je ne parle presque pas de XMPP. Il faut qu'on fasse la même chose pour le site, mais on aura certainement besoin d'un bon week-end pour ça, et pour le moment c'est difficile à trouver.
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Ben en fait le backend implémente le plus de choses possibles, mais l'idée c'est de pouvoir faire des frontaux adaptés à des cas particuliers par la suite. On pourrait par exemple en faire un qui ne fait que du microblogging à la identi.ca.
On a déjà été contacté pour ça, mais c'est trop tôt pour le moment. La prochaine version (0.6) devrait commencer à être intéressante sur ce point, on pourra en parler plus sérieusement à ce moment.
Ça m'intéresserait de savoir ce dont vous avez besoin en particulier, histoire de voir si nos priorités sont bien placées…
[^] # Re: Résumé
Posté par letsyl . Évalué à 4.
Les principales utilisations sont :
- envoi de messages qui arrivent sous forme d'email avec un lien à cliquer. J'ai encore pas compris l'utilité du truc par rapport à un simple email, mais c'est très utilisé par la direction (je suppose que c'est pour encourager tout le monde à utiliser le RSE).
- news
- blogs
- partage de fichiers
- organisation d'événements
- wiki
- et dans une moindre mesure les forums
Ces fonctionnalités peuvent être regroupées dans des "espaces" avec la possibilité de donner des droits différents au sein de chaque espace.
Après on peut voter pour un contenu (yay !), entrer un relation avec quelqu'un et consulter son profil, mais là aussi je n'ai pas compris l'intérêt.
Pour moi, le principal manque dans l'outil qu'utilise ma boite est l'absence de messagerie instantanée. C'est un gros frein à son adoption.
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Je ne suis pas forcément fan du besoin de toujours devoir synthétiser, rationaliser. On a plusieurs points liés à ce projet, et ça n'est pas fait pour un cas d'utilisation précis. Maintenant les différents frontaux peuvent se concentrer sur un cas précis sans soucis, mais le projet dans son ensemble est large. Si tu veux résumer, tu peux dire un « client XMPP ».
Je le mets en avant quand j'ai un public que ça peut intéresser (des gens techniques sur un salon par exemple), ceci est possible avec l'interface en ligne de commande qui s'adresse déjà à un public technique.
C'est un client XMPP, ça ne se limite pas au chat ou au blog (pas encore de vidéo, mais on en parlera sûrement l'année prochaine).
Mon message est indépendant du projet, de manière générale je trouve dommage cette excitation à chaque annonce pour des trucs pas toujours commencés, Diaspora en a été l'exemple le plus caricaturale, et a contrario j'ai trouvé tout autant dommage qu'on le considère comme mort quand il a été repris par la communauté (pour ma part c'est là que j'ai commencé à lui faire confiance).
Quel est le problème avec ce message ?
Non mais on en a parlé aujourd'hui justement (on est à un hackathon XMPP à Berlin là), c'est donc la confirmation qu'on a besoin de le faire… On va retravailler sur le site aussi qui est trop technique, et parler un peu plus de l'association, mais comme pour tout faut qu'on trouve le temps de faire ça. Aujourd'hui on va essayer de travailler sur les standards déjà, y'a du beau mon ici (développeurs prosody, openfire, movim, buddycloud, etc).
[^] # Re: Résumé
Posté par barmic . Évalué à 6.
Ça n'est pas du tout une question de rationalisation, mais de structuration. Comment peut-on se servir d'un outil si on est pas en mesure de savoir ce qu'il fait ? Comment est-ce que des gens peuvent venir vous aider s'il faut potasser des pages de descriptions longues comme le bras pour comprendre à peu près ce qu'est SàT ? Comment comprendre ce que vous faites si les différents développeurs ne décrivent pas la même chose ?
La communication est importante à partir du moment où tu veux pouvoir partager ton travail et ça peut vraiment devenir problématique. Même de très gros projets ont eu des problèmes avec ça (pensons à Gnome OS par exemple).
Oui mais ce serait bien d'avoir une base, une idée directrice, une vision,… Là tu nous explique que tu fais un truc qui fait tout même le café, mais bon le café qu'il fait n'est pas encore très bon. Délimite une base fonctionnelle que les gens puissent comprendre.
Au passage ok, SàT est un client XMPP, mais tu modifie XMPP (via des XEP) pour pouvoir faire SàT. Tu n'implémente pas tout XMPP (pas d'internet des objets si j'ai bien compris) et au contraire tu cherche à augmenter XMPP pour ton besoin. C'est bien que ce n'est pas simplement un client XMPP, c'est un client XMPP développé dans une direction donné et c'est cette direction qui n'est pas mise en valeur.
Tu répondais surtout à quelqu'un qui parlait de remplacer XMPP, qui semblait penser que XMPP est mort ou est du passé.
Ce sera vraiment bien. Pour le moment, ne le prend pas mal, mais moi, j'ai l'impression que SàT essaie de tout faire et ne fait rien de bien (par bien j'entends "qui soit utilisable pour l'utilisateur moyen").
AMHA, mais ça n'est que mon avis, avant de courir vers la perfection XMPP et de pousser des XEP qui remplace ARP, il faudrait sortir quelque chose qui fonctionne, même s'il ne fait pas grand chose de plus que gajim ou pidgin. Ça permet d'avoir une base d'utilisateurs qui font des remontés, proposent des idées, d'avoir des contributions, d'avoir une base de testeurs et des gens qui vont faire de la doc et de la com'. Ça permet aussi d'avoir une base fonctionnelle éprouvée sur la quelle s'appuyer pour faire la suite. Les développeurs de serveur pourront aussi plus facilement tester l'interopérabilité entre leur serveur et ton client (si ton client est l'un des seuls à implémenter leur nouvelle fonctionnalité).
AMHA c'est pas du temps de perdu que de stabiliser une base fonctionnelle, c'est un investissement pour la suite (ou une dette que tu t'évite au choix).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Résumé
Posté par Maclag . Évalué à 4.
Un des problèmes quand on inclut "XMPP" dans la description, c'est que XMPP couvre tout et n'importe quoi.
Il me semble effectivement indispensable de définir un but au projet. Après tout, XMPP est censé être un outil, pas le but lui-même.
Aujourd'hui, il y a effectivement des applications qui partent dans tous les sens (quelqu'un parlait de réseau d'entreprise, on peut jouer aux cartes…).
Je ne trouve pas forcément que c'est un mal à ce stade. Ça permet de tester l'architecture et pas se rendre compte 2 ans après qu'y a un truc dans le cœur qui empêche de faire un machin, et il faut casser la compatibilité avec les back-end.
Mais pour une version grand-public, je ne m'attends pas non plus à voir "Adapté aux réseaux d'entreprise" et "jeux de carte" dans le même paragraphe (ou sur le même site promotionnel…).
[^] # Re: Résumé
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 11 septembre 2014 à 13:57.
Oui, pour l'instant nous cherchons principalement à avoir un chat complet (ça c'est plus ou moins le cas, il nous manque quelques gadgets comme la modification du dernier message, et des trucs plus utiles comme l'historique côté serveur), et un (micro)blogage complet.
Les choses que nous faisons à côté c'est soit parce qu'on en a besoin (les commandes ad-hoc, qui servent à faire la télécommande, sont nécessaire pour configurer par exemple prosody). Après parfois on s'amuse un peu, c'est utile pour rester motivé, et ça permet de pousser un peu (la télécommande n'est qu'un usage à peine détourné des commandes ad-hoc, ça m'a pris un soir et m'a sorti un peu du code chiant).
Oui je pense que c'est une erreur en effet, et je critiquais aussi la cause à mon avis de ce raisonnement.
Non je ne le prends pas mal au contraire. Je suis quelqu'un de très susceptible si on ne met pas les formes quand on me parle: quelqu'un qui me prend de haut je l'enverrai chier au quart de tour. Mais je suis preneur de critique justifiée, et effectivement pour l'instant on ne fait pas les choses parfaitement (pour le chat on commence à être pas mal quand même). A priori on devrait être bien pour le (micro)blogage à la prochaine version, ça se stabilise (on bosse aujourd'hui sur les XEPs pour ça justement.
Les 2 XEPs sur lesquelles je travaille, qui sont les premières vu qu'avant je n'avais pas le temps avant que souliane me rejoigne, sont pour utiliser notre service pubsub avec n'importe quel serveur. Ça permet d'accélérer le développement, de ne plus être compatible qu'avec prosody avec une bidouille sale, et d'avoir la compatibilité avec Movim et Jappix. Ce n'est pas de la nouvelle fonctionnalité, ça sert plutôt à stabiliser ce qu'on a et le faire de manière plus propre.
Oui nous avons attendu avant de vouloir avoir des utilisateurs. Avec l'utilisation de SàT pour nos propre blogs, on devrait avoir un microblogage suffisamment au point pour une utilisation régulière pas une communauté, au moins de premiers testeur (nous avons déjà quelques personnes qui utilisent régulièrement et nous font des remontées, même si nous décourageons ça car nous n'avons pas encore de politique de sauvegarde sur le serveur de démo).
Les 2 XEPs qui devraient établir la compatiblé avec Movim/Jappix devraient aussi permettre d'avoir une communauté active.
Même si on peut donner une impression différente, on ne va pas vraiment dans tous les sens, on a cheminement relativement logique, par moment on ajoute des trucs parce qu'on en a besoin (par exemple les marque-page à cette version), et des fois on a implémenté un truc qui nous donne envie d'essayer de bidouiller, parce que c'est motivant aussi de sortir un peu des sentiers battus (ex. la télécommande). La plupart du développement va toute de même dans la stabilité et le chat/microblogage.
# Sécurité
Posté par moules . Évalué à 5.
En quoi est-ce à Libervia de gérer ces aspects ? Ce n'est pas plutôt au serveur web de gérer le protocole SSL/TLS, et à l'application web de se contenter de la couche applicative ?
[^] # Re: Sécurité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Le serveur web est intégré dans Liberiva.
[^] # Re: Sécurité
Posté par moules . Évalué à 3.
Est-ce que tu peux expliquer ce choix ?
[^] # Re: Sécurité
Posté par Anonyme . Évalué à 3. Dernière modification le 09 septembre 2014 à 10:51.
facilité de diffusion je suppose … quoique je viens d'y jeter un coup d’œil, et en terme de facilité de déploiement, serveur http interne ou pas, il faut vraiment en avoir envie.
Avant les fonctionnalités de blog, je préfèrerai avoir une installation plus automatisée
[^] # Re: Sécurité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Ça va venir, c'est pour ça qu'on ne parle pas encore de version grand public. La difficulté vient principalement du fait qu'il faut transpiler le python en javascript (d'ailleurs on devrait peut-être envisager des paquets déjà transpilés, ça simplifierait l'installation).
Nous sommes en train de travailler avec des développeurs Debian pour que Libervia arrive dedans (peu probable avant le freeze malheureusement), et ça devrait être le cas dans d'autres distributions comme Arch.
L'autre difficulté est que nous devons utiliser un service PubSub maison, et ça demande une bidouille dans Prosody (Prosody uniquement pour le moment). Nous avons commencé à travailler sur les standards pour avoir une version générique et simple à installer, nous espérons que ça sera le cas pour la 0.6 (je peux détailler le pourquoi technique si ça intéresse).
donc si tout va bien, d'ici quelques mois un « apt-get install sat-xmpp-libervia » ou l'équivalent pour votre distro devrait suffire, suivit d'une éventuelle ouverture de port sur votre firewall, voire d'options particulières à votre installation dans le sat.conf.
[^] # Re: Sécurité
Posté par Reihar . Évalué à 1.
Tu as entendu parler de metronome? C'est un fork de prosody avec le PubSub.
[^] # Re: Sécurité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Oui bien sûr que je connais. Mais nous avons des besoins particuliers (en particulier pour les permissions fines, c'est à dire la possibilité d'envoyer un message à un groupe de personnes plutôt que publiquement), et nous ne voulons pas être dépendants d'un serveur en particulier. Avoir la maîtrise sur le service pubsub permet de ne pas être bloqué pour développeur une fonctionnalités en cours de standardisation, ou non encore standard.
[^] # Re: Sécurité
Posté par Reihar . Évalué à 1.
Je m'en doutais mais j'ai préféré demander au cas où. :)
[^] # Re: Sécurité
Posté par barmic . Évalué à 3.
Il y a une différence entre "transpiler" et "compiler" ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité
Posté par djano . Évalué à 3.
Pas vraiment.
On utilise souvent le terme "compiler" pour passer a un langage ayant un niveau d'abstraction bien inférieur (C -> ASM, OCaml -> code natif), alors qu'on utilise plus volontiers transpiler lorsque les niveaux d'abstraction du langage source et du langage cible sont équivalents (Python -> Javascript, Java -> Javascript). Ceci dit, on utiliser également le terme compiler la ou l'on utilise le terme transpiler, donc il n'y a pas de terme unique ou inapproprié.
[^] # Re: Sécurité
Posté par barmic . Évalué à 2.
J'avais jamais entendu ce verbe. Ça fait suer de transpi?er du code comme ça ? :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité
Posté par djano . Évalué à 2. Dernière modification le 09 septembre 2014 à 18:10.
Je ne suis pas sur de l'origine.
Avant d'avoir la page wikipedia, je ne connaissais pas non plus.
Est ce cet effet?
http://blogs-images.forbes.com/alexknapp/files/2011/11/citogenesis.png
[^] # Re: Sécurité
Posté par BAud (site web personnel) . Évalué à 0.
et pourtant, c'est sur le wiktionary transpiler o_O (bon, on va dire qu'il y a bien capillotracté aussite /o\).
[^] # Re: Sécurité
Posté par djano . Évalué à 2.
Ce n'est pas moi qui l'ai créée, promis :)
[^] # Re: Sécurité
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 11 septembre 2014 à 15:44.
Qui est ce « on » ? Parce que bon, je ne vois pas l'intérêt de ce « verbe ». Traduire ou compiler sont tout à fait adapter.
[^] # Re: Sécurité
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui, ce choix a été fait pour plusieurs raisons: rester sur Twisted déjà, en développement asynchrone, avoir la maîtrise simplement sur le serveur, faciliter le déploiement (pas de serveur à installer et configurer), et c'était très facile à faire car le serveur fait partie de Twisted lui même. Donc beaucoup d'avantages, alors qu'avec un serveur externe nous aurions sans doute eu d'autres problèmes à gérer, et en tout cas une installation plus compliquée. Ça nous permet aussi de contourner des problèmes, comme l'impossibilité d'envoyer un message D-Bus à un autre utilisateur du système.
Ici soit une utilise le serveur intégré et il n'y a rien d'autre que le firewall à gérer, soit on utilise un serveur web principal déjà en place, et il suffit de faire un reverse proxy. En bonus il est possible d'avoir le serveur principal sur une machine et SàT/Libervia dans une machine virtuelle par exemple.
# [HS] Quel serveur XMPP ?
Posté par gUI (Mastodon) . Évalué à 4.
Je voudrais monter un serveur XMPP privé (mais accessible depuis Internet) pour les copains/copines de mes gamins. Je dis "privé" parce que je dois simplement interdire n'importe qui de se connecter, moi doit pouvoir créer un nouvel utilisateur.
Je suis resté sur un echec avec Jabber que j'ai trouvé hyper lourd (c'était il y a longtemps, je suis prêt à remettre en question mon jugement).
Que me conseillez-vous ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: [HS] Quel serveur XMPP ?
Posté par Reihar . Évalué à 3.
Je dirais prosody/metronome. C'est léger et simple à configurer.
[^] # Re: [HS] Quel serveur XMPP ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
prosody: simple, fonctionnel et léger.
[^] # Re: [HS] Quel serveur XMPP ?
Posté par gUI (Mastodon) . Évalué à 2.
A l'unanimité, je vais donc tenter
prosodyMerci à tous les 2 !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Super !
Posté par edhelas (site web personnel) . Évalué à 7.
Coucou Goffi :)
Superbe version avec plein de trucs à tester. Je vois qu'on s'approche de pas mal de fonctionnalités communes entre SàT et Movim ça va être sympa de bosser ensemble là dessus pour voir comment on peut améliorer l'intégration et le standard (je pense particulièrement à Microblog mais pas que…).
On se voit au Summit donc on va avoir un peu de temps de parler de tout ça ;)
edhelas
# SaT et Movim
Posté par mahikeulbody . Évalué à 0. Dernière modification le 12 septembre 2014 à 18:40.
C'est complètement subjectif mais je trouve que le nom (Salut à Toi) est très sympa mais pas "vendeur". A cet égard, je trouve que Movim "passe" mieux.
A propos de Movim, peut-on considérer que les deux projets ont la même cible fonctionnelle ou bien y a t-il des applications de l'un qu'on a peu de chances de voir sur l'autre (et vice versa) ?
Pour les fonctionnalités de base que les deux ont (ou auront) - chat, micro-blogging, partage, etc… - quels sont les critères qui peuvent conduire à préférer l'un plutôt que l'autre ? Par exemple, les deux permettent-ils de changer de serveur sans perdre son historique ? Puis-je passer de l'un à l'autre ?
En tous cas bravo à tous les deux (et à ceux qui vous accompagnent dans ces deux projets).
[^] # Re: SaT et Movim
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Oui c'est un truc qui re-sort souvent. Le nom a été choisi pour plusieurs raison, notamment éviter d'avoir un énième nom anglophone (ou qui sonne comme tel).
« Salut à Toi » est le nom du projet dans son ensemble, les gens auront plutôt tendance à parler de Libervia ou Bellaciao qui sont les interfaces.
Au niveau du microblogage and co (messagerie par exemple), ça ne sera pas forcément présenté de la même façon, mais on devrait avoir à peu près les même fonctionnalités. Après SàT est plus large sur ce qu'on veut faire, mais c'est pas forcément intéressant selon l'usage que tu veux en faire. Les interfaces multiples par exemple sont d'un intérêt ou manque d'intérêt évident selon l'utilisation que tu as.
On devrait à terme se valoir sur ces points, après tu pourras choisir de la même façon que tu choisies entre Gajim ou Swift, Pidgin, Psi, etc. On n'a pas les mêmes priorités non plus: Movim a déjà commencé à s'attaquer à la vidéo conférence par exemple, alors que nous on garde ça pour plus tard.
Merci :). Faut pas hésiter à nous contacter au besoin, et Movim aussi, nous sommes des projets clairement amis…
# Rappel passage radio
Posté par souliane . Évalué à 1.
C'est demain à partir de 14h sur http://icietmaintenant.com (95.2 FM).
Les autres invités :
- Benjamin Bayard
- Eric, Ju et Stéphane de franciliens.net
- Julien Barrier et Valérian Salliou de Jappix
- Tubahn, qui a écrit le script Host@Home (http://linuxfr.org/users/thuban-0/journaux/host-home-faciliter-l-auto-hebergement)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.