unbound: blocklist improvements#10149
Conversation
|
Thanks for this ae32651 |
|
@sopex thanks for confirming, missed that part yesterday it seems. |
| <yy>YoYo List</yy> | ||
| </opt1> | ||
| <opt2 value="Hagezi Multi - Clean the Internet"> | ||
| <hgz001>LIGHT - Relaxed Blocking</hgz001> |
There was a problem hiding this comment.
one thing that is annoying here for later lookup is that the vendor is no longer attached to the entry but moved to the category. the categories absolutely make sense but it would be nicer per use case, not vendor specific moving into the pickle of not having the vendor name in the label. Then it still has use cases in the string but in part that's due to vendor funkiness.
There was a problem hiding this comment.
I thought about this very early on, but I don't think this is a problem after all.
You get the basic info from looking at it and then you can click edit for more info.
The per-category blocking will make very little sense...
There was a problem hiding this comment.
To me it looks like the grid was clearer before as now it's missing more context but the names are currently too long / inconsistent in length. the tradeoff in the PR is not well balanced at a quick glance. But it's rather difficult in this inhomogeneous set of data.
My main concern is that categories are a very good tool here but making vendor categories and general categories and use-case categories at the same time will not get you a clearer picture/overview of the blocklists which I think you goal was. The categories should categorize one thing and the use-case seems to be the most reasonable as it is also self-explanatory. And when you only have use-case categories then you need the vendor in the actual listing again.
In contrast it would also be ok to update the documentation which can hold more data and info and add several layers of categorization away from complicating the code/data representation in the model.
There was a problem hiding this comment.
There is zero context missing. On the contrary, IMO the context is front and center now.
The problem obviously stems from the blocklists themselves.
But I completely disagree with changing the grouping to usecase in this instance.
A) Because the usecases with more than 1 option (Minimal Hardware Requirements excluded) are two:
-
General Usage (Includes all except the targeted hegazi and 2 OIDC)
-
Targeted Usage (Includes targeted hegazi and 2 OIDC)
B) To make this work, we present to the user "competitive" options for the same thing, which is not helpful...
Why would someone choose the hegazi gambling vs the XX gambling blocklist?
The way it is in this OR is like a shopping list that you pass through and get what you need
In the documentation, we can add anything you want, but the UI should stand on its own... Because people refuse to read the documentation even after searching for the solution for 3 hours 😞 #10151 (Completely random point, it could just as easily have been me)
There was a problem hiding this comment.
I guess I’m missing the point here then. It’s difficult to be productive in these non-technical PRs and I only meant to provide input into what is good and bad about the current and the proposed way. This is a tricky problem domain with multi vendor presentation and always has been.
There was a problem hiding this comment.
Your feedback is always valuable, technical or not.
Let's leave it open to see if any good ideas for usecase grouping show up.
I currently don't have any, but no reason to move forward here if I am the only one happy with the result. I am definitely not infallible 😂
4 participants
Important notices
Before you submit a pull request, we ask you kindly to acknowledge the following:
Describe the proposed solution
*Organizes DNSBLs by provider/category.
*Adds the Social Network blocklist by hegizi.
*Fixes: /ui/unbound/dnsbl/index#blocklist_tester having an extra apply button :)*The tester now gives you the DNSBL name instead of its shortcode.
Related issue
Closes: #10133