Meet Origo Source
An open contract between independent content services and reading apps, built on ORSP.
Auf dieser Seite
Content that connects to readers
Origo Source, called 元源 in Chinese, connects independent books, articles and serial chapters to reading apps through HTTP(S). You keep your content and storage. The reader handles layout, interaction and reading positions. A publishing service such as Yuanchuang can distribute its work through this boundary.
Explore the Origo Source page.
The public name and the protocol
Origo Source is the source ecosystem for Origo X. ORSP means Origo Source Protocol. New sources use these canonical names:
| Item | Canonical value |
|---|---|
| Discovery protocol | origo-source |
| Default discovery path | /.well-known/origo-source.json |
| Endpoint relations | v1/... relative to apiBaseUrl |
| Protocol header | X-Origo-Source-Protocol |
| Published identities | Existing source, book and chapter IDs |
The current contract is a candidate. Package metadata records the exact version, source commit and checksums. The canonical specification lives in origo-source-protocol.
A compact reading core
A core source implements discovery, search, book details, catalogs and chapter content. Content includes bookId, chapterId, title, contentType and content. Source identity stays globally stable; book/chapter IDs are scoped to that source. URLs, page numbers and array indexes do not replace content identity.
Readers can import the discovery URL. Existing 1.x sources retain their endpoints; optional features are declared only after implementation. A specified feature does not mean every source or reading app already supports it.
Clear responsibilities
Adapt content on the server; send structured data to the reader. Author tools, accounts, points and reading sync remain distinct services. Persistence belongs to your database and asset storage, HTTP owns delivery and validators, and the reader owns rendering and positioning. You can replace storage or add capacity without renaming content or changing its reading contract.
Start with a small file adapter if suitable; use indexed queries and separate body/asset storage as the library grows. Add caching and workers for measured demand. Distribute content you can provide, and keep upstream credentials server-side.
Continue with your first source and reading profiles.
HTTPS and legacy readers
Both HTTP and HTTPS are supported. Use HTTPS for public discovery, APIs, EPUB files and media. Clients verify certificate trust and hostnames and never silently downgrade. HTTP/2 and HTTP/3 are hosting negotiations; the JSON contract is unchanged. Local development may use HTTP.
The legacy /.well-known/open-reading-source.json endpoint returns protocol: open-reading-source and retains the X-Open-Reading-Protocol header for installed readers. Both entries share the same IDs and API, without duplicating content. New clients accept both identifiers; support for the canonical entry in existing clients depends on their actual version.
Fehler in dieser Anleitung gefunden? Korrektur vorschlagen