Paperlib's manifest says 3.1.6, its newest release says 3.1.12, and its installer is unsigned

The manifest says 3.1.6 and the newest release says 3.1.12

The version number on this repository is stated in three places and they do not agree.

The manifest names the project at version 3.1.6. The release history's newest entry is a tag called release-electron-3.1.12, published in September 2025, after release-electron-3.1.10 from December 2024 and release-electron-3.1.9 from August 2024.

So the source on the default branch describes itself as 3.1.6 while a release two point six versions higher exists. The most likely explanation is mundane: the default branch is named chore/official-sync, which is a maintenance branch rather than a release branch, so the version field there reflects a synchronisation step rather than the shipping line. Anyone reading the manifest to answer what version this is will get the wrong answer, and the only reliable answer is the release tag.

The tag prefix is worth reading too. It is release-electron rather than a bare version, which tells you what the artefact is: an Electron build, published from a repository whose tree holds an electron builder configuration and a directory of per platform build configurations. The number 3.1.11 never appears in the release history, so either that build was never tagged or the tag was removed.

The dates are the other half. The newest release is from September 2025 and the last commit on the default branch is dated 1 April 2026. That ordering is normal for a project whose default branch is not the release branch. It does mean that the gap between the newest release and the newest commit is about six months, and that a reader deciding whether to adopt the project should look at both dates rather than at the tag list alone.

The installer is unsigned and the instructions say to click past the warning

The download section is where this project is most candid about itself, and the honesty is worth having even though the practice is a real risk.

On Windows, the page says you will notice a warning when installing, and gives the reason: there is no code signing in Paperlib because it is so expensive. It then says the source code can be found, that it will not hurt your machine and will never collect personal information, that you should make sure you are using HTTPS and the official webpage or the repository to download the installer, and then gives the specific instruction: in the Windows protected your PC window, click More info and Run anyway.

On macOS the equivalent is to go to the preference pane, Security and Privacy, and run anyway. Linux is handled on a separate page.

So the project's own documentation instructs users to disable the operating system's code integrity check for this application. That is exactly the sequence a user performs when a malware sample arrives, and the difference between the two cases is entirely the provenance of the file, which is why the HTTPS and official source caveats are not incidental wording but the only thing holding the instruction together.

The practical advice follows from that. Verify the download came from the project's site or its repository over HTTPS, not from a search result advertisement or a mirror. If you are installing on a work machine, expect your security team to have an opinion about an unsigned binary that tells users to bypass SmartScreen, and expect the same on managed macOS fleets where Gatekeeper is enforced by policy rather than by a click.

There is a repository entry named SECURITY.md in the tree, which is where a disclosure process would be documented. Its contents are not visible here, and for an unsigned application it is one of the files worth reading before you install.

Every AI feature is an extension, not part of the core

The readme splits its feature list in two, and the split is the most important thing on the page.

The core highlights are: metadata scraping through many scrapers with the ability to write your own, fulltext and advanced search, a smart filter, rating, flagging, tags, folders and markdown or plain text notes, RSS subscription to follow new publications on a topic, locating and downloading PDF files from the web, a macOS spotlight style plugin for copy and pasting references while writing, also supporting Word, cloud sync across macOS, Linux and Windows, a clean interface, and extensibility.

Then there is a separate heading for what you get with extensions: citation counts, summarising papers with language models, automatic tagging with language models, semantic search over your library in natural language, and chatting with a model about your papers.

So the model features are plugins. That is a deliberate and defensible architecture, and it has three consequences. The application ships without them, so a user who wants summarisation has to find or write an extension before they get one. The extension is where your papers and your prompts go, so the trust question is about the extension rather than about the desktop app. And the natural language search example on the page, papers written by a person in a given year, is a query against an index the extension has to build, which means it will be worse than a keyword search over a library of a few hundred papers and better than nothing over ten thousand.

The extensibility is not a hypothetical. The readme links a separate extension development document, and states that you can write your own extensions. The metadata scraper system is described the same way, with the note that you can write your own scrapers, which is the more consequential of the two plugin points because a scraper runs against third party sites.

Five type check targets describe five process boundaries

The scripts in the manifest describe the architecture more clearly than any prose would, because each type check target is one process boundary.

There is a check for the app as a whole, one for the main process, one for the service, one for the extension surface, and one for the renderer, and a combined target that runs all five in sequence. Four of the five use the TypeScript compiler directly with no emit, and the renderer uses a Vue aware checker instead, which is the ordinary consequence of building an interface in a framework whose templates are not plain TypeScript.

So this is a desktop application with a renderer, an Electron main process, a background service, and a plugin interface, each with its own type system boundary and its own configuration. That is a larger structure than a single window with a menu, and it is consistent with the feature list: cloud sync, a system level paste plugin for macOS, an extension system, and a Word integration.

