Implement the core uBlock-compatible filtering engine in Star-Lang #6

New issue

Open

opened 2026-09-11 05:16:59 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-09-11 05:16:59 +00:00

(Migrated from github.com)

Parent: #1
Depends on: #2

Goal

Implement the actual blocking/evaluation core in Star-Lang against the contract and compatibility corpus defined in #2.

Scope

Static/network rule matching and exception precedence.
URL/hostname/domain matching.
First-party/third-party and document/request context handling.
Resource-type and option constraints.
Dynamic/per-site allow/block rules.
Cosmetic selector evaluation and page-side actions needed by Nyxt.
Redirect/modify-style outcomes where the Nyxt platform can support an equivalent behavior.
Deterministic rule precedence and explainable decisions.
Efficient compiled/indexed rule representation appropriate for large public filter lists.
Runtime reload/update support so list changes do not require restarting Nyxt.

Star-Lang requirements

Blocking policy and evaluation live in Star-Lang.
Do not embed the upstream JavaScript engine or use JS as a hidden evaluator.
Keep parsing/compilation boundaries explicit so #3 can feed normalized rules into this engine.
Expose a stable library API usable by the Nyxt adapter and by tests without launching Nyxt.

Verification

Run the #2 compatibility fixtures directly against this engine.
Include regression fixtures for precedence, exceptions, site-specific rules, large-list lookup, and malformed/unsupported data reaching the boundary.
Benchmark rule-load time and steady-state request-decision latency with realistic list sizes.

Acceptance criteria

The compatibility corpus for the implemented subset passes without JavaScript evaluation.
Every decision can return action + matched rule/expert + source/provenance.
Large filter sets are indexed/compiled rather than linearly reparsed on every request.
Rules/lists can be reloaded atomically at runtime.
The engine works headlessly as a Star-Lang library before Nyxt integration.

Parent: #1 Depends on: #2 ## Goal Implement the actual blocking/evaluation core in Star-Lang against the contract and compatibility corpus defined in #2. ## Scope - Static/network rule matching and exception precedence. - URL/hostname/domain matching. - First-party/third-party and document/request context handling. - Resource-type and option constraints. - Dynamic/per-site allow/block rules. - Cosmetic selector evaluation and page-side actions needed by Nyxt. - Redirect/modify-style outcomes where the Nyxt platform can support an equivalent behavior. - Deterministic rule precedence and explainable decisions. - Efficient compiled/indexed rule representation appropriate for large public filter lists. - Runtime reload/update support so list changes do not require restarting Nyxt. ## Star-Lang requirements - Blocking policy and evaluation live in Star-Lang. - Do not embed the upstream JavaScript engine or use JS as a hidden evaluator. - Keep parsing/compilation boundaries explicit so #3 can feed normalized rules into this engine. - Expose a stable library API usable by the Nyxt adapter and by tests without launching Nyxt. ## Verification - Run the #2 compatibility fixtures directly against this engine. - Include regression fixtures for precedence, exceptions, site-specific rules, large-list lookup, and malformed/unsupported data reaching the boundary. - Benchmark rule-load time and steady-state request-decision latency with realistic list sizes. ## Acceptance criteria - The compatibility corpus for the implemented subset passes without JavaScript evaluation. - Every decision can return action + matched rule/expert + source/provenance. - Large filter sets are indexed/compiled rather than linearly reparsed on every request. - Rules/lists can be reloaded atomically at runtime. - The engine works headlessly as a Star-Lang library before Nyxt integration.