Recently, I got very interested in trackballs due to my wrist and shoulder pain issues worsening -- and, of course, the skin-like coating on my two-year-old MX Master 2S starting falling apart. It began as a friend recommended me to try out trackballs during my complaints about wrist pain, after which I quickly went down the rabbit hole and pulled trigger on an entry-level thumb-operated trackball, the Logitech M570. This article is not about how trackballs are somehow better than normal computer mice, but I can't really stress enough how much more comfortable it is after switching to the trackball. Naturally, it quickly replaced the old mouse as my daily drive.

The M570, to me, has a few issues though. The first complaint I had with it was that it has no tilt angle, unlike the MX Ergo, and thus the operating hand can still get a bit uncomfortable after extended period of use. This was solved without a hitch by 3d-printing a pre-made model of a tilted mount for the trackball. I went with the 20-degree version and find it way easier to the wrist after the modification. The second complaint, which is also the theme of this article, is that I want to be able to replace the stock ball, the blue one, which I do not exactly like, with something custom.

I am going to start a blog series on porting custom ROMs for Android devices. This idea comes from recent chats with friends on the topic of choosing new phones to buy and custom ROMs -- that the whole notion of being able to compile an entire operating system from scratch and make it running on a given device seems pretty magic-like to many. Pretty much all of these friends of mine are fairly tech-savvy, and many of them are developers themselves and use Linux as their daily driver OS on their PCs. But when it comes to phones, somehow, running a customized OS begins to sound like magic to them, and most of them just sit around and wait for someone to port a custom ROM to the phone they are using, or alternatively, they check if there is already somebody working on a port before deciding to switch to a new phone.

To be clear, I am not expecting everybody to learn to make everything on their own. Frankly, working with something like a custom ROM has never been something too enjoyable except for people that like to stare at a terminal window rolling for hours and exclaim when the phone even just lights up the screen with a boot animation, to say the least. However, it seemed to me that people do not refrain from trying just because they do not like the process. Instead, most of them stop trying long before they even get a glance into the actual process itself. They stop because there is not enough guidance on where to begin and how to start their first step into the rabbit hole of custom ROM development.

As you may know, I have been a user of Standard Notes for a long time. Since I am a self-hosting nerd, during this whole time I was using a self-hosted server of Standard Notes, using the Go implementation of the Standard File protocol (the former name of the sync protocol of Standard Notes). There is just one slight problem: this implementation seems to be abandoned since mid-2019.

Of course, Standard File (and thus Standard Notes Sync Protocol) is not a particularly complicated protocol that needs maintanence that often, but things have happened since the Go implementation last updated. For example, the whole Standard File name was discarded and the protocol became officially named as the synchronization protocol of Standard Notes. But the protocol itself was later updated too, at least introducing a different conflict resolution algorithm, which the Go implementation did not support and totally relies on backwards-compatibility of the client-side.

We are not in a time short of products that claim to "encrypt" your personal data with "millitary standards" and thus keeping them safe from leakage or delibrate attacks. This can really work in convincing a lot of non-tech-savvy people and even some with rudimentary computer knowledge about how secure those products are -- until some leakage events happens out of nowhere and everybody gets screwed.

The problem here is that things involving encryption does not necessarily imply security of the particular data you are concerned about. Encryption is a broad term that can be applied to anything that includes some algorithm to prevent part of the population from accessing some data. Anything from simple dictionary-based cipher to modern cryptography all fall into this category, but I am not even talking about the vulerabilities concerning different ciphers here. What I am talking about is the question of which part of the population exactly do you want to block from accessing, in other words, the threat model.

(From "The Zygon Inversion", in 9th series of Doctor Who)

...

"It's not fair."

"Oh it's not fair. Oh I didn't realize that -- it's not fair. You know what, my TARDIS doesn't work properly, and I don't have my personal tailor."

"These things don't equate."

"These things have happened. They are facts. You, just want cruelty to beget cruelty. You are not superior to people who are cruel to you. You are just a whole bunch of new cruel people. A whole bunch of ... you cruel people, being cruel to some other people, who end up being cruel to you. The only way that anyone can live in peace, is if they are prepared to forgive. Why don't you break the cycle?"

"Why should we?"