Jeremy’s model and goals are a bit different from the ones I see for userjs.org:
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.
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 userjs.org. 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.
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.
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
* 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 userjs.org 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.
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.
While userjs.org 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 userjs.org One feature.
h3. The boring technical details
So, what am I planning to run this thing on?
Ok. I can hear some of you going “What?” with enough exclamation marks to prove any insanity. I’m still going to run “userjs.org”:http://userjs.org/ 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.
* 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”:http://www.bradchoate.com/, 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!_