nheko VS Signal-Android

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...?).

Haven't used Signal FOSS, but as it happens Molly bas just implemented OSM support, perhaps when it lands you might have better luck with it. Anyway, is there no issue tracker for that fork? I tried looking in their repo and found it disabled

Try using the Signal FOSS version from https://www.twinhelix.com/apps/signal-foss/

Yeah I followed that whole story. Since then some forks have been created that do not care what Signal Foundation thinks about using their servers. Molly and Signal-FOSS for example, both compatible to regular Signal. Those two forks will not keep SMS support, Molly never had it, and Signal-FOSS will most likely drop it because they think it's too much work to keep it while staying compatible and up to date. I hope there is going to be another fork specifically dedicated to keeping SMS support. We'll see.

You can get a completely open source version without the Google stuff here: https://www.twinhelix.com/apps/signal-foss/

Signal FOSS removes proprietary google blobs https://www.twinhelix.com/apps/signal-foss/

Signal - Molly , Foss-Signal

Maybe they had outdated info from when the server software was not updated for a long time. Or, it's regarding the dependencies on closed-source Google Mobile Services and Firebase libraries, though those can be removed... and have been in this fork.