Re: [Monotone-devel] Re: [RFC] versioned policy -- bootstrapping

[Timothy Brownawell]

On Sun, 2006-09-10 at 14:01 +0200, Wim Oudshoorn wrote:
> Nathaniel Smith <address@hidden> writes:
> 
> > (For archive readers: this should be read after
> >   http://article.gmane.org/gmane.comp.version-control.monotone.devel/8169
> > )
> 
> > Another try
> > -----------
> >
> > Here's an algorithm that does work:
> >
> > Call a revision R with cert C "trivially reachable" from some other
> > revision S, if R is a descendent of S, and C is a cert trusted by S
> > which claims that R is in the policy branch.  Trivial reachability
> > defines an overlay graph on the revision graph, where you draw an edge
> > between two nodes when one is trivially reachable from the other.
> > It's the heads in _this_ graph which form our candidate set, and full
> > reachability is simply equivalent to reachability in this graph.
> 
> Hm, why like this?  What about the following:
> 
> Let G be the DAG that is the monotone repository containing the policy
> revisisions.
> 
> let T(G) be the trust DAG of G.  That is, let the  nodes of T(G) be the
> nodes in G and the edges of T(G) consist of:
> 
> Edges (T(G)) := {R -> S | if R->S is an edge in G AND R trusts S}
> 
> Now we do more or less what you propose, 
> let TF (the trust frontier) be defined as
> 
> TF (S, G)  = {all revisions R in T(G) such that there is 
>               a path from S to R in T(G) and R does
>               not have descendents in T(G)}
> 
> Or in other words TF (S, G) consists of all maximal elements
> in the PO-set induced by T(G) greater than S.
> 
> 
> Now back to your example:
> 
>              A  <- Alice and Mallory access
>              |
>              B  <- Only Alice access, signed by Alice
> 
> Now if Mallory wants to fork, it has to commit a descendant
> of A not B to get the same effect.  
> 
> Oh and TF (S, G) trivally satisfies your (*) condition
> (at least as far as I understood your condition.)

This seems more like what I remember being suggested in earlier
discussion as the trust branch algorithm, rather than the certs thing.
It also seems nicer; was it disqualified for some reason I don't see?

> GENERAL REMARK
> --------------
> Oh, and I don't like the fact that everyone who ever had commit
> access could always stall the project.  
> 
> I want that if I distrust Mallory, that all revisions signed
> by him will NOT enter my database.

There are different levels of trust/distrust. That's why admin
permissions, commit permissions (so that the commit is visible), and
netsync permissions (whether it even gets to your database) should all
be different.

> Also I don't like it that the decision who to trust, by picking a new
> trust seed, is forced on all users.
> When I am a user, I more or less trusts the owner of the database I sync with.
> He can do whatever he wants with his database, if he is evil, he can just
> stuff the database with useless data or just take it off-line.  
> So I have a basic trust in the owner.

Well, this would be one of the UI issues mentioned in the other post. A
sane way to handle initial setup would be to ask the server what its
trust seed is, and use that.

> If mallory wants to fork and
> Alice the owner does not agree, let mallory start his owner server
> and I will connect to that one.  

What if the server is owned by someone else (shared hosting site,
maybe), who wants to serve both forks?

> Furthermore, if there are two rival branches, I as a user might
> want to sync with them both.  So how is that managed?

Probably by having something like a trust seed <=> project name mapping
in a file under ~/.monotone . You can say you trust both forks, but
would probably have to (locally) override the name that one of them
wanted.

Tim
-- 
Free (experimental) public monotone hosting: http://mtn-host.prjek.net