Agregador de noticias

Monal IM: New Mac beta up

Planet Jabber - 16 January, 2018 - 19:50

There is a new beta of the Mac client with all of the recent  fixes and addition of group messaging.  I know there are still a few issues, for example it doesn’t save the password for auto joining a bookmarked group. Im curious to see what other issues people encounter. Its been working ok for me the last couple of days as I’ve been using it to lurk on the XMPP developers group chats.

Paul Schaub: Smack: Some busy nights

Planet Jabber - 16 January, 2018 - 13:11

Hello everyone!

This weekend I stayed up late almost every evening. Thus I decided that I wanted to code something, but I wasn’t sure what, so I took a look at the list of published XEPs to maybe find something that is easy to implement, but missing from Smack.

I found that XEP-0394: Message Markup was missing from Smacks list of supported extensions, so I began to code. The next day I finished my work and created Smack#194. One or two nights later I again stayed up late and decided to take another look for an unimplemented XEP. I settled on XEP-0382: Spoiler Messages  this time, which was really easy to implement (apart from the one little attribute, which for whatever reason I struggled to parse until I found a solution). The result of that night is Smack#195.

So if you find yourself laying awake one night with no chance to sleep, just look out for an easy to do task on your favourite free software project. I’m sure this will help you sleep better once the task is done.

Happy Hacking!

Monal IM: The new group chat UI

Planet Jabber - 16 January, 2018 - 05:29

I’m getting closer to the UI that I would like for group chats. It might not be the greatest thing for power users but I suspect it will work well for most people. Especially those familiar with iMessage or other chat clients already.   Things to note in the picture below, proper nick name support and subjects. I’ve decided to treat the subject like the group name.  I’ve observed that in other chat clients people like to change the group name on a whim mid conversation.  This is not something the muc spec supports as far as I can tell. People  can however change the subject, so subject it shall be.

Monal IM: Mac has group chat

Planet Jabber - 12 January, 2018 - 19:52

The Mac client has always had group chat but didn’t have a UI surfacing the functionality. I am adding that now.  I know favorites and auto join have long been asked for. I hope to have that in the iOS client as well. 

ProcessOne: ejabberd 18.01

Planet Jabber - 12 January, 2018 - 11:29

ejabberd 18.01 is a bugfix release. This version of ejabberd Community Server is a good candidate for Linux distributions packaging as it concludes a year of development and stabilised all recent changes for production use.

  • Fix TLS driver memory management
  • Fix privacy_set command
  • Report ‘fs’ support as unavailable on SunOS
  • Let mod_block_strangers bounce an error when a message is rejected

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

Paul Schaub: Reworking smack-omemo

Planet Jabber - 10 January, 2018 - 16:36

A bit over a year ago I started working on smack-omemo as part of my bachelor thesis. Looking back at the past year, I can say there could have hardly been a better topic for my thesis. Working with Smack brought me deep into the XMPP world, got me in contact with a lot of cool people and taught me a lot. Especially the past Google Summer of Code improved my skills substantially. During said event, I took a break from working on smack-omemo, while focussing on a Jingle implementation instead. After the 3 months were over, I dedicated my time to smack-omemo again and realized, that there were some points that needed improvements.

One major issue was, that my “OmemoStore” class, which is responsible for storing keys, sessions, etc. was not having access to the users data before the user logged in. The reason for that is, that my implementation allows multiple OMEMO instances to be running on the same connection. That requires the OmemoStore to store keys for multiple instances (devices), which I distinguished based on the Jid and deviceId of the user. The problem here is, that the Jid is unknown before the user logged in (they might use a burner jid for example, or use an authentication system with username and password which differ from the jid).

While this is an edgecase, it lead to issues. I implemented a workaround for that problem (using the username instead of BareJid in case the connection is not authenticated), which caused numerous problems.

I thought about replacing the Jid as an identifier with something else, but nothing was suitable, so I started a major rework of the implementation as a whole. One important aspect I wanted to preserve is that smack-omemo should still be somewhat usable even when the connection is not authenticated (ie. the user should still be able to scan qr codes and make trust decisions).

