Thanks, Alex.   Rather than reply point-by-point here's this:

In GNU Arch 1.x we have, I claim, decentralized + human-readable +
secure names.  The design has some imperfections so I won't defend it
in every detail.  It basically works, though, and suggests a paradigm.
I'll describe the paradigm in idealized terms so as not to get hung up
in the flaws in Arch.

We again start with the idea of an infinite tree-topology
name-space in which ownership can be assigned (recursively)
to subtrees:

		community-sentiment
                  /      |      \
               top-level authorities
               /   |     |     |    \
              names and sub-authorities
                       ...

To be decentralized we must allow authorities to self-nominate.

To be secure, that self-nomination must be based on a public key.

To be human-readable, we can not (normally) use the text of the
public key itself as the name of an authority.

So:

  By convention -- community sentiment -- we start with a generative
  grammar for human-readable names with the property that it is easy
  for people to make accidental collisions unlikely and malicious
  collisions clearly apparent as such.  The current SRFI-84 draft does
  such but also goes further (too far?) by creating specially
  privileged top-level authorities and by failing to allow people to
  self-nominate as new authorities without paying perpetual tribute to
  the privileged authorities.

  By standard, define a way for self-appointing naming authorities to
  issue certificates which bind public keys to names within the
  context.  Of course there may arise contention, though in practice
  there is little legitimate need for such.  When contention arises,
  we fall back to the community sentiment to form a consensus about
  which competing claim is true.  The role of crypto here is simply
  to give the community an objective basis on which to recognize and
  discuss the contention.

  As a pragmatic matter, communication falls into the classes
  "formal" and "informal".   Where formal communication is called
  for, certificates are explicitly referred to and tools are available
  to see that they are applied correctly.  In informal discourse,
  the human-readable names enough.   In other words, in talking at
  the conference on software for missile launching I'll just say
  `foo:bar' and people know what I mean.  But in the paper in the
  proceedings and in the link-loader for my software -- I'll use
  the keys, thank you very much.

It turns out that some folks are way ahead of us on systems like this.
This paper is well written and appears to be a good entre to the
literature:

   http://theory.lcs.mit.edu/~rivest/ClarkeElElFrMoRi-
CertificateChainDiscoveryInSPKISDSI.ps

 If we accept the general thrust of what I'm saying then we can ask
 about the proper form and function of this SRFI.   Should it say
 anything about certificates?  Should it privilege some short-hands
 over others?

 I've got my own opinions about such questions but I'm not terribly
 interested in trying to argue anyone into them.   I'm content to
 raise contextual awareness and to be seeing some contemplation of the
 issues going on.

-t

p.s.: one last thing that doesn't quite fit into the above but
responds to Alex:

  Yes, there is a difference between securing the named thing,
  securing the binding of name to name thing, and securing the
  name itself.

  I'm interested here in the issue of securing the name itself --
  in other words, allowing a decentralized yet secure process
  to create new nouns and refer to those nouns unambiguously.
  The binding problem (names to meaning) and ontology thing
  (identities of the named things) are separate.   Securing
  names seems to me a prerequisite, though, for solving the
  binding and identity problems.

  What a mouthful.  I need a gin an tonic.   Mmmm.... `Quine'ine.
  :-)   (Sorry. ;-))