Open PeterDaveHello opened 2 years ago
If I remember correctly the lists are aggregated per group. 🤔
So it would be quite troublesome gathering the information if the entry is duplicate in multiple lists in the same group.
I assume you'd like to get all lists with the entry? This may really clutter the logs. 😅
Wouldn't splitting your lists in multiple groups and using all of them as your block groups be more readable? One list per group would be a name for it's url. 🤔
Indeed, storing the list(s) a url is blocked by would increase RAM usage a fair bit.
What I do is have a group per list provider (examples: disconnect-me, blocklistproject) so it helps narrow down the problematic list.
Maybe adding a subcommand to blocky that downloads and parses the configured lists, and then prints the ones that block a specific domain would be a good approach. That would avoid any extra resource usage until you need it, which shouldn't be too often.
As mentioned by @kwitsch and @ThinkChaos , the workaround is to define one url per group. I think, we could change the internal cache representation to provide more detailed information. Maybe internal a cache struct per url or storing a additional byte with list order?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.
😅
I'm thinking we should probably move towards having a CLI command like blocky why <domains...>
that loads the config and tells you why a domain is being blocked.
Having it separate from the server means we don't care about memory or runtime as much, so we can avoid merging groups and regexes allowing use to give precise info to the user.
I'm thinking we should probably move towards having a CLI command like
blocky why <domains...>
that loads the config and tells you why a domain is being blocked. Having it separate from the server means we don't care about memory or runtime as much, so we can avoid merging groups and regexes allowing use to give precise info to the user.
CLI uses currently only the REST API and doesn't contain any logic. I think we can use existing cache and provide calculated result over the API
Will be helpful to tell the exact block list(s) that being the reason a certain domain being blocked, like Pi-Hole:
Right now we can only know the "group", but there could be many blocklists in a single group, if you want to find out which one is the one, that'll be pretty hard: