Librepunk Podcasts

logo for trash cat tech chat

003 - Matrix part 1

from trash cat tech chat

14 Jun 2022

Listen: ogg | mp3

Show Notes

trash cat (they/them) and Juliana (she/her) talk about Matrix. Part 1 of 2.

Timestamps

Transcript

Pre-intro

trash cat: Hi, editing trash cat here. Juliana and I had a really long conversation about Matrix, and it ended up being more than one episode's worth, so I decided to split it up. Here's how it's going to be organized. First, we'll have episode 3, which is part 1 of the Matrix conversation, and then between episode 3 and 4, there's like an episode 3-extra thing, which is just me talking about cryptography for like 40 minutes. [laughs] And then, we'll have episode 4, which is part 2 of the Matrix conversation. And that'll be the discussion about Matrix. So it's 2 major episodes and then an extra. So here's part 1. Enjoy.

[Intro]

tc: You're listening to trash cat tech chat, a Librepunk podcast.

Introductions

tc: Hi everyone, and welcome to episode 3 of trash cat tech chat. I am trash cat. My pronouns are they/them.

Juliana: And I'm Juliana. My pronouns are she/her.

tc: And I'm excited to have you back on the show! We did [laughs] So, this is funny. We did our first episode a few weeks ago, whenever that was, and we actually um... I wanted to cut down the episode to not more than an hour. I feel like podcasts longer than an hour long are... excessive and just become hard to listen to, and I didn't want that. So I um, we recorded more than an hour's worth of conversation. Then I had to trim some stuff out. One of the things we did talk about was Matrix, and I ended up cutting it for time. And then like immediately after I announced the episode and people had had a little bit of time to listen to it and whatever, someone sent us a message asking, "I don't think you talked about Matrix. What are your opinions on that?" It's like aahhhh, we did talk about this, but I didn't include it.

J: [laughs] Yeah.

tc: But I figured it would be a good idea to have just an entire episode about Matrix 'cause I think we have -- between us, we'll have a lot to say. So that's what we're gonna do today. We're just gonna talk about Matrix, and it's gonna be great.

J: It is gonna be great!

tc: Yeah.

What is Matrix?

tc: So um, would you like to introduce Matrix? Do you want to explain kind of what it is?

J: I can try. So, obviously I have a lay understanding, but it is a -- well, it includes voice and video, but it's a text chat platform as I've used it primarily, that is kind of like -- from my understanding, it's aiming to be a sort of free software alternative to Discord. So prioritizing group chats and having mechanisms kind of like Discord "servers". You have your rooms and your (what are they called?)

tc: Spaces?

J: Spaces, that's it, yeah.

tc: Yeah. In Matrix parlance. Equivalent of... Discord guilds are what they properly are called, but what Discord calls "servers", which is a terrible abuse of that word.

J: Yeah. I don't use Discord a whole lot, so...

tc: I don't either, but it's terrible. [laughs]

J: Yeah. But then Matrix also adds on top of Discord-like functionality and being free software and being, well, at least theoretically self-hostable, it also adds encryption, which is awesome.

tc: Yeah. And it's -- Did you mention it's federated? So not only can you host your own server, but your self-hosted server can talk to other servers, and it's... Most people, or many people who use Matrix end up using the same server. matrix.org is very big, very... kind of a big point of centralization, but theoretically the network is decentralized, and that's cool.

J: Yeah. I was actually talking to some folks about this the other night 'cause I just got two friends on Matrix, and they were trying to figure out what server to make their accounts on, and the analogy we gave was you can join like, a smaller server, or you can join the mastodon.social of servers.

tc: It's exactly the same, yeah. mastodon.social. Ugh. [laughs]

J: Unfortunately, I am on -- The mastodon.social in question is matrix.org, and that's where my account is, so...

tc: Yeah. Well, you can always move! [laughs]

J: That's true, and I probably will at some point, but...

tc: And that is -- I mean, I say that, you know, as a lighthearted comment, but that is actually one of the material benefits of federation. Like, even if you have a very centralized model of what federation is, there's always the potential to move. Even if, like, most people use matrix.org, if, say, matrix.org bans you for some unfair reason or you dislike matrix.org, but it would be really hard to get all of your friends to move off of it, or whatever, you can just individually move to a different server and still communicate with your friends. And that really reduces the barrier to switching.

