Goffi a écrit 1524 commentaires

On a choisi XMPP (qui a ses qualités et ses défauts) justement pour pouvoir travailler sur une base commune, qui est déjà suffisamment extensible pour permettre tout ce qu'on veut.

Les autres projets ont choisi de faire leur propre protocole, c'est à mon avis une erreur, mais ils ont leur raisons. Je ne sais pas s'ils ont l'intention de standardiser leurs trucs respectifs (j'imagine qu'ils ont tous l'espoir de devenir suffisamment populaires qu'ils deviennent des standards de fait, mais peut-être que je me trompe).

Enfin bref, de mon point de vue, XMPP a déjà toutes les qualités pour être le « posix » de la communication (mais y'a encore du boulot pour le microblogage).

Le choix de PHP ça peut être stratégique, ou tout simplement parce que c'est le langage que les dév à l'origine d'un projet connaissent le mieux. Pour Movim je sais que c'était stratégique: pouvoir être facilement installable y compris sur un serveur mutualisé (qui fournissent presque toujours un PHP plus ou moins récent). D'autres ont fait d'autres choix (Diaspora c'est Ruby, Newebe* et nous c'est Python), question de goût/point de vue. En tout cas je ne regrette pas une seconde d'être parti sur Python :)

En tout cas, je ne serai pas contre voir un planet dédié à ce genre d'outils, et des réunions de temps en temps…

*P.-S.: honte sur moi j'ai oublié de citer Newebe tout à l'heure !

à part reddit (qui n'est pas libre, si ?) je ne connais pas les autres. Est-ce qu'ils sont libres ? Qu'est-ce qu'ils permettent de faire ?

On est en réflexion dessus, on a plusieurs possibilités envisagées, mais j'en parlerai un peu plus tard dans une dépêche, vu qu'on a une version sur le feu.

Je ne me suis pas encore attaqué sérieusement au dev Android aussi peut-être que je dis une connerie, mais l'emulateur du SDK ne suffit pas ?

On utilise XMPP qui est un standard reconnu, on peut considérer ça comme du « posix ».

On a un backend qui gére toute la partie métier, y compris les extensions, et différents frontaux qui gèrent l'affichage (le tout communicant par un IPC, D-Bus actuellement). On fait en sorte qu'il soit le plus facile/rapide possible de faire un nouveau frontal, et de ne pas être dépendant de technos graphiques (nouvelle techno = nouveau frontal, mais ça consiste surtout à lier les appels D-Bus au comportement graphique adapté).

En gros, ça ressemble à ça:

Maintenant ce qui est demandé ici, c'est de pouvoir étendre l'interface par un utilisateur (je comprends ça comme « mon microblogage s'affiche de telle façon, j'aimerais ajouter un bouton/une image/un schmilblick qui affiche tel code HTML et qui fait tel truc »), soit un truc typiquement graphique.

Or nos frontaux utilisent des environnements graphiques complètement différents:

• Libervia est un frontal web, il sort du XHTML

• Wix est un frontal WxPython, il sort du WxWidgets

• jp est un frontal cli, il sort du texte

• Primitivus est un frontal console, il sort de l'Urwid (interface console à la ncurses)

• Bellaciao est un frontal Qt et en C++, il sort du Qt

Bref, le bouton à ajouter qui sort un code XHTML ne peut être utilisable que pour Libervia.

Par contre, notre système d'extensions côté backend permet de sortir une interface avec un code XML (une sorte de micro-XUL) qui sera interprété par tous les frontaux ou presque, donc pour les cas simples on peut faire un truc commun.

Bref on essaye de factoriser au maximum, mais il y a des cas où c'est très dépendant de la techno d'affichage, d'où l'intérêt des interfaces multiples, et le probable besoin à terme de faire des extensions liées aux interfaces.

compatibles entre les frontaux tu veux dire ?
Ben vu que les frontaux peuvent être écrits en n'importe quel language (la plupart sont en Python, on en a un en C++ pour le moment), et avec n'importe quelles bibliothèques, ça me parait compromis.

Les extensions côté backend sont déjà utilisables par tous les frontaux, et elles sont capables d'afficher des interfaces.

Et j'ai pas l'impression salt (enfin l'ui web) & co utilise une architecture prévu pour que chaque bout de l'interface soit modifiable via une extension.

salt = SàT ? Dans ce cas non en effet, pour le moment les extensions sont uniquement côté backend, mais ça permet déjà de faire beaucoup de choses (à part les RFC de base et quelques XEPs principales, tout est fait sous forme d'extensions), et surtout ça profite à tous les frontaux d'un coup.

À terme si le besoin s'en fait sentir (ça sera probablement le cas au moins pour Libervia, le frontal web), on fera un système d'extensions aussi dans certains frontaux.

Attention, je parlais de l'état de fonctionnement actuel des réseaux sociaux distribués, je ne voulais pas que cela soit pris comme du: c'est de la merde ;)

Je ne l'ai pas pris comme ça, et quand bien même je suis ouvert à la critique (enfin si on y met les formes quand même), donc faut pas hésiter, c'est toujours bon d'avoir des retours :)

Pour Movim, je veux bien croire que y'a du boulot autour mais de ce que j'ai pu tester, c'est vraiment trop buggé… Et je parle même pas de ma tentative perso mais bien des pods indiqués sur le site. Et en particulier l'interface web manque vraiment d'une IHM plus claire parce que même moi, je voyais pas ou se trouvaient les zones de saisie de texte.

Bon là faudrait voir directement avec les dévs

Pour SalutAtoi, je savais que tu allais réagir :)

Ben oui, faut bien que je justifie mon temps sur DLFP au lieu de bosser sur SàT…

Mais dans l'ensemble, ce que je leur reproche, c'est le manque de fonctionnalités et je comprend du boulot que représente le dev d'un réseau distribué.

Nous sommes désormais 2 à plein temps sur SàT, et si tout va bien d'ici l'été prochain on devrait avoir une version installable facilement qui offre au minimum microblogage, partage de fichiers, organisation d'événements et chiffrage de bout en bout.
On a une 0.4 qui devrait sortir avant la fin de l'année…

Salut à vous,

voleur ! ;)

Movim: Très buggé et surtout lent et sans les fonctionnalités essentielles pour espérer remplacer un Facebook ou G+

T'as rapporté les bogues à l'équipe de dév ? Timothée bosse beaucoup dessus et avance bien, si tu aides en faisant des rapports de bogues bien comme il faut, m'étonnerait qu'ils restent très longtemps tes bogues.

Salutatoi: Très geek, trop geek et surtout si j'ai bien compris, pas moyen d'intégrer ça sur un serveur web…

Bon là c'est pour moi: pourquoi trop geek ? Y'a des fonctionnalités console et tout oui, parce que ça ne fait pas que du microblogage et apparentés, mais l'interface web est prévue pour le grand public, même si elle est encore trop complexe (on y travaille). De toute façon ce n'est pas encore considéré grand public, on prévoit ça d'ici l'été prochain (ça sera la première version nommée).

Et sinon bien sûr que c'est intégrable à un serveur web. Libervia (l'interface web) a son propre serveur web intégré, mais il suffit de faire un reverse proxy sur Apache/Nginx ou autre et c'est réglé.

