SàT progress note 2019-W51

goffi 20/12/2019, 18:43 jabber-xmpp-en SàT project libre SàT progress

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

E

edhelas 20/12/2019, 21:04

debacle 21/12/2019, 18:58

SàT progress note 2019-W48

goffi 28/11/2019, 21:43 jabber-xmpp-en SàT project libre SàT progress

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.

debacle 29/11/2019, 16:48

SàT progress note 2019-W44

goffi 03/11/2019, 20:24 jabber-xmpp-en SàT project libre SàT progress

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.

screenshot of share widget first draft

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!

E

errormovim 16/11/2019, 16:09

SàT progress note 2019-W42

goffi 20/10/2019, 15:36 jabber-xmpp-en SàT project libre SàT progress

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.

E

edhelas 20/10/2019, 15:40

debacle 20/10/2019, 21:57

E

errormovim 16/11/2019, 16:09

SàT progress note 2019-W41

goffi 10/10/2019, 12:05 jabber-xmpp-en SàT project libre SàT progress

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).

debacle 10/10/2019, 14:03

E

errormovim 14/10/2019, 21:04

SàT progress note 2019-W35

goffi 30/08/2019, 10:13 jabber-xmpp-en SàT project libre SàT progress

Hi everybody,

I've skipped last week note because I could not find the time, and anyway I did the same thing as this week, so it was not really needed.

I'm currently working on porting jp (the CLI frontend) to Python's asyncio, and at the same time I'm documenting every command (I need to review them one by one, so it's a good occasion for that). It's long and really boring, but it's a good thing to do.

Let me explain why I'm doing that. SàT and its frontends are historically using D-Bus to communicate (it's an IPC, and we call it internally the bridge). SàT is 10 years old, and the Python implementation that we have used was the reference at the time : Python D-Bus. This implementation has flaws, that they recognise themselves (like trying to guess signature, see " Problems and alternatives " in the page linked). Furthermore, it's the main reason why we use GLib and its loop in SàT, which can cause trouble to install (mainly due to compilation).

Frontends and bridges are using a callbacks mechanism, which can be hard to code and maintain in some cases. Python-dbus can work with callbacks or in a blocking way, and historically we have used this feature in jp. For instance, to get backend version we have a getVersion() method, and to avoid too much callbacks hell, it was used with the bridge in a blocking way (blocking jp is not such a big deal as there is no UI to maintain or things which must run in background). This was wrong and experience shows why, you are either blocking or asynchronous, not a mix. Using D-Bus bridge in a blocking way, even if it's only in a few places, makes the code unusable with other bridges, so jp could only work with D-Bus, and today we have other ones (like Twisted Perspective Broker which is the bridge used on Android).

So in one hand we had the callback issue, and on the other hand some bridge calls using blocking mode to limit callbacks hell, and causing design issues.

The proper solution to that is to use coroutines, which is a way to write asynchronous code nearly like we write blocking code. Twisted has been offering this possibility for years thanks to the inlineCallbacks which is using Python generators in a smart way. It's really usable and indeed used in many parts of the backend: you basically have to use a decorator and yield syntax.
This could have been used in jp but this would have forced the use of Twisted (and we want jp to work with other frameworks if other bridges are used). Furthermore, inlineCallbacks are not easy to debug: in a debugger if you don't add a breakpoint just after the yield, a step over brings you in the execution workflow of the main loop.