J: Yeah.

tc: Because it can be done one person at a time. It doesn't have to be "Okay, I want to get off Facebook, so I have to convince all of my friends to get off Facebook and onto something else all at once.

J: Yes, that is a big advantage.

Bots and bridges

J: And then, on a related note, which you might -- I saw you talking about having notes for this one, so you might bring this up later, but bridges and the ability to interoperate with other protocols are common throughout Matrix. So they don't even have to be on Matrix necessarily for you to talk to them.

tc: Yeah. And that's, uh, that is something I have on my roadmap. That's something that I think is worth talking about because bridges, I think, are both good and bad from the context of privacy. Right? So... And bridges kind of lump in the same category as bots, even though they're -- they do different things, but they kind of work the same way. Like, a lot of bridges are implemented as bots. So let's talk about that a little bit. A lot of, I guess, instant messaging platforms these days have things like bots which do some automated function. Do you have anything you want to say about bots? I don't use them in anything, so...

J: I actually was just messing around with some of the Matrix functionality around bots. They call them "integrations", and the like, conceptual model for them is a widget. And I was messing around with them last night and was surprised by how relatively easy -- Well, okay, so I'm using Element, and Element is made by the Matrix project, and it integrates with a lot of their services, and one of them is scalar... It's scalar.vector.im, and it allows for integrating stuff fairly easily, and I was kind of looking at the thing like "What is this?" And there were a bunch of, you know, bots and bridges and apps, I guess. Widgets, just general widgets that you can just click and setup instantly. And I thought that was pretty neat.

tc: So, like "What would people use bots for?" I guess is a useful question.

J: So, bots specifically... The thing I've heard people talk about bots for the most is like, reminders. So like, if you're working on a software project that has a continuous integration pipeline where, you know, you build the software, test it, every time you push or whatever, then you might have a Matrix bot to let you know that that build is done so you can go check and see "Hey, did this merge break anything?" Another use might be as a translation tool. So, this is common I know in the Discord world to have translation bots. And then because of the broader, like, abilities of these widgets, last night the thing I was looking at it for was setting up a private sticker repo that a friend was hosting.

tc: Cool. And yeah, like, my experience with bots is fairly limited. I used to use Discord to play D&D with some friends, and so we would -- we had some bots for... one of them played music when we were in voice chats, and one of them -- I think there was one to like, handle YouTube videos or something, and there was one that was totally unrelated to anything that like, let us play Pokémon, or something. Like, Pokémon would randomly appear in the chat, and then we could try to catch them or something. It was weird.

J: That's kinda cool.

tc: Yeah. So, bots can do all kinds of things. And one of the things that they are used for in Matrix is bridging. Bots and bridges are kind of different things, but they're... but really, bridges are often a type of bot, so they make sense in my head to put together. But bridges let you connect a room in Matrix to a room on some other protocol. Right? So you can have like, if there's a conversation in Telegram that you want to follow, but you don't wanna use Telegram; you wanna use Matrix... you can do that. And depending on the style of bot, there are different ways of doing this, but basically what you end up with is like, the conversation transcript or whatever, the list of messages duplicated on both instances.

J: Yeah, that sounds about right. I was just using a bridge last night to XMPP.

tc: I love XMPP. [laughs]

J: Yeah. It's -- I still haven't set up an account, but I'm going to. Another interesting use case for bridges I have seen, and you may be familiar with this, you may not... The video game Veloren, on its primary -- well, not its primary, its like, the project's hosted server for it, they have a Matrix bridge to their chat. So if you're in Matrix or you're in chat, you're talking in the same room, basically, which I think is neat.

tc: Ah, okay. I see, I see. I feel like... What am I thinking of? Did like, Owncast do some sort of integration with Matrix as well? Or... There's some project that I remember hearing about was doing like, Matrix chat for livestreams.

J: It may be Owncast, then because I don't know of another livestream platform. Well, unless PeerTube's trying to implement livestreaming.

tc: PeerTube does have livestreaming support, but I don't think it was PeerTube. But I don't remember. Doesn't actually matter. [laughs]

J: Yeah, it's interesting regardless and really cool how you can do that. I mean, of course, Matrix -- uh, not Matrix bridges, but -- well, yes, Matrix bridges, but bridges generally exist for other protocols as well, of course.

