Element Web and matrix.to unavailable for legal reasons
6 points · Open discussionelement-hq
element-web
TypeScript2017–2026
element-hq / element-web
element-web
A glossy Matrix collaboration client for the web.
68Distinct people
125Mentions
0Explicit recommenders
13.7KGitHub stars
What to know before exploring
What it is
A glossy Matrix collaboration client for the web.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- matrix-org/synapse · linked in 7 of the same discussions
- matrix-org/matrix-spec-proposals · linked in 6 of the same discussions
- matrix-org/matrix-react-sdk · linked in 4 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year125 dated mentions
Observed mentions: 2017-02-14 06:05:55 UTC to 2026-04-15 22:22:09 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 28 | 1 | 27 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 30 | 1 | 29 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 19 | 0 | 19 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Element
Element (formerly known as Vector and Riot) is a Matrix web & desktop client built using the Matrix
JS SDK.
Supported Environments
Element has several tiers of support for different environments:
Supported
Definition:
Issues actively triaged, regressions block the release
Last 2 major versions of Chrome, Firefox, and Edge on desktop OSes
Last 2 versions of Safari
Latest release of official Element Desktop app on desktop OSes
Desktop OSes means macOS, Windows, and Linux versions for desktop devices
that are actively supported by the OS vendor and receive security updates
Best effort
Definition:
Issues accepted, regressions do not block the release
The wider Element Products (including Element Call and the Enterprise Server Suite) do still not officially support these browsers.
The element web project and its contributors should keep the client functioning and gracefully degrade where other sibling features (E.g. Element Call) may not function.
Last major release of Firefox ESR and Chrome/Edge Extended Stable
Community Supported
Definition:
Issues accepted, regressions do not block the release
Community contributions are welcome to support these issues
Mobile web for current stable version of Chrome, Firefox, and Safari on Android, iOS, and iPadOS
Not supported
Definition: Issues only affecting unsupported environments are closed
Everything else
The period of support for these tiers should last until the releases specified above, plus 1 app release cycle(2 weeks). In the case of Firefox ESR this is extended further to allow it land in Debian Stable.
For accessing Element on an Android or iOS device, we currently recommend the
native apps element-x-android
and element-x-ios.
Getting Started
The easiest way to test Element is to just use the hosted copy at https://app.element.io.
The develop branch is continuously deployed to https://develop.element.io
for those who like living dangerously.
To host your own instance of Element see Installing Element Web.
To install Element as a desktop application, see Running as a desktop app below.
Monorepo
This repository is a monorepo hosting Element Web and other related projects in various subdirectories.
You can read more about the structure here.
Element Web
To learn more about Element Web click here
Running as a Desktop app
Element can also be run as a desktop app, wrapped in Electron. You can download a
pre-built version from https://element.io/get-started or, if you prefer,
build it yourself.
To build it yourself, follow the instructions at https://github.com/element-hq/element-web/tree/develop/apps/desktop.
Many thanks to @aviraldg for the initial work on the Electron integration.
The configuration docs show how to override the desktop app's default settings if desired.
Development
Please read through the following:
Developer guide
Code style
Contribution guide
Translations
To add a new translation, head to the translating doc.
For a developer guide, see the translating dev doc.
Triaging issues
Issues are triaged by community members and the Web App Team, following the triage process.
We use issue labels to sort all incoming issues.
Copyright & License
Copyright (c) 2014-2017 OpenMarket Ltd
Copyright (c) 2017 Vector Creations Ltd
Copyright (c) 2017-2025 New Vector Ltd
This software is multi licensed by New Vector Ltd (Element). It can be used either:
(1) for free under the terms of the GNU Affero General Public License (as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version); OR
(2) for free under the terms of the GNU General Public License (as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version); OR
(3) under the terms of a paid-for Element Commercial License agreement between you and Element (the terms of which may vary depending on what you and Element have agreed to).
Unless required by applicable law or agreed to in writing, software distributed under the Licenses is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the Licenses for the specific language governing permissions and limitations under the Licenses.
Please contact licensing@element.io to purchase
an Element commercial license for this software.
Read the full README on GitHubWhat Hacker News says
125 sourcesThe Matrix server is open source. https://github.com/matrix-org/synapse
The Element client is also open source. https://github.com/element-hq/element-web
It does not actually need to be configured in a federated state and frankly scales better when it's not. The login can be tied to anything or use it's own. From a modern SAML SSO to an old school forum.
You can run one for a few friends and it scales just as well as a private discord for a few friends. Just need persistent storage for media uploads if people are sharing video a lot.
In Welcoming Discord users amidst the challenge of Age VerificationPros of Matrix: it actually has a consistent history (in theory); no vendor lock-in.
Cons of Matrix: encryption breaks constantly. Right now I’m stuck in a fun loop of endlessly changing recovery keys: https://github.com/element-hq/element-web/issues/31392
In Gpg.failthanks for sticking with it and the vote of confidence. totally agreed that Element Web has issues (i'm currently having to run a custom fork to stop it OOMing thanks to https://github.com/element-hq/element-web/issues/27983#issue...); hopefully switching to matrix-rust-sdk will be a huge improvement; https://github.com/element-hq/aurora is already looking promising.
In Why We Abandoned Matrix (2024)/me sighs; Merry Christmas everyone.
For what it's worth, we've been working on improving Matrix's metadata footprint this year: MSC4362 (https://github.com/matrix-org/matrix-spec-proposals/blob/kay...) got implemented on matrix-js-sdk for encrypting room state (currently behind a labs flag on Element Web: https://github.com/element-hq/element-web/blob/develop/docs/...). Meanwhile more radical proposals like MSC4256 (https://github.com/dklimpel/matrix-spec-proposals/blob/mls-R...) go and remove senders entirely and encrypt room state via MLS.
The reason Matrix hasn't prioritised metadata protection earlier is:
* If you're particularly concerned about metadata footprint, you can run your own servers in whatever network environment you feel like - you are NOT surrendering metadata to some central or 3rd party server as you would in a centr
Read the rest
alised platform.
* We've had to focus on getting decentralised encryption stable, which turns out to be hard enough without also throwing in metadata protection - it's only this year that we've turned that corner.
* Unless you're using a mixnet, network traffic gives away a significant amount of metadata anyway.
Anyway, yes: Matrix can do better on obfuscating metadata on servers, and we'll continue improving it in 2026.
Meanwhile, if anyone's feeling nostalgic you can see a presentation I wrote preempting the challenge of metadata protection back in 2016 (on the day we first turned on E2EE in Matrix, ironically): https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E.... In some other world perhaps we would have got to this point sooner, but better late than never.
EDIT: I can't face going through all the other points in this post, but it's worth noting that some of it is just entirely false - e.g. the hackea claims of "an impressive collection of private data being sent to Matrix central servers, even when you use your own instance", or the fact that media isn't authed (it has been since Jun 2024). Meanwhile the abuse situation has evolved significantly in 2025, with stuff like https://matrix.org/blog/2025/02/building-a-safer-matrix/ and https://matrix.org/blog/2025/12/policyserv as well as hiring up a larger trust & safety team at the Matrix Foundation.
"We’ve also removed the duplicative meta-spaces (People, Favourites). Filters are the new foundation — more flexible, more future-proof, and built for growth."
As a heavy Element user for work, I have long hated this in Element X iOS and now I have the pleasure of hating it in Element web. Everyone at my job is mad about the remove of these "duplicative" metaspaces. Here's a GitHub issue about it: https://github.com/element-hq/element-web/issues/30849
I am a UI dev and I try to give people the benefit of the doubt, but after using Element for nearly 5 years, it really does feel like the user experience only gets worse over time. It is really sort of amazing.
In New Element Web and Desktop appsMedia loading fails with M_NOT_FOUND (debug console network tab), regardless of wehter the user posting the image is from my own home server or another one.
Invite issue:
https://github.com/element-hq/element-web/issues/29028
And several ones opened against synapse, but as it happens a fix was finally merged a day ago: https://github.com/element-hq/synapse/pull/18696
In Giving Up on Element and Matrix.org> Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place.
I actually wrote the notification panel in the first place: https://github.com/element-hq/element-web/pull/2113 and when we shipped it, it worked fine. However, this was 2016, before Matrix had E2EE (which eventually got turned on by default in 2020), and E2EE complicates notifications enormously, given the server can't read the messages in order to figure out whether they're a notification or not. So, instead, the client has to calculate notifications instead, which (worst case) means it has to spider every message in every E2EE room to figure out whether to no
Read the rest
tify based on keywords, mentions, event type, etc.
So, rather than hooking up all that logic in Element Web, we left NotifPanel as is, working fine for unencrypted rooms (and working best-effort for encrypted ones, iirc), instead focusing on fixing Matrix's famous decentralised E2EE stability (Unable To Decrypt errors), which literally took years. Then, rather than implementing proper notification logic in duplicate across both js-sdk (Element Web) and rust-sdk (Element X), we focused on nailing it in rust-sdk - and meanwhile hid the feature on Element Web until we can swing Element Web over to use rust-sdk (Aurora).
So to answer your question: we didn't ship a flakey feature in the first place. But hiding it once it got flakey rather than even further slowing down our progress on stabilising E2EE (given we don't have manpower to adequately to maintain two stacks) definitely feels defensible.
A more interesting question is whether we've done the right thing by rewriting all the platforms to use a shared Rust core. However, we're not alone in doing that sort of transition: https://github.com/signalapp/libsignal etc.
> > To improve the UX with clients, we had to improve the protocol.
>
> While I believe this to be the best way forward, was it also the fastest way to acquire a userbase? If we look at Bluesky for instance, they pretty much did the reverse of what Matrix.org did, and (I think) thus was in a position to garner hefty growth as a result.
We know the Bluesky team quite well, and I strongly suspect they learnt from Matrix's misadventures (just as we in turn learnt from XMPP's). My FOSDEM talk this year was literally about this: https://youtu.be/lkCKhP1jxdk?t=490. Empirically Matrix is good at ecosystem uptake (better than Bluesky) but worse at mainstream. It's never too late to change though.
> (Recently they finally added the ability to require authentication for the media store, although they didn't add support for it to their web client, only their new Android one.)
This is not true. If it were true, it would imply you can't view any newly uploaded media from the web client. Here is the web implementation of MSC3916: https://github.com/element-hq/element-web/pull/27326
In Matrix Foundation to shut down bridges if it doesn't raise $100KUnable to Use Element Web on Firefox ESR
5 points · Open discussionI work at a 25 person startup and we've been using Element as our main chat platform for the past 6 months (paid hosting), however we're now in the process of migrating away. I really wanted to like it because it supports good encryption and is open source, but unfortunately it's just too buggy. The main pain points are:
- Stuck notifications [1]
- Being unable to decrypt messages (from certain users sending from certain devices; some people can read them, others can't)
- No proper notifications for old threads
- Various GUI instability bugs: chats that are suddenly empty, text suddenly randomly overlaid on other text, randomly missing scroll bars, etc.
1: https://github.com/vector-im/element-web/issues/24392
In Matrix 2.0: The Future of MatrixThe main remaining Nebuchadnezzar issue is mitigating server-controlled group membership. The first step has been to kill off the 1st gen E2EE implementations, which were responsible for the implementation vulns found by RHUL - and we should hopefully conclude that next week by moving everything into the matrix-rust-sdk crypto crate implmentation: https://github.com/vector-im/element-web/issues/21972#issuec... is the tracker.
Then, we can address the harder server-controlled group membership issue in one place. First step will be to improve device verification & trust so that trust is the default, not the exception, to make it easier to spot and warn about unexpected devices in the room. The full solution is then either MSC3917 (https://github.com/matrix-org/matrix-spec-proposals/blob/fay...) - or potentially to switch everything to ML
Read the rest
S.
We're working on MLS anyway in parallel to RHUL mitigation work; you can see the progress at https://arewemlsyet.com, and it's looking good.
I'm guessing you're not interested in doing a podcast on "yay we converged our crypto implementations on a single robust Rust implementation so we can fix the remaining bugs in one place", but as soon as the server-controlled group membership thing is solved we'll be in touch. Work has also gone much slower than hoped on this, thanks to the joys of funding open source.
Sounds like you’re talking about Element Web or Desktop here. On Mobile, we just rewrote the app as Element X and it addresses almost all your concerns (other than per-room nicks, although ironically Element Web does have that today - try the /roomname command).
Having got Element X out the door, my attention at least is going to swing back to Element Web. In terms of encryption disasters, we are about to switch Element Web’s crypto to the same rust implementation as Element X, hopefully next week - you can track the progress at https://github.com/vector-im/element-web/issues/21972#issuec.... Hopefully this will make a much-needed massive improvement on encryption, while also speeding it up 5x or so. On Element X, encryption failures are almost unheard of (other than when talking to Element Web).
In Matrix 2.0: The Future of MatrixI saw this and got excited but no, this isn't discord voice channels. This is an integrated jitsi meet call. It looks like some sort of prototype has been merged to develop though:
https://github.com/vector-im/element-web/pull/21476
In Revolt: FOSS Discord Alternative> it is actually possible to downgrade a flatpak
Only when the version you want to downgrade to happens to be within the last 10 versions! Why 10? Beats me!
Case in point: the flatpak package for the Element messaging client seems to be the preferred installation method for non-debian distros. But for many users, encrypted message search is broken! [1] [2] Some users claim that downgrading can fix the issue, but the flatpak has been updated too many times now for any user to downgrade to an old enough version - tough luck!
[1] https://github.com/vector-im/element-web/issues?q=is%3Aissue...
[2] https://github.com/flathub/im.riot.Riot/issues?q=is%3Aissue+...
In KDE and GNOME seeks $100k to turn Flathub into a Store for the Linux desktopShowing the 15 most recent of 125 sources. Enable JavaScript to search and browse every indexed mention.