The build targets are shaped the same way. There is one per platform, for macOS on both architectures, for Windows, and for Linux, and a development variant of each, which is eight build targets in total. Every one of them begins by type checking the renderer and then running the build before handing over to the packager, so a type error blocks packaging rather than shipping. The per platform configuration files live in their own directory with a json5 extension, which is a deliberate choice: a configuration format that allows comments and unquoted keys is easier to maintain when a dozen of them differ by a handful of lines.

The manifest is marked private, so nothing here is published to a package registry. There is a lockfile and a package manifest because it is an application that installs dependencies, not a library that others install.

Three changelog files and a server component

Three files in the tree carry release history, and that is one more than a project this size usually maintains.

There is a changelog in English, a changelog in Chinese, and a separate release notes file. Three artefacts describing the same sequence of changes is a maintenance cost, because each has to be updated at the same time as the others, and a divergence between them produces a support question of the worst kind: which one is right.

The two changelogs being in different languages is the obvious explanation. That implies the second language is not a translation produced once but a document written alongside the first, and that a maintainer working alone is keeping three release histories in step. The readme is duplicated the same way, with an English and a Chinese version.

Then there is the directory named for an API. A desktop application with a cloud sync feature and a plugin system has a server component, and the tree holds it separately from the application code. That matters for anyone assessing the trust story of an unsigned desktop app, because part of what runs is not on your machine.

The rest of the tree is ordinary and well chosen. An editor configuration directory, formatter and package manager configuration, a build output directory, static assets, tests, and a single TypeScript configuration at the root that the per area configurations extend. The entry point in the manifest is a compiled main process bundle, which is the normal shape for a packaged Electron application.

The origin is conference papers that have no identifier

The introduction explains the project in a way that explains its whole design, and it is worth reading before deciding whether it is for you.

The author is a computer science doctoral student. In their research community conference papers are the majority, which is different from other disciplines, and without a DOI, an ISBN or usable metadata many conference papers are hard to look up, with two venues named as examples. The consequence they describe is concrete: when citing a publication in a draft, they had to search for the publication's information in a search engine or a bibliography database, over and over again.

The criticism of existing tools has two parts. The first is that good metadata scraping is a core function of a paper management tool and that no software does it well, including commercial software. The second is a modern interface with no extra useless features.

Then the specification, in four steps: import a paper, scrape its metadata as accurately as possible, organise the library simply, and export it when writing.

That order is the product. Metadata first, because in a field where identifiers are missing, the identifier is the thing you have to go and find. Organisation second and deliberately simple. Export last, because the destination is whatever you are writing in. A tool built for a different discipline, where every paper has a DOI and the metadata comes free with it, gets very little from this one.

The RSS subscription and the PDF location features follow from the same premise: if you follow a topic rather than a journal, you need a way to find out what appeared and a way to get the file, since the file is often not where the metadata points.

The readme opens by asking for another maintainer

One line sits above the introduction and it is the first thing on the page: the author is looking for someone to work with on developing the project, and asks interested people to make contact.

That is worth weighing alongside the dates. The last commit on the default branch is dated 1 April 2026, the newest release is from September 2025, and the project is a desktop application with an extension system, per platform build targets, a server component, a website with documentation in two languages, and three changelog files. That is more surface than one person sustains indefinitely.

The page does not say the project is finished, and it is not archived. But the combination of a six month gap since the last commit on the default branch, a personal appeal for a collaborator, and a feature list that includes an extension ecosystem suggests a project where a prospective user should plan for the possibility of slower movement than a commercially backed competitor would offer.

The support signals around it are real but small in scale. Two infrastructure sponsors are named, a content delivery network and a hosting provider, plus a donation link at the bottom of the page. Those reduce the cost of running the project and the website; they do not fund a maintainer.

For an evaluator, the practical questions are narrow. Does the version you want have a build for your platform, and does the extension you need exist or can you write it. Whether the answer to the second question is yes depends on the extension document and on how long the person who would write it stays interested, which is the thing the top of the page is actually about.

Editorial conclusion

Paperlib suits a researcher whose field is dominated by conference papers and who has been copying references out of a search engine by hand. Four things to check before you install it. Where the binary came from, because the project ships no code signature and its own instructions tell Windows and macOS users to click past the operating system warning, which is the same delivery shape malware uses, so get the installer from the project site or the repository over HTTPS and nothing else. What version you are actually running, since the manifest on the default branch and the newest release tag disagree. What the state of the project is, given that the last commit on the default branch is dated 1 April 2026 and the newest release is from September 2025, and the page opens by asking for someone to work with the maintainer. And whether the AI features are what you need, because summaries, tagging, semantic search and chat are all extensions rather than parts of the core, so you are choosing an extension ecosystem as well as an app.

Frequently asked questions

Official sources

1. Future-Scholars/paperlib on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases