Element Matrix Services Announces Element Home(element.io)
element.io
Element Matrix Services Announces Element Home
https://element.io/blog/element-home/
168 comments
> 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.
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.
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))
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))
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.
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.
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]
[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
> €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.
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.
I only use Element / Matrix as an IRC replacement for now so I couldn't tell.
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.
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/
[1] - https://www.mumble.info/
Interesting, I’ve heard of Mumble but never looked into it. Thanks!
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.
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
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
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.
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.
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.
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
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.
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!
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.
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.
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.
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!
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...
>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.
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.
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. 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.
>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.
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
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 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.
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.
* 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.
"Dedicated server" mentioned 4 times in that article. In hosting world, dedicated server means real physical server. I wonder if that's just marketing speak and in reality it's virtual server or they really install a separate server for every customer.
I think this bit of marketing speak was popularized by discourd - and inspired by team speak and ventrillio - all of which talk about chat "servers".
Its particularly odd with discord, as they clearly mean "instance" not "server".
Sure, it's a chat server daemon (like you could get a web server daemon) - but I think "dedicated private instance" would be better. Should probably drop the misleading bit about "not sharing resources" as I assume instances aren't that isolated?
Its particularly odd with discord, as they clearly mean "instance" not "server".
Sure, it's a chat server daemon (like you could get a web server daemon) - but I think "dedicated private instance" would be better. Should probably drop the misleading bit about "not sharing resources" as I assume instances aren't that isolated?
A dedicated server seems like overkill. A shared VPS works fine for many realtime applications, even fast-paced games that host 50 players concurrently that send out updates every 32 milliseconds, like agar.io, diep.io, or vnav.io.
If I wanted lower latency, I would add WebRTC-based P2P chat for those who support it, to connect directly between servers.
If I wanted lower latency, I would add WebRTC-based P2P chat for those who support it, to connect directly between servers.
I wanted to add: "Dedicated server" in the cloud business refers to a 1-to-1 mapping between server and physical computer. A "virtual server" is one that maps onto a physical computer when it actually needs the CPU. There are generally two types of virtual servers: A very low-end one running ARM or Intel ARM slower than your typical 1.3GhZ laptop, and a very high-end one typically used for CPU-bound applications.
The cheapest dedicated host on AWS costs $370/month: https://aws.amazon.com/ec2/dedicated-hosts/pricing/
So Matrix is misusing cloud terminology when it says "dedicated server."
The cheapest dedicated host on AWS costs $370/month: https://aws.amazon.com/ec2/dedicated-hosts/pricing/
So Matrix is misusing cloud terminology when it says "dedicated server."
There are cheap dedicated servers, for example check out scaleway. I think they're around $10/month. They're slow Intel Atoms, though.
I agree, I just think that this particular wording introduces unfortunate confusion. Virtualized cloud solutions should work just fine for most uses.
Its $10 a month - unless they're using raspberry pi's, I think you can assume virtual servers.
server as in the server daemon, not server as in the physical server.
I would phrase that as 'server instance.' Their language like "you’re sharing minimal infrastructure with anyone else" does reinforce the idea they mean physical server.
Maybe "dedicated" and "infrastructure" are being abstracted into meaninglessness as cloud computing matures.
Maybe "dedicated" and "infrastructure" are being abstracted into meaninglessness as cloud computing matures.
they could have used "personal server" instead ?
My understanding of it was that it would be a dedicated instance of the matrix server software using your own domain and not the shared matrix server.
For those interested in self-hosting the home server, I would recommend https://github.com/spantaleev/matrix-docker-ansible-deploy - the documentation is fantastic and it’s very well maintained.
I'm personally waiting for Dendrite. Apparently the beta is usable now, setting it up has been on my to-do list.
I self host Synapse for personal use, what are the expected benefits of Dendrite? Is it mostly the performance gain of Go versus Python, or are there other reasons to be looking forward to Dendrite?
My main issue with self-hosting has been federation bandwidth requirements. I joined the very quiet `#homeowners:matrix.org` announcement room, but because almost 600 other people are in there my server was inundated with presence messages (just in case I wanted to know which of those 600 were online right now).
Oh, and there's no way to prevent receiving these messages. They arrive on the same endpoint as non-presence messages, and you can't signal to the sender to stop sending them.
Oh, and there's no way to prevent receiving these messages. They arrive on the same endpoint as non-presence messages, and you can't signal to the sender to stop sending them.
I’ve been hosting my own matrix server for just a few months now. I have a small handful of users. Bandwidth hasn’t been a problem for me, as I’ve only served 5GB in the last 30 days. It’s the sheer number of requests that the server handles that I find staggering. In the last 30 days, my server has handled 1.3mm requests!
It seems like everything polls for data, which I see as wasteful. I recently saw they were adding socket support in a recent MSC... hopefully that will help.
It seems like everything polls for data, which I see as wasteful. I recently saw they were adding socket support in a recent MSC... hopefully that will help.
Unfortunately not a solution for federation with other servers, but you can disable presence on Matrix servers you control.
For this playbook, use these variables:
For this playbook, use these variables:
matrix_synapse_use_presence: false
matrix_client_element_enable_presence_by_hs_url: {"https://matrix.yourserver.com": false}Thank you. I had that set for my server, but I just wish there was a way to tell other servers not to send them. Disabling them on my server turns them in to a no-op, but it still has to process all those requests.
The minute you mention Github, you lose 98% of human beings? This is clearly aimed at those who just want something to work out of the box, surely? HN is not the target audience I guess.
This sounds cool for non-technical people, who don't have the skills to setup their own self hosted Synapse &/or Element server. Let's be real, for folks who don't frequent HN, that's just about everyone. Seems like a good option for them, and a good way for Matrix to generate income. Great news as far as I'm concerned!
Sounds like some are complaining about the price, but it seems more than fair to me. Heck, I host my own Synapse instance, but I might consider this in the future. Not that the maintenance is a problem, I don't think I've had to touch it since I set it up. But it might be worth it to not ever have to go in and do upgrades, or worry about something going wrong.
Sounds like some are complaining about the price, but it seems more than fair to me. Heck, I host my own Synapse instance, but I might consider this in the future. Not that the maintenance is a problem, I don't think I've had to touch it since I set it up. But it might be worth it to not ever have to go in and do upgrades, or worry about something going wrong.
The day the element and jitsi projects marry and offer a single $10 plan for secure chat and group video all the commercial providers can pack up... But I fear the day may never come.
Element has group video calls using Jitsi integrated
I think Jitsi is build on XMPP for chat right? XMPP already offers federated and e2ee chat.
While I love Matrix and support their mission, this pricing is quite a bit steep, as well as the 5-person limit being too restricting. They will price out large majority of people who actually could/would want to switch.
Hi - Yep, we totally get that this won't be for everyone. We're currently looking for ways to be able to increase the efficiency of these smaller servers and to be able to pass those cost reductions on to customers. We've also got some projects in the works aimed at being able to offer single account / single user "homeservers" and obviously the pricing for these would be much lower, but we're not quite there yet. More info. on this as soon as we have it.
In case it's not clear, it isn't a 5 person limit for Element Home servers, it's just that up to 5 (active) users are included in your subscription. You can add more users at any time for an additional $2/month. Also bear in mind that you're not charged for everyone registered on your homserver, just the ones that are using it :)
(I head up Element Matrix Services / EMS)
In case it's not clear, it isn't a 5 person limit for Element Home servers, it's just that up to 5 (active) users are included in your subscription. You can add more users at any time for an additional $2/month. Also bear in mind that you're not charged for everyone registered on your homserver, just the ones that are using it :)
(I head up Element Matrix Services / EMS)
What hosting provider are you using? AWS, GCP, and Azure are several times more expensive with the same performance as smaller providers, of which DigitalOcean provides the worst performance. (50% less) https://vpsbenchmarks.com
Currently we're using AWS (but we're hoping to become more cloud agnostic in the future).
(I head up Element Matrix Services)
(I head up Element Matrix Services)
> Currently we're using AWS (but we're hoping to become more cloud agnostic in the future).
If you're not using Lightsail, you're overpaying. Look at this comparison: https://www.vpsbenchmarks.com/compare/ec2_vs_vultr
AWS bandwidth through anything but Lightsail is 1000 times more expensive. AWS servers are 3-5x more expensive. AWS isn't successful because it's good, it's successful because it has good marketing.
Look at OVH and Linode.
Is Element hiring, by the way? Here's a look at my skills, if you're interested: https://news.ycombinator.com/item?id=26305569
If you're not using Lightsail, you're overpaying. Look at this comparison: https://www.vpsbenchmarks.com/compare/ec2_vs_vultr
AWS bandwidth through anything but Lightsail is 1000 times more expensive. AWS servers are 3-5x more expensive. AWS isn't successful because it's good, it's successful because it has good marketing.
Look at OVH and Linode.
Is Element hiring, by the way? Here's a look at my skills, if you're interested: https://news.ycombinator.com/item?id=26305569
Thanks for the info on Lightsail. We'll look in to it as one of the options for the future.
As for AWS, yep, they're certainly not cheap, but they do have good points in quite a few areas and give you a great number of tools to build with. Hopefully the trick is not to get too dependent upon their infrastructure, and we'll definitely be looking to other cloud platforms to help bring the costs down in future.
> Is Element hiring, by the way? Here's a look at my skills, if you're interested: https://news.ycombinator.com/item?id=26305569
Yes, we are hiring (and are rapidly growing at the moment)! Thanks for the link - I'll pass it on to one of the team (not just saying that, I really will). That said, in the mean time you're probably best to have a look at the open positions (https://apply.workable.com/elementio/) and see if there's something there that particularly takes your fancy. If there is, apply, and say that Rick from EMS sent you via way of HN ;)
As for AWS, yep, they're certainly not cheap, but they do have good points in quite a few areas and give you a great number of tools to build with. Hopefully the trick is not to get too dependent upon their infrastructure, and we'll definitely be looking to other cloud platforms to help bring the costs down in future.
> Is Element hiring, by the way? Here's a look at my skills, if you're interested: https://news.ycombinator.com/item?id=26305569
Yes, we are hiring (and are rapidly growing at the moment)! Thanks for the link - I'll pass it on to one of the team (not just saying that, I really will). That said, in the mean time you're probably best to have a look at the open positions (https://apply.workable.com/elementio/) and see if there's something there that particularly takes your fancy. If there is, apply, and say that Rick from EMS sent you via way of HN ;)
> As for AWS, yep, they're certainly not cheap, but they do have good points in quite a few areas and give you a great number of tools to build with. Hopefully the trick is not to get too dependent upon their infrastructure, and we'll definitely be looking to other cloud platforms to help bring the costs down in future.
AWS wins because it has a fun user interface and good marketing.
> they're certainly not cheap
The cheapest component (compute) of an on-demand EC2 instance is five times more expensive than Linode, Vultr, and OVH. Bandwidth is, I'm not exaggerating at all, 1000 times more expensive. If you use reserved instance discounts and Spot Instances, it's still two times more expensive than hourly-billed Linode and Vultr.
If you're willing to bear with its worse GUI and monthly billing, OVH is a good choice. They've been in business for longer than AWS and operate more servers. Their prices are so low that they're in shortage. If you need instances that aren't in shortage, try Azure.
"AWS Cost Optimization Guru" is a mistake. The best way to optimize your AWS costs is to migrate off of AWS.
> give you a great number of tools to build with
Yes, although you could host your compute at one of the third-parties I mentioned, and still call into AWS services. It adds a little bit of latency for great cost savings. Linode and Vultr gives you DNS, Kubernetes, block storage, load balancers, and private network in addition to compute.
> Yes, we are hiring
Let me know where I could be most useful at Element, or if there's a need for a general fixer role.
AWS wins because it has a fun user interface and good marketing.
> they're certainly not cheap
The cheapest component (compute) of an on-demand EC2 instance is five times more expensive than Linode, Vultr, and OVH. Bandwidth is, I'm not exaggerating at all, 1000 times more expensive. If you use reserved instance discounts and Spot Instances, it's still two times more expensive than hourly-billed Linode and Vultr.
If you're willing to bear with its worse GUI and monthly billing, OVH is a good choice. They've been in business for longer than AWS and operate more servers. Their prices are so low that they're in shortage. If you need instances that aren't in shortage, try Azure.
"AWS Cost Optimization Guru" is a mistake. The best way to optimize your AWS costs is to migrate off of AWS.
> give you a great number of tools to build with
Yes, although you could host your compute at one of the third-parties I mentioned, and still call into AWS services. It adds a little bit of latency for great cost savings. Linode and Vultr gives you DNS, Kubernetes, block storage, load balancers, and private network in addition to compute.
> Yes, we are hiring
Let me know where I could be most useful at Element, or if there's a need for a general fixer role.
Keep in mind that this doesn't mean you can only chat with 5 people. You can chat with anyone who uses Matrix. You can only have 5 people with addresses at your server. Basically identical to email hosting with a 5 account limit.
Yep, as you say, you get to chat with anyone in the Matrix ecosystem (or even further afield if you use bridges).
> You can only have 5 people with addresses at your server
Actually, it's better than this. You can technically have as many people / accounts as you like registered on your server, but you're limited to 5 active users by default. Users are considered "active" if they've been logged in to and using your server for more than two days in a given 30 day period.
> You can only have 5 people with addresses at your server
Actually, it's better than this. You can technically have as many people / accounts as you like registered on your server, but you're limited to 5 active users by default. Users are considered "active" if they've been logged in to and using your server for more than two days in a given 30 day period.
I wonder if tye price is truly steep, or if I am just spoiled by free IM services offered by data harvesting companies?
$5 per month is a big entry cost. And I am not sure how well this price will work in the long run when people begin using the server a lot. Perhaps pricing based on message throughput or used storage capacity would make for an easier and fairer entry.
$5 per month is a big entry cost. And I am not sure how well this price will work in the long run when people begin using the server a lot. Perhaps pricing based on message throughput or used storage capacity would make for an easier and fairer entry.
Is that the only base domain? ems.host (I assume element matrix service?) is so uninspired and sounds like a back end domain rather than what you want your identity tied to. Could they not have gone with something a bit more catchy and on brand?
Well i haven't really gotten used to the name "Element" yet, it's as bland as it gets.
And vague. At least "Telegram", "Signal", and "Whatsapp" suggest that they have something to do with communication, whereas neither "Element" nor its logo/icon suggest what it is. Unless they know what it is already, most people would probably scroll past it, assuming it's like a boring CRM thing or crappy drop-shipping store or whatever.
But I guess it's too late for them to reverse that decision. Maybe the logo will change, but the name is probably here to stay.
But I guess it's too late for them to reverse that decision. Maybe the logo will change, but the name is probably here to stay.
I got excited for a cheaper offering when I saw the headline. If I was wanting to pay $10/month that was already an option. Sadly this is just marketing and not anything more appealing.
Question for anyone in-the-know of Matrix:
I'm toying with using Matrix or IPFS (my two primary interests atm) as a .. P2P layer. Which is to say, i have an app that shuttles thousands of byte chunks between instances of this app, and i need something in that network layer to do the shuttling. I of course could just use a centralized SSH server, but Matrix and IPFS both have be interested as alternatives.
With that said, doing this in Matrix would involve sending quite a bit of volume through Matrix. double digit GiBs of data every month in 10KiB chunks.
Would using hosting Matrix be bad for this purpose? I could of course self host, but A: i'd like to support Matrix, and B: if this is kosher i'd rather give Matrix my money, than give a VPS my money.
Does Element Home limit message sizes or message counts? Does it throttle? Caps would be bad for me (potentially), but throttling would be fine. I just don't want to abuse Matrix, and i'd like to support them with money i'm spending in this use case.
I'm toying with using Matrix or IPFS (my two primary interests atm) as a .. P2P layer. Which is to say, i have an app that shuttles thousands of byte chunks between instances of this app, and i need something in that network layer to do the shuttling. I of course could just use a centralized SSH server, but Matrix and IPFS both have be interested as alternatives.
With that said, doing this in Matrix would involve sending quite a bit of volume through Matrix. double digit GiBs of data every month in 10KiB chunks.
Would using hosting Matrix be bad for this purpose? I could of course self host, but A: i'd like to support Matrix, and B: if this is kosher i'd rather give Matrix my money, than give a VPS my money.
Does Element Home limit message sizes or message counts? Does it throttle? Caps would be bad for me (potentially), but throttling would be fine. I just don't want to abuse Matrix, and i'd like to support them with money i'm spending in this use case.
You might find this recent (discussion and submission) interesting if you missed it:
Show HN: Hummingbard – decentralized communities built on Matrix
https://news.ycombinator.com/item?id=26277602
Show HN: Hummingbard – decentralized communities built on Matrix
https://news.ycombinator.com/item?id=26277602
Depending on the data, it sounds like it might be more a job for IPFS. Matrix is best for passing around histories of JSON blobs no larger than 65KB. Whereas it sounds like you might be manipulating files rather than data objects?
Element Home doesn't have traffic limits currently, but all Matrix has rate limits (a few messages/s) to prevent flooding.
Element Home doesn't have traffic limits currently, but all Matrix has rate limits (a few messages/s) to prevent flooding.
The bytes i refer to are immutable blobs, the content in an immutable content store. IPFS would hypothetically work fine, my only concern is having too much needless history. Eg, once all clients are up to date the history could be pruned.
There would be basically no need to store weeks/months old data, as i'd be just using Matrix for P2P not storage.
(just replying for posterity)
There would be basically no need to store weeks/months old data, as i'd be just using Matrix for P2P not storage.
(just replying for posterity)
The terms of service are interesting:
> This agreement does not apply to Matrix servers run by anyone else - Matrix is an open network like the Web and this agreement only applies to the server provisioned by the Customer and provided by Element.
What do other Matrix servers matter to my hypothetical Element Home server or my selfhosted matrix-synapse server?
>The Customer must ensure that all Authorised Users are at least 16 (sixteen) years old to use both our Hosting and Communication Services or such greater age required in their country to register for or use our Hosting and Communication Services.
So no using it with your younger family or school for example?
I appreciate a service being offered but would prefer a solution that enables an out of the box package for self hosted consumer NAS systems. Maybe something to provide dyndns, a domain and a quick setup.
> This agreement does not apply to Matrix servers run by anyone else - Matrix is an open network like the Web and this agreement only applies to the server provisioned by the Customer and provided by Element.
What do other Matrix servers matter to my hypothetical Element Home server or my selfhosted matrix-synapse server?
>The Customer must ensure that all Authorised Users are at least 16 (sixteen) years old to use both our Hosting and Communication Services or such greater age required in their country to register for or use our Hosting and Communication Services.
So no using it with your younger family or school for example?
I appreciate a service being offered but would prefer a solution that enables an out of the box package for self hosted consumer NAS systems. Maybe something to provide dyndns, a domain and a quick setup.
> What do other Matrix servers matter to my hypothetical Element Home server or my selfhosted matrix-synapse server?
Matrix is federated, like email. Once you send a message to someone on another server, what happens to it is out of your / your server's control.
(E.g., Google's Terms of Service apply to Gmail, but you can use Gmail to send mail to someone at Yahoo... at which point it's beyond Google's reach.)
Matrix is federated, like email. Once you send a message to someone on another server, what happens to it is out of your / your server's control.
(E.g., Google's Terms of Service apply to Gmail, but you can use Gmail to send mail to someone at Yahoo... at which point it's beyond Google's reach.)
I would gladly pay $10/month to support Element and Matrix.
If you (or anyone else reading this) are okay with Patreon, they do have one at https://www.patreon.com/matrixdotorg. If you don't like Patreon for some reason, they are also on Liberapay, PayPal, and accept BTC and ETH.
They have some minor benefits and flair, although the page hasn't been updated in awhile, so I don't know how many are still valid.
They have some minor benefits and flair, although the page hasn't been updated in awhile, so I don't know how many are still valid.
I was on their Patreon for a while, but had to hop off because of financial fun.
Sadly none of the rewards are updated and the flair is no longer given out; at this point it makes sense to just see it as a donation.
Sadly none of the rewards are updated and the flair is no longer given out; at this point it makes sense to just see it as a donation.
Actually, the flair still seems to be given out.
Guess I was just skipped, then. C'est la vie - still a great project, and one worth sponsoring if you can (IMO).
So why don't you?
As you probably saw in the blog post, the ability to do this is currently only offered via the desktop app, which I do not use. I only use the web interface, the Android app, and a non-Element matrix client. Element said in the blog post that it will add this option to the Android app, and once it does, I will use it and subscribe. Hopefully that answers your question.
The Element desktop app SEGFAULTs on startup when I run it on Debian (partly "unstable", like everybody). Curiously, a prior version used to work, and then recently started crashing with no apparent changes, and still crashes apparently the same way after upgrading to the latest release. It is possible that one of its 100+ library dependencies updated, and Element depends on behavior not retained.
I have not dug into where it crashes, yet. Element rooms have got so slow, lately, I hardly use it anymore. Nobody will say who is responsible. The room owner? My homeserver? Others' homeservers? Matrix.org? All I ever see is the spinner, with no hint as to what or who it is waiting on, or any way evident to ever find out.
On the Android app, meanwhile, rooms have taken to keeping a series of one or more very old messages always displayed at the bottom where current messages are supposed to be, taking up as much as half the screen, thus far.
It also makes a noise every 30 seconds that I cannot turn off, spamming my notifications log to tell me it has polled its server again. I have found that force-killing the app makes this go away. I don't know if this makes it unable to alert me to timely messages from others on my homeserver. The constant noises make it hard to care.
Fluffychat has the same noise problems, so the notification spam is probably in the client library. The sticky ancient message problem is only in Android Element.
I have not dug into where it crashes, yet. Element rooms have got so slow, lately, I hardly use it anymore. Nobody will say who is responsible. The room owner? My homeserver? Others' homeservers? Matrix.org? All I ever see is the spinner, with no hint as to what or who it is waiting on, or any way evident to ever find out.
On the Android app, meanwhile, rooms have taken to keeping a series of one or more very old messages always displayed at the bottom where current messages are supposed to be, taking up as much as half the screen, thus far.
It also makes a noise every 30 seconds that I cannot turn off, spamming my notifications log to tell me it has polled its server again. I have found that force-killing the app makes this go away. I don't know if this makes it unable to alert me to timely messages from others on my homeserver. The constant noises make it hard to care.
Fluffychat has the same noise problems, so the notification spam is probably in the client library. The sticky ancient message problem is only in Android Element.
Strace says Desktop Element crashes after a series of calls to recvmsg; one returns 32 bytes, then four fail with EAGAIN. Gdb says SIGSEGV at 0x000055555a03b652, which points into /usr/bin/element-desktop, v1.7.21 from packages.riot.im/debian/. So, probably not a dependency.
Looking on Element Web/Desktop's issue tracker: https://github.com/vector-im/element-web/issues?q=is%3Aissue... there are no open issues concerning segfaults currently. If you file a bug report with the details requested in the template then we'll be able to investigate and fix it, just as we did for https://github.com/vector-im/element-web/issues/13553 (for instance). Otherwise, expecting us to be aware of this and to fix it without a bug report is not going to happen.
In terms of "slow rooms" - we'd need more details to advise. A bug report on github.com/matrix-org/synapse/issues would give us something to go on.
In terms of stuck messages on Element Android - this sounds like a bug which was fixed months ago. Please upgrade.
In terms of getting a notification every time the app syncs - I have no idea what would cause that, nor have I heard of it. Please file a bug at https://github.com/vector-im/element-android/issues.
In terms of "slow rooms" - we'd need more details to advise. A bug report on github.com/matrix-org/synapse/issues would give us something to go on.
In terms of stuck messages on Element Android - this sounds like a bug which was fixed months ago. Please upgrade.
In terms of getting a notification every time the app syncs - I have no idea what would cause that, nor have I heard of it. Please file a bug at https://github.com/vector-im/element-android/issues.
Thank you, that saves me time searching for dups. You'll have to forgive me, in 30 years I have only ever seen one bug fixed in response to a report I filed online.
But hope springs eternal: <https://github.com/vector-im/element-web/issues/16599>.
The stuck messages are still there, in a newly upgraded Android Element 1.1.0, same as in the last two upgrades to 1.0.14 marked (2021-01-30) and 1.0.17 (2021-02-14). Other people report the same: <https://github.com/vector-im/element-android/issues/2494>
Android Element 1.1.0 seems to spam the notifications log with "Listening for events", "parcel size: 992", a bit less often than previous versions. I see it now at 22:16, 22:17, 22:18, 22:20, 22:35, 22:43, 22:49, 22:51, 22:53, 22:56, 23:00, 23:21. Better than 2x/minute.
I can imagine that the slowness (endless spinner when scrolling back in a room transcript) might be a consequence of delays in my homeserver -- privacytools.io -- but the app offers no hint as to where the stall is. Does my homeserver have anything to do with slowness of rooms ? I also don't see any way to check the version of Synapse running on the homeserver. Should I be able to find that?
An example of a very slow scrollback room is #_oftc_#mobian:matrix.org.
But hope springs eternal: <https://github.com/vector-im/element-web/issues/16599>.
The stuck messages are still there, in a newly upgraded Android Element 1.1.0, same as in the last two upgrades to 1.0.14 marked (2021-01-30) and 1.0.17 (2021-02-14). Other people report the same: <https://github.com/vector-im/element-android/issues/2494>
Android Element 1.1.0 seems to spam the notifications log with "Listening for events", "parcel size: 992", a bit less often than previous versions. I see it now at 22:16, 22:17, 22:18, 22:20, 22:35, 22:43, 22:49, 22:51, 22:53, 22:56, 23:00, 23:21. Better than 2x/minute.
I can imagine that the slowness (endless spinner when scrolling back in a room transcript) might be a consequence of delays in my homeserver -- privacytools.io -- but the app offers no hint as to where the stall is. Does my homeserver have anything to do with slowness of rooms ? I also don't see any way to check the version of Synapse running on the homeserver. Should I be able to find that?
An example of a very slow scrollback room is #_oftc_#mobian:matrix.org.
Accounts on their Element Home plan can work on Android and iOS apps too. It's just that copying over data from a different homeserver to this new homeserver is possible only on the desktop app at the moment.
The ability to copy traffic history from one homeserver to another is a huge deal. I have not succeeded in discovering any details of this rollout. What server versions support it? Does it suffice to copy using one client, once, and then all clients see the result? Or, only after pointing those other clients at the new server? Do the other clients only see old traffic, after, until they are switched over, too?
How can I have more thsn one homeserver watched? Do I need to run N independent client apps (e.g. Element and Fluffychat), with each pointed at one homeserver?
It is very hard to find out any details of what is handled where in Matrix. Nobody in rooms devoted to services acknowledges questions, never mind answering any.
How can I have more thsn one homeserver watched? Do I need to run N independent client apps (e.g. Element and Fluffychat), with each pointed at one homeserver?
It is very hard to find out any details of what is handled where in Matrix. Nobody in rooms devoted to services acknowledges questions, never mind answering any.
As you rightly say, you can use any client for Element Home and the only restriction is that the in-app setup and migration wizard is only available in the Element web clients at the moment (this is now corrected in the blog article).
That said, the Matrix->Matrix migration tools (https://ems.element.io/tools/matrix-migration) can be used outside of the setup flow, to help migrate your existing chats to new accounts. So people can always use those separately from host setup, if needed.
That said, the Matrix->Matrix migration tools (https://ems.element.io/tools/matrix-migration) can be used outside of the setup flow, to help migrate your existing chats to new accounts. So people can always use those separately from host setup, if needed.
Ahh... thanks for pointing that out. That was a mistake in the blog article (fixed now).
In fact the migrator only works on the web apps at the moment (not desktop or mobile).
That said, even if the in-app migrator isn't available to other clients, people are obviously free to set up Element Nickel or Home direct from the website.
In fact the migrator only works on the web apps at the moment (not desktop or mobile).
That said, even if the in-app migrator isn't available to other clients, people are obviously free to set up Element Nickel or Home direct from the website.
I find the chart presented to be very deceptive with regards to "Own your data" and Signal. It implies that the Signal servers store your messages and other data which they do not.
AFAIK they do, just not in a way that anyone but the sender and receiver(s) can read.
Encrypted messages are stored on their servers only until they are delivered, and then deleted.
From their privacy policy:
From their privacy policy:
Messages. Signal cannot decrypt or otherwise access the content of your messages or calls. Signal queues end-to-end encrypted messages on its servers for delivery to devices that are temporarily offline (e.g. a phone whose battery has died). Your message history is stored on your own devices.
Additional technical information is stored on our servers, including randomly generated authentication tokens, keys, push tokens, and other material that is necessary to establish calls and transmit messages. Signal limits this additional technical information to the minimum required to operate the Services.That's good nuance; not what I'd understand as "not storing it on their servers", but really the best you could want, IMHO.
[deleted]
Does this include all the bridges? So the users of the instance can combine other platforms to the same app, such as signal, instagram, twitter, whatsapp, irc, telegram and all that?
I'm pretty sure it doesn't. But my real question is can you run your own bridges with this homeserver?
Is there a whatsapp bridge?
Yes, but it is not being offered as a hosted service atm:
https://github.com/tulir/mautrix-whatsapp
https://element.io/element-matrix-store
You would not want some sort of popular Whatsapp bridge. That would an easy target for Facebook. It would likely be blocked.
Better for everyone to run their own bridges...
Better for everyone to run their own bridges...
Why home vs nickle? Nickle seems to be the same with the addition of your own DNS for the same price.
This genuinely makes no sense on Element's part.
The exact same features are listed for the same price, on the feature comparison page - https://element.io/pricing - except Nickel has one extra.
Why would anyone choose to have one less feature, all-else being apparently equal?
Either the comparison page is wrong/missing something, or...?
The exact same features are listed for the same price, on the feature comparison page - https://element.io/pricing - except Nickel has one extra.
Why would anyone choose to have one less feature, all-else being apparently equal?
Either the comparison page is wrong/missing something, or...?
Hi - I head up Element Matrix Services (EMS), so hopefully I can answer some of these questions for you.
Element home is really aimed at helping to get less technical users up and running with their own home on Matrix as quickly and easily as possible.
Under the hood Element Home servers and our smaller / Nickel products are pretty similar (similar resource allocations etc.). The main differences are in the setup process.
With Element Home we've created a whole new setup process and have tried to reduce the number of configuration steps, selecting default options wherever possible.
The trade-off for this is that while many of these options are changeable after setup, some (like custom DNS) are not. So, if you're a bit more technical and want things like custom DNS, then you're better to start off with a Nickel host.
Element home is really aimed at helping to get less technical users up and running with their own home on Matrix as quickly and easily as possible.
Under the hood Element Home servers and our smaller / Nickel products are pretty similar (similar resource allocations etc.). The main differences are in the setup process.
With Element Home we've created a whole new setup process and have tried to reduce the number of configuration steps, selecting default options wherever possible.
The trade-off for this is that while many of these options are changeable after setup, some (like custom DNS) are not. So, if you're a bit more technical and want things like custom DNS, then you're better to start off with a Nickel host.
Ok! Thanks for the detailed answer, that makes sense.
Maybe could the comparison page do with another point in Home's favour to this effect?
Maybe could the comparison page do with another point in Home's favour to this effect?
Yep, it's a good point (thanks for the feedback). I'll see what we can come up with.
The link to "Nickle" actually goes to the subscription page for "Silver". Their product listing seems to be broken?
If it's just an option that can be turned on or off in a control panel of sorts, the plans might just be different pre-provisioning configurations. For many people, especially the non-tech users, custom DNS isn't really something that they want or even should be using.
If it's just an option that can be turned on or off in a control panel of sorts, the plans might just be different pre-provisioning configurations. For many people, especially the non-tech users, custom DNS isn't really something that they want or even should be using.
Thanks for the report on that. I'll get someone to look into it asap.
What you are referencing sounds interesting. Would you please provide a link with more information? Googling "nickle matrix" does not yeild useful results, and it's even worse for "nickle element"
Nickel is one of their existing plans, and Home is their new plan. Both offer the same features, except that Nickel offers an ability to use custom domains and is aimed at businesses. More on their pricing page [1]
[1] https://element.io/pricing
[1] https://element.io/pricing
It looks like Nickel is $2/user, with a minimum of $10. So for a family a fixed $10 is probably the smarter choice, rather than to have $2 more for every user added. EDIT: it seems Home is limited to 5 users, which means it's actually the same price.
May i ask what would be the benefit of having your own DNS? I don't understand what your average group chat would gain...
May i ask what would be the benefit of having your own DNS? I don't understand what your average group chat would gain...
Owning your domain has the same advantage for element than it would for, for example email. If your company has their own domain for email, but hosts at Gmail, Google can one day decide to kick you off their platform. But, because you have a domain, you can take your business somewhere else.
On the flipside, if your email and personal identity is tied to an @gmail.com address, you are stuck at that vendor.
A second reason is vanity. Full matrix usernames and channels do appear from time to time, and it's nice when it's our own address. (we self-host matrix)
On the flipside, if your email and personal identity is tied to an @gmail.com address, you are stuck at that vendor.
A second reason is vanity. Full matrix usernames and channels do appear from time to time, and it's nice when it's our own address. (we self-host matrix)
As some of the others have said, custom DNS is largely for vanity and discoverability reasons. People know that they can find your website on your domain, why not chat to you on Matrix there too? :)
In addition to that though, there's also the aspect of being able to choose to host your homeserver on your own infrastructure, using your own domain, should you want to.
In Matrix your homeserver (domain) name is "baked in" to every event created by your homeserver, which means that you can't change it after setup. If your homeserver is set up on, say, "foo.ems.host", you can take a snapshot of the data at any point but you couldn't just set it up to run on your domain. If you start hosting with your own custom DNS pointed at EMS then you can take over and host on your own infrastructure at any point.
As mentioned in this thread, Element home is intended to make it as easy as possible for people to get up and running with their own Matrix homeserver. To do this we've really reduced the number of configuration steps in initial setup as much as possible, including hiding custom DNS setup which can be quite complicated.
This won't be a problem for most people, but if you're interested in custom DNS (and want EMS to host it for you), you'd probably want to start with the EMS Nickel package, with custom DNS, rather than Element Home.
It's worth noting that we're currently working on "account portability" which would allow you to decouple homeservers from specific domains. So, once this is available you should be able to change domain names etc. at any point.
I think that you've got it already, but just to clarify the pricing, the costs and constraints for Nickel and Element Home hosts are the same - $10 per month for up to 5 active users. Additional users can be added at an additional cost of $2/per user/month.
(Disclaimer - I head up Element Matrix Services)
In addition to that though, there's also the aspect of being able to choose to host your homeserver on your own infrastructure, using your own domain, should you want to.
In Matrix your homeserver (domain) name is "baked in" to every event created by your homeserver, which means that you can't change it after setup. If your homeserver is set up on, say, "foo.ems.host", you can take a snapshot of the data at any point but you couldn't just set it up to run on your domain. If you start hosting with your own custom DNS pointed at EMS then you can take over and host on your own infrastructure at any point.
As mentioned in this thread, Element home is intended to make it as easy as possible for people to get up and running with their own Matrix homeserver. To do this we've really reduced the number of configuration steps in initial setup as much as possible, including hiding custom DNS setup which can be quite complicated.
This won't be a problem for most people, but if you're interested in custom DNS (and want EMS to host it for you), you'd probably want to start with the EMS Nickel package, with custom DNS, rather than Element Home.
It's worth noting that we're currently working on "account portability" which would allow you to decouple homeservers from specific domains. So, once this is available you should be able to change domain names etc. at any point.
I think that you've got it already, but just to clarify the pricing, the costs and constraints for Nickel and Element Home hosts are the same - $10 per month for up to 5 active users. Additional users can be added at an additional cost of $2/per user/month.
(Disclaimer - I head up Element Matrix Services)
The primary and only advantage that I can think of is, personalized addresses. It's better to have one's address as `@james:potter.family` instead of `@james:potter.ems.host`, where `potter.family` is my custom domain.
Maybe your own domain. In the home expamples all usernames are `@name:subdomain.ems.host`.
[deleted]
Good stuff!
Now we just need to get the cost down. I got email hosting for free with my domain, that's the price point I would like for Matrix, too.
May I ask which registrar it is? The ones I know only offer email forwarding for free, not a full-fledged email account.
Not OP, but I'm getting the same from Gandi [0].
[0] https://gandi.net/
[0] https://gandi.net/
It's Strato.de
Depending on the specific package, I get 1-unlimited email accounts on my new domain
Depending on the specific package, I get 1-unlimited email accounts on my new domain
I believe they are asking twice as much as they should be. Hear me out.
At $1/month/user, they would make $12/user/year. I would say most people have extended ~10-20 family members they communicate with, at $20 -$40/month on the lowest priced plan, that would be a fair expenditure that would fall on one family member, because trying to get everyone to chip in if usually unrealistic. Now outside of the USA it begins to get really expensive.
If they could offer it at $1/month, they would have significantly greater uptake. As for the bandwidth and hosting costs, are they not paying for that anyway through the default Matrix server?
I get they want to make money from businesses, but they are pricing out a lot of families who have Facebook-fatige.
At $1/month/user, they would make $12/user/year. I would say most people have extended ~10-20 family members they communicate with, at $20 -$40/month on the lowest priced plan, that would be a fair expenditure that would fall on one family member, because trying to get everyone to chip in if usually unrealistic. Now outside of the USA it begins to get really expensive.
If they could offer it at $1/month, they would have significantly greater uptake. As for the bandwidth and hosting costs, are they not paying for that anyway through the default Matrix server?
I get they want to make money from businesses, but they are pricing out a lot of families who have Facebook-fatige.
I agree.
They're competing against free services. For many if not most family-and-friend groups there will only be one person knowledgeable about matrix and actively interested in using it (there might be more interested in using "something that's not Facebook", but matrix isn't the only option there). This needs to be priced low enough that one person can buy it without thinking and get their family and some friends on the thing. Maybe start at $40/year or $25/six months, up to 15 accounts.
Pay six months or a year to start so there's no subscription, then give an option to pay for another block or switch to monthly.
Also needs to include bring-your-own-domain (ie, let the customer point DNS at the service), because if you're interested in matrix and want to have your own homeserver then you know you also want to properly own the domain to avoid being locked into a particular hosting provider.
(All just my opinion, I have no relevant experience, etc etc)
Pay six months or a year to start so there's no subscription, then give an option to pay for another block or switch to monthly.
Also needs to include bring-your-own-domain (ie, let the customer point DNS at the service), because if you're interested in matrix and want to have your own homeserver then you know you also want to properly own the domain to avoid being locked into a particular hosting provider.
(All just my opinion, I have no relevant experience, etc etc)
The only thing stopping me from moving away from the matrix.org homeserver is the fact that I already have an account and chats there.
Sure, I could rejoin all my rooms from a new account on a different homeserver. But that’s not exactly an elegant solution.
I’m looking forward to when account migration is a solved problem. That’s one of the more impressive and daunting parts of the Matrix spec that I’ve seen.
Sure, I could rejoin all my rooms from a new account on a different homeserver. But that’s not exactly an elegant solution.
I’m looking forward to when account migration is a solved problem. That’s one of the more impressive and daunting parts of the Matrix spec that I’ve seen.
Back when WhatsApp's business model relied on subscriptions rather than ads, it sold for $1/year. What justifies this being 120x more expensive? Is it just economies of scale?
WhatsApp was selling you access to your account. Element is selling you access to an instance which you can share with as many users as you want.
The pricing page says you can only share it with 5 users for the $10/month package. Am I missing something?
You are right, apologies. :) x24 more than WhatsApp for the benefit of being sure your data doesn't fall into third party hands, that's for you to decide if it's enough.
"your data" falls into at least elements and aws hands with this. Yeah the content is encrypted but there's lots of metadata to grab by malicous actors. The reality is 10$ for 25 Users would have been more reasonable. Enough to setup a server for your family and close friends.
> memorable Matrix IDs such as @yourfirstname:yoursurname.ems.host
Nobody outside of tech will agree with that. Multiple kinds of punctuation, "ems", ".host", and so on.
Nobody outside of tech will agree with that. Multiple kinds of punctuation, "ems", ".host", and so on.
not sure i understood from the article, is this supposed ot host a server locally on your device rather than use someone elses server?
(that would make it function almost like a peer to peer system.)
or is it just a way for them to market their own hosting for matrix servers?
or is it just a way for them to market their own hosting for matrix servers?
This is probably a stab at BeeperHQ, judging by the price.
I chat with Arathorn pretty regularly and I'm quite sure that we're not competitors, at least not yet . Beeper is focused in hosting and maintaining bridges between Matrix and other networks. EMS is vanilla Matrix hosting.
Work on Element Home predates Beeper's launch by a few months, and is in no way a response to it. EMS does have some paid bridges too, but the emphasis is on the Matrix rather than the bridging, unlike Beeper.
Hasn't this offer already been existing for a while?
Maybe. If so, I wasn’t aware. I always thought the cheapest plan was pricier than €10.
> You can just enjoy the fact you know you chose someone you trust (us!) with your data.
Isn't the point of decentralization that I don't have to choose some centralized party to trust?
Isn't the point of decentralization that I don't have to choose some centralized party to trust?
You can pick another Matrix host if you want, if there are any. Element being the first to host the services they develop commercially makes sense. If another Matrix host stand up, you're free to go with their competitor instead and still chat with the same people.
The biggest downside of this kind of hosted service is that they use subdomains of their own service. That means that you can't take your exact username to another service if you do end up switching. For most people, this makes switching from Element Home to something else as much of a problem as switching from Whatsapp to Signal.
The same is true for other federated services like email, of course, but the service would be a lot more portable if, for example, you could buy a domain, have the folks at Element set up the necessary DNS config (they can require one particular domain provider for their API services for all I care), and then later be able to switch to another host with the same contacts, usernames and services. Because of data portability laws, Element is forced to make this possible in the EU anyway, so it might as well be a feature of the Matrix ecosystem to be able to transfer your domains and accounts without hassle.
The biggest downside of this kind of hosted service is that they use subdomains of their own service. That means that you can't take your exact username to another service if you do end up switching. For most people, this makes switching from Element Home to something else as much of a problem as switching from Whatsapp to Signal.
The same is true for other federated services like email, of course, but the service would be a lot more portable if, for example, you could buy a domain, have the folks at Element set up the necessary DNS config (they can require one particular domain provider for their API services for all I care), and then later be able to switch to another host with the same contacts, usernames and services. Because of data portability laws, Element is forced to make this possible in the EU anyway, so it might as well be a feature of the Matrix ecosystem to be able to transfer your domains and accounts without hassle.
Generally it's enough to have multiple providers with equivalent offerings and near-zero costs of switching and starting your own provider
Could anyone TL;DR this? I honestly struggle with understanding what exactly is the offer.
You get your own instance of the matrix server to use which is faster than the shared free instance. Saves you from having to host it yourself.
Imagine if you paid for email accounts - this is like paying 10usd/month for up to 5 email accounts (with eg fastmail).
Only its not email, but text/voice/video/group chat.
Only its not email, but text/voice/video/group chat.
This would be insane for anyone outside of HN. $10 a month for a 5 person chat? They know everyone can get this free elsewhere for decades now? A 5 person Signal group would even have higher security.
> A 5 person Signal group would even have higher security.
Why is it higher security?
Why is it higher security?
Fewer ways for it to be misconfigured?
In Matrix you've got to remember to turn on the encryption, and verify each of your clients. At least that's my understanding, maybe that is out of date.
In Matrix you've got to remember to turn on the encryption, and verify each of your clients. At least that's my understanding, maybe that is out of date.
Encryption is on by default.
In both cases you should verify.
It's also worth noting that verification is much easier these days given that cross-signing has been implemented.
Before you had to verify each pair of (sender, recipient) devices. This meant N*M verifications.
Now you only need to verify a new device when you are setting it up and each new recipient when you start talking to them for the first time. So it's N+M verifications.
Before you had to verify each pair of (sender, recipient) devices. This meant N*M verifications.
Now you only need to verify a new device when you are setting it up and each new recipient when you start talking to them for the first time. So it's N+M verifications.
Neat! Thank you for the correction.
The beauty of matrix is the interoperability: you can actually talk to other users on other servers, like email.
You can join large public groups, too.
I have one large concern with this. It's not a FLOSS service, it's SSaaS. Let me explain.
While Matrix is open-source, Element Matrix hosting gives you no option to modify the source code, not letting you install add-ons or modifications. There's no way to say, "Hey, check out this cool chat patch, just install it on your homeserver!" With proprietary service, if you want a feature, all you can do is say, "Ugh, I wish they would add it." With a freedom-respecting service, you could just hire someone to add it.
Therefore, EMS is not a freedom-respecting service. It's as freedom-respecting as proprietary ElasticSearch.
The headline explains that it violates the most fundamental principle of free software:
- The freedom to run the program as you wish, for any purpose (freedom 0).
It does not even attempt to give you this freedom:
- The freedom to... change the program so it does your computing as you wish.
OSS that's not FLOSS doesn't have any of the ethical benefits: A locked-down Android phone is "open-source" but not free software, as you can't modify it.
There should be a way to be able to upload patches onto your server. If corruption ensues, Element Matrix Services should not be held responsible. Let users be responsible for their software! Stop treating them like babies.
It also generally makes it much harder for open-source contributors to experiment, as you must go through a centralized repo to gain adoption.
While Matrix is open-source, Element Matrix hosting gives you no option to modify the source code, not letting you install add-ons or modifications. There's no way to say, "Hey, check out this cool chat patch, just install it on your homeserver!" With proprietary service, if you want a feature, all you can do is say, "Ugh, I wish they would add it." With a freedom-respecting service, you could just hire someone to add it.
Therefore, EMS is not a freedom-respecting service. It's as freedom-respecting as proprietary ElasticSearch.
The headline explains that it violates the most fundamental principle of free software:
- The freedom to run the program as you wish, for any purpose (freedom 0).
It does not even attempt to give you this freedom:
- The freedom to... change the program so it does your computing as you wish.
OSS that's not FLOSS doesn't have any of the ethical benefits: A locked-down Android phone is "open-source" but not free software, as you can't modify it.
There should be a way to be able to upload patches onto your server. If corruption ensues, Element Matrix Services should not be held responsible. Let users be responsible for their software! Stop treating them like babies.
It also generally makes it much harder for open-source contributors to experiment, as you must go through a centralized repo to gain adoption.
It's a SaaS offering hosting for FOSS. If you want to be able to patch and change and manage the running homeserver, than you're just manually managing the homeserver, which would be self-hosting! Which is a great thing to do, but then there's no point in buying this service, just rent a VPS. The entire point of this service is that they do the management for you - if you would rather do the management yourself, you totally can. People running their own homeserver are very much first-class citizens on the Matrix network, and managing it yourself is cheaper. The extra expense here is entirely to get them to manage it for you, which seems to be the opposite of what you want.
> The entire point of this service is that they do the management for you - if you would rather do the management yourself, you totally can.
I want them to manage it and also let me upload patches.
I want the setup, DNS, storage, hosting, all the sysadmin stuff... and still be able to patch the software. I want them to be able to `git pull` an update over my patches, and have it carry forward after updates.
I want the agency of FOSS but still pay for the management, simply put.
> It's a SaaS offering hosting for FOSS.
I can't modify the software, so it's not free software. If they provided some sort of "patch app store" or patch download, it would be free software.
I want them to manage it and also let me upload patches.
I want the setup, DNS, storage, hosting, all the sysadmin stuff... and still be able to patch the software. I want them to be able to `git pull` an update over my patches, and have it carry forward after updates.
I want the agency of FOSS but still pay for the management, simply put.
> It's a SaaS offering hosting for FOSS.
I can't modify the software, so it's not free software. If they provided some sort of "patch app store" or patch download, it would be free software.
Interesting - do you know of any service that does this?
I'm curious as to how exactly you want it to work. Rereading your comment, I agree DNS and backups make sense, but upgrading the application itself still seems somewhat fraught. If your patch doesn't apply on an update, what should happen? Don't upgrade and send you an email? Do they upgrade the rest of the system it runs on? Do you want to be able to run other programs on the server as well, and if so, how would distro updates work?
I think we disagree pretty fundamentally, but you've got me curious now about how your idea would work, and I'd like to hear more.
I think we disagree pretty fundamentally, but you've got me curious now about how your idea would work, and I'd like to hear more.
> If your patch doesn't apply on an update, what should happen? Don't upgrade and send you an email?
Get a new version of the patch for that new version from the patch author, which is included in patch metadata.
Get a new version of the patch for that new version from the patch author, which is included in patch metadata.
As amusing as it'd be to let people patch their synapses with buggy/vulnerable code and wreak havoc in our datacenter, we're not going to. If you want to run a custom server, run it yourself.
> As amusing as it'd be to let people patch their synapses with buggy/vulnerable code and wreak havoc in our datacenter, we're not going to.
Each Matrix instance is isolated and "dedicated", so one can only wreak havoc on their own instance. Just provide backups and revert when people mess up.
Each Matrix instance is isolated and "dedicated", so one can only wreak havoc on their own instance. Just provide backups and revert when people mess up.
The pricing is certainly odd, though. 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). Double that for a limit of 5 users (with another $2/user surcharge) is high for what I'd expect is a logical separation of tenants under the hood.
I know some of the Matrix folks pop in to HN threads from time to time, and I'll readily admit my woeful inexperience in all things business. That said, could someone enlighten me as to how the pricing strategy was determined? It seems like the better route would have been to create an obscenely cheap plan on the low end for groups/families and push for enterprise adoption (perhaps even with increased prices, $75/mo for 25 users seems on the low end at first glance).
Edit: Just re-read the first paragraph and caught this: "You can just enjoy the fact you know you chose someone you trust (us!) with your data." The whole reason I'm using element is because I don't trust anyone else with my data & social connections, and so I'd like to own as much of that scope as possible. I'm sure it's just a poorly worded marketing zinger, but it's unfortunate nonetheless.