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

[Wim Oudshoorn]

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



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.

Now I understan that the following scenario could happen:

1 - mallory has commit access to the project according 
    to current trust rules
2 - Mallor kicks everyone out and syncs with the project 
    database
3 - Nobody can do anything anymore.  Not even fork.

However, I do think that these situations should be resolved
by the owner of the project database.  Just leave commit 
access to the database open always, just so we can keep
on working in this event seems not the right approach to me.

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

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

Wim Oudshoorn.