# PaperQuay keeps translation caches and notes in one SQLite library

> An Electron desktop application for reading papers that treats translation, note-taking, structured overviews and library management as one workflow rather than four tabs. The architecture is deliberately local first, with SQLite in the main process, a rich-text editor built on a mature editor framework, and model access through any OpenAI-compatible endpoint. What is worth reading closely is the licence, which is the copyleft variant with an explicit only suffix and a network clause, and the scale of the dependency surface behind a 0.1 release.

**WangQrkkk/PaperQuay** — A desktop-first literature manager for PDF reading, translation, paper overviews, and AI agent workflows.

- Repository: https://github.com/WangQrkkk/PaperQuay
- Website: https://github.com/WangQrkkk/PaperQuay
- Stars: 306 · Forks: 37
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-09-14 · Updated: 2026-09-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/wangqrkkk-paperquay

## Translation is pre-computed per parsed block, not per click

One design decision does most of the work in this application, and it is about timing rather than quality. The parser produces structured blocks for a paper, and the application can translate and cache each of those blocks in advance. When you are reading, clicking a block in the source jumps to its already-translated counterpart instead of triggering a request and waiting. Everything else in the feature list follows from taking that latency seriously: the original text stays on screen rather than being replaced by two columns, the source, the parsed block, the translation, your notes and the generated overview stay linked to each other, and the parser's base URL is configurable so a local deployment of it can be used instead of a hosted one. The trade is up front. Nothing is translated until you ask for it to be, so the first pass over a paper is slower than a tool that translates on demand, and the cache is a per-paper cost you pay before the reading session rather than during it.

## Notes are a rich-text document, not a tagged string

The notes workspace is built on a mature editor framework rather than a text field, and the extension list in the package metadata is the most honest description of what that buys you: nineteen separately versioned extension packages at the same version, covering headings, lists, task lists, code blocks with syntax highlighting, tables with their three cell-level pieces, images, links, highlights, mathematics, a placeholder, a character counter, a drag handle, a suggestion mechanism and the starter kit, plus the underlying editor packages and a low-level grammar and state manager. Each note is stored three ways, as editor document structure, as rendered HTML and as searchable plain text, which is why full-text search works across notes without re-rendering. The research-specific layer is small and specific: wiki-style note links, hashtag tags, an at-sign reference to a library paper, backlinks, an outline, folders, and pin and favourite states, with autosave.

## The copyleft choice is explicit in the package metadata

The licence is stated three times and all three agree, which is more than most projects manage. The repository metadata reports the GNU Affero General Public License, the readme's tree contains a licence file and a separate trademarks file, and the package manifest declares it as the Affero variant with an only suffix rather than the bare name or the or-later variant. That distinction matters more than it looks. The network clause is the part that bites: if you run a modified version of this software as a service for other people, you owe them the corresponding source of your modifications. For a desktop research application that clause rarely triggers, because you are not offering it to anyone else. For anyone who takes the library half, or the agent tooling, and builds a hosted product on it, the clause is the whole conversation. The presence of a separate trademarks file alongside it is also a deliberate choice, since it means the name is not granted as part of the code grant.

## Everything model-shaped goes to an endpoint you choose

The architectural paragraph is unusually clear about what runs where, and the division is the thing to understand before you install it. The renderer implements the library, the reader, the notes, the agent workspace and the settings. The main process and a local Node backend handle filesystem access, inter-process messaging, reference-manager import, SQLite persistence, application updates and packaging. The renderer never touches the disk directly, which is the correct shape for an Electron application and means the security boundary is the message channel. But every model-shaped feature is a network call: translation, paper overviews, agent tool use and retrieval all connect through an OpenAI-compatible API. The readme frames that as a feature, since bringing your own endpoint, model and runtime parameters is presented as the answer to model lock-in. The corollary is that local-first describes where your library lives, not where your prompts go.

## Word export is the hard part and it shows in the release notes

The most recent update section is the best place to see what actually breaks. The newest release the readme describes focuses on review writing, knowledge-graph usability, parser configuration, library storage migration and note synchronisation. Within that, the word-export item is the substantive one: it now handles mathematical formulas, missing figures, localised section titles, richer references and inline figure placement coming out of model output. Each of those is a specific failure mode of going from a generated review to a document a journal will accept. The formulas point at two dependencies doing a conversion nobody wants to write themselves, one that translates mathematical markup into the office format's equation markup and one that rewrites document templates with a zip library. That is a well-known way to produce broken documents, and the fact that the release note lists these as recent fixes rather than features tells you how much of it is unsolved.