The result of my work (so far) is a diff of “+6,300 −5,361″, and a modified API (sorry to all those who already use smack-omemo :O). One major change is, that the OmemoStore no longer stores trust decisions. Instead those decisions are now made by the client itself, who must implement a OmemoTrustCallback. That way trust decisions can be made while the OmemoManager is offline. Everything else what remained in the OmemoStore is only needed when the connection is authenticated and messages are received.

Furthermore I got rid of the OmemoSession class. Session handling is done in libsignal already, so why would I want to have a session related class as well (especially since libsignal doesn’t give you any feedback about what happens with the session, so you have to keep sessions in sync manually)? I recommend everyone who wants to implement OMEMO themselves not to create a “OmemoSession” class and instead rely on libsignals session management.

OMEMO sessions are somewhat brittle. You can never know, whether a recipient received your message, or if it failed to decrypt for some reason. There is no signalling to provide feedback about the sessions state. Because of the fact that even message encryption can go wrong, the old API was very ugly. Originally I first checked, whether there are devices which still need a trust decision to be made and threw an exception if that was the case. Then I tried to build sessions for devices without session and threw an exception when session negotiation failed. Then I tried to encrypt the message for all recipients and threw an exception if something went wrong… Oh and the exception I threw when sessions could not be negotiated contained a list of all devices with intact sessions, so the user could retry to encrypt the message, only for all devices which had a session.


The new API is much cleaner. I still throw an exception when there are undecided devices, but otherwise I always return an OmemoMessage object. That object has a map of OmemoDevices for which message encryption failed, alongside the respective exceptions, so the client can check if and what went wrong.

Also sessions are now “completed” whenever a preKeyMessage arrives.
Prior to this change it could happen, that two senders chose the same PreKey from a bundle in order to create a session. That could cause on of both session to break which lead to message loss. Now whenever smack-omemo receives a preKeyMessage, it instantly responds with an empty message to make the session stable.
This was proposed by Philipp Hörist.

Other changes include a new OmemoStore implementation, the CachingOmemoStore, which can either wrap other OmemoStores to provide a caching layer, or can be used standalone as an ephemeral store for testing purposes.

Also the integration tests were improved and are much simpler and more readable now.

All in all the code got much cleaner now and I hope that at some point it will be audited to find all the bugs I oversaw (everyone who wants to take a look for themselves, the code can currently be found at Smacks Repository. I’m always thankful for any types of feedback)

I hope this changes will make it to Smack 4.2.3, even though here are still some things I have to do, but all in all I’m already pretty satisfied with how smack-omemo turned out so far.

Happy Hacking!

Monal IM: Monal OSX 2 beta 7 out

Planet Jabber - 10 January, 2018 - 00:19

OSX Beta 7 has been pushed  out. This version support making and receiving Jingle calls.  I have also added Monal to brew. You can now do this:

brew cask install monal


ProcessOne: ejabberd 2017 year in review

Planet Jabber - 9 January, 2018 - 11:56

This was an amazing year for ejabberd! With almost regular monthly updates, tons of new features and improvements, we worked hard to make ejabberd the best XMPP server available. Let’s take a look at the past year, and let us wish you a Happy New Year!

January – 17.01

We started last year with a cleanup. Most notably, we introduced SSL in PostgreSQL connections and improved database migration.

March – 17.03

This release introduced dynamic configuration reload, to ease ejabberd administration and management. To ease end users’ life, we created mod_block_strangers to significantly reduce XMPP spam.

April – 17.04

One of the most significant features of 2017 was introduced in April: Redis and SQL backends can now be used to store RAM tables, just like Mnesia.

May – GSoC

In May, ejabberd was yet again accepted to Google Summer of Code ’17. With two projects, Support for “Let’s Encrypt” ACME protocol and Server-to-Server stream management support it was looking like a super-interesting summer.

June – 17.06

Another significant ejabberd update happend in the middle of 2017. This time, we introduced a handy Certificate Manager, new caching system and the highly demanded Riak support.

August – 17.08

At the end of summer we produced another ejabberd release that improved the XEP-0357: Push Notifications support, as well as made it easier to configure a cluster backend – although only for Mnesia, for now.

September – 17.09

This was a busy month for ProcessOne. The result of the two ejabberd GSoC projects was very satisfying, both for us and the participants. Additionally, this month’s ejabberd release introduced a new, much better avatar module, implemented XEP-0368, and updated OpenSSL libraries in our installer.

November – 17.11

