[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Matrix communication protocol.

From: Msavoritias
Subject: Re: Matrix communication protocol.
Date: Wed, 29 Jul 2020 18:25:36 +0200

   On Fri, Jul 24, 2020 at 11:47, Adonay Felipe Nogueira via
   libreplanet-discuss <> wrote:

   Note: I don't speak for FSF, nor for GNU. Em 23/07/2020 18:56,
   Msavoritias escreveu:

     Guix on system. I am part of the Guix Channel on Matrix.> […] I
     created three channels on my server I know that
     there are some GNU channels on the server but I went
     forth with […] I noticed that there are a lot of GNU projects
     already there. Some of them are GUIX, Octave, Gnunet, a lot of GNU
     channels, Linux Libre and so forth.

   On the subject of channels/rooms, please make sure that these are pure
   Matrix channels by checking the full address, since last time I tried
   (many years ago) with purple-matrix, Matrix itself doesn't tell that
   very easily. Also, make sure that the official pages of the projects
   advertise these channels, if not, they might not be official.

   Fair point. From what I can see there are some that are basically IRC
   bridged channels and some that are native.
   But they don't seem to be advertised so they are unofficial.

     creating one on my server. First for Decentralization reasons. is the biggest server. And second is slow due
     to the number of users there.

     we can al ways set up an IRC bridge to talk with people on the gnu
     IRC server.

   Setting up a bridge means allocating a separate part of the server to
   talk to those protocols. How this communication is made (if a guest
   account is created for every person or if each of them have to manually
   set their own account in case the IRC network has rules to only allow
   participation of registered people) is another set of issues. The best
   option I know of thus far, which also helps non-experienced and
   unregistered users although possibly having some limitations on which
   IRC features will be available, is to set a bot to serve as a message
   relay back and forth between the target channels. Disregarding the
   message relay bot solution, Matrix's bridge services seem to be similar
   to XMPP's. As for the bot, as a Free Software Directory
   reviewer/evaluator, I saw a submission (still unapproved) for one such
   tools, which I'm trying to review as of today.

     Second a lot of new users nowdays expect modern tooling and
     communication. I think integrating a Matrix server will be a great

   Indeed but, let's not forget that the means of communication and data
   interoperability/exchange that are still stable as of today succeeded
   in such a way thanks to one specific kind of standardization that was
   the norm before the growth of the Californian ideology past 2000 (i.e.:
   the term coined by Richard Barbrook and Andy Cameron, not to be
   confused with beliefs of a random person from California). The standard
   in question which resisted is called "open standard", not because it
   simply came from a free/libre and "open source" software project, but
   because it was/is approved by a national or international standards
   body/collective/workgroup — e.g.: internationally we have many
   organizations, including W3C, IETF, ISO, XSF. These standards bodies
   often accept members from different groups so as to make sure that
   everyone has a chance to participate.

   That all sounds great in theory. But in practise from my experience the
   W3C is controlled by Google basically with the browser monopoly they
   have. And POSIX and other stuff have been holding innovation back. That
   happens because of the resistanse to change and the slow beraucracy of
   the process.
   I think we should look into finding striking a better balance between
   standartization and innovation and also having Standard bodies that
   actually listen to everybody.

   These "open standards" can of course be obsolete or not reflect a new
   scenario that arose, this is why the members of the bodies can
   occasionally call on the others to make updated versions, which in most
   cases, even if approved, are in no way immediately mandatory. However,
   when it involves standards "auto-regulated" by their own projects, we
   will occasionally see lots of anomalies, such as: new versions being
   approved as mandatory very fast and thus breaking software which,
   despite being updated, still implement the old version; and other group
   of people making and following a partially compatible parallel standard
   branched from the original (e.g.: original Markdown, GitLab/GitHub
   Markdown, BibTex, BibLaTeX, abnTeX2, abnTeX2cite, BibLaTeX-ABNT). It
   must be noted that even if "open standards" suffer from these anomalies
   — e.g.: WhatsApp which was a XMPP service provider too big (because
   many people recommended it instead of pointing to either a "XMPP server
   list" or a local provider), and so made "FunXMPP" which embraced XMPP,
   extended it, and extinguished XMPP communications); and the many
   non-conforming CSV and vCard implementations —, the original reference
   is not lost and the revision approval has clearly defined process. The
   failure to keep those means of data exchange standardized and
   interoperable opens space to the abuses described in [1].

   It does and I'm not disagreeing with you. But, a lot of the time the
   commitees a lot of the time are so strict to change and so slow a lot
   of contributors don't even try to propose stuff.
   We need to seriously modernize how standards are used and implemented
   if you ask me. But that is not the discussion at hand.

     Also I think having a bunch of semi-official channel using
     Non-FreeSoftware like Riot does't help anybody. […] Disclaimer: I am
     NOT saying to use Riot or any other proprietary client.

   The only free/libre one I have heard so far is purple-matrix for

   There is also an emacs client but it has lagged behind a little bit.

     I would like to ask is it in the works to have an official FSF/GNU
     server in the future? Are there any blockers I can help with?

   FSF already has XMPP service for their associate members.

   I guess it comes down to personal preference but for me I didn't see
   the same features in all the clients I tried and almost all of them
   were badly designed. This doesn't help with convincing people to use

   # References [1]:
   m>, under CC-BY-SA-3.0-US, according to
   * Ativista do software livre *
   [3] * Membro dos grupos
   avaliadores de * Software (Free Software Directory) * Distribuições de
   sistemas (FreedSoftware) * Sites (Free JavaScript Action Team) * Não
   sou advogado e não fomento os não livres * Sempre veja o spam/lixo
   eletrônico do teu e-mail * Ou coloque todos os recebidos na caixa de
   entrada * Sempre assino e-mails com OpenPGP * Chave pública: vide
   endereço anterior * Qualquer outro pode ser fraude * Se não tens
   OpenPGP, ignore o anexo "signature.asc" * Ao enviar anexos * Docs.,
   planilhas e apresentações: use OpenDocument * Outros tipos: vide
   endereço anterior * Use protocolos de comunicação federadas * Vide
   endereço anterior * Mensagens secretas somente via * XMPP com OMEMO *
   E-mail criptografado e assinado com OpenPGP

   _______________________________________________ libreplanet-discuss
   mailing list [4]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]