Planet Libre

Goffi : Parlons XMPP - épisode 8 - PubSub et PEP

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Aujourd'hui nous allons expliquer dans les grandes lignes comment fonctionnent « PubSub » et « PEP », et voir à quoi cela peut servir. Cet article va reprendre en partie ce que j'ai dit à la conférence « PubSub, microblogage et XMPP » en juillet dernier aux RMLL.

PubSub signifie « Publish/Subscribe » (Publication/Abonnement), c'est un mécanisme qui permet à une ou plusieurs personnes de publier toutes sortes d'informations sur un endroit connu (qu'on appelle un nœud) et aux personnes qui le désirent de s'abonner, c'est à dire d'avoir accès au contenu et d'être averti des modifications, le tout avec un système d'accès simple. Il s'agit du patron de conception « observateur/observable » décentralisé et appliqué à XMPP.

Le fonctionnement est expliqué dans la XEP-0060, c'est une des XEPs les plus longues de XMPP mais le principe est relativement simple à comprendre. Sans reprendre le long glossaire du document, expliquons quelques termes :

  • le service PubSub est l'entité qui gère le mécanisme de publication, d'autorisation, d'abonnement, de notification. C'est une entité XMPP et un jid y est donc associé, c'est à lui que vous faites toutes les requêtes pour un nœud donné.
  • le nœud est un espace associé à une publication. On peut associer ça à l'adresse d'un flux Atom.
  • un « item » (élément) est une publication dans un nœud. On peut associer ça à un article dans un flux Atom.
  • cet « item » contient un « payload » (charge utile), c'est à dire un contenu significatif qui dépend de la fonctionnalité utilisée. En effet la XEP-0060 décrit un mécanisme générique et souple, qui est ensuite utilisé dans des cas pratiques par d'autres extensions.

Un service PubSub est généralement un composant de votre serveur, mais ça peut-être n'importe quelle entité : votre serveur lui-même (c'est le cas avec PEP que nous allons voir ci-dessous), ou un client voire votre client lui-même (mais c'est assez rare – je n'ai jamais vu de client le faire –, car en général on utilise le service de son serveur).

Le mécanisme général est très simple et centré sur les nœuds : chaque entité (associée à un jid) à un rôle lié à ce nœud selon qu'elle l'ait créé, qu'elle soit publieur, abonné, banni ou sans lien avec le nœud. À ces rôles sont donnés des autorisations : le droit d'écrire (avec le « publish model » ou modèle de publication) et le droit en lecture (avec l'« access model » ou modèle d'accès).

Reprenons de manière un peu plus formelle. Les rôles dont nous avons parlé sont appelés « affiliations », et on peut avoir les suivantes:

  • owner (propriétaire): en général celui qui a créé le nœud
  • publisher (publieur): celui ou ceux (il peut y en avoir plusieurs) qui ont accès en écriture
  • publish-only (publication seulement): droit d'écriture mais pas de lecture, c'est un cas peu fréquent.
  • member (membre): quelqu'un qui est abonné au nœud
  • none (rien): l'entité n'a pas de lien avec le nœud
  • outcast (banni): l'entité a été explicitement interdite d'accès au nœud

La section 4.1 de la XEP-0060 fourni un tableau qui montre les autorisations selon l'affiliation. Ainsi on voit que le propriétaire peut publier ou configurer un nœud.

Les modèles d'accès (pour la lecture) définis dans la XEP-0060 sont les suivants:

  • open (ouvert, public): tout le monde peut lire le nœud
  • presence (présence – oui je traduis même pour un seul accent –) : si une entité est autorisée à voir la présence du publieur, alors elle peut accéder au nœud
  • roster (liste de contacts): si une entité est dans un groupe défini (dans la configuration du nœud) de la liste de contacts du service pubsub, elle a accès au nœud.
  • whitelist (liste blanche): des entités sont explicitement autorisées dans la configuration du nœud

Et rapidement les modèles de publication:

  • publishers (publieurs): quelqu'un qui a l'affiliation publieur peut écrire
  • subscribers (abonnés): n'importe quel abonné peut écrire
  • open (ouvert/libre): tout le monde peut écrire

Il faut bien noter une chose essentielle dans PubSub : quand la combinaison autorisation/abonnement/configuration le permet, on reçoit une notification immédiatement quand un élément est publié, modifié ou supprimé. Autrement dit on n'est plus du tout dans l'analogie avec un flux Atom – où on doit aller vérifier régulièrement qu'il n'y a rien de nouveau –, on est prévenu si nécessaire. Ceci est beaucoup plus efficace, rapide, et économe en ressources.

Voilà pour la base. La XEP défini d'autres choses qu'il n'est pas forcément pertinent d'expliquer ici, comme les métadonnées ou les inscriptions temporaires. On peut toutefois s'arrêter sur les collections, qui ne sont que mentionnées dans la XEP-0060 mais décrites en détails dans la XEP-0248. Elles permettent de faire des arbres de nœuds, et ainsi de représenter des données avec des relations entre elles. Des exemples valent parfois mieux qu'un long discours: les collections peuvent être utilisées pour représenter un système de fichiers sur un disque dur, ou un arbre généalogique.

Tout ceci est souple, générique, puissant, et relativement facile à utiliser par un client. Mais la XEP étant très longue, et l'implémentation de la partie service plus complexe, les implémentations ont mis du temps à arriver (et encore aujourd'hui elles sont très inégales). Comme PubSub peut être intéressant même sans tout le mécanisme, une version simplifiée est décrite dans la XEP-0163: « Personal Eventing Protocol » (Protocole d'évènements personels).

Cette dernière se base sur PubSub, mais définit les règles suivantes qui simplifient beaucoup :

  • 1 compte (jid) = 1 service : probablement la règle la plus importante, elle évite d'avoir à chercher un service PubSub associé à un jid, puisque le service est l'adresse canonique (« bare jid ») de l'entité. Ainsi pour la microblogage (XEP-0277), il suffit de connaître le jid de la personne – le nœud étant défini dans la XEP – pour retrouver ses publications.

  • 1 publieur par nœud : le propriétaire et le publieur sont le même, et il n'y a qu'un publieur par nœud. On se coupe ainsi de l'édition collaborative par souci de simplification, et il faudra utiliser PubSub pour ce genre d'applications.

  • accès par présence par défaut : sans rien toucher, il suffit d'avoir quelqu'un dans sa liste de contacts (et qui a accès à la présence) pour qu'il soit autorisé à voir nos publications

  • notifications filtrées sur l'intérêt exprimé : pour éviter d'être submergé de notifications, une entité/un client doit explicitement indiquer qu'il est intéressé par tel ou tel nœud

  • options par défaut au plus simple

PEP était utilisé au début pour des événements (sans grand intérêt à mon sens) comme l'humeur ou la musique en cours d'écoute, mais depuis son utilisation a évolué.

Voici, pour finir, quelques exemples d'utilisation de PubSub ou PEP:

  • enregistrement de données publiques ou semi-publiques (XEP-0222), par exemple une clef publique de chiffrement
  • enregistrement de données privées (XEP-0223), très utile pour n'importe quelle donnée de petite taille
  • les marque-pages (XEP-0048) utilisés pour les salons de discussions utilisent PEP (la XEP-0048 a été modifiée après l'apparition de PEP pour s'y adapter)
  • le microblogage bien entendu (XEP-0277), qui utilise PEP et utilise du Atom pour sa « charge utile » (« payload ») et un accès en général public. Les commentaires sont sur un nœud PubSub séparé, en général avec un modèle de publication par abonnement.
  • la XEP-0214 utilise PubSub et les collections pour faire un dépôt de fichiers
  • le futur protocole de discussions de groupe « MUC 2 » devrait se baser sur PubSub

PubSub pourrait aussi être utilisé pour placer des points sur une carte, faire un wiki, organiser des événements, ou encore gérer et surveiller une batterie de serveurs qui nous préviendraient en cas de problème.

Je reviendrai sûrement plus tard sur tout ça pour expliquer le microblogage ou d'autres extensions.

La prochaine fois, je pense vous parler de Jingle (mais pas de la partie vidéo-conférence). J'espère qu'à ce stade vous commencez à comprendre que XMPP n'est pas une technologie, mais un ensemble de technologies coordonnées et qui se réutilisent les unes les autres quand nécessaire.

J'ai un peu réduit le rythme des articles ces derniers temps car je travaille sur mon projet, et qu'une partie a été traduite en anglais avec l'aide de pas mal de monde (merci encore !), tout cela prend du temps.

Si vous venez à la fête de l'huma ce week-end, vous pourrez me trouver au village du libre, où Parinux me prête gentiment un bout de stand (merci aussi !). Je n'y serai pas en permanence, car je compte aussi profiter un peu de la fête :)

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Vous voulez du (micro)blogage, de la décentralisation et du chiffrement sur Android ?

Salut à vous !

 Aujourd'hui nous lançons une petite campagne de financement participatif pour le développement d'une version Android de Libervia/Salut à Toi. Nous souhaitons ici développer une application native, avec toutes les fonctionnalités avancées dont nous disposons déjà, telles que le (micro)blogage, le chiffrement de bout en bout via OTR (et il est possible que nous ajoutions OMEMO/Axolotl, une nouvelle méthode permettant de chiffrer les messages hors ligne ou dans une discussion de groupe), le partage de fichiers, ou des choses plus exotiques comme une télécommande universelle. Ce développement fonctionnera également sur bureau (Gnu/Linux bien sûr, mais il devrait fonctionner sur d'autres plateformes comme Windows ou Mac OS X) avec la même interface. Il existe déjà quelques clients Android (comme le très joli Movim de notre ami Edhelas, Conversations ou Xabber), mais aucun n'offre actuellement le même bouquet de fonctionnalités que Libervia/Salut à Toi, aussi ce développement sera un vrai plus. D'autre part nous sommes particulièrement attentifs à l'éthique (cf notre contrat social) et nous sommes organsiés en association loi 1901 en autogestion, dans l'idée de faire une coopérative sur le long terme. Cette campagne est aussi l'occasion de tester un moyen de financement, et nous avons choisi Arizuka car ce site se concentre sur les projets de l'économie sociale et solidaire. Voilà, donc maintenant on compte sur vous ! N'hésitez pas à poser vos question soit en commentaire, soit par courriel (goffi@goffi.org) soit sur notre salon de discussion XMPP: sat@chat.jabberfr.org lien vers la campagne: http://www.arizuka.com/fr/projects/liberviaSalut à Toi: http://salut-a-toi.org 
P.-S. : nous préparons aussi une (grosse) nouvelle version dans les semaines à venir, je ferai certainement une série d'articles pour expliquer les nouveautés et comment se servir de Libervia ou SàT en général.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Parlons XMPP - épisode 9 - copie de fichiers et Jingle

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Bien que déjà répété un certain nombre de fois, je le redis : XMPP fait bien plus que de la messagerie instantanée. Une des fonctionnalités qui est apparue rapidement est la copie de fichiers, voyons cela de plus près

Le problème : XMPP étant du XML, il n'est pas vraiment adapté aux données purement binaires comme des fichiers. La solution est de passer par l'extérieur, c'est à dire une autre connexion non XML, et d'utiliser le flux XML pour la gérer, on parle de connexion « out-band ». Malheureusement, parfois il n'est pas possible d'établir cette connexion, alors on passe tout par le flux XML : c'est lent, peu efficace, mais ça fonctionne presque toujours, on parle de connexion « in-band » (qu'on pourrait traduire par « interne »).
Il y a aussi des cas où il est plus simple et efficace de rester « in-band », enfin surtout un : si on envoie très peu de données, comme une petite image (un avatar par exemple).