tc: Yeah. XMPP has had the same thing for a long time... but they call them something else. They call them transports, maybe? That sounds right.

J: Interesting.

tc: Not that that's an important detail either, but I think that XMPP calls them transports -- the things that XMPP has that do the same thing. So, bots and bridges and stuff like that, those are really cool, and those can be really useful if, like, you know, say you don't want to use Telegram, you only want to use Matrix, or like, they can be really convenient because they can let you have all your conversations in the same place, and they can help you avoid having to run spyware on your own computer. Right? Like if you want to participate in a Discord channel (room), then you can bridge that room to Matrix so that you don't have to use the Discord software, for example. So that can be nice, but then you also have the downside of you're still contributing your data. The messages that you send and receive are still going to those companies like Discord or whatever. And...

J: Yeah.

tc: ...because of the way bridges work, the bridge has to be set up on a... well, not "has to be". I guess you could run the bridge locally, but bridges are set up usually on some server. It might be your own homeserver. It might be something else. They act as a participant in the conversation, and as far as I'm aware, there are no bridges that are so sophisticated that they can take a message from Matrix encrypted with the Matrix encryption protocol and, without decrypting that message, translate it into something encrypted in the destination protocol's encryption protocol. And for the most part, when you're bridging things, you're probably bridging things that don't have encryption anyway like Discord or Telegram group chats or whatever.

J: Yeah.

tc: So the consequence of this is you can't have both end-to-end encryption and a bridged conversation from Matrix to something else.

J: Yeah, unfortunately not.

tc: And that's just the territory of talking to those protocols, right? Like, I don't know, I... [laughs] You can't magically add on end-to-end encryption to Discord anyway. I mean, you could like, PGP-encrypt your individual messages before pasting them into the chat, right? But you can't reasonably have end-to-end encryption on Discord or whatever else, a lot of those things, anyway. But even the ones that do have end-to-end encryption, you can't -- like, they use a different protocol, and you can't seamlessly end-to-end encrypt from, say, Matrix to XMPP and back.

J: Yeah. Although, that would be an interesting project for somebody.

tc: It would. I have looked into it a little bit, like "Would this be possible?" and it would be really complicated because they... even though they both use kind of similar encryption to some degree, they are different encryption protocols, and like, the way that they handle key data and stuff, you get it from different places, and it's... It would be complicated and probably not possible, unfortunately.

J: That's a shame.

tc: Um, anyway, so bridges and bots... Cool, but they have to be a participant in the conversation, which kind of defeats the end-to-end encryption in most cases. You can actually, it is possible to set up a bot that uses end-to-end encryption, that like -- sorry, it is possible to set up a Matrix bot that can participate in end-to-end encrypted Matrix rooms. However, the bot then becomes one of the participants in the encryption, which means whoever's running the bot has access to all the room data.

J: Interesting. So, okay, so you need to... Okay, this makes sense. You would need to host the bot separately from the Matrix server itself.

tc: In order for the end-to-end encryption to mean anything, yes.

J: Okay.

tc: Because otherwise, the server has access to the plaintext for all the messages because the bot is running on the server, and the bot needs to have access to the plaintext.

J: That's... I see.

tc: Yeah.

J: That makes sense.

tc: I mean... arguably, there could still be some theoretical benefit like... I mean, even if they're both running on the same server, like... server here -- sorry, even if they're both running on the same computer, there could be a benefit because the Matrix homeserver is a different program than the bot itself, and so maybe just from like, if you trust the person running that computer, but you don't -- you think there might be, say, vulnerabilities within Synapse, the Matrix homeserver running on it or something, so you want to protect your messages from that. There could be some benefits like that or something, but that's... For the most part, I think you look at it as like, these are running on the same computer run by the same person; therefore, that person has access to those messages. Right?

J: Yeah. And I mean, of course, this is the question of trust, right? You just, you gotta trust people if you're gonna use these things.

tc: Yeah. Or, I mean -- I mean, yes, you do. Everything comes down to trust at some level, and that was the whole point of episode 1, right? But... [laughs]

J: Right.

tc: But, um, where you draw that line can be different with end-to-end encryption if you're running your own bot or there aren't bots or whatever, right? 'Cause then you can say "Only the participants, not the server, know what's happening."

Software

tc: Um, do you want to talk about the software that powers Matrix? 'Cause there's a lot of it, but there's also only like 2 programs.

