• chevron_right

    Paul Schaub: Re: The Ecosystem is Moving

    Timothée Jaussoin · Tuesday, 31 December, 2019 - 08:16

A really nice response to Moxie Marlinspike conference 😃

  • reply chevron_right

    Paul Schaub: Re: The Ecosystem is Moving

    Moxie Marlinspike, the creator of Signal gave a talk at 36C3 on Saturday titled “The ecosystem is moving” . The Fahrplan description of that talk reads as follows: Considerations for distributed and decentralized technologies from the perspective of a product that many would like to see decentralize. Amongst an environment of enthusiasm for blockchain-based technologies, efforts to decentralize the internet, and tremendous investment in distributed systems, there has been relatively little product movement in this area from the mobile and consumer internet spaces. This is an exploration of challenges for distributed technologies, as well as some considerations for what they do and don’t provide, from the perspective of someone working on user-focused mobile communication. This also includes a look at how Signal addresses some of the same problems that decentralized and distributed technologies hope to solve. Basically the talk is a reiteration of some arguments from a blog post with the same title he posted back in 2016. In his presentation, Marlinspike basically states that federated systems have the issue of being frozen in time while centralized systems are flexible and easy to change. As an example, Marlinspike names HTTP/1.1, which was released in 1999 and on which we are stuck on ever since. While it is true, that a huge part of the internet is currently running on HTTP 1.0 and 1.1, one has to consider that its successor HTTP/2.0 was only released in 2015. 4 / 5 years are not a long time to update the entirety of the internet, especially if you consider the fact that the big browser vendors announced to only make their browsers work with HTTP/2.0 sites when they are TLS encrypted. Marlinspike then goes on listing 4 expectations that advocates of federated systems have, namely privacy, censorship resistance, availability and control. This is pretty accurate and matches my personal expectations pretty well. He then argues, that Signal as a centralized application can fulfill those expectations as well, if not better than a decentralized system. Privacy Privacy is often expected to be provided by the means of data ownership, says Marlinspike. As an example he mentions email. He argues that even though he is self-hosting his emails, “each and every mail has GMail at the other end”. I agree with this observation and think that this is a real problem. But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right? This is not really an argument for centralization, where each and every message is guaranteed to have the same service at the other end. I also agree with his opinion that a more effective tool to gain privacy is good encryption. He obviously brings the point that email encryption is unusable, (hinting to PGP probably), totally ignoring modern approaches to email encryption like autocrypt . Censorship resistance Federated systems are censorship resistant. At least that is the expectation that advocates of federated systems have. Every time a server gets blocked, the user just simply switches to another server. The issue that Marlinspike points out is, that every time this happens, the user loses his entire social graph. While this is and issue, there are solutions to this problem, one being nomadic identities . If some server goes down the user simply migrates to another server, taking his contacts with him. Hubzilla does this for example. There are also import/export features present in most services nowadays thanks to the GDPR. XMPP offers such a solution using XEP-0277 . But lets take a look at how Signal circumvents censorship according to Marlinspike. He proudly presents Domain Fronting as the solution. With domain fronting, the client connects to some big service which is costly to block for a censor and uses that as a proxy to connect to the actual server. While this appears to be a very elegant solution, Marlinspike conceals the fact that Google and Amazon pretty quickly intervened and stopped Signal from using their domains. With Google Cloud and AWS out of the picture, it seems that domain fronting as a censorship circumvention technique is now largely non-viable in the countries where Signal had enabled this feature. Notice that above quote was posted by Marlinspike himself more than one and a half years ago. Why exactly he brings this as an argument remains a mystery to me. And even if domain fronting was an effective way to circumvent censorship, it could also be applied to federated servers as well, adding an additional layer of protection instead of solely relying on it. But what if the censor is not a foreign nation, but instead the nation where your servers are located? What if the US decides to shutdown for some reason? No amount of domain fronting can protect you from police raiding your server center. Police confiscating each and every server of a federated system (or even a considerable fraction of it) on the other hand is unlikely. Availability This brings us nicely to the next point on the agenda, availability. If you have a centralized service than you want to move that centralized service into two different data centers. And the way you did that was by splitting the data up between those data centers and you just halved your availability, because the mean time between failures goes up since you have two different data centers which means that it is more likely to have an outage in one of those data centers in any given moment. Moxie Marlinspike in his 36c3 talk “The Ecosystem is Moving” For some reason Marlinspike confuses a decentralized system with a centralized , but distributed system. It even reads “Centralized Service” on his slides… Decentralization does not equal distribution. A federated system would obviously not be fault free, as servers naturally tend to go down, but an outage only causes a small fraction of the network to collapse, contrary to a total outage of centralized systems. There even are techniques to minimize the loss of functionality further, for example distributed chat rooms in the matrix protocol . Control The advocates argument of control says that if a service provider behaves undesirably, you simply switch to another service provider. Marlinspike rightfully asks the question how it then can be that many people still use Yahoo as their mail provider. Indeed that is a good question. I guess the only answer I can come up with is that most people probably don’t care enough about their email to make the switch. To be honest, email is kind of boring anyways XMPP Next Marlinspike talks about XMPP. He (rightfully) notes that due to XMPPs extensibility there is a morass of XEPs and that those don’t really feel consistent. The XMPP community already recognized the problem that comes with having that many XEPs and tries to solve this issue by introducing so called compliance suits. These are annually published documents that contain a list of XEPs that are considered vitally important for clients or servers. These suits act as maps that point a way through the XEP jungle. Next Marlinspike states that the XMPP protocol still fails to be a suitable option for mobile devices. This statement is plain wrong and was already debunked in a blog post by Daniel Gultsch back in 2016. Gultsch develops an XMPP client for Android which is totally usable and generally has lower battery consumption than Signal has. Conversations implements all of the XEPs listed in the compliance suits to be reuquired for mobile clients. This shows that implementing a decent mobile client for a federated system can be done and there is a recipe for it. What Marlinspike could have pointed out instead is that the XMPP community struggles to come up with a decent iOS client. That would have been a fair argument, but spreading FUD about the XMPP protocol as a whole is unfair and dishonest. Luckily the audience of the talk didn’t fully buy into Marlinspikes weaker arguments as demonstrated by some entertaining questions during the QA afterwards. What Marlinspike is right about though is that developing a federated system is harder than doing a centralized service. You as the developer have control over the whole system and subsequently over the users. However this is actually the reason why we, the community of decentralized systems and federated protocols do what we do. In the words of J.F. Kennedy, we do these things… …not because they are easy, but because they are hard…

    group_work PlanetJabber 29 December, 2019

  • favorite

    5 Like

    dumb bird , mirabilos , debacle , Marzanna , rydroid


  • 23 December, 2019 rydroid

    Salut. Y a t'il une option pour l'utilisateur/utilisatrice permettant de désactiver l'inclusion automatique de contenu tiers ? Là j'ai mon fichier hosts qui redirige vers localhost et ça évite d'envoyer une requête à un de mes grands amours (tout en étant moins consommateur de ressources), mais j'aimerais idéalement bien que l'outil me protège par défaut plutôt que l'inverse.

  • chevron_right

    Movim 0.16.1 – Cesco

    Timothée Jaussoin · Friday, 6 December, 2019 - 09:51