And here come asyncio and the great async/await syntax. This syntax is doing basically the same thing as Twisted inlineCallbacks, but in a cleaner and more readable way, in locations where yield is not possible (in a loop for instance), and it is nowadays well handled by debuggers (at least pudb that I'm using). Thanks to that, it is possible to convert easily blocking parts of the code, and to simplify many things.

Doing something like repeating a method on several pages of result (when RSM is used for instance) becomes easy and pleasant. One of the main goal of asyncio was to have a common loop/framework for all asynchronous code, and Twisted made the compatibility layer so we can use Twisted and asyncio at the same time with async/await syntax.

I'm currently finishing that, for the moment I'm keeping 2 versions of the bridge (one callbacks based and one using async/await) to progressively do the conversion, but the goal is to have all frontends using the new syntax soon. It is one of the many things that has been unlocked by the port to Python 3. It's taking lot of time because of the documentation made at the same time, but it is definitely worth it.

That's all for this note, see you next week.

E

errormovim 07/10/2019, 22:43

SàT PubSub 0.3.0 has been released

goffi 21/08/2019, 18:12 jabber-xmpp-en SàT project libre release

SàT Pubsub is a server independent PEP/PubSub XMPP service, which aims to be complete and universal.

This project was born due to the fact that it is difficult to have feature-full PEP/PubSub on every XMPP servers, and even if it is the case there can be huge delays before seeing new functionalities implementation, or they can be difficult to extend.

The "Salut à Toi" project being using extensively XMPP PubSub functionalities, there was 2 ways to work around the issue:

  • to concentrate on a particular XMPP server, to recommend it, and if possible make it evolve in the wanted direction.
    This would mean being blocked on a specific XMPP server implementation and taking the risk to have incorrectly working (or not working at all) functionalities on other servers

  • create a server independent component, by using XMPP extensions to have a privileged access to server

The latter option has been retained, SàT PubSub uses XEPs (XMPP extensions) Namespace Delegation (XEP-0355) and Privileged Entity (XEP-0356) to be able to offer advanced features and PEP.

Beside the use of "SàT" in the name (which is due to its origins), you don't need to install or use Salut à Toi with this component, and it can be used by any XMPP compatible software.

SàT PubSub was already implementing MAM and RSM (allowing to do searches in archives and to use paginations to retrieve new items), the 0.3.0 version also brings:

  • the presence access model
  • +notify handling
  • notion of administrators, which are identifiers ("JID") with privileges
  • affiliations
  • the possibility to find items sorted by creation or modification date, thanks to Order-By (XEP-0413)
  • the "Node Schema" experimental feature, to associate data types to a node using Data Forms (XEP-0004). This feature is notably used by Salut à Toi for tickets
  • the "Serial IDs" experimental feature, which set new items identifiers using increments (1, 2, 3, etc.) instead of random values. This is notably useful for tickets.
  • the "PubSub Admin" experimental feature, which let administrators publish items by specifying an other publisher. This can be used to restore nodes backups.
  • the "consistent publisher" experimental feature which, once activated in node settings, keep the original publisher when an item is updated by the node owner or an administrator. This permit to update an item without preventing the original publisher do modify it himself or herself (for instance while editing a blog comment or updating a ticket status).
  • a config file can now be used with SàT PubSub, avoiding to have to specify settings – including the password – entirely on the command line. The same file as for Salut à Toi (sat.conf) is used, the settings for SàT PubSub must be set in the [pubsub] section.
  • a new documentation

You'll find more details in the CHANGELOG.

Version 0.4 development has already begun with a working Python 3 port, completing the port of the whole Salut à Toi ecosystem.

To install SàT PubSub, you just have to enter pip install sat_pubsub in a Python 2 virtual environment, check documentation for more details.

E

errormovim 07/10/2019, 22:43

O

oipioi 05/10/2021, 06:54

no me hace efecto cialis <a href=https://cialisklad.com/>organic cialis</a>

O

oipibow 15/10/2021, 17:51

cialis discount prices <a href=https://buyedcialis.com/>cialis 10mg buy online india</a>

SàT PubSub 0.3.0 est disponible

goffi 21/08/2019, 07:00 jabber-xmpp SàT SàT Pubsub project libre release planet-libre

La version 0.3.0 de SàT Pubsub est disponible.

SàT PubSub est un service XMPP PEP/PubSub indépendant du serveur, qui vise à être complet et universel.

Ce projet est né du constat qu'il est difficile d'avoir des services PEP/PubSub complets sur tous les serveurs XMPP, et que même si c'est le cas ils peuvent tarder à implémenter de nouvelles fonctionnalités ou être difficiles à gérer.

Le projet « Salut à Toi » faisant un usage intensif des fonctionnalités PubSub de XMPP, 2 solutions étaient envisageables :

  • se concentrer sur un serveur XMPP particulier et le recommander, voire le faire évoluer dans la direction voulue. Ceci reviendrait à se bloquer sur une implémentation particulière d'un serveur XMPP et risquer de voir des fonctionnalités fonctionner incorrectement ou pas du tout sur les autres.

  • faire un composant indépendant du serveur, en utilisant des extensions XMPP pour avoir un accès privilégié au serveur

C'est la deuxième option qui a été retenue, SàT PubSub utilise les XEPs (extensions XMPP) Namespace Delegation (XEP-0355) et Privileged Entity (XEP-0356) pour pouvoir fournir des fonctionnalités avancés et PEP.

Bien que « SàT » soit utilisé dans le nom (par son origine), ce composant ne nécessite pas d'utiliser Salut à Toi et peut-être utilisé par tout logiciel XMPP.

SàT PubSub implémentait déjà MAM et RSM (permettant de faire des recherches dans les archives et d'utiliser la pagination pour retrouver les éléments), la version 0.3.0 apporte également :

  • le modèle d'accès presence
  • la gestion de +notify
  • la notion d'administrateurs, qui sont des identifiants (« JID ») avec des accès privilégiés
  • les affiliations
  • la possibilité de retrouver les éléments classés par date de création ou modification avec Order-By (XEP-0413)
  • la fonctionnalité expérimentale « Node Schema », pour associer des types de données à un nœud via les Data Forms (XEP-0004). Cette fonctionnalité est notamment utilisée dans Salut à Toi pour les tickets.
  • la fonctionnalité expérimentale « Serial IDs » qui permet d'attribuer des identifiants d'éléments utilisant des incréments (1, 2, 3, etc.) au lieu de valeurs aléatoires. Ceci est notamment utile pour les tickets.
  • la fonctionnalité expérimentale « PubSub Admin », qui permet aux administrateurs de publier des éléments en spécifiant un autre éditeur (« publisher »). Peut-être utilisé pour restaurer une sauvegarde.
  • la fonctionnalité expérimentale « consistent publisher » qui, une fois activée sur un nœud, garde l'éditeur (« publisher ») original quand un élément est modifié par le propriétaire du nœud ou un administrateur. Ceci permet de modifier l'élément sans empêcher l'éditeur original de le modifier à nouveau lui-même (par exemple en éditant un commentaire de blog, ou en changeant le statut d'un ticket).
  • un fichier de configuration peut désormais être utilisé avec SàT PubSub, évitant d'avoir à spécifier les options – dont le mot de passe – entièrement sur la ligne de commande. Le même fichier que pour Salut à Toi (sat.conf) est utilisé, les options de SàT PubSub doivent être mises dans la section [pubsub]).
  • une nouvelle documentation

Vous trouverez plus de détails dans le CHANGELOG.

Le développement sur la version 0.4 a déjà commencé avec le port pour Python 3 qui est fonctionnel et complète le reste de l'écosystème Salut à Toi.

Pour installer SàT PubSub, il vous suffit d'entrer pip install sat_pubsub dans un environement virtuel Python 2, référez-vous à la documentation pour plus de détails.

E

errormovim 07/10/2019, 22:43

SàT progress note 2019-W33

goffi 18/08/2019, 19:22 jabber-xmpp-en SàT project libre SàT progress

Hi there,

after the release I've got some vacations and I've made a break, that's why I've skipped the last few weeks progress notes, but now I'm back.

The release was a big thing, after 3 years of developments, and many new exiting stuff to show (Cagou, which is also running on Android, the advanced file sharing, photo albums, events, etc.), it is also the first "general audience" version, meaning that it's the first one which is usable for everybody, not only people with technical background. Even if there is still work to do on UX and stability, we're on the right track.

The Android version of Cagou is not stable yet, but there are several things which were not fixable easily under Python 2 (there is notably a bug on file opening with Python for Android which is not reproducible on Python 3). I hope to have feedbacks to make next version really enjoyable.

I was really happy to finally do this release, and now I can move forward and in particular do the Python 3 port.

During my holidays I've spend some time doing the first steps of the port (just a few hours here and there), and I could quite quickly get the backend and frontends running. Once back, this week, I've reviewed it and done some polishing before committing, and I'm happy to say that the development version of the backend and all the frontends now run on Python 3. Some features are still not working, but most things are here and running.

This unlock many things, and I'm very looking forward to used them : asyncio with async/await syntax, Brython, Transcrypt, and many libraries which are Python 3 only.

Thanks to better error handling, I could also already fix some issues not seen with Python 2, and we can already appreciate a performance boost (specially visible with tickets).

Once that done, I've released SàT Pubsub 0.3.0 (a release note will come soon about this), and started the developments of 0.4.0 with… Python 3 port : dev version of SàT Pubsub is now also running on Python 3. That means that all SàT ecosystem is now Python 3 only.

Beside that, I've also made 3 pull requests to see Cagou, Primitivus and jp on Flathub, but there are some modifications to do there before they can be merged.

That's all, see you next week.

E

errormovim 07/10/2019, 22:43

Salut à Toi v0.7 « La Commune »

goffi 24/07/2019, 22:50 jabber-xmpp-en SàT libre project release

Salut to you!

It is with a big pleasure and a sort of relief that I announce you the release of "Salut à Toi" v0.7.0 (La Commune).

To remind you "Salut à Toi" (or SàT) is an ecosystem of decentralised communication, based on "XMPP" established standard.
It features many functionalities (instant chatting, file sharing, blogging/microblogging, events organisation, forums, etc.) and has the particularity of being multi-interfaced (different "frontends" are available for the web, desktop, mobile devices or even the terminal and command line).

The preparation of this version has taken 3 years. This is the first version we can call "general audience", in other words it is approachable also by those without technical background . Though, there are still some improvements to be done in the frontend and "user experience" level.

I shall not enumerate again all the functionalities with screenshots, you can consult the announcement of the alpha version to do so by yourself. I'd rather explain some major updates, which has been done:

Cagou, the desktop/mobile interface

As promised by our modest crowdfunding, Cagou is the name of the new desktop/mobile frontend (Android only at this moment). To share a little story with you, it is a reference to a beautiful bird, which does not fly, but barks, and is endemically present on the no less beautiful island of New-Caledonia. It is also a nod to Kivy, the framework we are using and from which the name and logo may remind you of Kiwi of New-Zeland.

So, this interface is multi-platforms, not focusing only on instant messaging: you can use it for file-sharing (e.g. the videos/photos between your computer and phone), or as a remote-control for your media player. It is of course planned that it will be able to cope with blogging in the close future.

Cagou is thought to be usable on a little screen, as well in full-screen mode of desktop, and allows the screen division into zones - to, for instance, follow several discussions at the same time.

On android, the application has still some problems with the reactivity and bugs time to time. Lot of problems will be corrected by with Python 3 port. Consider this version as the first one to have you commentaries et propositions.

Cagou sur Android

End-to-end encryption

Of course, SàT has been featuring end-to-end encryption for several years already through "OTR", however this version witnesses the arrival of "OMEMO", an algorithm correcting the issues of previous one (specially allowing sending of offline encrypted messages, or to display them on multi-devices). OMEMO is implemented only for simple conversation ("1:1", between 2 people) at the moment, but the next version will surely cope with end-to-end-encrypted conversations within groups.

Events, photo-albums, forums, ticket-handling, merge-requests

Numerous new functionalities has appeared in this version. You can now create and manage events (e.g. for the family) with the classic list of invited persons et the replies of type "RSVP" (attending, not attending, maybe attending). It is possible to invite people, even though they don't have XMPP account - using the "invitation" accounts which are automatically generated and sent to their emails.

You can create and share the photo albums, a specialisation of file-sharing. The possibility to create one is not yet available from graphic interface, however, this is planned to be improved soon. To consult the photos is simple from Libervia (web interface).

The forum is also in the party, as well as the tickets handling and merge requests. These two last functionalities have been implemented for the project needs, but they are very flexible and can be (in the next version) easily used in a everyday life (e.g. as a shopping lists, to do lists etc.)

All of this take profit from XMPP "PubSub" capabilities, and can benefit of its permission system (we can imagine the shopping list being shared between the family members indicating who bought what).

Remark - to actually benefit from all this it is necessary to use the "SàT Pubsub" service, the project made for the needs of Salut à Toi (but which can be used by all XMPP based programs)

un blog sur Libervia

album photo sur Libervia

Web Framework

The development of Libervia, the web frontend of SàT, has evolved to make it become a web framework. The reason of this evolution is the need of a very flexible interface, one which would allow implementation and testing of new ideas and functionalities easily. The goal is to have a naturally decentralised and federative framework (thanks to XMPP), which integrates simply to the ecosystem. I will speak only briefly about the technical details, but the point is to join Jinja2 with SàT and use PubSub as the database. Also CLI frontend (jp) allows to use the same models to make a static rendering (for instance to generate a static blog or chat archives).

It is with this framework that these above mentioned features were developed, they are organised in "pages" which are supposed to be simple to use and can work without JavaScript (when possible, it is not the case for the chat). The new official website works thanks to the new framework, you'll find there an introductory documentation.

Even More

I won't get too much into details as the updates are too numerous, but though it it worth mentioning that SàT can be also used to store your folders on the server (it can be used as a "component"), or jp, the command line frontend allows manage a lot of things (find or publish an article or blog, send encrypted or non-encrypted message, find someone's avatar, etc.)

