I 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 Matrixelement-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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 1:03:20 AM 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
8 sourcesThe 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 desktop> "At least as standard" how?
There are 8 people who vote on changes to the Matrix spec (the Spec Core Team), 7 of which are Element employees (including Matthew, Element's CEO). Element also controls the development of clients and servers used by the large majority of users in the public federation.
The IRCv3 working group is made of plenty of organizations (non-exhaustive lists at https://ircv3.net/participation / https://ircv3.net/charter) with at most two "representatives" each.
> A substantial portion of the IRC comunity is actively hostile to the IRCv3 extensions, and in some cases prefer incompatible implementations of the same functionality; Matrix has nothing like that going on.
But any IRC client will work fine on any IRC server, and they can simultaneously connect to various servers which support variants of the protocol (eg. t
Read the rest
hrough capability negotiation). Also note that 75% of servers support IRCv3 capability negotiation: https://www.ircstats.org/server-features/cap (and the others are often at all not developed anymore)
On Matrix, clients (generally) can only connect to one homeserver at a time; which forces them to converge on following the same spec. And if your server differs ever so slightly from the other ones in how it implements some parts of the spec (room consensus), then it can be split-brained from the rest of the federation. Instead, changes to the room consensus are done by pushing new room versions, and each server implementation needs to explicitly support it or they can't join it. This means Synapse devs (which are a majority of Element employees) get to decide what room versions can get traction.
It is not uncommon for people in the Matrix community to complain about this and Element keeping specs in limbo, and PRs to the flagship clients being stuck in "design review tar".
> And there seem to be more visibly independent implementations of Matrix than IRCv3.
Clients, maybe, at least in the number of implementation. It's hard to find stats of this, but I feel that >95% of people in the public federation use Element even in tech-y rooms; IRC has a healthier mix of major clients (weechat, irssi, IRCCloud, Hexchat, KiwiIRC, The Lounge each have >5% of desktop/web users). But I admit that's just my very subjective point of view.
In terms of servers, Matrix has three open source ones as far as I know: Synapse (controlled by Element), Dendrite (controlled by Element, and almost on par with Synapse according to https://arewep2pyet.com/ ), and Conduit. Based on https://gitlab.com/famedly/conduit/-/milestones/3 , Conduit seems to be far from implementing the spec yet (eg. it doesn't seem to support leaving rooms or respecting history visibility). And I can't think of any non-Synapse server, besides Matrix devs self-hosting.
Meanwhile, IRC servers: https://www.ircstats.org/servers (note: this counts servers and not networks or users)
> things like: server-side history extensions tended to mess up my client's history implementation (I'd end up with multiple copies of the same messages in my local logs, often with the wrong timestamps)
You can use https://ircv3.net/specs/extensions/message-ids to deduplicate them.
> And if you're in a conversation where people are using embedded gifs, then fundamentally you'll always be a second-class citizen if you're trying to participate in that with a client that can't display embedded gifs.
A conversation where people are using embedded gifs will exclude me regardless of client, because they are too distracting. At least on IRC I can expect people not to do it too much, and use words or emojis instead of reaction gifs.
Speaking of which, Matrix does not provide a way to provide alt-text to images and videos, which ends up excluding plenty of people as well. (To be specific, the spec technically does provide a way, but clients use it for filenames instead: https://github.com/vector-im/element-web/issues/22100#issuec... )
> SSO access control; you just can't do that in a nice way if the client doesn't support it
That's a fair point; IRC is made by hobbyists more than companies, so that's not surprising. There is some discussion around it though: https://github.com/ircv3/ircv3-ideas/issues/74 and Sourcehut is sponsoring design and implementations (https://emersion.fr/blog/2022/irc-and-oauth2/).
Gitlab and Element's website structure is different. element.io is the site for the managed product, so even their "on-premise" installer is meant to be used in a commercial relationship. For install docs you'd probably have to purchase their product (which isn't available freely).
You probably want to read the open-source software's installation instructions at: https://github.com/vector-im/element-web
TLDR, check out the project, run `yarn install`, then edit the config file, then `yarn build`.
And, yes, that is all there is to it. It's significantly simpler to deploy than GitLab.
Finally, you keep mentioning self-hosting; you _can_ just use a non-self hosted application like the downloadable version of Element, SchildiChat, Fluffychat, or any other client.
No reason to bring hosting into the mix for the client, if that's causing concer
Read the rest
n.