Here we go, 0.16.1 released 😉🎉

  • reply chevron_right

    Movim 0.16.1 – Cesco

    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 :) Communities layout were a bit redesigned, publication rules are now displayed clearly in the right column and the header shows more information on mobile. All the messages that you sent in the one to one discussions can now be edited. 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

    group_work Movim 6 December, 2019

  • favorite

    8 Like

    Nicolas Vérité , Miguel A. Arévalo , Marzanna , Orbifx , togart , togart , prasoonkumar , SFPG Online


  • person

    6 March, 2020 prasoonkumar

    \\\\ Yeah . . . . !!

  • chevron_right

    Le monde du logiciel est en train de se détruire... Manifeste pour un développement plus durable

    Timothée Jaussoin · Sunday, 1 December, 2019 - 22:25 edit · 1 minute

Je tiens à vous partager ce super article qui résume parfaitement mon point de vue sur le monde du logiciel.

Après avoir passé 5 ans en tant que développeur "professionel" (rémunéré) dans le monde du Web (et environ 10 de façon non rémunéré), je suis personellement fatigué de celui-ci.

Je suis fatigué de sa complexité, du fait que nous tournons en rond:

  • le Cloud n'est qu'une version moderne des mainframes, partager les resources et le temps pour mutualiser les coûts
  • le "nouveau" language/framework qui permettra de développer qu'une fois et déployer partout, nous avons eu Java, Qt, et maintenant React Native ("partout étant Android et iOS…) ou des trucs moches comme Electron

