It would be better to have a common protocol in order to have collaboration features between vim, emacs, gedit and more. The existing collaboration features in vim cannot interoperate with GNU Emacs, and the existing collaboration features in GNU Emacs cannot interoperate with vim. The AbiWord’s plugin Collab protocol has good ideas to avoid and resolve conflicts as explained in a GNOME Journal article (and more good ideas will come with the abicollab.net service). But the Collab’s protocol is tied to Abiword internal structures. Aseigo discussed the issue and want a generic library for collaborative features.

A common protocol would be useful for editing source code with my contacts (I want to use Telepathy tubes!) but also when one user want to use both vim and emacs on the same buffer. D-Bus is now the way to go for applications to communicate with one another, and D-Bus tubes are available in Telepathy.

The editors landscape use very different languages: Emacs Lisp for GNU Emacs, the Vim script language for vim (although Python can be used, see this presentation from PyCon), C and Python for gedit. Whatever the way we choose to resolve conflicts that happens in real-time editing, it seems complex: it took some years to the Abiword team to build the Collab plugin. I would prefer to avoid writing complex things in all theses differents editors and languages.

So I am thinking of an architecture with an intermediary component that make the difficult job of handling conflicts. Let’s call it text-remote-control now but I am looking for a better name.

Then, editors would have to implement a basic D-Bus specification. I don’t know yet if it is possible to isolate the complexity from the editor, but I would like to explore this possibility.

So I started to hack on gedit:

• gedit’s remote control plugin: file (on git)
• text-remote-control: script (on git)

And I have built this screencast:

I have also a plugin for vim (on git) that fires a D-Bus signal each time the buffer is changed. The problem here is that vim use its own mainloop and I don’t know how to integrate the GLib mainloop used by the python-dbus. So my vim plugin cannot receives method calls yet.

I don’t know how to use GNU Emacs but I hope someone will take the opportunity to show that writing plugins in emacs is easier!

• Gshrooms : Music rooms in Gaim (now Pidgin) with Rhythmbox,
• Playlists sharing with DAAP in Rhythmbox.

Vincent has also written a Rhythmbox plugin (proposed for inclusion) to update the status in IM clients (Empathy or Gossip).

What can Telepathy do for music sharing? There is a limitation in the DAAP Rhythmbox’ plugin: you can share your music with people on your local network or if you know the IP address of your contact. However, users don’t know what is an IP address and it may not be reacheable if the contact is behind a NAT.

A better interface should just be to select the contact in the contact list and the DAAP protocol is routed to the remote contact through a Telepathy stream tube. This feature request has now a proof-of-concept implementation and you can enjoy the screencasts:

• Export the music to your contact
• The music got imported

However, the current implementation is not usable: it uses In-Band Bytestreams (IBB, XEP-0047). This means that all your Ogg Vorbis files go through the Jabber server in XML, encoded in base64. Even if it was not too slow, it would abuse the public Jabber servers.

Let’s hope Telepathy will support real P2P stream tubes soon!

More graphs

The command line was:

debtree -r --condense --no-conflicts --no-recommends --no-alternatives --no-provides empathy > empathy.dot
dot -Tpng -o empathy.png empathy.dot

With this configuration: ~/.debtree/skiplist ~/.debtree/endlist

This can be achieved with Mscgen (patched to draw D-Bus signals) and some scripts. Mscgen is a simple tool to generate diagrams from a simple text file with a simple syntax. Text files can be put in a SCM.

I wrote a python script that listens on the bus and writes the .msc file.

Example with Quod Libet:

Example with Telepathy:

The python script has a DBusMessagesBox object. I can filter D-Bus connection I don’t want to draw. In this example, I don’t print messages from or to the script itself. I can filter message from or to the dbus-daemon.

