Libervia progress note 2023-W22

goffi 31. 5. 2023 20:39 jabber-xmpp-en SàT Libervia project libre Libervia progress SàT progress XMPP

Hello,

It's been a while since my last progress note. I've been immersed in work on Libervia, with many tasks to accomplish. I'll keep this update brief.

A/V Implementation in Libervia

I'm thrilled to announce a new development that I haven't yet officially shared on this blog: Libervia has once again received a grant from NLnet, this time via the NGI Assure Fund. This funding will facilitate the implementation of A/V calls with Jingle across several frontends: Web, Desktop, and CLI. In addition to one-on-one calls, multi-party calls are in the plans. The first approach will be using XEP-0272: Multiparty Jingle (Muji), which supports Peer-to-Peer (P2P) connections between participants without the need for a specific service—ideal for a small number of participants. For larger groups, a Selective Forwarding Unit (SFU) will be used, mirroring the technology used in platforms such as Jitsi Meet.

Alongside calls, we plan to offer Desktop Sharing, and even a specification and implementation for Remote Desktop Control atop XMPP!

Progress is well underway; one-on-one calls are already functional within the web frontend. However, there is still substantial work ahead.

To gain insight into the related tasks and what we've accomplished so far, you can check the associated tickets.

ActivityPub Gateway

I realize the high level of anticipation surrounding this gateway. While the gateway is operational (this blog utilizes it), it is yet to stabilize. I had hoped early adopters would install it and provide bug reports or other feedback. Unfortunately, this was not the case, with only one person (to my knowledge) having used it and provided prior feedback. This is understandable considering the requirement of an existing XMPP server, installation of a dev version of Libervia, and setting everything up. If you wish to try it out, you're welcome to join our official chat at libervia@chat.jabberfr.org (http link).

Nonetheless, I've decided to adjust my strategy. At some point, I plan to open a test instance. Due to limited resources for moderation, it will likely be invitation-only initially. The ultimate aim is to gather sufficient feedback to ensure stability.

Official Website and Test Instance

There have been several changes to the website:

  • The Flatpak and Docker images appeared to be malfunctioning. I've temporarily removed them and plan to rectify this issue later. If you wish to test Libervia in the meantime, the sources remain available.

  • I've added a roadmap at https://libervia.org/roadmap. Many had requested this, so here you go.

I've discontinued the libervia.org test instance, after years of service, as I've relocated the official website there to align with the project's new name (Libervia versus formerly Salut à Toi). As mentioned above, I have plans for a new instance, but it will likely be invite-only initially. I'm also considering a local-only demo for a quick overview of the web frontend—a non-federated feature that self-resets every few hours. We'll see if I can make the time to set it up.

Talks

I'll be delivering two talks next month in Paris:

I would be delighted to engage in a conversation if you happen to be there.

Other

In addition to these projects, I've been focusing on parallel tasks like code refactoring, work on calendar events, and the web frontend. However, I'll delve into these topics in more detail at a later date.

That's all for this note.

Libervia progress note 2022-W45

goffi 24. 11. 2022 11:58 jabber-xmpp-en SàT Libervia project libre Libervia progress SàT progress XMPP

Hello, it's time for a long overdue progress note.

I'll talk here about the work made on ActivityPub (AP) gateway and on end-to-end encryption around pubsub.

Oh, and if everything goes well, this blog post should be accessible from XMPP and ActivityPub (and HTTP and ATOM feed), using the same identifier goffi@goffi.org.

Forewords

