[Greasemonkey] Goals for the user script directory (very long)

Jeremy Dunck jdunck at gmail.com
Fri Apr 8 02:07:55 EDT 2005


I can see from the UI design thread that there's some confusion as to
what I'm hoping to do with the user script directory.

I'm open to suggestions, but I'm also writing code, so if you think
I'm doing something wrong, convince me.  :)

Goals:
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.

Assuming we can agree on these goals, here's how I plan to address them.

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).

But 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
exposing lots of people to rude things.  So 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.

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.

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).

(As a side note, this isn't a bad read on the sort of problem we have
here, although I didn't find anything I could directly map for a
solution in GM:
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=286
)

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 IETF/whatever 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?).  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 guys will tear it apart and tell
me what I'm doing wrong, but this is the direction I'm headed.

If anyone got to the end, congrats, and please take a few more minutes
to beat on this and make it better.

Thanks for your involvement,
  Jeremy


More information about the Greasemonkey mailing list