Bootloader unlocking worked out of the box, and GSI installed without a hitch

issues right now:

- The flip doesn't turn on the internal screen

- front screen is inoperable and just displays T-Mobile's logo after installing the APK for the radio

- obviously there is no T9 keyboard with the GSI

- PTT button DOES work with an add-on app that maps keys, it registers fine

Happy to help anyway I can if you're interested

There is no T9 keyboard on F-Droid that I can find, and everything on the Play store is adware.

Last complaint is that it's thick AF. Yes all the reviews mention it. But it's the same WxL as my iphone SE 2016, and TWICE the thickness.

When I contacted CAT to retrieve the original ROM so I could fix the lid switch issue, I was met with "we do not redistribute ROMs outside of the company". Aside from the usual "You are not GPL compliant if you don't release your kernel now!" style response, this is an asshole move.

I want to like it, I want to use it, we'll see how much resolve I have to fix the aforementioned issues. Does anyone want an unlocked CAT S22 with a GSI installed? ;)

I had the first Pebble and have fond memories. I have high hopes for this!!!! I also love hardware but I never made it stick for work. I was one of the first engineers at Mesur.io, but things didn't work out.

My other thought would be to make this highly configurable; there is a large cohort of HN crowd who also want an un-Googled Android phone, myself included. There are no un-Googled small android phones, however with Project Treble many of them can run GSIs such as this most popular one https://github.com/phhusson/treble_experimentations/releases . Of course Lineage OS deserves a mention, maybe you could ship with that, build on what the community already offers.

The Unihertz line of phones deserves mention, but also scorn; they do NOT support their old hardware at all. The Jelly had 1 update to Android 8.1 and was left for dead. Additionally the system updater software included in the stock ROM was spyware. So unfortunately they were written off in my book.

Finally, I would like to see band 71 LTE availability for T-Mobile in the US. It really makes a big difference in the sticks. Unihertz does not support that, and for that reason I am sticking with my iPhone SE 2016 for the moment (until I find a small Android phone....)

Can't wait to hear more!

With regards to Unihertz, I'll add on top of what you said, that they are hiding behind ""crowdfunding"" to give non-existent customer support, while devices have already passed Google certifications months ahead (so my guess is that the device is actually already produced when they start the crowdfunding). In my case, the smartphone I ordered never arrived, and I never got any compensation for it, even though