http://elgg.org/

Oui c'est connu comme projet, et bien que je n'ai jamais essayé je pense pas mal. Mais c'est centralisé, ce n'est pas ce que nous (Movim, SàT, autre) on cherche. Il est nettement plus simple (et donc plus rapide) de faire un réseau centralisé, d'où son avance apparente. Si ça te convient, ben c'est parfait :).

Sinon as tu jeté un œil à Buddycloud, Friendica, Lorea, le fork de Diaspora (dont j'ai oublié le nom), pump.io, Gnu Social/StatusNet/Free social et Tent ?

Wé enfin Freenet ça existe depuis un sacré bout de temps, bien avant Twitter d'ailleurs. C'est un réseau pseudo-anonyme (basé sur un logiciel libre) qui permet d'accéder à des choses comme des sites ou des newsgroups. En plus de l'anonymat il permet la résistance à la censure (tant qu'un contenu est demandé, il est présent dans le réseau, plus il est demandé, plus il est facile à accéder), et la possibilité d'avoir de l'espace disponible sans serveur central (si je mets un fichier d'1 Go et qu'il est demandé, une fois qu'il est inséré sur le réseau je n'ai plus à me soucier de la place nécessaire pour l'héberger). C'est un projet très intéressant qui souffre(ait?) surtout d'une lenteur insupportable.

Darknet ça fait pas mal d'années que j'entends ce mot. Ça reste un terme pour renommer l'existant comme l'informatique aime bien en sortir régulièrement, et c'est probablement ce que Zimmermann a voulu dire dans l'entretien (même si je ne suis pas du tout d'accord avec sa façon de le dire). À ce moment là il serait à placer aux côtés de web 2.0, réseaux sociaux, cloud, etc.

J'ai écouté les 10 première minutes, pour Zimmermann un Darknet c'est « la capacité à 2 ordinateurs de parler le protocole de leur choix, que ça soit chiffré ou anonymisé n'y change rien » ou « internet moins le web ». D'après Wikipédia (francophone et anglophone) c'est bien anonymisé, et c'est la définition que j'ai toujours comprise. Ils ajoutent la notion d'ami à ami (F2F), là du coup c'est moins évident, puisque Freenet première version ne serait pas un Darknet.

À écouter Zimmermann (enfin à moins que j'ai mal compris) XMPP ou FTP c'est du Darknet. À lire Wikipédia, Freenet première version n'est pas un Darknet, TOR ça ne rentre pas dedans non plus. Guiton a l'air plus proche de la définition Wikipédia.
Je pense qu'un Retroshare mettra tout le monde d'accord :)

Du coup va falloir accorder les violons, est-ce qu'il y a une définition « officielle » quelque part ? Ça reste de la pignole, je trouve quand même plus clair de parler de réseau pseudo-anonyme, ou de réseau chiffré, etc.

Enfin je vais écouter la suite, mais pour le moment je ne suis pas convaincu du tout par Zimmermann.

à lire les commentaires du lien pointé, si !
Mais effectivement, l'idée est sympa et joliment implémentée :)

Oui cv est bien utile, je viens de le mettre sur 2 des mes machines :). Sans compter que ça gère d'autre outils, que ça fonctionne une fois la copie lancée (donc idéal en cas d'oubli de barre de progression), et que ça permet de voir ce qui est en cours. Tu as l'intention de l'empaqueter sous Debian et/ou dans d'autres distros ?

