Home

About MemoryFile

Technical overview, security model, and current capabilities

Architecture

A MemoryFile is a single HTML file that bundles:

  1. HTML UI for the interface
  2. CSS styles for presentation
  3. JavaScript app code for logic
  4. SQLite WASM runtime for the database engine
  5. Embedded database as base64, optionally encrypted
  6. Trust + commit metadata for verification and history

On load, the browser decodes the embedded database, decrypts it if needed, and initializes SQLite in memory. On save, the database is exported, encrypted if enabled, and the HTML file is rebuilt with updated data. Saved files inline the SQLite WASM loader when available so the export is fully standalone.

File lifecycle

1. User opens myapp.html
2. Browser loads and parses HTML
3. JavaScript decodes (and decrypts) database
4. SQLite WASM initializes in memory
5. User interacts, modifies data
6. App exports database to binary
7. JavaScript encrypts (optional) and base64-encodes
8. JavaScript rebuilds HTML with new data
9. File System API saves in place or downloads a copy

Trust and verification

Content-addressed filenames include a hash of the file contents.

Example: contract.a1b2c3.html

The hash is derived from SHA-256 of the entire file. Change one byte and the hash changes. This makes tampering visible.

How files verify themselves

  1. Read the filename and extract the hash
  2. Hash the current file contents
  3. Compare expected vs actual hash
  4. Show VERIFIED or TAMPERED badge

This is self-verification, not external verification. An attacker who modifies both code and content can bypass checks, so social context and expected filenames still matter.

Security model

Protected by default

Not protected

See SECURITY.md for full details on encryption, CSP requirements, and threat model guidance.

Browser compatibility

Environment JS execution Save in place Export Notes
Desktop Chrome/Edge (http/https) Yes Yes Yes File System Access API
Desktop Firefox/Safari (http/https) Yes No Yes Downloads a new copy
iOS Safari/Chrome opened from Files No No No Quick Look blocks JS
Android Chrome opened from Downloads Yes No Limited External files may not load
Mobile browsers (http/https) Yes No Yes Use export/share

Performance and limits

See docs/LIMITS.md and run tests/limits-runner.html on your hardware for concrete limits.

Use cases

For developers

For end users

Comparison to alternatives

LocalStorage is browser-specific. MemoryFile is portable.

IndexedDB is performant but domain-locked. MemoryFile is SQL and shareable.

Server + database requires hosting. MemoryFile runs offline.

TiddlyWiki stores JSON. MemoryFile stores SQL.

SQLite files need a separate app. MemoryFile bundles UI + data.

Embedded vs OPFS

MemoryFile focuses on embedded, portable HTML exports. SQLite WASM supports OPFS for higher performance, and the core library exposes detection, but the shipped examples are embedded-first. A common pattern is OPFS for daily work and embedded exports for sharing or backup.

Testing

Open test/index.html for the full browser test runner. Targeted runners live under tests/, including limits, trust, encryption, and inline WASM coverage.

Future possibilities