Matrix very recently has had e2ee calling since at least last april

I don’t host a server currently, so I can’t fully recommend it without knowledge of the backend, but i’m liking the experience as a user

Just looked at Session, and holy shit is that a massive downside…

From their own whitepaper:

Through the integration of a blockchain network, Session adds a financial requirement for anyone wishing to host a server on the network, and thus participate in Session’s message storage and routing architecture.

So you have to pay to self-host, and that’s somehow an upside???

This staking system provides a defence against Sybil attacks by limiting attackers based on the amount of financial resources they have available.

Which is a fine explanation in a world where everyone has a relatively equal amount of wealth. This is the epitome of dunning-kruger economics: a little knowledge is a dangerous thing.

Firstly, the need for attackers to buy or control Session Tokens to run Session Nodes creates a market feedback loop which increases the cost of acquiring sufficient tokens to run large portions of the network. That is, as the attacker buys or acquires more tokens and stakes them, removing them from the circulating supply, the supply of the Session Token is decreased while the demand from the attacker must be sustained. This causes the price of any remaining Session Tokens to increase, creating an increasing price feedback loop which correlates with the scale of the attack

So the more nodes a single entity holds, the harder it becomes for other entities to buy nodes and break the monopoly? Did you take 3 seconds to think this through???

Secondly, the staking system binds an attacker to their stake, meaning if they are found to be performing active attacks, the underlying value of their stake is likely to decline as users lose trust in the protocol, or could be slashed by the network, increasing the sunk cost for the attacker.

“Assuming every user is a perfectly rational actor, malicious actors would be shunned. This is somehow due to the economic incentive, and not just how humans operate when they’re assumed to be perfectly rational.”

Also: malicious actors when they find out they might lose their money if they get caught: “welp, I better not do that then. Thanks laissez-faire capitalism!”

Jesus christ fucked on a pike, these dipshits really drank the crypto kool-aid, huh?

Con Te Partirò - Andre Bocelli
遙か彼方 - ASIAN KUNG-FU GENERATION
アイワナビー - Stance Punks
I Samma Bil - Bo Kaspers Orkester
A 67-Es Út - Republic
Papaoutai - Stromae

Since you’re installing Debian, presumably you’ve done the required reading according to their wiki, and seen the DontBreakDebian page.

If not, here’s the portion I’m thinking of (emphasis mine)

Don’t make a FrankenDebian

Debian Stable should not be combined with other releases carelessly. If you’re trying to install software that isn’t available in the current Debian Stable release, it’s not a good idea to add repositories for other Debian releases.

First of all, apt-get upgrade default behavior is to upgrade any installed package to the highest available version. If, for example, you configure the forky archive on a trixie system, APT will try to upgrade almost all packages to forky.

This can be mitigated by configuring apt pinning to give priority to packages from trixie.

However, even installing few packages from a “future” release can be risky. The problems might not happen right away, but the next time you install updates.

The reason things can break is because the software packaged for one Debian release is built to be compatible with the rest of the software for that release. For example, installing packages from forky on a trixie system could also install newer versions of core libraries including libc6. This results in a system that is not testing or stable but a broken mix of the two.

Repositories that can create a FrankenDebian if used with Debian Stable:

• Debian testing release (currently forky)
• Debian unstable release (also known as sid)
• Ubuntu, Mint or other derivative repositories are not compatible with Debian!
• **Ubuntu PPAs and other repositories created to distribute single applications **

Some third-party repositories might appear safe to use as they contain only packages that have no equivalent in Debian. However, there are no guarantees that any repository will not add more packages in future, leading to breakage.

Finally, packages in official Debian releases have gone through extensive testing, often for months, and only fit packages are allowed in a release. On the other hand, packages from external sources might alter files belonging to other packages, configure the system in unexpected ways, introduce vulnerabilities, cause licensing issues.

Once packages from unofficial sources are introduced in a system it can become difficult to pinpoint the cause of breakage especially if it happens after months.

I would personally add that this isn’t a case of “if”, but rather “when”. Even if it works at the beginning, all it takes is Mint deciding they want to use a newer library when they update the package you’re using, and suddenly your system won’t boot and there’s no clear, easy solution other than “restore from backup.”

Even if you know what you’re doing, I would limit tinkering to binaries managed in the $HOME/.local/bin (and any applications that work as package management for that, like cargo, pip or homebrew) or packages that you completely control yourself (such as through git pulls and compiling yourself).

“Stick to the official repo” is generally the advice I would give for any distro, with the exception of DIY OSes that are intended to be patchwork, like gentoo or Arch.

THAT BEING SAID: I’m not saying “don’t install without a DE and piece your desired DE together from their parts.” Debian has a lot of DEs, window managers, and their individual parts all in the official repos; a lot of the difference you see between the versions Debian offers and the versions Mint or Ubuntu offer are basically just theming that you can do yourself without altering the system packages.

If you absolutely must install a 3rd party repo, just understand you are sacrificing Debian’s selling point of stability, and waiving your rights to hold the Debian Maintainers responsible; and when your system breaks (which might not be for many years), it will be entirely your own fault.

Since you can run the apps (glitchy as they may be), nothing is wrong with the read perms on the drive. Maybe write perms or exec perms? But ntfs perms don’t map neatly onto POSIX perms, so it’s hard to say. Maybe try setting the gid to the vboxuser group id and see if that helps?

You might also check out the mount manpage and look at the section about “Generic Mount Options”; this is the more in-depth explanation of the “options” column in fstab, and the defaults option (which depends on the distro) can hide stuff like nouser, which prevents users from mounting the drive.

Finally, look into ACLs and how to manage those for interoperability across Windows and POSIX systems.

Best case scenario, fixing it so your user has all access to the drive with the user,exec options fixes your issues. Otherwise, you’ve just gotta do the learning about ACLs and POSIX perms