This page is part of the web mail archives of SRFI 84 from before July 7th, 2015. The new archives for SRFI 84 contain all messages, not just those from before July 7th, 2015.
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. ;-))