nheko VS axolotl

Look at this, notice anything different? https://github.com/Nheko-Reborn/nheko/issues/new/choose

Nheko has been around for a number of years. Never used it myself though.

https://github.com/Nheko-Reborn/nheko

Matrix clients hit different than pretty much any other chat client I've use before. Theres multiple clients I've found like nheko, moments, element that are a pleasure to look at and smooth as hell. Even better you can have users use web services like Element Web to sign-up and chat. Its sick.

The Nheko flatpak is official. Just compare the source to the nightlies we build and upload to our nightly repo.

Like almost every client out there it has no support for e2ee. I was happy to find https://nheko-reborn.github.io (I'm a KDE user so Qt apps are preferred).

There's also FluffyChat or Nheko if Element is too heavy.

I probably wouldn't have guessed that `e.dataTransfer.items` gets cleared at the first await (since I'm not a proficient web developer), but I would've been extremely wary of this code in general. Additionally (not tied to async-await but race conditions in general), is `item.getAsFileSystemHandle()` a TOCTTOU vulnerability where the type of an item can change between folders and files and symlinks etc., while this code is running?

Rust's & vs. &mut system largely eliminates shared state hazards in both threading and asynchronity (&mut is exclusive/unaliased and can't be mutated by other threads or event loop jobs, and & is difficult and unidiomatic to mutate), though it doesn't solve async cancellation errors (https://carllerche.com/2021/06/17/six-ways-to-make-async-rus..., discussed at https://news.ycombinator.com/item?id=27542504), or filesystem TOCTTOU (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html as well as user code).

Qt event loop reentrancy is fun(tm) as well. It looks like a blocking call, but spawns a nested event loop which can do anything (but rarely enough to lull you into a false sense of complacency), resulting in segfaults like https://github.com/Nheko-Reborn/nheko/issues/656 (workaround at https://github.com/Nheko-Reborn/nheko/commit/570d00b000bd558..., I didn't look into it). And Qt lacks "easy" await syntax and a framework based on calling red functions (though I didn't look into C++20 coroutines yet, perhaps https://www.qt.io/blog/asynchronous-apis-in-qt-6 or https://github.com/mhogomchungu/tasks or https://blog.blackquill.cc/asynchronous-qtquick-uis-and-thei...?).

While searching around a bit more I found another unofficial Signal client for arm64 Linux optimized for mobile called Axolotl. The github page makes it look promising, but once installed I couldn't log in successfully. I intend to put more effort in there. Axolotl appears to be the most promising looking option for Signal on mobile Linux - assuming it works..

> Only a small thing, but due to Signals strict phone-desktop pairing mechanism, when registering Axolotl, both phone and regular Desktop wont work anymore.

> Also, you cant use Axolotl on Desktop together with Signal mobile.

> After deleting the Axolotl registration I had to wait a while to be able to register on Signal again, I didnt loose any backups and my codes didnt change.

> Nonetheless a warning should be displayed at the beginning, that users wanting to use regular mobile (iOS, Android) and Desktop (Windows, macOS, Flatpak or Snap), they should use a second phone number for testing.

https://github.com/nanu-c/axolotl/issues/811

>Signal also notably isn't self-hostable: there's no way to run your own signal server, and control your data. Marlinspike ruthlessly shuts down anyone attempting to build alternate clients or servers that could communicate with the main one.

That is perfectly wrong. As a maintainer of https://axolotl.chat, a third-party signal client initially built for Ubuntu Touch but which runs on almost everything now, I can tell you that our client is speaking without any problems to the official Signal servers, and also that the code of the server is available and is running fine, we used it to test our code.

Wouldn't Signal Desktop be a way to make backups?

I moved my home directory to a new computer and Signal Desktop started like if something changed. Sure you lose your messages on your phone, but you can still access them on your computer if needed.

On a rooted Android phone, you could use oandbackup to backup Signal. If you care about these things, maybe consider using a rooted Android phone?

I agree with you on the centralized platform aspect and the use of phone number (which is both a blessing (this makes it easy for new users to join) and a curse). I also agree with you on Element's UX, but it's getting better and most people can use it fine. I have a few groups on both apps.

I personally prefer Element, which seems more open than Signal and which I can actually use correctly on the PinePhone. Axolotl [1] still needs some work.

[1] https://github.com/nanu-c/axolotl

I think the best option to communicate through Signal will be Axolotl. Because the original desktop client of Signal might work as well but it's not optimized for touch input.

If you go to the git repo for Axolotl (https://github.com/nanu-c/axolotl), you will see links to the deb among other formats.

Ah well then I applaud you. :) Perhaps some ideas could come from past efforts like Axolotl, which I've had working in a basic way in the past.