I have now started serious work on the “”: site. While I am very aware of Jeremy Dunck’s “effort”: with his “”:, I still feel that there is room for a second site devoted to User JavaScript.
Jeremy’s model and goals are a bit different from the ones I see for

h3. Opera
I plan on devoting to scripts compatible with Opera. The reason for this has it’s background in the different scripting models of Opera User JavaScript and Greasemonkey.
While Opera is “capable of running many Greasemonkey scripts”: User JavaScripts should ideally be written specifically for Opera, to allow access to the parts of Opera that “Greasemonkey can’t reach”:
Specifically: Opera User Javascripts has the ability to capture and act on certain events that Greasemonkey scripts has no way of intercepting. The User Javascript model allows a script to rewrite author scripts before they have even had a chance to run.
Also, there are also some Greasemonkey scripts which are incompatible with Opera out of the box.
I think the two different scripting models would be hard to manage within one site, and it could potentially end up being confusing to end users with little or no scripting knowledge, which is the group I am aiming for.
h3. Safe haven: Script QA
When I speak of the user space and the web, I think user scripting technologies is the most important thing that has happened to the web: User scripts allow users to exercise great control over how they interact with a web site, and it has the potential to fix accessibility and usability problems that simply cannot be fixed by user CSS alone.
User scripting can also enhance sites, interacting with third-party services, leveraging the value of any given site on which a User JavaScript is applied.
In short: User scripting (and user styling) _is the new platform._ You can build entire applications and services on top of existing services and sites.
However, the fact that user scripts can interact with third-party services also poses a risk: How does a user that often has no knowledge of programming know that a script is safe to run?
The answer is: The user can’t know that. She or he will have to trust the person who provided her or him with that script.
Which is also one of the important aspects of The site will not accept scripts that:
* … contain spy/malware.
* … are misleading about what they do
* … alter affiliate or ad ID’s.
* … perform click-fraud or similar.
* … are obfuscated.
While this means that this script directory will not contain every User JavaScript in the universe, it should mean that users can install a script from and be sure that their security or privacy is not compromised.
This also means that I won’t be running this site as a one-man show: I have already gotten some volunteers, and I will probably be enlisting more as the workload grows.
These volunteers will be reading through every script that is submitted for inclusion, and thus will be ensuring that the scripts are safe for end-users. Incidentally, this is also the reason why obfuscated scripts will be rejected. If an experienced JavaScript developer can’t understand what a script does, noone can really be sure it’s safe.
By the way, there is no reason to apply as a volunteer: Every one who will be doing QA on these scripts will be hand-picked and headhunted by the existing volunteers.
h3. Metadata and an API
Every script published on the site will hold some metadata about the script, in addition to what the User JavaScript “metadata format”: allows:
* A script ID
* A script download URL
* A documentation URL
* (Simple) version information
* Author data: Name, URL
So, where does the API come in? If user scripts distributed from carry all these metadata, and an API is provided, it is relatively trivial for software to ensure that all installed user scripts are always kept up to date.
h3. Licensing
This is something I haven’t yet decided on, but I’m considering to mandate a license for scripts submitted to the site. The copyright will remain with script authors, but the reasons for mandating a license are numerous:
* Derivative works. User scripts hold great value
* Users should be certain they can use scripts downloaded from the site, and if neccessary, roll their own.
* Volunteers need to be able to audit scripts in a sensible manner, and they also need to be able to fix bugs in scripts as needed, without asking permission.
* Prevent hijacking of scripts for more sinister purposes.
I have not yet decided on a particular license scheme, or if the “one license to rule them all” approach is the right one, so I’m open to suggestions and insights from my readers here.
h3. Tutorials
As time permits, the site will also host a few tutorials devoted to User JavaScript, so that authors can learn how to write their own scripts, fix sites themselves, and enhance their own browsing experience.
h3. Future
While One won’t feature this – bookmarklets are part of the plan. Especially bookmarklets that interact with and leverage existing user scripts.
User CSS is also part of the plan, but that is also not a One feature.
h3. The boring technical details
So, what am I planning to run this thing on?
“Movable Type”:
Ok. I can hear some of you going “What?” with enough exclamation marks to prove any insanity. I’m still going to run “”: on Movable Type:
* The front page will be handled by one weblog, as set up in a Movable Type installation. It will hold news and announcements, and will be coordinated with the rest of the site.
* Tutorials will be handled by a separate weblog instance in the same install.
* Script submissions will be handled by the MT commenting system, set up in a slightly weird way on yet another weblog instance.
* The scripts will be handled by another weblog instance, and both the download and “display” version of a script will be handled from this weblog instance, and my Army of Volunteers should be able to move the submissions from comments to a weblog with two clicks. I predict that User JavaScript may eventually reduce this to a one click-operation.
* There will be no RSS. Since the target group is Opera users, these users presumably has support for an Atom 0.3-compatible feed reader. RSS is deprecated.
* I have already had to modify the db scheme for MT in two ways:
** Some of the file name templates are insanely complex. @templatemap_file_template@ in the @mt_templatemap@ table has been changed from @varchar@ to @text@ (yes, my file name templates easily exceed 255 characters).
** Movable Type does not by default accept duplicate category names, since a unique constraint exists named @category_blog_id@ on @category_blog_id@ and @category_label@ in the @mt_category@ table. At the suggestion of “Brad Choate”:, I changed this unique constraint to be on @category_blog_id@, @category_parent@ and @category_label@ instead
* There is a whole load of plugins involved. As always.
h3. Release date?
I’m parroting Opera on this one — WIR: When It’s Ready (Enough). _Stay tuned!_

Previous Post
Leave a comment


  1. Great! Can’t wait to see it.

  2. TreeGhost

     /  2005-04-21

    Very nice! Thank you. 🙂

  3. Great initiative, Arve. Really looking forward to the first results!
    Regarding the license; I’m definitely not very knowledgeable about the various types of licenses available, but a clause which may solve many of the issues you raised is the ‘share-alike’ clause as can for instance be found in the Creative Commons licenses.

  4. This is a GREAT idea! A lot of User JS files are on the ‘net, but they haven’t been organised in a proper way yet.
    I’m looking forward to!

  5. chaimav

     /  2005-05-06

    Great Idea. Could you possibly add a section for ua.ini entries for Opera as well?
    Here is “thread that has some already posted”:

  6. For the curious: is real close to a beta release now.
    Chaimav: I don’t think ua.ini is quite appropriate for this site, as it is focused solely on User JavaScript.