The work made on the AP gateway has been possible thanks to a NLnet/NGI0 grant (with financial support from the European Commission's Next Generation Internet programme).

I especially appreciated that the team was really there to help bring the ideas to life, and not once did they get in the way: little paperwork, no unnecessary pressure, caring, contacts when help was needed, etc.

I wish there were more organizations like this one that really help develop libre projects for the common good.

So once again I want to thank them for all that.

XMPP ⬌ ActivityPub Gateway

There is probably no need to explain here what is ActivityPub, we can simply write that it is an open protocol that allows to do things that XMPP also allows doing, and that until now these 2 protocols could not communicate together. The work on the ActivityPub gateway aims to allow software implementing one of these 2 protocols to communicate as easily as possible. I firmly believe that all open protocols should be able to communicate which each other, to avoid creating more silos, proprietary software is already good enough at that.

To be useful, a gateway must use the full potential of both protocols. A simple bot transcribing messages as we see too often, using unsuitable features (such as instant messaging for blog posts), or using a very limited set of features to ensure compatibility are flaws that I have tried to avoid. Building a good gateway is a difficult and time-consuming task. If done right, the gateway should be as invisible as possible to the end user.

XMPP is featuring blogging since long before AP, however the set of features is not exactly the same. Current use of AP is clearly inspired from commercial "social" networks, and metadata such as subscribers/subscribed nodes (or followers/following in AP terms) are highlighted, feature such as like/favourite were missing in XMPP, and some implementation such as Pleroma do implement reactions. To integrate that in the gateway, I've been working on new specifications:

  • Pubsub Public Subscriptions: a way to publicly announce subscriptions, in an opt-in way. With this it's possible to implement followers/following features in a way respectful of privacy.

  • Pubsub Attachments: a generic way to attach any kind of data to a pubsub item. It's notably used to implements noticed/favourite button (see here and reactions.

  • Calendar Events: handling of events and all the RSVP mechanism. Libervia was handling events for years, but it was an experimental implementation, this specification is a next step in the effort to make it a standard.

Note that this XEP and the others linked below have been accepted but are not yet visible in official list.

You may wonder why there is a specification for Calendar Events… It's because the AP gateway also handles them, making it compatible with Mobilizon. The gateway may evolve in the future to support other non (micro)blogging use cases.

The gateway is now finished in terms of functionalities, however the code is clearly of an alpha quality for the moment. Now the goal in the coming months will be to stabilize and possibly implement other features if there is a demand for it.

Early adopters are encouraged to try and test it as long as they keep in mind that it's not stable. So if you do try it, I recommend keeping a separate ActivityPub account in whatever stable implementation you use at the moment, this way you can check if messages or media are missing, if there is any inconsistency or other bugs, and report them to me. If you test it, please join the XMPP room libervia@chat.jabberfr.org (click here to connect from your browser) for help and feedback. Stabilization will probably take weeks, but I hope to have it done by early 2023.

Installation instructions and details on how the conversion between protocols is done is available in the documentation and notably here

A question I've been asked a lot: yes, you can use the same identifier for XMPP (JID) and AP (WebFinger actor handle) as long as you use "simple" characters (i.e. alphanumeric ASCII chars, _, . and -). If you use something more complicated, you'll have to use the escaping mechanism explained in the doc (this is due to constraints with some AP implementations).

As for blogs on pubsub nodes (what Movim calls "communities"), I made it simple: you can use directly the name of the node that holds the blog in the local part (i.e. before the "@") of your actor handle: a blog named community_bog at the XMPP pubsub service pubsub.example.org can thus be addressed with the AP actor community_blog@pubsub.example.org. This way you can use a rather user-friendly identifier to share your blog with people who are only on ActivityPub.

This gateway should work with any XMPP server, and any client that implement blogging features (Only Libervia itself and Movim implement it for now, but I have heard that other clients are planning support for it). To enjoy the whole feature set of the gateway, the new specifications need to be implemented by the clients, so you can start to fill feature requests…

With this gateway, the door is open to have a client able to talk to the ActivityPub network, while having the feature of XMPP, including e2e encrypted private messages (e2e encrypted only if you communicate with an XMPP account, not with an AP one).

Oh, and please update your graphics, drawing and other texts to include XMPP in the fediverse ;)

End-to-End Encryption

Much effort has also gone into end-to-end encryption.

OMEMO implementation has been updated (OMEMO:2 is now used), including Stanza Content Encryption which allows encrypting arbitrary elements instead of only the \<body/> of the message, I believe that Libervia is the first XMPP client to implement it. OpenPGP for XMPP (or "OX") has also been implemented, all that thanks to the work of Tim Henkes "Syndace", the author of python-omemo.

Beside instant messaging, end-to-end encryption has also been introduced to pubsub. I've made specifications for two methods:

  • An OpenPGP profile for pubsub which is thought to encrypt a whole node, with a system of secret sharing/rotation/revocation. With it, it is easy to give access to new entities after publication, and to retrieve old items for newcomers. This specification can be used to encrypt any pubsub based features: (micro)blogging, calendar events, lists, etc.

  • Pubsub Targeted Encryption which is a way to apply the same cryptographic system used in instant messaging to pubsub. This way, OMEMO can be used with its forward secrecy property. It is not a good option to use this specification to encrypt a whole node, as archive is then not accessible to newcomers, and to add access to a new entity you have to re-encrypt all items, but it's an interesting option to encrypt an element occasionally, for instance to restrict access of a specific post in an otherwise public blog.

