Hello, it's time for a summer progress note.

Libervia has seen a major UI revamp with a new theme based on Bulma CSS framework.

I've been hesitating for long to use a CSS framework, and the default theme has been home made with CSS classes following BEM naming convention. On the paper it's nice because you can easily extend it without breaking accidentally other components/pages, but in practice that was more work for a not so great result regarding the UI. It could become nice with time and efforts, but I'm desperately lacking time, and I rather put my efforts on other things.

So I've decided to work on theming and try the Bulma framework, on which I was keeping an eye for a little while. I was so far quite reluctant to use super popular CSS frameworks, because we tend to end with all websites looking the same, but I have to admit that using one save a LOT of time, and the result is clean and good looking with little effort.

Here is a screenshot of the forum page with the new theme:

Last time I've explained how I have implemented dynamic part of Libervia with Brython. This is now completed by the use of Nunjucks for dynamic templating. The goal is to have the same templates in the backend and in the browser, and Nunjucks is more or less compatible with Jinja2. I say "more or less" because some features, filters or extensions are missing. To work around that, I've implemented myself missing filters (xmlattr for instance), or a way to parse keyword arguments with Nunjucks convention. Nunjucks doesn't handle kwargs in macros so I've add to rewrite macros where it was used. The most tricky part was the use of i18n extension: Nunjucks doesn't have it, and thus it was failing when reaching a {% trans %} tag. I've had to implement an extension myself, but for now it doesn't translate and just returns the string unmodified.

Finally, it's working quite well, and the same templates can be used for static (backend) and dynamic (in browser) parts. This is particularly useful when you're doing a website which can be used without JavaScript, and which is enhanced when JavaScript is activated.

I've implemented server part of HTTP File Upload in the file sharing component included with SàT. This way you can see all files uploaded (with SàT or any other XMPP client) in your uploads directory, and you can delete them, which is something I was badly missing from current ecosystem.

Deletion is currently done using Ad-Hoc Commands, but I'm planning to move at some point to a PubSub based file sharing which would give all we need to manage correctly deletion or notifications. There is some work to do on the standards first, that's why I haven't done it from the beginning.

In addition to the ability to delete files, there is no upload limit with SàT file sharing component. Instead there will be a quota system (not implemented yet).

Some import mechanism should come soon, at least to import files uploaded on Prosody HTTP Upload, so the switch to SàT file sharing component will be easy.

I've put some efforts on the photo album, the goal is to have something simple and straightforward to use, working well on desktop or mobiles platforms, with or without touchscreen. There is a permission system to indicate who can view the pictures. From Libervia, pictures are currently uploaded with HTTP Upload (with some specific headers to indicate the path of the albums), until I have time to implement Jingle with WebRTC (maybe in next version?).

Here is a screenshot of the photo album with the new theme:

I'm currently putting my effort to make SàT/Libervia a good fit for sharing with family or close friends, little communities or small team. In other words a familial social network.

If everything goes well, I have good hopes to go beta in August and release 0.8 somewhere in September.

That's all for this note! As usual, feedbacks are welcome.

Hello everybody,

during the last few weeks, I've been focusing on Libervia (web): I've been working on the management of dynamism, or in other words the integration of JavaScript and browser side Python with the Libervia web framework.

If you're wondering what I mean by "browser side Python", let me explain briefly some history of Libervia: the former version of this web frontend was a single page application made with Pyjamas, a framework more a less similar to GWT but with Python instead of Java. The main reasons of this choice was to avoid constantly moving from 2 different programming platforms (Python and JavaScript), to factorise code with other frontends, and to avoid the JavaScript ecosystem which is constantly moving (resulting in lot of time spent in following the evolutions, learning new frameworks, rewriting code, etc.).

Pyjamas was made of 2 main parts: a Python to JavaScript transpiler, and a set of libraries to write a web site in a way similar to a desktop application. This was working reasonably well, and once past the initial big download, the application was working nicely. We could indeed factorise code with other frontends, and save time and maintenance efforts.

With time, we realised that hiding the abstraction of the web development to make it look like desktop was not so great: since the beginning of Libervia, the web ecosystem had improved greatly (HTML 5 and CSS things like flexbox notably), and it was getting hard to use the novelties. The application was not responsive and unusable on mobile, while phone was getting the main platform for many people.

