Allow ActivityWatch to Ignoring / Filtering

[NathanaelA]

@ErikBjare @johan-bjareholt - Actually when it came to implementing it -- several things changed from my initial idea that I proposed in https://github.com/ActivityWatch/activitywatch/issues/1

1. I ended up using the brand new KeyValue table in 0.12.0, So basically in the keyvalue table you can add a new key called IGNORE_FILTERS with the json value of: {"APPS": ["app1", "app2", ...], "TITLES": ["title1", "title2", ...]}

2. The DataStore module on startup loads this JSON key, parses it into two vectors that it then uses during inserts and replace functions on the event table. If any of the values you put into the TITLES key sub-string matches the Event.title it skips adding it to the database. Ditto with the Event.app against the APPS vector. This is a substring match so if you put "BRAV" in the APPS then it will filter out any app that contains BRAV anywhere in the app name. (i.e. BRAVE, BRAVO, ABRAVING, etc...

At this point I DO NOT have any GUI to add this value, you just use SQLite (or perhaps a POST to / which acts like a KeyValue "set") but at this point the process works.

[raudabaugh]

Thanks for this! It's working really well for me. :)

Some things to consider:

1. aw-watcher-window has additional filtering logic specific to macOS/Chrome here. I think it makes sense to drop such platform-specific cases and keep filtering responsibility solely within aw-server-rust.

2. For my use case, I'd prefer that AW still adds the events to the database while redacting the title. I implemented it this way here.

[real-or-random]

@NathanaelA Are you planning to continue working on this?

[NathanaelA]

@real-or-random when I have some of that spare time that people talk about... It is an low priority as this PR works great for my use-case.

[2e3s]

I made a similar feature in Linux Idle&Window watcher, but with regexp replacements. Given so many various watchers for ActivityWatch, it seems that the general rule may better be to keep watchers choosing what to send rather than implement the filtering and processing to make the server decide on what to store in DB. + This would also give extra security, because less unwarranted data travel through the network. + Also it allows to preview easily the private data without storing it on the server (if not sure of what app ID and title will be used).

[johan-bjareholt]

Given so many various watchers for ActivityWatch, it seems that the general rule may better be to keep watchers choosing what to send rather than implement the filtering and processing to make the server decide on what to store in DB.

That's the big reason why implementing it on the server would make sense, all watchers could get support for filtering without having to modify all of them to support this feature. If you would want to support filtering in all watchers separately, we would have to implement this feature at least 3 times (once for aw-client-python, once for aw-client-rust, once for aw-client-js) as well as maintaining it.

I'd also argue that the previewing would be more user friendly if done on the server-side, as then you could easily support that in the web-ui.

[real-or-random]

If you would want to support filtering in all watchers separately, we would have to implement this feature at least 3 times (once for aw-client-python, once for aw-client-rust, once for aw-client-js) as well as maintaining it.

I agree, and let me add having separate filters could be very surprising to user. And surprises are particularly bad when it comes to privacy features. For example, suppose the user has configured some filters, but then adds a new watcher, and suddenly the filters are not effective anymore.

edit: I still can imagine that some watchers would filter certain entries by default (e.g., in a browser watcher, one could ignore websites visited in private mode). But applying manual filters should be done on the server side.

[2e3s]

all watchers could get support for filtering without having to modify all of them to support this feature

Don't all watchers use their own keys? I clicked a couple random ones from https://docs.activitywatch.net/en/latest/watchers.html and looks like it. This code in PR looks specifically for app and title which is a realm of the window watcher, which is pretty much the only one.

I'd also argue that the previewing would be more user friendly if done on the server-side

It would be more GUI oriented indeed, but the event would be stored on the server then, while the whole point of the feature is to prevent that. For instance, I don't know how bitcoin wallet is reported in terms of app ID and title, and I don't want to keep in the history the usage of it. Client-based preview is trivial, but server-one would be not.

[johan-bjareholt]

but the event would be stored on the server then, while the whole point of the feature is to prevent that. For instance, I don't know how bitcoin wallet is reported in terms of app ID and title, and I don't want to keep in the history the usage of it.

It would be stored the first times when you test your filter yes, but since you then have a filter that works you could easily use that same filter to remove those events from the server.

I think it's important that we try to keep as many features as possible accessible through a GUI. We want to avoid excluding users just because they are not tech savvy when possible.

Don't all watchers use their own keys? I clicked a couple random ones from https://docs.activitywatch.net/en/latest/watchers.html and looks like it. This code in PR looks specifically for app and title which is a realm of the window watcher, which is pretty much the only one.

I agree that this is not desirable how it works in this PR and should be made more generic.