Happy Birthday ejabberd! It’s been 15 years :) Apart from the celebrations, this month we introduced “Let’s Encrypt” ACME support created during ejabberd GSoC, and implemented much demanded PubSub improvements.

December – 17.12

With the end of this amazing year for ejabberd, we were happy to announce a major XMPP/PubSub project migration to ejabberd server. And with another successful ejabberd release, we introduced SNI for inbound connections, and improved support for PubSub v1.14 and OMEMO.


2017 was an amazing year for ejabberd, but we are not stopping there! Looking forward, we are happy to announce that ejabberd is compatible with XEP-0387: XMPP Compliance Suites 2018 as well as passes the Conversations Compliance Suite.

We have many new features and improvements lined up for this year. Look forward to our next release! To stay tuned, be sure to follow us on Twitter, Facebook, or subscribe to ejabberd newsletter.

Monal IM: Mac Jingle Voice Calls Work

Planet Jabber - 9 January, 2018 - 01:30

Tested out jingle voice calls on the Mac today.  There is a call button on the toolbar but you can’t initiate calls quite yet. You can however, accept a call, talk and hang up.  Monal is the bare bones ui with the hang up button :).  Try it out with the beta that is currently available. 

Monal IM: Revisiting Muc

Planet Jabber - 8 January, 2018 - 17:00

Muc aka Group Chat has been something that’s been in Monal since the beginning.   I’ve decided to throw out all the old  UI for this and remake it.   The old version was something I wrote before I had very many users and based on my experience using pidgin/adium/gaim. It doesn’t work anywhere near as nice as I would like it to. Also given the greater importance of group conversations these days, I have decided make it a top level item.   There isn’t a lot of room for things on the tab bar at the bottom.  I think this is what the current four will be.  

Monal IM: iOS Voip works again and logs

Planet Jabber - 8 January, 2018 - 01:39

Fixing the issues with Jingle Voip was a high priority this week.  The iOS client audio  should not have issues anymore.  I was testing this with pidgin (and wire shark) in a linux VM until I discovered Jitsi, which is a nice client in it’s own right.  I will likely test Voip with this going forward.

Continuing on to the next stop of the  refactoring train, I looked at some persistent bugs with the chat logs. It seems  I hadn’t made changes to that code since 2014.  It helps that Boston is experiencing record breaking cold right now, there isn’t a lot of motivation to go out.

The settings screen now has a chat logs option. It works like the old screens but with out the (null) entries.



Tigase Blog: IoT over XMPP

Planet Jabber - 7 January, 2018 - 01:56

Just over a year ago, Tigase presented a talk about IoT over XMPP at FOSDEM 2017. Our idea was to use an XMPP server as a go-between the user and the controlled device, eliminating direct access to devices from the internet.

Tigase Blog: IoT over XMPP

Planet Jabber - 7 January, 2018 - 01:56

Just over a year ago, Tigase presented a talk about IoT over XMPP at FOSDEM 2017. Our idea was to use an XMPP server as a go-between the user and the controlled device, eliminating direct access to devices from the internet.

Monal IM: Jingle all the way

Planet Jabber - 5 January, 2018 - 23:23

I’ve revisited of the jingle code that appears to have broken in the last couple of years. While I was at it I added jingle support to the Mac for audio calls.  I still need to write the audio code for OSX but the signaling component is all exactly the same as iOS. 


Fanout Blog: The Edge is Nothing Without the Fog

Planet Jabber - 4 January, 2018 - 14:40

Edge computing is hot right now. The growing maturity of IoT networks ranging from industrial to VR applications means that there’s an enormous amount of discussion around moving from the cloud to the edge (from us as well). But edge computing is only the first step.


Peter Saint-Andre: Scales and Modes and Tetrachords, Oh My!

Planet Jabber - 3 January, 2018 - 00:00
In preparation for recording my arrangements of music by Yes for solo electric bass, I've started taking music lessons with Mark Stefaniw, a fine bassist in the Denver area. Under Mark's tutelage I've been digging into music theory, which is both fascinating and enlightening (especially given my many years of musical learning at the surface)....

Arnaud Joset: Errol: XMPP Automatic file sender

Planet Jabber - 1 January, 2018 - 13:00

Errol is a file sender that rely on inotify. It can be used to watch a directory and automatically transfers the new files (or modified ones) with XMPP.

