Developer Docs on Mol* Linker Wiki

Architecture & Execution Flow

Mon, 01 Jan 0001 00:00:00 +0000

Core Philosophy#

Mol* Linker operates across several strict security boundaries imposed by the browser. Modern browsers enforce Content Security Policies (CSP) that block unsafe-eval in Manifest V3 extension pages, and restrict cross-origin requests (CORS) between websites and external servers.

To load multi-megabyte structural files from dynamic Single Page Applications (GitHub, GitLab, RCSB) into a high-performance WebGL visualizer (Mol*), the extension uses a 4-Layer Architecture where each layer has one clearly defined responsibility.

Contributing & Build System

Mon, 01 Jan 0001 00:00:00 +0000

Development Workflow#

Mol* Linker is written in TypeScript and uses a two-stage build pipeline:

Type checking — tsc --noEmit validates the entire codebase against strict TypeScript rules without producing any output files.
Bundling — esbuild takes each entry-point module and bundles it with all its dependencies into a single, self-contained JavaScript file per page.
Assembly — assemble.js copies the bundled JS, static HTML/CSS, icons, and the correct browser manifest into a browser-specific output folder.

This separation means the TypeScript compiler is a pure quality gate, and esbuild handles the actual output — giving you both type safety and fast, modern output with zero runtime overhead.

Module Reference

Mon, 01 Jan 0001 00:00:00 +0000

All source files live in src/ and are written in TypeScript. Each entry-point module is compiled by esbuild into a single self-contained .js file in dist/. Shared modules (types, config, permissions, mvs-builder) are not separate output files — they are bundled into whichever entry points import them.

Shared Modules#

`src/types.ts`#

Defines all shared TypeScript interfaces and the inter-context message protocol. This is the single source of truth for data shapes across the entire codebase.

Security

Mon, 01 Jan 0001 00:00:00 +0000

Security & Threat Mitigation#

Browser extensions that handle cross-origin data and execute complex rendering engines are frequent targets for security audits. Mol* Linker employs a strict Defense-in-Depth strategy to protect user privacy, prevent malicious payload execution, and secure local networks.

Here is a breakdown of the active security layers within the extension.

1. Zero-Upload Data Privacy#

The most significant security feature of Mol* Linker is its local-only architecture. When a user visualizes a proprietary, unreleased structure from a private GitLab or ElabFTW instance, the file is never uploaded to an external server. - Data is fetched directly from the authenticated host server into the browser’s volatile memory (RAM).

Developer Docs on Mol* Linker Wiki

Architecture & Execution Flow

Core Philosophy#

Contributing & Build System

Development Workflow#

Module Reference

Shared Modules#

src/types.ts#

Security

Security & Threat Mitigation#

1. Zero-Upload Data Privacy#

`src/types.ts`#