J: Yeah, so the software that powers Matrix... There's obviously the -- Well, the ones that power Matrix as a protocol are the servers, and there are two of those. There's Synapse, and there's Dendrite, which, of course, you may have noticed, are both named after neurons, types of neurons in the human brain, which is -- well, in all brains, I think, but I think that's kinda cool. Synapse is the like, main server. It's written in Python, if that means anything to you. So, a side effect of that is it's perhaps not as quick as it could be. At the same time, it's the one with all the functionality implemented.

tc: Can I just interject to say, Synapse is terrible in terms of efficiency? Uh... like [laughs]

J: Yeah...

tc: Saying it's maybe not as quick as it could be is, feels like a massive understatement. Uh... [laughs] So, first of all, disclaimer: Synapse has gotten better over time. Okay? But I want to tell you a story from like... 2 years ago, maybe? I was running a Synapse server. I was the only user on this server. Okay? So, yeah, single-user Synapse server. My... the computer that this was running on had on normal usage about 4 gigabytes of RAM free, on top of whatever Synapse and everything else was normally using, just kind of when idle. I joined the "matrix" room on matrix.org, so like #matrix:matrix.org. I tried to join this room as a user. Over the next 8 minutes, Synapse ate up all of my server's RAM, all 4 gigabytes that were available...

J: Geez.

tc: ...and then caused it to, like, lock up essentially because it was just trying to use all the RAM and didn't have any -- it couldn't -- like, it was super slow if I was trying to do anything on my server over ssh.

J: Yeah, I've heard several stories like that, so...

tc: It's just like, joining very large rooms -- and part of this has to do with the model of how Matrix is designed. It's very server-oriented where the idea is that the server should for some reason store the entire history of everything forever, basically... which is not a model that I personally like. [laughs]

J: Yeah, that's not -- I am probably with you on that. This might be a digression from the topic of software, but does it have to do that for encryption purposes?

tc: This was an unencrypted room. Oh, you mean store everything forever?

J: Yeah.

tc: No, because you can... I mean, the metadata is not encrypted, right? So you know when messages were sent.

J: Okay.

tc: And so you can purge messages that are older than X amount of time. I mean, like theoretically it should be possible to do this, not saying it's easy to do in Synapse. But it's possible without knowing the contents of the messages to purge old messages. It's possible without knowing the contents of the messages to allow users to delete individual messages based on like their message ID or whatever. The end-to-end encryption shouldn't affect how long messages are stored on the server.

J: Okay.

tc: And like, XMPP for example supports end-to-end encryption, right? At the client level. I feel like that's something that I want to talk about later, the specific way that end-to-end encryption from like, the user experience perspective works is something that I think we should talk about, but not right now. Anyway, XMPP by default doesn't store messages on the server. You send a message to someone else. It gets delivered, doesn't get stored on the server after that. You have to enable additional uh... XEPs. Additional extensions to XMPP in order to save messages on the server. And then even when you do that, they're usually only saved for like a week or something by default.

J: That's interesting. So it's more like the IRC model where the messages are stored by the client?

tc: Yes, very much so.

J: That's interesting. I didn't realize that.

tc: And that's what I prefer. That's not what Matrix does, but here we are. [laughs]

J: Yeah. For security and privacy, it's probably better. So you have Synapse, right? Which is slow and heavy, and then on the other hand, you have Dendrite. And Dendrite is written in a language called Go which is much faster. It's specifically designed for web applications like this, like server-side web stuff.

tc: I feel like you and I have talked about the fact that Dendrite is written in Go, and I just completely forgot. I had in my head that it was C++. [laughs]

J: Yeah, I thought it was just C, I think, and then I was looking at the repo the other day. 'Cause I was looking at setting up a server, and so I was like, "What -- Is Dendrite ready?" I knew it was the one that compiles to native code. Python, by contrast, is an interpreted. That's part of why it's so slow. And I was looking at it, and I was like "Okay, okay." And basically, Dendrite doesn't have several key features of Matrix...

tc: Yeah, it's still a work-in-progress.

J: Yeah, and also, I was talking to someone about it, and they mentioned that in terms of memory and CPU usage, there's not a... Dendrite is still very heavy... [laughs] ...because of how Matrix does messages, like trash cat was talking about. You know, you join a room. It downloads every single message ever sent to that room to your server. So, there's just -- at a certain point, that's just an inefficient model that's going to cause inefficiencies, so...