Installation

Salut à Toi is available on Debian and its derivates, but attention! It is only the case for the backend, the console interface and the command line. By the way, a help to make the Cagou package land there too would be much appreciated.

It is also available on the Arch Linux's AUR repository, and you'll also find there the development versions.

The Flatpak packages allows the easy installation of Cagou, Primitivus (terminal) and jp (command line) on most of GNU/Linux distributions, you can find the links on the main page of the site.
You can of course, use as well pip, the Python packages manager. A simple pip2 install --user sat followed by pip2 install --user cagou and pip2 install --user libervia should be enough. The instructions are available in the site's documentations.

For Android, you can find a APK on this link (unsigned, a definitive version will follow in a couple of days). After the release, I will make steps to make it available on F-Droid, and eventually the "play store".

Even though SàT should technically be working on Mac OS X, Windows and *BSD, however on these platforms it is not yet tested (as I do not have any of this devices). I have had some feed-backs concerning Mac use. If you are interested, help with testing and packaging would be nice.

Future

The principal planned development of 0.8 is the port to Python 3, which is now finally possible, as no more dependency is blocking, and it is the only thing promised for the next version. Lot of big steps are to follow, and it will be inevitable to make some choices. Don't hesitate to give me opinions/feedback in the commentaries.

Video conference

