chevron_right
Contact publication
Juanro · Monday, 5 April, 2021 - 07:05
Se viene soporte de OMEMO en Movim!! https://github.com/movim/movim/issues/63#issuecomment-804704130 #movim #OMEMO
chevron_right
Instant messaging: how to combine communication and freedom in a sustainable way / Part 1: What is the problem?
Yannv · Friday, 29 January, 2021 - 08:35 edit · 5 minutes
Unlike the telephone network - historically managed by a single company in most countries - the Internet consists of tens of thousands of interconnected networks managed globally by service providers: companies, associations, universities, governments and other entities.
The Internet embodies a technical idea: that of an open architecture allowing the connection of heterogeneous networks. This open architecture reflected the founding spirit of the Internet: neutrality, sharing and freedom.
But it is not enough to physically link the networks: a common language is also needed. And it is thanks to the open standards, managed by the Internet Engineering Task Force (IETF), that these heterogeneous networks were able to communicate with each other as a single network. This made it possible to achieve the success we know today.
Thus, in a collaborative research project , universal communication protocols were born which allow access to resources by name (DNS), reading web pages (HTTP), exchanging e-mails (SMTP, IMAP, JMAP) and exchanging messages instantaneously (XMPP).
It is thanks to this that anyone can create content, offer services, exchange products and chat freely without having to ask permission from a central authority!
The first versions of the "current" mail appeared in 1982, and came out of the IETF Network Working Group, in the form of the Simple Mail Transport Protocol (SMTP). Subsequently, mail has evolved by gradually adding new possibilities, while still being accessible to all. This 39-year-old standard is still fully present in everyday life. A simple exchange of e-mails highlights these ideas which have not changed since its origins:
Instant messaging systems soon drifted towards extreme partitioning. The Internet Relay Chat (IRC), which appeared in 1988 as an open standard, successively gave rise to a series of closed protocols, derived from ICQ, AIM, Yahoo messenger and MSN software.
In 2004, the XMPP protocol was standardised by the IETF, finally allowing the emergence of a modern universal standard.
#xmpp in figures
This web includes more than 13 000 servers in the world, bringing together individuals, associations ("La quadrature du net", "l'april", "les chatons" ...), companies, multinationals and governments...
There is a multitude of clients with all kinds of technologies (web, native, in a terminal, etc.), different uses (blogging, sav, games, IOT) and on all types of platforms (Linux, Windows, MacOS, iOS, Android).
Despite the emergence of this modern universal standard, the waltz of messaging software continues: this software is associated with each company's flagship products, all of which are incompatible with each other: Skype, Facebook messenger, Whatsapp, iMessage, Telegram, for the best known.
In their early days, some software, such as Facebook messenger or Skype, were compatible with the XMPP standard. But once the number of users was sufficient, they came out of it to create their closed network.
This fragmentation is so marked that nowadays, users of these different networks are unable to communicate with each other: they are compartmentalised, and can hardly get out of it because of the network effect: they would have to convince all their contacts to switch to another network or to use an open standard protocol to be able to communicate again.
At present, it is sad to observe a plethora of protocols, each one more incompatible than the other. There is no concerted work with the IETF to ensure that everyone can communicate with each other. On the contrary, instant messaging players are forcing their "standards" or voluntarily closing their networks.
The case #signal: technically "free" and "decentralised", but in practice closed and centralised, just like its proprietary counterparts
signal dev I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal.". You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.
wikipedia Signal's developers chose to use a centralised network architecture to provide the service17. This choice is intrinsically political and it is often difficult to place the cursor between security and accessibility. The developers justify their decision by the fact that it is difficult to develop rapidly on decentralised networks, which would not all be up to date and therefore secure. Developers argue that decentralisation is not an end in itself and that it is preferable to hand over metadata to a trusted actor who deletes it, rather than to several potentially unreliable ones39,17.
The sustainability of a communication system is measured by the number of users and the openness of its governance. It is thanks to this that e-mails work everywhere in the world and that you can access web pages independently.
Today, instant messaging, combined with social networks, is increasingly present in everyone's life. The Internet has always been a free space. Alas, the most commonly used instant messaging systems today are building walls that threaten this freedom.
So why not use open instant messaging that respects collectively defined standards?
We would thus be opting for free, universal and borderless communication, reflecting the founding spirit of openness of the Internet.
author : Yann, reading : Ludivine / Hugo, schematics : Mathieu, published on the XMPP network from the #movim web client.
You can comment on this article via the XMPP network by first logging into movim (with your xmpp account or by creating a new one) and going to this address.
chevron_right
Messagerie instantanée : comment allier communication et liberté de manière durable / Partie 1 : Quel est le problème ?
Yannv · Wednesday, 27 January, 2021 - 09:51 edit · 6 minutes
Contrairement au réseau téléphonique -historiquement géré par une seule entreprise dans la plupart des pays- Internet se compose de dizaines de milliers de réseaux interconnectés et gérés mondialement par des fournisseurs de services : des entreprises, des associations, des universités, des gouvernements et autres entités.
Internet incarne une idée technique: celle d’une architecture ouverte permettant de relier des réseaux hétéroclites. Cette architecture ouverte était à l’image de l’état d’esprit fondateur d'Internet : neutralité, partage et liberté.
Mais il ne suffit pas de relier physiquement les réseaux: il faut aussi parler un langage commun. Et c'est grâce aux standards ouverts, gérés par l'Internet Engineering Task Force (IETF), que ces réseaux hétéroclites ont pu communiquer entre eux comme un seul réseau. Cela a permis d'atteindre le succès que l'on connaît aujourd'hui.
Ainsi sont nés, dans un travail de recherche collaboratif, les protocoles de communication universels qui permettent d'accéder à des ressources à partir de leur nom (DNS), de lire des pages web (HTTP), d'échanger des mails (SMTP, IMAP, JMAP) et d'échanger des messages instantanément (XMPP).
C'est grâce à cela que n'importe qui peut créer du contenu, offrir des services, échanger des produits et discuter librement sans avoir à demander la permission d’une autorité centrale!
Les premières versions du mail "actuel" sont apparues en 1982, et étaient issues du groupe de travail "réseau" de l'IETF, sous la forme du Simple Mail Transport Protocol (SMTP). Par la suite, la messagerie a évolué en ajoutant petit à petit de nouvelles possibilités, tout en restant toujours accessible à tous. Ce standard, vieux de 39 ans, est encore pleinement présent dans la vie de tous les jours. Un simple échange de mail met en lumière ces idées qui n'ont pas changé depuis ses origines :
Très vite, les systèmes de messagerie instantanée ont dérivé vers un cloisonnement extrême. Apparu en 1988 comme standard ouvert, l'Internet Relay Chat (IRC) a successivement vu naître une série de protocoles fermés, issus des logiciels ICQ, AIM, Yahoo messenger et MSN.
En 2004, le protocole XMPP a été normalisé par l'IETF, permettant enfin l'émergence d'un standard moderne universel.
#xmpp en chiffre
Cette toile comprend plus de 13 000 serveurs dans le monde, regroupant particuliers, associations ("La quadrature du net", "l'april", "les chatons" ...), entreprises, multinationales et gouvernements...
Il existe une multitude de clients avec toute sorte de technologies (web, natif, dans un terminal, etc..), des utilisations différentes (bloggage, sav, jeux, IOT) et sur tous types de plateformes (Linux, Windows, MacOS, iOS, Android).
Malgré l'émergence de ce standard moderne universel, la valse des logiciels de messagerie continue : ces logiciels sont associés aux produits phares de chaque entreprise, tous incompatibles les uns avec les autres : Skype, Facebook messenger, Whatsapp, iMessage, Telegram, pour les plus connus.
A leurs débuts, certains logiciels comme la messagerie Facebook ou Skype, ont été compatibles avec la norme XMPP. Mais une fois le nombre d'utilisateurs suffisants, ils en sont sortis pour créer leur réseau fermé.
Cette fragmentation est marquée au point qu'à présent, les utilisateurs de ces différents réseaux sont dans l’incapacité de communiquer les uns avec les autres : ils sont cloisonnés, et peuvent difficilement s'en extraire à cause de l’effet réseau: il leur faudrait convaincre tous leurs contacts de basculer vers un autre réseau ou d'utiliser un protocole standard ouvert pour pouvoir de nouveau communiquer.
Actuellement, il est triste d'observer un foisonnement de protocoles plus incompatibles les uns que les autres. Aucun travail de concertation avec l'IETF n'est effectué pour faire en sorte que tout le monde puisse communiquer ensemble. Au contraire, les acteurs de la messagerie instantanée imposent leurs "standards" de force ou rendent volontairement leur réseau fermé.
Le cas #signal : techniquement "libre" et "décentralisé", mais en pratique... fermé et centralisé, tout comme ses homologues propriétaires
signal dev : Je ne suis pas d'accord pour que LibreSignal utilise nos serveurs, et je ne suis pas d'accord pour que LibreSignal utilise le nom "Signal". Vous êtes libres d'utiliser notre code source comme bon vous semble selon les termes de sa licence, mais vous n'avez aucun droit d'utiliser notre nom ou le service que nous gérons.
wikipedia : Les développeurs de Signal ont choisi d’utiliser une architecture réseau centralisée pour assurer le service17. Ce choix est intrinsèquement politique et il est souvent difficile de placer le curseur entre sécurité et accessibilité. Les développeurs motivent leur décision par le fait qu’il est difficile de développer rapidement sur des réseaux décentralisés, qui ne seraient pas tous à jour et donc sécurisés. Les développeurs affirment que la décentralisation n’est pas une fin en soi et qu’il est préférable de remettre ses métadonnées à un acteur de confiance qui les efface, qu’à plusieurs potentiellement non fiables39,17.
La pérennité d’un système de communication se mesure à son nombre d’utilisateurs et à l'ouverture de sa gouvernance. C'est grâce à cela que les mails fonctionnent partout dans le monde et que vous pouvez accéder aux pages web en toute indépendance.
Aujourd’hui, les messageries instantanées, associées aux réseaux sociaux, sont de plus en plus présentes dans la vie de chacun. Depuis toujours, Internet est un espace libre. Hélas, les messageries instantanées les plus utilisées actuellement érigent des murailles, qui constituent une menace à cette liberté.
Alors pourquoi ne pas utiliser une messagerie instantanée ouverte qui respecte les standards définis collectivement?
Nous ferions ainsi le choix d'une communication libre, universelle et sans frontière, à l'image de l'esprit d'ouverture fondateur d'internet.
Comment faire en pratique ? Partie 2 au prochain article :)
auteur : Yann, relecture : Ludivine / Hugo / Peetah, schémas : Mathieu, publié sur le réseau XMPP à partir du client web #movim.
chevron_right
Goodbye, Hexstream
Michał "phoe" Herda · Tuesday, 24 November, 2020 - 12:54 edit · 12 minutes
I am saddened that I need to write this post, but I need to make a public confession.
After Jean-Philippe Paradis, a Common Lisp programmer better known online as Hexstream, requested me to review his "extensive contributions" to the Common Lisp ecosystem, he seems to have disliked my reply so much that he has declared me the single biggest threat to the Common Lisp community right now.
(A gist copy of the review is here for people who would rather avoid browsing the full issue.)
The review has appeared after yet another discussion thread on GitHub - originally about implementations of Clojurelike arrow macros in Common Lisp - has been derailed by Hexstream in the traditional way in which he derailed many [1] other[2] GitHub[3] discussions[4]: asserting as a logical fact that his preferences take precedence over other people's preferences, aggressively calling out other people for questioning this state of matters, and finally playing the victim card of being silenced, censored, and tortured by a so-called Common Lisp Mafia.
Unlike during the past few times, this time I have decided not to give up posting. On the contrary, I have spend a considerable amount of my personal time (including one all-nighter) to actually respond to every single post of Hexstream, analyze it, take it apart into individual claims that he is making, and refute every single false point that I could find to the best of my ability using the full extent of my available tools.
After several posts of increasing angriness exchanged with Hexstream, in which discussion I have once again tried to coerce him into changing his course and stop being an aggressive offender towards members of the Common Lisp community, and after being explicitly invited to analyze Hexstream's contribution to the Common Lisp community in a tweet of his, I replied to his request with an analysis of the public data collected from GitHub, Quicklisp and Hexstream's public CV. Hexstream has announced multiple times that he is proud of this information and there is nothing to hide there; no, quite the contrary. Hence, I felt welcome to use it and see for myself what kinds of prominent contributions of his I must have missed.
It seems that my analysis of that data was not well-received; Hexstream disappeared with a mere "see you in 2021" comment, stating that he has projects with higher priorities to work on at the moment, and simply replied on GitHub that "my posts contain countless factual, logical and other errors". Afterwards, his Twitter contained this.
Welp.
(with-irony "
It seems to me that I must have thought the unthinkable. (How could I have said that he is not a Common Lisp expert and a fraud? How was it even possible!?) Moreover, I then dared to say it aloud. Worst of all, I even backed it all with solid, concrete, data-based evidence that cannot be immediately refuted as a mere opinion and requires some serious figuring out of how to turn it around so that the Common Lisp Mafia is guilty for all the facts that I've noted.
All of a sudden, after posting this single post, I have become the main threat to the whole Common Lisp community, declared impossible to directly and indirectly fund in an ethical manner, and then proclaimed to require immediate medical attention of psychiatric nature.
Oh goodness. I assume that the analysis must have been way too short for his liking. I regret that I have not found the time to go into his GitHub issues in detail...
")
So, Hexstream. If you're reading this, I hope that my review serves as a proper wake-up call for you to actually see that your behavior is off and needs adjustment in order for other people to actually consider you acceptable in the Common Lisp community. If it does not, I have done everything to actually try and help you as a fellow Common Lisp hacker. I can, and will, do no more in this matter, and will instead do everything to protect the people I respect, like, and cooperate with from your destructive influence.
You are planning to launch some kind of Common Lisp Revival 2020 Fundraiser soon. I would like to tell you that I consider you to be the wrong person to launch one: not even for any of the aforementioned reasons, but for the reason that to you, Common Lisp seems to be a completely different language than it is to me. Based on the above review that you have requested me to do, it seems that you perceive Common Lisp as a strictly single-player language where you have to struggle against countless feats and enemies on Twitter, GitHub, and wherever else, in order to produce anything of even the smallest value after grand feats and massive effort to struggle against censorship.
On the contrary, I know many people who consider Common Lisp to be a multiplayer language where people support one another, are eager to help each other, share knowledge, indulge in fascinating projects that would be tough to indulge in with other languages and, best of all, are not hostile towards one another at the smallest hint of suspicion. Some of those people form the Common Lisp Foundation that, in my opinion, should take over any kind of Common Lisp revival fundraisers.
Obviously, all other reasons from my analysis why you are not entitled to represent the Common Lisp community as head of such a fundraiser still apply. And they are much more damning than the worldview issue above.
And to top it all, after the above analysis was posted, instead of fulfilling my hopes and responding to this critique of your Lisp merit by indulging in meritocratic discussion about your technical contributions to the Common Lisp ecosystem, you instead immediately announced that I require psychiatric help.
For completeness, I do have to admit: you have been popularizing crowdfunding among Lispers and achieved visible success there, with multiple authors and repositories adopting various means of crowdfunding (GitHub Sponsors, Patreon, LiberaPay) thanks to your efforts and suggestions. This is the one single thing that I can unambiguously consider a net positive coming from you. That's all.
Other than that, I do have to repeat what I have said at the end of my analysis. You try to pose as a Common Lisp expert. No, with all of the above I have no reasons to claim that you are one. Your expertise is hollow. Your experience seems false. You pretend to be someone you are not. You are a scam, Hexstream, and I am saddened and torn that I need to speak these words because I sincerely wish you were not.
The earliest Lisp commit that I was able to find in my GitHub repositories is from November 2015. That is exactly five years ago. In 2015, I was getting frustrated over Emacs keybindings. In 2015, you were "exposing" Zach Beane. Through these five years, I was learning Lisp to the best of my ability. Through these five years, you were doing I have no idea what. I can only guess based on what I see.
And I see Twitter rants. I see GitHub issue derailments. I see self-announced policies that contradict one another. I see tiny Lisp libraries with zero users. I see no other Lisp code of yours. I see no code of yours in any other GitHub repositories. I see big claims backed by nothing. I see an image of a Common Lisp expert that is so fragile that it falls into pieces after a brief glance.
Seriously, what were you doing with your life during these years? Researching ethics? Verifying the boundaries set by Twitter and GitHub moderation teams? Fighting for your life while the Common Lisp Mafia caged you and demanded a ransom of 20,000,000 US parentheses for your freedom?
I simply cannot comprehend it. And I do feel sorry for you, since most likely neither can you.
If you are still reading, please answer one question that I will ask at the end of this block of text. I will attempt to be somewhat honest regarding myself in the topic of my own impact on the Common Lisp community, as I see it. No boasting too much, not being too humble. Let's try it.
I have attempted to complete the Common Lisp UltraSpec which I talked about at an European Lisp Symposium one time and then failed miserably at this task after grossly misestimating it. I have implemented package-local nicknames in Clozure Common Lisp and then used the momentum from that work to make a portability library for package-local nicknames. I have managed to rewrite and optimize the somewhat famed split-sequence system commonly used in the Common Lisp ecosystem. I have managed to overhaul the even more famed Lisp Koans by rewriting them almost from scratch and fixing multiple compliance errors. I have successfully convinced Massachusetts Institute of Technology to release the Common Lisp WordNet interface under a permissive license (which took only half a year of pinging people via mail) and fixed it up as appropriate. I have written a utility suite for managing protocols and test cases with some documentation that I am proud of even after two whole years. I wrote an implementation of Petri nets in Common Lisp that seems either to work fine or not to be used at all, because I do not get much attention from it; still, I've tested it (hopefully) well enough to be useful in the general case. I recently wrote the fastest priority queue available in Common Lisp after someone mentioned that the ones on Quicklisp are too slow. I then ended up miserably failing at rewriting the Common Lisp arrows system, which resulted in a different system with a tutorial for arrows that I have received several thanks for. And then there's some smaller libraries that might not be all that mentionworthy.
I have been hosting the Online Lisp Meeting series which have met general acclaim and popularity and are considered a worthy continuous extension of the ideas of the European Lisp Symposium - even if, in my opinion, they contain a bit too much CL content, compared to the ELS ideals and statistics. The eleventh installment is bound to happen this week, where I will speak for the second time - again about the topic of control flow and condition systems. I already have two more talks queued up and we plan on going until the next European Lisp Symposium, which will most likely eat up all of the available talks and then some. (Maybe some of the rejected papers will sublimate as OLM videos though?... I sincerely hope so! ELS recently had to reject papers not because they were bad, but because they had an already full schedule.)
With help of countless people helping me on various stages of the book lifecycle and with support from Apress Publishing, I have managed to release the book The Common Lisp Condition System along with a pair of accompanying Common Lisp systems, the larger Portable Condition System and the smaller trivial-custom-debugger, plus a release of source code from the book and a free online appendix to the book containing content that did not make it inside in time. I have also proven that the condition system can be easily implemented in a non-Lisp, which is Java, and I will talk about this in extent to the WebAssembly committee to ensure that WASM has all the necessary functionalities to ensure that Common Lisp can be efficiently implemented on WASM.
Finally, I made some art once. I think it did not sting anybody's eyes too hard. Or that it's strictly Lisp-related too much... but hey, it's CL implementations, and the Lisp Lizard.
I think I am generally tolerated and maybe even enjoyed in my community as a Common Lisp programmer, despite my occasional outbursts of frustration and outright stupidity. I try to be available on Reddit, IRC, Discord, and in private messages for all sorts of support that I am capable of providing. I try to teach other people the way I was taught when I was starting out. Whenever I notice that I should apologize and make amends because I fucked up somewhere (e.g. in the recent Quickdocs issue), I do try my best to be sorry and amend my behavior as appropriate, and I try to welcome other people's remarks and inegrate them into my behavior as appropriate; I think it helps other people tolerate my behavior when I'm not easily tolerable.
And, well, you know, there is this single person in my environment who just keeps on smearing shit on people in my vicinity, but I don't think I care anymore; this person has willingly made so many enemies by now, that they are ignored by many, confronted by few (who actually have some time to spare), and hell, I even got some most unexpected people to cheer me on in my attempts to actually try and confront this guy and his bullshit excuses for repeatedly setting fires in the Common Lisp world.
But, yeah, anyway. You still consider that it's me who needs psychiatric help. Is that right?
So, Hexstream, this is a goodbye. Thank you for the unique chance to train my patience, persistence, and insistence. I assure you that it has not gone to waste, and I assure you that I will remember it for the rest of my life.
Since you do not seem to want to change your behavior in the slightest, then I wish you to stay on your current course and not change in the slightest so you may see for yourself where it leads you. The faster you slide into irrelevance because of your current choice, the healthier the Common Lisp community will be.
(And I mean the real Common Lisp community, containing more than just a single person who's purely accidentally named Jean-Philippe.)
Bye. I don't think I will miss you much, even though I adore the technical thought behind some of your libraries. And if I encounter you again on the Internet, be prepared to once again meet the side of me that has long run out of spare chances to give you anymore.
chevron_right
If you ever think about using Electron
debacle · Monday, 28 January, 2019 - 00:25 edit · 1 minute
If you ever think about using Electron for your next application, think twice. Or thrice. It's probably a bad idea:
Github user miksuhwrites:
It is an really bad idea to use Electron. Electron is completely 100% inaccessible and unusable with the Orca screen reader on Linux. None of the Electron applications work with the Orca screen reader. All of the Electron applications are completely unusable if you are visually impaired or blind like I am. Orca screen reader speaks absoletely nothing when you try to use Electron based applications. Electron is based on Chromium technology. Chromium web browser is also completely inaccessible and unusable with the Orca screen reader. During the last 10 years people have requested several times that Chromium developers should start to support the Orca screen reader. But nothing has happenened. People have requested the same from Electron developers but nothing has happened. Chromium and Electron are still completely inaccessible and unusable. Blind users like me must use computer using screen reader which speaks the content on scree. blind and other visually impaired people can not use any Electron applications because Electron does not work with the Orca screen reader. It also looks like situation will not change, looks like Chromium and Electron developers have no plans to supoort the Orca screen reader. There is now applications like Skype which is made using Electron. Because of that Skype on Linuxx is completely inaccessible and unusable if you are visually impaired. So visually impaired users can not use e.g Skype or e.g Signal on Linux. that is simply discriminitaing visually impaired users. So no, use of Electron is not ok.
#orca #accessability #a17y #blind #visuallyimpaired #electron #signal #chromium #screenreader #jaws
chevron_right
HOWTO: Emacs + ECL on Android
Michał "phoe" Herda · Sunday, 23 December, 2018 - 12:02
(This is a repost of an old blog post of mine from Teknik.)
apt install build-essential clang to install the compiler backend that ECL requires.apt install emacs. Install spacemacs or download your favorite emacs configuration./etc/apt/sources.list.apt install ecl. If you are on 32 bits, run apt install ecl-ext to install ecl-ext, which is a 32-bit version of ECL with threads enabled.(setf inferior-lisp-program "ecl").emacs and M-x slime.If the above does not work for you, please drop me a line at phoe@teknik.io and I'll fix it.