I've done a bit of a dig into Tangled and Millix and found a few alarming things:

KYC in the Extreme

Unless I provide a whole lot of personally identifying information (such as my real name, tax number, copies of my ID document and photos of me holding my ID), I can't get my account verified. Without verification, I can't withdraw any of the millix that I earn there. I'd have to send it to a verified account that I trust enough to send it to my external millix address. (However, if you've got no problem with giving your personally identifying information to an unknown entity, particularly a supposedly crypto/Web 3 site, on the Internet, I wonder how trustworthy you really are. Not very, IMO.) Long-term readers know that I don't feel at all happy about going through the KYC process and this one seems particularly invasive. As someone for whom I used to work would say, "I'm surprised it doesn't also ask for a recent photo of my genitals".

Millix doesn't use a server RDBMS

Milix uses SQLite as its backend database. SQLite is meant to be a simple single-access file-based database for offline applications. Why anyone would use it for a Web-based application is beyond me. Yet people do. I suppose that's because they can. It doesn't handle lots of read/write operations at scale (not unless you write an RDBMS with task queues for queries on top of it, which is no small feat ^). I know this from past experience, having worked at a company that used an SQLite DB to power a whole host of Web-based services and sites. We had to restart the server regularly because the database kept getting locked. While the code for millix is open-source and it is possible to change it to use MySQL or Postgre, it would have been better/easier to write it to use one of those two in the first place (as was the case with the codebase of the company at which I worked). It might be fine for now, but it's going to be a problem in the not-too-distant future if not addressed early on.

NodeJS

Millix uses Node. For me, personally, there's a whole lot of "nope" right there. I don't know if any of the MEA/RN stack can be trusted, particularly Node and React. I'd have to scrutinise the code behind all of it. Even though I've probably got the time, I haven't got the inclination. I'd be a lot more comfortable if it was using ASP .Net, Java, PHP or Python. (As much as I hate Java, it's not something created by Google or Meta.) I wish Websites would put up a warning when using all (or part) of the MEA/RN stack, so that visitors could decide if they want to keep using the site or not, instead of squirreling away that information in an FAQ that most people (myself included on too many occasions) don't bother to read.

Tangled Browser

The Tangled Browser is built on Chromium, which is made by Google. Chromium has tracking/telemetry code within it, which allows Google to spy on its users and collect their data. (I know this because the Ungoogled Chromium browser project has specifically removed that code. However, it's a PITA to install and run on GNU+Linux machines.) Plus, it's slow AF and there's not much point running it beyond the "new user" stage of being active on Tangled.

TL;DR

In short: Once I've got to one million (1 000 000) millix, I'm sending it to someone else on Tangled and getting the fuck out of Dodge City. I'll have to look elsewhere for an alternative to noise (maybe even learn how to build my own Web3 site that uses Nano, also a DAG-based blochchain cryptocurrency, and the nPass wallet).* It serves me right for not doing my due diligence first.

Snark out! 😱

^ Something like RQLite, perhaps. Personally, I'd just stick with an RDBMS like MariaDB/MySQL or Postgre

* AFAIK, nPass only works with chrome-based browsers, so maybe I'll have to look into using Arbitrum (ARB), Optimism (OP) or Polygon (POL) with MetaMask or WalletConnect, assuming I ever get that far, which is unlikely. It just depends on how fed-up/fired-up I get about this.

Post image copyright Disney