Technical documentation

Understand the system.
Keep the boundaries clear.

Rinwa combines a quiet reading surface with local storage, local semantic search, optional AI providers, and operation-log synchronization. This documentation explains what runs where—and what is still in progress.

Current architecture

Local-first · Protocol v1
Primary store
SQLite per device
Local embeddings
ONNX · q8 · 256d
Sync relay
CouchDB operation log
Last reviewed
July 29, 2026
01 System overview

Every device owns a complete reading library.

The cloud is an optional collaborator, not the database of record. Reading, saved content, search, and knowledge begin on the device.

Your device
InterfaceReact reading surfaceDesktop · tablet · phone
→
BoundaryPlatform + RepositoryHTTP today · native SQLite migration
→
Primary storeSQLiteArticles · state · knowledge · indexes
Extraction queueTranslation cacheEmbedding queueEncrypted backup
Optional knowledgeObsidianManaged Markdown sections
Optional intelligenceAI providerOnly after explicit consent
Optional continuityRinwa SyncOperations, never raw SQLite
Transitional boundary

The desktop/web path currently uses the local Node API. Mobile SQLite adapters compile, but the complete reading-path cut-over and real-device verification are not finished.

03 AI runtime

Evidence first, provider second.

AI assistance starts by assembling bounded evidence. A short article can use the whole text; a long article or library question retrieves passages. Paragraph offsets and knowledge records become citation IDs before the provider receives the request.

ArticleHighlightsNotesLibrary search
↓
LOCAL CONTEXT BUILDER Scope → retrieval → token budget → citation IDs
[P] article[H] knowledge[S] library
↓ explicit consent
OpenAIOpenRouterOllamaCustomDeepL
↓
Streamed answercitation validation · retry policy · usage accounting

Provider boundary

Chat uses OpenAI-compatible completions across configured providers. Translation can use DeepL, OpenAI, or a custom endpoint. Without a configured provider, local reading remains intact.

Runtime safeguards

Transient network, rate-limit, and server errors receive bounded retry. Invalid credentials and requests do not. Unknown citation IDs are removed before answers are shown.

Keys and usage

Packaged clients keep keys in OS secure storage. Usage records separate prompt, completion, cached, and reasoning tokens when a provider supplies them.

04 Synchronization

Sync operations, not database files.

Each device remains independently useful. A local change becomes an immutable operation with a device sequence and Hybrid Logical Clock. The server relays operations; clients decide how fields merge.

DEVICE ASQLitelocal writes
operation queue
push→pull←
RINWA SYNCCouchDBimmutable, idempotent operation log
opaque _changes cursor
pull→push←
DEVICE BSQLitelocal writes
field-clock merge
01

Record

deviceId:sequence, entity, action, payload, timestamp, and HLC are persisted locally before upload.

02

Relay

The server validates bounded batches. Duplicate operation IDs become harmless CouchDB conflicts.

03

Merge

Each field applies only when the incoming HLC is newer. Unrelated edits can converge independently.

04

Delete

Tombstones stop an older subscription, note, search, connector, or highlight operation from resurrecting deleted data.

SYNCED

Subscriptions · reading state · preferences · saved searches · connector subscriptions · summaries · notes · tags · references · highlights

DEVICE-LOCAL

Article bodies · media · translations · model files · embeddings · search indexes

Remote vectors are not active

The server can provision Qdrant, but the protocol advertises semanticSearch: false. Current semantic retrieval is local; a configured collection is not a shipped remote-search feature.

05 Data & cache

App versions and content versions are separate.

A visual update, new setting, or gesture fix does not invalidate article data. Extraction, translation, generated summaries, and embeddings each own a compatibility version.

LayerInvalidates whenFailure behavior
Feed contentThe upstream content hash changesKeep current feed copy
Extracted articleExtractor contract and content hash changeKeep last successful article
TranslationPipeline, target language, or source hash changesOriginal remains readable
Generated summarySummary contract, language, or source hash changesManual summary is untouched
EmbeddingsModel, revision, chunk, or vector contract changesSearch falls back to FTS
06 Knowledge surfaces

Your reading can leave the app.

Obsidian

Rinwa manages only clearly marked Markdown sections. User-authored content around them remains intact, and edits made in the Vault return to Rinwa.

Local MCP

Read tools are available locally. Adding subscriptions, changing state, saving notes, creating highlights, or exporting to Obsidian requires an explicit write token.

07 Platform architecture

One interface, native boundaries.

React and Vite provide the shared reading surface. Tauri 2 packages it for desktop and mobile. Components do not branch directly on macOS, Windows, iOS, or Android; native capabilities stay behind the platform adapter.

Shared UIReact · responsive reading · gestures · knowledge
↓
Platform adaptertransport · files · links · clipboard · secure storage
↓
macOSWindowsiOS / iPadOSAndroid
08 Capability status

Implemented is not the same as released.

Working in current source

Local SQLite on the current desktop/API path, extraction queues, inline translation, local embeddings, hybrid retrieval, citations, knowledge tools, operation-log sync, backups, and shared responsive UI.

Preview / transitional

Android shared UI package, mobile SQLite repository, native secure storage migration, and the Rinwa public brand transition.

Requires platform validation

Mobile database population, background refresh, Android Keystore verification, iOS and Windows packaging, signing, notarization, and store review.

Need implementation-level detail?

Read the source on GitHub ↗