Proposal: change the static ruleset JSON structure

[ameshkov]

Problem

The overall problem explanation is the same as in #466, we'd like to have a place in the static ruleset file where we could store additional metadata. There's rule-level metadata mentioned in #466, but there can be "ruleset-level" metadata and currently due to the structure of a ruleset file there's no good place to store it.

Can we consider changing the structure from having an array on the root level [ rule1, rule2 ] to something like that:

{
    rules: [ rule1, rule2 ]
}

In this case we can declare that the metadata field can be used to store additional metadata, whichever the developer needs:

{
    metadata: {
        "name": "AdGuard Base filter",
        "created": 1697193986329
    },
    rules: [ rule1, rule2 ]
}

To not break existing extensions I propose accepting both formats (array at the root and object at the root), but having the second format recommended in the documentation.

[tophf]

If #466 is implemented you can simply store the extra data in the first rule's comment.

[ameshkov]

@tophf right, that will be a workaround if this change is not supported. But you know, not a beautiful one.

[rdcronin]

We discussed this at the WECG Meet-Up.

We're agreed that this is a good proposal for the structure of the rules file and would be more flexible (great idea, @ameshkov !) However, we're probably not going to do this now, for the following reasons:

• For ruleset-relevant configuration (i.e., non-metadata), we can leverage the entry in the declarative_net_request field of the manifest.json file, so we already have a way of doing this.
• There are other workarounds for how to have ruleset-wide metadata (e.g., also the entry in the manifest.json file, an unused rule entry in the ruleset file, etc).
• There are enough extensions out there using declarativeNetRequest that we would need to do this in a backwards-compatible way (and support both formats for the foreseeable future).

Because we wouldn't be able to just change the format and because there's no concrete use case we'd hope to solve with this change, we're unlikely to change this schema in the near future. For that reason, I'm going to close this out rather than leave it open without intention of working on it soon. However, this may be something we revisit in the future if we find a need for such data.

Thanks again for the proposal, @ameshkov , and for the discussion at the WECG Meet-Up.