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