tc: Yeah.

J: And then on the client side, there's basically one full-feature client, and it's Element. And there's about 2 hundred thousand other clients, it feels like... [laughs] ...with various features that don't work or various, you know, synchronous, uh... What am I trying to say?

tc: Quirks?

J: Quirks. Yeah, so...

tc: Idiosyncrasies?

J: Idiosyncrasies! That was the word, thank you.

tc: Sure.

J: So yeah, it's kind of messy, and basically at the end of the day, if you want the full Matrix experience, despite having multiple servers and clients, you have to basically use Synapse and Element for everything to work.

tc: Yeah. And there are a few clients that I think are worth mentioning that aren't Element. But there really are -- there are a bunch, and most of them are not, mmm, usable as like, an everyday thing.

J: Right.

tc: Because they're missing some essential feature. A lot of them are missing end-to-end encryption...

J: Yeah.

tc: ...which for me is an essential feature.

J: Yup.

tc: Uh... [laughs] Yeah. So there's Element, like Juliana said. There's something called SchildiChat, which I personally use. It's just Element. It's the same codebase as Element, but it makes some cosmetic changes, and I prefer how it looks and feels. So that's what I use.

J: I'll have to look into this one 'cause Element's look-and-feel is kinda weird to me.

tc: Yeah. I'm not a fan of how Element looks and feels, and I do enjoy using SchildiChat. It's still... It's, um, an Electron app, which I dislike. It's inefficient. It's [discontent noise] There are a lot of things I dislike about it... but at least it, you know, feels nicer to use.

J: Yeah.

tc: To me. SchildiChat is not available on iOS, which also brings me to one of my biggest complaints about Element, which is: Element on iOS does not support resizable text. The font size cannot be increased, which for people with impaired or poor near-vision is a major issue! This app just flat-out is not accessible to a lot of people.

J: Yeah, and that's very important and something that is often overlooked, especially in free software circles.

tc: Yeah. And like, again, Element is kind of the only fully complete Matrix client, so it's a big issue. So there's Element and SchildiChat, which is just Element. And then there's FluffyChat. And FluffyChat is written in Flutter, which -- Are you familiar with Flutter? I know you're a programmer.

J: I have looked into it a couple times. I know a little bit about it, but I've never actually used it.

tc: I mean, same, but uh... [laughs] ...my understanding of Flutter is... It's a Google project. It is related to Dart. I mean like it uses Dart, and I don't really understand the difference between Dart and Flutter. Maybe Dart is the language, and Flutter is a framework using that language? But regardless, the idea is you write one codebase, and then it can cross-compile to multiple platforms. Which is -- Again, this is a Google project. It makes a lot of sense that this is something Google would make to make it really easy to make apps for both iOS and Android.

J: Yeah.

tc: Especially because, you know, if you're Google, you don't want people to make just iOS apps and ignore your platform.

J: Yeah.

tc: So, FluffyChat is written in Flutter, and it is available on Android, iOS... there's a web version, and there's a desktop version. And my understanding of how Flutter compiles is that the web version and the desktop version are different, as opposed to like an Electron app where the desktop version is essentially the web version and a Chromium browser to package it in...

J: Yeah.

tc: ...I believe that with Flutter, it actually compiles it to native desktop code.

J: Yes.

tc: And the desktop version of FluffyChat, I believe at time of writing -- [sarcastically] writing -- time of recording is only available on Linux, not on macOS or Windows yet. But anyway, we've got this app called FluffyChat. And FluffyChat is lagging a little bit behind Element like everything that's not Element, including SchildiChat because they don't do updates for every single Element version. Everything that's not Element is lagging a little bit behind Element, right?

J: Yeah.

tc: But FluffyChat is pretty good overall. It works pretty well. The encryption stuff all works. It's generally a good time, in my experience.

J: Yeah. I was just gonna say, it's the one people suggest if you don't want to use Element, basically.

tc: Yes. And then the only other client that I think is worth mentioning is nheko, n-h-e-k-o. And... that client... It's uh... what's the framework it uses? I wanna say it's written...

J: Qt.

tc: ...in C++ and uses Qt. Is --?

J: Yes.

tc: Yeah. And it's... It doesn't look amazing, but it's okay. I'm not super picky about that. I would rather use something that doesn't look amazing than have to deal with Electron. [laughs]

