Userscript.org

I posted something very like this to the mailing list, but I wanted it to get out to more people for consideration.

So far, Greasemonkey has gotten by with a wiki page, but it's quickly outgrowing that.

So I'm starting to work on a new user script directory, which will live over on userscript.org.

I'm interested in input on how I'm planning to do this (or if someone would like to help). If you think I'm doing something wrong, please convince me.

To set the stage, here are the goals I'm attempting to address:

1. Provide versioning and update notification.


2. Improve ability to judge trustworthiness of scripts


3. Provide an easy way to find user scripts.


4. Encourage sharing of scripts.


5. Provide a home for the idea of user scripts, including other browsers.

That's all fairly ambitious, so I'll be reluctant to take on new goals.

In order to serve goals 1-4, the directory will need to discover scripts, and regular spidering won't be very useful, I think, because there are relatively few user scripts, and I'm not sure how to go about finding good sources of scripts.

(Well, there are obvious things like checking domains you've found them on before, and taking outbound links from those sites if url like *user.js, but even so...)

I think using delicious for discovery is a pretty easy win, because people will tag for Greasemonkey if it's useful, and delicious is useful as a directory to start with, and we can seed the tagging with quite a number of scripts already.

Of course the directory will allow form-post submission of a URL to a script so that authors can have a more direct way of discovery.

So assume we've got a directory and it has lots of scripts and no trouble finding more.

I plan on managing versioning as follows: once a script has been discovered, it will be hashed, and this hash will be the basis for differentiating the originally retrieved script from any later version. Scripts in the directory will be periodically retrieved, and changes in hashes will create new versions in the directory.

Why take this route over allowing (read: requiring) authors to explicitly version?

1) Because this versioning is meant to allow not just for update notification, but also for assignment of trust. A popular script that has not changed in a month is very likely trustworthy, but once a new version is published, all bets are off. If the author controlled the versioning as well as the script, there'd be no basis for trust.

2) Because authors won't consistently version their own scripts. User script authoring is meant to be relatively fluid and lightweight, and making backups and renaming and re-versioning is a bunch of overhead when the author just wants to spend a couple seconds fixing a bug.

So assume we have a directory with scripts and versioning. With this, we can provide update notification. Syndication seems the obvious choice; it's lightweight, and people interested in Greasemonkey are very likely to use it. I suppose we could also do email notification, but, well, I don't know much about administering a mail server or mailing list software.

So the user's been notified that there is a new script he may be interested in. How does she know whether its OK to install? There've been suggestions that sand boxing user scripts would be good, and breathless descriptions of how this is the end of e-commerce (OK, that's a small hyperbole).

(Thanks to Adrian Holovaty for pointing out that Craigslist has this problem and has proven that a community review process is all you really need to keep bad things from happening.)

I think generally people will be interested in controlling this problem, and keeping stuff completely safe is sort of an impossible goal. All you can hope for is to keep things from going off the rails and exposing lots of people to rude things. We'll have people using these scripts, and some of them will peek under the hood, and some of -them- will notice that the script is doing rude things. These people should be able to flag scripts as evil, and a trusted group (perhaps recruited on the basis of correct flagging) will review a queue of flagged scripts. Anything sufficiently flagged (what's sufficient? I dunno) will be unavailable in the directory until it's reviewed. Anything that's been reviewed and has the Good Webkeeping seal of approval will be exempt from flagging (or have a higher threshold, or something complicated). Things reviewed and found to be evil will be banished from the directory, along with the IP subnet and country of author. OK, maybe just the script.

Along the same lines, I'd like to have a flag that says "doesn't work", and eventually, I'd like this to be integrated in GM's client so that when people say something doesn't work, we can have a list of injected scripts for clues as to script compatibility problems (because that really is a problem, and it's only going to get worse).

Further along trust lines, there's also the idea that a script that's been out unchanged a while and followed out and unflagged is probably a good and Good script, so those scripts might get some bonus in ranking. Which leads us into actually finding the script you're looking for.

There'll be full text search (so you can see how people are using GM_* functions or find a script through a comment), there'll be header search (show all scripts which match URL x, or have name y, etc). There'll also be a tag search, which will just use delicious' tags.

So now you've got some search results. They'll be ranked by number of delicious links to start with, and maybe that'll be good enough. If not, we can throw in trust or search noise, or something else complicated.

Also, particular script versions will be available off of stable URLs on the directory. The search results will take you to the original publishing location, but if your favorite ~user/script goes down, the directory will still be there. I haven't decided what the stable URL should look like. /root/namespace/userscript seems obvious, but of course, lots of people aren't setting their namespaces, so who knows. I also plan to have all versions available, so that if /root/namespace/userscript is current, then /root/namespace/userscript/20050110-164502 was the script as of that date and time (and it'll use the normal W3 date format, of course). I dunno, maybe this isn't version 1 stuff, but I think it'd be useful to see evolutions or to have a stable pointer for some discussion and such.

That about does it for goals 1-3. But assume you're a script author, and you'd like to share your script. You just post it on your site (Or submit it to the directory for hosting? This might get complicated.) Everyone knows where to find user scripts, so it's way out there, even if you're not an A-lister. And if you change something, everyone that wanted to know will know.

Another benefit of the hash approach is that the GM client could some day support auto update by hashing its installed script and asking the directory for any updates.

We also have a situation where authors modify functionality of scripts after publishing (say, to support UPS tracking after publishing a FedEx-only linker), and an accidental benefit of the wiki has been that script authors could say what changed easily. I'd like a @longdesc so that script authors could write a book (like this one!) about how great their user script is, and the directory would scrape this so that updated functionality just shows up in search.

That's up to goal 4.

Goal 5 is a bit broader, but I'm pretty stoked to see user scripts in Opera and IE. Safari already had Pith Helmet, and we apparently didn't inspire Opera, but I don't care. I just want user scripts to be useful and for them to spread, so I'd like to do what we can to provide a home for user scripts in general, and help other projects that don't have mozdev and mozillazine to help them with hosting and community. userscript.org will start out GM-only, but I hope that changes.

This last one is months or longer out, but it seems worth doing, and I'd like to do it.

Of course I don't plan on doing all this stuff before putting something out there, and I hope you readers will tell me what I'm doing wrong, but this is the general direction I'm headed.

If anyone got to the end, congrats, and please take a few more minutes to tell me how this could better, but please keep the goals listed above in mind.

P.S. There's already been useful discussion on the mailing list. If you're interested in this stuff, I recommend you join.