Impossible to take them seriously if they have already started off on the wrong foot using exclusively megacorpo proprietary platforms for coms. If your developer / testers privacy doesn’t matter since they opted for Microsoft GitHub & Discord, what would lead you to believe their project would take privacy seriously?

For the masses maybe, but Signal & Bluesky ain’t it for a Privacy forum

Always was 🔫🧑‍🚀

Persistence is for forums. Chat has horrible discovery / search UX which makes it a black hole for knowledge—which is why it should be seen as temporary (I think even Signal sets 4 week expiry as default). Folks often say things the regret 5 years down the line in chat space & that sort of info needs to just fade away than be some target of some weirdo doxxing campaign.

You know you can have archive management & multi-devices without syncing the entire history right? Some protocols think holding onto the last 20 messages in a new group & the last year of private messages is good enough (can be saved local to the device if desired). Copying the Discord/Telegram/Slack model ain’t it.

Synpase is the reference server. It’s Python & slow as balls because of it, but the others are always playing catch-up. With Element moving with it & graceful fallbacks not being a high priority, shit just doesn’t work in practice using anything but Synapse / Element since most other users are using features on that setup. Technically having alternatives is not the same as the current situation in actual practice. Even if they can try to hide the some of the perf issues behind these gland concepts like sliding sync, there are literal fundamental issues with how the protocol is architected that a server of hand-written optimized assembly could never overcome—the eventual consistercy is by design.

That is nowhere near the mass of the centralized community & the fact it can’t be reasonable ran my medium-sized groups on a budget shows it doesn’t scale right & is not accessible. Sure you can run your own ATProto/BlueSky node if you have $80k USD / mo to host it—it’s technically open source! This is the kinda the same thing… costs too damn much so folks flock to the buggered instances.

One of the big flaws of snapshot-based VCSs like get is the patch order mattering—which causes conflicts. I would love to see an alternative built on Darcs or Pijul with their Patch Theory-based VCS system that does not have the flaws Git does.

Matrix literally syncs the entire data/metadata history to all other servers where someone pops in; chat is meant to have an ephemeral aspect to it. The whole network is de facto centralized on Matrix.org or the servers they host for others which means one org has access to almost everything—like the issue with Signal.

What’s scary to me is how expensive it is to run this eventual consistency model, which should not be a protocol requirement for this style of communication. It sucks so much RAM, so much storage, so wasteful—which causes medium-sized servers to shutdown on maintenance costs alone which causes more users to leave for the Matrix.org. These are not the characteristics of a revolutionary protocol—revolutionary is users & collectives to reasonably be self-hosting this stuff for their privacy & autonomy.

It takes 2 to tango. It’s like trying to send an email from a self-hosted email server without following all of Google’s rules/guidelines… which means you won’t be able to send a message to most (sadly). Most folks are either on Matrix.org or a server they host in practice… you alone self-hosting will only help if you only communicate to folks also doing similar… to which if just one user from Matrix.org (or a server they host) joins your chatroom, then literally everything that is being & has been said in that room will now be synced to Matrix.org by its protocol design. With the expense it takes to self-host Matrix for a community, almost all medium-sized communities had to drop it on RAM & storage costs alone which caused most of those users to move to Matrix.org. You can run a single-user host with some efficiency, but most users are not technical enough for this. The only option to use Matrix & keep costs down is to unfederate… at least with Matrix.org (& servers they host), but that now defeats a huge part of the argument those saying Matrix is federated/decentralized.

It isn’t decentralized in clients or servers either. Almost all servers must run Synapse which is resource intensive but actually has the features folks expect as the de facto reference server & Element is the only viable client considering most users will be using Element-exclusive features like threading, polls, etc. where protocol hasn’t done a great job of providing a progressive enhancement approach to its features & so folks on alternative clients straight-up just don’t see / can’t interact with this stuff.

