Define Star-Lang blocking engine contract and uBlock compatibility corpus #2

New issue

Open

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

lost-rob0t commented

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

(Migrated from github.com)

Parent: #1

Goal

Before implementation, define the behavioral contract the Star-Lang blocker must satisfy and build a compatibility corpus from upstream uBlock behavior.

Scope

Inventory upstream network filtering, exception rules, hostname/domain matching, request types, party/context semantics, redirects/resources, cosmetic selectors, scriptlet-style behavior where applicable to Nyxt, dynamic/per-site rules, and logging/explanation behavior.
Define normalized Star-Lang input facts for a request/document decision: URL, origin, document URL, resource type, frame/context, initiator, method, and relevant page metadata.
Define normalized decision output: allow/block/redirect/modify/cosmetic actions plus provenance/reason.
Build fixture-driven behavioral tests from representative filter syntax and expected outcomes.
Explicitly record features that are browser-extension-specific and need Nyxt equivalents rather than literal ports.

Black-box rule

Treat upstream behavior as the compatibility reference. Do not design the Star-Lang implementation around upstream JavaScript object structure.

Acceptance criteria

A stable engine API is documented before UI work begins.
Compatibility fixtures cover both positive and exception cases.
Each result can report which rule/expert caused the decision.
Unsupported/deferred upstream features are enumerated, not silently dropped.
The contract is sufficient for the filter-list, Nyxt integration, settings, minor-mode, and LISA issues to build against.

Parent: #1 ## Goal Before implementation, define the behavioral contract the Star-Lang blocker must satisfy and build a compatibility corpus from upstream uBlock behavior. ## Scope - Inventory upstream network filtering, exception rules, hostname/domain matching, request types, party/context semantics, redirects/resources, cosmetic selectors, scriptlet-style behavior where applicable to Nyxt, dynamic/per-site rules, and logging/explanation behavior. - Define normalized Star-Lang input facts for a request/document decision: URL, origin, document URL, resource type, frame/context, initiator, method, and relevant page metadata. - Define normalized decision output: allow/block/redirect/modify/cosmetic actions plus provenance/reason. - Build fixture-driven behavioral tests from representative filter syntax and expected outcomes. - Explicitly record features that are browser-extension-specific and need Nyxt equivalents rather than literal ports. ## Black-box rule Treat upstream behavior as the compatibility reference. Do not design the Star-Lang implementation around upstream JavaScript object structure. ## Acceptance criteria - A stable engine API is documented before UI work begins. - Compatibility fixtures cover both positive and exception cases. - Each result can report which rule/expert caused the decision. - Unsupported/deferred upstream features are enumerated, not silently dropped. - The contract is sufficient for the filter-list, Nyxt integration, settings, minor-mode, and LISA issues to build against.