The script choose the right name (”salut” instead of “:1.15″). Some programs requests several connection names on the session bus. In this case, you can choose the prefered name with the ‘prefered_names’ option.

   #skip_entities = set(“DBusMessagesBox”, “DBus”)    skip_entities = set(“DBusMessagesBox”)    options = { ’skip_entities’ : skip_entities, \                ‘prefered_names’ : ‘gabble’, ’salut’, ‘ChatFilter’ }

   box = DBusMessagesBox(options)    box.start_recording()    try:        gtk.main()    except:        print

   box.stop_recording()

   box.parse("/tmp/file.msc")    os.system("mscgen -T png -i /tmp/file.msc -o /tmp/file.png")

Mais GTetrinet est aussi un jeu de hasard. Le jeu choisit aléatoirement les pièces et les bonus-malus. Et le hasard se manipule, surtout sur un jeu avec une architecture client-serveur où les lancés de dés se font sur le client. Certains n’hésitent pas à écrire un patch pour pouvoir choisir eux-mêmes leurs bonus-malus au lieu de faire confiance au destin (j’ai hésité à mettre le lien vers le patch en question, mais finalement je ne le mets pas!).

Pour se protéger contre cela, on pourrait choisir aléatoirement les pièces et les bonus-malus sur le serveur. Car à priori, on fait plus confiance au serveur qu’aux clients, non? Dans le cas de Gtetrinet, cela impose de changer le protocole client-serveur, et donc de briser la compatibilité avec les autres clients existants sous Windows.

Et si on n’a pas confiance au serveur non plus, on fait quoi? Y a-t-il une solution si les deux clients communiquent directement entre eux sans passer par un tiers de confiance? C’est le même problème que jouer à pile ou face par téléphone. Il existe des solutions en utilisant un peu de cryptographie. Bruce Schneier reprend dans Cryptographie Appliquée (ISBN-10: 2841800369) une petite histoire de Uses of Randomness in Algorithms and Protocols de Joe Killian (ISBN-10: 0262111535):

Alice: Premièrement, tu penses à un bit aléatoire, ensuite je pense à un bit aléatoire. Ensuite, on prend le ou exclusif des deux bits.

Bernard: Mais que se passe-t-il si l’un de nous ne choisit pas aléatoirement?

Alice: Peu importe. Aussi longtemps que l’un des deux bits est vraiment aléatoire, le ou exclusif des deux bits doit être aléatoire.

Bernard: Ok, je parie sur 1. Mon bit aléatoire est 1. Et le tien?

Alice: Mon bit aléatoire est aussi 1. Le ou exclusif fait donc 0. Tu as perdu.

Ce protocole ne marche pas car Alice peut changer son bit si le choix de Bernard ne lui convient pas. Il faut modifier légèrement ce protocole pour mettre en gage un bit aléatoire en utilisant une fonction de hachage.

Il y a 9 bonus-malus différents dans GTetrinet. Pour choisir son prochain bonus-malus, Alice va effectuer les opérations suivantes:

1. Alice choisit deux nombres aléatoires quelconques R1 et R2.
2. Alice choisit son bloc B1 entre 0 et 8 aléatoirement.
3. Alice envoie HASH(R1, R2, B1) et R1 à Bernard
4. Bernard envoie un numéro de bloc B2 entre 0 et 8 aléatoirement.
5. Alice envoie en clair R1, R2, B1 à Bernard
6. Les deux joueurs calculent le bloc B obtenu par Alice: B = B1 + B2 modulo 9.

J’ai implémenté ce protocole en Ruby avec D-Bus: random_client.rb (pour Alice) et random_server.rb (pour Bernard). Les deux programmes doivent s’exécuter sur le même ordinateur sur la même session D-Bus pour communiquer, mais avec les tubes D-Bus de Telepathy, ça devrait pouvoir s’arranger.

This user interface lets you choose the contact to play with and the game settings in the same window. Once chosen, you cannot add additional players. I propose an alternative user interface: you first choose the game settings in the connection window, and then you add your contacts in the party from the main window. You can see the screencast!

And maybe I will have some time to clean up the GTetrinet patch I used to create the screencast.

Christine Albanel demande à Chronopost International de lutter plus activement contre le piratage

vendredi 12 octobre 2007

