Integrate with OpenUserJS.org

[sizzlemctwizzle]

I'm very interesting in having Greasy Scripts integrate with OpenUserJS.org. My question is what exactly do you need from us?

Would the normal search (e.g. https://openuserjs.org/?q=youtube.com) returned in JSON format be enough? Or would you prefer something that only searches the @include (obviously @match too) rules of scripts? Like https://openuserjs.org/json/search.json?match=youtube.com? Do you want us to do the @include/@exclude resolution so that only scripts that actually match the given URL are returned, or would you prefer a basic search where you can just handle those things yourself?

You can respond here or over at OpenUserJS/OpenUserJS.org#77

[Ede123]

Hi Mike, thanks for interest!

The current idea is to give the user script results _per domain_ - a "domain" consisting of a public suffix plus one domain name part. (If you're familiar with Firefox programming: Greasy Scripts uses nsIEffectiveTLDService.getBaseDomain() to extract the domain from any given URL).

Therefore an API that allows to search for scripts by domain name using exactly this definition of "domain" would be the most compatible approach.

After a quick check I'm afraid your normal search wouldn't return useful results in all cases. For example a search for https://openuserjs.org/?q=mozilla.org returns a huge list of scripts - few of them actually being applied to mozilla.org.

If you create a new API for this it would probably suffice if you did a quick (domain-based) check of @include / @match. There's no need for advanced checking (like subdomains, exludes or even paths). As a rule of thumb: If a script is applied to any URL belonging to a certain domain (with above definition) or subdomains thereof it should be found when searching for that domain.

Regarding specific implementation

Greasy Scripts currently supports the Greasy Fork API, so the more alike a future OUJS API will be, the easier the implementation of current and future features across both projects (and that is not only for Greasy Scripts but for any code that might be written for any of the projects). So as far as you find their approach useful you might want to consider re-using syntax and data structure wherever it makes sense.

As an example Greasy Scripts currently makes use of the following Greasy Fork API calls / URLs:

1. https://greasyfork.org/en/scripts/by-site/mozilla.org.json?meta=1 - this is the current core of it all: a quick way to determine the number of scripts that are available for e.g. mozilla.org. Kudos to @JasonBarnabe for implementing this for me!
2. https://greasyfork.org/en/scripts/by-site/mozilla.org.json - this would be the according API call to get details on each of these scripts (Greasy Scripts does not currently use it but if I ever implement anything to provide the user with more information about the available scripts, this is what I'm going to use)
3. https://greasyfork.org/en/scripts/by-site/mozilla.org - this is the current landing page a user will see if he decides to view details on the available scripts.

As you see (at least for now) it would be completely sufficient if OUJS offered 1. and 3.
At some point I might think about collecting available scripts in a native GUI (then I'll need 2.) but there's no pressing need for it as long as all supported projects have a nice landing page.

[Martii]

I believe that we can always add a QSP for a more finite search result... we search by default a bunch of intel on the script lists. As far as the API itself goes we can return a collection in just about any ordering and tier structure. Thanks for the linkage and explanation.