This comment alone should be reason enough for the company behind Element to sue Google.

Google may be able to control the Element app on the play store, but at least for the server side there's no way to do that with synapse (the official matrix protocol server side implementation), which is fully open source and distributed directly from the developers.

They are also working on a Go version called Dendrite - https://github.com/matrix-org/dendrite

The Matrix team is doing a LOT of cool stuff. :)

Yes, but IMO the Matrix team should _really_ focus on Dendrite since Synapse is extremely resource hungry and prevents a lot of people (including me) from running their own servers.

It's not that resource hungry anymore. Hovering stably around 500M RSS and 8% CPU for me right now. That's with ~25 users and a lot of federated, public rooms, some of them quite large.

What CPU are you running it on and how many cores are being used? Are you also in really large rooms like Techlore and Matrix HQ? Because I think I'm in all of the largest rooms (and a lot of the smaller ones)

I'm running my instance with lots of bridges in a 3-core 4GB server, paying about eight euros a month for it. Synapse runs just fine, but I'll probably switch to the Rust impl when it's done.

If you want to go cheaper and have only 300-400 Mbps of bandwidth, I've heard lots of good things about this provider:

https://contabo.com/en/vps/

Contabo is great: finally a provider that does not save on mem and disk space. I moved everything to them and I save tons of money. The 400mbps is only for the cheapest as well: you can pay more to get more. Not that most people would need more. Especially for running matrix for a company etc.

Not those two (and I know those are especially large), but we are in many 5-10k rooms, including bridged Freenode rooms which are known to be some of the worst offenders.

Note that many significant improvements have landed very recently, for instance the chain cover stuff which significantly improves handling of rooms with frequent membership changes (such as the aforementioned bridged IRC rooms).

8% CPU average actually sounds like a lot, unless your 25 users are chatting around the clock.

The federation is chatting around the clock. Remember, joining a Matrix room means that your server needs to handle all of the room's traffic. And 25 users can easily be in a lot of large rooms. However, each room only needs to be handled once, so if more of my users join a room in which my server is already participating, the cost doesn't increase.

That said, this isn't an average but a spot value. It frequently falls below 8% (though typically stays above 5%). Note that this is a cheap and relatively weak VPS.

I'm not saying Matrix is terribly lightweight. I'm saying you can easily run a small personal instance on a cheap machine without any performance problems.

If I run Weechat on my VPS, and join a few high-traffic IRC rooms, I expect my average CPU use to be 0%. Same if I run mailman with a few messages per minute, or an IRC server.

The fact that we can now run it on a VPS is an improvement, but it is still orders of magnitude heavier than equivalent non-decentralized systems.

How can you rely on the app/play store for any app? This suspension has nothing to do with element, it could have been any app.

Can't you just use a web app or any other matrix client if this happens?

If Google were to "ban" slack from their store, their browsers, etc. then you would be quite in trouble.

But with matrix, just pick a different client and move on.

Yes, I'm doing a custom react client integration. AA has to prepare for black swan events from every angle and this is a perfect example of one.

When you have 100,000+ employees, it's not trivial to just switch up communication platforms.

If you need to prepare for Black Swan events, doesn't it make sense to have your own channel to distribute APKs to all devices? Why would you rely on the Play Store at all?

that’s a lot of tooling to build for a single application—plus not everyone is tech savvy and installing from non-standard locations requires more user support

A 100K-sized company is going to have a BYOD or corporate device issuance program with tie-in to MDM, which effectively functions as a private appstore (the DPC (device policy controller) (itself an app) can silently install apps (as in, download APK from $anywhere, hand to PackageManager) without confirmation, etc).

MDM infra is big bu$ine$$, but DPCs are quite simple to write.

(Psst. They also let you read CPU usage on Android 7+ (sadly not per task, but at least with per-core granularity). The catch? Installing a DPC requires a factory reset. xD)

> A 100K-sized company is going to have a BYOD or corporate device issuance program

Some will, some might run a more open org, with a lot of rather independent contractors, focusing on providing services on standard platforms (email, chat, wiki, bugtracker etc).

