Stillpoint

Gee thanks.

An export file, yes. There's no server to sync through, so moving between devices is one JSON file that carries the library, the reading positions, the highlights, the per-book settings and the book files themselves, encoded inline so the file stands on its own. Importing it merges rather than overwrites, keeping whichever position is more recent for each book. On a phone it goes out through the share sheet, so AirDrop handles the transfer. On phrase mode: the chunk size is fixed and you choose it, but the timing isn't fixed at all. A sentence ending gets the longest pause, clause punctuation gets a shorter one, words over eight characters buy a little more time, and a paragraph or chapter boundary gets an extra beat on top. There's also a per-sentence complexity factor, so a dense sentence slows down on its own without you touching the speed control. The gap is that the chunk window doesn't re-group itself around clause boundaries yet, so a three-word phrase can still straddle a full stop. That's the part I'd fix first.

Thanks Gal. The re-reading loop was the thing I was aiming at, and most of the rest followed from trying to remove it.

That's the gap it's built for. Reading speed is mostly limited by your eyes jumping back rather than by how fast you can actually understand something, so holding every word at one point lets you run closer to the speed you're already thinking at. Start around 400 and move up from there. It feels too slow for about thirty seconds and then it doesn't.

It doesn't handle them, and you've found the one place I'd expect it to break. The text comes out in the order the PDF's own content stream provides it, with a spacing heuristic for when the vertical position shifts. Papers produced by LaTeX usually write that stream one column at a time, so those come through in the right order and read normally. A PDF that interleaves its columns will interleave in the reader too, because nothing currently sorts by horizontal position to catch it. Tables and figures are the exception: those get detected and shown as the real thing rather than flattened into the stream, so at least they don't turn into word soup halfway down a column. Sorting by horizontal position is the fix, and it's the next thing I want to do to the parser. If you have a paper that breaks it, send it over, because I'd rather build against a file that actually fails than one I made up. Thanks for opening the network tab, by the way. Not many people actually check.

The export includes everything, and that's the part worth being precise about: library metadata, reading positions, highlights, per-book settings and the original PDFs and EPUBs themselves, encoded inline. That's deliberate, because a backup that carried only metadata would leave you on the new device with a list of books that aren't actually there. It is not encrypted. It's plain JSON sitting on your disk. So the privacy model holds while that file stays on your device or moves directly between your own devices over AirDrop, and it stops holding the moment it lands in a cloud drive or an email attachment. You're right that this is where it gets thin. Passphrase encryption on export can be done entirely in the browser with WebCrypto, so there's no real reason not to add it. It should stay optional though, because plenty of people are just moving a stack of public papers between two machines and shouldn't have to manage a passphrase to do that.

Thanks. If you're reading a lot, the on-device library and the chapter-scoped progress are probably the parts that matter most, because both are built for having several books going at once rather than one at a time.

Thanks Iqbal, appreciated.

That's a fair thing to ask for, and the honest version of that guide is partly a list of what doesn't work yet, which is probably the reason to write it. Where it stands today: code blocks and tables get detected and shown as the real thing instead of being streamed as words, which is the case I'd want to see demonstrated before I trusted a reader with a paper. Two-column pages are the weak one, because there's no horizontal-position sorting yet, so the ordering depends on how the PDF's content stream happened to be written. Footnotes and inline citations flow in wherever the stream puts them, so a citation marker can land in the middle of a sentence. I'll put together a page that runs a real paper through it and shows each of those cases with the failures included, because that's more useful than a feature list and it lets you predict whether your own documents will survive before you spend attention finding out.

Fixed window. Five words, every resume, with no away-time detection at all. So you've named the exact flaw. Five words is about right for a ten-second glance away and useless after a four-minute interruption, and today those are the same code path. The four-minute case is the one that actually matters and it's the one it handles worst. Scaling to measured away time is clearly right. Timestamp the pause, and past some threshold fall back to the start of the current sentence instead of a word count, because a word count doesn't respect meaning. Sentence replay covers it manually right now, but you have to remember to reach for it, and the whole point is that the interruption already took the context with it. This is going in. Most useful comment on the page. Curious how you handle it in Unstuck. A calendar gap has the same shape, where the length of the gap should change the re-entry, and I'd guess you hit the same threshold-tuning question.