Les couches et couches et couches de technologies qui au final ne font que n'ajouter de la complexité sur un problème qui ne devrait pas être là en premier lieu.

L'intégralité de la partie chat de Movim tiens dans un fichier en pure Javascript de moins de 1000 lignes. Je n'utilise strictement aucune dépendances. Ce chat gère les emojis, l'édition des messages, le regroupement des bulles, l'historique, les salons de discussion, les pièces jointes, les stickers, les séparateurs de lecture/de journée… soit des fois plus de fonctionnalités que des applications comme Slack, Mattermost ou autres qui pèsent des dizaines de mégà.

Au final nous ne redéveloppons que les mêmes outils, les mêmes solutions, de façon plus lourdes et plus lentes. Pourquoi nous faut-il télécharger des dizaines de méga de données pour lire un article ou pour réserver un billet de train là où il nous fallait que quelques dizaines de ko il y a a peine 20 ans?

De mon coté je vais essayer de continuer, un temps, ce travail, en essayant de choisir les entreprises qui font tout pour éviter ça. Je vais aussi continuer à essayer de montrer qu'il est possible de faire des logiciels novateurs, léger et fonctionnels tout en étant léger et performants.

  • chevron_right

    Timothée Jaussoin · Monday, 18 November, 2019 - 05:31

    Here we go, Movim 0.16 – Cesco finally released PARTY POPPER

  • reply chevron_right

    Movim 0.16 – Cesco

    A bit less than 4 months after the previous 0.15 release we are pleased to announce the release of the 0.16 version of Movim. This release comes like always with both new exciting features and performance improvements. But for this one we focused more on making the general usage more accessible and bringing some useful features in. What's new? Drawing and content sharing Thanks to the awesome collaboration with my girlfriend this release comes with a totally new feature that will allow you to draw quickly something over a picture you just took or a blank canvas. Those drawings can then be published within chat discussions or as publications. The Snap feature was slightly redesigned to integrate with the Draw feature, you can also now switch between different cameras if multiple are detected (useful on mobile phones). The camera switching feature was also integrated in the video-conferencing system allowing you to switch from your front and back views within a video-conference. Attachments The attachments menu in the chat panel was redesigned to integrate this new Drawing feature while keeping the UI clean and accessible. Chat improvements Movim now integrates a quick #emoji insertion feature 😱😍 in the chat discussions. When writing a message you can directly type the emojis code using its related :shortcut:. On desktop some work was also done to do all this process using only the keyboard. Chats and chatrooms list improvements The chats and chatrooms list now displays more information about the currently opened discussions: The chatstates (to know if the contact or one of the rooms occupants is currently typing a message) are displayed in real-time Movim is showing if the last chat message was sent by you The chatrooms are now displayed with a specific icon if they can be publicly discovered and if the occupants can see each-other public profiles (some issues were also fixed regarding the handling of those information backend wise). This allows the users to know more clearly what are the risks of discussing within a room and for the admins to change the rooms configurations regarding their privacy needs. Big refactoring of how the XMPP clients and servers capabilities are handled This is one of the biggest internal changes that was made for this release. On the XMPP network, the clients and servers are telling each-others what they are capable of. This allows, for example, for a client to know if a server supports file upload to display the feature automatically in the UI. Movim was handling very weirdly the content of those capability information for several years. The related code was heavily refactored fixing some features detection issues and adding some new features for the users. Movim now displays all the connected clients of all your connected contacts. This allows you to call a device specifically if your contact can be reached on several clients that supports the video-calling feature. Search The search panel was improved and now allows you to search in Communities. It is also faster to load (especially on mobile) and displays more reliable results especially for tags results. Slight design changes The general design and animations were slightly changed to allow more content to be displayed (some padding were removed in the chat to display more information within the discussion bubbles) or to make the UI a bit more snappy. Performances Last but not least! New features don't mean performance hit. Two big performance improvements were introduced in this release. A small database change that was overseen until now allows Movim to load chat messages way faster if you have hundreds of thousands (or even millions) of records stored. The upgrade of one of our dependencies, reactphp/http, improved the overall speed of around 10 to 20% (especially during the connection and during page switching). This allows Movim to stay around or bellow 300ms for most of the pageloads. What's next ? For the next release some work is planned to support the PHP 7.4 version and to boost code regarding the new performance features that are coming with this exciting release (especially with the Preloading feature). Some new XMPP extensions such as XEP-0424: Message Retraction and XEP-0425: Message Moderation are also planned. We will see if those changes will come into a minor 0.16.1 release or a major 0.17 release. In the meantime we hope you'll enjoy all those new features and keep spreading Movim around. You can also support us by giving a bit of money monthly on our Patreon. This allows us to cover our expenses (servers, domains) and to create some goodies (I heard that some new stickers are planned). That's all folks!

    group_work Movim 18 November, 2019

  • favorite

    4 Like

    eyome , debacle , Marzanna , Nicolas Vérité

  • chevron_right

    Contact publication

    Timothée Jaussoin · Wednesday, 16 October, 2019 - 16:05 edit