In addition, 2 major issues were resulting in a dead end for Pyjamas: first a hijack of the project (not just hostile fork, but true hijack: the official website has been redirected to the fork named pyjs without the consent of the main contributor of Pyjamas, and the mailing list has been redirected without the consent of its subscribers), and second Pyjamas was stuck with Python 2, and a Python 3 port would mean a nearly full rewrite.

So we decided to move away, and the result was Libervia Pages, i.e. the framework made to integrate XMPP, Python, and web. For SàT 0.7 the first goal was to have a static or nearly static framework, with minimal JavaScript, and to implement dynamic part for 0.8.

The decision was to keep Python in the browser, for the same reason that initially lead to Pyjamas, but this time with the possibility to change the "engine", i.e. the software allowing to do Python in the browser. So we keep the door open to use only JavaScript if in the future we decide to move to something like Vue.js or React.

We have been carefully checking the various options, and our favorite candidates were Brython and Transcrypt.

Transcrypt is a Python to JavaScript transpiler, pretty similar to what was doing the transpiler of Pyjamas. It has the advantage of staying close to JavaScript, keeping its speed, and has a system to activate/deactivate Python compatibility features depending on the needs (better compatibility may mean lower performances).

Brython on the other hand is doing the transpilation in the browser, it is like having a Python interpreter in the browser. Its has some decisive (for us) advantages: full Python compatibility, and the possibility to dynamically convert Python to JS. The Python compatibility is essential to factorise the code with other frontends, and the ability to convert Python to JS open the way for future use (like sharing code during a chat, e.g. for a school or scientific use). I've been following the Brython community for years, it is really friendly and dynamic, and the few issues I've reported online were addressed quickly.

So Brython has been chosen as the main way to do dynamic code in the Libervia web framework, but it is possible to switch to something else. To use it, it is as simple as writing some Python in a __init__.py file in a _browser directory of a page ; Libervia will take care of installing Brython, copying and loading the script.

As an example, here is how you would show an alert if somebody click on an element with author class:

from browser import bind,alert

@bind(".author", "click")
def click(ev):
    alert("click on an author")

As we want to have dynamism used progressively (i.e. the page works without JavaScript, but enhancement happen if JavaScript is activated), it's really straightforward to work this way, while it is still possible to do more complex code for fully dynamic pages (like it will be the case for the chat).

Beside Python, JavaScript ecosystem been integrated through the use of either yarn or npm (whichever is present on the system). A common JSON file is used to indicate dependencies (using the syntax of package.json well known by frontend developers), and potentially how to generate corresponding Brython module. Sass has been integrated too.

I've also worked on themes, but I don't want to make this blog post too long to write and read, so I'll talk about that next time.

Hello, it's time for a new progress note.

attachments

As I've mentioned last time, I've continued the work on Cagou UX, with attachments. When you select a file to upload or send to your contact, it's not sent directly anymore, but appears in a "attachment" layout just above your message. This way, you can check that you'll send the right file to the right person (notably on touch screens, it could be easy to touch the wrong file).

When sharing large images, a "reduce image size" checkbox will appear, checked by default. I've chosen this way over automatic resizing, as a user may want to share HD images. Of course this behaviour may be adjusted in a future release, according to users feedback.

I've also worked on attachment on reception, images end-2-end encrypted (or e2ee) with OMEMO are now displayed instead of their links (it was already the case for non e2ee images), except if the contact is not your contact list (or "roster" in XMPP terms), in which case user has to click on the attachment (this is to avoid leaking your IP address to unknown people, as OMEMO encrypted images use HTTPS to retrieve the file).

There is now an integrated full-screen image viewer, where you can pinch or zoom the image. It's for now really basic, but I plan to add a menu to open the image in external editor, download it, or even doing basic edition.

When several images are linked in one message, a "collection" is shown : you see a grid of thumbnails of the first images, and clicking on it will open the editor, where all the images are in a carousel. Unfortunately, OMEMO Media Sharing, which is currently the only way to share e2ee files, allows only one file per message, so the collection is only usable with non encrypted images. This will be fixed thanks the recent work done by XMPP community on OMEMO : new version don't encrypt the body only anymore, this will open the way to a proper standard to share e2ee images, something to expect probably in the incoming months.

