This is the first in a series of posts about Chive, a decentralized eprint service built on AT Protocol. Future posts will cover the knowledge graph, collections, open review, and discovery and citations in detail. You can follow the project on Bluesky at .
This post describes Chive v0.1.0. Details may change as the project develops.
The challenge
Scholarly identity is spread across many platforms. Preprints are on arXiv, reviews are on editorial platforms or OpenReview, reading lists are in Zotero or Mendeley, code (and maybe data) are on GitHub, and your citation record is assembled by services that each hold their own copy of it.
There has been significant work on making these records portable and interoperable. ORCID provides a persistent identifier that follows researchers across institutions, tracking works, peer review activity, funding, and employment in one place. arXiv has reliably hosted open-access preprints for over 30 years. Semantic Scholar and OpenAlex have built large-scale open indexes over the literature, with Semantic Scholar offering AI-powered recommendations and research feeds and OpenAlex cataloging over 470 million works under a CC0 license. Persistent identifier systems like DOIs, ROR, and ORCID link records across services. These systems interoperate: publishers deposit peer review metadata to ORCID, Zenodo records link to arXiv preprints via DOIs, and OpenAlex pulls from Crossref, ORCID, and institutional repositories.
What these systems exchange, though, is metadata about your scholarly activity rather than the activity itself. ORCID knows you reviewed for a journal, but the review text lives on the publisher’s site. OpenAlex indexes your publications, but your reading lists and annotations are locked to whatever tool you use to manage them. The persistent identifiers and metadata standards that the scholarly infrastructure community has built are good at tracking references to your work. What’s missing is a protocol for owning the work and commentary as portable data: the review itself, not just the fact that you reviewed; or the reading list itself, not just the papers in it.
AT Protocol offers a different model: users own their data and applications are views over that data. Bluesky demonstrated this for social networking, and scientists were among the earliest to move there in large numbers. A growing ATProto Science community is now exploring how the protocol can serve research communication more broadly, with the ATScience 2026 workshop bringing together developers and researchers in Vancouver this March.
Several scholarly tools are already being built on the protocol: Semble lets researchers curate and share knowledge collections; Leaflet and WhiteWind provides long-form blogging; Lanyards builds researcher profiles; Margin.at supports social bookmarking and annotation; and newer projects like Frontpage (link aggregation) are extending the ecosystem further.
Chive applies the same model to scholarly communication specifically: your papers, reviews, and collections live in infrastructure you control, and any number of services can index and display them.
How Chive is different from other eprint services
Chive is an AppView on AT Protocol, the same open protocol that powers Bluesky. When you submit a paper to Chive, the record is created in your Personal Data Server (PDS), not just in Chive’s database. Chive reads from the AT Protocol firehose, filters for Chive records, and builds a searchable index over them. The same is true for reviews, endorsements, collections, and your profile. All of it lives in your PDS.
The consequence is that the index is disposable. If Chive’s entire database were deleted tomorrow, your records would still be in your PDS. Another indexer could replay the firehose and reconstruct the same view. This is the core guarantee of AT Protocol applications: you can always leave, and you never have to ask permission to take your data with you, because it was never in someone else’s hands to begin with.
What goes into an eprint
When you submit a paper, the client creates a record in your PDS containing the paper’s metadata (title, abstract, author list, keywords, license, field classifications, and external resources, like code and data repositories) along with a reference to the document file stored in your PDS. Chive never holds your eprint; it's always on your PDS.
The metadata is more structured than what most preprint servers capture. Affiliations use ROR identifiers, so there’s no ambiguity about which institution you mean. Contributions follow the CRediT taxonomy with degree annotations (lead, equal, supporting), which means the record captures who designed the experiments versus who wrote the code versus who drafted the paper. Licenses and field classifications are selected from the knowledge graph (which we describe in a subsequent post).
Chive accepts 10 document formats, from PDF and LaTeX to Jupyter notebooks and DOCX. Papers can be revised, and each version preserves the full history with changelogs. Eprints can also link to supplementary materials: code on GitHub or GitLab, datasets on Zenodo or Figshare, archives on Software Heritage, and models on Hugging Face. This keeps the paper and its artifacts connected in one record.
The knowledge graph
The Chive knowledge graph is the connective tissue of the entire system. Fields, licenses, institutions, contribution types, annotation motivations, document formats, and conference venues are all nodes in the graph. When you classify your paper under formal semantics or select a Creative Commons license, you’re picking a node. When you endorse a paper’s methodology, the endorsement type is a node. When you annotate a passage with a questioning motivation, that motivation is a node. Every structured choice a researcher makes in Chive is a connection to the graph, and the graph connects all of those choices to each other (as well as to external knowledge graphs and other resources).
The nodes are linked by typed edges (broader, narrower, related) with types that themselves are nodes in the graph, so the full taxonomy is traversable: you can navigate from a specific topic up to its parent field and across to related areas.
The graph is governed Wikipedia-style. Researchers propose new nodes or edges, the community discusses and votes, and trusted editors approve or reject. Because the vocabulary lives in the graph rather than in a hardcoded schema, the system can accommodate new fields and classification schemes without code changes. We describe the governance model and the graph’s structure in a subsequent post, and the technical schema is in a separate deep dive.
Richer rich text
An enriched version of Bluesky's rich text is the primary interface between human-written prose and the knowledge graph. An abstract can include formatting, inline LaTeX math, and typed references to Wikidata entities, knowledge graph nodes, other eprints, and authors. When you mention computational linguistics in your abstract, that becomes a queryable link in the knowledge graph. You can find all papers whose abstracts reference a given concept, trace how a term’s usage evolves across the literature, or discover connections between papers that cite the same entities in their text.
The same rich text system is used in reviews and annotations. Every review that references a methodology, every annotation that links to a dataset adds structured connections to the graph. Over time, the community’s everyday scholarly activity builds a web of typed references across the entire literature. A client that doesn’t understand the structured types can fall back to the plain text version, so nothing breaks. We cover how rich text works for reviews in a later post, and the implementation is in a separate deep dive.
Finding papers
Chive provides full-text search with field boosting (titles are weighted more heavily than body text), filtering by field, author, and date range, and shareable search URLs.
There’s also a browse mode built on the knowledge graph. Instead of typing a query, you navigate faceted categories that the community defines: methodology, time period, geographic region, or whatever other dimensions turn out to be useful. Because the facets come from the knowledge graph (not just the facet values; the facets themselves!) rather than a hardcoded list, researchers in a given field can organize their own corner of the taxonomy without waiting for a platform decision.
The rich text references in abstracts and reviews also feed into search: a paper that mentions a concept inline is discoverable through that concept, even if it isn’t listed in the paper’s keywords. Users can also tag papers with their own labels, and trending tags surface what the community is currently paying attention to.
Importing existing work
Most researchers already have papers elsewhere, and we don’t expect anyone to start from scratch. Chive currently lets you search arXiv, OpenReview, PsyArXiv, LingBuzz, and the Semantics Archive directly from the submission form. You pick a paper, the form is prefilled with its metadata, and the record is created in your PDS. Chive additionally provides a plugin system for extending the external repositories eprints can be imported from.
Chive can also suggest papers to claim. Given your name, name variants, ORCID, or affiliations, it searches external databases and returns candidate matches ranked by confidence, which you can review and import in batch. If a paper is already on Chive in another author’s PDS, you can request co-author status. The PDS owner approves or rejects the request, and Chive never writes to anyone’s PDS directly.
Author profiles
Your Chive profile extends your Bluesky identity with academic metadata: ORCID, institutional affiliations via ROR identifiers, research fields, keywords, and name variants for paper matching. Chive can discover your external authority IDs automatically by searching Semantic Scholar, OpenAlex, and DBLP for matching author profiles, so you don’t have to re-enter information that already exists in those systems.
Reviews
Reviews in Chive are currently public and tied to your Bluesky identity, though we may support anonymous review in the future. The main design goals are threaded discussion, passage-level anchoring using W3C Web Annotation selectors, and giving authors a single place to see and respond to all feedback on their work. Because reviews live in the reviewer’s PDS, reviewers keep control of what they’ve written. They can reference their reviews from their profile, build a track record over time, and take that record with them if they move to a different service. We go into this in detail in a later post.
Annotations
Chive supports span-level annotation of eprints. These span-level annotations support both direct links to the Chive knowledge graph or Wikidata as well as rich text comments about a particular passage. You can select a sentence in a PDF and link it to its Wikidata entity, connecting that paper to everything Wikidata knows about the concept. Or you can select a passage and leave a rich text comment that itself references other eprints, authors, or knowledge graph nodes. Annotations use W3C Web Annotation selectors to anchor to text, so they survive minor edits when the author revises the paper. Like reviews, annotations are stored in your PDS, support threading, and are indexed into the knowledge graph. We go into the details in the open review post.
Endorsements
Separate from reviews, there’s a formal endorsement system. Rather than writing a review, you can make a structured assertion about a specific aspect of a paper’s contribution: its methodology, its empirical rigor, its reproducibility, its data, or any of 11 other types loosely based on CRediT. Each endorsement type is a knowledge graph node, which means the vocabulary for evaluating research is community-governed and extensible through the same proposal process as fields and licenses. Over time, a paper accumulates a profile of what other researchers consider its strengths, and those endorsements are queryable across the entire platform.
How it fits into the ecosystem
Because Chive shares an identity system with Bluesky, it sees activity across the ATProto ecosystem. When someone adds your eprint to a Semble collection, cites it in a WhiteWind blog post, or embeds it in a Leaflet article, Chive picks that up from the firehose and creates a backlink. You can see where your work is being discussed without anyone building a custom integration. The interoperability comes from the protocol itself.
This is worth emphasizing because it's the part that traditional scholarly infrastructure doesn't do. arXiv doesn't know that someone discussed your paper on Bluesky unless it builds a Bluesky integration. Chive knows automatically, because ATProto applications share a data layer. As more scholarly tools are built on the protocol, the network of cross-references grows without any coordination between the developers.
Chive also has a built-in composer for sharing to Bluesky with mention autocomplete and social card previews, and it notifies you when someone reviews or endorses your work or when co-authorship requests need your approval.
Current status
The alpha has been running since early 2026. We’re looking for researchers to try it and give feedback. You can sign-up to be an alpha tester at chive.pub and folow for updates!
In this series: What Chive is · The knowledge graph · Collections · Open review · Discovery and citations
Technical deep dives: XRPC adapter · Lexicon namespace · Rich text · Firehose · Storage · Knowledge graph schema · Review system · Citations · Discovery · Plugins · Auth · Observability