With Jingle already implemented, the video conference has been planned for a long time. It shouldn't be too difficult to be implement it into the web interface (thanks to WebRTC), but certainly would need a lot of work on desktop/Android (to evaluate different options, GSTreamer is the hot candidate at the moment, and integrate with Cagou). This is an important work.

Improving the file sharing

SàT already allows advanced file sharing (more than a simple sending of the files to the server), including a server component. It is very possible, that the future developments will continue in this direction.

share a directory with Cagou

iOS Version

It would be technically possible to use Cagou on iPhone. Though, there are several obstacles to cope with - especially the legal ones (Apple store is not compatible with the current licence, AGPL 3+). Lot of time and investments would be needed. This is clearly not the priority, but keep in mind that an iOS version is doable.

ActivityPub Gateway

With this version, SàT can be used as a "component", i.e. a server service. This possibility can be used to build an ActivityPub gateway, that would allow 2 ways communication with projects using this protocol. There is already somebody working on a similar gateway for Prosody, , so I will certainly wait to see how it evolves before starting it by myself.

Chat Evolution

Though its already functional, the chat can become very complete if we take the time for it. Here, we speak of adding some missing features (like reactions or editing of the last sent message), improving the file handling, copy/pasting of code, end-to-end group encryption, etc.
All this is on the roadmap, the question is whether this is a priority or not.

Improvement of User Experience

This is probably the project which will have the priority, once Python 3 port is done. SàT has already lot of features, but the interfaces need some work to become really user-friendly. I would specially like to work on launch screen and contacts discovery. There are as well lots of "small details " which all together take lots of time, but in total make the user-experience much more pleasant: integration to desktop, file-sharing actions, easier file selection, etc.

Well, so much for the future steps, all of this would take time, but again - your feedbacks are highly welcomed. There are other ideas to think about, but one has to choose her priorities.

But…

Salut à Toi is an huge project with a potential - and it is currently developed by a single person. I have currently only one day a week dedicated to SàT (besides mornings, evenings and nights), the rhythm is very difficult to cope with. In the next months I will seriously study the projects financing possibilities. It will be necessary that I find a way to keep the project on track.

Useful Links

  • official website: https://salut-a-toi.org
  • documentation: https://salut-a-toi.org/documentation
  • my blog: https://www.goffi.org (I publish there weekly progress notes)
E

edhelas 24/07/2019, 23:00

debacle 30/07/2019, 12:41