matrix-js-sdk VS nheko

I'd quite like some more high level documentation for the Matrix JS SDK (https://github.com/matrix-org/matrix-js-sdk). I've been looking at it for quite some time and still don't understand how timelines work.

Currently we don't force TURN, so in practice this means that voice packets go direct between the clients if possible, and so the IP addresses of the clients are necessarily exposed to each other.

However, this is utterly trivial to fix: matrix-js-sdk already exposes https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... and we simply haven't exposed it as a setting in Element Call yet. I've filed a bug for it at https://github.com/vector-im/element-call/issues/251 - thanks for bringing it up!

In terms of moderation: this is no different to moderation in Matrix as a whole, where we're already busy working on shared greylists (MSC2313 and friends) - https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... has more details at the end.

We expect to turn it on in the next few weeks - the problem we were debugging that we meant it was turned off looks to be fixed. https://github.com/matrix-org/matrix-js-sdk/pull/2002 is the PR that will need to merge to enable it ftr.

Unlike any open source projects to which I've contributed, this project involves 2 other repos, matrix-react-sdk and matrix-js-sdk. As explained in the Development guide in the element-web repo, I need those 2 SDKs in order to build Element successfully for code contribution.

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