Christine Albanel, ministre de la Culture et de la Communication, s’est entretenue jeudi 11 octobre 2007 avec le directeur général du leader français de courrier express Chronopost International, filiale de GeoPost (groupe La Poste). La Ministre a rappelé son attachement inconditionnel au respect des droits d’auteurs et de l’intégrité des oeuvres, et son engagement dans la lutte contre le piratage. A ce titre, elle a manifesté sa réticence face aux nouvelles caractéristiques du service d’envoi de colis de Chronopost International, Chrono 8.

Depuis quelques jours, une évolution du service d’envoi de courriers Chrono 10 permet de transporter des colis beaucoup plus volumineux (pouvant contenir jusqu’à 50 DVD), tout en réduisant la durée du transport d’un colis pour être livré le matin à huit heure (Chrono au lieu de dix heure. La Ministre a fait remarquer que, même si tel n’est pas l’objet du service conçu par Chronopost International, il permet aux clients du groupe d’envoyer anonymement et massivement des contenus pirates sur Chrono 8.

Christine Albanel a demandé au directeur du groupe que la maîtrise technique incontestée de Chronopost International soit mise à profit pour faire respecter la loi, et a demandé la restriction effective de l’accès à ce service à des communautés fermées, voire sa suppression pure et simple.

La Ministre a rappelé la décision de justice qui a contraint Chronopost International à supprimer le transport de courriers contenant manifestement des contenus douteux, vecteurs de piratage massif, et a exprimé son soutien aux associations de défense des droits d’auteurs qui ont manifesté leur désapprobation.

Si les mesures élémentaires de protection ne sont pas prises alors ces services sont des instruments mis gracieusement à la disposition des pirates payant un abonnement Chrono 8. La Ministre considère que l’engagement tangible de Chronopost International dans la lutte contre le piratage est un prérequis essentiel à l’examen de leur dossier d’attribution du marché public d’échange de courriers rapides entre les ministères.

J’ai fait quelques modifications au communiqué d’origine, dont:

• Free -> Chronopost International
• dl.free.fr -> Chrono 8
• licence de téléphonie 3G -> marché public d’échange de courriers rapides entre les ministères

J’ai ajouté du gras sur deux parties importantes, mais le texte en gras n’a pas été modifié. Ainsi, la ministre demande à Free la restriction de ce service à des communautés fermées, voire sa suppression pure et simple. Pour faire passer sa demande, une petite phrase qui ressemble fort à du chantage sur l’attribution de la licence de téléphonie 3G.

Sur le fond, j’ai déjà utilisé il y a quelques mois le service dl.free.fr pour envoyer des données privées (photos de vacances et autres documents). Ca évite de trop charger les boites à lettres électroniques. Il est possible de protéger les données par un mot de passe. Et c’est vrai que c’était lent. Si c’est plus rapide, tant mieux!

Actuellement, chaque joueur voulant jouer ensemble doit se connecter à un même serveur de jeu. Les connexions se font selon le modèle client-serveur:

Si les joueurs discutent déjà entre eux en utilisant la messagerie instantanée, il serait plus simple de lancer la partie en sélectionnant ses adversaires directement depuis le logiciel de messagerie instantanée. Ou alors de voir la liste de ses contacts dans Gtetrinet et les sélectionner directement sans passer par l’étape du choix du serveur.

Les tubes de Telepathy permettent de faire communiquer arbitrairement n’importe quelle application (Gtetrinet, par exemple) par la messagerie instantanée. Le schéma suivant montre les connexions après que le joueur 1 ait proposé au joueur 2 une partie. Le joueur 1 a sélectionné directement depuis Gtetrinet le joueur 2. Gtetrinet 1 propose alors un tube au joueur 2. Gtetrinet 2 l’accepte et se connecte à Gtetrinet 1.

Il est possible d’implémenter les tubes sur différents protocoles de messagerie instantanée. Avec Jabber, le message envoyé par le joueur 1 au joueur 2 ressemble à celui-là:

<message from="player1@localhost/Telepathy" id="540813737502" to="player2@localhost" >   <tube xmlns="http://telepathy.freedesktop.org/xmpp/tubes"         service="tetrinet-x"         type="stream"         id="1506758346" >     <parameters>       <parameter type="str" name="login" >foobar</parameter>     </parameters>   </tube>   <amp xmlns="http://jabber.org/protocol/amp">     <rule action="error" value="stored" condition="deliver-at" />     <rule action="error" value="exact" condition="match-resource" />   </amp> </message>

Tubes over XMPP

Le nom du service (”tetrinet-x”) permet de connaître l’application qui va gérer ce message lorsqu’il arrivera sur l’ordinateur du joueur 2. La bonne application pourrait être lancé automatiquement (après acceptation de l’utilisateur).

Pour éviter de faire trop de modifications dans Gtetrinet, le plus simple est d’utiliser les stream tubes au lieu des D-Bus tubes: cela évite de refaire le protocole de communication de Gtetrinet en D-Bus. Les stream tubes permettent d’encapsuler une socket dans un tube. Cela est rendu possible récemment par le travail de Cassidy.

Pour faire un prototype rapide, Cassidy a écrit un patch qui évite de changer de protocole: on conserve le serveur qui tourne sur l’ordinateur du joueur qui initie la connexion. Lorsque le joueur 1 sélectionne le joueur avec qui il veut jouer dans sa liste des contacts, Gtetrinet lance le serveur et configure le tube pour rediriger la connexion du joueur 2 sur le serveur. Ainsi, aucune modification du serveur n’est nécessaire.

Actuellement, la configuration du tube marche, mais le Gtetrinet du joueur 2 n’est pas encore capable de l’accepter. Ca devrait bientôt arriver!

1. Les logiciels de bureautique lourds comme OpenOffice.org, KOffice ou GNOME-Office. Beaucoup de fonctionnalités mais très difficile de synchroniser les documents par email.
2. Les wikis. Plus facile à synchroniser puisqu’il n’y a qu’une seule version: celle du serveur. Mais on perd beaucoup en fonctionnalités.
3. Google Docs. Il tente d’assembler les avantages des logiciels de bureautique lourds et des wiki. La vidéo montre très bien les avantages. Ca supporte le OpenDocument, et il y a pas mal de fonctionnalités, même si ça reste du web. Mais c’est centralisé chez Google et ce n’est pas du Logiciel Libre.
4. Imaginons une autre solution avec seulement les avantages!

Regardez du côté d’AbiCollab. C’est un plugin pour Abiword permettant d’éditer à plusieurs un document en temps réel, à l’aide de Jabber. J’ai fait une démo d’AbiCollab pour Toulibre:

Pour résumer, il faut configurer son compte Jabber dans Abiword (plus tard, Abiword devrait pouvoir utiliser Telepathy pour réutiliser la connexion Jabber du bureau et ne plus demander à l’utilisateur les détails inintéressants comme le login et mot de passe). Puis cliquer sur “Partager le document” dans le menu “Collaborer”. Ensuite, vos contacts peuvent voir votre document en cliquant sur “Documents disponibles”, toujours dans le menu “Collaborer”. C’est tout! Vous voyez votre curseur mais aussi celui de vos contacts, et vous voyez leurs modifications aussi rapidement que le permet votre réseau.

Cela pose bien quelques problèmes techniques mais AbiCollab explique comment ils sont résolus (enfin, c’est encore très instable).

Ce que je voudrais pour la suite, c’est que d’autres logiciels de bureautique utilisent la messagerie instantanée pour permettre l’édition collaborative. Il faut aussi qu’ils utilisent Telepathy et les tubes pour éviter à l’utilisateur de configurer sa messagerie instantanée dans chaque logiciel, pour partager la connexion au serveur de messagerie instantanée, et pour pouvoir utiliser plusieurs messageries instantanées différentes (Jabber pour Internet, Bonjour pour le réseau local). Il faudrait aussi standardiser le protocole de synchronisation pour que plusieurs logiciels utilisant OpenDocument puissent collaborer ensemble. Enfin, il faudrait que cela marche même quand l’initiateur du document coupe sa connexion Internet en utilisant la XEP-0049 XEP-0223 par exemple.

Oui, ça fait beaucoup de travail. Mais on a le droit de rêver, non?