Skip to content

Repository files navigation

AWSM — Archive What Should Matter

AWSM is a local-first webpage archival platform with optional zero-knowledge synchronization. It captures, stores, and presents an archive on the user's device; a Coordination Server is optional and receives encrypted data rather than plaintext archive content.

AWSM was created for the OpenAI Devpost hackathon from a concern with conventional clipping services: an archive should not become inaccessible because a provider shuts down, changes direction, or restricts access, and sensitive captures should not require giving a service provider plaintext content.

The implementation is pre-release software. It is not currently available from the Chrome Web Store, and the hosted service is not advertised as a public service.

Download and try AWSM

Download AWSM for Chrome

Download the ready-to-install Chrome ZIP (v0.1.5)

Download its SHA-256 checksum · View the latest Release · Installation guide

The latest Release contains a ready-to-install Chrome ZIP and its SHA-256 checksum. No source build, Account, server, test credentials, or seeded sample data is required to try the core local archive.

  1. Download the Chrome ZIP and matching .sha256 file using the links above.
  2. Verify and install the ZIP using the Chrome extension installation guide.
  3. Open AWSM, select Continue without sync, and create a local Vault.
  4. Open any HTTP or HTTPS page and select Archive this page.

For a guided walkthrough, continue with Try a Capture and Verify offline behavior. To review the hackathon development process, see How OpenAI tools were used.

Supported platform: Chrome 116 or newer on a desktop operating system supported by Chrome. AWSM must be used in a normal Chrome profile; Incognito is not supported. AWSM is not currently packaged or tested as a Firefox, Safari, mobile, or standalone web application.

What works today

The Chrome extension currently supports:

  • local-only setup with no Account or server;
  • webpage capture from active HTTP and HTTPS tabs;
  • immutable Captures containing MHTML, a full-page screenshot, a thumbnail, extracted text, and structured content when each best-effort representation succeeds;
  • an encrypted local Vault backed by browser-local storage;
  • offline Library browsing, screenshot viewing, text and structure inspection, and MHTML download;
  • multiple local Vaults, Vault locking and renaming, Collections, deletion, restoration, and Vault Vacuum;
  • passphrase-protected Complete Vault Export and Import; and
  • optional Account authentication and synchronization of an encrypted Vault Replica through a compatible self-hosted Coordination Server.

MHTML is preserved as the primary Capture Artifact and can be downloaded from the Library. AWSM does not render MHTML inside the Library. The full-page screenshot is previewed in the Capture detail view, while extracted text and structured content can be inspected there.

Search, AI-generated summaries, tags, embeddings, classifications, annotations, and folders are not implemented user-facing features. AWSM already preserves normalized text and document structure as architectural groundwork for future client-side search and derived Artifacts; it does not present those future capabilities as current behavior.

Quick start: local-only Chrome extension

Requirements

  • Chrome 116 or newer
  • Node.js 22
  • Corepack

Use a normal Chrome profile. Do not enable Allow in Incognito for AWSM; Incognito is not a supported storage or capture environment.

Clone the repository, install the pinned dependencies, and build the extension:

git clone https://github.com/parasquid/awsm.git
cd awsm
corepack pnpm install --frozen-lockfile
corepack pnpm build

Load the build in Chrome:

  1. Open chrome://extensions.
  2. Enable Developer mode.
  3. Select Load unpacked.
  4. Choose apps/browser-extension/.output/chrome-mv3.
  5. Pin AWSM from Chrome's Extensions menu.
  6. Open AWSM and select Continue without sync.
  7. Name and create a local Vault.

AWSM is now ready to capture without an Account or Coordination Server. For installation from a GitHub Release, download the latest Chrome ZIP and its SHA-256 checksum. See the Chrome extension installation guide for checksum verification, unpacked installation, upgrades, and troubleshooting.

Try a Capture

No seeded sample data is required. AWSM creates its sample data by capturing a live HTTP or HTTPS page.

  1. Open a webpage in Chrome.
  2. Open the AWSM toolbar popup.
  3. Select Archive this page.
  4. Wait for the Archived: preview card.
  5. Open that card or select Open library.
  6. Open the Capture to view its full-page screenshot and Artifact list.
  7. Select Inspect for extracted text or structured content, or Download for MHTML.

The Devpost demonstration uses this CNN article:

https://edition.cnn.com/2026/07/20/science/pompeii-survivors-docuseries

If that page is unavailable or does not capture reliably, use the equivalent Science News article:

https://www.sciencenews.org/article/pompeii-documentary-tom-hiddleston

These links are demonstration inputs, not repository fixtures, and may change independently of AWSM.

Verify offline behavior

After a successful Capture:

  1. Disconnect Chrome or the machine from the network.
  2. Close or reload the original webpage to confirm it is unavailable.
  3. Open the AWSM Library.
  4. Open the saved Capture.
  5. View and scroll the full-page screenshot.
  6. Inspect the extracted text or structured content.
  7. Download the locally stored MHTML if desired.

Core archive functionality remains available because the Capture and its local Artifacts do not depend on a server. A user who explicitly applies synchronized storage relief can remove local MHTML and screenshot wrappers after AWSM verifies their encrypted server copies. Those remote-only Artifacts require the configured Account and a network connection until retrieved again; compact Library data remains local.

Optional self-hosted synchronization

The local client is the primary application. Synchronization is an optional coordination layer for encrypted data between devices.

Start the development Coordination Server and PostgreSQL with Docker Compose:

docker compose up --build

The server is then available at http://localhost:3000. In AWSM, choose self-hosted synchronization, enter that origin, grant Chrome access to it, and create an Account. See the Coordination Server development guide for operations and troubleshooting.

The client encrypts Vault content before transmission. The server stores opaque encrypted Objects, Events, Artifacts, and wrapped keys; it does not receive the keys needed to decrypt plaintext Vault content. The current pre-release implementation does not include device signing and revocation, Account Recovery Keys, password changes, production quotas, billing, shared object storage, or production deployment hardening.

Development

Use the repository-pinned pnpm through Corepack:

corepack pnpm build
corepack pnpm typecheck
corepack pnpm lint
corepack pnpm test
corepack pnpm test:integration
corepack pnpm test:e2e

Create a distributable Chrome ZIP with:

corepack pnpm zip

The repository is organized as follows:

apps/browser-extension/     Chrome Host, Runtime, local storage, and user interface
apps/coordination-server/   Rails coordination service for opaque encrypted data
docs/architecture/          architectural intent and system boundaries
docs/specifications/        formal formats, protocols, and Runtime contracts
docs/plans/                 approved implementation plans and TDD evidence

Product intent begins in VISION.md. Architectural constraints are defined by the design principles, and canonical terminology is in the glossary.

How OpenAI tools were used

AWSM was developed as a human-directed, AI-assisted project. The product problem, privacy goals, local-first requirements, architectural decisions, and acceptance of the resulting behavior were provided and reviewed by the project author. OpenAI tools supported the work end to end:

  • Planning and design: GPT-5.6 in ChatGPT helped turn the initial product idea into requirements, implementation plans, architecture documents, specifications, threat boundaries, and explicit acceptance criteria.
  • Implementation: Codex implemented the browser extension, local Runtime and storage Drivers, cryptographic workflows, Coordination Server, synchronization protocol, and user-facing flows under the author's direction and review.
  • Testing and debugging: Codex developed unit, browser integration, packaged-extension end-to-end, multi-replica synchronization, failure-injection, and recovery tests; investigated failures; and iterated on implementations until the required behavior was demonstrated.
  • Privacy and consistency review: GPT-5.6 and Codex helped trace changes across architecture, formal contracts, implementation, tests, and operations so that plaintext remained inside trusted clients and superseded pre-release behavior was not retained as compatibility code.
  • Product and UI refinement: Codex iterated on onboarding, capture feedback, Library and Artifact presentation, responsive layouts, accessibility, error states, and rendered visual checks based on author guidance.
  • Delivery: Codex helped build the development environment, packaging and release validation, GitHub Actions CI/CD, installation documentation, and the Devpost demo narrative.

The tools accelerated design, implementation, review, and iteration; they did not replace human product direction or responsibility for the project's decisions and claims.

Design principles

  • Local first: Captures are created, encrypted, stored, and viewed on the client.
  • Cloud optional: A Coordination Server synchronizes encrypted data but is not required for core archive use.
  • Preserve first, interpret later: Original source Artifacts are retained independently from future derived interpretations.
  • Immutable originals: Captures and their authoritative Objects are not edited in place.
  • No plaintext server dependency: The server must not require plaintext user content or unwrapped Vault keys.

AWSM treats a web Capture as one immutable Bundle graph. Its MHTML, screenshot, thumbnail, normalized text, and structured content are independently encrypted Artifacts. This preserves the source while supporting bounded-memory storage, integrity verification, portable Complete Export and Import, and future locally derived capabilities.

Release process

Maintainers publish validated Chrome artifacts from version tags:

  1. Update version in apps/browser-extension/package.json.
  2. Commit and push the change to main.
  3. Create and push the matching v<version> tag.
  4. Wait for the Chrome Extension Release workflow to validate and publish the Release.

Versions ending in -alpha.N, -beta.N, or -rc.N create prereleases. Plain versions create stable Releases. The workflow does not move or overwrite an existing tag or Release.

License

AWSM is free software licensed under the GNU Affero General Public License, version 3 or later. See LICENSE for the complete license text.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages