My apologies for having been absent for over a month and a half!  Yow.
 First I moved, then work caught up with me, and then I fell into a
deep winter hibernation.

My thanks to Tom Lord for his insightful comments and to Tony
Garnock-Jones for posting the references to the Petname System and
Zooko's Triangle.

  http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
  http://www.zooko.com/distnames.html

It took me a while to read and absorb the material.  Now that I have,
I find the arguments of Petname system quite compelling and a great
improvement over my current proposal.

While I encourage everyone to read the article, to briefly recap:

In the Petname system, the "nickname" of something is the public,
published, human readable name: "PLT Scheme", "SLIB", "Andrew Wilcox",
"Spiffy web server".

Search engines such as Google often do a good job of letting you type
in a nickname and finding the things that have that name.

Nicknames are not unique: lots of people have the name "Andrew Wilcox".

Nicknames are not secure: anyone can publish a name that might be
confused with "Andrew Wilcox" and thus leave you open to phrishing
attacks:  "Andrew Wi1cox".

Something can have multiple nicknames: "Spiffy web server", "Spiffy",
"Spiffy Egg".

Nicknames can even be misspelled.  I type in "Spify web server" and
Google says, "did you mean 'Spiffy web server'?"

The "petname" is the unqiue name that I personally give to something.
I am free to choose whatever name I wish.  I might choose "slib", or
"scheme-slib", or "jaffer-slib", or "the-standard-scheme-slib".
Whatever name that makes sense to me and disambiguates the SLIB
library from anything else in my life that I'm working with that might
also me called "slib".

The "key" is a cryptographically secure, unique, unforgable, computer
readable identifier.  At any one time, the petnames in my personal
system refer to one and only one key, and no key has more than one
petname.

An essential feature of the petname system is that the correspondence
between keys and petnames is *bidirectional*.  Whenever information is
displayed that has an item with a key corresponding to one of your
personal petnames, your petname is shown.

(I'm not sure I like the terminology of "nickname" and "petname", but
I'll let that pass for now...)

So far I have the following thoughts.

On the SRFI-83 R6RS Library Syntax mailing list, Michael Sperber
described his interpretation of the SRFI as a distribution format:

> The idea is that you send this stuff to your friends or download it
> from somewhere, and then let your Scheme implementation slurp it
> into its package library or whatever, possibly (and probably)
> translating it into a format more suitable for its internal
> processing.  [...]
>
> I don't expect PLT Scheme or Chez or Scheme 48 to change their
> module systems much or to stop developing new ones as a result of
> this SRFI---rather I expect that their authors will implement
> "translators" from and to the distribution format specified here.

As a distribution format, my first thought was that keys would be the
natural thing to use to refer to the library name and whatever
libraries it imports.

When I received a library, in raw form it might look something like

   (library a673482b8a1e23... 7812abe317...
      (import 87a16327dea2...)
      ...)

(where these hex digits are supposed to suggest keys, although I don't
actually know what keys would look like).

On my personal system, I can map these keys to whatever petnames I want.

For example, suppose 7812abe317... was the key for R6RS.

If I dislike URI's, in my system I can map 7812abe317... to 'r6rs.

Someone else who wanted to could map 7812abe317... to "scheme://r6rs"
on their system, if that's what worked for them.

(Personally, I think Scheme symbols are natural to use for petnames,
but it's not a problem if someone else wants to use strings for their
petnames).

If on my personal system I had mapped these keys to my personal
petnames of 'spiffy, 'r6rs", and 'srfi-1, when I looked at the library
I would see:

   (library spiffy r6rs
      (import srfi-1)
      ...)

An essential feature of petnames is that they are bidirectional.
Let's say I make some changes to the source and send them to you.  My
personal petnames get replaced with their corresponding keys.  On your
system, they get transformed into your petnames.

Here are some advantages I see over my current proposal:

There are no problems with my losing my domain name or changing my web
site address.

We completely separate out the issue of cataloging and categorizing
libraries.  If I want to create a deeply hierarchical library catalog
and you want to create a wide and flat one, we can both go ahead and
do it.

The petname system seems to me to be conceptually simpler.  (Not
simpler as necessarily easier to understand: each part may have a
steeper learning curve... but simpler in that the parts are better
separated and fit together well).

Then I have some questions...

Is there a crypto key generating system we can use today?

Suppose when I say

   (import 87a16327dea2...)

that I'm referring not to a specific implementation of SRFI-1, but
instead to SRFI-1 as an API.

When I send you my library of code that uses SRFI-1, I'm not saying
you have to use the exact implementation of SRFI-1 in my Scheme
system, I'm saying go ahead and use whatever is the best
implementation of SRFI-1 on your system.

In such a scenario, does 87a16327dea2... need to be a
cryptographically secure key instead of for example just a UUID?  If
it does need to be cryptographically secure, what am I protecting?

Suppose I were to say that "Andrew's Super-Lister library is a
faithful implementation of SRFI-1 and does not steal your credit cards
or format your hard disk".  Such an assertion we *would* want to make
cryptographically secure.  You'd want to know that it was really me
saying it, and that the library you got was actually the Super-Lister
library I was referring to.

But if I'm just looking for a unique identifier to refer to "the
SRFI-1 API", would a UUID be good enough?

Andrew