AFAICT, wikipedia works perfectly with librejs; so i dont fully understand the concern raised in this thread - i will do my best to explain things as i understand them though
as best as i understand this proposal, it seems like it would be a matter of "feature-creep" for librejs - the purpose of librejs is to inhibit dynamic behaviors, which are normally beyond the control of, and practically invisible to, the user - that is, conditions such that the user has no opportunity to inspect or replace the code, before running it, or to so much as witness it's effects while running it blindly - librejs does not allow the user to do any of those things either - librejs can only inhibit code from running without prior consent; and nonetheless, that consent is _always_ given blindly - that is because, every time some web page is visited, the server may (and often does) send different scripts than those previously inspected/approved by the user in contrast, "clickable" URLs on web pages are generally, static properties of the HTML document (read: inert, harmless) - these are a very different case; because although URLs also may be different each time the page is visited, the user, before deciding to click the link (intentionally), always has the opportunity to inspect the URL which would be resolved - more substantially though, is that unless the URL is a literal IP address (most are not), the actual web-server to which any domain name resolves, is fundamentally governed by a DNS mechanism, as chosen by each user - that mechanism is entirely orthogonal to librejs and the web browser - there are better ways to manage that concern, such as the good ol' 'hosts' file there may be some confusion regarding "direct" vs "re-direct" URLs - the reason why youtube can be accessed generally by other tools, is because youtube exposes a programmer's API; which are a set of stable entry-points (essentially URLs) for heterogeneous clients to access network resources, generically (ie: with or without a web browser) - clients such as invidious use the youtube API in a way, such that youtube can be accessed by web browser clients, via a proxy web service; but that is only one possible design choice - it is the least imaginative one actually, and the least effective for the goal of achieving software freedom - it is merely "passing the buck" as they say, to another website, which itself serves javascript for librejs to filter, in exactly the same way - it entails the same degradation/preclusion of software freedom which is inherent in any remote network service - such proxy web services offer no more or less software freedom than the original web service does - _unless_ one hosts one's _own_ instance, proxy services have zero relevance to software freedom - that is true, irrespective of the software license; because the user has zero software freedom, while using it, and can never inspect _any_ of the software which is _actually_ running on the remote server an alternate design option, is direct clients such as totem and minitube, which use the same API to access youtube from local desktop applications - this is another important distinction to make - those tools perform exactly the same tasks as a proxy service does, except that nothing like librejs is needed; because total transparency and control over the software is inherent in them, by nature of the user having their own local copy, necessarily wikipedia's underlying software, mediawiki also exposes a programmer's API - i believe that it is enabled on the wikipedia,org instance; so the same variety of third-party clients, which could be written for youtube, could be written for wikipedia as well - i am not aware of any website software which uses the mediawiki API to proxy access to wikipedia.org data - presumably none exists, and presumably because there is no demand for one - if the suggestion is to re-write URLs "inline", to forcibly re-direct all matching URLs to some other website, then in the case of wikipedia.org, there is no alternative website serving the same data, toward which to redirect as a "drop-in" replacement - that is why i am confused by the wikipedia example, as justification for librejs to blacklist entire domains, and forcefully redirect to another; but again, perhaps i have mis-understood the proposal network API are essentially URLs, which are designed to never change - in general, there is no distinction from the user's perspective - they are both nothing more than addresses of some network resource - the main difference is that the API can search/locate resources, without firstly fetching some other resource (such as an HTML index page or external search engine) - the distinction is irrelevant though, WRT web proxies such as invidous; because the back-end service uses the API to locate the resource, but the user still accesses the data, by firstly downloading an HTML page - the only difference is from which server the HTML page is downloaded in either case of API vs directly-clickable URLs, neither are executable software, and so do not themselves impose any impedance to software freedom (the primary concern of librejs) - librejs only needs to serve as a guard or warning, when one's software freedom would otherwise have been restricted without it
