This was truly a great year for matrix. Thanks to the whole team for making a dream about decentralized www come true!
But I have a great pain with that bug: https://github.com/vector-im/element-web/issues/469
Everytime I’m fighting with myself to not be sarcastic when speaking about this issue, but I want to say I have hard time believing that Element could we a main communication platform for anyone without this being fixed. It drives me mad, and I have just two people to communicate with!
In This Year in 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, 12:01:02 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
19 sourcesSo I've just double-checked this by opening https://app.element.io in an incognito tab and looking at the network inspector. What I see is what I was referring to in the grandparent as:
* Element has to query your server to find out what authentication mechanisms are available before you log in. Therefore if its config points to the default matrix.org homeserver, you end up pinging that every time you log in, even if your homeserver is elsewhere. The solution for now is to change your default homeserver in the config to avoid this.
The same applies to the identity lookup server as well as the homeserver: the app checks the one in your config to ensure that it exists before the user tries to log in on it. It does this with a single request (a GET to https://vector.im/_matrix/identity/api/v1). There is no token exchange there.
The workar
Read the rest
ound is to configure the app with the correct default homeserver & identity server (if any) for your deployment. The underlying bug (i.e. don't validate the config until the user tries to log in) is https://github.com/vector-im/element-web/issues/11655, and it simply hasn't got to the top of the list yet; we've been focusing on narrowing the UX gap between Element & Discord/Slack/Teams rather than reimplementing the login flows. As you can see on the bug, it's been picked up off the backlog 9 days ago and is currently being worked on.
Separately, I'm seeing a related bug that Element Web's guest mode is incorrectly kicking in on the login page. Guest mode exists so you can deeplink straight to something like https://app.element.io/#/room/#matrix-dev:matrix.org and read scrollback without needing to register an account - but it looks like we're spinning up guests on the default homeserver needlessly on the login page. This is https://github.com/vector-im/element-web/issues/11533, and we've put it on the radar too.
TL;DR: this is slightly leaky, but is it really any different to Chrome's default config loading up Google as a default homepage? Or Firefox loading up Mozilla.org? Or Thunderbird loading up Thunderbird.org? Eitherway, we'll fix the behaviour, but PLEASE understand that this is a million miles away from the bogus "central authority can have influence on another server" smear from the original post.
> I don't think the intent is malicious, but the system is definitely leaky. My homeserver config doesn't mention vector.im (perhaps it's a hidden default somewhere?), I checked.
IIRC, identity server is something primarily set on the client (element.io here) rather than the homeserver.
It really needn’t and shouldn’t ping an identity server as part of the sign-in process (esp before/without privacy policy agreement)
FWIW it seems the issue is that there’s a fallback process for identity server; if neither your account nor your homeserver has one set, it defaults to the client default. if you host your own Element-web instance you can change this.
https://github.com/vector-im/element-web/blob/develop/docs/c...
Or check out ma1sd. You don’t need to enable all the bells and whistles if you don’t want to.
In XMPP, a comeback storyYup, Matrix as a network has no central authority at all, although it's a common untruth which gets passed around, rather depressingly.
Things which could be at the root of this misunderstanding include:
* The fact that we operate a *strictly optional* logically centralised directory service to look up matrix IDs by email address or phone number. I really wish we'd never added this to Matrix; it causes way more grief than it solves - we'd have been better off waiting off for someone to build a decentralised keybase service and use that instead.
* Element runs a centralised integration manager (aka app store) to make it easier to add bots/bridges/widgets to rooms. Again, this is completely optional - although back in 2019 we had a stupid bug in Element Web which meant it checked the integration manager even if you weren't using it. This
Read the rest
was fixed in June 2019 (https://github.com/vector-im/element-web/issues/6802).
* Element has to query your server to find out what authentication mechanisms are available before you log in. Therefore if its config points to the default matrix.org homeserver, you end up pinging that every time you log in, even if your homeserver is elsewhere. The solution for now is to change your default homeserver in the config to avoid this.
* Servers need to be able to validate events from servers even if those servers are offline. To do this you need to grab the public key for the offline server from somewhere; by default Synapse uses matrix.org as a fallback, but loudly nags the admin to pick a better default when you install the server.
None of these actually allow a "central authority to have influence on another server" though; I've just listed the only places I can think of where a typical self-hosted Matrix implementation might interact with centralised services run by Matrix.org or Element.
Unfortunately I think the real root of the misinformation is that it's just a bit too tempting and easy to throw around FUD. Some day we may get to the point where alternative FOSS projects will realise that the real enemy are centralised proprietary user-exploiting services rather than one another...
I think this one is also pretty bad. And years later still not fixed. https://github.com/vector-im/element-web/issues/2527
In short? When you look at a room, your client sends a (public) read receipt. So stalkers get near-realtime data on your activity and the simple act of viewing different rooms (and maybe even just focusing the window) to see what's up causes data to be sent to the server. Ugh.
In Notes on privacy and data collection of Matrix.org (2019)These issues I'd consider pretty crucial to approaching Signal-like privacy and there's not been much progress on them unfortunately:
https://github.com/matrix-org/matrix-doc/pull/1769
https://github.com/vector-im/element-web/issues/11655
https://github.com/vector-im/element-web/issues/2320
https://github.com/vector-im/element-web/issues/2772
https://github.com/vector-im/element-web/issues/2458
In Notes on privacy and data collection of Matrix.org (2019)sneak’s pet issue is https://github.com/vector-im/element-web/issues/11655: that element web assumes that you want to log into the matrix.org homeserver by default unless you change its config to default to a different one.
The libremonde research is over 2 years old now, and the valid bits of it were addressed at the time (https://matrix.org/blog/2019/09/27/privacy-improvements-in-s...)
In Element One – All of Matrix, WhatsApp, Signal and Telegram in one placeWe hear the desire to fully hide the Spaces sidebar loud and clear. It wasn't a blocker for leaving Beta, but we are tracking that request in https://github.com/vector-im/element-web/issues/18898
In Spaces launch in ElementIt's funny, but I can not agree more.
I never think a concrete issue will affect me. But over the last weeks I've been affected exactly by 2). Today I finally figured out that it had to do with the sender having turned on the setting "Never send encrypted messages to unverified sessions from this session". It's terribly implemented, because it gives the sender no feedback that they break any unverified receivers, and the unverified receivers only see an obscure error message. For more details, see my issue report: https://github.com/vector-im/element-web/issues/18255
Also +1 on Element's terrible UI and UX. It was designed by programmers instead of UI designers, and you can feel that. I always find it weird when people talk about Element being a good client. It's literally the best of the worst. From the thousands of open issues (5000+ We
Read the rest
b, 1000+ iOS and Android each!) you can clearly see they have an organization problem. Even most volunteer open source projects are more organized. I hope at least 30 million will be enough for them to hire some talented people and build a better management.
I have the feeling most of them are hackers. Hacking and experimenting with new things like Matrix P2P is great, but it's not enough to have consistent output. You need to manage an organization, and I have the feeling they aren't capable of doing that. On that note, I'm surprised they managed (pun!) to get 30 million of investment.
There's no "phoning home". What I think you're talking about is that Element Web's default config specifies the identity lookup server at vector.im: https://github.com/vector-im/element-web/blob/develop/config.... The identity server is optional, and just used for looking up matrix IDs based on email address or phone number. When Element Web launches is currently checks if your config is valid (i.e. do these URLs actually point to valid servers?). If you're running your own deployment with your own server, then you'd point the config to whatever identity server you wanted, or just remove it entirely - just as you'd point the config to default to your own homeserver.
We have a separate bug to defer the server validation check until the user actually tries to talk to the identity (or home) server, but it hasn't got to the top of the tod
Read the rest
o list yet; patches welcome!
Edit: To clarify: this behaviour only occurs with Element Web (rather than Matrix clients or servers in general)
thanks; filed https://github.com/vector-im/element-web/issues/17396 for widgets.
Not sure what problems you're seeing with the Matrix API; it's lightyears ahead of Slack & Discord in my experience, but I guess i may be getting high on my own supply...
In The Matrix Space BetaI wish Matrix would instead focus on fixing all the existing encryption usability issues instead of these new features:
https://github.com/vector-im/element-web/issues?q=label%3AA-...
I would love to migrate my family to Element (and also friends, and eventually also recommend it to employers if they're ever choosing something other than Teams) but can't until it's reliable as webmail. I also wrote this comment:
https://news.ycombinator.com/item?id=25271512
"Once Element is mature enough (and I'm sorry, but looking at the incoming issues on https://github.com/vector-im/element-web/issues?q=sort%3Aupd..., it doesn't look like it yet), then hopefully more companies will start considering it."
I get that E2E means it cannot be as simple as email, and I can handle the extra training that's needed, but not for figuring out all these known is
Read the rest
sues and attempting to prevent people hitting them, or having to handle the situation if they do.
As per my comment at https://github.com/vector-im/element-web/issues/11655#issuec..., we'll switch auto-update checks to require user confirmation.
In The Matrix Space Beta> I'm puzzled by this comment. Can you elaborate on what you mean by phoning home?
On first launch, it connects to multiple centralized servers before you have a chance to select your homeserver.
The issue was with the default client, in the default config.
Not sure if it's still happening, but it was concerning enough that it happened in the first place.
https://github.com/vector-im/element-web/issues/13942
https://github.com/vector-im/element-web/issues/12712
https://github.com/vector-im/element-web/issues/11655
https://github.com/vector-im/element-web/issues/11655#issuec...
It would also appear that it intends to maintain a Solarwinds-style remote code execution vulnerability on the machine on which it is installed:
https://github.com/vector-im/element-web/issues/11655#issuec...
In The Matrix Space BetaThank 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
Read the rest
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.
Showing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.