Paprism

Main Concept
Select categoty
MainPage
ViewPages
ViewPages with graph display
Ask function you can ask anything you want

Inspiration

Research papers contain some of the most important ideas being produced today, but discovering and reading them still feels unnecessarily difficult. Traditional paper databases are powerful, yet they often assume that users already know exactly what they are looking for. On the other side, modern content feeds make discovery effortless, but they are optimized for passive consumption rather than serious learning.

Paprism started from a simple question: what would a research discovery experience look like if it were as natural to browse as a modern content feed, without reducing papers to disposable content?

The name combines paper and prism. A paper enters the prism as a dense academic document and is refracted into multiple ways of understanding it: metadata, summaries, translation, questions, saved references, and the complete original text.

What it does

Paprism is a mobile-first research discovery and reading application built around a vertical, swipeable paper feed.

Users can:

Browse newly published research through a focused, full-screen feed.
Filter papers by research category.
Open a native reading view instead of switching between external browser tabs.
Translate papers in structured blocks while preserving the original document.
Ask questions about selected passages and inspect difficult sections more closely.
Save papers into a local library.
Review reading history.
Download reader-friendly offline copies and PDF files.
Use their own OpenAI-compatible API credentials.
Use the application without creating an account or sending personal library data to an application backend.

Paprism is designed to make the first step into a paper easier while keeping the complete paper available. It does not try to replace the source material with an AI summary. The feed helps users discover; the reader helps them investigate.

How we built it

Paprism is built with React Native, Expo, TypeScript, and Bun. A shared codebase handles the mobile interface, paper discovery, local storage, document rendering, translation orchestration, downloads, and library management.

The application communicates directly with arXiv to retrieve paper metadata and documents. There is no Paprism application server between the user and the source. Saved papers, history, preferences, translation state, and downloaded content are stored locally on the device.

The main product flow is divided into several feature-oriented modules:

A feed system handles pagination, deduplication, category changes, prefetching, and swipe navigation.
A document pipeline converts papers into structured blocks that can be rendered natively.
A translation pipeline divides documents into stable block identifiers, sends controlled batches to an OpenAI-compatible model, validates the structured response, caches completed work, and restores progress when possible.
A local library tracks saved papers, history, offline reading packages, and PDF metadata.
A provider system stores API credentials securely on the device.
A durable state queue serializes important storage mutations so that an operation is only reported as complete after it has actually been persisted.

The interface was designed specifically for mobile reading. Paprism uses a dark, editorial visual language and combines modern product UI with the idea of a paper being refracted into clearer layers of information.

Challenges we ran into

One of the hardest challenges was making a swipe-based interface coexist with long academic abstracts and full documents. A gesture may begin inside scrollable text but eventually become an attempt to move to the next paper. Handling that interaction consistently required careful coordination between the internal scroll position, page boundaries, and the outer feed gesture.

Translation introduced another set of problems. Large papers cannot be sent as one uncontrolled prompt. We needed to split documents into identifiable blocks, preserve ordering, reject malformed or duplicated model output, recover from partial failures, and avoid applying an old response to a newer reading session.

Local-first storage also became more complicated than expected. A simple optimistic UI update can claim that a paper was saved even when the device write later fails. We built a durable mutation queue so concurrent operations are serialized and state is only committed after successful persistence. We also added partial recovery during startup so one corrupted local dataset does not prevent the entire application from opening.

Offline documents and PDF downloads required separate lifecycle handling. Downloads can be cancelled, metadata persistence can fail after a file has already been exported, and two simultaneous tasks must not overwrite each other’s state. We introduced an explicit single-task model and task ownership rules to prevent invalid combinations.

Finally, keeping a rapidly developed AI-assisted codebase maintainable was itself a challenge. We repeatedly reviewed abstractions, removed misleading asynchronous contracts, added tests around failure scenarios, and introduced CI checks for formatting, linting, type safety, tests, and Expo configuration.

Accomplishments that we're proud of

We are proud that Paprism has moved beyond a visual prototype into a working, locally installable application with a complete discovery-to-reading workflow.

Several technical accomplishments were particularly important:

Building a swipeable research feed that still supports normal long-form reading interactions.
Rendering structured paper content natively rather than relying entirely on an embedded webpage.
Supporting resumable, block-level translation with strict response validation.
Keeping user credentials, reading history, saved papers, and downloads local to the device.
Providing useful AI features without requiring a Paprism account or application backend.
Designing storage operations with durable completion semantics instead of fire-and-forget writes.
Recovering gracefully when individual local datasets fail to load.
Automating Android testing, validation, multi-architecture builds, and GitHub releases.
Developing a distinct identity for research software rather than presenting Paprism as another generic AI chat interface.

The project is also fully open source, allowing others to inspect how the feed, reader, model integration, local persistence, and release process work.

What we learned

We learned that improving access to research is not mainly a summarization problem. It is an interaction-design problem.

Users need different levels of engagement at different moments. Sometimes they want to quickly decide whether a paper is relevant. Sometimes they need a translated paragraph. Sometimes they want the complete document, figures, metadata, or an answer tied to a selected passage. A useful research tool must support movement between these levels without hiding the original source.

We also learned that local-first applications still require serious data engineering. Removing a backend simplifies privacy and deployment, but it moves responsibility for migrations, recovery, concurrency, file ownership, and persistence consistency onto the client.

Working with model-generated structured output reinforced the importance of treating AI responses as untrusted data. Prompts alone are not contracts. Responses must be parsed, validated, checked for missing and duplicate identifiers, and associated with the correct active session.

Finally, we learned that AI-assisted development works best when the model is used to accelerate implementation while architectural decisions remain explicit. The largest improvements came not from adding more abstraction, but from reducing invalid states and defining clearer contracts between modules.

What's next for Paprism

The next major milestone is full iOS support and TestFlight distribution. The current application is focused on Android, so the download, file-sharing, signing, and release flows need to be adapted to Apple’s platform conventions.

We also plan to:

Improve paper recommendations without introducing invasive user profiling.
Add more precise passage-level questions and citations.
Refine the translation and reading experience for long mathematical documents.
Add better offline asset and figure support.
Introduce stronger local-data reconciliation and recovery tools.
Simplify the largest reader components as more functionality is added.
Expand accessibility, tablet layouts, and platform-specific interaction polish.
Continue improving the project’s automated tests and release pipeline.

The long-term goal is not to maximize time spent inside another feed. It is to create a better entry point into serious ideas—and make it easier for users to move from discovery to genuine understanding.