SummaReader
A reader that pulls in what you follow — feeds, articles, YouTube, Mastodon, Nostr — summarizes it, and keeps the result in step across your own devices.
- Your library never leaves your devices in readable form.
- Summarization runs on-device by default. You can point it at your own server or a cloud API instead — that is the only time content goes anywhere, and only if you choose it.
- Sync is end-to-end encrypted: the server holds ciphertext against sequence numbers and cannot read any of it.
There is no server-side summarization, no server-side search, and no web reader. Those are not missing features; they are what the first line costs.
What you can paste
Press + beside Your shelf and paste an address. The right thing happens:
| You paste | It becomes |
|---|---|
A feed address (…/feed.xml, …/rss) | A feed |
| A site's home page | A feed, if the page advertises one |
| A YouTube channel or video address | That channel |
A Mastodon account (@name@server) | That account's posts |
| Any other page | The page itself, kept once |
Coming from another reader, Settings → Your data → Import and export takes an OPML file and everything in it arrives as a source.
Where summaries run
Nothing is configured on first run. The reader works with no language model at all, and the first time you ask for a summary is when you choose where it runs.
| This device | Gemma, as an optional download of about 2.6 GB. Nothing leaves the machine. Slower, and it costs battery. |
|---|---|
| Your own server | Any OpenAI-compatible endpoint — Ollama, LM Studio, llama.cpp. |
| A cloud API | Your own key. Faster, costs money, and the only time an article's text goes anywhere. |
The address and model are stored in the library; the API key goes to the system keychain, never beside your library. On Linux, if the Secret Service is unavailable or locked, it falls back to an owner-only file and says so rather than pretending otherwise.
How it works
One item, one identity
An item's id is a hash of its canonical URL, so the same article arriving from a feed, from a share and from a Mastodon link is one item listed under each. That is also what makes merging two devices a set union rather than a reconciliation problem.
Summaries are chunked, mapped and reduced
Long transcripts are split to a prefill budget using a real tokenizer, not
chars / 4 — measured, that rule of thumb undercounts Slovak by
about 43% and Czech by about 51%, which overflows the context and truncates the
model's reply.
Retention is two-tier
The extracted text and the title picture go first, reclaiming almost all the space while metadata and summaries stay; the picture's address is kept, so opening the article later fetches it again. Items go later. Anything saved, pinned, annotated or awaiting a summary is never purged — highlights are user-authored and may exist nowhere else.
Sync is a log of encrypted entries plus content-addressed blobs
The server holds ciphertext against sequence numbers and cannot read any of it. Deletion travels as explicit tombstones; an empty server never causes local deletion, because a server can be empty for several reasons and only one of them means anything was deleted.
What works, and what does not
| Storage, canonical URLs, identity | works |
| Ingestion: RSS/Atom, web, YouTube, Mastodon | works |
| Nostr | not yet — event parser written, no relay transport |
| Reading, saving, search, sources, settings | works |
| Retention and local notifications | works |
| Summarization, on-device model download | works |
| Encryption, keys, pairing, recovery | works |
| Sync: items, read state, summaries, highlights, article text, title pictures | works |
| Sync of subscriptions | no — a feed added on one device stays there |
| Linux | builds and runs |
| Android | builds, installs and runs; share sheet arrives |
| Windows | scaffolded, never built |
| iOS | compiles, but there is no release build |
Two gaps worth naming. Pages that render their text in JavaScript fail cleanly rather than being extracted — there is no headless browser, on purpose. And chunk sizes are provisional until the prefill benchmark runs on real mobile hardware.
Getting it
SummaReader is not distributed publicly yet. There are no downloads on this page and no waiting list to join — a waiting list is a server holding your address, which is the thing this app exists to avoid.
If you want to follow it or try it, write to development@dataiza.sk.
The app is licensed under the Mozilla Public License 2.0 — chosen because this app's central claim, that your library never leaves your devices in readable form, is worth more when it can be checked. A privacy promise in a binary nobody can read is a promise you are asked to take on trust. The sync server is separate and AGPL-3.0.