close
  • Be chevron_right

    Berlin Online XMPP Sprint 2020

    debacle · pubsub.movim.eu / berlin-xmpp-meetup · Sunday, 22 March, 2020 - 00:47 edit

Berlin Online XMPP Sprint 2020

The planned XMPP sprint in Berlin from Thursday, 2020-03-26 to Sunday, 2020-03-29, will take place despite the current crisis. But instead of an in-person meeting, it will be an online event!

We will mainly use the XMPP group chat xmpp:xmpp-sprint@chat.cluxia.eu?join for all coordination, and multiple Jitsi instances for audio/video conferencing, maybe also mumble for voice chat.

Please find all details in the wiki and consider participation! This time, there are neither travel nor hotel costs! https://wiki.xmpp.org/web/Sprints/2020_March_Berlin

See you at the Berlin Online XMPP Sprint! Berlin is whereever you are!

#xmpp #sprint #event #community #hacking #freesoftware #uwpx #beagleim #siskinim #xmppjs #omemo #kaidan #smack #dino #omemo #prosody #xmpprs #salutatoi #debian #jitsi

  • favorite

    1 Like

    DebXWoody

  • Mo chevron_right

    Movim 0.16.1 – Cesco

    Timothée Jaussoin · pubsub.movim.eu / Movim · Friday, 6 December, 2019 - 09:50 · 1 minute

Only a few weeks after the 0.16 release here is the 0.16.1 one!

This release includes several fixes and a few new features.

Features

You can now share posts to your connected chatrooms :)

Chatroom post sharing

Communities layout were a bit redesigned, publication rules are now displayed clearly in the right column and the header shows more information on mobile.

Communities redesigned

All the messages that you sent in the one to one discussions can now be edited.

Message edition for the whole history

The videoconferencing feature was heavily refactored and several issues were fixed during this process. A new XEP was also used partially to improve the call negociation flow, XEP-0353: Jingle Message Initiation.

Fixes

In the database an index was added on the key that was tracking contacts avatars. This sounds maybe a bit technical to you but this small fix boost quite a lot the performances during the login process, when you join a chatroom (especially that one) or when a contact updates his/her avatar. Because it's a database change you should run the database migrations when updating from 0.16 to 0.16.1.

All the entities that are on the XMPP network needs to declare what they are capable of to the others. This allows feature discovery and negociation and is specified in the #XMPP extension XEP-0115: Entity Capabilities. After the big code refactor of the handling of those #capabilities within the Movim codebase some other small improvements and fixes were done to wrap up properly this feature.

Presences sent to MUC are now generated the same way than those sent to contacts, this fixes #711.