The origins

Errol find its origin in tasks I am doing for a small association, "Les compagnons du CEP", a joint buying organization who sells wines. I manage their ERP, the excellent Odoo. One of these tasks is the generation of their price list from an Excel spreadsheet (yeah, I know). I designed this process with a LaTeX generator written in python because I am fluent with it since 10 years. As I did not want to install a LaTeX distribution on the production server, the logical decision was to delocalize this task on another machine. The user uploads his excel file on a webpage, the file is saved in a "watched" directory and its transfer is triggered on the second machine with XMPP. The generation of the latex document and its compilation is performed with LaTeX and the resulting PDF is sent back to the server. The PDF is therefore available for download.

Why Errol?

In the fictional universe of Harry Potter, Errol is the Weasley family's owl. It is quite old and awkward. One could says the same about XMPP but Errol is quite useful, XMPP is too :-). Errol is a great grey owl. (see pictures)

Photo credit:, Great Grey Owl

Howto Prerequisites

Errol needs the following requirements:

  • A system supporting inotify (Linux).
  • an XMPP (jabber) account supporting the following XEPs: Stream Management, Publish-Subscribe, Multi-User Chat
  • A PubSub service where the nodes can be set as open. The node name is defined in the configuration file. I personally use sat_pubsub. A PubSub component developed for the project Salut à Toi.
  • A Multi-User Chat because not all XMPP accounts support PubSub. For now, some information are still shared through MUC messages. This behavior could change in the future.
  • The latest (dev) version of Slixmpp.

You can use your own XMPP server or choose a XMPP service among the following list.

Create the PubSub node

This step is optional if you already have a write access on the pubsub node. The following example use jp, the Salut à  Toi command-line interface but slixmpp or sleekxmpp can be used.

$ jp pubsub node create -f publish_model open be.agayon.errol:0 -s -c

The node name be.agayon.errol:0 is recommended in order to identify the functionality.

As an example, there are the node options on the service

$ jp pubsub node info be.agayon.errol:0 -s persist_items: True deliver_payloads: True serial_ids: False publish_model: open access_model: open send_last_published_item: on_sub

If your server supports Personal Eventing Protocol(PEP) or if you do not want to use the generic PubSub service of your server, you can use your jid.

$ jp pubsub node create -f publish_model open be.agayon.errol:0 -s -c Tests

You can test your setup with the examples scripts of slixmpp.


./ -j -p pass -r -f /path/to/file.txt

See the scripts for more information.

Getting started with Errol

First you need to clone the repository. Errol needs the following dependencies:


You can easily install errol with pip:

$ pip install errol

Note: errol can be installed in a virtualenv.

You can also clone the git repository:

$ git clone $ cd errol $ python3 install

On Archlinux:

A PKGBUILD will be available soon. Configuration

You need to provide information about the XMPP account.

$ cat config.example.ini [XMPP] node=be.agayon.errol:0 password=pass ressource_receiver=-receiver ressource_sender=- nick_sender=example_sender nick_receiver=example_receiver
  • jid : the jabber account
  • password: the xmpp password
  • pubsub: the PubSub server (publish activity)
  • room: the MUC (chatroom) where errol display information.

The files will be sent by and received by . The nicks are the usernames used on the MUC.


Photo credit: Wisconsin Department of Natural Resources, Great Grey Owl at Mauston

Once installed, Errol can be launched in a terminal.

$ errol --help usage: errol [-h] [-e EVENTS] [-f FILE] [-d] -p PATH -c COMMAND Automatic XMPP file sender and directory watcher optional arguments: -h, --help show this help message and exit -e EVENTS, --events EVENTS Number of events to watch (delete, create modify) in the directory. Once reached, the program stops. -f FILE, --file FILE Config file containing XMPP parameters -d, --debug set logging to DEBUG -p PATH, --path PATH The path watched. -c COMMAND, --command COMMAND The executed command: xmpp or watcher In Hogwarts

If you want to watch the directory /tmp/sender, the following command can be used:

$ errol -f config.example.ini -p /tmp/sender -c watcher

All modified or new files created in the watched location will be sent by XMPP.

In Azkaban

If you want to receive the files, you have to launch Errol with the following command line.

$ errol -f config.example.ini -p /tmp/receiver -c xmpp

