Rewisp - See it once. Ask forever.
by•
Rewisp gives your Mac a memory. It reads your screen text on-device and remembers it for you. Catches promises like "I'll send it Friday" and reminds you until it's done. Ask "what changed since Tuesday?" and see exactly what's new. Search by meaning, not just words. Tracks numbers like weight or grades over time. Fills forms from your saved details — never passwords. One quiet 9 PM summary each day. Fully private: screenshots never saved, only text stays on your Mac.
Replies
Screenshots-never-saved plus everything staying local answers the privacy objection most people would raise first. Curious about the SQLite file itself though: is FileVault the only thing standing between it and a plaintext read, or is there another layer on top?
Rewisp
@vollos
Straight answer: FileVault is the encryption at rest. Rewisp doesn't encrypt the SQLite file itself yet, so a process running as you could read it. On top of that the data folder is chmod 0700 and the local API is token gated, so other accounts and other processes can't get at it.
The layer I lean on most is reduction rather than encryption. Messages, password managers, banking sites and incognito windows fully pause capture, credential shaped text is refused, screenshots are never written at all, and the text expires after about six months. App level encryption is the obvious next step.
@yashmitb Appreciate the straight answer on that, not everyone admits the gap that plainly. Reduction-first tracks with me, you can't leak what never gets captured. Out of curiosity on the app-level step: closer to SQLCipher on the same file, or would that mean rethinking how rows get stored?
Rewisp
@vollos SQLCipher on the same file. Field level encryption is the tempting version but it breaks FTS5, and full text search is the whole retrieval engine, so encrypting the values would mean rebuilding how search works. SQLCipher encrypts at the page level, so the index keeps working and nothing above the storage layer changes.
The real problem is key custody, not storage. A key in the Keychain that unlocks automatically protects a copied file or a backup, but not a process running as you, which is what you were actually asking about. Closing that means gating it behind Touch ID per session, and then deciding what the capture daemon does while the session is locked. That part I have not settled.
@yashmitb Doesn't your reduction rule already answer the locked-session case? Messages and incognito pause capture, so a locked session pausing too is the same move, and the timeline just gets a hole where the lock was. The other shape I've seen for it is making the daemon write-only: each capture gets encrypted with a public key whose private half only exists inside an unlocked Touch ID session, so the daemon keeps capturing but can never read back what it wrote. Costs you indexing until the next unlock, since FTS5 can't see into the sealed rows, which is probably why nobody loves that one either.
What does the always-on screen reading do to battery and CPU on a laptop? I like the idea of asking "what changed since Tuesday" but I'd want to know the cost of having it watch everything all day.
Rewisp
@talhakhalidmtk Great question!
It isn't recording, which is the main thing. There's a cheap check twice a second for which window is frontmost, and it only actually captures on a trigger: you switch apps, a URL changes, you stop scrolling, or a 60 second heartbeat. Unchanged screens get dropped by a thumbnail diff before OCR even runs, so most heartbeats cost nothing.
When it does capture, OCR is Apple's Vision framework running on device and hardware accelerated, about a second, and only on the display holding the frontmost window. There's no video encoding anywhere, which is the expensive part of screen recorders. It's text only.
It also fully stops after five minutes of no input, and when the screen is locked or the display sleeps, so it isn't doing anything while you're away.
Measured on mine right now it sits at basically 0% CPU between captures with a short spike during one.
Keeping everything on-device and never saving screenshots is the smart trust move here, a memory tool only works if you feel safe letting it watch.
Rewisp
@ilko_kacharov Thank you for the feedback!
on-device is the right call for something reading everything on your screen all day, but on-device isn't automatically safe - if my Mac gets stolen or someone gets local access, is that stored text file encrypted at rest, or just sitting in plaintext waiting to be read?
Rewisp
@omri_ben_shoham1 Good catch, thank you. Right now the database is a plaintext SQLite file, so FileVault plus your account permissions are what protect it at rest, and the Vault holding your personal details sits behind Touch ID(mac's auth) in the app on top of that. App-level encryption is on the roadmap and this is a good push to prioritize it.
The ambient memory idea feels useful for people who context-switch all day. The tricky part for me would be separating “I saw this once” from “this is worth remembering.” Are you doing any local filtering or recency scoring so old or accidental screen content does not pollute answers?
Rewisp
@simon_dao Yes, all locally: near-identical frames are dropped at capture, retrieval fuses keyword and semantic relevance with recency so old content has to be clearly relevant to surface, and anything you actually ask about gets reinforced and exempted from expiry while everything else decays and ages out around six months.
LottieFiles
On-device screen reading is the right call, but I am curious about the practical cost — what does continuous OCR do to battery on a laptop that is unplugged all day? And can I exclude specific apps entirely (password managers, banking) so they never even hit the local index?
Rewisp
@reallynattu Good catches! The computational cost is little to none. In the 2 weeks of development/testing phase, my computer's battery performed the exact same. I even wrote a benchmark test to get real numbers and on average the program effected my computer's battery level by 1.1%. And also yes, you can blacklist apps and websites on the dashboard so they are blocked before even trying to get stored(the app automatically has some built in but is super customizable).
nice idea, do u plan to release a similar version for Windows as well?
Rewisp
@luca_ardito Yes! I'm currently taking feedback and improving my plans and going to make a windows version very soon!
The "what changed since Tuesday" search actually pulled up stuff I'd completely forgotten about scrolling through, which was a nice surprise. The on-device-only approach makes me feel way better about letting it read everything on my screen.
Rewisp
@salcanamin72213 Thank you for the kind words :)
As a fellow solo dev, the privacy-by-construction bit (text-only, screenshots discarded on the spot) is what makes this trustworthy vs a plain screen recorder. One thing I always hit shipping Mac apps though — the screen-recording permission prompt on first launch scares a chunk of users off. How are you handling that onboarding moment so people don't bounce before they get to the value?
Rewisp
@lennoxbeflying This is still an issue I am working on trying to fix. I would love to connect outside of this and discuss/collab more on this issue.
Congrats on the launch and #5th rank on Sunday.
Love the promise-catching idea. that's the stuff that always slips through the cracks. Does it handle commitments made in voice memos or dictated text, or only typed content?
Rewisp
@kbaqeri Thank you!
It currently handles everything that it saw on the screen, no audio/dictated content can be detected yet, but it is in the future improvements.