The menu to share a file has been reworked too, as you can see in the screenshot below. I've decided to let the 2 options to share a file : upload it, or direct transfer (which is P2P when possible). While upload is more user friendly, direct sending is more adapted when sending a large image to a single entity, and you may not want to let the file on your server (note that in some cases when P2P connection can't be established, the file may transit through your server).

There is a clear note indicating what will happen to the file (mainly telling if it goes to the server and if it is encrypted).

Dropping files is now handled on desktop, including dropping multiple files at once.

note: I've got feedback for my last note about the use of GIF images for screencast. I totally agree that's an issue : it's an outdated format, it's playing automatically which is annoying, it's heavy, not restoring all colors, etc. I've been using it so far because it's the only format which can be read without trouble everywhere (no thanks to some company with a fruit logo). I've got a pointer to ogv.js (thanks Link Mauve) which seems a reasonable solution used notably on Mediawiki websites, I plan to integrate it in Libervia, I just didn't got the time to do it for this note.

OMEMO

After attachments, I've moved back to OMEMO to improve UX. Now if you have an unencrypted session and somebody is writing to you using encryption, the encryption will be started automatically on your side too, so there is no risk anymore to accidentally answer without activating e2ee.

I've not yet implemented e2e encryption by default for several reasons:

• not all XMPP clients manage OMEMO (Movim doesn't for instance), and activating OMEMO or any other algorithm by default would exclude them

• there is already mandatory encryption by default with XMPP (between client and server, and between servers), it's just not end-2-end, but still your message are not traveling in clear text on the network

• current de facto OMEMO standard, what I'll call now "OMEMO legacy" (see below), has plenty of issues, and notably it encrypts only the body, i.e. the plain text payload of the message. This prevent the use of many useful XMPP extensions.

• authentication is a mess, fingerprints validation is often hidden or not used at all, which makes e2ee interest arguable. This situation is not specific to XMPP, it's really hard to make authentication user friendly, and most e2ee capable chat clients just hide it. In other words, without authenticating properly all your contacts devices (by a secured external channel, like being face to face), end-2-end encryption is only useful against so-called "passive" attacks on your server and your addressees servers, that means that it protects against an administrator only looking at the logs or archive without actively trying to spy on you. With active attacks, adding a fake device is enough to ruin the purpose of e2ee.

That doesn't mean that I wont do it at a later point. After the great work done by the XMPP community on OMEMO:1, I may switch to e2ee encryption by default once the novelties are implemented.

In Cagou, following what can be seen on other clients, I've added a lock to indicate if a message was encrypted or not. If you receive an unencrypted message in an encrypted session, the lock will not only be open, but will also appear in red, as this situation should not happen.

I've implemented Blind Trust Before Verification (BTBV) trust policy in SàT. BTBV has been introduced by Conversations, and as its name states it trusts by default any new device, until a manual verification is done (QR Code scanning is not implemented yet in Cagou, but it's on the TODO list). This improves a lot user experience, while letting open the option of a more secure workflow.

Automatically trusted devices are indicated in the trust UI (the panel shown when you manually trust a device), as well as an option to restore BTBV behaviour for this contact.

note that this UI should be improved in future versions, with QR Code, colors, etc.

OMEMO legacy vs omemo:1

a couple of weeks ago, part of the XMPP community met in Germany to work on fixing OMEMO issues. Currently, most clients implement a de-facto "OMEMO" standard which has been done as a first draft many years ago and has many majors flaws (only the body is encrypted, dependency on libsignal, list of devices saved in a single pubsub item, etc.).

This resulted in new versions of XEP-0384, and the situation is far better now. Notably, the inclusion of Stanza Content Encryption is a game changer.

This new version has a new namespace urn:xmpp:omemo:1, that's why there is a distinction betweek omemo legacy and omemo:1. We can most probably expect a major adoption of omemo:1 before the end of the year.

You may want to check the nice blog post of vanitasvitae for more details.

Sprint

Finally, I've been participating to Berlin Sprint. While it was initially an in-person meeting, due to the pandemic situation that you're all aware of it has been converted to an online one. This has been a nice occasion to block the same time spot for several members of the XMPP community, and thanks to the precious help of Syndace (author of the python-omemo library used in SàT) a nasty bug has been fixed.

