Re: [Monotone-devel] long RFC: "contexts"

[Jon Bright]

Christof Petig wrote:

> I was not quite sold to context IDs (which simply adds _another_ unique 
> ID for hash(id+[ancestry/timestamp])) unless I realized that they make 
> edge certs (!) possible.

Hm, well monotone doesn't already have an ID on this?  The lack of 
ancestry hashes makes loops possible, and leads to various hateful 
effects...

> More ID namespaces will not make it more easy to understand monotones 
> concepts but edge certs are the way other VC systems work. Perhaps 
> designing them as edge IDs (hash(id+ancestry[+timestamp])) instead of 
> hash(a big context text blob which even contains changelog) would be 
> even more desirable.

I'd actually be relatively in favour of not troubling the user with 
manifest IDs at all.  Could not pretty much all monotone operations 
which currently take a manifest ID operate equally well with a context 
ID (/edge ID)?  Only one concept to explain to the user.  Am I missing 
something?

> Though there's no easy way to edit a changelog afterwards once the 
> information is stored in the combined form [disadvantage of the 
> combination].

At least for my way of working, this is an advantage.  You can add 
*more* changelog afterwards pointing out errors in the original or 
expanding on its content, and have that in a second commit (or a cert). 
 But the original is still there and everyone can refer to it. 
Allowing editing of the original changelog introduces a non-versioned 
element into the system, which for a versioning system, has to be a bad 
thing?

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com