DNS resolution errors an timeout are now handled properly displayed during the authentication flow (#368).

The SQL_DATE constant was renamed to MOVIM_SQL_DATE to prevent some naming conflicts (#820).

What's next?

PHP 7.4 was released a few days ago, so the upcoming version will focus on fixing issues to make Movim fully compatible with that version.

This new PHP release also includes an exciting feature that allows #PHP developpers to call directly C libraries in their codes. This could allow #Movim to directly use the libsignal C library and therefore (finally) allow OMEMO end-to-end-encryption to be implemented. This will be a lot of work and verifications so we're not promissing anything anytime soon. Stay calm please!

That's all folks!

#omemo #videoconference #jingle #release

  • movim/movim

    Movim - Decentralized social platform. Contribute to movim/movim development by creating an account on GitHub.

  • favorite

    4 Like

    togart , eyome , CNT 31 , Marzanna

  • Be chevron_right

    Kaidan - A user-friendly XMPP client, and ATT - Automatic Trust Transfer

    debacle · pubsub.movim.eu / berlin-xmpp-meetup · Saturday, 2 March, 2019 - 12:48 edit

Kaidan - A user-friendly XMPP client, and ATT - Automatic Trust Transfer

At this months Berlin XMPP meetup, we will probably

When? Wednesday, 2019-03-13 18:00 CET

Where?JWD: Takustraße 3, 14195 Berlin

#xmpp #meeting #meetup #berlin #jabber #kaidan #client #sprint #att #omemo #jwd

  • chevron_right

    Things I don't like with OMEMO as it is today

    debacle · Tuesday, 13 November, 2018 - 19:21 edit · 2 minutes

I use OMEMO every day, because I prefer end-to-end encrypted messaging for many purposes. OMEMO is much better than OTR, and it works well enough to be useful. But OMEMO has a number of usability issues, that should be addressed by the IM and XMPP community at some point.

  1. It relates to devices instead of users. I don't want to know, whether my contacts own a new device, nor should they care when I do.
  2. Forward secrecy is a good thing for TLS. But when used for messaging, I cannot decrypt my old messages stored on the server in all cases. Also, it makes key escrow impossible, which is a killer for using it in business.
  3. Deniability. I want verifiable signatures instead. Maybe I want to conclude a contract via XMPP? For deniability I would use an anonymous account in the first place.
  4. OMEMO does not encrypt the complete stanza, but only the textual part of a message.
  5. It does not work with local, serverless messaging. I don't use this feature a lot, but still, encryption should work with it, too.
  6. OMEMO seems to be pretty complex, which makes implementation relatively hard. In fact, bugs related to OMEMO are still frequent in some clients.
  7. I already have an OpenPGP key, that is trusted (and occasionally signed) by many. Why not re-use it for IM purposes?
  8. (added 2019-02-15) This is an amendment to the first point: If we accept the concept of keys per device, at least improve the management. The keys should have a label, e.g. "mobile" or "PC at work", to be less confusing. Or why not automatically cross-sign keys from all devices?

Some of the points can be addressed in later OMEMO versions, but some points seem to be woven into the fabric. Fortunately, I see the light at the end of the tunnel (and I hope it is not the oncoming train): OX or "OpenPGP for XMPP". I hope, that it will heal all my OMEMO aches:

https://xmpp.org/extensions/xep-0373.html

https://xmpp.org/extensions/xep-0374.html

The only thing, I do not like is synchronising of encrypted private keys using PEP, which involves storing it on the server, only secured by the PGP passphrase and the "backup code", generated by the device. But nobody forces me to use the backup feature and I assume, that it can be blocked by admins who feel uneasy about it. Also, OpenPGP seems to have a higher per message overhead than OMEMO. This is probably unavoidable.

Edit: Correction about OX private key encryption, thanks to lovetox!

Edit: Add point about OMEMO complexity and errors, thanks to Holger!

#omemo #xmpp #im #ox #openpgp #e2ee

  • Mo chevron_right

    Movim 0.11 - Tuttle

    Timothée Jaussoin · pubsub.movim.eu / Movim · Friday, 31 March, 2017 - 08:00 edit · 6 minutes

Six months after Movim 0.10 Holmes, here is the new winter release of the Movim project.

Small recap: Movim is a project that aims to build an IM and social networking service exclusively on top of the XMPP protocol.

This 0.11 version refined several features and will introduce a couple of big changes, mainly regarding the navigation and the project UI.

Features

New contacts list

The contacts list (or roster) has always been a very complex element inside Movim. It was ported on Angular 1 a couple of versions ago but suffered since then of performances issues (that could block the page loading for several seconds).

This new version brings a complete rewrite of this feature in pure PHP (with a bit of JavaScript). The contacts are now grouped in a simple list. The search has been improved and now allows you to search instantly among your contacts using their name, ID, nickname or group.

Onboarding

At first startup, Movim is now asking for some browser and account preconfiguration regarding notifications and pop-ups (used for videoconferencing) preferences.

test

The sharing feature

As promised, articles sharing has been greatly improved in and around the Movim project. It is now possible to share an article (as in "write an article as an answer to") on your own Blog. This feature is based on the IETF — Atom Threading Extensions (RFC 4685) norm. Again, Movim aims at showing that it's possible to build a social solution relying only on existing standards.

Sharing an external link has also been improved. Movim now understands XMPP URIs.

Communities

Communities, previously named "groups", are the result of a deep redesign of the way articles are displayed navigated through. The reorganization of the content makes the exploration much easier and natural. This new name also lets Communities clearly stand out from group discussions (chatrooms) and groups in the contacts list.

Communities also benefited of a better management system, for users, but also for administrators who can now assign roles in a more precise way.

All in all, that's a lot of changes but don't worry, Movim will still be compatible with old versions as nothing has changed on the XMPP side. ;)

Posts

Two littles features have been added on the articles page to facilitate articles discovery and evaluation. An article is now surrounded by links to the previous and following articles of the same Community or from the same contact and a "Like" button let's you express your contempt to the author of the article. :)

As an author, a new Notifications block on the homepage informs you of comments and likes on your published articles.

Discovery

The interface redesign also brings new features of content discovery.

Movim now provides readers with related articles published on Blogs or in Communities. Suggestions are so far pretty basic but should get better in the upcoming versions.

Chat

The Chat part has not been forgotten. A lot of changes have been done on the interface to ease the navigation on small and big screens (removal of useless spaces) and to fix a few bugs (on Android). A new pack of stickers has been added with a Creative Common BY-SA license.

The file upload and file sharing UI have both been redesigned and now make use of one of the latest XMPP norms, XEP-0385 : Stateless Inline Media Sharing (SIMS). It allows Movim to integrate them better in Chats.

Videoconferencing (beta)

In this version, the videoconferencing feature is coming back in Movim. As usual, nothing but standards here (WebRTC and XMPP Jingle this time). However some bugs still remain. They should all be fixed for the upcoming (0.12) version. This feature is only available for the desktops for now.

Refactoring of the session system

The user sessions management code within Movim was one of the oldest ones in use in the project. It has been heavily redesigned and now brings a new way of handeling cookies and session variables both in memory and in the database.

Around Movim

We now see more and more external contributions on Movim and its linked projects.

Android Client

Thanks to schlusslicht the Android native file selector has been integrated to the application. You can now upload files from your phone.

A little security update regarding certificates management has been added at the same time (non valid certificates are no longer accepted).

The Android application is available on Google Play and F-Droid.

Electron Client (desktop)

The Electron client has been updated. Mike Barnes (bremensaki) has added the support of contextual menus in the interface. Thanks Mike !

New Debian and RPM packages have been made. Movim is now also available on Windows and macOS. All those applications are available on the official website.

Atomtopubsub

Atomtopubsub is the little magic tool that, as its name suggests, parses Atom feeds and injects them on Pubsub nodes. It allows Movim to offer a lot of news feeds among Communities. A big thanks to Link Mauve, who took some time during the 33c3 to port atomtopubsub in Python 3 and to optimize the processing of articles inside the application.

Movim Europe

Movim Europe is a structure that provides support for the Movim project. It has been declared in the Netherlands and currently offers two services.

  • technical support and advices to deploy the platform (and linked services such as XMPP servers or SQL databases) and/or on the technologies involved in the project;
  • the possibility as a company, an association or an individual to fund the development of features that were not initially planned on the roadmap and that are part of a particular need.

The gathered funds will first cover the running costs (domains, hosting, travels...) that were until now payed by the founder, but also to free more time to develop the project and its surroundings (administration, linked projects, conferences...).

Don't hesitate to contact us on the official chatroom.

A few figures

We also have two official servers: one hosted in Amsterdam, with around 4 000 registrations and 50 connected people, and one in Roubaix with 2 800 registered people and around 20 simultaneously connected people.

Everyday, 4 000 messages (simple or from groupchats) are sent or received, and around twenty articles are written by the users of nl.movim.eu.

Statistics that are (voluntarily) sent on api.movim.eu by the deployed instances are showing a total of 8 000 registered users and around 250 simultaneously connected ones along the day. The XMPP server movim.eu reaches 300 connected people during the day.

Some plans are made to open new servers both in Australia and in Russia.

Movim 0.12

A new roadmap is also planned for the 0.12 that should be released this summer. Two main changes are planned:

  • Movim has a heavy memory consumption, it can reach 50 Mio for some users connected on a server. This problem is not due to memory leaks but to architectural decisions that are duplicating for each session some parts of the Movim code in memory. A huge change on this subject is planned, that should significantly reduce the memory footprint during runtime.
  • An implementation of the OMEMO protocol has been strongly demanded by the community. A preliminary research work has been done in January and it seems that this end-to-end encryption protocol could be implemented in Movim. A publication about this feature will most probably be released in the next few months.

We need you!

Don't forget, the Movim project needs you! As a source code contributor, but also as an administrator, packager, translator or even a drawer (if you want to add your own stickers to Movim!).

All contributions are welcome, so don't hesitate to come and discuss them with us on movim@conference.movim.eu. :)

That’s all folks!

Translated from the original French article by nodpounod - Christine HO & daftaupe - Pierre-Alain TORET

  • Movim

    Movim is a kickass distributed social networking platform that protect your privacy an comes with a set of awesome features.

  • favorite

    8 Like

    preptorrent , Roelof Pieter , U , Timofey Kostenko , krille , daftaupe , Tristan , Matija Šuklje

  • 1 Comments

  • 31 March, 2017 Matija Šuklje

    If anyone wonders, AtomPubSub is available through GitHub and edhelas is its main author.

    Link to code and project: <https://github.com/edhelas/atomtopubsub>

  • chevron_right

    Cryptocat, ou le piège du client magique

    Timothée Jaussoin · Wednesday, 6 April, 2016 - 19:35 edit · 6 minutes

Il y a quelques jours je suis tombé sur un article annonçant la sortie de la nouvelle mouture du client de messagerie sécurisé Cryptocat. Je ne m'étais jamais réellement penché sur ce client car il faisait, selon moi, partie des dizaines d'autres clients surfant sur la vague des messageries instantanées chiffrées sorties suite aux révélations d'E.Snowden. J'ai donc voulu creuser un peu et voir de quoi il était composé.

Comme vous le savez peut-être, je travaille moi-même sur un client de messagerie "sociale" appelée Movim exploitant le protocole XMPP. J'essaye, au travers de ce projet, de montrer aux gens qu'il est parfaitement possible de créer une solution à la fois sécurisée, standard et décentralisée tout en offrant une interface agréable et simple à comprendre. Petite précision toutefois: Movim ne possède pas (encore, mais j'y travaille) de fonctionnalité de chiffrement de bout en bout. Néanmoins il est possible de faire ce genre de chiffrement sur XMPP de façon standard et compatible avec des technologies standardisées comme OTR et le récent OMEMO (c'est d'ailleurs cette norme que j'ai décidé d'implémenter dans Movim).

La chose que je trouve dommage avec tous ces services et clients c'est qu'ils ne sont pas compatibles entre eux. Pourtant il existe aujourd'hui plusieurs clients XMPP proposant la norme OTR et OMEMO mais qui ne sont malheureusement pas si connus et médiatisés que les autres. Je mentionnerais en particulier l'excellent Conversations (sur Android) dont l'équipe est à l'origine de la norme OMEMO (qui est elle-même une implémentation de la norme Axolotl dans XMPP, notamment utilisée sur le client Signal).

Étant un peu curieux par nature je me suis plongé dans le code source de la nouvelle version de ce cher Cryptocat pour regarder un peu ce qu'il a dans le ventre.

Ni une, ni deux, je clone le dépôt sur ma machine et je commence à explorer le code.

Première surprise !

Avant même d'ouvrir le moindre fichier j'avais déjà un petit sourire en coin en voyant le nom de certains d'entre eux dans le répertoire src/js/.

axolotl.js
omemo.js
xmpp.js

Tiens, tiens, tiens. Un petit tour sur la page Security du site me confirme bien ça. Cryptocat utilise XMPP comme transport et OMEMO comme méthode de chiffrement. Le reste du blabla n'est rien d'autre qu'une réexplication de la norme Axolotl sans pour autant la mentionner.

Donc Cryptocat est un client XMPP, en Javascript, avec la norme OMEMO par dessus.

XMPP…

Je ne me suis pas particulièrement penché sur la partie chiffrement du projet, j'avoue ne pas avoir assez de compétences en cryptographie pour offrir une critique constructive et je pense que l'auteur du projet est bien plus expérimenté que moi là dessus. Je salue par ailleurs sa volonté de transparence à ce propos. Néanmoins je commence à bien connaitre le protocole XMPP et je sais que son point fort est la possibilité d'interconnecter les serveurs entre eux et de laisser le choix du serveur à utiliser aux utilisateurs.

L'interconnexion est une fonctionnalité que j'estime nécessaire car d'une part, elle permet aux utilisateurs d'avoir le choix du serveur sur lequel ils iront déposer leurs données et d'autre part, elle décentralise les points d'échange du réseau (et rend ainsi plus difficile la censure et l'écoute du réseau).

Après avoir regardé plus en détails le fichier xmpp.js j'ai enfin la confirmation de ce dont je me doutais jusque là.

jid: username + '@crypto.cat',
server: 'crypto.cat',

Oui, il y a bien un serveur XMPP écrit en dur dans le code source du projet.

Explorons un petit peu le serveur crypto.cat

Le site XMPP IM Observatory nous retourne une note de A pour la sécurité du serveur, ici rien à dire. Par contre je découvre que l'interconnexion avec les autres serveurs du réseau n'est pas autorisée. La connexion entre le client Javascript et le serveur se fait au moyen d'un Websocket et le serveur XMPP est un serveur Prosody tout bête.

Cryptocat n'est donc pas qu'une application de chat offerte par Nadim Kobeissi, mais aussi un service centralisé auquel les utilisateurs sont contraints de se connecter (sauf s'ils changent le code source du client, ce qui est possible, mais combien le feront ?).

Précisions sur le chiffrement de bout en bout dans XMPP

Le chiffrement de bout en bout est une très grande avancée dans l'anonymisation des données échangées. Néanmoins il ne permet pas tout. Sur XMPP par exemple il faut savoir que OTR et OMEMO ne chiffrent que le contenu des messages et pas la signalisation qui les accompagne (certains diront les métadonnées). Mais que pouvons nous trouver dans ces métadonnées ? Et bien l'identifiant de l'émetteur et du destinataire du message mais aussi beaucoup d'autres choses pouvant êtres sensibles. Une page sur le Wiki de Reporters Sans Frontieres résume plutôt bien tout ça. Ces informations peuvent être conservées dans des historiques et journaux sur les serveurs XMPP.

En choisissant de centraliser son service sur un seul et unique serveur (qui semble être hébergé dans le datacenter d'OVH à Roubaix) l'auteur de Cryptocat a aussi fait le choix de concentrer l'intégralité du trafic de sa plateforme sur un seul et unique point du réseau Internet.

Cela me serait égal si toutes ces informations étaient précisées sur le site du projet, au moins de façon temporaire si l'objectif à terme était de permettre la connexion à d'autres serveurs XMPP. Mais je trouve vraiment dommage qu'il ait tu ces informations.

Petit bonus, qu'en est-il de la v1 de Cryptocat ?

Même si je salue le fait d'utiliser des normes comme XMPP et OMEMO dans Cryptocat, j'ai quand même jeté un œil à la première version du projet pour voir sur quelle architecture il s'était basé.

Sans grande surprise la première version se base également sur XMPP et OTR. Néanmoins elle permettait de changer le serveur XMPP sur lequel le client se connectait. J'espère donc qu'il sera également possible de faire la même chose sur la seconde version.

Pas de quoi s'inquiéter donc ?

Oui, pour le moment pas de quoi crier au scandale mais je souhaiterais que Nadim soit aussi transparent sur l'architecture de son projet que sur les méthodes de chiffrement qu'il utilise au sein de son application.

Je pense qu'il est aussi important d'informer les utilisateurs de comment sont protégées leurs messages mais aussi par où et comment ceux-ci sont acheminés.

Dernière petite question, pourquoi vouloir à tout prix fermer la plateforme alors que XMPP permet nativement l'interconnexion avec les autres réseaux ?

En bref, si vous voulez avoir les mêmes fonctionnalités que Cryptocat, plus tous les avantages de XMPP (interconnexion, gestion de l'historique, profiles, notifications, accusés de réception…) tournez vous vers des clients comme Conversations ou Gajim (et bientôt Movim concernant le chiffrement je vous promet !).

That's all folks !