I've also made a lightning talk to quickly show SàT ecosystem.

Despite the difficult situation, Berlin sprint has been well organised and flexible enough to adapt, big thanks to organisers and participants.

now

That's it for this long note. Now I'm working on improving avatars handling, and then I plan to finally move to web dev with Libervia.

Hello everybody,

it's been a while since the last progress note, that's because I have very little free time at the moment, and I use it to code instead of writing blog posts.

So I'll try to summarize the last weeks progress without going too much into details.

Continuing my work on improving Cagou usability, I've added a panel which shows open chat rooms, all your contacts, and bookmarks. It was necessary to have a way to select easily a contact or room, as so far you had to enter part of the name and count on autocompletion. So now, by default you land into a screen showing you icons of contacts/rooms, and you just have to click on them.

In chat mode with Cagou, you can slide between open discussions without having to go back and forth in the menu. The order in which you do the slide correspond to the order in which icons appears in the "chat selection" panel. They are sorted by alphabetical order for the moment, but it will be easy to add other way to sort, for instance by time of last received message.

I've added a notification counter, so you know immediately where somebody has talked to you.

For now the icons are arranged in a grid, but it may be possible to add other layouts in the future, like showing the chats entities in a list (which would give more room to display extra data like the last message).

On Android, opening a system notification for a chat message now opens the right chat widget in Cagou.

I've also improved session reopening: when the frontend is closed on Android, the last connected profile will be reconnected automatically, as well as the last selected mode. This was also the occasion to implement profile auto connection on backend startup, which is particularly useful for components.

I had to fix SRV records handling on Android: this platform doesn't use /etc/resolv.conf which Twisted expects, and finding the DNS servers used is not trivial. Thanks to some hints I've found (notably here), I could implement a decent solution to work around that and make SRV records looking work.

On desktop, I've removed the main top menu, as it is redundant with features available elsewhere. Instead there is a new "extra" button in mode selector, which open a side menu (this is how you open the "about" screen for instance).

There have been also a bunch of improvements like logging the path of parsed config file(s), the implementation of a stable resource instead of the one given by server (something like sat.[ID]), the handling of runtime permissions on Android, a better management of header's input in Cagou, many bug fixes, etc. I won't enumerate everything, this note is to have a global overview of the work done or in progress, the direction taken, and the reasons behind some decisions.

I'm currently finishing the handling of file attachments in chats, I will then move on Libervia.

That's all for today.

Hello and Happy New Year, this is the first progress note of the year.

Last weeks have seen work on OMEMO, and SàT has now a full OMEMO implementation (one2one, files with aesgcm scheme, and MUC encryption). One2one e2e OMEMO encryption was already available since 0.7, and I've talked about file encryption last time. The work on MUC has been quite straightforward, it was basically about handling the workflow differently (checking that we have a room JID and not a user JID, checking that we can retrieve real JIDs from Room, and retrieving room occupant JIDs). On Cagou, I've added the encryption button, and I've had to filter encryption algorithms available for MUC (where OTR is excluded, while it's available for one2one chat).

Once trying on Android, I've realised that OMEMO was not working as expected. After investigation I've found the issues (bad version and the Protobuf Python binding was not installed correctly), and I've proposed 2 small fixes to python-for-android's omemo and protobuff_cpp recipes, which are now merged upstream.

Once that working, I've decided to work a bit on Cagou usability. On Android, there is now a notification sound in addition to the vibration (you can activate/deactivate them in settings).

I've refactored the way platform specific behaviours are handled, and this is used, among other things, to manage URIs opening. Thanks to that, I can now handle the geo: URI scheme in a platform specific way: while by default it's opened in browser, on Android it's opening the application picking menu, so you can display the location in your map/navigation application.
That's pretty neat as you can now, using a map/navigation application + Android data sharing mechanism, send or get a location with SàT (and this may be end to end encrypted).

