https://github.com/vector-im/riot-web/issues/5857 or https://github.com/matrix-org/synapse/issues/4762
In Synchronous Messaging at Mozilla: The Decisionelement-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, 8:59:20 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
28 sourcesI guess https://github.com/vector-im/riot-web/issues/2735 is the bug to upvote. Annoying it's been stuck open forever :(
In Synchronous Messaging at Mozilla: The Decision1a: Yes. the second we have parity, we'll start turning it on by default for private rooms. We'll probably start with DMs, and we'll probably do a fairly soft roll-out to sneak in some final testing. Current status is that we have E2E Search working (github.com/matrix-org/seshat); we have E2E cross-signing almost done (https://dashboard.lant.uk/#/plan?epic=vector-im/user-stories... we have eyes on the remaining causes of undecryptable messages and are working through them. We're aiming for Jan.
3: Interesting. It could be a very temporary CPU saturation on the Matrix.org CPU master. We're working on sharding the master per-room to mitigate this, but it's going to be a few months to land.
4: Looks like there is a bug for this already - please upvote https://github.com/vector-im/riot-web/issues/10649.
Testing & reporting bugs is absolut
Read the rest
ely invaluable - thank you.
That's true, but cross-signing is right around the corner for Matrix [1], which will enable e2e by default in direct chats [2].
Encryption is useless for most public rooms, and actually counter-productive most of the time. If the room is public, anybody can join it, idle there and save the logs on their computer, or publish them. Activating encryption is just annoying: from the top of my head, you can't read what was posted before you joined (unless someone sends you their keys), search is client-side only, it's hard to link to attachments or reuse mxc: (matrix content such as images) from one channel to another.
[1]: https://github.com/vector-im/riot-web/issues/2714 and the two links below
[1]: https://github.com/vector-im/riot-web/issues/10605 and associated labels
[1]: https://github.com/vector-im/riot-web/issues?q=is%3Aissue+is...
[2]
Read the rest
We use it for the end-to-end encryption implementation in Riot.im on Web; from memory it sped up the asm.js emscripten based implementation by a factor of about 3x, and also is a (slight) improvement in terms of risk of timing attacks.
Edit: here's the PR for switching from asm.js to WASM, in case anyone's interested: https://github.com/vector-im/riot-web/pull/7385/files apparently it merged in Oct 2018.
In WebAssembly becomes a W3C RecommendationSo, firstly - huge thanks for taking the time to list the problems :) I'm the project lead for Matrix & Riot hence my interest.
Totally agreed that the lack of cross-signing for key verification is our single biggest problem. It turns out that this is not an easy problem to solve, but after a few rethinks we finally have a design (https://github.com/matrix-org/matrix-doc/pull/1756) and an implementation (https://scitech.video/videos/watch/d1ef04a8-397a-4570-a9a9-c...) which works. The only bit that remains is wiring it into the Riot's UI itself, which we started a few weeks ago and is looking promising. The TL;DR is that it optimises the number of verifications to the absolute bare minimum. You verify your new device once when you log into it (a bit like WhatsApp), and then everyone else will transitively trust the new device.
In term
Read the rest
s of the unreliability of the matrix.org server: we added encrypted key backup about a year ago to solve the whole "if you get logged out you lose your keys" problem, but agreed it used to be a massive problem. And yes, the matrix.org security breach was a nightmare - apologies.
For the i18n bug: if the request to load the i18n file for your language fails for whatever reason, you get that ugly error - it's similar to getting an ugly page if the CSS didn't load. We can make the i18n req retry, though - i just filed https://github.com/vector-im/riot-web/issues/10965 for this.
In terms of the number of bugs - yes, we have 3775 open, and 5871 closed. This is because we deliberately try to track each and every possible suggestion & feature request & bug of every severity in the issue tacker; trying to use it as the main knowledge store for the project. I wouldn't judge the quality of a project by the number of bugs - it's like judging the quality of a book by the number of pages. It doesn't tell you much beyond how big a book it is.
Search should work, but delegates straight through to postgres's FTS engine. We need to tune it better, for sure.
> So basically, it's a mess right now
Hopefully key verification will fix the biggest issue here. Thanks for persevering with it in the interim.
Okay, so maybe "unbelievable crappy" was a bit of an exaggeration. After all, I do use it. But I'll try to explain. It starts with the fact that so many of the features still aren't up to par with what e.g. Discord provides. It feels like a knock-off.
The biggest problem I've faced is dealing with the encryption. Every new device in a conversation has to be verified with every other, which means you need n(n-1)/2 pairings for a room with n devices. That's right, if you're trying to set up a chat with 10 people who have an average of three devices, you're going to need to do 435 pairings. The pairings themselves are a huge pain: there are different pairing "methods" to use, and different clients will make guesses about the method the other client supports, and the whole thing falls apart if it guesses wrong (there's no negotiation, as far
Read the rest
as I can tell) or if the person with the device doesn't immediately respond. There's no notion of a web of trust or trusting a person instead of a specific device. Even if everything goes right (it usually doesn't) it's going to take about 30 seconds per person to do each pairing, which means your group chat with just 10 people is going to take over 7 hours to set up. You could just ignore the verification stuff, but presumably the reason you wanted to use Matrix (instead of a centralized service) in the first place was because you thought it was more secure / private.
Someone adds a new device, or logs out of a device, or there's some glitch (it's happened to me)? Everyone in the room gets to do another pairing. With every one of their devices.
Another issue has been the unreliability of the service itself. Sometimes it breaks, logging you out. (Hope everyone backed up their keys!) Or they get hacked and the server goes down for days: https://matrix.org/blog/2019/05/08/post-mortem-and-remediati...
And then there's just the random client bugs. I literally just opened the tab for Riot to remind myself of other issues and was greeted with this: https://i.imgur.com/8Rgebfr.png They don't seem to be keeping up with them, either. Riot Web alone has almost 4000 open issues: https://github.com/vector-im/riot-web/issues
Having a searchable history is supposed to be one of the major advantages of a Discord-like interface, but I just did a search for a word that I'm looking at in the chat and got no results.
So basically, it's a mess right now. I'm using it with one person because they're the only person who wants a Discord-like chat with me and are willing to put up with the amount of nonsense needed to use an alternative that doesn't siphon off your data to a private company.
Matrix does not require a centralized identity server (which exists only for optionally discovering users on Matrix based on their email/phone numbers).
The linked gist is loudly complaining (amongst other things) that Riot's default config points at a centralised one by default.
We've already fixed this (https://github.com/vector-im/riot-web/issues/10553) by simply removing the concept of default identity servers entirely and instead prompting the user to select on demand whichever one they want to use, if they actually try to look up a user based on email/phone. It should be released in Riot 1.4 (on Web, and equivalent ones on mobile etc) in the coming weeks.
You can see our response to that original gist at https://matrix.org/blog/2019/06/30/tightening-up-privacy-in-..., and you can track progress over at https://vector-im.github.io/f
Read the rest
eature-dashboard/#/plan?label=p... (which has a cache from yesterday published at https://matrix.org/~matthew/privacy-sprint.html).
> Signal uses standard cellular mobile numbers as identifiers
Exactly and what's to say I want some random guy on the internet being able to call my phone.
Keep in mind tptacek quite literally pastes replies gushing about Signal/Wire in any thread related to PGP or instant messaging. They even paste it in threads which mention PGP but talk about other issues such as file encryption, signing etc, ie the uses not covered by an instant messaging platform. I have come to just skimming over anything they say because of it. Come on, put a bit of effort into your reply.
> Wire uses metadata but only requires an e-mail account.
It also doesn't offer federation. At this point I think Matrix is the best hope if you're okay with minimal metadata. It is also making huge strides of progress if you keep up to date with their development, so that's exci
Read the rest
ting. https://matrix.org/blog/posts
> There is Cwtch (https://cwtch.im/) that extends Ricochet to support multi-party messaging. I did not dig deep into it, but it may use the same algorithms. Additionally, it uses a language with a GC.
I have high hopes for Cwtch. It seems to be a common thing people don't want to address: metadata. That said you can have a fairly meta-dataless experience with Matrix if you run a server and don't federate.
Ideally I'd like to see this get solved https://github.com/vector-im/riot-web/issues/2320#issuecomme...
> This is a feature, not a bug. Nobody actually wants to rely on a single entity (for or non-profit) for their communication. Nobody wants to be stuck in crappy Electron and mobile clients.
And nobody facing a nation state adversary wants to give their chat client their phone number. I really couldn't agree with you more on the nature of the problem and the status of the available solutions. It's really unfortunate that Matrix is as unfinished as it is. At least cross signing [1] is nearly done, which should eliminate the major issue making it unusable for anyone who's not technically competent and very dedicated.
[1] https://github.com/vector-im/riot-web/issues/9631
In Opmsg – A GPG AlternativeI'm pretty amazed at the number of chat offerings that don't offer encryption. (From a quick Google search it seems Mattermost doesn't either.) I'm still holding out for Matrix to deliver (I know it's currently working for some people), but my understanding is that it's not enabled by default yet:
https://github.com/vector-im/riot-web/issues/6779
In Open-Source Slack Alternative Mattermost Gets $50M FundingThis seems to be how Matrix/Riot plan to enable search in E2E rooms:
- https://github.com/matrix-org/matrix-search
- https://github.com/vector-im/riot-web/issues/2548
In What If All Your Slack Chats Were Leaked?The feature I miss most is expiring messages. Yes, it totally depends on correct end-user client implementations and honest participants, but it is crucial for many scenarios where a client is compromised after the fact (or, lets say, an over-ambitious border control...). https://github.com/vector-im/riot-web/issues/2497
In Tightening up Privacy in MatrixOkay, so i guess it's not really a question of privacy hyperfocus but just different users having very disjoint use cases.
I'm not sure i'd characterise this as phoning it in: the point of the blog post and all the accompanying bugs is to spell out that we're trying to solve for once and for all the problem of how best to enable contact discovery for folks who want it (as opt-in rather than opt-out!)... while also keeping the private-messaging crew happy. Totally agreed that it's been half-baked historically though, which is why we're fixing it now that 1.0 is out the door and we have some bandwidth to address it.
> Separate the flows.
The idea here is absolutely to separate the flows. We don't have a final UI proposal yet (as is clear from the bugs) because we're still working it through. The closest is probably https://github.com/vec
Read the rest
tor-im/riot-web/issues/10091 right now.
(Matrix lead here) The core problem is: empirically most users want an app which works like Signal, WhatsApp, Telegram etc and tells you which other users are contactable. If you’re some random installing a comms app, you want to know if any of your contacts are on it already. It’s nothing to do with whether your long lost cousin is on it.
However, there are then folks hyperfocused on privacy who declare this ‘toxic data exfiltration’ and vociferously object.
We’re trying to get the balance right, and it’s worth noting that the bug you linked is still up in the air. We don’t have the final UX yet, but the idea is to even more explicitly warn the user that their contacts are being uploaded to a identity lookup service if they want to discover people on the network. An alternative/complementary approach is https://github.com/vector-im/riot-
Read the rest
web/issues/10093.
(edited due to accidentally hitting submit...)
Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.