linXiv started from a fairly specific irritation: as a physics researcher at UW–Madison, my research group ran on a paid Overleaf subscription for compiling papers, managing citations, and real-time collaboration. Overleaf's semi-recent OpenAI partnership got me thinking harder than I had before about who actually holds researchers' data. Academia was the field I knew best, so it was the obvious place to start.
Core Values and the "Secret" Agenda behind linXiv
Core Values
- Privacy when possible.
- Honesty about limitations.
- Owning your own thoughts for as long as you choose.
- Doing what is possible locally, not just what is easy.
- Building intentionally: conveniences have consequences.
The Bet
There's a not-so-hidden agenda behind linXiv, too: we want to build something more useful than the tools researchers already default to.
linXiv's bet is that once people adopt a genuinely good tool, they can start caring about controlling their own data as a side effect, not as the sole sales pitch. Even so, the local-first pitch differs depending on who's asking.
For Universities and Research Groups
Universities get less dependence on cloud services that keep getting less reliable and more intrusive, with terms of service that seem to shift every day.
Research groups are usually aware enough of that to be a little worried about their data, but they're also busy, and switching services every time a privacy policy changes badly isn't realistic; convenience wins more often than people would like to admit.
For Individuals
Individuals get more democratic access (the same tooling regardless of funding) and a workflow that carries over cleanly when they leave an organization, instead of evaporating with an institutional login.
This one's personal for me. I currently collaborate with researchers outside my group, some of them independent, on adjacent problems. We want to work together the way labmates take for granted, but none of us has access to the tools a shared institutional group would hand us.
The Real Roadblocks
The real roadblocks for linXiv to be useful to researchers are local-deployment and adoption: setup has to cost only a handful of "grad student hours."
Because everyone is busy, and professors/post-docs/PhDs especially so, getting to something like a real v1.0 means spending real time up front figuring out what limitations are actually acceptable. This means working directly with at least a few research groups (in different fields of study) and getting it wrong before getting it right.
What is linXiv?
linXiv is a self-hosted academic paper manager, built on a Rust/Tauri backend with a React frontend. Data lives locally in your own SQLite database. It fetches papers and resolves metadata arXiv-natively, and layers on notes, tags, projects, and a knowledge-graph view. A CLI and an MCP server ship alongside the desktop app, all three talking to the same library. Current version is v0.4.1.
In spite of all the motivations and goals of linXiv, the bar linXiv must continue to clear to exist is simply "researchers like using it."
How linXiv compares
What linXiv brings
linXiv adds P2P E2EE sharing on top of a local-first, self-hosted, arXiv-native baseline, with AI and MCP integration designed intentionally to be outbound and malleable rather than baked in. None of this makes linXiv unique piece by piece; most of these ideas exist somewhere else already. What's less common is having all of them designed in together from the start.
A lot of the older tools in this space only get there by stacking plugin on top of plugin on top of plugin. Many of the newer tools aren't built to be customizable, or do not consider privacy/local-first AI workflows. Generally, they are only focused on the fact-gathering stage, rather than a full research stack. Local-first, AI-capable tools aren't especially rare. Malleable, human-first ones still seem to be.
The alternatives
- Local-first and self-hosted.
- A genuinely rich community of users and plugin developers.
- Time-consuming to adopt to your workflow.
- Most complete tool out there.
- Cloud-only, and requires an Elsevier account.
- Mostly unavoidable rather than well-liked: Elsevier's ecosystem is one of the real barriers to getting the same access anywhere else.
- Fetches arXiv natively.
- Cloud-only and tied to Google Drive.
- Local-first, self-hosted, arXiv-native, with AI integration.
- Honestly the closest comparison.
The local-first construction
Every read and write, from every client, goes through one local service layer over to SQLite queries. The GUI, the CLI, and the MCP server are three thin surfaces on top of the same Rust API. None of them require a server, local or otherwise, to be running anywhere.
Sync and sharing are built as an optional layer added on top of a complete, already-functional standalone app, not the other way around. If you never touch the sharing features, linXiv behaves exactly like a local tool, because it is one.
Core data model
The data model separates a paper's abstract identity from any particular fetched copy of it. A Paper Root is the identity; a Paper (Version) is a specific fetched snapshot, since arXiv papers accumulate v1, v2, v3 revisions and you often want to know which one your notes actually refer to.
This is the cleanest difference from most other paper managers I've looked at: arXiv lets a paper get republished multiple times, but linking those versions together is left entirely to you, and arXiv's own API won't even let you search for an old version: a fetch always hands back the newest one. Keeping versions as a first-class part of the data model was the only way I found to actually track the way a paper evolves over time.
Projects hold many-to-many collections of Paper Roots. Notes attach to a Paper Root always, and can optionally pin to a specific version or scope to a specific project. Tags are shared vocabulary across both papers and projects.
Citations are the one piece I would deliberately point out as missing from a minimal construction important to academic papers. However, extracting them consistently and correctly across different fields of study turns out to be quite the non-uniform problem, so it's still an open item rather than a half-done feature bolted in early. The most consistent, lightweight path seems to be arXiv's full source, which is usually rich enough to pull citations out, but it's slow to fetch, and has similar consistency issues, at a lower rate, so it isn't something I want users to lean on by default.
Resolving PDF metadata
Importing a bare PDF (no BibTeX, no known source) runs through a resolution pipeline designed so a partial or wrong record never silently overwrites what the PDF itself says. First, pdfium extracts whatever it can directly from the PDF bytes: title, authors, DOI, arXiv ID, year. If title and authors are both present, that PDF-derived record wins outright: the file's own metadata always takes priority when it's actually there.
From there, linXiv looks for an arXiv ID or DOI in the extracted text. An arXiv ID triggers a direct fetch by ID. A DOI triggers DOI resolution. Neither found, but there's a title, tries a CrossRef title search (CrossRef and OpenAlex are both good, freely available sources for enriching a record once you have enough to search on), and any CrossRef hit is verified before being trusted, requiring a re-fetch and a title match of at least 0.5 Jaccard similarity before it's allowed to attach an identity to the record. If nothing verifies, the fallback is the raw PDF-derived record, partial as it is, rather than a wrong guess.
This whole online-lookup path is also gated behind a setting: turn it off and imports stay PDF-only, no outbound calls at all.
P2P sharing: the stack
Peer-to-peer project sharing is built on four layers, each doing one job. iroh provides QUIC transport: direct peer connections between Ed25519-identified endpoints, with relay servers used only to help peers punch through NATs, not to hold any data. Automerge provides CRDT documents, so a shared project merges edits from both sides instead of one copy overwriting the other. keyhive, from Ink & Switch, provides capability-based access control designed for local-first data. beelay, also from Ink & Switch, is the end-to-end encrypted sync protocol that layers on top of all three: iroh for transport, Automerge for the document, keyhive for who's allowed to see and write what.
Transport and access control
In practice, a share runs over one iroh endpoint exposing three protocols. Plain project shares sync as Automerge documents over a linxiv/sync/0 protocol, read-only for now. End-to-end encrypted shares sync as keyhive-encrypted beelay commits over linxiv/beelay/0. A separate iroh-blobs protocol handles fetching PDF blobs, gated and fetch-only.
Roles inside an E2EE share (Admin, Edit, Read) live in keyhive's capability graph, and revoking a member triggers BeeKEM to rotate keys so new content becomes unreadable to them going forward. The honest caveat: content already synced to a former member before revocation stays readable to them, since there's no way to un-deliver bytes someone already has.
I consider that acceptable, in the same way that retention of physical lab materials has always run on an honor system: people share things with each other and save them to their own machines all the time without asking, and no one really objects. The prudent among us delete what we have afterwards, but it's hard to track. This is something that needs feedback from lab groups. In practice, most of what matters is in people's heads anyway; there's no real mechanism to take that away from someone either, on linXiv or off it.
An invite itself is an iroh ticket plus a signed keyhive delegation; a host-side write check gates plain sync today, with beelay-native delegation enforcement next on the list.
Other integrations
The CLI exposes the same core library as the GUI, nothing held back. BibTeX import and export is there because it matters a lot for people actually switching tools: it's the format Zotero and just about everyone else already builds around, so it makes resolving what paper you're actually looking at close to trivial.
Obsidian export is currently one-way, out of linXiv rather than round-tripping. And for papers resolved via DOI, linXiv can optionally fetch authors' ORCiDs, which helps a lot with author de-duplication across a library: the same person shows up under a different acronym, a full name, a partial name, depending on the source, but their ORCID is always the same.
AI, kept at arm's length
LLMs and modern AI integrated into learning and research is a great example of where "conveniences have consequences"; for that reason, some of linXiv's constraints are deliberate rather than incidental. LLM integrations are kept outbound only: AI will never be integrated into the base app, and it will never be "opt-out."
If you want an LLM in the loop, linXiv was designed to allow this, but if you don't want it, you have nothing to opt out of. Web integrations are likewise avoided outside of arXiv search, trading a bit of friction for forcing users to be intentional about when they reach for AI at all. The MCP server is the main surface for that: it exposes the same tools as the GUI and CLI, this time for an AI agent to call directly.
Search itself runs on two SQLite FTS5 virtual tables (papers_fts over abstracts and ingested full text, notes_fts over note content), merged together for library search. The underlying data model is kept vectorizable and linkable so embeddings-based search is a real option later, but that's explicitly not where I'm spending effort right now: the local-first core product is the priority.
Anecdotally, having full text available has visibly improved how well an LLM can replicate math, equations, and proofs when working with a paper. In one small experiment on a curated database, RAG did outperform plain FTS at reproducing citations, which is a useful data point for when embeddings do get prioritized.
What's shipped, and what's next
Shipped as of today
- Plain project shares
- Two-way sync
- keyhive membership and roles
- beelay E2EE sync, plus encrypted PDF blobs
- Host-side write enforcement
- An encrypted local key store
On the roadmap
- A headless or containerized always-on peer: something a research group can leave running and query over iroh at any time. It's a superset of a self-hosted relay, adding its own access-control design and a live presence/activity feed.
- Real-time collaborative writing. TeamType (peer-to-peer, editor-agnostic collaborative editing of local text files, also built on Automerge and iroh) is already doing a lot of that work, and I'd rather build on it than reinvent it.
- Improving the PDF import pipeline with metadata-hash deduplication.
- An optional OCR plugin for a more genuinely local-first notion of "full text." The caveat: arXiv's own full source is extraordinarily data-rich, it has no true local-first replacement, and local+accurate OCR is slow.
All of this is informed by actually meeting with research groups to understand their collaboration constraints, not guessed at in isolation. Honestly, the PDF pipeline hasn't moved faster mainly because linXiv is still deliberately light, and most of what would meaningfully improve it would 5–10x the size of the packages the app depends on, and that's not a trade I want to make casually.
Thanks
linXiv is built on iroh and Automerge, on Ink & Switch's keyhive and beelay, on arXiv, CrossRef, and OpenAlex, and on SQLite and Tauri.
Special thanks to co-creator Andre Figueroa Kilgore and contributor Matt Riccio for their work in the project's early stages; linXiv wouldn't have gotten this far without them.