Goffi a écrit 1523 commentaires

En même temps, le monde du logiciel libre à aussi changé et est devenu moins "politisé" j'ai l'impression. Est-ce que ce rachat va inciter les libristes à migrer vers une autre forge? Et d'ailleurs pourquoi le feraient-ils

Ça dépend pour qui, nous avons jusqu'ici refusé d'utiliser Github (ou Facebook, ou Twitter) pour notre projet et association entre autre pour des raisons politiques. On ne crache pas pour autant sur ceux qui le font, et on s'est tout de même posé la question plus d'une fois notamment en assemblée générale. J'ai d'ailleurs un compte pour les contributions à d'autres projets.

[…]
C'est vrai que ça m'intrigue beaucoup cette histoire, Github est devenu au fil du temps un réseau social pour moi et j'y passe beaucoup de temps. Je ne pense pas migrer tout mon code sur une autre forge dans un avenir proche mais je vais suivre les évolutions avec grand intérêt…

Pour info j'ai commencé à intégrer des outils de forge décentralisés dans Salut à Toi, en particulier tickets et merge requests (cf. mon billet sur le sujet), le tout basé sur XMPP donc. C'est aussi agnostique de l'outil : c'est utilisé avec Mercurial pour SàT, mais l'intégration de git est prévu.

S'il y a des gens qui veulent participer à l'élaboration d'une forge décentralisée, qui est déjà fonctionnelle et qui est faite dans un langage populaire (Python), n'hésitez pas à me contacter et ou à venir sur notre salon XMPP (sat@chat.jabberfr.org), de l'aide ne serait pas de trop.

