Hacker News Reader

> You can just enjoy the fact you know you chose someone you trust (us!) with your data.

That stood out to me as poorly phrased, as well. They're assuming I trust them. Even if I do/would have, it's a turn-off.

I agree completely. I thought the point of element and matrix was that I don't trust anyone, and that the messages are e2e encrypted. I guess maybe metadata is still accessible by Element?

Calling Matrix decentralized is a little misleading. If's a federated protocol that still relies on user-trusted "home servers". Currently the majority of folks use the `matrix.org` home server, but a number of other folks (like myself) operate their own home server.

This means if a user on the matrix.org server is talking to another user either on matrix.org or elsewhere, matrix.org (and the 'elsewhere' participant's server operator) will be able to determine who is talking to who.

Also of note is that e2ee is optional, which makes sense because Matrix isn't just a replacement for direct user to user or small private group messaging, but also large public groups, where message content is intentionally public, and e2ee just adds overhead.

As I understand it, the consensus is to call multi-server systems "federated" and peer-to-peer systems "decentralized". So I agree that Matrix should be called the former and not the later.

You'd better trust them with your metadata, unless I'm misunderstanding their protocol.

I also think the explanation could use a bit of work. If I have more than 5 users, do I need to switch to Nickel? Get another Home plan?

Up to 5 Monthly Active Users are included in your subscription. After that you can add additional users at an additional $2 per user per month.

It's worth noting that the Monthly Active bit can be quite important. What this means is that you're not charged for the number of users registered on your server, but the number who are actively using the server. Users are only considered as "active" and counting towards the number that you pay for if they use the account for more than two days in a rolling 30 day period. The aim here is that you're not penalised for occasional or "drive-by" users of the service.

(Disclaimer -- I head up EMS (Element Matrix Services))

This is so much more expensive than Slack. If you were comparable you might have a sell with E2EE but this seems way off.

[edit: seems like I failed to parse Slack's pricing page. Slack is expensive as hell. Carry on]

Are you kdding? Slack is at least three times that:

> €6.25 per active user per month billed annually. > Or, €7.50 per active user per month, billed monthly.

https://slack.com/pricing/standard?from_pricing=1

The mobile page wasn't that clear... That is not cheap at all. Thanks.

That's smart - I know I've had a couple of folks interested enough to download the app, but not interested enough to use it on a daily basis.

If I may, I'd like to push a little deeper on this. Why the single-digit user limit at that price? Doubling or quadrupling the users, or halving the price, would make it a no-brainer of an option to point people to if they don't want to go through the trouble of setting up their own server. As it stands, the pricing feels restrictive to the point where I would feel punished for growing my server (I'd instead tell someone to get their own matrix.org address, at which point it sounds like we could just use Discord/Signal/Slack?). The extra financial burden (these are my family and friends, so I would never ask them to chip in) would actually incentivize me to keep my server as small as possible, which is the antithesis of what the goal of a hosted service should be.

As I write this, I'm realizing that there's no real utility here for anyone technical enough to warm to Matrix/Element's strengths. We can talk about the everyman who's not on HN all we want, but my hunch is that those people would rather just use Signal or Discord based on their use-case - no confusing concepts like "homeservers" and "federation". With a user limit and the current pricing model, every use-case (from a short tryout to a long-term personal homserver) is better served either by the free matrix.org model or by a self-hosted solution.

I had the same thought, but do your dozen folks use video calls on your instance? Does it work well enough? I'd definitely expect to be able to host a text-only instance for $5, but maybe they also need to provision for more demanding features?

I only use Element / Matrix as an IRC replacement for now so I couldn't tell.

AFAIK, Matrix does not support Video chat yet?

But the VoIP/audio chat is using WebRTC, so Matrix is only the signalling server and the audio is p2p between the participants. As such the strain on the hosting server should be minimal

Even if it's P2P, you still need TURN servers because participants might be behind NAT that are hard to pierce through. This basically means you're proxying the full video traffic between both participants.

Have you had success with encrypting TURN servers? In trying to host my own Matrix server and have E2E encryption for texts, video, and voice, I found that video/voice had to be disabled as Let's Encrypt and SSL weren't compatible.

You definitely can make it work with Let's Encrypt, that shouldn't disturb anything.

Setting up STUN and TURN is a real pain, though, if you run into any issues.

Interesting! Were you able to set up a fully encrypted TURN server to use with Matrix? Any tips? I wasn't able to succesfully.

Tip: read the "Be precise and informative about your problem" section [0] of the infamous "How To Ask Questions The Smart Way".

Actually, I'd suggest reading the entire document when you have time. For now, though, at least have a read of that section (it's short and sweet).

[0]: http://www.catb.org/~esr/faqs/smart-questions.html#beprecise

That was a good tip, thanks! :) Will read the document so I can be a better contributor in the future.

If you pop in to #voip-tester:librepush.net I may be able to lend an ear at least.

You won't be the first (nor the last, though if I can have the chance to improve that at some point I would love to) person to have struggled with it.

Thanks for pointing me in this direction!

Matrix supports both video and audio chat over WebRTC. IIUC this provides strong e2e encryption and very good performance (it is the best looking video call I have used as they don't seem to really have any limit on the resources used because it is p2p). However it is limited to 1:1 right now.

Element (and some other clients, but I don't think it is part of the standard) also supports multi-user voice and video using Jitsi which works very well but you loose e2e encryption (although IIUC Jitsi has some experiments for this) and need to run it separately.

I host a Matrix server for my family and we regular make audio calls to Australia. I had to try a few services before I found a $5 VPS that worked well, but network was always the limiting factor rather than server specs. The unavoidable latency makes video calls unpleasant so I can’t speak to that.

Hmmmm, which service worked well for you? Interested in knowing.

I ended up at Genesis Hosting. Their web console is a little rough but the server specs and network performance are better than any other $5 VPS I’ve tried.

Have you tried using Mumble [1] to chat with your family? I ask because I have chatted with gamers that are in AU and NZ from the US with almost no detectable latency. I can see their latency in the client, but I can't hear it. There are open servers you can test it out with to avoid setting up the server and save you some time setting up the server in the event it does not work better.

[1] - https://www.mumble.info/

Interesting, I’ve heard of Mumble but never looked into it. Thanks!

With you. Something more like "element family" where all kith and kin can use it would be more valuable. 5 users for a household is ... weak use case.

> For 5 bucks a month I run my own server with almost a dozen folks on it, which requires basically zero maintenance (I can count the number of times I've had to go in and restart it over the past two years on one hand).

Yes, but how much work was it to get set up in the first place? There's a reason that people pay for Wordpress subscriptions, even though you and I can set up static hosting off Gitlab pages (for example) for free. I do think the pricing is slightly steep but you can charge a premium for making it usable by the masses.

Anecdotally, it took me about an afternoon. I realize that I'm more technical than the average person, so setting up the certs and installing the python deps was a breeze because I've done it before; the documentation for the synapse homeserver was also quite good.

I see where you're coming from, but is this offering geared towards people like that? Looks like there's a significant push to get people who've had their own servers running to adopt this new service, and Element as a whole is geared towards the techy DIY crowd. I know there have been concerns raised in other threads about its UX problems, and from personal experience most of my friends don't share the same concerns that I do about data security or bootstrapped personal infrastructure.

And if $5 a month is worth the hassle of self hosting, I'm glad you have a way to save it. My time is my most valuable resource, if I can get the benefits of self hosting, and not have to do the work, I'll spend that $5 any day.

> Looks like there's a significant push to get people who've had their own servers running to adopt this new service

How do you mean? I run my own, and there’s zero push to move or migrate to Element Home.

I’d imagine this only targets folks with accounts on matrix.org.

> You can just enjoy the fact you know you chose someone you trust (us!) with your data.

Yeah, no. Blast from the past:

https://news.ycombinator.com/item?id=19642554

This is the entity/company who decided to revoke clients keys because not because the users messed up but because they messed up and therefore destroying access to the users messages and defended that as the approach!

Their quote related to the incident and deleting keys (GPG release signing keys on prod machines, no locked down servers, etc leading to the hack):

>You might have lost access to your encrypted messages.

>As we had to log out all users from matrix.org, if you do not have backups of your encryption keys you will not be able to read your encrypted conversation history. However, if you use server-side encryption key backup (the default in Riot these days) or take manual key backups, you’ll be okay.

>This was a difficult choice to make. We weighed the risk of some users losing access to encrypted messages against that of all users' accounts being vulnerable to hijack via the compromised access tokens. We hope you can see why we made the decision to prioritise account integrity over access to encrypted messages, but we're sorry for the inconvenience this may have caused. [1]

I think this shows they simply revoked keys to avoid the hacker accessing messages. Had messages been breached, that would have been significantly worse for an E2EE federated messaging platform.

[1]: https://matrix.org/blog/2019/04/11/we-have-discovered-and-ad...

They revoked keys of users without giving users a choice, ability to save, backup user messages etc.

It is a company with operations, engineering and business ran by amateurs that do not understand the foundation of any user facing business - when you have a choice between not destroying user data and devising a method to handle a situation even if it costs you and losing user data, you do the first.

Every single person that gives them his or her data to host is a toddler having a tantrum.

>As we had to log out all users from matrix.org, if you do not have backups of your encryption keys you will not be able to read your encrypted conversation history. However, if you use server-side encryption key backup (the default in Riot these days) or take manual key backups, you’ll be okay.

I'm not defending them, in fact I prefer XMPP+OMEMO (or I would if I had someone people to talk to). But it seems like the default is key backup which means a significant number of users do have access to their old messages once they restore their key.

>Every single person that gives them his or her data to host is a toddler having a tantrum.

I mean, if you're criticizing a central server in a decentralized platform, agreed, I don't like the heavy influence a single "default" server will have, which is why I self host for myself and any friends/family who want to use it.

Keep in mind that this was a bad hack and IMO they made the right decision to revoke keys (alternative is possible leak of every message, ever sent on their platform) but I don't like that it came to that. Do you think they should not have revoked keys, and if so why? If you're criticizing about the hack in general, though, 100% agreed.

> Keep in mind that this was a bad hack and IMO they made the right decision to revoke keys (alternative is possible leak of every message, ever sent on their platform) but I don't like that it came to that. Do you think they should not have revoked keys, and if so why?

That is not a decision for them to make, rather that is a decision for their users to make. Their inability to understand that the mantra of a company that happen to carry user data is "Shall not lose user's data" means the are not tall enough to take the ride.

> If you're criticizing about the hack in general, though, 100% agreed.

That's a separate topic. Their operational security was atrocious, which even by itself should be a reason why one should highly discount their hosted promises but to me inability to understand that under no circumstances they can choose to destroy user's data trumps it.

>That is not a decision for them to make, rather that is a decision for their users to make.

At which point the data could be taken and leaked. That would end the company, protocol, and platform forever.

>Their inability to understand that the mantra of a company that happen to carry user data is "Shall not lose user's data" means the are not tall enough to take the ride.

I think having lost data is better than having it stolen and lost...

>That's a separate topic. Their operational security was atrocious, which even by itself should be a reason why one should highly discount their hosted promises but to me inability to understand that under no circumstances they can choose to destroy user's data trumps it.

I concur. Again, not arguing against that there were significant failures, missteps, and mistakes that led to this. But saying "the users should have the choice" simply would have opened up the risk of a more serious attack at the whim of whoever was doing the attack...

> At which point the data could be taken and leaked. That would end the company, protocol, and platform forever.

First of all, Could and is are two different things. Second of all, if the protocol and company are so badly designed that "could" is equal to "leaked" then it should be the end of the the protocol and the company.

> I think having lost data is better than having it stolen and lost...

Not "stolen" vs. "lost" but "possibly stolen" vs. "definitely lost". It is up to a user to establish if they think that "possibly stolen" is worse than "definitely lost"

> But saying "the users should have the choice" simply would have opened up the risk of a more serious attack at the whim of whoever was doing the attack...

Absolutely not. That's the trade off that one makes when deciding to handle user data. Encryption and backup strategies come into play there. The company in question had not bothered to think about it.

>Not "stolen" vs. "lost" but "possibly stolen" vs. "definitely lost". It is up to a user to establish if they think that "possibly stolen" is worse than "definitely lost"

Not when you are in a critical situation and you don't know if the attacker is exfiltrating data right now.

>Not "stolen" vs. "lost" but "possibly stolen" vs. "definitely lost". It is up to a user to establish if they think that "possibly stolen" is worse than "definitely lost"

No, it's "possibly stolen" vs. "lost if you don't have your password and can't log in", because: "No keys were revoked (nor does Element have the power to do so). What happened was that existing user login sessions were destroyed and users had to log in again." https://news.ycombinator.com/item?id=26316147

No keys were revoked (nor does Element have the power to do so). What happened was that existing user login sessions were destroyed and users had to log in again.

If you had either backed up your keys locally or had an encrypted copy of your keys stored on the server-side as a backup, no access was lost.

If the keys were associated with a session, then it quite literally demonstrates how clueless the company and its engineers are:

1. Send a message to the users with the existing sessions telling them to create backups.

2. Have users confirm that the backups were created

3. Log users that created backups out.

There's no excuse at losing user's data. Ever.

I ran the response for the Apr 2019 incident that you're digging up, and fwiw:

* The breach impacted the free best-effort matrix.org server & infrastructure, not Element Matrix Services (the subject of this HN thread).

* We didn't "revoke user keys", we logged users out on matrix.org whose password hashes & login access tokens had been exposed.

* At the time we were in beta, and there was only one mechanism to logout users: a 'hard logout' used to evict client sessions which would cause them to clean up their local data; the common case where as a user you want to kick off old sessions and don't want to leave your keys littered around. Before exiting beta in June 2019, we implemented 'soft logout' as a mechanism to expire access_tokens without clients cleaning up data: https://github.com/matrix-org/synapse/issues/4280. Given the urgency to protect user data immediately after the breach, we couldn't release new clients to expedite soft logout, so had to go with hard logout.

* However, any user who backs up their E2EE keys, either online (the default configuration), or offline was unaffected. To repeat: the default configuration was to nag the user into backing up their keys, encrypted, on the server, for precisely this sort of situation. And to the best of my knowledge I don't recall anyone who reported having lost data to us.