Comme souvent dans le monde XMPP, plusieurs solutions ont été proposées, expérimentées, parfois adoptées puis dépréciées, jusqu'à ce qu'on trouve et garde celle qui semble convenir le mieux, et qui est a priori la meilleure techniquement.
Commençons par la solution courante, appelée « Stream Initiation » (initiation de flux), elle est définie par la XEP-0095, et la copie de fichier l'utilise via la XEP-0096.

La copie de fichiers est la seule application qui utilise la XEP-0095. Nous avons 2 personnes en jeu : celle qui veut envoyer le fichier, qu'on appellera « l'expéditeur » (« sender » en anglais) et celui qui veut le recevoir, qu'on appellera « le destinataire » (« receiver » en anglais).

La XEP-0096 défini ce qu'on appelle un « profil » pour l'initiation de flux, le profil « transfert de fichier ». Elle sert principalement à transmettre les métadonnées du fichier : une description, sa taille, son nom, sa date de dernière modification, et un « hash », c'est à dire une somme de contrôle pour vérifier que le fichier a été correctement copié. C'est l'algorithme MD5 qui est utilisé ici, pourtant connu pour avoir des failles, même si elles ne sont pas dramatiques dans le cadre d'un transfert de fichier (l'expéditeur étant déjà validé par ailleurs).

Il est également possible d'indiquer une fourchette (« range ») à copier, c'est à dire un point de départ (« offset ») dans le fichier et une longueur (« length »), pratique si un transfert a été interrompu en plein milieu, par une coupure de courant par exemple.

Le reste, c'est la XEP-0095 qui s'en occupe, il s'agit juste de négocier la méthode à utiliser, le destinataire accepte ou non le flux, et choisi une des méthodes. Il y a 2 méthodes principales : la première est le transfert en interne (« In-Band Bytestreams », XEP-0047) qui se contente de transcoder les données en base64.

La deuxième (la XEP-0065, « SOCKS5 Bytestreams ») est plus intéressante, elle utilise SOCKS v5 pour établir une connexion externe (« out-band ») et tenter une connexion directe ou via un « proxy » qui est un élément externe relayant les données. L'utilisation d'un proxy est moins efficace qu'une connexion directe bien entendu (les données passent par un 3ᵉ point), mais est parfois nécessaire si une connexion directe est impossible à cause d'un pare-feu ou d'un NAT par exemple. XMPP permet, grâce à disco (la XEP-0030) de savoir automatiquement si votre serveur propose un proxy.
C'est donc la XEP-0065 qui est à l'origine du nom « proxy65 » couramment utilisé.
Petit détail qui a son importance : dans le cas du transfert direct, la connexion se fait du destinataire vers l'expéditeur (qui a ouvert un port pour l'occasion), aussi la connexion peut échouer dans beaucoup de cas (par exemple l'expéditeur est derrière un NAT). Une méthode a été faite pour améliorer la situation, mais elle n'a jamais été standardisée, vous pouvez la trouver ici : http://delta.affinix.com/specs/stream.html.

Voilà pour la méthode actuelle. Elle pose de nombreux problèmes : c'est uniquement l'expéditeur qui doit proposer et le destinataire accepte ou refuse, il n'y a pas de vraie méthode de secours (appelée « fallback » en anglais), c.-à-d. de méthode pour passer de SOCKS5 (ou « s5b ») au transfert « in-band » (ou « ibb »), et il y a souvent des difficultés pour établir une connexion directe comme expliqué au paragraphe précédent. Bref, ça n'est pas satisfaisant. Mais le problème est assez complexe, il n'est pas si simple de faire une connexion directe, c'est à dire pair à pair (ou « peer to peer » en anglais).

Heureusement, une nouvelle méthode est apparue, et elle est beaucoup plus souple et efficace : Jingle. Mais cet article étant déjà long, j'en parlerai la prochaine fois.

J'en profite pour annoncer que je vais commencer une série d'articles pour expliquer l'architecture et ce qu'on peut faire concrètement avec « Salut à Toi ».

Je vous rappelle aussi que nous avons une campagne de financement participatif en cours pour porter « Salut à Toi » sur Android et faire une version de bureau, et que nous avons bien besoin de soutien ! http://www.arizuka.com/fr/projects/libervia
Merci :)

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Articles similaires

Goffi : SàT: Comment ça marche ?

Salut à vous,

En parallèle de la série d'articles sur XMPP, j'en commence une pour expliquer « Salut à Toi », notre logiciel à tout faire basé sur ce protocole. Il y a beaucoup de choses qui tournent autour de ce logiciel, sur son organisation technique, sa philosophie, et ce qu'on peut faire avec. Aussi je vais faire des articles plus ou moins techniques (plutôt moins), et je vais bientôt expliquer quelques cas concrets d'utilisation.


Ce premier article est un peu technique, puisque je vais expliquer l'organisation générale du logiciel, et ce qu'elle a de particulier.

Donc pour vous donner une idée, SàT c'est dans les grandes lignes ça:

http://ftp.goffi.org/media/pictures/schemas/sat_simplified_overview.png

C'est un client XMPP. Si vous avez lu mes articles, vous savez que XMPP ne signifie pas que « messagerie instantanée », mais beaucoup, beaucoup plus de choses. Le projet SàT essaye non seulement de faire le maximum de ces choses, mais aussi d'expérimenter de nouvelles.

La partie centrale  est la partie « d'arrière-plan » ou « backend » en anglais. C'est elle qui gère le plus gros du logiciel. La partie à droite  sont les « frontaux » (« frontends » en anglais) ou encore les interfaces homme/machine. C'est elles qui gèrent tout l'affichage des informations, ou la réception des commandes et autres messages.

Ce qui fait la force de cette architecture, c'est qu'il est très facile de faire un nouveau frontal, et que le tout représente un seul client. Autrement dit : si vous créez un profil (voir plus bas) sur un frontal, il sera disponible sur tous les autres, si vous envoyez un message d'un côté, il sera visible sur tous les frontaux connectés, l'historique est commun, les fonctionnalités aussi.
En effet, quand on ajoute une fonctionnalité (les messages de groupe par exemple, la copie de fichier, les blogs), c'est dans le « backend » que nous le faisons, et elle se retrouve ainsi disponible partout. Évidemment dans certains cas ça demande du développement particulier pour les interfaces : nous avons un jeu de Tarot par exemple, et on ne dessine pas les cartes de la même manière dans l'interface console (appelée Primitivus) et dans l'interface web (appelée Libervia).

Les interfaces (ou frontaux) disponibles aujourd'hui sont:
 
  • Libervia : interface web 
  • Primivus : interface de console (avec des fenêtres de type ncurses
  • jp: ligne de commande, permet d'automatiser des tâches facilement, d'envoyer un fichier dans parcourir des menus, d'écrire depuis Vim, etc 


Nous avions une autre interface pour le bureau, appelée « Wix », mais nous l'avons abandonnée, car elle était peu pratique et peu utilisée. Notre campagne de financement en cours permettra de remplacer cette interface et par la même occasion de porter le projet sur Android.

Cette architecture a un autre avantage : il est facile d'intégrer SàT dans des logiciels existants, et avec n'importe quel langage de programmation, mais laissons cela de côté pour le moment.

SàT a également une architecture modulaire via l'utilisation de greffons (ou « plugins » en anglais) au niveau du  sur le schéma : le cœur ne gère que l'essentiel (messages simples, liste de contacts, système de logs, gestion des profils, etc), et toutes les fonctionnalités avancées sont disponibles sous forme de greffons (messages de groupe, blog/microblogs, syntaxes avancées, etc). L'idée est d'une part de pouvoir désactiver les fonctionnalités qu'on ne veut pas, et d'autres part de permettre d'étendre facilement le logiciel : un greffon sera d'autant plus intéressant qu'il sera disponible pour toutes les interfaces. Ainsi un de nos greffons gère les marque-pages (c.-à-d. une liste de salons de discussions) : ils sont utilisables à la fois avec Primitivus (en texte), avec Libervia (graphiquement via le web) ou encore avec jp (en ligne de commande). À terme nous comptons faire un système de téléchargement automatisé de greffons, un peu comme les dépôts de logiciels.

Nous avons besoin de travailler un peu côté serveur, pour notre composant PubSub ou notre annuaire par exemple, nous avons donc aussi quelques travaux de ce côté.

 Enfin les profils dont je parlais plus haut sont des comptes locaux associés à un compte XMPP. Ainsi j'ai un profil pour mon compte sur le serveur jabber.fr et un autre pour celui sur libervia.org, je peux utiliser l'un ou l'autre ou les 2 en même temps.
 
Voilà pour une première introduction, un peu technique parce que je voulais expliquer l'originalité de l'architecture. La prochaine fois je pense parler un plus spécifiquement de Libervia, et du système de blogs/microblogs décentralisé.

N'oubliez pas que nous avons une campagne de financement en cours, et nous avons grand besoin de soutien ! Merci.
 

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : centralisé, décentralisé, P2P, mais c'est quoi tout ça ?

Une petite mise au point technique, parce que je vois qu'il y a beaucoup de confusion sur les termes « centralisé » (encore lui ça va), « décentralisé », « distribué », « fédéré », « pair à pair », etc.

Il faut dire que la confusion est assez normale, il n'y a pas vraiment de définition de ces termes, et ce que les gens entendent en les employant dépend de leurs lectures, leur compréhension, et leur sensibilité.

Commençons par le plus simple : centralisé. Un système centralisé c'est un système où tout le monde dépend d'une même autorité, un serveur a priori dans le cas informatique. Bien qu'un système centralisé soit beaucoup plus simple à faire sur le plan technique (facile de trouver des gens ou des informations quand ils sont tous au même endroit), il peut avoir ses propres problèmes : montée en charge en particulier ; il est plus difficile d'absorber des données quand il n'y a qu'un centre de traitement, les tuyaux peuvent rapidement se trouver trop petits, etc.

Un système de communication centralisé pose de nombreux problèmes : il est évident qu'il est plus facile d'espionner, censurer ou modifier des données quand elles sont dépendantes d'un seul point. Même sans intention malicieuse, on a un point unique de défaillance (ce que les anglophones appellent « single point of failure »), c.-à-d. qu'une panne, une attaque, une catastrophe naturelle ou pas provoque l'arrêt du service voire la perte des archives.
Dans les cas les plus gros, on prend un hangar et on le remplit d'ordinateurs, ce sont les fameux centres de données ou « data centers ».

Là où ça se complique un peu, c'est qu'un système centralisé peut être physiquement en plusieurs endroits, ou utiliser des systèmes de répartition/répétition des données. Le principe est d'éviter l'engorgement ou les risques de pannes cités plus haut, mais même si ces machines sont séparées et communiquent entre elles à distance, elles sont a priori toujours sous la même autorité.


http://repos.goffi.org/sat_docs/raw-file/tip/schemas/decentralisation/centralised_simple.png


Passons maintenant aux systèmes décentralisés/distribués/fédérés. Certains vont pousser les haut-cris que je mette tout ça ensemble, parce qu'il n'y pas vraiment de définition et que chacun se fait plus ou moins la sienne.

« dé-centralisé » veut dire qui n'a pas de centre, ni plus ni moins. L'idée pour un système de communication, c'est que toute entité (individu, association, organisation, etc) puisse être une partie d'un réseau qui n'a pas d'autorité principale, et que ces autorités puissent parler entre elles.

On essaye ainsi d'éviter les problèmes de la centralisation, mais on se retrouve avec tout un tas de nouveaux problèmes, techniques pour la plupart : il est beaucoup plus difficile de retrouver des données ou des gens en plusieurs endroits, de se mettre d'accord sur la « langue » à utiliser pour communiquer (surtout quand on a des logiciels ou des versions d'un même logiciel différents), ou encore d'être sûr que la donnée qu'on a est à jour (est-ce que le message a été modifié ou supprimé ?).

« fédéré » est généralement employé pour parler de systèmes différents (noms de domaines différents par exemple, voire logiciels différents) qui peuvent communiquer entre eux. Un système décentralisé est fédéré par nature, sinon on a affaire à plusieurs systèmes centralisés indépendants. Disons que si on veut être pointilleux, on peut dire qu'un système décentralisé peut communiquer avec seulement certaines entités (je communique avec les serveurs de mon entreprise internationale, mais pas avec le reste du monde), et que la fédération implique l'idée que c'est ouvert à tous (ou presque, il y a souvent des gens qu'on ne veut pas, les spammeurs par exemple).

« distribué » ne devrait pas être employé pour les systèmes de communication. Le terme est normalement utilisé pour le calcul : si votre ordinateur a plusieurs processeurs, il distribue la charge de calcul entre eux, ou dans le cas de très grosses demandes (recherche par exemple), on peut demander à plusieurs machines distantes de faire chacun une partie d'une grosse opération mathématique. Dans ce cas, l'organisation de la répartition est souvent contrôlé par une même autorité (par exemple le laboratoire qui veut faire cette opération).
Par extension, le terme est aussi utilisé pour les systèmes de fichiers, et certains l'emploient pour les logiciels de communication, mais cela ne veut pas dire autre chose que décentralisé.


http://repos.goffi.org/sat_docs/raw-file/tip/schemas/decentralisation/decentralised_simple.png


Enfin, il y a le terme P2P ou « pair à pair » (« peer to peer » en anglais). En fait une connexion pair à pair n'est rien d'autre qu'une connexion directe entre 2 ordinateurs, mais on l'associe souvent aux technologies plus ou moins apparentées qui ont commencé à apparaître à la fin des années 90/au début des années 2000 et qui servaient (et servent toujours) principalement à partager des fichiers.

Après Napster (lancé mi 1999) qui était un bête système centralisé qui mettait en relation des machines pour une connexion directe, il y a eu beaucoup d'essais et d'évolutions pour trouver un système qui permet de se passer de serveurs, l'idée étant principalement de permettre au réseau de fonctionner même si on lui coupe l'accès à une partie de lui-même.

Je vous passe toutes les techniques qui sont utilisées : c'est un domaine très pointu, très intéressant, et qui demanderait facilement un livre pour être expliqué. Ça part des systèmes de répartition par propagation de proche en proche à la Usenet, jusqu'aux récentes chaînes de blocs (blockchain), en passant par les tables de hachage distribuée (Distributed Hash Table), etc.

Ce qui fait principalement la différence entre un système « décentralisé » et « entièrement P2P », c'est la place du serveur. Un serveur, dans les grandes lignes, c'est ce qui permet à votre logiciel (le « client ») de contacter d'autres clients via d'autres serveurs. Il est là pour tout un tas de raisons : identifier les gens, donner les bonnes données aux bonnes personnes, garder
les fichiers à donner à un client actuellement hors ligne quand il sera disponible, etc.
Si on supprime le serveur, inévitablement c'est votre client (ou un autre) qui va devoir se charger de ce travail, ce qui aura un impact sur votre bande passante, la charge de travail pour votre processeur (et donc la durée de vie de votre batterie le cas échéant), et compliquera la tâche de votre logiciel (plus difficile de savoir à qui parler et à qui faire confiance quand on n'a pas de serveur comme référence).