c'est bien sympa de voir l'histoire de ce logiciel, c'est marrant c'est comme lire une petite nouvelle et ça me rappelle des souvenir (j'ai connu Deluxe Paint – 2 je crois – sur Amiga), j'ai installé rapidement pour voir à quoi ça ressemble, c'est super intuitif.

Je me demandais l'intérêt d'un logiciel comme ça par rapport à quelque chose d'incomparablement plus puissant comme Gimp, est-ce qu'il y a des fonctionnalités spécifiques ? Le premier qui me vient à l'esprit est la simplicité, on comprend tout de suite comment faire une animation, ça c'est chouette.

Merci d'avoir fait connaître :)

Il y a eu un appel d'offre pour ça ?

• indépendance vis-à-vis de toute entreprise, ça nécessite donc un système décentralisé

Non, la décentralisation et la dépendance à une entreprise ne sont pas liés (sauf si on n'est pas dans du libre et que le seul serveur est géré par une entreprise). Si tu as un serveur IRC chez toi, tu n'es pas décentralisé mais tu n'es pas non plus dépendant d'une entreprise.

Et pour le coup, c'est justement un des gros problèmes que j'ai avec Matrix (avec leurs attaques gratuites de XMPP même si ça s'est un peu calmé), c'est à l'heure actuelle très dépendant d'une entreprise, il n'y a aucune implémentation alternative (à ma connaissance, corrigez moi si je me trompe), et bien qu'ils veulent en faire une association indépendante (si je me souviens bien), pour l'instant le protocole est aussi contrôlé par une seule entreprise. Autrement dit on est très loin du compte pour l'indépendance vis à vis de toute entreprise.

• messagerie, voix et vidéo

leur interface est jolie et apparemment complète (je n'utilise pas). Mais la vidéo c'est Jitsi (et donc XMPP) ou webRTC, du coup je me demande pourquoi Jitsi a été écarté vu qu'il rempli tous les critères.

Bref, c'est bien de voir le libre enfin pris en compte, mais je suis dubitatif pour le choix, et je me demande dans quelles conditions il a été pris. C'est dommage pour la communauté XMPP.

et je viens de tester sur Konsole/Zsh, ça fait bien le comportement que vous décrivez (ça colle mais n'exécute pas, il faut valider avec [entrée]).

Reste la question : comment le shell peut-il savoir qu'il s'agit d'un collage de texte et non d'une saisie manuelle ?

Les 2 manières de détecter un copier/coller que je connais c'est soit détecter une grande quantité de caractères d'un coup (on n'écrit pas 100 caractères d'un coup à la main), soit via des échappements avec le bracketed paste mode.

C'est pas génial de filer son IP à Google à chaque fois que quelqu'un balance une vidéo (ce qui arrive on ne peut plus souvent).

Ah ben je ne le savais même pas, merci du tuyau.

Salut,

ça a l'air intéressant ! Je n'ai pas encore testé, mais ça pourra très certainement me servir pour faire des captures vidéo pour présenter des fonctionnalités, ou pour des démos en conférence. Est-ce qu'il est possible/serait possible d'afficher un indicateur visuel (par exemple un cercle pendant quelques secondes, ou un trait si le doigt/la souris se déplace) à l'endroit où on clique/touche l'écran ? Ça serait super.

Merci pour le boulot et le partage :)

Précisions: la partie www.example.net devrait être chiffrée aussi, mais il y a des appels DNS qui sont très certainement en clair, et d'autre part le fonctionnement de HTTPS Everywhere peut nécessiter des requêtes (ça je n'en sais rien, je suppose, je ne connais pas son fonctionnement interne). De toute façon on sait à quelle IP c'est destiné.

edit: je pense que tu as lu la FAQ trop vite, et tu as loupé « the entire hostname part of the URL »

ça ne contredit pas ce que j'ai dit, le hostname est connu, c'est l'URL complète qui ne l'est pas (elle est chiffrée). Si tu as https://www.example.net/dossier_super_secret/fichier_super_secret?clef=clef_super_secrete toute la partie dossier_super_secret/fichier_super_secret?clef=clef_super_secrete est chiffrée par HTTPS.

Aussi la dépêche dit:

En revanche, et comme le rappelle la FAQ, l'identité du site accédé (et même généralement l'adresse complète de la page accédée) voyage en clair, sauf à coupler HTTPS Everywhere avec Tor.

c'est vrai pour le domaine, mais l'URL complète n'est pas envoyée en clair avec HTTPS.

En tout cas superbe dépêche ! Ça serait super la mettre à jour régulièrement (tous les ans ?), c'est vraiment utile.

J'en profite pour placer un article que j'avais écrit il y a 2 ans pour expliquer la différence entre centralisé/décentralisé etc. : centralisé, décentralisé, P2P, mais c'est quoi tout ça ?.

En très gros, une archi centralisée est plus simple sur le plan technique (sauf pour cas particuliers comme la montée en charge), mais pose des problèmes de gouvernance, gestion des données, etc.

Ring est une architecture entièrement P2P, c'est à dire sans serveur central (je n'ai pas regardé le détail, mais c'est ce que j'en ai compris). Ça a ses avantages, mais ses inconvénients aussi : le client doit faire le boulot du serveur, ce qui impacte la bande passante, la charge processeur – et donc la durée de vie de la batterie sur appareils portatifs –, etc. Le problème mentionné ici (pas de message hors ligne) est une des conséquences de cette archi (on pourrait y remédier avec des serveurs intermédiaires, des super nœuds ou autre, mais ça complique beaucoup et demande là encore des ressources).

XMPP est une architecture « hybride » (décentralisée avec possibilité de faire du P2P, voire d'être entièrement en P2P – sans serveur –), ce qui donne une grande souplesse.

Ring a l'air intéressant sur le papier, il faudrait que je trouve le temps de le tester. J'ai l'impression qu'on peut le rapprocher de Retroshare.

Salut,

pour l'audio/vidéo avec XMPP, tu peux regarder du côté de Jitsi (dont c'est la fonctionnalité principale), et Movim l'implémente également. Pour SàT c'est prévu pour la 0.8 (pas la version à venir, la suivante, mais j'espère pouvoir augmenter le rythme des sorties après le gros chantier qu'à été la 0.7).

Le TURN n'est pas obligatoire, c'est juste utilisé si les autres cartouches n'ont pas fonctionné pour établir la connexion P2P.

Sinon je n'ai pas encore essayé Ring même si j'en ai entendu parlé depuis longtemps, il faudra que je teste ça.

Bonjour et bravo pour ce travail et superbe outil !

Est-ce que G'MIC serait utilisable dans un logiciel non spécialisé traitement d'image, je pense notamment à l'application de filtres rapides pour des photos (sur téléphone par exemple) sans ouvrir un logiciel lourd ? Je n'ai pas regardé le code/la taille générale des bibliothèques, est-ce lourd à embarquer ?

D'autre part je me demandais si ça pouvait être utilisé pour générer un Diaporama vidéo (par exemple en donnant un effet photo papier, ou vieux film) ?

merci

On l'utilise aussi pour Salut à Toi, et j'apprécie beaucoup que l'équipe est accessible (on les retrouve sur des réseaux libres, ou dans les communautés libres en général, ici notamment), et l’anonymat (qui fait que ce sont vraiment des dons, et pas des achats cachés ou du sponsoring).

J'espère voir l'intégration d'XMPP dans les comptes externes arriver bientôt :).

Pour ma part je pourrais déjà, mon opérateur me permet d'avoir mon numéro en SIP. Enfin pour les appels sortant, pour la réception ça n'est pas possible (là du coup la redirection du tél est intéressante).

Je connais et j'ai vaguement utilisé quelques fois comme passerelle SMS. Le côté modulaire est super, mais il y a plusieurs choses qui me chagrinent :

• c'est pas simple à mettre en place pour quelqu'un pas technophile (application principale + extension(s), configuration du compte, etc.)
• ça sous exploite XMPP. Il se comporte plus comme un bot que comme une entité XMPP, j'aurais aimé voir des commandes ad-hoc plutôt que des trucs à taper à la main, une séparation propre des commandes et du texte (pas 2 espaces, des espaces de noms XML dédiés)
• j'aurais aimé que ça se comporte comme une passerelle, pour intégration invisible côté client (avec par exemple [numero]@tel.[monserver.tld] pour joindre mes contacts).
• MAM serait top pour avoir les archives SMS côté serveur
• là ça demande de travailler sur une XEP, mais une découverte/configuration automatique sur réseau local faciliterait grandement les choses

En comparaison, kde connect est loin devant (facile à installer, détection automatique sur réseau local, utilisation intégrée à KDE).

Ça reste un super projet, qui a une architecture bien pensée et qui a un gros potentiel. J'espère qu'il va continuer sur sa lancée. À terme ça serait génial qu'on puisse intégrer ça dans nos clients.

Dans un pays anglophone, on lui répondrait de suite que c'est nom commun, pas protégeable pour le coup.

T'es sûr de ton coup ? Parce qu'il y a quand même un bon paquet de boîtes pas si petites qui ont des noms que je qualifierai de plutôt communs de fruits, de parties de maisons qui permettent de faire passer la lumière, de guerrières de la mythologie, de trombinoscope, et j'en passe.

Budget Insight contribue souvent mais avec un retard de plusieurs semaines, probablement pour garder un avantage concurrentiel)

