PaperQuay: an Electron paper workspace that keeps reading, translating and note-taking in one app

The reading workflow PaperQuay is trying to stop you from breaking

The README frames the problem in workflow terms rather than feature terms. Reading a paper usually means Zotero for the library, a PDF viewer for the text, a translation tool for the hard paragraphs, a chat window for summaries, and a separate note app for anything you want to keep. Each hop costs context, and the note you write ends up detached from the page it came from.

PaperQuay's answer is a single Electron desktop application that holds the library, the PDF renderer, the translation layer, the notes editor and an agent workspace. The stated audience is graduate students, researchers and heavy paper readers. Zotero compatibility is deliberately optional: the app can import Zotero collections, tags and PDF attachments, but it does not require Zotero to run.

That positioning has a cost the README does not hide. Everything runs locally, which means the Electron main process, a Node.js backend and a SQLite database all sit on the same machine as your papers. You get control over the data and you pay for it in install weight and in the operational surface you have to keep alive.

How the Electron, React and SQLite layers divide the work

The architecture is stated plainly in the README and matches the repository layout. The React renderer, built with Vite and TypeScript, implements the literature library, the PDF reader, the rich notes, the agent workspace and the settings UI. The Electron main process and a local Node.js backend handle filesystem access, IPC, Zotero import, SQLite persistence, app updates and cross-platform packaging. The package.json confirms this split: the entry point is electron/main.cjs, the dev script is node electron/dev.cjs, and the production path is npm run build followed by node electron/build.cjs.

The rendering and storage choices are visible in the dependency list. PDF rendering uses PDF.js. Rich notes use Tiptap and ProseMirror, with extensions for tables, task lists, mathematics, code blocks and drag handles. Local data uses SQLite through sql.js plus sqlite-vec, which is what makes the local RAG retrieval story possible without a server. Knowledge graph views use cytoscape, and Word export of review documents uses docxtemplater and pizzip.

AI features do not ship with a bundled model. The README says they connect through OpenAI-compatible APIs for translation, paper overviews, agent tool use and RAG retrieval. MinerU is the parsing backend for structured blocks, and the v0.1.24 notes mention that MinerU parsing can point at a configurable API base URL, which is what makes a self-hosted MinerU instance usable.

Block-level translation, MinerU parsing and the local RAG index

The translation design is the most distinctive part of the README. Instead of translating after you select text and waiting on an API round trip, PaperQuay pre-translates MinerU structural blocks so that navigating to a translated block is instant because the translation is already cached. The original PDF stays visible; you move to the translated block on demand rather than reading a two-column layout.

This is a real trade-off, not a free win. Pre-translation means you spend tokens and time before you know which blocks matter, and it only works as advertised if MinerU produces clean structural blocks in the first place. Papers with heavy two-column layouts, scanned pages or unusual math will test that assumption. The README does not document a fallback path for PDFs that MinerU parses badly.

The same parsed blocks feed the local RAG index. Because storage is SQLite with sqlite-vec, retrieval happens against your local library rather than a hosted vector store. The README lists local RAG as a first-class capability alongside translation and overviews, and describes the goal as keeping source text, parsed blocks, translation, notes and overview linked together so that the original wording is not lost behind a translated file.

Installing PaperQuay and running a first paper through it

The README does not give binary download instructions, so the reproducible path is from source. The repository is a Vite project with an Electron shell, and the package.json defines the scripts. Clone the repository, install dependencies, then start the Electron development build, which launches the main process defined in electron/main.cjs.

npm install
npm run dev

If you only want the renderer in a browser for UI work, the package.json exposes a separate Vite server on port 1420 bound to 127.0.0.1. That path does not give you filesystem access, Zotero import or SQLite persistence, because those live in the Electron main process.

npm run web:dev

To produce a packaged desktop build, the build script runs the TypeScript compiler and Vite, then hands off to the Electron packaging script. The README does not document code signing, notarization or a rollback procedure for a failed upgrade.

npm run electron:build

