HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ProtonMail
WebClients
TypeScript2016–2026
ProtonMail / WebClients

WebClients

Monorepo hosting the proton web clients

25Distinct people
27Mentions
0Explicit recommenders
5.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Monorepo hosting the proton web clients

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

No other repository is repeatedly linked in the same discussions.

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 year27 dated mentions

Observed mentions: 2016-03-17 18:55:54 UTC to 2026-04-03 13:40:33 UTC.

024682016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 8 mentions; 2 submissions, 6 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC826
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Web clients This project is a monorepo hosting the Proton web clients. It includes the web applications, their dependencies & shared modules as well as all tooling surrounding development of the web clients (as well as some additional miscellaneous things). Proton Mail Proton Calendar Proton Drive Proton Account Proton VPN Proton Pass Proton Wallet Proton Lumo Proton Meet Technically, this monorepo is based on pnpm & pnpm workspaces, with unified versioning for all packages inside. Getting Started Prerequisites You'll need to have the following environment to work with this project: Node.js satisfying engines.node in the root package.json (a .node-version file is provided for fnm, mise, and similar tools, and a matching .nvmrc for nvm — keep both in sync) pnpm satisfying engines.pnpm in the root package.json (install with your preferred method, e.g. npm install -g pnpm) git CI installs the exact pnpm version from the packageManager field; locally, any version that satisfies engines.pnpm is fine. Wrong package managers are rejected at install time (preinstall), and engine-strict=true in .npmrc makes pnpm install fail when Node or pnpm is below the declared floors. Installation # Clone the project git clone https://github.com/ProtonMail/WebClients.git git clone git@github.com:ProtonMail/WebClients.git # Install all dependencies for the entire monorepo & symlink # local dependents to one another pnpm install # Run web clients by running proton-<package-name> # Example: proton mail web client pnpm --filter proton-mail run start For additional details on how to interact with the monorepo, see the pnpm docs for reference. Shared dependency versions (catalog) Every workspace declares the dependencies it imports. When many workspaces declare the same dependency and must stay on the same version, the range lives once in the catalog: section of pnpm-workspace.yaml, and each workspace references it with "catalog:" instead of a range: "devDependencies": { "@types/node": "catalog:" } Use catalog: when: the dependency is declared by several workspaces (as a rule of thumb, three or more), and they have to move together, for example the @types packages that tsconfig.base.json lists in compilerOptions.types, or a package where two versions in the tree would break things. Declare a plain range instead when: only one or two workspaces use the dependency; a workspace deliberately needs a different version (for example utilities/lumo-dev-proxy keeps @types/node@^22); it's another workspace: use workspace:^; you need to pin a transitive dependency, for example for a security fix: use overrides in pnpm-workspace.yaml, since the catalog only applies to workspaces that reference it. To add an entry, add the range to catalog: and switch every existing declaration of that dependency to "catalog:" in the same change. To bump it, change the range in pnpm-workspace.yaml only. Either way, run pnpm install and commit the updated pnpm-lock.yaml with it. How VPN app differs from the rest VPN is present in both proton.me and protonvpn.com. However, they are served differently. Some parts of VPN are shared, hosted within @proton/components or @proton/shared, however, the entry points to them are different. For protonvpn.com, the entry point comes from applications/vpn-settings and for account.proton.me/u/{X}/vpn, the entry point is applications/account. Since both domains are separate, we don't share a local SSO between them. Therefore, we need to serve both applications separately: # To serve VPN through vpn-settings pnpm --filter proton-vpn-settings run start --port 8050 # To serve VPN through account pnpm run start-all --applications "proton-account" How to version an application manually While being on the main branch for a clean release. From the root folder, run pnpm --filter @proton/version run version --applications proton-X --version x.x.x.x Help us to translate the project You can learn more about it on our blog post. License The code and data files in this distribution are licensed 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. See https://www.gnu.org/licenses/ for a copy of this license. See LICENSE file
Read the full README on GitHub

What Hacker News says

4 sources
This all seems to be a web-based application (https://github.com/ProtonMail/WebClient). How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code? The arguments against server-supplied, js-in-the-browser crypto have been done to death. Why is this any different, and why am I wrong to dismiss it out-of-hand as (in)secure as simply sending unencrypted data to the server? Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server). > we choose our own primes rather than those used by TLS Does TLS specify any primes? You can use your own DH primes, SRP primes, and your key is your own prime. Those RFCs recommend primes, but allow the server to use different ones. TLS, SRP, or DH doesn't
Read the rest
"use" a single prime, any prime satisfying the requirements in the RFC is acceptable. know it's nitpicking but something about how it was said rubbed me the wrong way. I would love to know how they communicate between their TLS-SRP layer and their authentication layer. Most implementations are file-based. Did they write a plugin for gnutls or openssl? Did they write their own TLS layer? I would love for TLS-SRP to be more wide-spread, but this is always the biggest hurdle to adoption in my case.
In Improved Authentication for Email Encryption and Security

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.