Et ils l'utilisent en production pendant ce temps donc ? Ça ne me semble pas très compatible avec l'AGPL cette histoire.

s/actuelle/actuel/

(tiens j'ai inversé l'URL et le texte clair dans mon précédent message)
J'ai déjà été en contact avec un dév de Diaspora qui a contribué à ActivityPub (Jason), mais je pense que les 2 protocoles sont partis pour vivre leur vie séparément (je vois mal comment on peut faire pour collaborer à ce point, les technos sont assez différentes).

Il est surtout important de faire des passerelles, les différents réseaux libres doivent pouvoir communiquer ensemble. Si j'avais de quoi dégager du temps je serais déjà dessus, mais avec mon rythme actuelle, il va falloir attendre un peu.

Là je t'avoue que je n'en sais pas grand chose. Au niveau XMPP ça se passe entre l'IETF pour les RFCs de base (et des choses bas niveau comme https://tools.ietf.org/html/rfc7395) et la XSF qui a autorité sur les extensions (les fameuses XEPs). Je ne connais pas les liens exacts entre W3C et IETF.

Ce qui m'intéresse c'est d'avoir un standard libre et relativement bien fait, et j'espère que ça ne se tire pas dans les pattes volontairement (avoir la main sur un standard donne un pouvoir, c'est pour ça qu'il faut faire très attention à ce qu'on utilise).

ActivityPub ré-invente la roue en refaisant ce que fait déjà XMPP depuis longtemps, et c'est fort dommage, du coup on se retrouve avec un standard de plus alors qu'on aurait pu unir nos efforts.

Cette remarque faite, j'ai jeté un œil au protocole, et je pense qu'il serait assez facile de faire une passerelle XMPP, et du coup les sites communiqueraient ensemble au prix de ressources supplémentaires (faire des passerelles a un coût par rapport à une communication native, même si a priori je ne pense pas que ça serait énorme dans ce cas). Aussi si plusieurs sites suivent ActivityPub, ça simplifierait le travail (un seul protocole supplémentaire à gérer).

En tout cas j'aimerais faire une passerelle ActivityPub, mais il faudrait pour cela que la version ait suffisamment de succès pour que j'ai de l'aide sur le développement.

Dernière petite note: je trouve vraiment dommage d'inclure les notions de « like » et « followers » dans la base du protocole, c'est vraiment se calquer sur ce qui a été imposé par les réseaux propriétaires.

Libervia inclus un serveur HTTP, donc ça serait intéressant de prendre ça en compte à ce niveau aussi, mais c'est à voir bien plus tard.

Oui côté serveur XMPP et service Pubsub ça serait très intéressant aussi. Il y a déjà eu un peu de travail dessus dans le passé au niveau des salons de discussions (avec distributed MUC et federated MUC). Disons que ça n'est pas la priorité à l'heure actuelle, mais ça pourrait en devenir une dans le futur, surtout si on arrive à transformer l'essai avec le version à venir et qu'on a un peu d'aide (pour mémoire: je suis le seul développeur actif pour le moment).

oui, mon blog, c'est à dire l'interface web de SàT. Tu peux voir le code sur repos.goffi.org (en particulier la partie pages servers et les modèles correspondant.

Est-ce qu'il y a une notion de redondance, haute-disponibilité ? Si un site ("service"?) tombe que se passe t-il?

Pas pour le moment, le framework en est à son début, on verra en fonction des besoins/demandes/ressources disponibles. Il ne se destine, pour le moment du moins, pas à des sites qui ont besoin de haute disponibilité : il y a besoin de maturité, tests en production, etc. avant ça.

J'aimerais bien intégrer ces notions à XMPP même pour commencer, en particulier à Pubsub.