J: Yeah.

tc: It supports end-to-end encryption and has all that stuff at what I think is sort of an acceptable level in terms of user experience. My biggest concern with nheko is that the end-to-end encryption implementation has not been audited.

J: Oh no.

tc: And the reason that I think that this matters in particular is because it uses the libolm library, which is the one developed by the, you know, official matrix.org organization. And libolm was audited in 2016. And -- I recommend reading this audit, actually, if you're interested in how the crypto works. It does a good explanation, I think, of "How does this actually" -- like, "What is this actually doing? (this thing that we're evaluating)" and then "What issues did we find with it?" However, there's -- in that audit, there's a list of issues that were found, and most of those issues -- it's like 8 out of the 10 or something; I don't remember the exact number off-hand -- were not solved in the libolm library. They were addressed in the matrix-sdk-js or whatever it is, the higher-level library that calls libolm.

J: Oh.

tc: Which means I don't feel confident with an unaudited implementation of the cryptography using this library that like, did not itself within the library solve the issues. Right? Because you have to be careful when implementing something using that library to avoid the same issues that came up there that were not fixed in libolm.

J: Yeah. And as a programmer, I'll just say, that's a bad call actually. You should fix the problems with your code in the code that has the problems.

tc: Yeah. [laughs]

J: [laughs] It seems to be obvious to me.

tc: Yeah. So that's my thing with nheko. I believe, since I said this, I believe that FluffyChat uses the same SDK [editor's note: software development kit] that Matrix uses for the crypto. I'm not -- er, sorry, not Matrix, Element. They're so synonymous. Uh, [laughing] which is not a good thing, but it is what it is.

J: Yeah...

tc: I believe that FluffyChat uses the same crypto SDK that Element does. I'm not positive about that, but I think it does. So FluffyChat should be okay there, but I don't feel confident with third-party implementations.

J: Yeah, that's really interesting because one client project that I've been interested in is called Fractal. I really like the UI. It's a Linux-only deskt-- well, it's not Linux-only, but it is a desktop-only app.

tc: It's the GNOME one, isn't it?

J: Yeah, it's the GNOME one, so it uses the same toolkit as my desktop environment, so it integrates well. But they haven't had end-to-end encryption because there -- it's written in a language called Rust, and there hasn't been an implementation in Rust --

tc: Until now!

J: Until now? Did they finally finish it?

tc: Uh, I mean, they're working on it. So, while we're on this topic, sure. Uh... [laughs] So, the Matrix project has been working on a reimplementation of libolm using Rust. And it's called vodozemac.

J: Oh, interesting.