However, hardware-wise, they aren't too bad, so once you managed to receive it, and you flashed a GSI on it, it's a rather acceptable experience. I know someone daily-driving a GSI (I think it's ProtonAOSP?) on Unihertz Jelly 2, and they are happy with it.

In my opinion, Unihertz small phones are fun, but /too/ small. As the article says, target would be 5-5.5" borderless, 4.5" in Jelly2's format, and I couldn't find any model that match. Closest is Xiaomi Qin 2 Pro (I have it, the form factor is really awesome), but it is too thin and thus its battery is abysmal. (If anyone is interested in Xiaomi Qin 2 Pro, yes it can run GSI just fine, but it requires a bit of work - feel free to send me an email for help)

Overall I found the standards of electrical work in Europe is significantly higher than US counterparts. In modern buildings every outlet and line has mandatory grounding, and GFCI is built into the fuse box on every power line for any building that's less than 30 years old. That really came in handy once when I accidentally hit a power line when drilling through the ceiling. I can't imagine doing any kind of renovation work without GFCI on everything.

I've seen none of the problems all these (presumably N American) commenters are reporting, but our power systems are famously much better in Europe. I'm from England but live in Czechia and apart from different plugs everything works the same.

I bought a rice cooker from a Taiwanese woman a couple of years ago and was shocked (fortunately, not literally) to discover that apparently Taiwan runs on American sockets and American (crappy) voltages. Luckily I had an adaptor plug and it seems to cope with 220V mains without releasing the magic smoke.

I don't ask in jest, I just was arguing with CAT (yes the heavy equipment people) about getting ROM/sources for their Android ROM, which they've stated they won't even ship the .bin out of the company.

Spaces was implemented but again the UI is just terrible

Other clients are better as an im like fluffy chat tho

Sub-folders would be even better for large-volume stuff like throwing multiple Discords worth of things into a Space, but I don't currently need that.

---

E2EE I have routine fights with, so yeah - Element is not great yet. But it's good enough that my siblings and I are seriously considering converting us + my non-technical parents over, now that Hangouts is horrible and we all hate how flaky it is. And it's a much, much better experience than Signal. The only other contender at the moment for that migration is Telegram (which is absolutely stellar, they're doing an amazing job).

How would they differ from sub spaces?

I may have just missed it.

Thanks! I've got Stuff™ to organize now.

I'm very much hoping they will hurry up with Sync v3, which would make this protocol a hell of a lot easier to use (for me, and a lot of other people). Right now booting up Element (or any other Matrix client, this is really a protocol issue) feels like a major chore, and it's something I prefer to avoid if I can. This is also why I keep Telegram installed on both my mobile, desktop and laptop.

Aside from Element, there isn't really much choice on Linux anyway. Fractal is ancient and gets stuck at "Syncing", Nheko takes up gigabytes of memory on initial sync until OOM'd, FluffyChat doesn't really work on my desktop (neither does NeoChat, Quaternion, Spectral), etc. etc. If you name a Matrix client, I have most likely tried it before and it didn't work (aside from Fractal Next, which doesn't have a release yet FWICS).

I've also considered hosting some sort of XMPP service, then bridging my Matrix account to said service so I don't have to endure the poor UX of various Matrix clients. Then again I'm not sure how the end-to-end encryption would work with that, and I would like to keep that if possible.

I have never experienced (or had to endure) an app with such poor UX as Element. Nothing seems to work quite as it should, sometimes it just plainly refuses to work, and other times you get issues which have been reported multiple years ago to the Matrix team (and still have yet to be fixed).

At this point I am very worn out of having to use Matrix, however due to my moderational duties I have no other choice.

Ahh, thank you telling me. I guess that's off the cards then.

> That's one of the reasons why I believe working on improving existing Internet Standards is better than switching to another trendy, non-standard protocol.

As much as I hate to admit it, I totally agree with you. While I personally quite like the API's and SDK's (although the JS SDK is pants, I've worked with it before), the UX of the client(s) just don't feel there yet, compared to what alternatives are offering.

Some polished XMPP clients include dino/gajim (desktop) and conversations/siskin (android/iOS). If you're looking for a unified-brand client/server distribution, snikket.im is a pretty cool project and could use help and funding.

[1]: https://cinny.in

Other than that, Cinny doesn't address the problem of Element on mobile not working very well. FluffyChat's UI isn't very nice either.

Hehe, I hopened with the inte tion to do it myself too, but never got around to doing it. It would require me to learn a bit of react and I don't have the time for it atm :/

I don't know what went wrong, but it still needs work. I'm glad to see that it's easier than last time I tried that.

The promised functionality doesn't really work reliably enough to protect against MITM, causes ugly warnings, but has been totally unactionable for years now.

If it doesn't matter, why not let people choose whatever they like? Personally I'm also wondering if having specifically white and specifically black thumbs-ups does not introduce more racial bias rather than the generic yellow default that I was used to, but I did notice people of color using specific colors so perhaps it does matter, at least for some of them. The rest of us can just be on (the afaik neutral) yellow, presuming that makes everyone happy.

Technology is made for people. People are all sorts of shades. Other chat apps give people the ability to modify skintone on several emoji.

Good grief.

Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients. [Some people are saying not: that homeservers don't see plaintext of E2EE traffic.]

There is talk about self-hosting in the client, but I don't know if it works yet, or ever will. Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.

If, in fact, messages are, or can now be, stored securely, I would welcome correction. Likewise, if client-side hosting works now, or message-store migration, or a stable address despite such a migration, or any effort at securing metadata. I have not kept up since abandoning Matrix, but still want a viable alternative to Signal.

The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.

Will we need to start all over again? A rigidly layered system, with a provably secure basis, probably in a single, sandboxed server talked to by all clients and gateways, with services built on top, seems needed if we want both security and features.

As it is, it seems like clients -- i.e. application services -- run in the same address space with what should be secure message transport, necessarily compromising all security with each bug added.

What do you mean? Signal is known for providing minimal information when requested by authorities, e.g., [0].

[0] https://signal.org/bigbrother/central-california-grand-jury/

i know "whatsapp admins" who have been made to report to police stations because they operate "whatsapp news channels". there they are made to submit their phone and wait outside. then the phone is returned. i have suspected, for like past 3 years that pegasus style malware would have been installed during that time.

now, a lot of these issues and problems can be reduced/prevented if you were not required to mandatory link your mobile number. if they know me by a handle, rather than a phone, it would be a little bit harder to do mass surveillance and bullying.

this was last yearand it continues. i have taught people to use launchers on android like evie that lets you hide apps. that saves you a lot of roadside quick grief. same for using password protected "gallery" like simple gallery to keep stuff behind a password. a thorough check will defeat all this but saves you in the field as you can be randomly picked.

whatsapp/signal/telegram as i said is more difficult, even clubhouse because since your phone is already public, the police do join groups, public or private using any means, lets say by surveillance, by getting access from company side or "borrowing" a phone from a member. then they just get a list of names and go knocking on doors. if the number was not there, it would have been much more difficult.

As a simple example, they could easily log whenever account xyz connects to do a token exchange for using sealed sender. Asking that of Signal won't be something I'd expect a judge would consider excessive if there is a legitimate reason.

Edit: grandparent comment can't seem to keep Matrix vs Signal straight.

Signal is the one that only works with Google Play, thus a Google account, and a phone number. It is easy for the spooks to connect that and its IP address to every subsequent communication, after the fact.

This is categorically untrue. Matrix’s E2EE is between clients; homeservers can not see plaintext in encrypted rooms, and all private rooms are encrypted by default these days.

The parent is completely confused.

It is proper end-to-end encryption using pretty much the same constructions as Signal.

Matrix homeservers have plaintext access to whatever is plaintext, though most matrix homeserver software doesn't include built-in functionality for admins to do that sort of thing; it would involve digging through the database(s). DMs are opportunistic e2ee and rooms can be plaintext or E2EE.

> besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness,

Signal is not Matrix...and Signal does not have any metadata except account creation and last-seen timestamps. Maybe the fact that you can't keep the two communications networks straight is a good sign you're not qualified to be critiquing them.

> The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.

That's not how that works.

Your comment is...seriously uninformed.

I hate the way Signal sells it, like there is zero trust involved and everything is solved by some magic encryption. There is a lot of data the Signal could store, like who is receiving the group message you just send to, that is only guaranteed by their server's source in Github (they could be hosting another thing and you will never know). That said, Signal is still much superior in terms of metadata protection, like the sealed sender feature for direct messages which will take time to arrive in Matrix [1]. I just wished they were more transparent about what they can't store and what they can store but is not storing.

[1] https://github.com/matrix-org/matrix-doc/issues/2318

Just clients I think. Otherwise it couldn't be E2EE. AFAIK, if you actually can manage to verify your correspondents with whatever the identity numbers are called in Matrix, you get effective E2EE.

The person sending the message and their intended recipient(s) are the "ends" in end-to-end encryption. The server is not an "end".

Incidentally, the client software is also not the "end": If the system includes a component designed to forward any data about the otherwise-encrypted content of the messages to someone who is not the sender or their intended recipient (unless at the direction of someone who is an intended party to the conversation) then the system does not implement end-to-end encryption. For example, Apple's iMessage app does this with their mandatory client-side scanning misfeature.

There's a lot of incorrect information here. First of all, it is not mandatory, it's opt-in - parents have the ability to turn it on for children under 18 whose devices have parental controls enabled. (Technically you could argue that it is then mandatory for those children, but that's no different from other parental control features.) Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.

I think you're conflating it with the iCloud Photos CSAM detection, which would have been mandatory and sent results of on-device scans to Apple if you have iCloud Photos enabled, but they seem to have scrapped that (for now at least) as they quietly removed all mentions of it from their website.

> Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.

… suggests that there was something similar in iMessage at one point, even if it was later removed. The "on-device learning" (or rather, on-device classification) means you're effectively sharing the data with Apple's agent running on the device, and the user doesn't have the ability to turn that off. Though it wouldn't be unreasonable to consider the parent who authorized this to be one "end" of the conversation since there is a minor involved—assuming there actually is a minor involved. (These "parental controls" have been abused to monitor adults.) It would be best if that fact was somehow communicated to all the other participants, for example with a "parental control active" or "monitored account" badge on the user's icon & profile.

> hmm, isn't that unavoidable?

Not only is it avoidable, it’s not actually true AFAIU. It’s unfortunate (if historically justifiable) that Matrix has a non-E2EE mode, but the thing it brands as E2EE is actually deserving of the name, with messages accessible to clients only and the associated hurdles (you literally can’t get access to message history in encrypted chats from a new client on the same account unless you get one of your old clients to cross-sign, even if the homeserver will help mediate the prompt).

Matrix is not free of problems, but it does have federated, multi-party, multi-device, end-to-end encrypted chats with persistent history and forward secrecy. The underlying crypto goes by Megolm[1]. It’s slightly weaker[2] (in particular regarding backward secrecy) than the strictly two-party thing Signal does (however they brand it these days), but nowhere near the point of allowing the homeserver to eavesdrop.

[1] https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-...

[2] https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...

Note that new features apparently come unencrypted, even in otherwise encrypted rooms. For example reacting to messages with emoji sends the reaction non-E2E-encrypted for both all home servers to see: https://news.ycombinator.com/item?id=29656282.

It is certainly not intended that new features are unencrypted, but unfortunately sometimes it happens in order for features to get added sooner.

That being said, there is still a lot of it that is up in the air. From what I've gathered, there's been talk about leaving aggregations to be done client-side specifically for reactions.

I checked that. While reactions are not encrypted indeed, a very recent feature - polls which are available in labs on Element Android - is encrypted.