matrix client
Is there a matrix client that you would recommend for running on Trisquel?
I am a translator!
Pidgin supports Matrix via a plug-in. How well it works I do not know.
The developers of Element maintain a .deb repository. https://element.io/get-started gives these commands, to be executed in a terminal:
$ sudo apt install -y wget apt-transport-https
$ sudo wget -O /usr/share/keyrings/riot-im-archive-keyring.gpg https://packages.riot.im/debian/riot-im-archive-keyring.gpg
$ echo "deb [signed-by=/usr/share/keyrings/riot-im-archive-keyring.gpg] https://packages.riot.im/debian/ default main" | sudo tee /etc/apt/sources.list.d/riot-im.list
$ sudo apt update
$ sudo apt install element-desktop
As Magic Bannana stated there is Element. I use it on Trisquel 9.0 with no issues so far.
Sweeeeet. thanks!
I use element for precise and complex tasks like encryption and nheko-reborn as a lightweight client for a day to day use. https://nheko-reborn.github.io/
I also use matrixcli for minimalistic operations and saving conversations to a text file.
https://github.com/ahmedsaadxyzz/matrixcli
I find Matrix problematic.
https://www.hackea.org/notas/matrix.html [onion]
Do you have more information about it?
[onion] http://hackeavw7lge3rj7vwfewaaid7akgmys2vlqggeirtorcg5g6zoawzqd.onion/notas/matrix.html
I have a feeling that you have just unearthed the last conspiracy theory, as a NYE treat.
"We have not done a serious fact-checking on every piece of information we have found, so we will not consider whether Matrix has any relationship with any intelligence agency or not." To put it short, this is FUD.
I have some criticisms of Matrix, but the article you link to is filled with misleading innuendo.
> On the Internet we find many pieces information connecting Amdocs with Israel’s Intelligence. We do not know if it is because they wanted to wash their image, but allegedly Amdocs does not own the project anymore. A new organization, New Vector, was created for Matrix.
This makes it sound like Amdocs created New Vector as some sort of puppet startup that is under their control. Amdocs simply abandoned the project and stopped funding it, as companies often do, after which the Matrix devs started their own company to continue development.
> We have not done a serious fact-checking on every piece of information we have found, so we will not consider whether Matrix has any relationship with any intelligence agency or not.
This is a cute little way of saying "We want to plant the thought in your head that Matrix is working with an intelligence agency, but we don't have any evidence, so we're just going to say that we're *not* saying that."
> In September 2018 Disroot decided to close their Matrix service and go back to XMPP. They gave several reasons, the main one: Privacy.
Disroot scaled back their Matrix server in 2018, closing it to new registrations and only retaining chat logs for three months. Their review of Matrix was not entirely negative, including with regard to privacy.
"While the Matrix protocol is also taking the user's privacy seriously, it seems like its architectural focus is directed elsewhere, valuing usability over privacy."
=> https://disroot.org/en/blog/matrix-closure
Disroot did eventually shut down its Matrix server entirely this month, but the reason was that it was a resource hog. It had nothing to do with privacy issues.
> In 2019, The Grid protocol community published their Notes on privacy and data collection of Matrix.org, a document which helps us assess what the extent of the problem is
Grid protocol is a competitor to Matrix, and based on the comments below the Github notes linked to, it seems author of them has a personal beef with Element (formerly New Vector). But I did read the updated version, which apparently has some corrections (I did not read the original).
=> https://github.com/libremonde-org/paper-research-privacy-matrix.org
It does raise some valid concerns, but it seems that Element has since addressed the main ones.
=> https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4/
Your link acknowledges that this blog posts exists, but says
> We have not read it. We do not think it is worth wasting more time.
Ok then.
Thank you for your inputs.
> => https://github.com/libremonde-org/paper-research-privacy-matrix.org
Yes, that report shows where the problem is.
I find problematic that a software, which is supposed to be decentralized, is released sending such a huge amounts of private data to their central servers.
I agree that Riot's behavior was problematic at the time that that report was written. According to Matrix, they have since made changes in order to address many of the issues raised in that report.
=> https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4/
The author of the report has not, as far as I know, done another evaluation and published an update since these changes were made, so it does not necessarily accurately reflect the current situation.
Hello,
I appreciate those that have the knowledge.
Let me ask about something that confuses me regarding the "privacy".
I read from some entity invoking Snowden that "everything requires trust; nothing deserves it."
I heard someone invoking the 'Z'man, that there is no privacy, "get over it."
How would these statements fit in with hypotheses of conspiracy?
Thanks.
> everything requires trust; nothing deserves it
I don't know what the context of this quote is. Some amount trust is necessary in order to have a society. Without society we can't work together to create complex things like computers, so any discussion of computing is only worthwhile if we accept the necessity of trust, in which case our goal is not to eliminate trust, but to manage it effectively.
> that there is no privacy, "get over it."
This is a defeatist, anti-privacy attitude, and it's not based in reality. There is still much people can do to protect their privacy individually. There is also much that governments can do protect privacy broadly. Declaring privacy dead discourages these actions, so it's a harmful attitude.
No tool can guarantee you perfect privacy in all possible situations, but you don't need it to. What you need is adequate privacy in the situations that you personally encounter. Someone like Snowden needs to worry about targeted surveillance by powerful state actors, which calls for extreme measures to defend against. Most people should be primarily worried about mass surveillance, which requires a different, less extreme set of measures to defend against.
> How would these statements fit in with hypotheses of conspiracy?
I don't know. I think we still have a lot of non-hypothetical problems that need solving. We should smart in how we go about solving them, which means not putting all of our eggs in one basket, especially when that basket is a VC-backed startup, so I'm in favor of taking things slow with Matrix and continuing to pursue other approaches in parallel, but I don't find the conpsiracy theories helpful. Again, we need some limited amount of trust in order to function as a society, which we lose if we endlessly speculate about everyone's motivations.
In fact I find amuza's worries quite sane. It does not sound wise to blindly trust a tool just because someone wrote somewhere that it was cool, or even secure - in what sense, and how deep did they check?
Since we need to trust someone, we should focus on choosing who we decide to trust in order to keep communicating. Would you trust more your close friends on a fully peer-to-peer network, or some unknown person somewhere in charge of a server, providing federated services?
My personal answer would be that in both cases I would need to check what the software is actually doing, or read expert reviews before even suggesting anyone to give it a try. I could never be sure about what Matrix was actually doing so I chose to focus on other options. That does not mean that Matrix is the ultimate evil plan to subvert privacy, nor that these other options are the Grail of privacy protection.
> someone invoking the 'Z'man
Would that be Zorro or Zapata? Or Frank Zappa maybe? Or is it a reference to some meta-sequel of the X-men in the making?
> hypotheses of conspiracy
You will find that there is in general no conspiracy, but people quite openly taking advantage of the ignorance and/or laziness of others. How would you call a conspiracy in broad daylight?
> the 'Z'man
Last guess: Tom Zenk?
Hello Chaosmonk,
>Some amount [of] trust is necessary in order to have a society.
In that I agree in the highest. And the paraphrase could be relevant to the ultimate negative consequence.
There was the question of privacy posted. And then the pivot to "conspiracy theory," privacy being the concern.
>...non-hypothetical problems...
Not intending to be argumentative, please consider that whether or not something is actually a [real] problem is hypothetical, subjective.
I'll be succinct to the extent I am capable, only trying to address the question of privacy and whether the above links should be considered as possibly having any useful or utile information to be gleaned.
Conspiracy is not a theory.
The ability to conspire at great length, along with the ability to sew trust enough to form human society, which is itself a conspiracy, is our greatest asset of survival in a harsh physical environment.
Conspiracy underlies everything we do, even right here on this forum.
The asset skill goes all of the way back to escaping the confines of the cave. Or, it is in our DNA.
My question is what if we can't trust anything, but because of what you pointed out, we must?
And if that, then where ought we most fruitfully focus our energies regarding concerns over our privacy?
I have not read anywhere that any communications in any medium are guaranteed safe and private.
Apparently, open source means code can be examined. However, I see many applications where it is admitted that the code has not been examined thouroughly in years.
And then, how could I or anybody be certain that the examiner(s) was not up to no good? Not to mention the "zero day" codes (if those are real or defeatism invoking propaganda) that can be missed by the best auditors.
Again, I appreciate that there are knowledgeable experts with encyclopedic knowledge here to help us get these gnu operating systems functioning. I like using Trisquel.
> My question is what if we can't trust anything, but because of what you pointed out, we must?
A decision to trust is a calculated risk. Whether you should trust someone or something depends on whether the benefit of doing so is worth the risk.
Most people do not grow their own food or build their own automobiles. This comes with the benefit of not having to do those things. It also comes with some risks. They must trust that their food is not poisoned, and that car does not have a dangerous defect. Governments can mitigate these risks with regulations. Invididuals can sometimes mitigate these risks with their purchasing decisions. But some risk is still there. That is the tradeoff we make in order to cooperate as a society.
Computing is no different. I use XMPP. Since I don't run my own XMPP server, this requires me to trust that the owner of the server I use, and that the owners of the servers used by people I communicate with, are not malicious or incompetent. I can mitigate this risk in various ways, such as by using end-to-end encryption. Ideally my government would help mitigate the risk with stronger privacy regulations. But some risk will always be there. E2EE does not encrypt metadata, and people do not always follow the law. The benefit is that I do not have to run my own XMPP server and refuse to communicate with people who do not do the same. For me, this is a worthwhile tradeoff. I choose to place a certain amount of trust in the owners of XMPP servers I interact with, accepting a certain amount of risk in order to enjoy certain benefits.
As I said, trust is necessary to have a society. However, one way to make society safer is to improve the design of the systems we rely on so that trust is harder to abuse. Since I want society to be safer, I want to support efforts to do this. A defeatist attitude would not be helpful, so I don't adopt one.
Hi there :)
Thank you so much Magic Banana for this hint ^^ i was using the appimage file https://github.com/srevinsaju/element-appimage/releases/tag/stable
but this is much better ^^
Greets
I'm aware of two decent-looking, native* Matrix clients for GNU/Linux.
Quaternion is a Qt-based client.
=> https://github.com/quotient-im/Quaternion
Fractal is a GTK-based client.
https://gitlab.gnome.org/GNOME/fractal
It appears that Fractal does not yet support end-to-end encryption, so be aware of that if you want that feature. Matrix is a complex protocol that keeps growing as features are added, and the Matrix foundation consists almost entirely of Element employees (the Quaternion developer is the lone exception), so clients other than Element have to play catch-up with whatever Element does. When choosing a non-Element client, check to make sure that it supports the features you personally need.
*I don't consider Electron applications to be native. They are basically Chromium wrappers around web apps. Electron has various issues that make it very difficult to package properly, so Electron applications are not included in GNU/Linux distributions with any degree of quality control. Electron also extends the influence of Google's browser monopoly into the desktop, which I would prefer to avoid.
I haven't had time to digest this thread or read the articles linked to yet, but will do. I am wary of the FUD and misleading innuendo that people have mentioned coming from the article linked by amuza. But I was not aware of some of the concerns about Matrix that have also been noted. I have found that some family & friends seem to prefer Element better than the XMPP clients I had them install. But this is certainly something I will want to think more about.
> I have found that some family & friends seem to prefer Element better than the XMPP clients I had them install.
Which XMPP clients did you go with? I recommend Dino for GNU/Linux and Conversations for Android.
My sister uses a Macbook and I installed Adium for her. It had an issue where it wouldn't automatically scroll to new messages which drew a lot of complaints. A friend was using Windows 10 and was using Gajim, which worked fine. But he wasn't able to setup OTR. Both expressed a preference for Element. I think the main thing they like about Element is how easy it is to copy/paste memes into it. My sister likes to use the call and video call feature a good bit as well.
(On an unrelated note, I am happy to say that my above mentioned friend has said he is replacing Windows 10 with Mint today. Will see if he follows through.)
> A friend was using Windows 10 and was using Gajim, which worked fine.
Gajim is quite good. That used to be the client I recommended for GNU/Linux as well, though I recently discovered Dino which I think is even better.
> But he wasn't able to setup OTR.
Use OMEMO instead. It is way easier to use than OTR. The hassle of using OTR is not worthwhile for sending each other memes.
> My sister likes to use the call and video call feature a good bit as well.
Conversations and Dino both support voice and video calls over Jingle. I know that some macOS clients do as well, though I don't recall which ones.
> I am happy to say that my above mentioned friend has said he is replacing Windows 10 with Mint today.
Nice. If he likes Gajim and wants to keep using that, have him install "gajim" as well as "gajim-omemo". The latter package contains the plugin for OMEMO support in Gajim. Or "sudo apt install dino-im". Dino has OMEMO support built in.
Thanks for the suggestions. I will give them a whirl!
If I were to use Matrix (which I don't) I would use the libpurple/Pidgin plugin. I don't recommend it for personal reasons (lack of official registered standard).
Tangentially, there is an issue that, although not caused by Matrix themselves — since they did develop the libpurple/Pidgin plugin —, still worries me, which is the fact that the *desktop* and *mobile* versions of the most popular client (Riot / Riot X / Element) depends on Electron and this one depends on Chromium, this one in turn was found to be non-free ([1]) last time I checked. Thus Electron was also considered non-free ([2]), and so was Riot ([3]).
From some presentations made by Richard Stallman (for example, the one in [4]), one can draw out that since by default copyright is very restrictive to the user and also due to the fact that it's tempting for the proprietor to abuse his/her power of having the source code to do bad things to users, we must consider every software non-free unless proven otherwise.
Of course there might be some failures with the review process, this is why we have community to aid in that regard, either through the Free Software Directory or other means of contribution to free/libre system distributions.
Except for the lack of official registration as an standard, the problems described in this comment don't apply to the *web browser* version of Riot / Riot X / Element, due to what was described in [3] and [5].
# References
[1]: https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1 .
[2]: https://directory.fsf.org/wiki/Talk:Electron .
[3]: https://directory.fsf.org/wiki/Review:Riot.im-REV-ID-1 .
I didn't realize that Element was dependent on Electron and therefore non-free. And it seems that the consensus of this thread still favors XMPP as a protocol. Therefore, I've decided to move my conversations primarily back to XMPP.
I need to figure out how to share files with the main XMPP clients, though. This didn't work out-of-the-box when I tried it with family & friends.
Thanks for your feedback, everyone.
For file upload you can do that by two ways:
a) using HTTP File Upload (XEP-0363[1]): requires that both the service provider and client/software of the person uploading the files to support this feature, doesn't require opening ports and doesn't require both people to be online at the same time. Most modern XMPP clients, such as Gajim from Guix (which can be installed in Trisquel too), and Conversations (eu.siacs.conversations) already support this since they support most of the compliance suites for 2021 related to instant messaging ([2]). This has the disadvantage that the person uploading the file has to pay attention to the size limit informed by their XMPP service provider, and both people (receiver and uploader) must pay attention to the conditions for the file to be excluded by the XMPP service provider used by the uploader, but this is generally not a problem since people download the file within a reasonable period anyways (one week at maximum).
b) through direct file transfer (Jingle File Transfer, XEP-0234, [3]): not recommended, not even by the XMPP standards committee, it requires opening network ports and only works if both people are online at the same time.
As for the “compliance suites”, if I remember correctly there is a way to make your XMPP client show a list of all parts which the XMPP service provider your account is supports, but I can't find the option now. I think you must be logged in and go to your account, but from there on I don't know what to look for.
# References
[1]: https://xmpp.org/extensions/xep-0363.html .