Continuing with Cagou UX improvements, I've added a small red "plug" icon when the user is not connected to the server. I was not sure how I can show that a user is disconnected without surcharging the interface, and I've found this solution acceptable (the icon is visible only when you're disconnected).

Now I'm working on chat room selection, i.e. how to open a chat room in Cagou.

Hello everybody,

it's time for an update on last weeks work.
As announced last time, the infinite scroll is now implemented in Cagou. It was a real usability issue to not be able to go back in history, so I'm quite happy to have it now.

Finding the right way and the right parameters to have smooth infinite scroll was not trivial: user can scroll quickly to the top, the scroll effect may still be running after use interaction (if you scroll with finger and let the screen, the scroll bar will have a inertia effect and continue to move for a little while), and you don't want that your history "jump" all of a sudden because new messages have been added.
By default, a "bump" effect is shown when you reach beginning or end of scrolling zone, which I've finally removed as it doesn't make much sense with infinite scroll.

The result is quite OK on desktop, but I have a bug on Android which make the scroll bar go to the bottom when new messages are prepended. I'll check that later.

I've also adjusted the delayed resizing for chat history (cf last note) to avoid an unpleasant flickering when a new message is sent/received.

To stay with Kivy, they have an infrastructure for community extensions called "garden", and they used to have a non standard home-made package management for that. That was really annoying for installation (Cagou is using 2 garden "flowers"), and fortunately they changed the infrastructure recently to use Python standard package manager (pip). The 2 "flowers" I'm using were not moved to the new architecture, so I did it following the online guide, with the help of Kivy team. Kivy team is really nice, helpful, and usually answering quickly; that's really important when you want to contribute.
To summarize, the 2 Kivy community extensions used by SàT are now installable like any other Python dependency, via pip/PyPI, that makes Cagou simpler to install.

The rest has been mostly about e2e encryption with OMEMO. I've updated the plugin which was not working anymore since Python 3, and updated version of python-omemo. The author of this lib, Syndace, is also really friendly and reactive, and he's on SàT room, that makes it handy to coordinate our code bases. Thanks to that we have discussed the possibility to reset trust for a device to undecided (the default state when a new device is seen), and he added the required method.

I've also fixed trust management in SàT, to handle correctly undecided and untrusted devices.

Last but not least I've implemented AES GCM encryption (the aesgcm:// scheme that you may have seen in URL with other clients), also known as OMEMO Media Sharing even if it's not directly related to OMEMO. This is not an official standard (it was proposed but rejected by XSF Council, for good reasons), but that's the only way we have at the moment to encrypt a file with OMEMO, so it's a must-have for now.

This was the occasion to use for the first time the async/await syntax in the backend. There was already a coroutine syntax in Twisted that SàT is using for years (inlineCallbacks), but the new syntax is part of Python language, is more pleasant to use, and allows some welcomed simplifications.
Thanks to the great work of Twisted team, it's super easy to mix Twisted Deferred, inlineCallbacks, and async/await code, so I can migrate the code progressively.

With that, SàT has now a complete OMEMO implementation for one2one chat. Group chat is not yet done, but I expect to do it quickly.

As usual, those features are usable from command-line with jp. You can upload a file and encrypt it with AES GCM with:

jp file upload -P --encrypt some_file.ext

(the-P is to have a progress bar)

This will give you an aesgcm:// URL

And to download from the other end:

jp file get -P "aesgcm://…"

The doc has been updated and can be seen at https://salut-a-toi.org/documentation/sat

It's time for a new progress note.

In last one I was talking about my attempt to optimize the chat history with Cagou on Android. Indeed, while scrolling through history is smooth on desktop, it's quite slow on Android (but not dramatic).

My plan was to use RecycleView, which is an optimized widget to show a big list of widgets.

But, as I've explained last time, RecycleView has troubles with widgets with dynamic height (which is the case for chat messages, height depends of content). While working on a workaround (the idea was to pre-render each widget without displaying them, and use the calculated size), I've realized that even RecycleView was not so smooth on Android, and that was complicating a lot the code.

So I took the (hard) decision to abandon this idea, it was taking too much time without perspective of good results. Sometimes it's a good thing to step back and save time for other things.

Instead, I've simplified a bit other parts of the code, and thanks to a blog post on Kivy website that I've read recently, I've used the idea of a delayed resize (the message history is complex to resize because there are many elements – messages with styling, images, avatars, nickname, timestamp, receipt flags, etc. –), meaning that when you resize the window or the messages widgets, the resize is not done immediately, but only after a short delay (replacing any previously delayed resize). This way you limit the number of size calculations, and the feeling is better.

Still there is room to improve perfs for chat history scrolling on Android, but that can wait, it's usable enough for now.

I've come across a ticket for python-for-android predicting a hard future on Android: background tasks are more and more difficult to run. I'm not sure how it will evolve and what will be the consequences for SàT, we'll see.

Still on the Kivy side, I've realized that a bug that I had on Android (issue when sliding chat widget with the Carousel) was fixed in dev version. As I have no idea when next version of Kivy will be released and I had to fix this issue immediately, I've done a backport of the dev version of Carousel in Cagou, which I'll remove as soon as the Kivy 2.0 is available.

I've moved to Python 3.8, and I've had to face a couple of troubles.

Twisted, which is a major component of the backend, is not yet Python 3.8 compatible. Fortunately, the issue and fix were easy, so I've reported the issue and proposed a fix.

It is not super pleasant to propose a fix to Twisted because you have to look into the doc (which is rather indigestible), create the ticket on their bugtracker – with a terrible UI – but with a Github account (I have one for contributions only, but I'm don't like to be forced to have it), do the fix, write a test – with a not so pleasant "Believe me, if you write your tests after you write your code, we will know. It's more obvious than you think." making you feel like a little pupil at school –, write a piece of text to generate the changelog automatically, and finally update the ticket to ask for review (then we'll follow usual change request/review until the patch get merged, rejected or abandoned).

On the bright side, the Twisted community is nice, and I have to admit that the code quality of Twisted is really good thanks to their test-driven development (and general competence of people working on it). I'm using Twisted since the beginning of SàT (without any regret so far), and I really love the stability of its API, and that I'm rarely crossing the way of a blocking bug. I just have the feeling that it could be more contributors friendly.

For the same reason as for Kivy, I've backported the patch to sat_tmp to be able to use SàT and SàT PubSub with Python 3.8.

Now I'm working on infinite scroll on Cagou. It is functional but not yet smooth.

That's all for this progress note, as usual feedbacks are welcome.

Hello,

once again I've skipped last week progress note, as there was not much to say and I don't think it worth writing something just to write something, so in the future I'll publish a note every week when it worth it, and may skip one or 2 weeks in case of low activity or if I'm continuing a long task.

During the last 2 weeks I've been focusing on Cagou on Android. The 0.7 version is a proof of concept and give a idea of the potential, but it's not good enough to use as a daily client; I'll try to fix this for 0.8 version.

Cagou is now windowed on Android and not fullscreen by default anymore. It was initially fullscreen to gain some space, but at the end it's not a good idea as it hides many useful informations from the user. I still plan to add a fullscreen mode in some cases (when seeing photo albums for instance).

I've added Cagou to the share menu of Android, so it can now be used to share any content, be it some text data, or an image/file. That's one of the important things which was missing, and it's pretty cool to see it when sharing something on the phone.

When possible, a preview of the data is shown (works only for text or images at the moment), and then you just have to touch the name of the contact to who the file/data to. Below is screenshot of image sharing.

The share widget is not polished yet, it's a first draft. I've tried to keep the design simple, and the option to resize the image is only shown if the image is too big, in which case it is activated by default.
It will be possible to use the same widget on desktop, I just need to do the integration with the various APIs.

I'm now working on improving the performances for chat history. So far, all the messages were put in a BoxLayout. It's working, but it keeps all widgets in memory and this is now optimized for something which may become big like a chat history. On desktop this it is fine, but on Android it is quite noticeable that scrolling the chat history is slow.

A recent Kivy widget is usable to improve that: RecycleView. This RecycleView only calculates what is necessary to show the widgets actually displayed on the screen, this is far more efficient and we can expect a good performance boost by using that. So I've started to move the history to RecycleView, but I've run into problems for which I've created Kivy issues (#6580 and #6582). I expect that it will takes some time before those tickets are handled and fixed, I'm trying to work around those problems for now.

I have some test code but it's not fine yet. Once that done, I'll implement the loading of more history when we are at the top of the chat (either with an infinite scroll or a button).

There are a couple of other improvements that I would like to do before releasing 0.8 to make Cagou good to use on Android, but let's talk about them in a future progress note.

Last but not least, jnanar, the maintainer of SàT packages on Arch Linux, has just say that the dev versions of SàT and Cagou (the new Python 3 version) are now working (but not Libervia yet), and that tests/feebacks are welcome. Thanks to him for maintaining those packages!

Hello,

a short progress note this week, I've mainly been working on building the Cagou Android apk with Python 3, so I've did the last bit of Python 3 porting. The port went well, thanks to the great tools done by the python-for-android, and I could remove some Android specific hacks. More important, there was a nasty bugs with Python 2 on the open method which is gone, and some crashes disappeared (notably when changing orientation). Cagou is considerably more stable on Android.

I'm now working on usability, as there are a couple of small things missing which make the overall experience painful.

I need to add a way to go back in history in chat widgets (I'm not sure yet if I'll go with an infinite scroll or if I'll add a button for a user action), and a summary widget with last active chats would be nice. I'm also looking to add Cagou in the share menu (it would be nice to do that on desktop too). Also the back button should have better behaviour, and go up to a home widget (either the future summary widget, or the widgets selector).

The welcome screen (where we select a profile/create an account) is not user friendly yet, I'm not sure if I'll work on this this week, but it's on my short term TODO list.

So I'm working on Cagou and Android at the moment. I have also some stuff planned for Libervia, we'll see next week how it went.

Hi everybody,

I've skipped the progress notes for a couples of weeks because I've been working on the same thing for a long time (writing documentation for jp + porting it to asyncio), it was making no sense to repeat this every week, and also because I've been seriously lacking time lastly due to events in my private life.

This week I've had absolutely no time to work on SàT, I could only update the instance running https://www.goffi.org and https://salut-a-toi.org to the dev version (i.e. on Python 3). One visible change is the performance boost when using tickets: retrieving tickets and building the page was previously taking ages, and the issue has been found and fixed.

Let's summarize some of the changes I've done while being silent on the blog:

• jp, The CLI frontend of SàT is now fully documented. That means that all the commands (107 commands so far!) are explained with examples; you can check the rendered doc at https://salut-a-toi.org/documentation. This was the most time consuming task during the last weeks, really boring to do, but necessary. I hope it will help people to use the full potential of this tool.

• also jp is now using asyncio, and some issues preventing to use an other bridge than D-Bus have been fixed. In other words, you can now use a bridge like pb (Twisted's Perspective Broker) instead of dbus. This has been requested by people using jp on servers where installing D-Bus was not desired, pb being natively supported by Twisted and then SàT, it's working without any extra dependencies (but D-Bus is still the default and recommanded bridge in most cases).

• Many more or less small improvments have been done to jp and SàT during this process. Some commands options have been updated.

• There are now 2 themes for jp, for light or dark background. You can specify the background using background option in [jp] section of sat.conf. Before that, jp was barely readable on light background. I still need to do something similar for Primitivus.

• If not specified, jp will automatically detect the background colour of the terminal where it runs. I've discovered that it was possible to do that thanks to a ticket I've randomly found reported for vim and neovim: there is an ANSI escape code returning the RGB value of background colour on compatible terminal, this is really useful.

• A long awaited feature: jp is now prompting for profile password if it is needed and not specified in arguments. This is better for security as the password is not visible anymore on the screen, in your shell history, or in your processes lists.

• Thanks to TLS fixes in latest Twisted version (19.7.0), I could remove the code working around the issues. Twisted required minimal version is now 19.7.0.

• last but not least, I've fixed an issues during launch of SàT backend, Libervia, and SàT Pubsub which could result in ReactorAlreadyInstalledError when they were all installed in the same Python environment.

That's it. With the new documentation and some usability fixes like background detection, I think jp is now very usable, and I hope people will give it a try. It's a tool particularly useful when working a lot in terminal (to send or upload a file for instance), or if you want to do scripting with XMPP. XMPP server admins could use it to, for instance, send service messages using ad-hoc command (see examples in documentation), and XMPP dev could use it to inspect PubSub services.

There are several options for next big features in SàT, I'm currently thinking about implementing video calls as I need it, but I may well also work on other tasks first (like improving file sharing).