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.

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.

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.

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)

Hello,

remember last week when I was mentioning external things that I've put on hold? There was a Twisted ticket that I've opened months ago, I've made a pull request for that, but there was still some changes to do according to review.

Unfortunately, between my paid job, work on SàT, and real life things I haven't had the time to update it, and little after sending my last week note, I've got an email notification about the ticket being fixed (with a patch replacing mine). I was feeling a bit bad to let this for months and not finding the time to update it myself (in 8 months). Fortunately Twisted folks are nice and understand well ("No need to apologize. We're all volunteers here :)"), and it's a good thing that they managed to fix this issue.

I'm telling this because people don't always understand why things take time (why the release it taking so long? Why nobody did review my merge request?), or may be forgotten. It's just that people can be really really busy, and in free software communities, many of them work on their free time.

During this week, again, it was debugging: really useful for the project, but not so much to tell or explain. The blocker list is getting really low, and I feel fairly optimistic that release can be done next week.

There is maybe one issue I've come through that may worth a mention : while the new chat page of Libervia was working fine during my tests on localhost, it was not working at all once deployed. This is a really simple chat for now, just a proof of concept before adding advanced feature in next version. Libervia pages which come with the new web framework are currently mostly static (i.e. there is no advanced javascript to handle complex changes, this will come in next version), and the chat works by establishing a websocket with the pages, and just sending new messages to display. The web framework is supposed to make life of developer easier, and you only have to declare a dynamic = True variable to activate the websocket. In the background, Libervia create the websocket, associate the page with it, and also the request which is an object containing many useful data, including the session with the profile of the user.

While investigating, I've realised that the issue was happening only in HTTPS, so it was not visible while working on http://localhost. Happily, I'm now working mostly in HTTPS even during local development, this make the detection of this kind of issues easier. I've been using mkcert which makes the process of adding personal certificate painless, and thanks to it I can work easily in HTTPS on my own private and local domain.

This led to an issue with the request object I was storing. This Twisted object is not made to be stored this way, but I was doing it to keep the useful data it contains. Once the HTTP GET request used to retrieve the chat page is finished, the channel is closed, and it is used to test if the request is secure or not (the Twisted session is not stored in the same object or using the same cookie if the request is secured or not). As a result I was getting an empty session, like if the user was not connected, and the chat could not work. I could easily work around this issue, and I've reworked this in a cleaner way; it's working fine now.

The release is not totally ready yet, but I'm already thinking about what's coming next (beside Python 3 port), and there are several big options in my mind, it will be important to choose carefully the priorities. I'll probably focus soon on user experience (UX), as current UI (specially for Cagou), is not that intuitive and accessible for newcomers. I'll write more about this for the release note (which may replace next week progress note).

Hello,

this week note will be short, first because I've mainly fixed bugs, second because I've pain in my wrist and it's not comfortable to write.

The most visible part of this week work is the addition of some installation instructions on the front page of https://salut-a-toi.org, which render like this:

capture of installation icons from https://salut-a-toi.org