Specifications have also been written to sign a pubsub item in a backward compatible way (client which don't implement those specifications can still work normally):

All those specifications are already implemented in Libervia, but they are only usable from CLI frontend at the moment. All you have to do is to use the --encrypt and/or --sign options from pubsub or blog commands (check documentation for details).

Uploaded files were already encrypted with OMEMO Media Sharing which is what is commonly used these days, but this method has not been accepted as a standard as it was a workaround for limitation of legacy OMEMO implementation. The proper way is now specified with Stateless File Sharing and is encrypted with Encryption For Stateless File Sharing. Those methods are currently only usable when OMEMO:2 is implemented in the peer client, and with them metadata on the shared file can be attached, including thumbnails.

Encryption has also been implemented for Jingle (XEP-0391 and XEP-0396), which is notably used for Jingle File Transfer (specially useful for large files transfers).

So to summarize, nearly everything (instant messaging, files uploaded, large file transfers, all pubsub related features) can now be e2e encrypted with Libervia.

Possible Future

With the AP gateway permitting to reach the whole AP network, all the new features implemented, and the work done on e2e encryption, Libervia has everything to be a solid option for communication. After the recent events regarding a famous commercial network, we see a breakthrough of ActivityPub that will hopefully last over time. We can now access AP from XMPP, while having the possibility to have e2e encrypted private conversations or even blogs or calendar events.

As far as I know this is, so far, something unique for a Libre decentralized software. However, there is still work to do on stabilization on UI/UX update before this is really usable.

Those feature were planned for very long (years), but the lack of resources made them slow to come. The grant has made it possible to greatly accelerate the pace of development, and I doubt that it would have been possible to have all that without it.

Regarding how large the project is, and my family life, it's not possible any more to develop seriously this project on my free time alone (and I would like to do other things, sometimes, of my free time).

In other words, I need to find a way to sustain the development of Libervia for the years to come, so I can work full-time on it, and with some luck, build a team. I'm thinking very seriously about it these days, I'll probably write on this topic in a little while. If you are willing to help in any way, please contact me (on the Libervia room linked above for instance).

That's all for this progress note. I'm now working on stabilization and UI/UX update on the web frontend.

Decentralized code forge, based on XMPP

goffi 6. 6. 2018 5:50 SàT XMPP jabber-xmpp-en project

With the recent announcement concerning the biggest known centralized code forge owner change, we have seen back here and there discussions about the creation of a similar tool, but decentralized.

I've used this occasion to recall the work done to implement tickets and merge requests in Salut à Toi (SàT), work which was relatively unoticed at the time of writing, about 6 months ago.

Now, I would like to bring some details on why building those tools.

First of all, why not the big forge? After all, a good part of current libre software is already using it! Well first it's not libre, and we commited ourself in our social contract to use libre software as much as possible, infrastructure included. Then because it's centralized, and there too our social contract is pretty clear, even if it's not as important for infrastructure as it is for SàT itself. Finally, because we are currently using Mercurial, and the most famous forge is build around Git.
We do not hide the fact that we already ask ourselves wether to use this platform or not in general assemblee (cf. minutes – in French –), we were mainly interested in the great visibility it can offer.

« It's centralized? But "Git" is decentralized! » is a point we are ofter hearing and it's a true fact, Git (and Mercurial, and some others) is decentralized. But a code forge is not the version control system, it's all the tools arount it: hosting, tickets, merge/pull requests, comments, wikis, etc. And those tools are not decentralized at the moment, and even if they are often usable throught a proprietary API, they are still under centralization rules, i.e. rules of the hosting service (and its technical hazards). This also means that if the service doesn't want a project, it can refuse, delete, or block it.

Centralization is also a technical facility to catalog and search project… which are on the service. Any external attempt will then have more difficulties to be visible and to attract contributors/users/help. This is a situation we know very well with Salut à Toi (we are not present on proprietary and centralized "social networks" for the same reasons), and we find it unacceptable. It goes without saying that concentrating projects on a single platform is the best way to contribute and exacerbate this state of affairs.
Please note, however, that we are not judging or attacking people and projects who made different choices. These positions are linked to our political commitment.

Why, then, not using existing Libre projects, already advanced and working, like Gitlab? Well, first because we are working with Mercurial and not Git, and secondly because we would put ourselves here too in a centralized solution. And there is an other point: there are nearly no decentralized forges (Fossil maybe?), and we already have nearly everything we need with SàT and XMPP. And let's add that there is some pleasure to build the tools we are lacking.

SàT is on the way to be a complete ecosystem, offering most, if not all, the tools needed to organise and communicate. But it is also generic and re-usable. That's why the "merge requests" system is not linked to a specific SCM (Git or Mercurial), it can be used with other software, and it is actually not only usable for code development. It's a component which will be used where it is useful.

To conclude this post, I would like to remind that if we want to see a decentralized, ethical and politically commited alternative to build our code, organise ourself, and communicate, we can make this real by cooperating and contributing, being with code, design, translations, documentation, testing, etc.
We got recently some help for packaging on Arch (thanks jnanar and previous contributors), and there are continuous efforts for packaging in Debian (thanks Robotux, Naha, Debacle, and other Debian XMPP packagers), if you can participate, please contact us (see our official website), together we can make the difference.
If you are lacking time, you can support us as well on Liberapay: https://liberapay.com/salut_a_toi. Thanks in advance!

E

edhelas 6. 6. 2018 6:34

Vers une forge décentralisée basée sur XMPP

goffi 6. 6. 2018 5:43 SàT XMPP jabber-xmpp seenthis planet-libre project

Avec la récente annonce concernant le changement de propriétaire de la plus grosse forge centralisée connue, on a vu resurgir ici et là des questionnements sur la création d'un outil similaire mais décentralisé.

J'ai profité de l'occasion pour rappeler le travail effectué pour implémenter tickets et requêtes de fusion (« merge requests ») dans Salut à Toi (SàT), travail qui était passé relativement inaperçu quand j'ai écrit à ce sujet, il y a 6 mois.

Désormais je souhaite apporter quelques précisions sur le pourquoi de ces outils.

Tout d'abord pourquoi pas la grosse forge ? Après tout une importante partie des logiciels libres actuels l'utilise déjà !
D'une part parce que ce n'est pas libre, et nous nous sommes engagés dans notre contrat social à utiliser tant que possible des logiciels libres, y compris pour l'infrastructure. D'autre part parce que c'est centralisé, et là encore notre contrat social est clair à ce sujet, même si c'est moins essentiel pour l'infrastructure que pour SàT lui-même. Enfin parce que nous utilisons à l'heure actuelle Mercurial, et que la forge la plus connue est construite autour de Git.
Ne cachons pas toutefois que nous nous sommes déjà posés la question notamment en assemblée générale (cf. les comptes rendus), nous étions intéressés en particulier par la visibilité.

« C'est centralisé ? Mais « Git » est décentralisé ! » est une réflexion que l'on entend souvent et elle est vraie, Git (et Mercurial, et d'autres) est décentralisé. Mais une forge n'est pas le gestionnaire de version, c'est tous les outils autour : hébergement, tickets, gestion des modifications (merge/pull requests), commentaires, wikis, etc. Et ces outils là ne sont pas décentralisés à l'heure actuelle, et même s'ils sont souvent accessibles par des API spécifiques aux services, ils restent soumis aux lois de la centralisation, c'est-à-dire du service qui héberge (et des aléas techniques de ce service). Cela veut également dire que si le service ne veut pas d'un projet, il peut le refuser, l'effacer, le bloquer.

La centralisation, c'est aussi la facilité pour cataloguer et rechercher… pour les projets qui sont sur ce service. Rendant de facto toute tentative extérieure moins visible et donc augmentant ses difficultés. C'est une situation que nous connaissons bien avec Salut à Toi (nous sommes également absents des « réseaux sociaux » propriétaires et centralisés pour les mêmes raisons), et que nous jugeons inacceptable. Il va sans dire que se concentrer sur une plateforme ne fait qu'encourager et prolonger cet état de fait. Notons tout de même qu'il n'est pas question ici de dénigrer ceux qui ont fait des choix différents, ces réflexions étant liées à notre implication politique forte et les contraintes changent d'un cas à l'autre.

Pourquoi, alors, ne pas utiliser des projets libres existants, avancés et fonctionnels comme Gitlab ? D'une part parce que nous travaillons avec Mercurial et non Git, et d'autre part parce que nous serions là aussi dans la centralisation. Il y a une autre raison : c'est qu'il n'existe pas ou peu (Fossil peut être ?) de forges décentralisées, et nous avons déjà tout ce qu'il nous faut avec SàT et XMPP. Et puis il y a un certain plaisir à créer les outils qui nous manquent.

SàT se veut un écosystème complet, offrant la majeure partie si ce n'est tous les outils nécessaires pour s'organiser et communiquer. Mais il est aussi générique et réutilisable. C'est pourquoi le système de « merge requests » n'est pas lié à un outil particulier (Git ou Mercurial), il peut être utilisé avec d'autre logiciels, et n'est d'ailleurs par réservé au développement de code. C'est une autre brique qui sera utilisée là où ça sera utile.

Pour conclure, je rappelle que si vous voulez voir une alternative décentralisée, éthique et engagée pour construire nos logiciels, nous organiser et communiquer, on peut la rendre possible en coopérant et contribuant, que ce soit avec du code, de la conception graphique (design), des traductions de la documentation des tests, etc.
Nous avons récemment eu de l'aide pour l'empaquetage sur Arch (merci à jnanar et aux mainteneurs précédents), et il y a des efforts continus pour l'empaquetage sur Debian (merci à Robotux, Naha, Debacle et les autre empaqueteur XMPP sur Debian). Si vous pouvez participer, merci de regarder comment nous contacter sur le site officiel), ensemble on peut faire la différence.
Si vous manquez de temps, vous pouvez aussi nous soutenir sur Liberapay: https://liberapay.com/salut_a_toi. Merci d'avance !

E

edhelas 6. 6. 2018 6:34

Le partage de fichiers arrive dans la prochaine version de Salut à Toi

goffi 28. 5. 2018 7:54 SàT XMPP jabber-xmpp seenthis planet-libre project

La dernière grosse fonctionnalité avant la préparation de la version alpha, le partage de fichiers, et désormais disponible pour Salut à Toi.

SàT est capable d'envoyer ou recevoir des fichiers depuis des années, soit directement quand 2 personnes sont connectées en même temps, ou via un téléversement sur le serveur (via « HTTP upload »).

Il est maintenant possible de partager une hiérarchie de fichiers, ou en d'autres termes un ou plusieurs répertoires. Il y a 2 cas d'utilisation principaux : avec un composant, ou un autre client.

partager un répertoire avec Cagou

Partager un répertoire avec un client

La première façon d'utiliser le partage de fichiers est directement entre 2 appareils. Ceci peut être utilisé, par exemple, pour partager des photos prises sur votre téléphone avec votre ordinateur de bureau, ou pour rapidement donner accès à des documents de travail à vos collègues.
Pour gérer les permissions, vous n'avez qu'à donner les JIDs (identifiants XMPP) des personnes autorisées (ou à cliquer sur les contacts dans Cagou, l'interface graphique).

Le transfert utilise la technologie Jingle, qui va permettre de choisir la meilleure façon d'envoyer le fichier. Cela signifie que si vous êtes sur le même réseau local que l'autre appareil (ce qui est le cas dans le précédant exemple de partager des photos prises sur le téléphone avec votre ordinateur de bureau, quand vous êtes à la maison), la connexion reste en local, et le serveur ne verra que le « signal », c'est à dire les données nécessaires à l'établissement de la connexion.

Mais si vos appareils ne sont pas sur le même réseau local, la connexion est toujours faisable, et SàT essaiera d'utiliser une connexion directe quand c'est possible.

partage de fichiers avec un client

Ci-dessus vous pouvez voir avec quelle simplicité on peut partager un répertoire avec Cagou, l'interface bureau/Android de Salut à Toi.

Le partage de fichiers avec un composant

SàT peut maintenant gérer des composants (qui sont plus ou moins des greffons génériques pour les serveurs XMPP), et un premier permet à un utilisateur de téléverser, lister, ou retrouver des fichiers.

Ceci est vraiment pratique quand vous voulez garder des fichiers privés pour une utilisation ultérieure (et y accéder depuis n'importe quel appareil), ou pour partager un album photo, par exemple, avec votre famille. Cette fonctionnalité est sur la voie d'un service similaire à ce qu'on appelle de nos jours « stockage sur le cloud », sauf que vous pouvez garder le contrôle sur vos données.

partage de fichiers avec un composant

Comme vous pouvez le voir, c'est très similaire à ce qu'il se passe entre 2 clients.

De plus avec le nouveau système d'invitation de SàT, vous pouvez partager des fichiers même avec des personnes qui n'ont pas de compte.

Quelques notes

Le transfert de fichier n'est pas encore chiffré, mais c'est prévu rapidement avec OX (OpenPGP) ou OMEMO.
La fonctionnalité de base est là et fonctionne, mais il y a encore des améliorations prévues à plus ou moins long terme : des quotas pour les utilisateurs, la synchronisation de fichiers, le chiffrement de bout en bout, ou encore la recherche avancée.

Tester

Vous trouverez sur le wiki les instructions sur comment utiliser cette fonctionnalité (en anglais).

Bien sûr vous aurez besoin de la version de développement pour tester. N'hésitez pas à demander de l'aide sur le salon SàT : sat@chat.jabberfr.org (ou avec un butineur).

Un paquet est désormais disponible pour Cagou sur AUR pour les utilisateurs d'Arch Linux, un grand merci à jnanar pour ceci.

Besoin d'aide !

SàT est un très gros projet, avec de fortes racines éthiques. Il est unique sur plus d'un point, et nécessite beaucoup de travail. Vous pouvez aider à sa réussite soit en nous soutenant sur Liberapay soit en contribuant (jetez un œil au site officiel ou venez sur le salon pour plus d'infos).

Le prochain billet sera à propos de la sortie de la version alpha, restez en ligne ;)

File sharing landing in next release of Salut à Toi

goffi 28. 5. 2018 7:24 SàT XMPP jabber-xmpp-en project

Last big feature before the preparation of alpha release, file sharing is now available for Salut à Toi.

SàT has been able to send or receive files for years, either directly when 2 people are connecting at the same time, or via an HTTP upload on the server. It is now possible to share a file hierarchy, or in other words one or several directories. There are 2 main uses cases: using a component, or a client.

sharing a directory with Cagou

Sharing directory with client

The first way to use file sharing is from device to device. It can be used, for instance, to share pictures taken from your phone with your desktop computer, or to quickly give access to discussion papers to your coworkers. To handle permissions, you just have to give the JIDs (XMPP identifiers) of allowed people.

The transfer is using Jingle technology, which will choose the best way to send the file. That means that if you are on the same local network (e.g. the previous case of sharing your phone picture with desktop computer, when you're at home), the connection will stay local, and the server will only see the signal (the data needed to establish the connection).

But if your devices are not on the same local area network, connection is still doable, and it will try to be direct when possible.

file sharing with a client

Above you can see how easy it is to share a directory with Cagou, the desktop/Android frontend of Salut à Toi.

File sharing component

SàT can now act as a component (which is more or less a generic server plugin), and a first one allows a user to upload, list and retrieve files.

This is really handy when you want to keep some files private for later use (and access it from any device), or to share a photo album, for instance, with your family.

This is on the way to a service similar to "cloud storage", except that you may keep control on your data.

file sharing with a component

As you can see, it's pretty similar to the workflow with client.

With the invitation system now available in SàT, you can even share with people without account.

Some notes

File transfer is currently unencrypted, but encryption is planed soon, either with OX (OpenPGP) or OMEMO.
The base feature is there and working, but some improvements are planed at more or less short term: quotas, files synchronization, e2e encryption, advanced search.

Testing

You'll find instruction on how to use this feature on the wiki.

Of course you'll need to use development version, don't hesitate to ask for help on SàT room : sat@chat.jabberfr.org (or via browser).

A package is now available for Cagou on AUR for Arch Linux, thanks to jnanar.

Help needed!

SàT is a huge project, with a strong ethical root. It's unique in many ways, and needs a lot of work. You may help its success either by supporting us on Liberapay or by contributing (check official website or join our room for details).

Next post will be about alpha release, stay connected ;)

Construisez un internet décentralisé avec Libervia (Salut à Toi) !

goffi 26. 1. 2018 7:30 SàT XMPP jabber-xmpp seenthis planet-libre project

Parmi les nombreuses nouveautés et évolutions de Salut à Toi pour la version 0.7 à venir, une a un particulièrement grand potentiel : Libervia (l'interface web) est devenu un cadriciel web (ou « framework web »).

« Mais il y en a déjà plein ! » vous entends-je dire… C'est vrai, mais celui-ci est décentralisé.

Construire sur du standard, avoir des outils pour créer décentralisé

Utiliser les comptes existants

Libervia s'appuie donc sur SàT et XMPP pour aider à construire voire reconstruire le web. Quel est l'intérêt ? Et bien déjà l'authentification, chose nécessaire sur la plupart des sites de nos jours, utilise le compte que vous avez déjà. Non je ne parle pas du compte sur le gros truc bleu ou l'oisillon piailleur, mais bien de votre compte XMPP, celui que vous utilisez avec SàT, Movim, Gajim, Conversations ou encore Pidgin, celui dont les données peuvent être chez vous dans votre salon, et avec lequel vous pouvez utiliser n’importe quel nom, celui avec lequel vos faits et gestes ne sont pas épiés.

Le ou la développeur/euse n'a donc pas besoin de gérer cela, et les utilisateurs n'ont pas à recréer un compte à chaque site ou à utiliser un compte centralisé (et ainsi dire aux aspirateurs à données du net où, quand et à quoi ils se connectent).

Autre avantage : on profite de l'existant ; si vous voulez intégrer d'autre moyens de vous authentifier (par exemple utiliser vos comptes GNU/Linux), vous n'avez qu'à activer ce qui va bien sur votre serveur (voir cette liste pour prosody, vous trouverez certainement une liste équivalente pour les autres serveurs.).

pubsub, la base de données décentralisée

XMPP n'est pas une technologie, mais un ensemble de technologies cohérentes, et pubsub est l'une d'elles. Pour mémoire, il s'agit d'enregistrer des données (ou « items ») dans des « nœuds » (qu'on peut voir comme des tables ou collections dans les bases de données), qui sont sur des services.

Un service pouvant être n'importe où sur le réseau, au même endroit que votre serveur web, à l'autre bout de la planète, sur l'intranet ou sur un .onion dans le réseau Tor. Bien sûr il est possible de garder des données localement si nécessaire, notamment pour le cache.

le cache parlons en justement, pubsub a une propriété très intéressante : on peut s'abonner à un nœud pour être prévenu des modifications sur celui ci (ajout/modification ou suppression de données). Ceci permet à Libervia d'avoir un système de cache automatique : une page peut être mise automatiquement en cache et celui-ci peut-être invalidé dès qu'une modification a lieu. Voilà encore de quoi simplifier la vie du développeur, et améliorer les performances côté utilisateur.

faciliter la vie

Libervia a été pensé pour faciliter la vie des développeurs.

changer l'apparence

Le système est entièrement basé sur un moteur de modèles (jinja2), qu'il est très facile d'étendre pour faire de nouveaux thèmes (du simple changement de CSS à la transformation de toute la structure des pages). Il suffit de créer un répertoire avec le nom du thème et de modifier ce que l'on souhaite, et uniquement ce que l'ont souhaite : les pages du thème par défaut vont être utilisées si nécessaire.

Intégration entre serveur et client

Un certain nombre d'outils sont présents pour faciliter l'intégration entre la partie cliente (dans le butineur) et la partie serveur (HTTP). Ainsi par exemple, il suffit de déclarer "dynamic = True" dans votre page Libervia (côté serveur), pour activer automatiquement un système de communication dynamique avec le navigateur (basé sur les websockets). Une méthode permet d'envoyer des données n'importe quand à la page, et une autre est appelée quand des données sont émises depuis le navigateur.

Ceci sera encore plus poussé dans la version 0.8, avec l'intégration prévue de transpileurs Python vers Javascript. Libervia utilise jusqu'ici Pyjamas, un projet qui n'est plus maintenu et qui se base sur un Python 2 obsolète. Pour éviter d'être bloqué sur une seule option, le choix sera laissé au développeur d'utiliser un transpileur Python vers Javascript (Brython et Transcrypt sont prévus), du Javascript simple (dit « vanilla »), ou s'il ou elle aime se faire du mal, un cadriciel Javascript à la mode.

Gérer les tâches communes

Un système de traduction est intégré nativement (utilisant Babel), ainsi que des filtres pour les dates, le rendu d'interfaces venant du backend, ou encore la création de formulaires.

Les modèles sont prévus pour êtres réutilisables, ainsi il est simple d'intégrer, par exemple, des commentaires dans une page.

Un écosystème en symbiose

Je m'arrête là pour les fonctionnalités, même si la liste n'est pas finie (il est par exemple possible de générer des sites statiques à la manière d'un Pelican ou d'un Hugo).

Ce nouvel outil a déjà été mis en pratique dans certaines des nouveautés de la version à venir, notamment avec le gestionnaire de tickets et de demande d'intégration de patch (« merge requests ») mentionnés précédemment.

La prochaine version de Salut à Toi est un aboutissement, c'est la première version prévue pour être utilisée en production, et constitue désormais tout un écosystème de communication, de création et de travail collaboratif, compatible avec le reste de la famille XMPP.

Si vous voulez vous tenir à jour vous pouvez consulter mon blog (qui est fait avec Libervia) ou nous rejoindre sur le salon sat@chat.jabberfr.org.

Si vous voulez nous soutenir, vous pouvez soit adhérer à l'association, soit nous aider sur Liberapay.

koala 17. 1. 2019 23:52

Build a decentralized internet with Libervia (Salut à Toi) !

goffi 25. 1. 2018 19:53 SàT XMPP jabber-xmpp-en project

Among many novelties of Salut à Toi in the next release (0.7), one has specially big potential: Libervia (the web frontend) is now a web framework.
"Yeah but there already so many of them!" I 've heard you saying… That is true, but this one is decentralized.

Building on standards, having tools for decentralization

Using existing accounts

So, Libervia is based on SàT and XMPP in order to help you to build or rebuild the web. But why? Well, first the authentication, which is used on most websites nowadays, use the account you alread have. No, I'm not talking about the account on the big blue stuff or the noisy bird, but about your XMPP account, the one you are using with SàT, Movim, Gajim, Conversations or Pidgin, the one, in which your data can be located in your living room, and the one in which you can use any name you choose; the one that does not tract your activity.

The developer doesn't have to worry about this, and the users don't have to create yet another account on each website, or to use an account from a big central website (and then tell to web data hoovers where, when and to what you did connect).

Other advantage: we take profit for existing software. If you want to integrate other authentication ways (for instance if you want to use your GNU/Linux accounts), you just have to activate the suitable thing on your server (check this prosody list for instance, you'll surely find similar lists for other servers).

Pubsub, the decentralized database

XMPP is not a single technology, but rather a basis for a variety of coherent technologies, and pubsub is one of them. As a reminder, with it you can store data (or "items") in "nodes" (which can been seen as tables or collections in other databases), on "services".

A service can be anywhere on the network : in the same location as your web server, on the other side of the Earth, on the intranet or on a .onion in Tor network. Of course it's possible to keep data locally if needed, in particular for caching.

Let’s talk about cache, pubsub has a really nice property: we can subscribe to a node to be notified when there are changes on it (new data, data update or deletion). Taking benefit from this gives Libervia an automatic cache system: a page can be automatically put in cache, and later can be invalidated as soon as a modification happen. That is an other thing to simplify developer's life, and to improve the speed for the user.

Simplify life

Libervia has been thought to make things easy :

Appearance change

The framework is entirely based on template engine (jinja2). It is really straightforward to create new themes (from doing simple CSS change to major changes in pages structure). You just have to create a new directory with theme name, and to modify what you want, and only what you want: pages from default theme will be used if needed.

Integration between server and client

A bunch of tools are there to facilitate integration between client (in the browser) and the HTTP server. For instance, you just have to set "dynamic = True" in your Libervia page on server side to automatically activate a bidirectionnal dynamic communication system with the browser (based on websockets). A method can be used to send data at any time to the page, and an other one is called when data are emited from the browser.

This will go deeper in the 0.8 release, with the planed integration of Python to Javascript transpileur/interpreters. Libervia is using so far Pyjamas, a project which is not maintained anymore and which is transpiling an obsolete Python 2. To avoid future blocking on a single option, developers will have the choice to use a Python transpiler/interpreter (Brython and Transcript are planed), Simple Javascript ("vanilla"), or if they really like pain, any currenly popular Javascript framework.

Handling common tasks

A translation system is natively integrated (using Babel), and also filters for dates, backend UI templates rendering, or forms creation.

Templates are built to be reusables, so it's easy to include, for instance, comments in page.

A symbiotic ecosystem

I'll stop here for features, though the list is not finished (it's for instance possible to generate static website à la Pelican or Hugo).

This new tool has already been used in severals features in the incoming release, notably with the tickets or merge requests handlers that I have announced recently.

Next release of Salut à Toi will be an achievement, the first version ready for production, and is now a whole ecosystem to communicate, create, or do collaborative work, compatible with the rest of XMPP family.

If you want to stay up to date, follow my blog (which is using Libervia), or join us on our room sat@chat.jabberfr.org.

If you want to support us, you can either join the association, or help us on Liberapay.

Other news to come soon…

E

edhelas 25. 1. 2018 20:57