All the received files will be stored in the directory defined with the option '-p'.


This project is licensed under the GPLv3 - see the LICENSE.txt file for details

Why not X or Y?

Photo credit: Bernard Spragg. NZ, Great Grey Owl (Strix nebulosa)

There are plenty solutions for this kind of needs. Some of them are more mature. I choose XMPP for several reasons:

  • already provides a up-to-date XMPP server with all the needed XEPs enabled.
  • I do not want to open additional port on the client that performs the LaTeX compilation.
  • I wanted to learn to work with XMPP for machine to machine communications and use PubSub notifications (because why not?).

Among the alternatives, I could have build the service on top of:

  • sockets
  • HTTP file transfer
  • SSH and remote commands.
  • rsync
  • ...

Photo credit: lasta29, Great grey owl, Osaka Tennoji Zoo

  • The french XMPP community (availaible on,, ...)
  • The Slixmpp maintainers Florent Le Coz, Mathieu Pasquet for their nice library.
  • Emmanuel Gil Peyrot (Link mauve) for its reactivity.
  • Goffi from the Salut à Toi project for his explanations and his disponibility.

Monal IM: Notifications Screen

Planet Jabber - 31 December, 2017 - 18:56

Push notifications have a lot of moving parts. To help people figure out where things may not be working (and to make sure everything is enabled), there is a new push notifications screen.

Jérôme Poisson: XMPP based tickets and merge requests with SàT

Planet Jabber - 30 December, 2017 - 18:01

Lot of work has been done in the past months, letting little time to talk about the novelties. Let's have a look at the most recent one.

For Salut à Toi development, we don't want to use proprietary or centralized software and we use Mercurial, so we have been reluctant to use current popular platforms. With the recent improvments of our SàT pubsub component (see, and of Libervia, our web frontend, it became clear that our old idea of using XMPP and SàT to handle tickets became close at hand, so we did it.

SàT is now able to handle tickets on top of XMPP, using Pubsub. There are many advantages

  • it's decentralized and federated, no need to have X accounts to use X tickets handlers. You can also import tickets from third party projects (e.g. plugins for your project) into your website.
  • it's standard: we can handle or fetch tickets in third party servers easily, without proprietary API.
  • it's very flexible: any field can be used, and the mechanism can be used for any list (bug tracker, TODO list, shopping list, etc.)
  • being based on SàT, it's usable on any platform
  • it can be used with gateways, allowing to use transparently tickets from other services (think about Gitlab or Github for instance)

The working is based on pubsub with an experimental addition: node schema which allows to specify a form (using data forms) which will be enforced on each item. This way tickets published by third party clients can be checked and validated. Pubsub offers permission mechanisms allowing to have public or private collections of tickets (nodes in pubsub terms). Comments are using the microblog (which really should have been called blog) feature of XMPP.

But that's not all! On top of that an other feature has been implemented: merge requests. The idea is to have a way to propose contributions in a agnostic way, meaning this can be used with Mercurial, Git, or potentially any tool. Once again we enjoy decentralisation here, and we can have contributions between people on different servers.