## A dependency list that reads like an application, not a library

Count the shape of the manifest rather than its contents. Nineteen editor extension packages, several of which are three-letter versions of the same thing for table cells and headers and rows. A graph layout library for the knowledge-graph view. An XML parser and two zip libraries, one of them a reimplementation, for document generation. An application auto-updater. A server-sent-events parser, which is how the agent streams its output. A WebAssembly build of SQLite plus a vector-search extension for the same database, so the library and the retrieval index live in one file. A syntax-highlighting engine. And a maths converter. That is a desktop application with a document pipeline, an editor, a graph view and a retrieval stack, all in one dependency list, in a project whose manifest version is zero point one point twenty-five and which is marked private so nothing is published to a registry.

## Two dev scripts run the same command and one port is not the default

The scripts section has a small redundancy and one useful detail. The development command and a second alias for it are byte-identical, both invoking the same Electron development helper, so one of the two names is a leftover from a rename. The web-only development command is the interesting one: it runs the bundler in development mode bound to loopback on port fourteen-twenty, which is not the bundler's default, so the renderer can be exercised in a browser without the desktop shell. The preview command uses another non-default port on loopback. The build is a type check followed by a bundle, and the desktop build runs that build and then a separate packaging step. So there are four distinct local states: renderer in a browser, renderer inside the shell, a production bundle preview, and a packaged application, and the ports for the first two are deliberately not the ones a developer would guess.

## Twenty-five patch releases in three months, and no stable version

The release history says something about the project's shape. Three of the most recent tags are patch-level application releases, twenty-three, twenty-four and twenty-five, spread across June, July and August of 2026, each tagged with an application prefix so they sit in their own namespace. The repository was pushed to in early September. The manifest version matches the newest tag, which is a good sign about release discipline. What it does not tell you is whether any of it is stable, because the version line has never left the zero point one range and there is no channel described. For a research tool that stores your library and your notes, that is a reasonable trade: the format of a note file and the shape of the SQLite schema can both move between patch releases, and there is no migration guarantee stated anywhere in the readme. If your library matters, keep the originals rather than the attachments alone, and check the storage migration note, since one of the recent releases moved the library directory structure and migrated attachment paths.

## Conclusion

PaperQuay fits a researcher who reads in long sessions and is tired of switching between a reference manager, a reader, a translation tool and a note application, and who is willing to keep their library on their own disk. It does not fit anyone who needs to modify it and ship the result under a permissive licence, because the project is copyleft with a network clause and the package metadata pins that choice explicitly. Before you adopt it, check the licence against your institution's policy, and check the data boundary: translation, overviews, agent tools and retrieval all leave your machine to whichever endpoint you configure, so the local-first claim covers your library and not your prompts.

## FAQ

### What is PaperQuay?

It is a local-first, open-source desktop application for reading papers, combining a PDF reader, block-level translation, structured overviews, inline notes, a Zotero import, agent-assisted library management and local retrieval. It is built as an Electron shell with a React and TypeScript renderer and a local Node backend.

### How does PaperQuay handle translation latency?

By caching ahead of reading. It parses the paper into structural blocks and can translate and cache them in advance, so clicking a block in the source jumps to its already-translated counterpart instead of waiting for a request. The original text stays visible and the translation is navigated to on demand.

### What licence is PaperQuay released under?

The GNU Affero General Public License with an explicit only suffix, declared that way in the package manifest. The repository also carries a separate trademarks file, so the name is not granted as part of the code. The network clause matters if you run a modified version as a service for others.

### Does PaperQuay send my data to a model provider?

Yes, for the model-shaped features. Translation, paper overviews, agent tool use and retrieval all connect through an OpenAI-compatible API that you configure, which the readme presents as the alternative to model lock-in. What stays local is your library: the renderer never touches the filesystem directly and persistence is handled by a local backend using SQLite.

### Do I need Zotero to use PaperQuay?

No. The readme states Zotero compatibility is optional rather than mandatory, and the comparison table frames the alternative as importing collections, tags and PDF attachments as an optional source rather than staying locked in one tool or rebuilding a library by hand.

## Sources

- [License: AGPL-3.0](https://github.com/WangQrkkk/PaperQuay/blob/main/LICENSE)
- [Project website](https://github.com/WangQrkkk/PaperQuay)
- [README](https://github.com/WangQrkkk/PaperQuay/blob/main/README.md)
- [Releases](https://github.com/WangQrkkk/PaperQuay/releases)
- [WangQrkkk/PaperQuay on GitHub](https://github.com/WangQrkkk/PaperQuay)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wangqrkkk-paperquay