> should automatically scan my emails, texts and chats
Great, easy to integrate one service with the APIs of a bunch of others!
> Also, want it to be 100% local and privacy first.
...but in combination? Never going to happen.
Ask yourself: who's signing up for the API keys to enable the client-side service to talk to all these services? Is it the end-user, or is it this software's developer?
If it's the software's developer, then they're effectively leaking all these API keys by embedding them into the software itself — where not just the end users, but anyone else could come along and reuse these keys for anything they like. The service providers will find this out, and block these keys. (No, you can't avoid this by proxying requests to some gateway, operated by the service-provider, that holds the API keys. Then you lose the "local/private" aspect.)
If it's each end-user, then the aggregate traffic from all the instances of this app running at once, will look exactly like a bot that's trying to evade API rate-limits using a "residential proxy cluster" like https://www.zyte.com/smart-proxy-manager/... and so the services will block these keys.
---
Mind you, in theory, you could do this on the OS level, using OS accessibility APIs to effectively "read" the messages off the screen. But 1. is there any third-party ISV — who isn't a certified accessibility-software provider — who you'd trust enough to allow their software the ability to constantly "read" everything on your screen? That includes your passwords, you know! And also, 2., the messages need to be on the screen for accessibility software to read them. An accessibility-API-driven CRM can't load your chat history unless you also grant it the ability to literally take your mouse and scroll through it for you.
Or, alternately, coming at this from the perspective of the Operating System vendor themselves, you could do this "in" the OS, by forcing emails/text/chat message handling to go through system APIs that can see these as special document types, and so do things with them. IIRC there was at least one pre-iPhone mobile OS that did this (BlackBerry OS, maybe?), enabling all of these types of messaging-app traffic to be muxed together into a single first-party app that did indeed manage all conversations with your contacts in a multi-channel way.
That presumes the client stores anything locally + in plaintext. Clients like Facebook Messenger, Slack, and Discord have no local storage other than (opaque, fragmentary, useless) cache databases, because they're just "webapps in a can"; while many of the more modern native chat clients like WhatsApp, Signal, Telegram, etc keep all their synced state encrypted-at-rest on disk.
Also, that presumes you're on desktop. On mobile, you just can't poke into another app's sandbox/container that way (unless the target app hasn't explicitly granted made some part of its container-filesystem externally accessible; and there's no reason these apps would.) And many people only have a mobile device.
If you're okay with a partial solution, a far easier one would be scraping the data out of the few clients that have web-app versions through browser extensions that read the state out of the page they're running in.
Great, easy to integrate one service with the APIs of a bunch of others!
> Also, want it to be 100% local and privacy first.
...but in combination? Never going to happen.
Ask yourself: who's signing up for the API keys to enable the client-side service to talk to all these services? Is it the end-user, or is it this software's developer?
If it's the software's developer, then they're effectively leaking all these API keys by embedding them into the software itself — where not just the end users, but anyone else could come along and reuse these keys for anything they like. The service providers will find this out, and block these keys. (No, you can't avoid this by proxying requests to some gateway, operated by the service-provider, that holds the API keys. Then you lose the "local/private" aspect.)
If it's each end-user, then the aggregate traffic from all the instances of this app running at once, will look exactly like a bot that's trying to evade API rate-limits using a "residential proxy cluster" like https://www.zyte.com/smart-proxy-manager/... and so the services will block these keys.
---
Mind you, in theory, you could do this on the OS level, using OS accessibility APIs to effectively "read" the messages off the screen. But 1. is there any third-party ISV — who isn't a certified accessibility-software provider — who you'd trust enough to allow their software the ability to constantly "read" everything on your screen? That includes your passwords, you know! And also, 2., the messages need to be on the screen for accessibility software to read them. An accessibility-API-driven CRM can't load your chat history unless you also grant it the ability to literally take your mouse and scroll through it for you.
Or, alternately, coming at this from the perspective of the Operating System vendor themselves, you could do this "in" the OS, by forcing emails/text/chat message handling to go through system APIs that can see these as special document types, and so do things with them. IIRC there was at least one pre-iPhone mobile OS that did this (BlackBerry OS, maybe?), enabling all of these types of messaging-app traffic to be muxed together into a single first-party app that did indeed manage all conversations with your contacts in a multi-channel way.