tc: (I'm probably mispronouncing that.) And that library was audited this year. Like, the official -- the audit was published -- or, not published, the audit was finalized March 30th, I think, and then like, last month or something, Matrix announced "This library has officially been audited!"

J: Oh wow, that's super cool!

tc: And the Matrix project is working on -- By the way, just all the things that I'm talking about here, I'm gonna include links in the show notes. Go check those out...

J: Yeah.

tc: ...if you're interested in more detail. The Matrix project is -- The next thing on the agenda is -- the Matrix project has also been working on -- I'm not sure what the status is, whether they're like, done with it, pending audit, or if they're still working on it prior to the audit, but the next piece is they're going to have their Rust language SDK audited as well, and that will be... That's designed to be more plug-and-play from what I understand, where all the other clients could just use that SDK, regardless of what language they're written in.

J: Oh, that's awesome! Just a quick note on why Rust is such a big deal for non-programmers, basically it is a highly performant language that makes it pretty hard to introduce memory bugs that could be security holes. So it's theoretically and, it seems to be practically, a more secure language than something like C or C++, which, I assume libolm was probably written in C?

tc: Yeah, libolm was... It -- I don't know enough about C and C++. It's written on the documentation and stuff as "C/C++".

J: That probably means C++. C and C++ are not as interoperable as they used to be, and it's kind of annoying people still use that construction, but yeah.

tc: Okay, thanks for clarifying because I am a programmer, but I have not done really anything ever in C or C++.

J: Ah, I love C. [laughs] So, the Rust SDK for Matrix is what we were talking about, and clients?

tc: Yes. You were talking about Fractal, and I interrupted you.

J: Yeah, I was just gonna say that I hope they get their Rust things working, which it sounds like they're about to, so...

tc: Hopefully. Fingers crossed. 'Cause I've -- Actually, I get Quaternion and Fractal mixed up in my head, so I don't remember for sure which one. I believe in the past I've tried Fractal, and I liked it. I found the user interface very nice. I mean, GTK apps in general are nice to me. I'm not super fond of like, the GNOME window tiling -- not tiling, um... What do you call that? The like, thing at the top of the window? [Editor's note: The phrase I'm trying to come up with is "window decoration".]

J: Oh, the, yeah, the header bar, I guess?

tc: Yeah...

J: They made it really thicc.

tc: Yeah, they made it really thick, and they made it not, um... Like, you can't make it go away and use your own regular window manager's title bar thing. And I run Qubes OS on my desktop, which create-- so, and Qubes, uh, has the like, title bar thing go away in all the windows and then recreates it in dom0, in the -- So, Qubes is like, you run everything in virtual machines, and so the like, kind of host machine creates the window for everything that contains the virtual machine window without the title bar thing. But you can't make the title bar thing go away for GNOME apps with that thing, with the big one, the big title bar thing. And so you just get like, double. You get the Xfce window manager thing and also the GNOME window bar thing. It's obnoxious.

J: Oh, that is obnoxious.

tc: Yeah. I mean, and this is a small aesthetic complaint, right? Like, I can deal with it. Whatever. That was all a tangent. My actual point was: I'm really excited about Fractal, if and when that becomes a thing because I believe, just going off memory, that I have tried it before and really wanted it to be usable, but it wasn't usable yet because of the lack of end-to-end encryption.

J: Yeah, I had the same experience.

A tangent about Qubes OS

J: By the way, are you gonna do an episode on Qubes at some point?

tc: Maybe. I don't have plans to, but I'd be happy to.

J: My -- I don't know a lot about it, but my understanding is it's just about the most secure computer experience you can have.

tc: Yeah, um... I mean, yeah, I... [laughs] ...I think so. It's... The approach that Qubes takes is you run everything in virtual machines, basically, so it's security through isolation, through compartmentalization, where you say, "Okay, these things over here in like my personal virtual machine are going to be separate from these things in my work virtual machine, are going to be separate from, like, I'm gonna browse over here using Whonix", which is an anonymity focu-- it's kind of like Tails. It's an anonymity-focused operating system meant to run in a virutal machine, so like, "I'm gonna browse the web using", say, "Tor Browser in Whonix", this very, like, Tor-oriented anonymity operating system, "and then also I'm gonna do my personal stuff over in a different virtual machine in Fedora, and I'm going to do my work stuff in a Debian virtual machine separate from that, and if someone sends me a file that I don't trust or whatever, I can open a disposable virtual machine that is isolated from the internet. And I can open the file in there, and then, 1. it's isolated from the internet. Like, it doesn't have networking access at all, so if it's some malware that's going to like, try to spread via the internet or phone home to some company or activate something, it can't. Assuming various properties about like, the operating system works properly and whatever. And if it is malware, and it tries to infect the system, well, it's just running in a temporary environment that's about to be destroyed once I turn it off anyway, so it won't infect the host system." At least, that's the idea of it.

J: That's pretty cool.

tc: It's really cool. And it's, like... I mean, everything is threat modelling, right? Like we said before. It's probably not within my actual threat model that I need to use Qubes. But it actually is really nice for various things. Like it offers me the flexibility of because everything's a virtual machine, I can run different Linux distros simultaneously on my desktop. It enables me to compartmentalize things in ways that are just generally a good idea, even if it's not like, necessary to be so hard locked-down to the point of like, the Xen hypervisor being your primary risk in running this thing. Comparmentalization in general is a good idea, and this makes that kind of easy for me. And it's really nice to be able to create disposable environments that I can just use for like, a single thing and then power them off, and they go away.

J: Yeah, that's awesome.

tc: Yeah.

J: I could ask you a thousand more questions, but we should probably focus on Matrix.

tc: Probably. Maybe a different episode.

[Outro]

tc: You've reached the end of this episode of trash cat tech chat. Check out the show notes for links and other information. This podcast is licensed under a Creative Commons Attribution-ShareAlike 4.0 license. Music by Karl Casey @ White Bat Audio.

Links

Credits

Music by Karl Casey @ White Bat Audio