http://repos.goffi.org/sat_docs/raw-file/tip/schemas/decentralisation/fully_P2P_simple.png

Pour transformer un système décentralisé avec serveurs en système entièrement P2P (c.-à-d. sans serveur), je vais vous donner une recette : vous mettez un seul client sur votre serveur, et vous mettez le serveur et le client sur la même machine.
Bien sûr si vous voulez être vraiment indépendant, il va falloir supprimer le besoin de points de références, et en particulier le système de noms de domaine ou « Domain Name System ». C'est ce qui associe le nom de votre serveur (par exemple « libervia.org ») à l'adresse « IP » qui permet de vous retrouver sur Internet. Il va falloir aussi être capable de retrouver les données ou les gens un peu partout, et là on se retrouve avec les technologies intéressantes mais complexes évoquées plus haut (« D.H.T. », « Blockchain », « SuperPeer », etc).
 

Et XMPP dans tout ça ?

Je vais quand même parler un peu de XMPP. XMPP est un système dit « hybride », c'est à dire qu'il fonctionne normalement sur un modèle client/serveur, mais il peut faire du P2P à la demande (pour transférer un fichier ou faire de la visioconférence par exemple).
Il est même possible de fonctionner sans serveur sur un réseau local (comme expliqué ici), et il peut parfaitement devenir à terme un système entièrement P2P comme expliqué dans le paragraphe précédent.

Ceci dit, même si l'approche entièrement P2P est séduisante, je pense que l'architecture décentralisée sur un modèle client/serveur est un compromis bien plus efficace : elle limite le travail de votre client, permet une meilleure optimisation du trafic ou du calcul, et facilite l'échange asynchrone (quand deux personnes ne sont pas connectées en même temps). Bref, c'est tout sauf un modèle du passé comme on peut le lire parfois, et bien qu'il y ait plusieurs recherches et options intéressantes pour des systèmes entièrement P2P, il ne faudrait pas jeter le bébé avec l'eau du bain.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Libervia/Salut à Toi à « fêtons Linux » (Lausanne 28/11/2015)

Un rapide billet pour vous dire que nous avons été invités à participer à « fêtons Linux », une journée de rencontre autour des logiciels libres et de Gnu/Linux.

J'y ferai 2 conférences, une technique de 45 min pour expliquer le cœur du projet (à 13h), et une plus grand public de 20 min (à 14h30), et bien sûr je serai présent toute la journée pour discuter (je passerai également par Genève s'il y a du monde qui veut s'y retrouver).

Un grand merci à l'organisation.

Nous avons également passé le premier palier pour notre campagne de financement, c'est à dire que nous sommes engagés à faire un prototype de version de bureau. Mais il nous manque encore un peu moins de 2000 € pour la version Android, et nous avons 2 semaines pour y arriver, aussi faite tourner ce lien partout ou vous pouvez, nous avons besoin d'un coup de pouce pour nous faire connaître : www.arizuka.com/fr/projects/libervia (ou en anglais: www.arizuka.com/en/projects/libervia). Merci !

Je n'ai pas eu le temps d'écrire d'article cette semaine car je suis débordé par le développement : nous espérons sortir la nouvelle version très bientôt.

À bientôt

N.B.: j'ai dû temporairement mettre la modération a priori sur les commentaires, j'ai depuis 2 semaines une vague de spam qui passe les filtres en place.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Libervia (Salut à toi) 0.6.0 : des avancées majeures !

Salut à vous,

Nous avons le plaisir d'annoncer la sortie de Salut à Toi (SàT) 0.6.0 et donc de son interface web « Libervia ». Pour mémoire, SàT est un « couteau suisse de la communication », un outil libre et décentralisé permettant de partager publiquement ou de façon privée des messages, des fichiers, des articles de blog, de microblog, etc.

Le projet a de nombreuses fonctionnalités allant du chiffrement de bout en bout aux jeux, et peut également servir de base pour créer de nouveaux réseaux.
C'est aussi un projet éthique, géré par une association loi 1901, suivant un « contrat social », utilisant exclusivement des logiciels libres, militant pour la décentralisation, et fermement opposé à la publicité.


Cette version a vu un très gros travail sur le système de blogs : Libervia offre un moteur de blog décentralisé, accessible à des groupes restreints ou de l'extérieur, et entièrement basé sur le protocole standard et ouvert « XMPP ». L'utilisation de ce standard permet de communiquer avec d'autres projets comme Movim ou Jappix, créant ainsi un grand réseau libre.

Le partage de fichiers en pair à pair (P2P) a aussi été grandement amélioré grâce au protocole « Jingle », ouvrant la voie pour de futures applications comme la visioconférence.

L'annonce officielle est disponible sur le blog suivant (basé sur Libervia) : https://libervia.org/blog/salut-a-toi.

Une dépêche Linuxfr plus détaillée est en cours de modération et devrait être publiée sous peu.

Une campagne de financement participatif est en cours pour faire une version de bureau (une étape déjà franchie), et une version Android. Cette campagne étant très proche de la fin, c'est le moment de nous soutenir !


 http://ftp.goffi.org/media/screenshots/0.6/overview.png 

 

site officiel : http://salut-a-toi.org
démo : https://libervia.org
campagne de financement : https://www.arizuka.com/fr/projects/libervia
N'hésitez pas à nous contacter (http://salut-a-toi.org/community.html)

L'équipe « Salut à Toi »

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Appel à la communauté: aidez moi à traduire la série « Parlons XMPP »

Salut à vous,

la série que j'ai commencé fin juin, « Parlons XMPP » a plus de succès que ce à quoi je m'attendais (surtout en été !), et a incité plusieurs personnes à regarder un peu plus ce que peut faire ce protocole.

Du coup j'aimerais bien traduire la série en anglais (ou autre !), mais je n'ai vraiment pas le temps de le faire moi même, vu que je dois déjà travailler sur Salut à Toi, et que l'écriture des articles en français me prend beaucoup de temps.

Alors je veux tenter le coup avec une traduction collaborative, un peu comme ce que fait framasoft pour traduire des articles de l'anglais vers le français, mais dans l'autre sens.

Tous les articles sont sous licence libre (Cc By-SA), et il faut bien noter que je parle souvent de « Salut à Toi » sur lequel je travaille, même si je parle aussi d'autres projets.

Bref, je tente le coup, j'ai ouvert un framapad avec le premier article.

Si vous voulez participer ajoutez votre nom ou pseudo pour être dans les auteurs de la traduction, et vous pouvez traduire en dessous du paragraphe en français. Je demanderai une relecture par un anglophone à la fin.

En dehors des 6 articles déjà publiés, je pense continuer au rythme d'un par semaine au moins pendant l'été.

Pour aider à la traduction, c'est par ici: https://bimestriel.framapad.org/p/parlons_XMPP

Merci d'avance !

Goffi

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Conférences des RMLL

Salut à vous,

  j'attendais de voir les vidéos publiées, c'est désormais le cas. Notre passage aux RMLL s'est très bien passé et a été l'occasion de se faire de nouveaux contacts et d'avoir des discussions très intéressantes. J'ai particulièrement apprécié participer à la table ronde sur les nouveaux médias, et rencontrer Arno de SPIP/SeenThis (je connaissais déjà les autres participants).   Je n'ai pas eu l'occasion de voir beaucoup de conférences car j'étais au stand, mais je viens bien sûr vous recommander de voir celles sur XMPP ou en particulier la table ronde sur les nouveaux médias:

Toutes les interventions étaient vraiment intéressantes, y compris dans le public. Merci à ceux qui y ont participé, et à Olicat pour avoir animé.

En ce qui concerne XMPP, il y a bien sur les conférences de Libervia et Movim. Pour Libervia la qualité est vraiment mauvaise, aussi je vous recommande plutôt la version de Pas Sage En Seine, c'est la même conférence:

Libervia

Movim

Et sur un plan plus technique, la conférence « PubSub, Microblogage et XMPP » dont j'ai déjà parlé plusieurs fois:

En dehors de ça comme je l'ai dit je n'ai pas pu voir beaucoup de conférences. J'ai particulièrement aimé celle de Paul Kocialkowski sur Replicant (en anglais, il y en a aussi eu une en français que je n'ai pas pu voir, je ne sais pas si c'est le même ou pas, du coup je mets les 2):

À voir aussi celle de Gelnior (de Newebe/Cozy cloud) sur la conception graphique, je l'avais vue aux JDLL:

Enfin, autre conférence que je n'ai pas (encore) vue, mais comme on en parle dans la table ronde je la mets ici, la conférence « SPIP et sa communauté »:

  Il y en a eu beaucoup d'autres, aussi n'hésitez pas à préciser en commentaires celles que vous conseillez.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Parlons XMPP - épisode 7 - cas pratiques: SleekXMPP et SàT

