• 1 Post
  • 23 Comments
Joined 1Y ago
cake
Cake day: Jun 20, 2023

help-circle
rss

Let me tell you a secret: any linux distribution is a kernel + a set of pre-installed drivers and programs + their configs. Nothing more than that! Most distributions use the same kernel and roughly the same set of programs. The only differences are in the desktop environment and initial settings.

I would recommend Linux Mint Debian Edition (LMDE) as a start choice. Do not trust those who say that if you choose a “beginner’s distro” you won’t have to get into the console or text configs. Your choice of distro will determine how often you’ll do this.

As a regular user, I’ve used different distributions and always something didn’t work. Many issues couldn’t be solved via GUI, so I had to deep dive into both the console and all Linux services.

P.S. Arch Linux daily-driver.


Arrr! Ok, correcting to “with both hands”! Sounds better?



We are together with you in favor of XMPP (I am with both hands)! You just “won’t sell” that kind of solution to very many people. We are already living in a zoo of messengers. We need to come up with at least two that will cover all the basic needs and offer sufficient privacy.


Matrix’s groups have an important difference from SimpleX. Even if the primary server is gone, the related servers will still have the copies.



Seems that’s true. Text-only communication in Briar is built by design. I see this from its communication scheme. I don’t think any other message options will come up. So I am also on it in case of the Internet outage. Besides, you can chat properly only when you and your contact are both online. Not a very handy option for daily use.

So SimpleX.Chat for privacy and Matrix for public groups.



If a server is hosting our data, albeit in encrypted form, there is always the risk of the server being compromised. You know the history of PGP and why OpenPGP was created, don’t you?

One of the options, where every user device is a server, is a blockchain. But I think you’ll also agree that this scheme doesn’t give complete privacy.

The issue of privacy in this case is a convenience issue. To me, federated is not a checkbox type property: it’s either there or it’s not. To me, it’s a spectrum: some protocol is more federated, some less so. We could design a fully privacy-aware protocol and service that can only partially be considered as federated. You may disagree with me, but I haven’t seen a clear definition with a complete list of federated protocol properties 😉


Agreed, it’s a contradiction to be privacy and federated at the same time. The federated protocol helps the network to be fault-tolerant and cooperative. In other words, it’s easier for us to find each other, and afterward it’s harder to lose each other. It obviously doesn’t condone privacy 😄



I think it’s unlikely this kind of service exists or is going to appear. There’s a blog post by developers of the present implementations of XMPP. It explains the difference between decentralized services and centralized ones, and why the Signal messenger is more popular than all other messengers. A must-read.


Here, the author refers to protocol as federated, not application. That is, he is comparing Matrix, IRC, SMTP, ActivityPub, etc. If a protocol can be used to develop an application that is decentralized and distributed, then such protocol can be called a federated protocol. I agree with you that labeling HTTP and FTP as federated is bizarre. But the author compares them because they are all from the same OSI model layer - application layer.

I’m not the author, just trying to give an explanation of how he was thinking (and I’m most likely wrong 😄).


The author’s explanation using HTTP as an example:

HTTP has somehow managed to live in a parallel universe, as it’s technically still completely federated: anyone can start a web server if they have a public IP address and anyone can connect to it. The catch, of course, is how you find the darn thing.


The Matrix protocol and its implementations do not provide the privacy you expect from them (matrix
Some interesting notes on the Matrix protocol, its limitations and comparison with IRC. A few crucial quotes, as the article itself is voluminous (but very exhaustive!): >Compare this to Matrix: when you send a message to a Matrix homeserver, that server first stores it in its internal SQL database. Then it will transmit that message to all clients connected to that server and room, and to all other servers that have clients connected to that room. Those remote servers, in turn, will keep a copy of that message and all its metadata in their own database, by default forever. On encrypted rooms those messages are encrypted, but not their metadata. >In a federated network, one has to wonder whether GDPR enforcement is even possible at all. But in Matrix in particular, if you want to enforce your right to be forgotten in a given room, you would have to: >1. Enumerate all the users that ever joined the room while you were there >2. Discover all their home servers >3. Start a GDPR procedure against all those servers >Overall, privacy protections in Matrix mostly concern message contents, not metadata. In other words, who's talking with who, when and from where is not well protected. Compared to a tool like Signal, which goes through great lengths to anonymize that data with features like private contact discovery, disappearing messages, sealed senders, and private groups, Matrix is definitely behind. >This is a known issue (opened in 2019) in Synapse, but this is not just an implementation issue, it's a flaw in the protocol itself. Home servers keep join/leave of all rooms, which gives clear text information about who is talking to. Synapse logs may also contain privately identifiable information that home server admins might not be aware of in the first place. Those log rotation policies are separate from the server-level retention policy, which may be confusing for a novice sysadmin. >Combine this with the federation: even if you trust your home server to do the right thing, the second you join a public room with third-party home servers, those ideas kind of get thrown out because those servers can do whatever they want with that information. Again, a problem that is hard to solve in any federation. >So while you can workaround a home server going down at the room level, there's no such thing at the home server level, for user identities. So if you want those identities to be stable in the long term, you need to think about high availability. One limitation is that the domain name (e.g. matrix.example.com) must never change in the future, as renaming home servers is not supported. >As a developer, I find Matrix kind of intimidating. The specification is huge. The official specification itself looks somewhat digestable: it's only 6 APIs so that looks, at first, kind of reasonable. But whenever you start asking complicated questions about Matrix, you quickly fall into the Matrix Spec Change specification (which, yes, is a separate specification). And there are literally hundreds of MSCs flying around. It's hard to tell what's been adopted and what hasn't, and even harder to figure out if your specific client has implemented it. >Just taking the latest weekly Matrix report, you find that three new MSCs proposed, just last week! There's even a graph that shows the number of MSCs is progressing steadily, at 600+ proposals total, with the majority (300+) "new". I would guess the "merged" ones are at about 150. >I'm also worried that we are repeating the errors of the past. The history of federated services is really fascinating:. IRC, FTP, HTTP, and SMTP were all created in the early days of the internet, and are all still around (except, arguably, FTP, which was removed from major browsers recently). All of them had to face serious challenges in growing their federation. >IRC had numerous conflicts and forks, both at the technical level but also at the political level. The history of IRC is really something that anyone working on a federated system should study in detail, because they are bound to make the same mistakes if they are not familiar with it.
fedilink

We recently discussed it in another thread. I recommend you read it, there are a lot of facts in the comments that will definitely help you make up your mind!


I don’t use it as my default provider. Obviously, for some messaging, I use Proton. But if you need a FOSS provider, that will be used for registration in some services and password recovery, this is a very good option! They don’t use this information for commercial purposes, that’s already better than Gmail or Outlook.


Fantlab for the Russian-speaking community. Couldn’t find anything better on the Anglosphere internet.

LibraryThing for English-speaking people. I use it for the rest.


Well, you know, e-mail gives you complete privacy only in special cases. There is a reddit’s comments thread about this. Non-gmail e-mail is only needed to avoid monitoring by the mail service provider.

TL;DR If you need complete privacy of communication, use Matrix-based software with your own server located in a neutral country.



I’m surprised no one’s posted about Skiff.



Agreed! Many times I faced the fact that the Chrome developers don’t follow the W3C standards, but they require it from Mozilla. Therefore, some functionality will only work in Chrome, but not in Mozilla (it’s not their bad!).