Once the app is running, the README's first-run workflow is the guide to follow: import papers or a Zotero library, open a PDF, and let MinerU parse it into structural blocks. Before translation or overviews will work you need to configure an OpenAI-compatible endpoint and model in settings. The README does not name a default provider, a default model or a default port for that endpoint, so treat the settings screen as the source of truth for the field names your deployment expects.

Where PaperQuay is the wrong tool

Version numbers are the first honest signal. The most recent release listed is app-v0.1.25 from 2026-08-11, and the README badge still shows v0.1.24. This is pre-1.0 software. Anyone who needs a frozen format for a shared lab library, or who cannot absorb a schema or storage change between minor releases, should wait.

The second limitation is the parse dependency. Instant block-level translation rests on MinerU producing usable structural blocks. The README does not describe what happens when parsing fails, and it does not document a manual block editor for correcting a bad parse. If your corpus is mostly scanned PDFs or non-standard layouts, the translation feature may not deliver the experience the README describes.

The third is the local-first model itself. Running Electron plus a Node backend plus SQLite plus sqlite-vec on the same machine as your library is a different operational profile from a web app that keeps state on a server. There is no documented sync or multi-device story in the README, so a shared or roaming library is not something this design targets. And because the app is AGPL-3.0-only, anyone who wants to embed it in a closed product has a licensing question to answer before writing code, not after.

PaperQuay against Zotero with translation plugins

The obvious comparison is Zotero plus a PDF reader plus a translation plugin. Zotero is mature, its plugin ecosystem is large, and it has years of library-format stability behind it. PaperQuay imports Zotero collections, tags and PDF attachments, which tells you the author expects Zotero users to be the main migration path.

The difference in approach is where the intelligence lives. In the Zotero stack, translation and summarization are add-ons that call out to a service and hand results back to the plugin. In PaperQuay, the parsed blocks are the shared substrate: the same MinerU output feeds translation, the local RAG index, overviews and the agent tools. That is a tighter design, and it is also a single point of failure. If the parser is wrong, translation, retrieval and overviews are all wrong together.

A second comparison is a general-purpose chat client with file upload. That approach is simpler and needs no install, but the README's core complaint applies: uploads are one at a time, outputs are not stored in a library, and nothing links a generated summary back to a page position. PaperQuay's bet is that the linking is worth the install.

Licence, release cadence and what an upgrade costs you

PaperQuay is licensed AGPL-3.0-only, and the package.json sets "license": "AGPL-3.0-only". The repository also carries a TRADEMARKS.md file, which is worth reading before you reuse the name or assets. This is a copyleft licence with a network clause, so if you modify PaperQuay and expose it to users over a network, the licence terms apply to your modified version. That is a description of the licence text, not legal advice; if you plan to redistribute or host a modified build, have someone qualified read LICENSE and TRADEMARKS.md.

The upgrade cost is visible in the release history. Tags run app-v0.1.23 on 2026-06-13, app-v0.1.24 on 2026-07-09 and app-v0.1.25 on 2026-08-11, roughly one release per month. The v0.1.24 notes list a library storage migration that moves the existing directory structure and attachment paths into a new location, plus safer note external-update detection. Those are the kinds of changes that touch your data on disk. The README does not document a rollback path for a storage migration, so back up your library folder before upgrading across a release that mentions migration. The app bundles electron-updater, which means updates can arrive through the app itself; the README does not state whether you can pin a version or defer an update.

Editorial conclusion

PaperQuay fits researchers who already run an OpenAI-compatible endpoint or a local MinerU deployment and want reading, translation, notes and library management in one window without handing their PDFs to a hosted service. It is the wrong choice if you want a stable 1.0 tool, if you refuse to run the Electron main process and Node backend on the same machine as your papers, or if your workflow depends on Zotero plugins that PaperQuay does not reproduce. Before adopting it, check the AGPL-3.0-only terms in LICENSE and TRADEMARKS.md, confirm that your endpoint speaks the OpenAI-compatible API the README describes, and decide whether the v0.1.x release cadence, roughly one tag every four to six weeks through mid-2026, matches the pace you need for a tool that touches your library folder.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. WangQrkkk/PaperQuay on GitHub