Below is a small video showing an example of merge request. We use jp (SàT's CLI frontend) to send a modification to a server. By default, the backend will try all registered merge requests handlers until it find one which can manage the given repository. There is a small wrapper around the command to do basic operations (notabily creating the data to export), the data and metadata are then formatted and send to the pubsub node. For now, only Mercurial is implemented, but git will definitely follow, and maybe a simple diff based handler for basic cases.

Your browser can't manage the "video" tag, you should update it, e.g. with the last Firefox >

Note : if you want to do a merge request for Salut à Toi on, you'll have to use the service with

jp merge-request set -p

Of course the feature is new and it's quite rough: it is not yet possible to specify which lines of a patch we comment, or to use rich formatting. This will of course come soon, but if you want to have it faster, well, merge requests are welcome ;)

You can see it on our bug tracker.

For people in Paris, I'll be at Paris Open Source Summit (booth A2, "Salut à Toi") on Wednesday and Thursday. If you want to support the project, we are on Liberapay.

See you soon for an other post on SàT novelties…

Jérôme Poisson: Tickets et « merge-requests » basés sur XMPP avec SàT

Planet Jabber - 30 December, 2017 - 17:10

Beaucoup de travail a été effectué lors des derniers mois, me laissant peu de temps pour parler des nouveautés. Jetons un coup d'œil à la dernière.

Pour le développement de Salut à Toi nous ne voulons pas utiliser de logiciels propriétaires ou centralisés et nous utilisons Mercurial, aussi nous avons jusqu'ici été réfractaires à utiliser les plateformes actuellement à la mode. Avec les améliorations récentes de notre composant SàT Pubsub (vous pouvez lire – en anglais – l'article de jnanar pour plus d'infos), et de Libervia, notre interface web, il est devenu clair que notre vieille idée d'utiliser XMPP et SàT pour gérer les tickets était à portée de main, nous l'avons donc fait.

SàT est maintenant capable de gérer les tickets via XMPP, en utilisant pubsub. Il a de nombreux avantages à cela :

  • c'est décentralisé et fédéré, pas besoin de X comptes pour utiliser X gestionnaires de tickets. Vous pouvez également importer des tickets de projets tiers (par exemple des greffons pour votre projet) dans votre propre site web.
  • c'est standard : il est possible de retrouver ou gérer des tickets sur un serveur extérieur facilement, sans API propriétaire.
  • c'est extrêmement souple : n'importe quel champ peut être utilisé, et le mécanisme peut être utilisé pour toute liste (rapports de bogues, choses à faire, liste de courses, etc.).
  • étant basé sur SàT, c'est multi-plateformes
  • on peut utiliser des passerelles, pour par exemple intégrer de manière transparente les tickets d'autres services (par exemple Gitlab ou Github)

Le fonctionnement est basé sur pubsub avec une extension expérimentale (non standard pour le moment): les schémas de nœud qui permettent de spécifier une mise en forme des données (en utilisant les « data forms » qui devra être respectée pour chaque élément (chaque ticket). De cette façon, les tickets publiés par des clients tiers peuvent être vérifiés et validés. Pubsub a également un système de permissions qui permet d'avoir des collections de tickets publiques ou privées (des nœuds dans la terminologie pubsub). Les commentaires utilisent l'extension microblogage de XMPP (qui aurait plutôt dû s'appeler « blog »).

Mais ça n'est pas tout ! Une autre fonctionnalité a été implémentée par-dessus ça : les requêtes de merges (« merges requests »). L'idée ici et d'avoir un moyen de proposer des modifications/améliorations à un projet sans être lié à un outil particulier, c'est-à-dire que l'on peut les utiliser avec Mercurial, Git ou potentiellement n'importe quel outil. Encore une fois, nous profitons de la décentralisation, et nous pouvons avoir des collaborations/contributions en personnes sur des serveurs différents.

Ci-dessous vous avez une petite vidéo (en anglais) qui montre les requêtes de merge. On utilise jp (l'interface CLI de SàT) pour envoyer les modifications à un serveur. Par défaut, le serveur va essayer tous les gestionnaires de « merge requests » jusqu'à ce qu'il trouve lequel peut gérer le dépôt demandé. Il y a une petite couche autour des commandes pour faire les opérations de base (en particulier créer les données à exporter), puis les données et métadonnées sont mises en forme et envoyées sur le nœud pubsub. Pour le moment, seul Mercurial est implémenté, mais Git va bien entendu suivre, et peut-être un gestionnaire de base utilisant un diff pour les cas les plus simples.

votre navigateur ne gère pas les vidéos, vous devriez mettre à jour par exemple avec le dernier Firefox

Note : si vous voulez faire une « merge request » pour Salut à Toi sur, il vous faudra préciser le service avec

jp merge-request set -p

Bien sûr, la fonctionnalité est nouvelle et encore basique : il n'est pas encore possible de préciser les lignes du code auxquelles un commentaire se réfère, ou d'utiliser une mise en forme riche. Cela va bien sûr venir plus ou moins vite, mais si vous voulez accélérer les choses, eh bien, les « merge requests » sont les bienvenues ;).

Vous pouvez le voir en œuvre sur le gestionnaires de tickets de SàT

Pour celles et ceux qui sont à Paris, je serais au « Paris Open Source Summit » (POSS) demain et jeudi (au stand A2, « Salut à Toi »). Si vous voulez aider le projet, nous sommes sur Liberapay.

Bientôt d'autres billets sur les nouveautés dans SàT…

Distribuir contenido