Je trouve l'astuce excellente, outil intéressant. Mais si j'ai bien compris ça ne marche que pour un gros fichier (ça cherche le fichier ouvert le plus gros), si tu copies une arborescente complète t'es marron.

J'en profite pour placer un petit outil que j'avais écrit, gcp: il est dans Debian et gère entre autres une barre de progression et l'ajout de fichiers à copier en cours de route, il y avait eu une dépêche à l'époque: https://linuxfr.org/news/gcp-un-outil-de-copie-%C3%A0-la-cp

Bon je suis tellement pris par Salut à Toi que je n'ai plus trop de temps à y consacrer (dernier commit en 2011), mais je m'en sers régulièrement et je vais peut-être me prendre une journée à l'occase pour ajouter 2/3 améliorations.

à noter aussi ((Ultra)|(Super))copier d'alpha_one_x86 dont on entend parler régulièrement ici.

À vrai dire, s'il y a un remplaçant digne de ce nom, ça ne me dérangerait pas que Twisted perde en popularité.

Ouai, enfin moi c'est au cœur de mon projet, et ça me ferait plus qu'un peu chier (je suis loin d'être le seul dans ce cas). Et je ne regrette pas du tout ce choix: Twisted m'a permis d'implémenter des idées très rapidement, les outils sont pratiques, et je trouve le tout relativement bien fait.

Utiliser Twisted, c'est une expérience un peu particulière : ils ont leurs propres conventions de nommage, ils réinventent la roue sur beaucoup de sujets (par exemple ils utilisent leur propre système de logging largement inférieur à celui de la stdlib). Et quand tu contribues un patch ils sont capables d'ergoter sur des points de détails comme le nombre de retours chariot dans les définitions de classe.

Les conventions de nommage, sauf erreur, c'est historique: c'était là avant la PEP 8 et ils ont gardé ensuite pour ne pas casser la compatibilité.

Pour le logging, il est parfaitement possible d'utiliser la stdlib: https://twistedmatrix.com/documents/current/core/howto/logging.html#auto3

Pour le reste c'est dommage.

Ceci dit j'ai arrêté de suivre Twisted depuis l'échec de mon fork :-)

Ah oui, j'ai vu après coup que le message avait 2 ans. Pourquoi le fork à échoué ? Et pourquoi ne pas avoir directement proposé des patchs mainsteam ?