/* Styles pour Pygments (coloration syntaxique) */ .hll { background-color: #ffffcc } .c { color: #408080; font-style: italic } /* Comment */ .err { border: 1px solid #FF0000 } /* Error */ .k { color: #008000; font-weight: bold } /* Keyword */ .o { color: #666666 } /* Operator */ .cm { color: #408080; font-style: italic } /* Comment.Multiline */ .cp { color: #BC7A00 } /* Comment.Preproc */ .c1 { color: #408080; font-style: italic } /* Comment.Single */ .cs { color: #408080; font-style: italic } /* Comment.Special */ .gd { color: #A00000 } /* Generic.Deleted */ .ge { font-style: italic } /* Generic.Emph */ .gr { color: #FF0000 } /* Generic.Error */ .gh { color: #000080; font-weight: bold } /* Generic.Heading */ .gi { color: #00A000 } /* Generic.Inserted */ .go { color: #888888 } /* Generic.Output */ .gp { color: #000080; font-weight: bold } /* Generic.Prompt */ .gs { font-weight: bold } /* Generic.Strong */ .gu { color: #800080; font-weight: bold } /* Generic.Subheading */ .gt { color: #0044DD } /* Generic.Traceback */ .kc { color: #008000; font-weight: bold } /* Keyword.Constant */ .kd { color: #008000; font-weight: bold } /* Keyword.Declaration */ .kn { color: #008000; font-weight: bold } /* Keyword.Namespace */ .kp { color: #008000 } /* Keyword.Pseudo */ .kr { color: #008000; font-weight: bold } /* Keyword.Reserved */ .kt { color: #B00040 } /* Keyword.Type */ .m { color: #666666 } /* Literal.Number */ .s { color: #BA2121 } /* Literal.String */ .na { color: #7D9029 } /* Name.Attribute */ .nb { color: #008000 } /* Name.Builtin */ .nc { color: #0000FF; font-weight: bold } /* Name.Class */ .no { color: #880000 } /* Name.Constant */ .nd { color: #AA22FF } /* Name.Decorator */ .ni { color: #999999; font-weight: bold } /* Name.Entity */ .ne { color: #D2413A; font-weight: bold } /* Name.Exception */ .nf { color: #0000FF } /* Name.Function */ .nl { color: #A0A000 } /* Name.Label */ .nn { color: #0000FF; font-weight: bold } /* Name.Namespace */ .nt { color: #008000; font-weight: bold } /* Name.Tag */ .nv { color: #19177C } /* Name.Variable */ .ow { color: #AA22FF; font-weight: bold } /* Operator.Word */ .w { color: #bbbbbb } /* Text.Whitespace */ .mb { color: #666666 } /* Literal.Number.Bin */ .mf { color: #666666 } /* Literal.Number.Float */ .mh { color: #666666 } /* Literal.Number.Hex */ .mi { color: #666666 } /* Literal.Number.Integer */ .mo { color: #666666 } /* Literal.Number.Oct */ .sb { color: #BA2121 } /* Literal.String.Backtick */ .sc { color: #BA2121 } /* Literal.String.Char */ .sd { color: #BA2121; font-style: italic } /* Literal.String.Doc */ .s2 { color: #BA2121 } /* Literal.String.Double */ .se { color: #BB6622; font-weight: bold } /* Literal.String.Escape */ .sh { color: #BA2121 } /* Literal.String.Heredoc */ .si { color: #BB6688; font-weight: bold } /* Literal.String.Interpol */ .sx { color: #008000 } /* Literal.String.Other */ .sr { color: #BB6688 } /* Literal.String.Regex */ .s1 { color: #BA2121 } /* Literal.String.Single */ .ss { color: #19177C } /* Literal.String.Symbol */ .bp { color: #008000 } /* Name.Builtin.Pseudo */ .vc { color: #19177C } /* Name.Variable.Class */ .vg { color: #19177C } /* Name.Variable.Global */ .vi { color: #19177C } /* Name.Variable.Instance */ .il { color: #666666 } /* Literal.Number.Integer.Long */

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Comme cela a été demandé plusieurs fois, nous allons pour cet article faire un petit cas pratique avec deux bots XMPP.

SleekXMPP

c'est SleekXMPP que nous allons tester, que je n'avais jamais utilisé avant cet article. Il s'agit d'une bibliothèque Python qui se veut simple, avec peu de dépendances, et gérant tout avec des greffons. Vous pouvez aussi utiliser le fork (amical) fait pour Poezio, Slixmpp qui a réécrit le cœur de la bibliothèque pour tout gérer en asynchrone (sans thread) via le récent asyncio (aussi il faut une version de Python >= à 3.4, alors que SleekXMPP fonctionne avec Python 2 et 3).

Sans entrer trop dans les détails, que vous trouverez sur le site officiel avec plusieurs tutoriels (http://sleekxmpp.com/), faisons un simple bot qui répond à des commandes ad-hoc (aucun lien avec Tintin, voir plutôt l'épisode 6):

Ce script est une adaptation de l'exemple donné dans le dépôt officiel (voir sa licence). Des explications sont données après le script, et il devrait fonctionner avec Python 2.6 ou supérieur ou 3.1 ou supérieur.

#!/usr/bin/env python # -*- coding: utf-8 -*- import sleekxmpp from sleekxmpp import jid JID="mon_super_bot@mon_super_server.tld" PWD="mon_super_mot_de_passe" ADMIN=jid.JID("mon_admin@mon_super_server.tld") CMD_ENVOI = u'envoi message' CMD_DECO = u'déconnexion' CMD_ADMIN = u'gros bouton rouge' class MonSuperBot(sleekxmpp.ClientXMPP): def __init__(self): sleekxmpp.ClientXMPP.__init__(self, JID, PWD) self.add_event_handler("session_start", self.session_start) # note 1 self.register_plugin('xep_0030') self.register_plugin('xep_0004') self.register_plugin('xep_0050') self.register_plugin('xep_0199', {'keepalive': True, 'frequency':15}) def session_start(self, event): # note 2 self.send_presence() self.get_roster() self['xep_0050'].add_command(node='monbot', name=u'Commandes de monbot', handler=self._handle_commands) def _handle_commands(self, iq, session): form = self['xep_0004'].makeForm('form', 'bot') form['instructions'] = u'Choisissez une commande' options = [CMD_ENVOI, CMD_DECO] # note 3 if session['from'].bare == ADMIN: options.append(CMD_ADMIN) form.addField(var='command', label=u'commande', ftype='list-single', required=True, options=options ) session['payload'] = form session['next'] = self._handle_command_complete session['has_next'] = False return session def _handle_command_complete(self, payload, session): form = payload command = form['values']['command'] if command == CMD_ENVOI: self.send_message(mto=session['from'], mbody="Message important !", mtype='headline') elif command == CMD_DECO: self.disconnect(wait=True) # note 4 elif command == CMD_ADMIN: # note 5 if session['from'].bare == ADMIN: session['notes'] = [('warning', 'BOOM !')] else: raise ValueError("ce n'est pas un admin !") return session if __name__ == '__main__': xmpp = MonSuperBot() if xmpp.connect(): # note 6 print(r"\\o/") xmpp.process(block=True) else: print(":(") Explications

Après avoir importé sleekxmpp, nous utilisons quelques constantes (n'oubliez pas bien sûr de remplacer JID et PWD par des valeurs adaptées) pour simplifier, les exemples officiels permettent de manière plus élégante de préciser jid et mot de passe en ligne de commande.

Notre bot se comportera comme un client, nous héritons donc de sleekxmpp.ClientXMPP.

au niveau de la note 1 nous implémentons les greffons qui gèrent les XEPs qui nous intéressent :

  • disco (XEP-0030) pour annoncer ad-hoc, comme expliqué dans l'épisode 3
  • les formulaires de données (x-data, XEP-0004) et les commandes « ad-hoc » (commands, XEP-0050), expliquées dans l'épisode 6
  • la XEP-0199 permet d'envoyer et de répondre à des « pings », afin de s'assurer que la connexion et les logiciels sont toujours actifs.

À la note 2 nous envoyons notre présence et demandons la liste de contacts (« roster »), ce qui est requis par les RFCs, certains serveurs pouvant refuser de répondre si ce n'est pas fait.
Ensuite nous utilisons le greffon des commandes « ad-hoc » pour ajouter le point d'entrée à nos commandes.

Ce point d'entrée appellera la méthode « _handle_commands », et nous utilisons un formulaire (comme expliqué dans la XEP-0004) pour spécifier nos commandes. La liste « options » nous sert à indiquer nos commandes dans l'ordre voulu.

Au niveau de la note 3, nous profitons de l’identification forte de XMPP pour vérifier très simplement si le demandeur utilise l'adresse (jid) de notre compte privilégié, que nous avons indiqué dans la constante « ADMIN ». Nous aurons ainsi un jeu de commandes différent si nous utilisons le compte privilégié ou un autre.
Évidemment si vous voulez profiter de l'authentification forte, il faut vous assurer que tout est en ordre au niveau des certificats et du chiffrement (ce que fait a priori SleekXMPP de base, consultez la documentation pour plus d'informations).

L'ajout de commande se fait ici par une liste à choix unique (« list-single »), mais vous pouvez demander d'autres choses comme des mots de passe ou des jids, tout est expliqué dans la XEP-0004.

Quelques précisions sur ad-hoc : à chaque « page » vous pouvez effectuer une action:

  • cancel pour annuler
  • prev pour revenir en arrière
  • execute pour lancer une commande ou continuer la session
  • next pour passer à la page suivante
  • complete pour finir la sesssion

Ces actions sont gérées par sleekXMPP à travers le dictionnaire « session », la meilleure documentation que j'ai trouvée sur le sujet est le code lui-même : dans le fichier « sleekxmpp/plugins/xep_0050/adhoc.py » présent dans les sources.

Ad-hoc permet également d'indiquer un message, une « note », pour donner l'état de votre commande, elle peut avoir un type « info », « warn » (warning: attention) ou « error » (erreur).

Dans le code nous indiquons que nous avons notre dernière « page » par « session['has_next'] = False », et qu'il faut traiter la réponse dans « _handle_command_complete ». Oui c'est un peu contre-intuitif d’avoir à la fois has_next à False, et un next, mais ce dernier correspond à la réponse et non à une nouvelle page.

Passons à ces réponses. Nous regardons ce qui est dans le formulaire pour savoir quoi faire. Dans le premier cas nous envoyons un message manchette ou « headline » (voir l'épisode 2)

Dans le deuxième cas (au niveau de la note 4) on fait une déconnexion. Alors j'ai eu un problème ici avec SleekXMPP, que j'utilise pour la première fois comme indiqué plus haut : il faudrait pour faire propre terminer la session ad-hoc avant de déconnecter, mais je n'ai pas trouvé de moyen simple de le faire, vu que la déconnexion est immédiate et qu'il faut retourner le dictionnaire session pour terminer la séquence. Peut-être que je suis passé à côté de quelque chose, n'hésitez pas préciser en commentaire si vous avez une astuce.

Passons à la note 5: je refais une vérification du jid avant de lancer la commande privilégiée. La raison est simple: le formulaire est envoyé du client au bot par le serveur sans être vérifié par ce dernier, c'est au bot à le faire. Il est interdit d'ajouter une nouvelle commande, mais comme je doute que SleekXMPP conserve le formulaire d’origine pour vérifier qu'il n'y a rien de nouveau, un attaquant pourrait ajouter la commande privilégiée sans être admin. Cette vérification permet de l'éviter.

Pour faire propre il faudrait envoyer une réponse XMPP précisant que l'action est interdite, mais pour faire simple je me suis contenté d'une exception ici.

Enfin, au niveau de la note 6 on se connecte. Pour un serveur local de test, si vous n'avez pas de serveur DNS configuré comme il faut, vous pouvez spécifier l'adresse ip ou le nom de domaine local en dur, ainsi que le port (par exemple « self.connect(('localhost', 5222)) ». Si votre certificat n'est pas valide, vous pouvez aussi utiliser « use_tls=False » (pour les tests uniquement !). La documentation de SleekXMPP vous indiquera plus clairement comment gérer correctement les certificats.

Enfin, un autre problème que j'ai eu avec SleekXMPP: il ne semble pas possible avec ma version (1.3.1) d'indiquer de ne pas utiliser de commande « exécuter » ou de spécifier son équivalence (ce qui est pourtant possible avec la XEP-0050). Il faudrait qu'elle soit absente ou équivalent à « compléter ». Vous allez ainsi avoir un bouton qui sera inutile, et provoquera même une erreur. Là encore si quelqu'un plus habitué à la bibliothèque peut indiquer en commentaire comment corriger cela. Utilisez donc le bouton « compléter » (ou « finir ») et non « exécuter » de votre client.

Voilà la capture de notre bot piloté par Gajim:

bot piloté par Gajim

Salut à Toi

Pour indiquer les ajouts faits au code, nous utilisons un bot dénommé « Sabot ». Nous gérons les sources avec Mercurial (sur https://repos.goffi.org/). Celui-ci permet d'exécuter une commande via des crochets (« hooks »), dont un qui est lancé à chaque série de commits: incoming. Nous avons donc ceci dans notre hgrc:

[hooks] incoming.sabot = /chemin/vers/hg_sabot_hook.sh

Pour le bot, nous profitons du côté multi-interfaces de SàT: SàT a une architecture qui permet pour un même client (et donc les mêmes profils, comptes, etc) d'avoir différentes interfaces (console, ligne de commande, bureau, web, etc).

Nous avons donc créé le compte comme un compte normal grâce à Primitivus, l'interface console (nous sommes sur un serveur sans interface graphique disponible). On peut joindre le salon désiré (ici sat@chat.jabberfr.org), et le mêttre en favori (grâce à la XEP-0048), ainsi que gérer l'entrée automatique (« autojoin »). Il ne reste plus qu'à envoyer le message quand le script hg_sabot_hook.sh est appelé, ce que nous faisons à l'aide de « jp », l'interface en ligne de commande:

#!/bin/sh #on s'assure d'abord que D-Bus est lancé eval `/chemin/vers/dbus-launch.sh` REPOS_BASE="http://repos.goffi.org/sat" PROJECT_FULL="Salut à Toi" REPOS="$REPOS_BASE/rev/$HG_NODE" MUC="sat@chat.jabberfr.org" hg log -r $HG_NODE --template "Commit from {author|person} on $PROJECT_FULL\\n{desc}\\n$REPOS" | jp message -cp sabot $MUC

(le vrai script est un tout petit peu plus long puisqu'il gère aussi les noms des autres dépôts).

L'option « -c » indique de se connecter si ça n'est pas le cas, et « -p sabot » précise qu'il faut utiliser le profil « sabot »

Le script dbus-launch.sh s'assure juste que D-Bus est bien lancé et réutilisé entre les sessions de l'utilisateur:

#!/bin/sh DBUS_PATH="/tmp/.dbus.`whoami`" if [ ! -e $DBUS_PATH ]; then dbus-launch --sh-syntax > $DBUS_PATH chmod 400 $DBUS_PATH fi cat $DBUS_PATH

Voilà pour ces cas pratiques. La prochaine fois, je parlerai soit de PubSub, soit de Jingle.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Parlons XMPP - épisode 8 - PubSub et PEP

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Aujourd'hui nous allons expliquer dans les grandes lignes comment fonctionnent « PubSub » et « PEP », et voir à quoi cela peut servir. Cet article va reprendre en partie ce que j'ai dit à la conférence « PubSub, microblogage et XMPP » en juillet dernier aux RMLL.

PubSub signifie « Publish/Subscribe » (Publication/Abonnement), c'est un mécanisme qui permet à une ou plusieurs personnes de publier toutes sortes d'informations sur un endroit connu (qu'on appelle un nœud) et aux personnes qui le désirent de s'abonner, c'est à dire d'avoir accès au contenu et d'être averti des modifications, le tout avec un système d'accès simple. Il s'agit du patron de conception « observateur/observable » décentralisé et appliqué à XMPP.

Le fonctionnement est expliqué dans la XEP-0060, c'est une des XEPs les plus longues de XMPP mais le principe est relativement simple à comprendre. Sans reprendre le long glossaire du document, expliquons quelques termes :

  • le service PubSub est l'entité qui gère le mécanisme de publication, d'autorisation, d'abonnement, de notification. C'est une entité XMPP et un jid y est donc associé, c'est à lui que vous faites toutes les requêtes pour un nœud donné.
  • le nœud est un espace associé à une publication. On peut associer ça à l'adresse d'un flux Atom.
  • un « item » (élément) est une publication dans un nœud. On peut associer ça à un article dans un flux Atom.
  • cet « item » contient un « payload » (charge utile), c'est à dire un contenu significatif qui dépend de la fonctionnalité utilisée. En effet la XEP-0060 décrit un mécanisme générique et souple, qui est ensuite utilisé dans des cas pratiques par d'autres extensions.

Un service PubSub est généralement un composant de votre serveur, mais ça peut-être n'importe quelle entité : votre serveur lui-même (c'est le cas avec PEP que nous allons voir ci-dessous), ou un client voire votre client lui-même (mais c'est assez rare – je n'ai jamais vu de client le faire –, car en général on utilise le service de son serveur).

Le mécanisme général est très simple et centré sur les nœuds : chaque entité (associée à un jid) à un rôle lié à ce nœud selon qu'elle l'ait créé, qu'elle soit publieur, abonné, banni ou sans lien avec le nœud. À ces rôles sont donnés des autorisations : le droit d'écrire (avec le « publish model » ou modèle de publication) et le droit en lecture (avec l'« access model » ou modèle d'accès).

Reprenons de manière un peu plus formelle. Les rôles dont nous avons parlé sont appelés « affiliations », et on peut avoir les suivantes:

  • owner (propriétaire): en général celui qui a créé le nœud
  • publisher (publieur): celui ou ceux (il peut y en avoir plusieurs) qui ont accès en écriture
  • publish-only (publication seulement): droit d'écriture mais pas de lecture, c'est un cas peu fréquent.
  • member (membre): quelqu'un qui est abonné au nœud
  • none (rien): l'entité n'a pas de lien avec le nœud
  • outcast (banni): l'entité a été explicitement interdite d'accès au nœud

La section 4.1 de la XEP-0060 fourni un tableau qui montre les autorisations selon l'affiliation. Ainsi on voit que le propriétaire peut publier ou configurer un nœud.

Les modèles d'accès (pour la lecture) définis dans la XEP-0060 sont les suivants:

  • open (ouvert, public): tout le monde peut lire le nœud
  • presence (présence – oui je traduis même pour un seul accent –) : si une entité est autorisée à voir la présence du publieur, alors elle peut accéder au nœud
  • roster (liste de contacts): si une entité est dans un groupe défini (dans la configuration du nœud) de la liste de contacts du service pubsub, elle a accès au nœud.
  • whitelist (liste blanche): des entités sont explicitement autorisées dans la configuration du nœud

Et rapidement les modèles de publication:

  • publishers (publieurs): quelqu'un qui a l'affiliation publieur peut écrire
  • subscribers (abonnés): n'importe quel abonné peut écrire
  • open (ouvert/libre): tout le monde peut écrire

Il faut bien noter une chose essentielle dans PubSub : quand la combinaison autorisation/abonnement/configuration le permet, on reçoit une notification immédiatement quand un élément est publié, modifié ou supprimé. Autrement dit on n'est plus du tout dans l'analogie avec un flux Atom – où on doit aller vérifier régulièrement qu'il n'y a rien de nouveau –, on est prévenu si nécessaire. Ceci est beaucoup plus efficace, rapide, et économe en ressources.

Voilà pour la base. La XEP défini d'autres choses qu'il n'est pas forcément pertinent d'expliquer ici, comme les métadonnées ou les inscriptions temporaires. On peut toutefois s'arrêter sur les collections, qui ne sont que mentionnées dans la XEP-0060 mais décrites en détails dans la XEP-0248. Elles permettent de faire des arbres de nœuds, et ainsi de représenter des données avec des relations entre elles. Des exemples valent parfois mieux qu'un long discours: les collections peuvent être utilisées pour représenter un système de fichiers sur un disque dur, ou un arbre généalogique.

Tout ceci est souple, générique, puissant, et relativement facile à utiliser par un client. Mais la XEP étant très longue, et l'implémentation de la partie service plus complexe, les implémentations ont mis du temps à arriver (et encore aujourd'hui elles sont très inégales). Comme PubSub peut être intéressant même sans tout le mécanisme, une version simplifiée est décrite dans la XEP-0163: « Personal Eventing Protocol » (Protocole d'évènements personels).

Cette dernière se base sur PubSub, mais définit les règles suivantes qui simplifient beaucoup :

  • 1 compte (jid) = 1 service : probablement la règle la plus importante, elle évite d'avoir à chercher un service PubSub associé à un jid, puisque le service est l'adresse canonique (« bare jid ») de l'entité. Ainsi pour la microblogage (XEP-0277), il suffit de connaître le jid de la personne – le nœud étant défini dans la XEP – pour retrouver ses publications.

  • 1 publieur par nœud : le propriétaire et le publieur sont le même, et il n'y a qu'un publieur par nœud. On se coupe ainsi de l'édition collaborative par souci de simplification, et il faudra utiliser PubSub pour ce genre d'applications.

  • accès par présence par défaut : sans rien toucher, il suffit d'avoir quelqu'un dans sa liste de contacts (et qui a accès à la présence) pour qu'il soit autorisé à voir nos publications

  • notifications filtrées sur l'intérêt exprimé : pour éviter d'être submergé de notifications, une entité/un client doit explicitement indiquer qu'il est intéressé par tel ou tel nœud

  • options par défaut au plus simple

PEP était utilisé au début pour des événements (sans grand intérêt à mon sens) comme l'humeur ou la musique en cours d'écoute, mais depuis son utilisation a évolué.

Voici, pour finir, quelques exemples d'utilisation de PubSub ou PEP:

  • enregistrement de données publiques ou semi-publiques (XEP-0222), par exemple une clef publique de chiffrement
  • enregistrement de données privées (XEP-0223), très utile pour n'importe quelle donnée de petite taille
  • les marque-pages (XEP-0048) utilisés pour les salons de discussions utilisent PEP (la XEP-0048 a été modifiée après l'apparition de PEP pour s'y adapter)
  • le microblogage bien entendu (XEP-0277), qui utilise PEP et utilise du Atom pour sa « charge utile » (« payload ») et un accès en général public. Les commentaires sont sur un nœud PubSub séparé, en général avec un modèle de publication par abonnement.
  • la XEP-0214 utilise PubSub et les collections pour faire un dépôt de fichiers
  • le futur protocole de discussions de groupe « MUC 2 » devrait se baser sur PubSub

PubSub pourrait aussi être utilisé pour placer des points sur une carte, faire un wiki, organiser des événements, ou encore gérer et surveiller une batterie de serveurs qui nous préviendraient en cas de problème.

Je reviendrai sûrement plus tard sur tout ça pour expliquer le microblogage ou d'autres extensions.

La prochaine fois, je pense vous parler de Jingle (mais pas de la partie vidéo-conférence). J'espère qu'à ce stade vous commencez à comprendre que XMPP n'est pas une technologie, mais un ensemble de technologies coordonnées et qui se réutilisent les unes les autres quand nécessaire.

J'ai un peu réduit le rythme des articles ces derniers temps car je travaille sur mon projet, et qu'une partie a été traduite en anglais avec l'aide de pas mal de monde (merci encore !), tout cela prend du temps.

Si vous venez à la fête de l'huma ce week-end, vous pourrez me trouver au village du libre, où Parinux me prête gentiment un bout de stand (merci aussi !). Je n'y serai pas en permanence, car je compte aussi profiter un peu de la fête :)

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Vous voulez du (micro)blogage, de la décentralisation et du chiffrement sur Android ?

Salut à vous !

 Aujourd'hui nous lançons une petite campagne de financement participatif pour le développement d'une version Android de Libervia/Salut à Toi. Nous souhaitons ici développer une application native, avec toutes les fonctionnalités avancées dont nous disposons déjà, telles que le (micro)blogage, le chiffrement de bout en bout via OTR (et il est possible que nous ajoutions OMEMO/Axolotl, une nouvelle méthode permettant de chiffrer les messages hors ligne ou dans une discussion de groupe), le partage de fichiers, ou des choses plus exotiques comme une télécommande universelle. Ce développement fonctionnera également sur bureau (Gnu/Linux bien sûr, mais il devrait fonctionner sur d'autres plateformes comme Windows ou Mac OS X) avec la même interface. Il existe déjà quelques clients Android (comme le très joli Movim de notre ami Edhelas, Conversations ou Xabber), mais aucun n'offre actuellement le même bouquet de fonctionnalités que Libervia/Salut à Toi, aussi ce développement sera un vrai plus. D'autre part nous sommes particulièrement attentifs à l'éthique (cf notre contrat social) et nous sommes organsiés en association loi 1901 en autogestion, dans l'idée de faire une coopérative sur le long terme. Cette campagne est aussi l'occasion de tester un moyen de financement, et nous avons choisi Arizuka car ce site se concentre sur les projets de l'économie sociale et solidaire. Voilà, donc maintenant on compte sur vous ! N'hésitez pas à poser vos question soit en commentaire, soit par courriel (goffi@goffi.org) soit sur notre salon de discussion XMPP: sat@chat.jabberfr.org lien vers la campagne: http://www.arizuka.com/fr/projects/liberviaSalut à Toi: http://salut-a-toi.org 
P.-S. : nous préparons aussi une (grosse) nouvelle version dans les semaines à venir, je ferai certainement une série d'articles pour expliquer les nouveautés et comment se servir de Libervia ou SàT en général.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Parlons XMPP - épisode 9 - copie de fichiers et Jingle

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Bien que déjà répété un certain nombre de fois, je le redis : XMPP fait bien plus que de la messagerie instantanée. Une des fonctionnalités qui est apparue rapidement est la copie de fichiers, voyons cela de plus près

Le problème : XMPP étant du XML, il n'est pas vraiment adapté aux données purement binaires comme des fichiers. La solution est de passer par l'extérieur, c'est à dire une autre connexion non XML, et d'utiliser le flux XML pour la gérer, on parle de connexion « out-band ». Malheureusement, parfois il n'est pas possible d'établir cette connexion, alors on passe tout par le flux XML : c'est lent, peu efficace, mais ça fonctionne presque toujours, on parle de connexion « in-band » (qu'on pourrait traduire par « interne »).
Il y a aussi des cas où il est plus simple et efficace de rester « in-band », enfin surtout un : si on envoie très peu de données, comme une petite image (un avatar par exemple).

Comme souvent dans le monde XMPP, plusieurs solutions ont été proposées, expérimentées, parfois adoptées puis dépréciées, jusqu'à ce qu'on trouve et garde celle qui semble convenir le mieux, et qui est a priori la meilleure techniquement.
Commençons par la solution courante, appelée « Stream Initiation » (initiation de flux), elle est définie par la XEP-0095, et la copie de fichier l'utilise via la XEP-0096.

La copie de fichiers est la seule application qui utilise la XEP-0095. Nous avons 2 personnes en jeu : celle qui veut envoyer le fichier, qu'on appellera « l'expéditeur » (« sender » en anglais) et celui qui veut le recevoir, qu'on appellera « le destinataire » (« receiver » en anglais).

La XEP-0096 défini ce qu'on appelle un « profil » pour l'initiation de flux, le profil « transfert de fichier ». Elle sert principalement à transmettre les métadonnées du fichier : une description, sa taille, son nom, sa date de dernière modification, et un « hash », c'est à dire une somme de contrôle pour vérifier que le fichier a été correctement copié. C'est l'algorithme MD5 qui est utilisé ici, pourtant connu pour avoir des failles, même si elles ne sont pas dramatiques dans le cadre d'un transfert de fichier (l'expéditeur étant déjà validé par ailleurs).

Il est également possible d'indiquer une fourchette (« range ») à copier, c'est à dire un point de départ (« offset ») dans le fichier et une longueur (« length »), pratique si un transfert a été interrompu en plein milieu, par une coupure de courant par exemple.

Le reste, c'est la XEP-0095 qui s'en occupe, il s'agit juste de négocier la méthode à utiliser, le destinataire accepte ou non le flux, et choisi une des méthodes. Il y a 2 méthodes principales : la première est le transfert en interne (« In-Band Bytestreams », XEP-0047) qui se contente de transcoder les données en base64.

La deuxième (la XEP-0065, « SOCKS5 Bytestreams ») est plus intéressante, elle utilise SOCKS v5 pour établir une connexion externe (« out-band ») et tenter une connexion directe ou via un « proxy » qui est un élément externe relayant les données. L'utilisation d'un proxy est moins efficace qu'une connexion directe bien entendu (les données passent par un 3ᵉ point), mais est parfois nécessaire si une connexion directe est impossible à cause d'un pare-feu ou d'un NAT par exemple. XMPP permet, grâce à disco (la XEP-0030) de savoir automatiquement si votre serveur propose un proxy.
C'est donc la XEP-0065 qui est à l'origine du nom « proxy65 » couramment utilisé.
Petit détail qui a son importance : dans le cas du transfert direct, la connexion se fait du destinataire vers l'expéditeur (qui a ouvert un port pour l'occasion), aussi la connexion peut échouer dans beaucoup de cas (par exemple l'expéditeur est derrière un NAT). Une méthode a été faite pour améliorer la situation, mais elle n'a jamais été standardisée, vous pouvez la trouver ici : http://delta.affinix.com/specs/stream.html.

Voilà pour la méthode actuelle. Elle pose de nombreux problèmes : c'est uniquement l'expéditeur qui doit proposer et le destinataire accepte ou refuse, il n'y a pas de vraie méthode de secours (appelée « fallback » en anglais), c.-à-d. de méthode pour passer de SOCKS5 (ou « s5b ») au transfert « in-band » (ou « ibb »), et il y a souvent des difficultés pour établir une connexion directe comme expliqué au paragraphe précédent. Bref, ça n'est pas satisfaisant. Mais le problème est assez complexe, il n'est pas si simple de faire une connexion directe, c'est à dire pair à pair (ou « peer to peer » en anglais).

Heureusement, une nouvelle méthode est apparue, et elle est beaucoup plus souple et efficace : Jingle. Mais cet article étant déjà long, j'en parlerai la prochaine fois.

J'en profite pour annoncer que je vais commencer une série d'articles pour expliquer l'architecture et ce qu'on peut faire concrètement avec « Salut à Toi ».

Je vous rappelle aussi que nous avons une campagne de financement participatif en cours pour porter « Salut à Toi » sur Android et faire une version de bureau, et que nous avons bien besoin de soutien ! http://www.arizuka.com/fr/projects/libervia
Merci :)

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Articles similaires

Goffi : SàT: Comment ça marche ?

Salut à vous,

En parallèle de la série d'articles sur XMPP, j'en commence une pour expliquer « Salut à Toi », notre logiciel à tout faire basé sur ce protocole. Il y a beaucoup de choses qui tournent autour de ce logiciel, sur son organisation technique, sa philosophie, et ce qu'on peut faire avec. Aussi je vais faire des articles plus ou moins techniques (plutôt moins), et je vais bientôt expliquer quelques cas concrets d'utilisation.


Ce premier article est un peu technique, puisque je vais expliquer l'organisation générale du logiciel, et ce qu'elle a de particulier.

Donc pour vous donner une idée, SàT c'est dans les grandes lignes ça:

http://ftp.goffi.org/media/pictures/schemas/sat_simplified_overview.png

C'est un client XMPP. Si vous avez lu mes articles, vous savez que XMPP ne signifie pas que « messagerie instantanée », mais beaucoup, beaucoup plus de choses. Le projet SàT essaye non seulement de faire le maximum de ces choses, mais aussi d'expérimenter de nouvelles.

La partie centrale  est la partie « d'arrière-plan » ou « backend » en anglais. C'est elle qui gère le plus gros du logiciel. La partie à droite  sont les « frontaux » (« frontends » en anglais) ou encore les interfaces homme/machine. C'est elles qui gèrent tout l'affichage des informations, ou la réception des commandes et autres messages.

Ce qui fait la force de cette architecture, c'est qu'il est très facile de faire un nouveau frontal, et que le tout représente un seul client. Autrement dit : si vous créez un profil (voir plus bas) sur un frontal, il sera disponible sur tous les autres, si vous envoyez un message d'un côté, il sera visible sur tous les frontaux connectés, l'historique est commun, les fonctionnalités aussi.
En effet, quand on ajoute une fonctionnalité (les messages de groupe par exemple, la copie de fichier, les blogs), c'est dans le « backend » que nous le faisons, et elle se retrouve ainsi disponible partout. Évidemment dans certains cas ça demande du développement particulier pour les interfaces : nous avons un jeu de Tarot par exemple, et on ne dessine pas les cartes de la même manière dans l'interface console (appelée Primitivus) et dans l'interface web (appelée Libervia).

Les interfaces (ou frontaux) disponibles aujourd'hui sont:
 
  • Libervia : interface web 
  • Primivus : interface de console (avec des fenêtres de type ncurses
  • jp: ligne de commande, permet d'automatiser des tâches facilement, d'envoyer un fichier dans parcourir des menus, d'écrire depuis Vim, etc 


Nous avions une autre interface pour le bureau, appelée « Wix », mais nous l'avons abandonnée, car elle était peu pratique et peu utilisée. Notre campagne de financement en cours permettra de remplacer cette interface et par la même occasion de porter le projet sur Android.

Cette architecture a un autre avantage : il est facile d'intégrer SàT dans des logiciels existants, et avec n'importe quel langage de programmation, mais laissons cela de côté pour le moment.

SàT a également une architecture modulaire via l'utilisation de greffons (ou « plugins » en anglais) au niveau du  sur le schéma : le cœur ne gère que l'essentiel (messages simples, liste de contacts, système de logs, gestion des profils, etc), et toutes les fonctionnalités avancées sont disponibles sous forme de greffons (messages de groupe, blog/microblogs, syntaxes avancées, etc). L'idée est d'une part de pouvoir désactiver les fonctionnalités qu'on ne veut pas, et d'autres part de permettre d'étendre facilement le logiciel : un greffon sera d'autant plus intéressant qu'il sera disponible pour toutes les interfaces. Ainsi un de nos greffons gère les marque-pages (c.-à-d. une liste de salons de discussions) : ils sont utilisables à la fois avec Primitivus (en texte), avec Libervia (graphiquement via le web) ou encore avec jp (en ligne de commande). À terme nous comptons faire un système de téléchargement automatisé de greffons, un peu comme les dépôts de logiciels.

Nous avons besoin de travailler un peu côté serveur, pour notre composant PubSub ou notre annuaire par exemple, nous avons donc aussi quelques travaux de ce côté.

 Enfin les profils dont je parlais plus haut sont des comptes locaux associés à un compte XMPP. Ainsi j'ai un profil pour mon compte sur le serveur jabber.fr et un autre pour celui sur libervia.org, je peux utiliser l'un ou l'autre ou les 2 en même temps.
 
Voilà pour une première introduction, un peu technique parce que je voulais expliquer l'originalité de l'architecture. La prochaine fois je pense parler un plus spécifiquement de Libervia, et du système de blogs/microblogs décentralisé.

N'oubliez pas que nous avons une campagne de financement en cours, et nous avons grand besoin de soutien ! Merci.
 

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : centralisé, décentralisé, P2P, mais c'est quoi tout ça ?

Une petite mise au point technique, parce que je vois qu'il y a beaucoup de confusion sur les termes « centralisé » (encore lui ça va), « décentralisé », « distribué », « fédéré », « pair à pair », etc.

Il faut dire que la confusion est assez normale, il n'y a pas vraiment de définition de ces termes, et ce que les gens entendent en les employant dépend de leurs lectures, leur compréhension, et leur sensibilité.

Commençons par le plus simple : centralisé. Un système centralisé c'est un système où tout le monde dépend d'une même autorité, un serveur a priori dans le cas informatique. Bien qu'un système centralisé soit beaucoup plus simple à faire sur le plan technique (facile de trouver des gens ou des informations quand ils sont tous au même endroit), il peut avoir ses propres problèmes : montée en charge en particulier ; il est plus difficile d'absorber des données quand il n'y a qu'un centre de traitement, les tuyaux peuvent rapidement se trouver trop petits, etc.

Un système de communication centralisé pose de nombreux problèmes : il est évident qu'il est plus facile d'espionner, censurer ou modifier des données quand elles sont dépendantes d'un seul point. Même sans intention malicieuse, on a un point unique de défaillance (ce que les anglophones appellent « single point of failure »), c.-à-d. qu'une panne, une attaque, une catastrophe naturelle ou pas provoque l'arrêt du service voire la perte des archives.
Dans les cas les plus gros, on prend un hangar et on le remplit d'ordinateurs, ce sont les fameux centres de données ou « data centers ».

Là où ça se complique un peu, c'est qu'un système centralisé peut être physiquement en plusieurs endroits, ou utiliser des systèmes de répartition/répétition des données. Le principe est d'éviter l'engorgement ou les risques de pannes cités plus haut, mais même si ces machines sont séparées et communiquent entre elles à distance, elles sont a priori toujours sous la même autorité.


http://repos.goffi.org/sat_docs/raw-file/tip/schemas/decentralisation/centralised_simple.png


Passons maintenant aux systèmes décentralisés/distribués/fédérés. Certains vont pousser les haut-cris que je mette tout ça ensemble, parce qu'il n'y pas vraiment de définition et que chacun se fait plus ou moins la sienne.

« dé-centralisé » veut dire qui n'a pas de centre, ni plus ni moins. L'idée pour un système de communication, c'est que toute entité (individu, association, organisation, etc) puisse être une partie d'un réseau qui n'a pas d'autorité principale, et que ces autorités puissent parler entre elles.

On essaye ainsi d'éviter les problèmes de la centralisation, mais on se retrouve avec tout un tas de nouveaux problèmes, techniques pour la plupart : il est beaucoup plus difficile de retrouver des données ou des gens en plusieurs endroits, de se mettre d'accord sur la « langue » à utiliser pour communiquer (surtout quand on a des logiciels ou des versions d'un même logiciel différents), ou encore d'être sûr que la donnée qu'on a est à jour (est-ce que le message a été modifié ou supprimé ?).

« fédéré » est généralement employé pour parler de systèmes différents (noms de domaines différents par exemple, voire logiciels différents) qui peuvent communiquer entre eux. Un système décentralisé est fédéré par nature, sinon on a affaire à plusieurs systèmes centralisés indépendants. Disons que si on veut être pointilleux, on peut dire qu'un système décentralisé peut communiquer avec seulement certaines entités (je communique avec les serveurs de mon entreprise internationale, mais pas avec le reste du monde), et que la fédération implique l'idée que c'est ouvert à tous (ou presque, il y a souvent des gens qu'on ne veut pas, les spammeurs par exemple).

« distribué » ne devrait pas être employé pour les systèmes de communication. Le terme est normalement utilisé pour le calcul : si votre ordinateur a plusieurs processeurs, il distribue la charge de calcul entre eux, ou dans le cas de très grosses demandes (recherche par exemple), on peut demander à plusieurs machines distantes de faire chacun une partie d'une grosse opération mathématique. Dans ce cas, l'organisation de la répartition est souvent contrôlé par une même autorité (par exemple le laboratoire qui veut faire cette opération).
Par extension, le terme est aussi utilisé pour les systèmes de fichiers, et certains l'emploient pour les logiciels de communication, mais cela ne veut pas dire autre chose que décentralisé.


http://repos.goffi.org/sat_docs/raw-file/tip/schemas/decentralisation/decentralised_simple.png


Enfin, il y a le terme P2P ou « pair à pair » (« peer to peer » en anglais). En fait une connexion pair à pair n'est rien d'autre qu'une connexion directe entre 2 ordinateurs, mais on l'associe souvent aux technologies plus ou moins apparentées qui ont commencé à apparaître à la fin des années 90/au début des années 2000 et qui servaient (et servent toujours) principalement à partager des fichiers.

Après Napster (lancé mi 1999) qui était un bête système centralisé qui mettait en relation des machines pour une connexion directe, il y a eu beaucoup d'essais et d'évolutions pour trouver un système qui permet de se passer de serveurs, l'idée étant principalement de permettre au réseau de fonctionner même si on lui coupe l'accès à une partie de lui-même.

Je vous passe toutes les techniques qui sont utilisées : c'est un domaine très pointu, très intéressant, et qui demanderait facilement un livre pour être expliqué. Ça part des systèmes de répartition par propagation de proche en proche à la Usenet, jusqu'aux récentes chaînes de blocs (blockchain), en passant par les tables de hachage distribuée (Distributed Hash Table), etc.

Ce qui fait principalement la différence entre un système « décentralisé » et « entièrement P2P », c'est la place du serveur. Un serveur, dans les grandes lignes, c'est ce qui permet à votre logiciel (le « client ») de contacter d'autres clients via d'autres serveurs. Il est là pour tout un tas de raisons : identifier les gens, donner les bonnes données aux bonnes personnes, garder
les fichiers à donner à un client actuellement hors ligne quand il sera disponible, etc.
Si on supprime le serveur, inévitablement c'est votre client (ou un autre) qui va devoir se charger de ce travail, ce qui aura un impact sur votre bande passante, la charge de travail pour votre processeur (et donc la durée de vie de votre batterie le cas échéant), et compliquera la tâche de votre logiciel (plus difficile de savoir à qui parler et à qui faire confiance quand on n'a pas de serveur comme référence).

http://repos.goffi.org/sat_docs/raw-file/tip/schemas/decentralisation/fully_P2P_simple.png

Pour transformer un système décentralisé avec serveurs en système entièrement P2P (c.-à-d. sans serveur), je vais vous donner une recette : vous mettez un seul client sur votre serveur, et vous mettez le serveur et le client sur la même machine.
Bien sûr si vous voulez être vraiment indépendant, il va falloir supprimer le besoin de points de références, et en particulier le système de noms de domaine ou « Domain Name System ». C'est ce qui associe le nom de votre serveur (par exemple « libervia.org ») à l'adresse « IP » qui permet de vous retrouver sur Internet. Il va falloir aussi être capable de retrouver les données ou les gens un peu partout, et là on se retrouve avec les technologies intéressantes mais complexes évoquées plus haut (« D.H.T. », « Blockchain », « SuperPeer », etc).
 

Et XMPP dans tout ça ?

Je vais quand même parler un peu de XMPP. XMPP est un système dit « hybride », c'est à dire qu'il fonctionne normalement sur un modèle client/serveur, mais il peut faire du P2P à la demande (pour transférer un fichier ou faire de la visioconférence par exemple).
Il est même possible de fonctionner sans serveur sur un réseau local (comme expliqué ici), et il peut parfaitement devenir à terme un système entièrement P2P comme expliqué dans le paragraphe précédent.

Ceci dit, même si l'approche entièrement P2P est séduisante, je pense que l'architecture décentralisée sur un modèle client/serveur est un compromis bien plus efficace : elle limite le travail de votre client, permet une meilleure optimisation du trafic ou du calcul, et facilite l'échange asynchrone (quand deux personnes ne sont pas connectées en même temps). Bref, c'est tout sauf un modèle du passé comme on peut le lire parfois, et bien qu'il y ait plusieurs recherches et options intéressantes pour des systèmes entièrement P2P, il ne faudrait pas jeter le bébé avec l'eau du bain.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Libervia/Salut à Toi à « fêtons Linux » (Lausanne 28/11/2015)

Un rapide billet pour vous dire que nous avons été invités à participer à « fêtons Linux », une journée de rencontre autour des logiciels libres et de Gnu/Linux.

J'y ferai 2 conférences, une technique de 45 min pour expliquer le cœur du projet (à 13h), et une plus grand public de 20 min (à 14h30), et bien sûr je serai présent toute la journée pour discuter (je passerai également par Genève s'il y a du monde qui veut s'y retrouver).

Un grand merci à l'organisation.

Nous avons également passé le premier palier pour notre campagne de financement, c'est à dire que nous sommes engagés à faire un prototype de version de bureau. Mais il nous manque encore un peu moins de 2000 € pour la version Android, et nous avons 2 semaines pour y arriver, aussi faite tourner ce lien partout ou vous pouvez, nous avons besoin d'un coup de pouce pour nous faire connaître : www.arizuka.com/fr/projects/libervia (ou en anglais: www.arizuka.com/en/projects/libervia). Merci !

Je n'ai pas eu le temps d'écrire d'article cette semaine car je suis débordé par le développement : nous espérons sortir la nouvelle version très bientôt.

À bientôt

N.B.: j'ai dû temporairement mettre la modération a priori sur les commentaires, j'ai depuis 2 semaines une vague de spam qui passe les filtres en place.

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

Goffi : Libervia (Salut à toi) 0.6.0 : des avancées majeures !

Salut à vous,

Nous avons le plaisir d'annoncer la sortie de Salut à Toi (SàT) 0.6.0 et donc de son interface web « Libervia ». Pour mémoire, SàT est un « couteau suisse de la communication », un outil libre et décentralisé permettant de partager publiquement ou de façon privée des messages, des fichiers, des articles de blog, de microblog, etc.

Le projet a de nombreuses fonctionnalités allant du chiffrement de bout en bout aux jeux, et peut également servir de base pour créer de nouveaux réseaux.
C'est aussi un projet éthique, géré par une association loi 1901, suivant un « contrat social », utilisant exclusivement des logiciels libres, militant pour la décentralisation, et fermement opposé à la publicité.


Cette version a vu un très gros travail sur le système de blogs : Libervia offre un moteur de blog décentralisé, accessible à des groupes restreints ou de l'extérieur, et entièrement basé sur le protocole standard et ouvert « XMPP ». L'utilisation de ce standard permet de communiquer avec d'autres projets comme Movim ou Jappix, créant ainsi un grand réseau libre.

Le partage de fichiers en pair à pair (P2P) a aussi été grandement amélioré grâce au protocole « Jingle », ouvrant la voie pour de futures applications comme la visioconférence.

L'annonce officielle est disponible sur le blog suivant (basé sur Libervia) : https://libervia.org/blog/salut-a-toi.

Une dépêche Linuxfr plus détaillée est en cours de modération et devrait être publiée sous peu.

Une campagne de financement participatif est en cours pour faire une version de bureau (une étape déjà franchie), et une version Android. Cette campagne étant très proche de la fin, c'est le moment de nous soutenir !


 http://ftp.goffi.org/media/screenshots/0.6/overview.png 

 

site officiel : http://salut-a-toi.org
démo : https://libervia.org
campagne de financement : https://www.arizuka.com/fr/projects/libervia
N'hésitez pas à nous contacter (http://salut-a-toi.org/community.html)

L'équipe « Salut à Toi »

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.

genma : Printemps de l'Entreprise : "Data Day" mardi 15 mars !

Le mardi 15 mars 2016, c'est Printemps de l'Entreprise : "Data Day" à l'IUT de Vannes en Bretagne. Le programme complet de la journée est en ligne ProgrammePrintemps2016_V1_NB.pdf

Lors de cette journée, je serai sur place et j'interviendrais pour trois animations :
Conférence de 8h45 à 10h00. Il y aura une première conférence - Vie privée et big data Données personnelles : comment le marketing utilise (ou non) vos données ? par Alexandre Léchenet d'alphoenix.net. Suivi de la mienne à savoir Big Data : comment s'en sortir ?

Suivrons ensuite deux "ateliers" que j'animerai :
-Vie privée et Big Data : Degooglisons Internet par Framasoft de 10h15 à 11h15
-Présentation de Firefox OS de 14h à 15h : l'actualité et l'avenir.

Mes supports de présentation seront prochainement en ligne.

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

RaspbianFrance : Bien choisir les accessoires à acheter pour la Raspberry Pi 3

Comme pour chaque nouveau modèle de la Raspberry Pi, nous vous proposons un article dédié au choix crucial, mais compliqué, de l’achat des accessoires de la Raspberry Pi.

Aujourd’hui nous allons donc aborder le cas de la Raspberry Pi 3, dernière née de la famille Raspberry et fière remplaçante de la Raspberry Pi 2.

 

La Raspberry Pi 3, une nouvelle Raspberry Pi avec le Wi-Fi !

Avant de passer à la liste des accessoires de la Raspberry Pi, arrêtons nous pour quelques lignes sur la Raspberry Pi 3 elle même et sur ses différences avec sa parente.

De toutes les différences, la plus importante est probablement l’ajout de la Wi-Fi et du Bluetooth, maintenant directement intégrés à la Raspberry Pi !

Par ailleurs, la Raspberry Pi 3 amène également un nouveau processeur avec une architecture 64 bits qui devrait encore améliorer les performances de notre framboise préférée.

Enfin, l’alimentation des ports USB est améliorer et devrait maintenant permettre d’alimenter tous les disques durs externe, résolvant ainsi un problème qui commençait à vraiment trop durer !

Et bonne nouvelle, le prix, lui, ne devrait pas bouger et rester à 35 € !

Devant vos yeux ébahis, voici donc un résumé des différences entre la Raspberry Pi 2 et la Raspberry Pi 3 !

Raspberry Pi 240€40€
  • Processeur : 32-bit quad-core ARM Cortex-A7
  • Cadance : 1000MHz
  • RAM : 1024Mo
  • Wi-Fi : Non
  • Bluetooth : Non
  • Alimentation : 5v 2A
  • Stockage : Carte MicroSD
  • Carte réseau : Carte réseau Ethernet
  • Ports USB : 4
  • USB 2.5A : Non
Acheter le modèle 2Raspberry Pi 345€45€
  • Processeur : 64-bit quad-core ARM Cortex-A53
  • Cadance : 1200MHz
  • RAM : 1024Mo
  • Wi-Fi : Oui
  • Bluetooth : Oui, 4.1
  • Alimentation : 5v 2.5A
  • Stockage : Carte MicroSD
  • Carte réseau : Carte réseau Ethernet
  • Ports USB : 4
  • USB 2.5A : Oui
Acheter le modèle 3

 

Les accessoires obligatoires de la Raspberry Pi 3

Pour une lecture plus simple, nous allons diviser les accessoires à acheter pour votre Raspberry Pi 3 en trois catégories (obligatoires, utiles et optionnels).

Nous allons donc commencer par nous pencher sur les accessoires obligatoires, c’est à dire ceux sans lesquels vous ne pourrez pas faire fonctionner votre Raspberry Pi !

 

Une alimentation adaptée à la Raspberry Pi 3

Comme nous l’avons dit plus tôt, la Raspberry Pi 3 améliore l’alimentation des ports USB. Cela se traduit notamment par un changement des besoins en terme d’alimentation électrique de la Raspberry.

Ainsi, la Raspberry Pi nécessite l’emploi d’une alimentation différente de la Raspberry Pi 2. Cette alimentation devra pouvoir fournir, au minimum, 5 volts et 2.5 ampères.

Nous vous conseillons donc de vous tourner vers cette alimentation qui fonctionne très bien et correspond parfaitement aux spécifications de la Raspberry Pi 3.

 

Bien choisir la carte MicroSD de votre Raspberry Pi

Comme vous le savez peut-être, la Raspberry Pi ne dispose pas de disque dur. En effet, celui-ci est remplacé par une carte MicroSD qui contiendra non seulement vos données, mais également le système d’exploitation lui même.

Cela signifie donc que cette carte sera sujette à de très nombreuse lecture/écritures qui influencerons directement les performances de la Raspberry Pi. Nous vous conseillons donc de choisir une carte de très bonne qualité et avec de bon débits en lecture/écriture.

De plus, bonne carte SD ne coûte pas beaucoup plus cher, vous assure une meilleure durabilité et pourra être utilisée pour d’autres usages que la Raspberry Pi.

L’autre question concerne bien-sur la taille de la carte SD. Nous vous proposons une règle simple pour faire votre choix :

  • Pas de stockage de données, 8 Go
  • Par défaut, 16 Go
  • Stockage de nombreux documents, 32 Go
  • Utilisation multimédia avec stockage, 64 Go

 

De façon générale, nous vous conseillons donc l’achat de cette excellente carte de SanDisk d’une capacité de 16 Go (adaptez la taille selon la règle ci-dessus).

 

Les accessoires très utiles

Si les accessoires suivant ne sont pas essentiel au fonctionnement de la Raspberry Pi, il sont néanmoins très utiles et peuvent considérablement améliorer votre expérience d’utilisation.

 

Un boîtier pour protéger la Raspberry Pi 3

Par défaut, la Raspberry Pi se présente comme une simple carte mère. Si cela est très pratique quand il s’agit de l’intégrer dans un montage, cela l’expose hélas terriblement à l’environnement et aux regards.

Que ce soit pour protéger la Raspberry Pi des risques divers (tordre un composant, décharge électrostatique, etc.) ou simplement pour des considérations plus esthétiques (notamment si elle doit être intégrée dans la maison, le salon, etc.), nous ne pouvons que vous encourager à utiliser un boîtier pour protéger votre Raspberry Pi 3 (notez que les boîtiers pour Raspberry Pi 2 sont compatibles avec la Raspberry Pi 3).

Il existe de très nombreux boîtiers, mais il préférable de choisir un boîtier qui vous permette d’accéder facilement aux différents ports (notamment GPIO) de la Raspberry Pi, et qui assure la bonne ventilation de celle-ci.

Nous vous recommandons donc ce boîtier de one nine design, assez élégant et compatible avec la Raspberry Pi 3.

Le boitier one nine design pour la Raspberry Pi 3

 

 

Un clavier sans fil avec sa souris

Si vous pouvez prendre le contrôle de votre Raspberry Pi à distance (notamment avec SSH), il y néanmoins certains cas où vous pourriez avoir besoin d’un clavier et d’une souris.

Si vous ne possédez pas de clavier/souris fonctionnant en USB, vous pourriez êtres amenés à devoir vous en procurer.

Attention alors à bien choisir des périphériques compatibles avec Linux.

Nous conseillons l’utilisation d’un clavier faisant à la fois clavier et souris, le tout sans fil.

De notre coté, nous utilisons et vous recommandons ce clavier qui marche très bien avec Linux.

 

Un écran (pourquoi pas tactile) et des câbles

Dernier point, vous aurez probablement besoin d’un écran pour votre Raspberry Pi 3.

Si vous souhaitez utiliser un écran tactile, (pour faire un contrôleur domotique ou de media-center par exemple), le plus simple est probablement de regarder du coté de l’écran officiel de la Raspberry Pi.

Écran tactile officiel Raspberry Pi Foundation

L’écran officiel de la Raspberry Pi Foundation peut être fixé à la Raspberry Pi à l’aide de vis !

 

Si vous n’avez pas besoin d’un écran tactile, choisissez si possible un écran HDMI.

Si vous possédez déjà un écran mais qu’il ne possède pas de port HDMI, pas de panique.

S’il possède un port VGA, vous pouvez passez par un convertisseur. De même, s’il possède des connecteurs RCA (les câbles rouges, jaunes et blancs) vidéos, vous aurez besoin d’un câble jack audio/vidéo.

 

Les accessoires utiles pour certaines utilisations

Derniers type d’accessoires, ceux qui se révèlent très utiles, mais seulement dans certains cas d’utilisation.

 

La caméra de la Raspberry Pi

Premier accessoire très utile, la caméra officiel de la Raspberry Pi.

Il s’agit d’une minuscule webcam proposant une résolution de FullHD, très utile pour monter des système de vidéo surveillance, mais également pour de la robotique.

Notez qu’il existe une version infrarouge de la caméra qui vous permettra de filmer dans la nuit !

 

Un disque dur externe USB

Dernier accessoire que nous verrons, les disques durs externes.

Le fait que la Raspberry Pi utilise une carte MicroSD est très pratique pour ce qui concerne l’encombrement, mais cela a hélas tendance à limiter la quantité de données que vous pourrez stocker.

Si généralement ce n’est pas gênant, ça peut le devenir dans le cadre de systèmes qui nécessite de stocker de grosses quantités de données, par exemple media-center qui doit stocker des dizaines voir centaines de films en HD, ou encore serveur hébergeant des nombreux documents, etc.

Pour pallier ce problème, le plus simple est d’utiliser un disque dur externe qui contiendra les données, tandis que la carte SD contiendra seulement le système.

Bonne nouvelle, la Raspberry Pi 3 peut maintenant alimenter un disque dur en USB, ce qui n’était pas le cas de la Raspberry Pi 2. Cela est d’autant plus appréciable qu’il deviens plus facile de trouver des disques dur aux alentours de 50€ pour 1 To de stockage.

 

Et maintenant ?

Maintenant que vous savez quels accessoires choisir pour votre Raspberry Pi, il ne vous reste plus qu’à découvrir comment installer Raspbian ou comment monter votre propre media-center !

Cet article Bien choisir les accessoires à acheter pour la Raspberry Pi 3 est apparu en premier sur Raspbian-France.

Gravatar de RaspbianFrance
Original post of RaspbianFrance.Votez pour ce billet sur Planet Libre.

Articles similaires

Mathias : Lancement du forum de support pour FreeSwitch

Afin de combler un manque, j’ai décidé de lancer un forum de support dédié à la communauté francophone de FreeSwitch. En effet, je reçois pas mal de demandes d’aide par email, et je trouve dommage de ne pas faire profiter la communauté des réponses.

FreeSwitch est un outil fantastique permettant de créer des applications VoIP et vidéo (mais pas seulement) complexes et performantes. J’ai créé plusieurs sections (d’autres sections peuvent être envisagées) : actualités, installation, configuration, programmation et matériels. L’objectif est de créer une communauté d’entre-aide.

Si vous souhaitez devenir modérateur, envoyez moi un message privé.

L’adresse : forum FreeSwitch France

Autres articles à lire:

Cet article Lancement du forum de support pour FreeSwitch est apparu en premier sur Blog des télécoms - Par Mathias, expert et formateur rédigé par Mathias.

Gravatar de Mathias
Original post of Mathias.Votez pour ce billet sur Planet Libre.

Pages