Not every device is under MDM in a big corp. Often you have people like external consultants bringing their own devices, who need to participate in (semi-)internal communications. You cannot just MDM those and you cannot just issue bigcorp devices to them, so you need something like the normal appstore to distribute the software. Maybe you even have BYOD for internal people, so MDM could be hairy from a GDPR/employee rights/liability standpoint. And maybe you even have customers and partners who you want to communicate with, whom you have to provide with a viable option of communicating. You can (maybe) separate those into an internal and an external communication tool. But then you just have two different tools, one of which will have the exact same problem about needing installation via commonly available appstores.

It's easier to simply ensure that the apps you need are present in multiple stores.

I take your meaning, but pedantically I think the idea of black swan is that you couldn't ever see it coming, so the only way to prepare for it is some sort of general robustness (which to be fair Matrix does have).

Let each user pick among any of the multiple clients available. Don't design your system / process to only support one client.

It puts too much pressure on Helpdesk to provide the support needed when you don't have a common path.

This reality should be yelled by a death metal band singer 24/7 at every FOSS developer.

I laughed hard ... but actually no.

That should be yelled at every FOSS evangelist, those people who claim everywhere that no one needs Windows, because Linux has everything Windows has, just better, etc.

We FOSS developers are free to do what we want. Most of us develope mainly for pleasure, not to ease the workload of some corporate helpdesk.

I'm arguing against the hidden premise that "having a dozen different client thingies" is a potentially good thing for users. It nearly never is, and the fact that a dozen devs derived pleasure from creating them doesn't change that.

I'll go even further and claim that "user choice" is code for, "warning: nobody in this space is competent enough in UI/UX to derive pleasure from working on it." In fact in mastodon's design, it's not even code-- the "choice" of servers by topic is literally a limitation imposed on the user before even signing up. So the very first part of the UX has a circular dependency-- choose a server to try out the service and discover which server most suits your interests. It'd be like Google redesigning search so that you have to type subreddit-style topic into the URL before searching.

Additionally, this "choice" meme seems to conveniently disappear for software that has a thoughtful UI. I don't see anyone talking about the downside of Krita not having multiple other half-baked UI's than very impressive one it ships with.

There are debug version apks available here: https://buildkite.com/matrix-dot-org/element-android/builds/...

Click on "Assemble GPlay Debug version" (or "Assemble FDroid Debug version" if you don't have Google Play Services), then click on "Artifacts" and then choose your apk from there.

How is that a solution to the problem? Of course there's other ways to install software, just like you could build your own iOS app and sideload it with a certificate. If an app is gone from the store it's basically dead.

If I were to test the implementation of an app in my enterprise, then it would benefit me to cut down on the unnecessary dependencies. Being dependent on the Google Play Store has shown to be a liability in the past because there were moments where it became a single point of failure (as demonstrated in this thread)

Sorry for this :((

There are alternative clients: https://matrix.org/clients/

FluffyChat would be the main contender.

Big players with clout can commission their own closed access app. The C levels just need to take a $0.5M hit among themselves.

Reach out how? You have no public contact information in your HN profile.

We've already had conversations and I reached out personally.

That's why XMPP has been adopted for military and industrial use.

You can use FDroid though.

How are you going to explain that to your manager?

How does your manager explain to you that you must agree to TOS from Google to install apps necessary for your job?

In the explanation to a company I see nothing wrong. In the tendency to make employees agree to arbitrary ToSes, I see massive liability that should be dealt with using a massive class action lawsuit against some behemoth.

I actually think federated protocols are a get out of jail card for employers since making your job related to owning a car is reasonable, to owning a specific brand of car is not.

Hello employee,

We have a new corporate policy that removes your access to anything related to O365 by Date. The only way to remediate this issue is to install InTune and the corresponding corporate security office's profile so it can enforce our policy on the device. If you qualify for our corporate device program, we will cover the cost of the device and data plan.

Sincerely, CTO

Honestly, it's very common at the largest public corporations and most corporate r&d groups in the US. It's not like we don't already do black box development or have strict vpn only enforcement rules. I wonder how risk assessment sees these kind of federated protocols because in theory you are right about it reducing liability if they run the system.

You’re lucky if you work a place that even sends you an email when they make unilateral changes to the software that’s running on employer-owned hardware. Everywhere I’ve been has a management engine running with highest privileges that does whatever it wants, this used to be true only in industries like finance and healthcare but now it’s standard.

Maybe places like google are different, I would not know but I’d be surprised to learn that there’s any publicly traded company that does not exercise total control of their machines.