asyncio a été conçu pour que les principales bibliothèques d'I/O asynchrones pour Python puissent s'y adapter (Twisted, Tornado, gevent…). Ce n'est pas spécialement adapté à Twisted. La notion de protocole et de transport a été adoptée simplement parce qu'elle est assez pertinente :-)

Je disais ça par rapport à ce genre de messages: l'API semble compatible, et Twisted devrait permettre à terme une compatibilité entre les deferred et les futures de Tulip. C'est vrai que ça serait super d'unifier un peu tout ça.
J'espère en tout cas que la multiplication des API asynchrones ne va pas provoquer un désintérêt pour Twisted, mais bon je ne m'inquiète pas trop surtout que le développement est toujours très actif.

À lire aussi sur le sujet, ce billet (qui a pas loin d'un an): http://labs.twistedmatrix.com/2013/01/twisted-python-3-and-you.html

Ils ont commencé le port depuis longtemps et la plupart des modules sont portés, ils cherchent à faire un port en faisant un code qui tourne à la fois sur python 2.7 et python 3, et ils ont une grosse batterie de tests pour valider ça. L'avancement peut être vu (si c'est à jour) à ces deux adresses:

• https://twistedmatrix.com/trac/milestone/Python-3.x

• https://twistedmatrix.com/trac/wiki/Plan/Python3

La syntaxe callback pose des problèmes à certains, personnellement je m'y suis fait et je n'ai pas tant de mal que ça à la débogguer (je la trouve même plutôt bien faite). Mais même s'il y a une API asynchrone qui arrive dans Python (qui a été faite en prenant en compte Twisted pour qu'il puisse l'intégrer si j'ai bien compris, tu en sauras sûrement plus que moi là dessus), ça n'apporte pas tous les protocoles supportés avec, avec les 11 ans d'expérience pour la gestions des subtilités, et les outils autour. Twisted est riche et mature, c'est une base solide.
En ce qui me concerne, c'est en particulier (mais pas seulement) la partie XMPP qui m'intéresse, et Ralph Meijer devrait remonter petit à petit Wokkel dans Twisted cette année.

Le fork semble tout à fait amical (je n'avais pas suivi ce fil je suis assez peu la liste de Twisted en ce moment), à lire en diagonale j'ai même l'impression qu'il va servir à porter le tronc principal.

Ce serait déjà bien que Twisted finisse son passage à Python 3.

asyncio a été discuté sur la liste de diffusion de twisted: https://twistedmatrix.com/pipermail/twisted-python/2013-March/026700.html

Ça change des pubs virales et des chats qui se cassent la gueule, merci pour le lien :)

Pour ceux qui trouvent ça trop long, en résumé c'est « élections, piège à cons ». L'argumentation est intéressante, je vais essayer de trouver le bouquin (les références pour ceux que ça intéresse: Démocratie. Histoire politique d'un mot aux États-Unis et en France, Lux, 2013 - ISBN 978-2-89596-090-4).

Je ne savais pas qu'il y avait eu les assemblées d'habitants dans les villages au Moyen Âge dont il parle (à part les Communes mais on n'est plus au Moyen Âge là), ça donne envie de se renseigner plus.

En suivant Wikipédia, on tombe sur ces 2 lettres émouvantes qui montrent les opinions de 2 camps opposés:

• Lettre à ma soeur militaire qui part en Afghanistan

• Réponse à mon frère qui s'oppose à mon déploiement en Afghanistan

Ça fait un peu penser au Maria de Jean Ferrat, pas tant pour le contexte - qui n'est quand même pas comparable -, que pour le frère et la sœur dans les camps opposés, sûrs de leurs convictions.

décidément un intéressant personnage

ah oui en effet, j'avais pas lu le message sur github, autant pour moi.

euh, si ! T'as même un petit cadenas en dessous du logo qui est ouvert ou fermé selon que tu utilises ou pas l'accès https.

ce que je veux dire, c'est outre le fait de proposer un truc sur github (il est hors de question que je me fasse un compte dessus), ça complique pas mal pour signer le manifeste. Je pense qu'un simple email aurait facilité les choses.

Alors oui peut-être qu'on peut envoyer un git-diff mais d'une ça oblige d'une à utiliser git, et de deux à chercher une adresse je ne sais où pour envoyer le patch.

Et puis pour la forme, ça aurait été pas mal de proposer un jid pour signer.

Il faut donc un dépôt git public.

je viens de faire le test 16 jours après la demande de suppression, mon compte a bien été supprimé…