31–40 of 77 posts
Funny timing. I've been building something similar in my spare time called Daydream. There’s a lot of overlap: local screen/audio capture, OCR and transcription, window and activity context, SQLite, and a searchable memory of what happened. The main difference is the product direction. Screenpipe seems focused on continuously giving agents context through APIs, MCP, and skills. Daydream is more narrowly built around…
How do you secure the database on my device?
We also have early support for encryption at rest through our CLI
Implementation specifics aside, I increasingly think life and death cycles are preferable. The opposite of omnipotent context, I want cycles of clean slates so that baggage - of all kinds - does not weigh down the new.
We capture everything and gives you and option for a flexible data retention policy, so that you can prune mp4 files for example or verbose accessibility trees, while our agents generate high level memories referencing low level data
It still not perfect, but ideally Screenpipe would record forever so that you have infinite memory of every tiny details, while having high level structured memories for humans and agents, individually or as a company
Well, i'm not sure who your customers are (except companies in Russia, NK..), but european employers would break laws by allowing your software to be used, long even before AI became a thing and especially after the EU AI Act has passed. To put it mildly, no sane corporation would allow such software to be used which tells me a bit about the sanity of the current VC landscape.
Well, i'm not sure who your customers are (except companies in Russia, NK..), but european employers would break laws by allowing your software to be used, long even before AI became a thing and especially after the EU AI Act has passed. To put it mildly, no sane corporation would allow such software to be used which tells me a bit about the sanity of the current VC landscape.
Out of interest, would it not be allowed even if the company hosted screenpipe on prem (which seems to be what they do)?
Well, i'm not sure who your customers are (except companies in Russia, NK..), but european employers would break laws by allowing your software to be used, long even before AI became a thing and especially after the EU AI Act has passed. To put it mildly, no sane corporation would allow such software to be used which tells me a bit about the sanity of the current VC landscape.
Out of interest, would it not be allowed even if the company hosted screenpipe on prem (which seems to be what they do)?
That's not just specific to digital stuff. E.g. warehouse cameras that film anything else beyond securing entries/exits, like they are commonplace in e.g. the US don't exist for the same reason.
Earlier quoted context omitted.
Sure! For one, even taking the ethos of local-only as something bulletproof, I can't think of a pro that would outweigh the con of recording everything I do. Part of that might be my lack of imagination, as I'm not a heavy user of ai besides basic Claude code. Most important though, the concept is ripe for pivoting away from local-only. It will only take a juicy investment offer and I'm sure local-onpy will be quietl…
Thanks! In fact most of AI apps today have a screen recording component, including Claude, Codex. There are even apps used by hundred of thousands that record your screen 24/7 in the cloud, to provide context, like Screenpipe does. We're the only local-first, open source option How much time do you spend explaining the context to your Claude? Or writing detailed prompts? Copy pasting documents into the prompt?
>How much time do you spend explaining the context to your Claude? Or writing detailed prompts? Copy pasting documents into the prompt?
Prompts: not much. If I feel my prompt is becoming a paragraph-long text, that's when I know I probably haven't thought things through enough yet. Documents: I typically have a interpreter console open where I'll do something like File.write("foo.html", page.body), and I'll just tell Claude to "find the missing div in foo.html". Or if its a file already in the repo, I won't need to copy paste anything. Context: also not much. It has all the context by default, doesn't it?