(this is a screenshot, this image is not clickage, check https://salut-a-toi.org to see the real clickable version)

Thanks to the work explained in previous notes, we're getting closer to an easy installation in a few clicks. We're not exactly there yet though, as Flatpak still needs to be installed in most distributions (I think, I don't know exactly where it's installed by default), Libervia (web frontend) is not installed this way (but I'll update the Docker image at some point which is also easy to install/run), and there are maybe other tweaks to do (for instance on Android you must activate the installation from external sources). Please note than when SàT is available natively in the distribution, it's the recommended way to install it.

Also the many ways to install + different frontends/versions (and I've not put yet Libervia + packages for others platforms like Windows or Mac OS) may be confusing. Maybe a platform detection could help to highlight the most probable package in the future.

Another thing which can cause trouble with SàT specific architecture is the backend: for Flatpak I've made a wrapper to launch it automatically if it's not already, otherwise the running backend is used. It works but there is a risk of troubles when the package will be updated and the running backend version may be older than the expected one. I'll have to modify the backend to check that at some point (probably in 0.8).

An other necessary improvement for 0.8 will be the login screen: for now it's really confusing for somebody not used to XMPP (you have to create a profile with a jid and a password, then click on it, then you land to widget selector). I have several ideas on how to change that, but I'll work on it only after release and python 3 port.

That's all for this week note, as I've said in the first paragraph I've mainly done debugging which is not really interesting to explain here. I'm a bit annoyed to lack the time to do more, as I've put aside some external things that I need to finish: I have 2 XEPs to update, and a pull request for Twisted that I've opened months ago and I need to update too. I haven't had much time either to follow standard mailing list, which is a pity because some really interesting things are happening there like the long awaited full stanza encryption.

I hope to be able to fix enough bugs in the incoming week to finally release the 0.7, I'm looking forward for it, and I'm sorry that the release will happen during the summer when many people will be on holidays (well I'm happy for people being on holidays, it's just that it's not the best time to have the release being noticed).

Hello everybody,

I was targeting end of June for the release, it seems that I'll have to postpone: it's not ready yet, there are still a couple of annoying bugs. That's a really boring part from a developer point of view, you have to take care of polishing, and things around the code (like the website, documentation or packaging), and you don't see your project evolving much. It's far more exciting to work on new features or experiments, but you need to go through polishing if you want something usable.

I've been talking about Flatpak last week, I still had to do some work on it.

After getting working packages for Cagou, Primitivus and Jp, I've created a repository for that (https://salut-a-toi.org/flatpak/sat-repo) and the flatpakref files which are metadata telling where to find and how to install the packages. I was happy to finally have a simple way to install Cagou so people could test it and give feedback, so I've sent a short notice on Diaspora and ActivityPub. I've indeed quickly got feeback reporting the outdated runtime (1.6 while 18.8 is now available, I've just missed it while working with my Manifest from last year), then I had to update the package again.

Once again, feedback has been useful (thanks JBB), so please if you see something buggy or you would like to see something (new feature or anything), let me know!

During my own test I realised that the MIME type for the flatpak refs files was wrong too (it was text/html so the browser was displaying them instead of downloading them). That was a bad default value used in Libervia, and it's now fixed.

After updating the runtime, testing it successfully without installation (using flatpak-builder --run build-dir org.gimp.GIMP.json sat_wrapper) and uploading it, I've had the bad surprise to realise that python2 was missing when trying to run the package normally. It is actually available in the SDK so it was working while testing with flatpak-builder, but not anymore in the runtime (which make sense as Python 2 support will be stopped next year, but still SàT is using it and will move to Python 3 for 0.8 release). So I had to compile Python 2 myself, and make several try to make it work correctly (and that's only after it worked that I have discovered that there was a pre-made module offered by Flatpak teams).

All of that to get this thing:

Cagou flatpak package seen on KDE Discover

Integration in the package manager (here Discover from KDE) is nice to have, and I hope that it will be the case by default in most distributions in some time. I'll propose the package on Flathub (the central repository of Flatpak) once the stable release is out.

There are still some little issues on the package/metadata (like the screenshot which are not at the recommended 16:9 format), but I'll take care of them later, I have already spent enough time there and I need to move forward. Furthermore, the screenshots seem to be displayed correctly beside their format on KDE Discover and GNOME Software.

Far more serious, there are some crashes on the Flatpak version of Cagou (I've had a infinite recursion crash when clicking on bookmarks) that I don't have on normal packages, so I have to debug that but that's part of the general debugging phase I'm now in.

To install dev preview packages of Cagou, Primitivus or Jp from Flatpak, just enter the following commands:

  • flatpak install --user https://salut-a-toi.org/flatpak/org.salutatoi.Cagou_dev.flatpakref
  • flatpak install --user https://salut-a-toi.org/flatpak/org.salutatoi.Primitivus_dev.flatpakref
  • flatpak install --user https://salut-a-toi.org/flatpak/org.salutatoi.Jp_dev.flatpakref

And later to update them:

  • flatpak update

Or use your graphical software manager. I'll add the links to the website soon, so it should be installable in a few clicks.

Remember that it's dev version, so expect bugs, and in addition there are still some issues specific to the Flatpak version that I'll try to fix today.

That's really a lot of time spent on those packages, but I now have scripts which will help to updates everything easily. Imagine if I had to do all packages myself for every GNU/Linux distributions + Docker + Flatpak + AppImage + Snap + YunoHost + Android + *BSD + Windows + Mac OS + … . I'm already doing several on this list, but I can't do everything alone, so if you feel you can help on packaging, please contact me (see address at the bottom of https://salut-a-toi.org or join us in our official room at sat@chat.jabberfr.org or via web). Note that there are already people working on Arch packages and on Debian and derivatives (but they need help).

So now it's all about debugging and documentation until the release.

Hello everybody, time for a new progress note.

This week I've been working with Flatpak. Flatpak is a new way to package applications using containerization, which has pros and cons: for a low overhead the applications can be run on most GNU/Linux distributions, they run in the same reproducible environment, and they have limited access to outside. I prefer using software packaged in my distribution when they're available (better integration, no overhead at all), but Flatpak is a nice way to try quickly something or to have access to software not packaged in our distribution.

About SàT, the main goal is to have super simple installation so people can try Cagou (desktop/mobile interface) easily. I'm also working on packages for other frontends mainly jp (CLI) and Primitivus (TUI), so they can be tested quickly. I hope this can encourage people to try them, and help gain some visibility.

Let's talk technical now. I have already worked on Flatpak nearly 1 year ago, and could launch several frontends using hand made manifests (the files instructing Flatpak how to build your application). I didn't found the time to polish it and it has never been made public.

This time, I wanted to have something as automated as possible: there are several frontends, and dependencies may change, I don't want to have to do everything by hand each time I update the packages.

The main difficulty when building flatpak, is that you have to deal with what is available in the "runtime" (the base of the distribution you'll use), and without network (you can't make internet connection during building process). In the case of Python, that means that you have to download every dependencies (including their own dependencies, etc.) and then install them in the right order (if you have wrong order, a module installation will fail because of missing dependency). This task is more complicated that it seems.

Flatpak ecosystem propose a script to make this task easier: Flatpak PIP Generator. It retrieves dependencies of a Python package, download them, generate the hash and retrieve download URL to prepare a list of "modules" usable in the manifest. The problem is that the list is not ordered according to dependencies, and the JSON produced is not directly usable. I quickly moved to make my own script specially tailored for SàT needs.

The first issue with dependencies is that there is no good way to find them. They are normally declared in the setup.py script which is the standard way to install a Python package, but you can't import this script to analyze it (it would execute its code and the usual if __name__ == '__main__' way to avoid that is never used with setup.py).

Well you have PyPI doing the analyze for you, and if you use its JSON API you can retrieve the mandatory requirements + optional ones using the ['info']['requires_dist'] field of the metadata object. Except that this field is far from always being complete, for instance it's not set for Twisted (I have not investigated for the reasons, maybe because Twisted is using an other file dynamically read). Twisted is far from being the only package without this data, so it's unusable in my case.

I've searched a bit on Internet and made different tries, and at the end the best I've found to reliably get the dependencies used by a Python project is to install it in a virtual environment and to parse the output of pip show <package_name>.
This command output a text with a Requires: line showing the actual requirements used in this project. Thanks to that I could solve the dependencies hell problem and my script is able to order correctly and automatically the modules needed in my manifest. The only modules not managed are setup requirements (requirements needed only for building the modules), but there are only a few of them and it's easy to specify them by hand.

I'm actually doing it in two times: first I download (using pip download) the requirements of the Python package to get the list and version needed, then I install the package in a virtual environment to analyze the output of pip show (pip handle a cache, so packages are not downloaded twice).

So my manifest generation script which I was expecting to do quickly took actually most of my free time this week and it's still not finished. I'm adding other options and I have to faces troubles likes Mercurial not being managed by Flatpak (for this case I have to retrieve myself the repository and upload it manually). I'm also sparing you other troubles (like how to organize the packages, SàT being a specific architecture I've first made my own runtime before being discouraged of doing this on the Flatpak mailing list).

At the end it's a lot of time spent just to make installation easier, and I have to do everything myself. I hope this kind of stories I'm explaining in my notes helps people to understand why it takes so long to develop a software, specially when you're on your free time. I hope also this work will help to popularize the project, and, maybe, bring some helping hands :)

See you soon.

As mentioned in my note 2 weeks ago, I was in holidays and skipped last week note.
It has been a really good thing, a relief, to be out of the screen for a couple of days, I recommend!

So I'm now back to work in my paid job, and working again on SàT on my free time. We are already in the middle of June, and the release is still not done; it's time for the home straight. As you can see if you follow progress notes, I'm working regularly, and moving forward each week, but there is so much to do. Anyway things are getting better now, the new website is online with documentation, the tickets system is working even if still buggy (it's getting better with time), and I start to have feedbacks, meaning that people are testing.

During my holidays I've got a report on ActivityPub about an issue with <link> elements, followed by a bug report. With those informations, I could spot the issue and fix it (it was a problem with caching, the data used in template were not deeply copied, and the list containing links was reused and growing each time the page was accessed). Thanks to Rydroid for reporting the issue.

When you test and see something wrong, the right thing to do is to contact me, and if possible report a bug on https://bugs.goffi.org. If it's easier for you, you can contact me by other means, but the ticket creation is the better way to be sure it's not forgotten.

I've finished and deployed the pubsub experimental option I have talked about in a previous note. I've called it consistent publisher and the goal is to keep original publisher if a node owner or an admin modify an item. The main reason is to maintain permission to edit the ticket for the original publisher, and thanks to that I can now change status of a ticket without replacing publisher.

Overwriting an item is not yet ideal in pubsub: either you follow XEP-0060 and any publisher can overwrite any other publisher item (not great in case of tickets or blog comments), or you restrict overwriting to your own published items but you need to do a workaround like this. I have ideas on how to improve the situation with node options and I'll probably propose a XEP at some point after SàT release.

As you know, I'm focusing on debugging, and I've spotted a couple of annoying bugs that I'll fix in the incoming week. My target is a release before the end of June. I have started work on packaging Cagou for desktop with Flatpak, so it should be easy to install and test on most GNU/Linux distributions, I'll probably talk about that in next week note.

Hello everybody,

during this week I've put online the new official website at https://salut-a-toi.org.

This is an important step for several reasons, let me explain.

The former site (which is currently still available at https://old.salut-a-toi.org, not sure yet how long it will stay here, but it won't be maintained anymore) was made with Django + bootstrap. It was working and not so bad, but outdated (with a really old screenshot on the front page), and it was a pain to maintain it in parallel of the work on SàT
Django is great, powerful, with a big community, but using it only for our presentation website means that we have to follow its evolution, and we have to solve issues from time to time, e.g. when we update the version. Django template engine is similar to Jinja2 that we use, but it's different enough to have to check documentation to maintain it, not a big deal, but some work that we could avoid.

By moving the website to our own Libervia framework, we stay on the exact same stack as SàT itself, so we don't have to follow other frameworks/libraries, it's easier to maintain. Also it's a good use case to test the framework, and make it evolve according to real life use case.
Furthermore, it simplifies our life for some features, like the news available at https://salut-a-toi.org/news, which is an XMPP blog. With Django we were using a iframe displaying a Libervia instance, while now we can directly show the blog.

With the new website I have added a "documentation" section. So far the documentation was mostly on the wiki, but it was not well maintained and a bit messy. Now it's inside the project itself, and written using reStructuredText which is the markup used most of time with Python project. Also we use Sphinx to render it nicely. As a result, we have a better rendered documentation, which is closer to the project (we can even use source code itself and its docstrings) so it should be up-to-date, and we can use the same source to produce things like man pages or a PDF manual.
Having to render the documentation with Sphinx, was the main reason to create our task manager in Libervia Web Framework.

The documentation is far from being complete, but I'm working on it. You can already see how to use jp for blogging or sending end-to-end encrypted message.

Now the TODO list for the release is done. What is left is debugging, writing documentation and packaging… And some rest! I'm currently in holidays so there will probably not be any progress note next week.

Nik: indeed, but I would still have had to convert existing templates, and keep up-to-date with Django evolutions.
Side note: You can simply switch Django to Jinja2 with one setting.