meganz/webclient

1. This repository is the MEGA web client: a large client-side application served as static assets, not a traditional server-rendered app. The main architectural boundary is between browser-executed UI/logic and MEGA’s backend APIs, with the client responsible for encryption, state management, and most UI rendering.

2. Bootstrapping is centered on secureboot.js, which loads versioned HTML/JS/CSS/resources from static content servers and verifies their hashes before execution. The repo’s index.html, html/*.html, and top-level secureboot.js form the entry-point layer; the live site is generated from this repo into hash-stamped assets.

3. The app is organized as a multi-surface frontend rather than one single view. Major surfaces include:

- File Manager (js/fm.js, js/mega.js, js/fm/*, html/fm.html)

- Chat/Meetings (js/chat/*, worker.sfuClient.bundle.js, worker.recorder.bundle.js)

- Mobile (js/mobile/*, html/mobile.html)

- Public/marketing/transactional pages such as login, signup, pricing, recovery, download, embed player, etc. (html/*.html, html/js/*)

4. The File Manager is the core application subsystem. js/mega.js holds the MegaData model and most data handling; js/fm/* contains file/folder operations, dialogs, devices, gallery, shares, S4 object storage UI, recents, versioning, and account-related views. This subsystem binds the remote node metadata model to the visible file tree, dialogs, and action menus.

5. Data persistence and caching are handled client-side through js/mDB.js, js/idbkvstorage.js, and related utilities. The client caches metadata and other state in IndexedDB/local storage to support responsiveness and offline-ish behavior, while js/utils/* provides shared abstractions for storage, events, network, locale, and DOM helpers.

6. End-to-end encryption is a first-class architectural boundary. js/crypto.js, js/keymgr.js, js/security.js, js/paycrypt.js, sjcl.js, aesasm.js, rsaasm.js, nacl-fast.js, and naclworker.js support key generation, content encryption/decryption, authentication, and secure transfer flows. Encryption is not just a transport concern; it is embedded into upload/download, thumbnail generation, chat, and password-manager features.

7. Upload and download are separate pipelines with their own workers and transport strategies. encrypter.js and decrypter.js run as web workers for file processing; js/transfers/* contains chunking, queueing, retry, filesystem/indexeddb/memory backends, and XHR/WebSocket helpers. This is the main data plane for moving encrypted file content between the browser and MEGA storage.

8. Chat and meetings are a distinct subsystem with its own runtime model and UI tree. js/chat/chat.jsx, js/chat/ui/*, and plugins under js/chat/plugins/* implement messaging, search, reactions, rich previews, presence, notifications, and MEGAchat-specific workflows. Audio/video calling is split into an SFU client (js/chat/sfuClient.js) and worker bundles for crypto and recording, which isolates realtime media/signaling concerns from the main app.

9. The mobile client is not just responsive CSS; it has dedicated code paths. js/mobile/* and css/mobile/* provide mobile-specific navigation, dialogs, cloud browsing, account flows, recovery, transfer overlays, and settings. This suggests a separate interaction model and routing layer for smaller devices rather than a single adaptive UI.

10. UI composition is shared but layered. Generic UI primitives live under js/ui/* and js/ui/components/*, while product-specific widgets live in js/chat/ui/*, js/fm/*, js/mobile/*, and js/ui/pwm/*. Styling is equally segmented with large CSS bundles for core app, chat, mobile, transfers, password manager, and feature-specific pages.

11. There is a public-transfer/site subsystem separate from the main cloud-drive UI. js/ui/transfer/* contains its own boot, pages, dialogs, overlays, subpages, fonts, and CSS, indicating an independently themed transfer experience with its own navigation and content pages. The html/download.html, html/embedplayer.html, html/planpricing.html, and related files fit the same “public-facing app surface” pattern.

12. The repository also includes specialized product modules that should appear as separate boxes in an architecture diagram:

- Password manager UI under js/ui/pwm/* and css/pwm/*

- S4/object-storage management under js/fm/s4/* and js/utils/s4.js

- Rewind/history features under js/rewind/*

- Document/image viewers and previews via pdf.worker.js, js/ui/docx.viewer.js, js/ui/xlsx.viewer.js, and related HTML/CSS

13. Workers and background helpers are important architectural nodes. Besides encryption/decryption workers, the repo contains pdf.worker.js, worklet.js, worker.sfuClient.bundle.js, worker.recorder.bundle.js, and service-worker support in sw.js. These offload CPU-heavy or asynchronous tasks from the main UI thread.

14. Build, QA, and deployment are client-build oriented. Gruntfile.js, webpack.config.js, karma.conf.js, Makefile, scripts/*, and test/* indicate a build/test pipeline for bundling assets, generating language files, running unit/integration tests, and preparing deployable static outputs. The dont-deploy/ tree contains prototypes and manual test artifacts excluded from production packaging.

15. In infrastructure terms, the app expects to be hosted as static content behind Apache/nginx or MEGA’s own static servers, with routing handled by HTML entry points and client-side code. The README’s local setup instructions and the presence of .htaccess, manifest.json, sw.js, and many versioned asset directories show a deployment model optimized for cached static delivery and browser-side application logic.