The accessibility to small–medium-sized communities matters if you want a healthy federated/decentralized network …but luckily there are alternatives.

AFAIK, chat.mozilla.org was set up on modular.im, now element.io, which if it still using the same host, is owned by Matrix.org. So even using a different host means Matrix.org might still have your metadata.

OMEMO is a mixed bag. Some clients are still preferring older versions that aren’t the best for security & almost every client does a bad job explaining that new keys are being used need to be verified… Gajim only recently gave a decent in-client pop-up for it, but it’s doesn’t work all the time. That said, this is basically the same issue Matrix has in the space. Both are based on libsignal if not outright using it, except Signal gets a point of privilege in basically having just one client …one that must be on Android/iOS according to their statements… so they can do a ‘better’ job managing who, what, & how many keys are being used. Many XMPP clients will recommend blind trust by default just because it can be a real hassle to deal with multiple clients & users coming back to less-often-used devices. There have been proposals to fix it, but I haven’t seen anything really take off (meanwhile considering just using the PGP encryption option as less flaky).

It’s worth following the project but it’s a bit too new & the funding aspect leads me to question how it will work in the long run (& being written in Haskell is neat, but boy does it have a lot of churn & maintenance issues in its ecosystem).

Matrix is centralized too in practice … & syncs even more metadata than Signal so I wouldn’t call that an upgrade—especially when you see how slow the clients & servers are.

Matrix.org is centralized like Signal (you can say Matrix is not centralized on paper, but in practice this isn’t remotely true). Both are stockpiling metadata in the West… what’s worse is Matrix’s eventual consistency model means syncing metadata to all servers is a by-design requirement (& also why all servers & clients are slow). There are options like Snikket to take all the hard parts of self-hosting out of the equation, but finding someone you can trust to host a server might be worthwhile. I would be wary of anything centralized.

We could still be communicating cooperatively in a lightweight, decentralized manner had WhatsApp federated with & Facebook reverted unfederating with XMPP. 😥

I use Posteo for their low-emission plan using boring technology that just works. 1€ / to is worth it, but I do wish you could bring your own domain name.

Eventually you will find you want a mail provider that just supports IMAP / POP without some paid middleman application just to use you email with certain clients else me stuck on the slow web UI. Luckily there are alternatives.

That is anonymity, not privacy.

Wat. You are saying you can’t package Python application on a system level? That means the language’s package managament is broken. Nix unlike most package managers can do a reasonable job juggling multiple version of packages at the same time & stuff still breaks, & more frequently than anything in any other language other than Haskell.

There was also the SolarWind attack, Colorama, JarkaStealer, Cobo, pywx, Dropbox, PyTorch 2023. Zero-days galore.

Meant to be glue but is used in all sorts of places it probably shouldn’t. The way libraries are handled & pinned leads to lots of breakage—a couple applications I have overlays to disable testing since stuff gets merged into Nixpkgs with failing tests so frequently that I is better to just turn it off & deal with failures at runtime.

The ultralytics thing was massive last month https://snyk.io/blog/ultralytics-ai-pwn-request-supply-chain-attack/. These have been coming with regularity—even worse than npm.

I would at least agree Lua is a better place to start—at least for a dynamic scripting language. It is not a complicated language & it even supports tail recursion which you can’t say about far too many languages.

It is slow. Syntax & community idioms suck. The package ecosystem is a giant mess—constant dependency breakage, many supply-side attacks, quality is all over the place with many packages with failing tests or build that isn’t reproducible—& can largely be an effect of too many places saying this is the first language you should learn first. When it comes to running Python software on my machine, it always is the buggiest, breaks the most shipping new software, & uses more resources than other things.

When I used to program in it, I thought Python was so versatile that it was the 2nd best language at everything. I learned more languages & thought it was 3rd best… then 4th… then realized it isn’t good at anything. The only reason it has things going for it is all the effort put into the big C libraries powering the math, AI, etc. libraries.