Element Matrix Services Announces Element Home
element.io
element.io
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.
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))
[edit: seems like I failed to parse Slack's pricing page. Slack is expensive as hell. Carry on]
> €6.25 per active user per month billed annually. > Or, €7.50 per active user per month, billed monthly.
If I may, I'd like to push a little deeper on this. Why the single-digit user limit at that price? Doubling or quadrupling the users, or halving the price, would make it a no-brainer of an option to point people to if they don't want to go through the trouble of setting up their own server. As it stands, the pricing feels restrictive to the point where I would feel punished for growing my server (I'd instead tell someone to get their own matrix.org address, at which point it sounds like we could just use Discord/Signal/Slack?). The extra financial burden (these are my family and friends, so I would never ask them to chip in) would actually incentivize me to keep my server as small as possible, which is the antithesis of what the goal of a hosted service should be.
As I write this, I'm realizing that there's no real utility here for anyone technical enough to warm to Matrix/Element's strengths. We can talk about the everyman who's not on HN all we want, but my hunch is that those people would rather just use Signal or Discord based on their use-case - no confusing concepts like "homeservers" and "federation". With a user limit and the current pricing model, every use-case (from a short tryout to a long-term personal homserver) is better served either by the free matrix.org model or by a self-hosted solution.
I only use Element / Matrix as an IRC replacement for now so I couldn't tell.
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
Setting up STUN and TURN is a real pain, though, if you run into any issues.
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
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.
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.
[1] - https://www.mumble.info/
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.
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.
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!
>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...
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.
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.
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.
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...
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 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
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.
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.
* 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.
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.
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.
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.
Maybe "dedicated" and "infrastructure" are being abstracted into meaninglessness as cloud computing matures.
If I wanted lower latency, I would add WebRTC-based P2P chat for those who support it, to connect directly between servers.
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."
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?
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.
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.
For this playbook, use these variables:
matrix_synapse_use_presence: false
matrix_client_element_enable_presence_by_hs_url: {"https://matrix.yourserver.com": false}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.
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)
(I head up Element Matrix Services)
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
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 ;)
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.
> 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.
$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.
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'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.
Element Home doesn't have traffic limits currently, but all Matrix has rate limits (a few messages/s) to prevent flooding.
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)
Show HN: Hummingbard – decentralized communities built on Matrix
> 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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.Better for everyone to run their own bridges...
May i ask what would be the benefit of having your own DNS? I don't understand what your average group chat would gain...
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)
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 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...?
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.
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.
Maybe could the comparison page do with another point in Home's favour to this effect?
Depending on the specific package, I get 1-unlimited email accounts on my new domain
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.
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)
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.
Nobody outside of tech will agree with that. Multiple kinds of punctuation, "ems", ".host", and so on.
or is it just a way for them to market their own hosting for matrix servers?
Isn't the point of decentralization that I don't have to choose some centralized party to trust?
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.
Only its not email, but text/voice/video/group chat.
Why is it higher security?
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.
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.
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.
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 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.
Get a new version of the patch for that new version from the patch author, which is included in patch metadata.
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.