Mot-clé - jabber-xmpp-en

Fil des billets

vendredi 4 décembre 2015

Libervia (Salut à Toi) 0.6.0 : decentralized blog and more

We are pleased to announce the 0.6.0 of Libervia (Salut à Toi).

Salut à Toi is a “Swiss Army knife” of communication : a multipurpose, multi frontend, free (as in freedom) and decentralised communication tool, and Libervia is it's web frontend.

With it you can publish publicly or to a private group, do end-to-end encryption for instant messaging, share files, play games, etc.

For this release there has been a lot of work on blogging/microblogging, and we can now enjoy a decentralized blogging system, with template engine, tags, etc. Being based on XMPP, we can communicate with projects like Movim or Jappix

P2P file sharing has also been improved with the implementation of the Jingle protocol.

A lot of others feature have been worked on, like a Docker image, HTTP upload, visual improvements, etc.

You can see the release announce on, a blog hosted on a Libervia instance.

We are in the last day of our crowdfunding campain, so if you want to help us to port the project on desktop and Android, it is *really* the time !

official website:
crowdfunding: last day !
Feel free to contact us:

The “Salut à Toi” team

lundi 26 octobre 2015

Want a decentralized, encrypted, Free (as in freedom) “social” app on Android and desktop ?
We have just launched a crowdfunding campaign to develop a new frontend to Libervia, and port it to Android (in a native application!). (subtitles available in many languages).
If the campaign is successful, we'll have a unique tool. Here are only a few features managed by Libervia:
  • blogging/microblogging: we have a decentralized blogging engine based on XMPP, no need to create an account/validate an email to post a comment
  • instant messaging, single or multi-user, with a lot of features
  • end to end encryption: we already manage OTR for single chat, there is a good probability that we also implement OMEMO/Axolotl
  • file sharing: being file uploading or P2P transfer
  • group permissions: similarly to what others call “circle” or “aspect”, you can share with only your friends or your family
  • a lot more, check (and don't miss the experimental ones)
In addition we are a non-profit association focusing on ethic, we want to make a good tool, not a place for advertisements!
So if you are looking for next-gen communication tool, please support us and share the link:
Thanks !

mercredi 26 août 2015

Let's talk XMPP - episode 4 - group conversations

This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there:

The translation to English was done thanks to: Poulet , Éfrit , Paco , mbarbarosa , Weyfonk and Chteufleur . The whole series is under CC By-SA , and any help would be appreciated to help with the translation of next articles.
(Follow the corresponding link to read the previous episodes).

In the software development field, and much in the libre software, group’s discussions are really common, mostly with IRC (Internet Relay chat).
This venerable protocol do what we ask it and XMPP is strongly inspired by it. Let’s see that closely.

Group’s discussions used nowadays are called MUC (Multi-User Chat) and are defined by XEP-0045. This one standardizes and extends the first solution called Groupchat. As all that comes from IRC, I’ll explain as they come the major differences between them.

It is possible to acces a chat room located on any server from any server (again, while it is not explicitly prohibited). Chat rooms do, as the users, have a jid, which has the pattern chat_room_name@service. For example, that of Salut à Toi is  “sat” is the chat room’s name, “” the service.

The resource is used for occupants of the chat room: corresponds to the occupant “goffi” in the chat room Ah little detail that I forgot in previous articles: everything is unicode in XMPP, including jid. So you can use arabic or russian nickname. But beware: some unicode characters are strongly similar, therefore it is possible to get 2 words graphically similar mixed up, we name it “homoglyphs”. For example “gοffⅰ” looks like “goffi” but it uses different characters. This issue is mentioned in a unicode technical report: Also, do not rely exclusively on a nickname to identify someone (espcially that it is possible that it can be reused by someone else between two sessions).

The nickname is linked to the chat room and not to the service. You can have a nick “toto” in a chat room and “titi” in another one, and someone else can have “titi” on a third chat room. This is a big difference with IRC where we have only one nickname on a server that will be used in every chat room (channel on IRC).

To go in or go out a chat room, or to change nickname, we send an available (or not) presence directly to, but this is normaly managed by your client.

It is also possible to write directly to all chat room’s occupants (under the hood this is a “groupchat” message that is sent to the chat room’s bare jid), or to have a private chat with a member (we write to the full jid of the recipient).

A chat room can be public or hidden (it will not appear in the chat room list), not anonymous or semi-anonymous (in the first case everyone can see the occupant’s real jid, in the second case only moderators and administrators can), persistent or temporary, open or accessible only by white list or can be protected by password, moderated or not.

All those parameters are normally defined at the creation of the chat room, or they can be modified after with the suitable option of your client (on Gajim: right click on chat room tab => Manage Room => Configure Room). According to the service you use, you can configure more or less things, for example limit the occupant’s maximal number.

A feature often implemented is the history or “back log”: when you get in a chat room, the service sends you the last X messages, allowing you to understand the context of the current conversation.

Also, if a public archive of the chat room is kept (we say “logged” chat room), the service must warn you (it’s mandatory in the XEP), this is another good point compared to IRC. For sure, one has to remember that anyone in the room can keep a log and could publish it without your consent.

So far, so good, but a great strength of IRC is its simplicity: no need to create an account, you just have to pick a nick (unique), with a server, and that’s it! So, you won’t be disapointed, XMPP has exactly the same thing with connections called “anonymous”. No anonymity in terms of Tor here, but rather the possibility to get a temporary account, with a jid more or less random, for the connection time. This comes built-in but it must often be explicitly enabled in the server configuration, and most of the time, anonymous connections are limited to the local network, no communication with other servers (to avoid spam).

If you want to chat as with IRC in a simple and intuitive way, and if you like the console, I would strongly recommend Poezio which is an excellent XMPP client that is easy to use: initially, without changing the configuration, you will be anonymously connected to the MUC service of Poezio. It is inspired by Irssi/Weechat and use the same commands (and more generally those of IRC). Below the welcome message, without changing the configuration, we see the anonymous jid assigned for the session time.

Poezio screenshot

Well this episode is long enough, but I am not finished with MUC, therefore we will talk about it next time, probably with transports.

mercredi 5 août 2015

Let's talk XMPP - episode 3 - core and extensions (part 2)

This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there:

The translation to English was done thanks to: Poulet, Éfrit, Paco, mbarbarosa, Weyfonk and Chteufleur. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles.
(Follow the corresponding link to read the previous episodes).
Some functionalities can be added to this central part, hence the X of XMPP (which stands for “eXtensible”).
Extensions are written using “XEP” (XMPP Extension Protocol) , following an idea taken from Python (if I am not mistaken). This is why the features supported by a server or a client are identified as XEP-0XXX. Obviously, no need to know this to use a XMPP client, but it can be useful to read an extension (you can find them at to understand correctly the utility of a functionality. Two parts are particularly useful without the need to enter in the implementation details: the “abstract” part (summary) in the top that indicates what the XEP is doing, and the “introduction” section (the very first section) that provides further details about the cause of the extension and its use cases.
XEP-0045 abstract
An XEP can describe a feature, a process (for instance the XEP-0001 explains the life cycle of the XEPs themselves), a historical legacy (related to something created before the XMPP Standard Foundation), information (like good practices), even a joke (yes, there are also lousy jokes in the XEPs!). It can have several statuses, detailed in the XEP-0001. It is interesting to note that a lot of XEPs are “experimental” and so technically not (yet) standards, but often implemented anyway. Such XEPs can be widely modified before they get the “Draft” status and eventually become a standard.
Why am I talking about all this? For you to get one thing loud and clear: XMPP is not only about instant messaging!
Some interesting examples of extensions:
  • Extended Stanza Addressing (XEP-0033): to send messages to several recipients at once, or to do carbon copies, as well as blind carbon copies (as the… yes, yes you see what I mean).
  • Multi-User Chat (XEP-0045): IRC-like group chat.
  • Ad-Hoc Commands (XEP-0050): a generic system to handle any kind of commands. Related to users' permissions, it is a great tool!
  • vcard-temp (Business cards, temporary version, XEP-0054): The legacy way to manage electronic business cards, which are a kind of public profile. A new extension will eventually replace it (XEP-0292).
  • Jabber Search (XEP-0055): used to search for jid, mostly used by directories.
  • Publish/Subscribe (XEP-0060): a big piece, used to publish all kinds of information, and its recovery based on permissions, with a notification system in real time.
  • XHTML-IM (XEP-0071): to publish with an XHTML subset, which enables formatting (to write bold text or include a picture for example).
  • Gateway Interaction (XEP-0100): to manage gateways, i.e. links to external networks.
  • Personal Eventing Protocol (XEP-0163): a kind of simplified Publish/Subscribe system.
  • Jingle (XEP-0166): Peer-to-peer session establishment with a wide range of possible applications, the most well-known being video conference.
  • Serverless Messaging (XEP-0174): unsurprisingly used to communicate without servers.
  • Message Archive Management (XEP-0313): to recover messages or other objects (works with Publish/Subscribe as well) following criteria such as a date. In particular, used to get a conversation history on a server, which is useful to access it from all your clients.
Keep in mind that we’ve barely scratched the surface here.
Further details will be provided about some of these extensions in future articles.
Please note that extensions can be referred by using short names, for instance “MAM” for “Message Archive Management”. Such names are usually mentioned at the end of the related XEPs, in the “Document Information” appendices.
This may lead to situations where clients and servers don’t support the same extensions subsets… How to make both parties agree on which one to use? This problem is solved through another extension (though so essential and widely implemented that it could nearly be considered as a main standard): “Service Discovery”, aka XEP-030, short name: “disco”.
The idea is simple: each client, server or component discloses who it is, what it can do, or associated items. A component is a service that plugs itself into a server, see below.

who it is

An XMPP address (or jid) can be used by all kinds of elements, be it a server, a client, a gateway, or a bot for instance. The latter is a robot, i.e. a program that automates tasks, and is often used to behave like a client.
When a client or another element sees a jid, it may need to know what kind of element is associated to that jid, for instance to render it in a special way in the user interface. This is how clients and gateways are shown in distinct ways in your contacts list.
Disco’s identity provides this through a category (“client” or “server” for instance), a type (e.g. a client can be “bot”, “web”, “game”…), and a free name (eg “ejabberd”). A list of categories and their associated types can be found on

what it can do

XMPP’s extensibility makes it very feature-rich, therefore knowing what the software we are talking to is able to do is mandatory. Disco provides a list of such supported features, which is why you may see disabled buttons or icons (e.g. for video conference) while talking to someone. This means the client you are talking to indicates that it does not support this feature, or more accurately: it does not reveal that it supports it.
These features are linked to namespaces that are mentioned in the related XEPs. A list of XEPs based on namespaces is available here:

associated items

Beside its identity and available features, an XMPP entity can have associated elements. They can be servers indicating where to find chat rooms, or gateways to other networks.


Let's try

Let’s make this clear with an example. Salut à Toi’s command line interface “jp” can retrieve an entity’s disco using the command “jp info disco”, see below with
% jp info disco
ejabberd (server/im)
As we can see, supports legacy vCards management (vCard-temp, XEP-0054) as well as ad-hoc commands (, XEP-0050), and the server (server/im) used for instant messaging is called “ejabberd”. We can also notice that various services are available, one of them being Let’s take a closer look:
% jp info disco
Public Chatrooms (conference/text)
JabberFR (13) []
We see that we are dealing with a chat rooms service (conference/text), which use the protocol “Multi-User Chat” ( It is at the moment the only one which is available for groups’ discussions (we will talk about it later). “Items” elements contain rooms’ list, with the name, the occupiers’ number with the corresponding JID. I shorten the list which was very long.
In’s information, you may have noticed the “extensions” section, it is the XEP-0128 which allow to extend disco for all kind of information. In the case of ejabberd here, it is to give contact addresses of server, but they aren’t indicated for
Below the disco’s window of Gajim:
Gajim disco
The first time I used XMPP, with Psi in the early 2000s, I was a bit intimidated by the “service discovery” menu, which shows near directly all information we just saw. This kind of menu is often, at my opinion, showed too abruptly in XMPP clients: using disco directly (that is all except what is automated by the client) is already advanced use.
Furthermore, I will quickly mention the “software version” extension (XEP-0092) which allows, as indicated by its name, to know to which software we are talking to, and the operating system used. jp allows to show these information with “jp info version”, let’s try on
% jp info version
Client name: ejabberd
Client version: 2.1.13
Operating System: unix/linux 3.2.0
We now know the ejabberd version that is used. Useful when we know if a feature is supported or if a bug is fixed. And this work with every entity which implement the XEP, not only servers.
% jp info version
Client name: MU-Conference
Client version: 0.9-svn (Jan 27 2014)
Operating System: Linux 3.2.0-4-amd64
That’s it. Knowing about the extensions allows to truly know what we can do with a client or a server. Next time I think I will explain groups’ discussions and see what changed in relation to IRC.

jeudi 30 juillet 2015

Let's talk XMPP - episode 2 - core and extensions

This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there:

The translation to English was done thanks to: Poulet, Éfrit, Paco and mbarbarosa and Weyfonk. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles.

Now that we know what we’re talking about, let’s see what the core of the protocol looks like.
Originally, XMPP is defined by 3 (previously 2) RFCs: RFC 6120, RFC 6121, and RFC 6122 (there are others, but these 3 are the main ones). They explain the core of the system, such as sending messages, presence information, statuses and so on.
Without getting too much into details related to developers, we can quickly explain that XMPP is based on 3 element types, or “stanzas”:
  • <presence/> to primarily indicate… our presence information (sometimes, we also add other things like our avatars, our capabilities, but let’s stay focused). The presence is broadcast by the server to all the people that you have given permission to (see below).
    We can associate a state and a message to our presence. The state can be one of the following (names can change depending on the client):
    • available (default): you’re online.
    • away: you’re away for a short period
    • chat: you want to talk
    • dnd (do not disturb): you’re occupied (often called “busy” in clients)
    • xa (eXtended Away): you’re away for a long while.
    The status messages allow you to specify your availability in a clear language (for example: “I’m watching a movie, do not disturb”), even though, in practice, it is used for any kind of message (a lot of people use a quote, for example).
  • <message/> A message’s sending of type “send and forget”. There are 5 types of messages::
    • chat: the most well-known message, used for simple instant messaging;
    • error: this one is usually managed directly by client software. It is often shown by means of a notification window in your client, indicating that something wrong occurred;
    • groupchat: as “chat”, but for discussion with multiple people. In practice the difference concerns only developers and it should be transparent in the client;
    • headline: an important message, an announcement. Normally, these messages aren’t kept offline, so if you aren’t connected while the message is sent, you shouldn’t receive it. These messages don’t expect answers. A typical example is an announcement for an imminent server maintenance;
    • normal: a little known yet interesting type. It is a message which generally has a subject, but outside of an instant conversation. Yes, exactly like an email! It is more or less its XMPP equivalent.
    Conversation threads are managed as well, but we’ll talk about it another time.
  • <IQ/> (Info/Query): used for everything that works on a question/answer pattern (it is mandatory to provide an answer to an request, even if you need to reply with an error). This is used mainly by developers, as it serves as a basis for most of the features you need. Using it is like saying "I need to know or edit this information".
I don't want to delve into technical details, but it seems essential for a user to know different message and presence types to understand their client.
One should note that there is an excellent feature that is largely underused in XMPP: it natively knows how to handle different languages because of its inheritance from XML (xml:lang). In other words, you can specify a normal or status message in French, German and Slovak at the same time. This is a major asset that we intend to use in Libervia.
Now let's talk about another essential part: the contact list.
It is called "roster" in the XMPP world. You can assign 0, 1 or several groups ("family", "friends", etc.), a name (which is an alias chosen by yourself, not by your contact), and subscription information to every contact you add to your roster.
Subscription lets you know whether you have allowed your contact to see your presence information and whether you are allowed to see theirs. Therefore, every time someone adds you to their contact list, your client (e.g. Gajim) asks you whether you wish to grant them access to your presence information. Note that these permissions don't need to be symmetrical: a contact may have been allowed to see your contact information without enabling you to see theirs, and vice versa. It might even be possible that neither of you can see each other's presence information (but I think most clients remove the contact from the roster in that case).
Groups are dependent on contacts, not the other way around (it's not a list of groups which contains the contacts): this explains why having an empty group (i.e. without any contact) isn't possible. In my opinion, groups too are underused in the XMPP world, but we'll get back to this.
That's it for today. I opted to keep the part on extensions for the next post to keep this one lighter.

mercredi 29 juillet 2015

Let's talk XMPP - episode 1 - the basics

This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there:

The translation to English was done thanks to: Poulet, Éfrit, Paco and mbarbarosa. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles.

Well, as it’s a shame that XMPP is not well known or understood, I decided to start a series of articles to explain what it is.
These articles are for a technical audience, but not necessarily for developers, and I hope it will help you to understand the advantages of this protocol and to use your software in a better way.
Being a developer of the “Salut à Toi” project, I’ll probably give examples with it quite often.
So let’s start with basis.
What’s XMPP? It’s a standard message and presence protocol, and extensible (XMPP means « eXtensible Message and Presence Protocol », that is it’s documented and used as a reference (validated by standards organization: the IETF). It allows all software which use it to speak the same language, and so to be interoperable. It’s a libre protocol, that is you can get the documentation and use it for free, without any legal or technical restrictions, and you can improve or modify it (but if you divert and don’t suggest your modifications, you risk to lose the compatibility with other software).
XMPP is decentralized and federated, that is you can have servers anywhere, they could (if they don’t forbid it explicitly in their configuration) communicate with each other.
It’s a popular protocol, many software allow to use it: for servers, there are Prosody, Ejabberd, Openfire, Tigase, Mongooselm, Metronome, etc. For clients: Gajim, Poezio, Pidgin, Psi, Swift, Jappix, Movim and of course Libervia/Salut à Toi (I let you find the official websites by yourself). A complete list (servers, clients and libraries) is available here:
If you cannot install your server at home, many public ones are available: in France one can cite those of APINC ((,, etc), of the Quadrature du Net, etc. A small list (it’s not up-to-date, don’t hesitate to contribute) is available here in French,, if not you can check on or (yes, there are a lot!). But I strongly suggest you to install your own server or to go meet a local organization that you can contact easily: on the one hand if you install it by yourself you’ll have a better control on your own data and on the other hand if you want a specific feature you’ll be able to ask admins for an update.
Knowing all that, let’s try to install an account.
Once the server installed or a public server chosen, you can create an account. You’ll have then an address, a “JID” (Jabber ID, “Jabber” is the former name of the protocol, this name is now owned by a private company and is kept here for historical reasons).
This address is on the form of local_name@domain.tld/resource, or in canonical form (or what is called “bare JID”) local_name@domain.tld. For example, mine is Does it sound familiar? Yes, it really looks like email addresses!
So what is this resource? The resource is linked with the client software that you use to connect: XMPP has been designed from the beginning to allow several clients to connect at once (10 years ago, a few messaging protocols were able to do that, and connecting again from a different place was often resulting in the disconnection of the first client) and this resource is used to identify them. In other words, you have a resource only once connected, and it will be a different one for each client that you are using: if I connect with Libervia, Gajim and Movim, I’ll have 3 different resources.
It used to be several strategies to name the resource, sometimes it was used to show the connection location (“home”, “work”), clients often used their names as default value (“gajim”, “psi”). Today, it’s well accepted that it’s better to have a resource that we cannot guess, as somebody can know if you are online or not (even if you don’t want this information to be public) by doing a request to this resource. The best way is to let the server choose the resource for you.
Finally, the resource is linked with a priority: it allows to indicate, if several resources are available, which one will get the message. But we’ll see that later.
In the next episode, I'll talk about extensions an features discovery
That’s it. Let me know if you are interested in this series, if it seems too technical for you, or if you have any comment or fix to suggest. Everything is under the license CC By-SA, so don't hesitate to re-use, share or modify !

vendredi 19 septembre 2014

Salut à Toi v0.5.1

We are happy to announce the release of Salut à Toi v0.5.1! This version focuses on security and code refactorisation to ease the add of new features and maintenance.

We remind you that SàT is a multi-purposes and multi-frontends XMPP client, mainly developed in Python. The more advanced frontends are Primitivus (console) and Libervia (web). Jp (command line) can be used for administrative tasks. Wix (desktop/WxWidgets) will be deprecated and replaced with Bellaciao (desktop/Qt). An Android frontend is also planned.



A new parameter has been added to define a password for the SàT profile, it is stored hashed in the database. Its raw version is used to cipher the other passwords - including the one for the XMPP account - which are encrypted. A scheme on the wiki explains how this all works: encryption.

Libervia now handles HTTPS. The administrator can choose the service(s) to enable: HTTP, HTTPS or both.

You can uses OTR for instant messaging end-to-end encryption. Primitivus console interface uses the Python library potr while Libervia is based on the Javascript implementation otr.js. Thus, your encrypted discussions on Libervia are really private because the encryption is done directly by your browser; you may encounter some slowdowns, especially when starting OTR.

http<em />unsecure</em>warning

stdui<em />profile</em>manager<em>primitivus</em>1

stdui<em />profile</em>manager<em>primitivus</em>2

Other additions

You will notice:

  • the add of chat rooms bookmarks;
  • the display of the composing states in chat rooms;
  • a better integration of the ad-hoc commands, e.g. to allow the administration of the server from Primitivus or Libervia;
  • the possibility to erase all your blog posts, change your password or delete your account from Libervia;
  • contextual menus on the roster contacts and the discussion panels;
  • a couple of new stuff concerning the static blog pages.

bookmarks<em />manager</em>primivitus

manage<em />account</em>delete_blogposts



We care to redesign the code when some conception issues are found, or if we imagine a new mechanism which would work better. It is especially important for a project like SàT which is multi-interfaces and still in development. For this version we made several refactorisations concerning:

  • XMPP service discovery;
  • messages sending and reception;
  • textual commands management;
  • contact list management;
  • hierarchical organization of the constants;
  • Libervia's source files hierachy;
  • Primitivus keyboard shortcuts.

These modifications are not of a big interest for the users, but they ease our life, and maybe those of the people who would like to give us a hand! We see them as required first steps to initiate the development of the mobile phone frontend and the add of new features.

We extended the usage of XMLUI, our internal micro-format for describing user interfaces. We use it to manage frontend's dialogs from the backend. The user actions are now better integrated and we will keep on improving it for the next versions.

stdui<em />contact</em>list_primitivus



To be mentioned

The backend is now launched as a Twisted plugin and starts by default in daemon mode, just as Libervia. The initialisation sequence backend / frontends has been improved; this fixes the issues that could occur when SàT and Libervia were launched from a script within a short time. Moreover, we added a .service file for D-Bus to automatically launch the backend when a frontend needs it.

The default paths for the user files are now compliant to the XDG recommendations: configuration file in ~/.config/sat, database and the rest in ~/.local/share/sat. Any previously existing default configuration file will be retrieved and eventually updated.

If the XMPP server address and port are left empty in the connection parameters, the actual values can be retrieved from a DNS SRV record - if one is set for the "domain" part of your JID.

There's a new log system, fully customisable and managing the colors, formatting, filtering and outputs (files, memory...).



Administrative aspects

We submitted the file for the creation of the association "Salut à Toi"... which has been accepted without any trouble, positively surprising us. Our working mode is indeed a bit special for a French "1901-law" association: a collegial board with no president, secretary nor treasurer but two co-administrators. We remind you that there is behind this project a desire to fully involve ourselves, and this is not compatible with the pursue of another professional activity. This means, for the developers, the necessity to find a funding source. We will start with testing / adapting our idea of a good funding model for SàT, of course meeting the ethical and moral commitments that are defined by our social contract.

The association memberships are our favorite source of income! We defined in the internal rules several amounts for the annual subscription, between 0 and 100 euros and every one is free to choose. There's no typo! For the persons who would like to support us without being able or willing to contribute financially, that's possible - because moral support is important too. So there's no reason not to join ;-)

We are unfortunately not ready yet to offer you the possibility to make it online. We actually plan to open a bank account for the association at the end of this month, then we will prepare the online form to manage the subscriptions.


We attended this year the "Free Software Days" (aka JDLL in French) in Lyon, "Pas Sage en Seine" in Paris and the "Libre Software Meeting" (aka RMLL) in Montpellier - see the links to watch the recorded conferences (in French). We met or saw again some nice people at the stands and during the speeches Goffi made. Many thanks to the organizers of these events, and to which wrote an article about SàT following the last version's release, allowing a larger public to get to know about the project.

We also participated last week to the "XMPP Summit" and its hackaton in Berlin. We met there some XMPP developers, including two with whom we have regular contact, such as Edhelas from Movim. We presented together our issues with the protocol and will suggest new XEPs to standardize some practices (especially regarding Publish-Subscribe and blogging), and push their implementations.

Saturday, September the 27th between 2pm and 5:30pm, Goffi will participate to a radio program from "Ici et maintenant", recorded in Paris and about self-hosting. There will be many guests including two from the Jappix project.

We would like to organize some gatherings via the association, at least once per year as a general assembly and maybe more often. The date and the location haven't been discussed yet.

Please also notice the recent creation of a "users" mailing list for SàT, it completes the chat room and the "dev" mailing list.

And then?

We would like to migrate our own blogs to SàT. The version 0.6 will focus on blogging (in SàT, it is based on a fine access permission system, so you only write to the people you want), pictures storage and tags implementation. These are essentials features and maybe the last important works before the publication of the first public release, which has been a bit delayed and should be stamped 0.7 or 0.8.

mercredi 26 février 2014

Salut à Toi 0.4.0: a new version of the powerful XMPP/Social software


We are pleased to announce « Salut à Toi » version 0.4, which comes with many important changes, also regarding the project's life.

Salut à Toi is a powerful communication tool, free and multi-frontends. It offers some features like micro-blogging, instant messaging, an easy way to manage groups permissions (elsewhere called « aspects » or « circles »), games and much more.

Constantly designed with ethical and social thoughts (politically speaking), Salut à Toi (abbr.: SàT) is also bound to its social contract.
Being based on XMPP, SàT is decentralised and compatible with the other projects that use this protocol.

Before starting with the traditional listing of the new features, a few words about the evolution of the project. We are now two persons working full-time on SàT: so did Souliane, a friend for a long time, join me. We would like to live from the project, but we also want to respect our ideals (cf. the social contract) : we are firmly opposed to commercial advertisements, selling data or any similar behaviors.

We decided to organize ourselves as a self-managed entity, probably under the terms of a cooperative and we would like to start it this summer.
There are 3 economical models that we are thinking about:
  • the first would be based on donations. This is a precarious model but it would offer us the largest independance in our decisions taking process.
  • the second, more trendy, is the use of the so-called crowdfunding platforms. It is finally very close to the donations system, but it requires more work to file the applications etc. Moreover, we would need to select with care the platforms to be used.
  • the third one runs more classically, based on services : technical support, specific customizations etc. This is the one model which would leave us the least interdependancy, and the least time to focus on the project itself.
We often discuss about the project organisation, the features to be implemented, etc. We not only agree that privacy is primordial, we also believe that it is not the sole aspect to be studied, and that the impact these kinds of tools have on our lives deserve some special attention. Technology is not neutral, so we are thinking about how to implement and design things, and we are open to discuss (in real life better then behind a screen) ; feel free to launch a discussion with us.

That being said, let's have a look at the change log!
The list is quite long (the last version was more than a year ago), here is a selection:


The micro-blogging has been much improved. Comments are now handled, still using the fine access tuning for Pubsub: comments inherit the permissions from the micro-blogs they are replying to. The unibox of Libervia was disturbing many people and it is now optional, the default behavior for typing messages being more classic.


Rich texts have been implemented. The system is quite versatile and it's easy to add new syntaxes that would be available for all frontends.


When you update some content, you can edit it using the syntax of your choice, even if it has been published with another one. Thus it is possible to edit in Markdown a post that has been originally created in XHTML.

For now, XHTML, Markdown and raw text are available, more should arrive soon (for instance Dokuwiki and Dotclear's syntax).


The textual (micro)blogs are now recognizing and displaying inline URLs.
In addition to the rich text edition, a WYSIWYG edition (also to be used as a preview feature) is available in Libervia.

And there's still the static blog to display your public messages. It is now completed with an Atom feed. We are getting closer to a full decentralised blog engine and we plan to
move our own blogs to SàT by the next release, so some import tools to migrate from Dotclear and Dokuwiki are to be expected.



It is possible to send messages in carbon copy or blind carbon copy, according to the XEP-0033

The MUC configuration has been implemented (the menu is currently only available in Primitivus)
Chat states notifications have been implemented, letting you know if someone is writing to you or if she/he left.


one plugin is adding some IRC-like commands e.g. /nick or /join

Command line

thanks to Dal, jp – the command line frontend – has been upgraded to ArgParse, allowing a proper commands refactorisation and confirming jp as being an XMPP “swiss knife”.

it's easy to forward a command or pipe output to a contact, but also to create a remote control (see below) or to transfer a file. Some more commands to publish micro-bloggs, manage your roster etc. are planned.

there's a bundled script to offer you the auto-completion with Zsh
Complètement de jp dans zsh


important work on the extra-features for the discussion rooms. The Collective Radio (allowing the members of a discussion room to upload some music and listen to it at the same time) has been improved, it also handles the user leaving and return.


Ad-Hoc commands are available, allowing to remotely control an entity with any XMPP client

based on the Ad-Hoc commands, a universal remote control has been implemented to offer the possibility to control most of the softwares. A post on my blog is presenting this feature, there's also a short demonstration video featuring VLC


command export
: command export : another original feature - it's possible to redirect the input/output of a process to any of your contact (including to another network via a gateway), again the easy way with the fine accesses tuning. There is a demonstration on my blog with an FTP session export to a contact using Gajim

messages notifications are available in Libervia (a contribution from Link Mauve): if someone is talking to you while the tab is hidden, a message should appear on your desktop.


In Libervia: in addition to the drag and drop which was already available, you can click on a contact or a group to open the associated widget. Widgets can now be moved from one tab to another.

considering the importance of the groups in SàT (used a lot to manage the permissions), a roster management user interface has been added to Libervia


a mini XMPP discovery service has been started, it's already running on the demonstration server.

Under and around the hood:

Some heavy refactorisations have been done to ease the development of future frontends e.g for small screen devices.
The SQLite database is automatically upgraded.

Some work has been done on the testing system, with the installation of a buildbot ( ) which is running a test batch after each commit.
Some SàTellites projects:
  • SàT Pubsub (based on Idavoll) is a Pubsub component for Prosody to manage fine access tuning, it's used for micro-blogging
  • Urwid SàText (based on Urwid) is a widgets library for console display, used by the frontend Primitivus.
  • "Salut" is a XMPP directory, at a very early development stage

Did you know ?

Some reminders about a couple of (hidden) features:

In Libervia you can position your widgets over several columns / lines

SàT comes with an IMAP server that let you use a MUA like Firefox or KMail to read your messages


Beside our projects regarding the cooperative, the following should happen from the technical perspective:
  • an important work concerning the security. Until now, we left on purpose this aspect behind, to not do things by halves and fully focus on it when the time has come. So we plan to integrate HTTPS to Libervia, end to end encryption and password encryption in the database.
  • finish the micro-blogging support and migrate our own blogs to SàT
  • (hash)tags
  • frontends/ports for telephones and tablets, Windows (and Mac?)
  • update the Bellaciao frontend (Qt-based)
  • RSS/Atom feed integration
  • event and calendar management, etc.
We plan to release a public version this summer, it would be the first named version and, as already announced, it will be named « la Commune ».


A big thank to contributors:
  • Link Mauve (Emmanuel Gil Peyrot): notifications Twisted plugin for Libervia, style improvments
  • Dal: jp profiles management, ArgParse in jp
  • Robotux (Thomas Preud'homme): locales correction, distribute update
thanks also to packagers (Naha and Robotux for Debian, Link Mauve for Arch, and surely other that we don't know, don't hesitate to contact us).
thanks to Elefantom for using daily the demo, and to give us several feedbacks
thanks to Parinux and Nanterrux to invite me for a talk, and to the JDLL where we'll be again this year.
thanks to the Loop to host the first Salut à Toi hackathon :). Ambiance and location where great.
thanks to Luc and Manu for the interview in the "Symbiose" emission, and for the following discuss.

Come and join us on XMPP MUC room

mardi 18 février 2014

A universal remote for your softwares

Salut à Toi (SàT) now allows to easily create a remote for most of your softwares, and to share it with permissions management.
Suppose that you are in a flatshare, and you want that your flatmates can change the music of the Amarok running in your living room: the following command is all you need for that:

jp ad-hoc remote -g flatmates -- amarok

where "flatmates" is the name of the group which can control Amarok. You may also want to remote control Okular (e.g. for a talk), or VLC on your phone.
Below is an example with VLC.

The syntax may seem complex in apparence, it's actualy very simple:
  • " jp ad-hoc remote" tell that we want a remote control
  • "-pgoffi" say thaat we want to use the profile "goffi", but if it's the default profile, it's not needed
  • "-cl" the "-c" means "connect this profile if it's not already done", the "-l" means that we want to loop on commands (after launching a command, we will return to the command menu instead of finishing the ad-hoc session).
  • "-g coloc" is a filter (coloc mean "flatmates" in french): it tells that in addition of your own jid, the jids from the group "coloc" are allowed to use the remote
  • " -- vlc" the "--" is just here to terminate optional arguments, and "vlc" is the name of the software to control.

once the command entered, SàT fill look in D-Bus's Session bus to find buses which have "vlc" in their names, and add commands which don't need arguments. The output show what has been found.

Now, let's see how we can use the remote in Libervia (web interface of SàT):


We use the remote with the ad-hoc "commands" menu

we enter the jid which exported the remote. So far, we have to enter manualy the full jid, but in the future, a simple right click should be enough.

vlc is indeed visible in commands

and voilà ! Commands are available. Once again, it's a bit unfriendly at the moment, but it will be easy to replace common names like "play", "stop", "previous", etc with nice icons...


And it's of course working with every XMPP clients featuring ad-hoc commands, like Gajim or Psi (here Louise can use the remote control created by Goffi because she is in her group "coloc").
There are many advantages: ease of use, it's generic (the software just need to have its commands exported via D-Bus, which is pretty common on freedesktop environments like Kde, Gnome or XFCE), authorisation can be easily managed, and it works everywhere where an XMPP client featuring ad-hoc commands is available. An another proof that XMPP can be used for far more than just instant messaging, and a demonstration of the potential of jp, the command line frontend of SàT...

To conclude, a short demo video (in french).

As usual, to watch the video you can use a recent browser (the last Firefox/Iceweasel for example).
You can also use VLC (version >=1.1 only), by using the "Media/Open Netword Stream" menu and by entering this URL:
Last but not least, you can use mplayer:: mplayer ""

this video is licenced under Creative Common BY-SA

vendredi 22 février 2013

Export command to a contact (with video)

G'day everybody,

I have made a small plugin for fun which export the input/outputs of an Unix command to a contact. The principle is really simple: you enter a command (so far it's not implemented in the frontends, so you'll have to directly use the D-Bus API, throught e.g. D-Feet or qdbus), then the contacts allowed to communicate with it, with options if necessary, and voilà !

There are 2 mains advantages by doing this:

the first one is that you can give access to an interpreter to any of your contacts (I'm doing this with FTP in the video, I have also made tests with bc, ipython or zsh), without using heavy tools like ssh which need to create an access account, a client, an opened port, etc. Of course, it's not elaborated, it's not a terminal, but it can help out. The escape sequences (what bring colors and others things in your interpreter) are not managed yet, and it can scramble your output (I had the case with ipython). I'm thinking about catching them, and convert to color with XHTML-IM (well, a first step would be that SàT manage XHTML-IM :p ).

the second one is to help to write bots really quickly: you just have to make a script with read stdin and react to it. You can make a bot in a couple of minutes with any scripting language (sh, Python, Ruby, etc) or others. And you can directly debug it from a terminal, without the need of an XMPP server to test it. To show you how easy it is, I have made a little test in Python, here what it looks like:

#-*- coding: utf-8 -*-
import sys

class QuickBot(object):

    def out(self, msg):
        sys.stdout.write((u"%s\n" % msg).encode('utf-8'))

    def start(self):
            _input = raw_input().decode('utf-8','ignore')
            if _input.startswith('!'):
                args = _input[1:].split()
                    getattr(self, "cmd_%s" % args[0].encode('ascii').lower())(args[1:])
                except (IndexError, AttributeError, UnicodeEncodeError):

    def cmd_salut(self, args):
        self.out(u"à Toi !")

if __name__ == "__main__":
    bot = QuickBot()

The contact just have to enter !command [arguments] to make it do something (here !salut). To add a new command, you just have to create a new method named cmd_my_command, e.g. cmd_toto will add the command !toto. Easy isn't it ?

I have made a short video to show you this, it's in french but easy to understand even without sound, where I export a FTP server.

I have also made a small web widget for Libervia (it's not pushed on the repository yet). Of course it's limited (because of javascript security restrictions), but it allow to show whatever you want beside your conversations, and to enjoy Libervia's layout management (you'll can, for example, put 4 websites on a grid).

See you soon

As usual, to watch the video you can use a recent browser (the last Firefox/Iceweasel for example).
You can also use VLC (version >=1.1 only), by using the "Media/Open Netword Stream" menu and by entering this URL:
Last but not least, you can use mplayer:: mplayer ""

this video is licenced under Creative Common BY-SA

vendredi 11 janvier 2013

Salut à Toi version 0.3.0 (with demo online !)

Salut à vous !

No news is good news ! The lack of news on the blog lastly is due to the work on Salut à Toi, which is comming in a new 0.3.0 release.

Really a lot of new things in this release, the 0.2 being more that one year old. If you follow the blog, you should have seen some of them like the radio collective, the pipe over XMPP, Primitivus becoming modal, the license change to full AGPL v3 or the group microblogging improvments. Other are still in early stage like the "Bellaciao" Qt frontend, or the quiz game. This year also came the new website, and misc other additions, more or less big. I will not talk again about all of this, there were already posts about most of named features. The installation instructions are at the bottom of this page.

Instead, let's talk about the new online demo. You'll find it at, and you'll just have to click on "register" to easily create a new account. This account come with a Jabber address (Jabber Id or jid), and will let you talk to the world. Don't hesitate to join the SàT room (menu "Groups/join room", then let the default address which is the one of the room: to ask your questions or just talk about the project.

Web Interface

The main goal of this demo is to let you try the web interface.

Libervia v0.3.0: sending a message to Louise

You can add widget as you want by drag and drop. This way, by moving the name of a group (well, you'll need to add some contacts of course ;) ) to the center, you'll create a new panel with the microblogs of this group. If you do the same thing with a contact, you'll start a chat. Drag over the "contact" header in the same spirit, and you'll obtain a panel with all microblogs, from all groups. In the future, it should be possible to save the layout to bring it back easily.

To send a message in a discussion, you need to click on it (the title bar become red, like for Louise in the screenshot above). When you enter a text, a green banner certify you that you're talking to one person or in a room.

If you unselect the widget, you can either click on an other one, either click on the gray space under the text entry (it's the status area). If you enter a text without nothing selected, it will be your status message.

For group microbloging, enter the target group by writing your message like this "@group: message". e.g.: "@friends: Salut à Vous !". A message written like "@@: Salut à tous" will be public (readable also for people which have no account, see below). NB: the banner will be blue for a group message, and red to say "careful, this message will be public, either for people you don't even know".

You can also try the collective radio, or the french tarot game (which will hopefuly work correctly).

public microbloging

the public messages page is a the following address: (e.g.: Here you'll find open microblogs (the ones written like "@@: message") from the person, a bit like or Twitter. This page is currently really basic, it will for sure become better with time.

using an e-mail client(MUA)

Like seen previously on the blog (well, in french actually :) ), you can use an e-mail reader like Thunderbird, KMail or Mutt to connect to SàT.

Thunderbird, connected to SàT show a message send by Psi through XMPP

So far it's really basic (it's not yet possible to create directories with IMAP, the account must be logged will using the e-mail client, you can't send message on the traditional e-mail network), but this should become better and better to finally bring a full e-mail server.

This feature show the way to many experiments through XMPP gateways or project like Weboob. Thank to it, we can for example send message through KMail to IRC, SIP or SMS (using gateways like Spectrum's ones). Add Weboob to this (using an XMPP gateway that I have started), and you'll can send messages to website like DLFP.

We can imagine "smart" answer: are you never annoyed by receiving notifications for messages from a website, and to have to connect to it using a web browser, just to read and/or answwer the message ? It will be possible to automate this, so you'll can do everything from your favorite email software.

I have other ideas in head, which should slowly come.

To use this, you have to indicate your jid (which is like as your e-mail address, the IMAP and SMTP server to use are (both) and the respective ports are 10143 and 10125. So far, you have to be logged to the web interface to be able to check you e-mail with your e-mail client, a issue which will of course disappear in the future. Other issue: you can't create an IMAP directory yet, so you'll have to save your messages/draft and other templates locally (in Thunderbird, in the account parameters, you'll have to put "Local Folders" for everything in "Copies & Folders").

Once the configuration is done, you can try with a jabber contact: ask her to sent you a "normal" message (the ones with a subject) with - for example - Psi or Gajim, and answer her with you e-mail client :)


The installation should be really easy (for people on GNU/Linux: multi-platform is not yet managed; please be patient ;) ), as the project is on pypi. So, a simple "pip install sat" (as root) should be enough. If you're using Arch, a package is already here (thanks to Link Mauve). On a fresh install of Debian, the following command should install "Salut à Toi" (to enter as root):

#apt-get install python-pip python-dev
#pip install sat

Once SàT is installed, you can launch it (by entering "sat"), then use the console ui (by entering "primitivus"). To use Wix, you'll have to install media as shown on the wiki. And don't forget the new website, with useful links and some screenshots:

Okay, I think this post is long enough (and I need to sleep to be honest), see you soon...


jeudi 2 août 2012

New website for Salut à Toi + some news


a quick post for the opening of the new Salut à Toi's presentation website: The goal was to have something more accessible than a wiki page: you should have quickly a global idea of what the project is with it. It's available in French and in English (any help to add a new language is welcome).

In addition, I was to Linux Software Meeting in Geneva (RMLL in French) in July, and I have had a talk about the project: . It's in French, I'm thinking about subtitling it soon (again, any help welcome). The meeting was good, I had a common booth with Romain from the friend project Weboob, and I have also seen again people from other project like MOVIM (we were neighbours), Jappix or Newebe.

People seemed interested by "Salut à Toi". More and more people know the project, at least by name. I hope next year the running version will be usable for everybody (not only developers)...

Other news: the project is now fully AGPL v3+ (before it was a mix between GPL v3+ and AGPL v3+) except the data which are Creative Common By-SA.
The Social Contract has been translated to English, thanks to a contribution from Matthieu Rakotojaona.


dimanche 24 juin 2012

Fine access tuning for PubSub

Warning this post is technical

As you may know, "Salut à Toi" allow to do microbloging with groups access, that mean that you can send post to only a group of your roster (e.g. "family" or "friends"). This feature has been available for a year, but was using a dirty hack (which only works with OpenFire); that was mainly a proof of concept

We need a simple permissions system which can be used beyond microblogging, something generic, which can extend PubSub.
Rather than thinking about tons of pubsub nodes with different access model each time (e.g. a family node, an other one for friends, etc), we need a way to fine tune permissions, by items.

For this reason, I started a pubsub component to validate the concept, and which will be used by SàT to manage microblogging. If the idea proove to be working, I'll talk about it on one of the XSF mailing list, to propose it as a standard.

The way it works is simple: we use exactly the same syntax as for nodes access model (, and we apply it to items.
The node access model is applied first, then the ones of items (that mean that an item with an open access model won't be available to somebody which is not in the right roster group if the node has a roster access).
The PubSub component parse the item stanza, apply access model, then save it (without the configuration part).
When somebody wants to get node's items, the pubsub component first check that he is granted to access node (by checking the "access model"), then send him only the items that he can access.

Imagine that Louise has a node with 3 items: 1 with an open access (A), 1 with a roster access, allowed for "family" group (B), and one with a roster access, allowed for "friends" and "coworkers" (C).
Pierre, who is a friend of Louise, will have access to items A and C. Louise's brother will access items A and B.

There a 2 main advantages: first this protocol stay standard compliant (with XEP-0060) - so there is no change to do for an XMPP client to get items -, and secondly the clients have only one node to check by entity that they want to follow.

Some words on test implementation: I use the "Idavoll" PubSub component as a basis, which was made by Ralph Meijer*, and I have slightly modified it for my tests. The main difficuly is that currently components have a very limited access to server, and we can't access entities' roster.
To work around the issue, I use an experimental protocol which allow to access a remote roster. Unfortunately, this protocol only permit to access a part of the roster, so I have patched Prosody's implementation to get the full roster.
Finally, I used some simplifications by saying that node creator, owner and publisher are the same. This is often true for microblogging, but is very limiting when we think about XEP-0060's possibilities.

Anyway it works, but it still need works (and a standardisation) before being a proper way to do.

Below is a server dialog example. We have here Pierre and Louise which are friends, Louise being in "friends" group of Pierre. The later post a microblog as follow**:
<iq from="àT" type="set" id="H_77" to="">
  <pubsub xmlns="">
    <publish node="">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>G'day my friends !</title>
        <x xmlns="jabber:x:data" type="submit">
          <field var="FORM_TYPE" type="hidden">
          <field var="pubsub#access_model">
          <field var="pubsub#roster_groups_allowed">

After receiving this, the server parse configuration data (the "" form***), delete this part of the stanza, save the item with the right permissions (roster access, only for "friends" group), and only send a notification to group's members, so it send one to Louise.

The notification is sent like this:

<message to="" from="">
  <event xmlns="">
    <items node="">
      <item id="8f532cc8-be1d-11e1-b5d3-00c0ca4f1546">
        <entry xmlns="">
          <title>G'day my friends !</title>

There is no way to know on which group Louise is in Pierre's roster (this is a classical notification). Even is an XMPP client doesn't manage the per-item access model, it will receive the notifications and will be able to manage them as usual.

I have sub-licenced the component to AGPL V3, you will find the code in my repository ( I invite XMPP community's members (authors of clients and servers, or others) to use the code, or to comment the idea

Fine permissions tuning are in my opinion a mandatory feature that XMPP really needs, and they will be more and more used by the "Salut à Toi" project. It was one of the last architecture point of SàT, a new release should follow quickly.

Stay connected :)

* Ralph Meijer is also a contributor of Twisted and the author of "Wokkel" library, which are in the heart of SàT, in addition of being one of the authors of PubSub XEP. A huge thank to him for its valuable contributions.
** Normally, microbloging use PEP, but component limitation that I mentionned above forced me to use a custom protocol, which doesn't use PEP.
*** I have used a "" namespace instead of "", as I should have do for an experimental feature, because I need it so Wokkel's PubSub service could parse it.

jeudi 2 février 2012

Collective radio (with video)

G'day everybody

after the shell pipe over XMPP, here is a new feature in "Salut à Toi": collective radio.

The idea is: you are in a chat room with a common playlist, and everybody can add a song to the playlist. The song is played simultaneously for everybody, making it a collective radio experiment.

So far, there are maximum 2 songs in queue, as soon as one song is played, anybody can add a new one. In the future, we can imagine a more sophisticated system to choose who can add a song in queue (e.g. each one in turn, with a vote if songs played are appreciated, or with a game: the one who can answer a quiz question can choose next song).

Maybe in the future we'll see thematic rooms: jazz, rock, experimental, discovery, song with nice lyrics, etc. Or maybe we'll spend some evenings with friends, each one adding nice songs after the other, or playing blind test. We can also imagine party were everybody can participate to the playlist.
If in addition you use it on your phone: you are your own radio disc jockey :)

Following is a video showing the current implementation of the proof of concept, it's in french but quite easy to understand.

For the record: I'll be in Brussels next weekend for the FOSDEM, where I'll make a demo of the project at the XSF stand; don't hesitate to come to have a chat :). In addition I'll have a short talk in the devroom on saturday evening (18:00), you can have more information by clicking on this link.

To play the video, you nead a recent browser (e.g. Firefox 4+ or the last Chromium).
You can also use VLC (>=1.1 only), by using this url as a flux:

Last but not least, you can use mplayer: mplayer ""

This video is licensed under Creative Common BY-SA

vendredi 7 octobre 2011

Shell: pipe you commands out via XMPP with SàT

G'day all,

just a short notice to show a feature i'm currently implementing, the hability to pipe out a command line stream via XMMP, using jp, the command line frontend of the "Salut à Toi" project.

The syntax is quite easy: imagine you have 2 people Pierre and Louise talking together. Louise is talking about the last Blender Foundation movie, Sintel, and Pierre is interested, and want to see the trailer Louise is talking about. To do that, he just has to enter the following command:

jp --pipe-in louise | mplayer -

Which mean "I'm waiting for an incoming stream from louise". Louise correspond to the name Pierre gave to its contact, jp do the association.
He could also have used the full jid instead: .

In the other side, Louise can pipe out the trailer to Pierre with the following command:

cat sintel_trailer-480p.ogv | jp --pipe-out pierre

Quite easy isn't it ? You don't have to worry about the IP address of your contact, just to know its jid, or to have it in your roster with an easy-to remember name.

Note that jp was already allowing you to pipe out command line result as a XMPP message (to do some ascii art for example ;) ).

If you want to copy a file, the syntax is quite similar:

jp -wg louise

for reception and:

jp -g sintel_trailer-480p.ogv pierre

to send the file. The -g flag means you want to see the progress bar.

The following short video show this in action. It's in french, but you don't really need the comments to understand it.

To play the video, you nead a recent browser (e.g. Firefox 4+ or the last Chromium).
You can also use VLC (>=1.1 only), by using this url as a flux:

Last but not least, you can use mplayer: mplayer ""

This video is licensed under Creative Common BY-SA

For the technical side, it's just a modified XEP-0096 . It would be intersting to propose this as a standard to the XSF, but maybe by using jingle transfer instead.

Please not that all of this is really experimental.

I plan to release the next version of "Salut à Toi" soon, stay connected :)

dimanche 5 juin 2011

Salut à Toi: a multi-frontends XMPP client

G'day all,

I have been working for a while on an XMPP client with a daemon/frontends architecture: the idea is that you have the main logic centralised in the daemon side, and you can make very different lightweight frontends for the view. The project is intended to be a modular, multi-platform, multi-frontend communication software. The frontends can be adapted to a particular use case, or platform.
Currently, there are a desktop frontend, a console frontend, a command-line frontend, and a web frontend. A Kde frontend is also planned.

The project is quite difficult to summarise, as it touch a lot of domains (it's not intended to be only an instant messaging software, but to explore deeply the power of XMPP): with it you have instant messaging, e-mail style heavy messaging, multi-user chat, microblogging, file sharing, games, etc.

Techical part

Salut à Toi (SàT) - which means « Hi to you » - is heavily based on the Twisted framework, and the XMPP library Wokkel, which is on top of it and should be integrated in Twisted in the future. The core backend concentrate only on the RFC, a couple of XEP, and the essential stuff to run. Most of the XEP and the advanced functionalities are put in plugins, that allow the code to be modular, and to choose which features you want (you can remove plugins to suppress features for e.g. a public station). SàT manage several profiles: you can use different profiles for different accounts on different servers.

The backend communicate with the frontends throught a "bridge", which is actually an IPC: so far, D-Bus is used, but it is possible to use an other one. All the frontends and the backend together make one client, that means that if you enter something in one frontend, it will appear in the other ones like if it was enterred there. It also means that the history of the conversations is shared, and that if you create one profile somewhere, it will be created globally.

As the backend is independent of the frontends, you can use SàT without graphical interface (i.d. without X running), or unplug a frontend while the backend is still running (e.g. to terminate a long file transfert).
As you can guess by seeing Twisted, SàT is made with Python, it is actually 100% Python, including browser side code (see below); but an other language can be used to make a frontend. Actually any language able to talk with D-Bus can work, and the planned Kde frontend will be made with C++.

Here is a global Diagram of the architecture:
Salut à Toi: Global view

The frontends

Wix: the desktop frontend

Wix is the reference frontend, it is used to test implementation of features. It is based on wxPython. It's intended to be a classical desktop frontend, which should work everywhere. In the future, it could be change its interface for a more experimental one.

Primitivus: the console interface

Primitivus is for console lovers. It is based on Urwid, and the interface is more worked. I had to make several widgets for this frontend, so I eventually put them in a separated library: urwid-satext (Urwid's SàT extensions), I hope they can be usefull for other projects.


JP: the command-line tool

JP is a swiss knife, it can be used in many ways. It can be use to easily send file: I spend most of my time in a shell, and it's often annoying to have to go in thousand dialogue boxes just to send a file, furthermore if I am already in the good directory. With jp, I can just type:
jp file
and I plan to use a more friendly interface like "jp file nickname".
In addition, jp can send a whole directory by compressing it, accept multiple files without having to accept each time, or send the output of an unix command. It can be used as a powerfull scripting tool, e.g. to notify you when something happen on your server.
In the future, it should gain lot of features like sending microblogs, or managing roster.


Libervia: the web frontend

I have waited to make this frontend to start the communication about SàT. Libervia is close to what the fashion wants to name "social network", but with a big emphasis on privacy and user respect; it clearly wants to be an alternative to the massively centralised commercial services. It's entirely made in Python, thanks to pyjamas, with is a Python port of GWT.
There are many thing to say about pyjamas: group centred right management, clear interface, use of widgets, unique input box, visual indicator to show who will be able to read your message, etc.
All of this is shown in a video (in French, but I'm pretty sure it's understandable without the sound, any help to make subtitles welcome):

This video is under Creative Common BY-SA

In addition, a technical demo is online: . Please don't pay any attention to the ugly appearance, we are working on it and it should be really nice looking soon.

Libervia, as the whole SàT project in linked to a social contract, see below.


Some things you can do with SàT

Here are some stuff you can do with SàT:

  • Use your e-mail client (MUA) to read and send your messages: XMPP manage "normal" type message, which are heavy messages pretty similar to e-mails (with a subject and a body). This messages are often managed really basically by XMPP clients, but this job could be done by feature-full stable and well-known e-mail softwares like KMail, Thunderbird, Mutt, Roundcube, etc. So, 3 extensions have been made: one to manage a Maildir box, one to manage an IMAP server, and one to manage a SMTP server. Theses extensions allow to connect most of e-mails clients to SàT, and use them to send message to your XMPP contacts, receive messages from them, or even send message to standard e-mail network throught an SMTP gateway. I think XMPP is an excellent candidate to be used as an alternative to e-mail.
  • Microblogging: SàT manage microblogs (only in Libervia so far), not only in the popular classical public way, but also with access restriction through roster-based group access. For example, if you have all you family members in the group "family", you just have to enter "@family: Salut à toi la famille" in the input box, and only the member of your family will be able to read this message. If you want to publish this for everybody, just enter a double @, like this: "@@: my global public message". With this, not only all you contacts will be able to read your message, but even people you don't know as it is public (on the online demo, you can see them through
  • receive multiple files from one contact without having to individually accept them: jp, the command-line tool, allow (among other things) to automatically accepts files, or to send a full directory at once by making a tarball with it.*
  • Nothing to do with XMPP, but an extensions allow to send message to a Couchsurfing account. There is a way to make lightweight XML interfaces for plugins: that allow to make a plugin which will work with all frontends; the couchsurfing plugin was just an excuse to try it.
  • Play French Tarot: I have made a French Tarot game (a card game extremely popular in France), which is playable on the desktop with Wix, in text-mode with Primitivus, or in a browser with Libervia. It was a test in the idea to make a general card game XEP, any people interested in cards games for XMPP can contact me.


Games are an important part of SàT. The following stuff are planned:

  • Generic card games engine: the Tarot Game was an implementation test of a card game. I'd like to take profit of this experience to make a generic XEP, wouldn't it be nice to play your favourite card game through your favourite XMPP client with your friends ? If you are too far to play on a real table of course :)
  • I'd like to do the same think for board games, and a Xiangqi game is planned (Chinese chess)
  • A quiz game is planned in the very short term, probably for next release
  • on the long term, everything can be made, even maybe real-time games


Social contract

Maybe the most important point of all the project: a social contract has been made, and show the principles that SàT and people involved in it follow. It can be read here:, but it's only available in French so far.


  • The SàT backend, Wix, Primitivus and jp are under GPL v3+
  • urwid-satex is under LGPL v3+
  • Libervia in under AGPL v3+

What's next ?

I have reached the point I wanted to build the foundations of the project, and make it credible. Now I need to stabilise everything, clean and re-factor several parts of the code, remove all the ugly Q&D hacks, finish half-made things, etc.
It's the perfect time to give a hand :)

But new features are planned on the short time, mainly picture sharing and quizz game.

You want to help ?

All the tools needed for contributions is here (wiki, bug tracker, mailing list, mercurial repository).
The project use many really interesting stuff like Twisted, Wokkel, Urwid, Pyjamas, etc. It can be a good way to discover them and improve you skill, and I hope give them some contributions.

The help I need:

  • developers ! The project begin to be too big for me alone. In particular, I need people to port SàT on other architectures (*BSD, Android, Mac OS X, Windows, etc.). Only portable technologies have been used, so it should ask a reasonable amount of work.
  • tester: SàT should work with most browsers, most platforms, most XMPP server, etc.
  • Graphic designers: many things to do: icons, design, etc. Somebody just started to help me on this point, that means that the aspect should improve quickly.
  • CSS designers, Libervia should offer different kind of presentations
  • translators
  • donations: if the project succeed, would you make some donation ? Should I take some time to have a donation system ?
  • ...

If you are interested, the first thing is to subscribe the mailing list: . I hope to have around 10 peoples to start to use it seriously.


This post is only an overview of Salut à Toi, and I think the potential is very big. I strongly believe in the community, and I hope I have interested you enough to have a hand :)

I finish with two videos showing the project (the third one is linked above), but they are in French. Any help to make subtitle for them welcome.

This video is under Creative Common BY-SA

This video is under Creative Common BY-SA

mardi 3 mai 2011

RMLL (LSM): Notice to XMPP projects development teams

G'day everybody,

As you may know, Libre Software Meeting (Rencontres mondiales du logiciel libre or RMLL in french) will take place on next july (from 9 to 14) in Strasbourg. You can have a look at the official website:

We are planning to have a common stand for various projects around XMPP/Jabber, and I'm taking inventory of people interested.
To make organization easy, if you want to join us, please send me an email ( ) with the following template:

subject: [RMLL] Stand XMPP


First name *:

Last Name:


email address:

Phone number:


Project website*:


The * mean that the field will be public (put on the wiki).

The nickname is not mandatory, it's just to make link with you if you are on XMPP MUC or forums.

the [RMLL] in the subject is mandatory as messages are filtered.

I will add people as one goes along on the wiki:

Please note that I will always send a confirmation email (within 3 days), so please send me again an email if you have no confirmation and your name is not on the wiki.

Last but not least, if you haven't any project but you are interested in XMPP and want to be present on the stand, you are welcome (if the stand is not already too full)

You can contact me for any question on the email given above.