"Les SUV, deuxième cause d'augmentation des émissions de CO2".
Mais, mais, mais. Il y a un filtre et il est Crit'Air Éco Bio Planet+ :(
#greenwashing #environnement #makeourplanetgreatagain #suv #velo #transports
  • Les SUV, deuxième cause d'augmentation des émissions de CO2

    Les SUV, gros véhicules urbains très populaires, ont été la deuxième source d'augmentation des émissions de dioxyde de carbone (CO2) dans le monde entre 2010 et 2018, selon le directeur de l'Agence internationale de l'énergie (AIE). Plus de 200 millions de SUV circulent aujourd'hui dans le monde, contre 35 millions en 2010, une tendance que l'on retrouve partout, relève en effet l'AIE dans une note parue mardi. «Ces dix dernières années, les SUV ont été la deuxième source de croissance des émissions de CO2», a affirmé, lors d'une conférence internationale sur l'électrification de l'énergie à Paris, son directeur. Après le secteur de l'énergie, mais avant l'industrie lourde (acier, ciment...), les poids lourds ou l'aviation. Souvent plus lourds et moins aérodynamiques, ces véhicules consomment un quart d'énergie en plus par rapport à une voiture de taille moyenne, souligne le rapport. «Si l'appétit des consommateurs pour les SUV continuait de croître au rythme de cette dernière décennie, ces voitures ajouteraient près de 2 millions de barils par jour à la demande mondiale de pétrole d'ici 2040, annulant les économies permises par 150 millions de voitures électriques», prévient le rapport, qui souligne aussi que «des voitures plus grosses et plus lourdes comme les SUV sont plus difficiles à électrifier».