[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] [RFC] versioned policy -- introduction
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] [RFC] versioned policy -- introduction |
Date: |
Thu, 7 Sep 2006 02:24:06 -0700 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
On Thu, Sep 07, 2006 at 10:21:35AM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Thu, 7 Sep 2006 00:42:36 -0700, Nathaniel
> Smith <address@hidden> said:
>
> njs> It's important that a community has a shared vocabulary for
> njs> referencing objects. I'll suppress my impulse to go off on a
> njs> long digression about the relation between this goal and pet
> njs> names systems, SPKI, blah blah blah, but basically the point is
> njs> that no-one is going to use key hashes to see who committed that
> njs> last change, and the group has to agree on these names so they
> njs> can talk to each other.
>
> I am not suggesting changing the user's experience at all, except to
> make it possible to create a new key with the same name (for example
> to follow up on revocation). All I'm suggesting is that instead of
> having an internal storage and structure like this:
>
> key name -> key object
>
> we could (and should, in my opinion) have the following:
>
> key name -> key hash -> key object
>
> I don't know exactly how the schema would look to implement that,
> how's this for a first guess:
[...]
> As to the private keys, they could be stored on disk as they are
> today, that doesn't matter much, the really truly important thing is
> that a NAME should be able to point to more than one KEY, at least if
> we're going to have any chance at replacing keys that have revoked for
> any reason. Whether names are globally or locally unique is
> irrelevant, the name will never be local enough when revocation
> happens.
They will be if renaming is possible. The versioned policy approach
is to put the key-name -> key-object mappings (with or without
intermediate hash value) into an ordinary versioned tree on a special
branch, and the latest version (under some definition) of that branch
always describes the mappings that are in place at a given time.
What you're describing sounds like a totally different approach -- I
can't quite tell from your email if you're intending it to be a
competing proposal, or?
-- Nathaniel
--
.i dei jitfa fanmo xatra
- [Monotone-devel] [RFC] versioned policy -- introduction, Nathaniel Smith, 2006/09/07
- Re: [Monotone-devel] [RFC] versioned policy -- introduction, Richard Levitte - VMS Whacker, 2006/09/07
- Re: [Monotone-devel] [RFC] versioned policy -- introduction, Richard Levitte - VMS Whacker, 2006/09/07
- Re: [Monotone-devel] [RFC] versioned policy -- introduction, Daniel Carosone, 2006/09/07
- Re: [Monotone-devel] [RFC] versioned policy -- introduction, Nathaniel Smith, 2006/09/07
- Re: [Monotone-devel] [RFC] versioned policy -- introduction, Richard Levitte - VMS Whacker, 2006/09/07
- Re: [Monotone-devel] [RFC] versioned policy -- introduction,
Nathaniel Smith <=
- Re: [Monotone-devel] [RFC] versioned policy -- introduction, Justin Patrin, 2006/09/07
- Re: [Monotone-devel] [RFC] versioned policy -- introduction, Nathaniel Smith, 2006/09/08
Re: [Monotone-devel] [RFC] versioned policy -- introduction, Thomas Keller, 2006/09/07
- [Monotone-devel] Re: [RFC] versioned policy -- introduction, Koen Kooi, 2006/09/07
- Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction, Thomas Moschny, 2006/09/07
- Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction, Nathaniel Smith, 2006/09/07
- Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction, Daniel Carosone, 2006/09/07
- Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction, Nathaniel Smith, 2006/09/08
- Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction, Daniel Carosone, 2006/09/08
Re: [Monotone-devel] [RFC] versioned policy -- introduction, Nathaniel Smith, 2006/09/07