[Monotone-devel] Re: Server up

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Mon, 09 Aug 2004 09:49:30 -0400, "graydon hoare" 
<address@hidden> said:

graydon> On Mon, 09 Aug 2004 12:05:25 +0200 (CEST), Richard Levitte - VMS 
Whacker <address@hidden> wrote:
graydon> 
graydon> > As far as I can see, having the keys be identified by hash
graydon> > rather than key identity would only require the following:
graydon> >
graydon> >  - have id in manifest_certs be the key+id hash (i.e. the
graydon> >    corresponding 'hash' from public_keys) rather than the
graydon> >    id.
graydon> >  - have id in file_certs be the key+id hash rather than the
graydon> >    id.
graydon> >  - change whatever code that depends on the above two
graydon> >    changes.
graydon> 
graydon> yeah. I'll probably be doing this on the changeset branch
graydon> (which is going to invalidate/re-issue all existing certs
graydon> anyways). the use of string identifiers for keys was a
graydon> mistake; I initially thought we'd do key management entirely
graydon> "out of band", but that's turned out to be less useful than
graydon> just content addressing them too (which I bolted on the
graydon> 'hash' field for). it should really assume the name role too,
graydon> in certs, I just didn't want to break all the certs until it
graydon> was strictly necessary.

Note that I'm not saying the UI should be much different.  "list
certs" should still display human-readable identifiers, "genkey"
should still take one, and so on.  The most user-visible change could
possibly be that a hook will get an id as a <str,hash> pair instead of
just a string...

I'm not sure what a "name role" would be in this context...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/