[Monotone-devel] Policy branches - first steps

[Paul Crowley]

As Graydon points out, we'll learn a lot more about what direction to 
take policy branches by implementing them than by thinking about them. 
I propose we make an incremental step that will get us moving, and that 
we'll be able to build on later.

So here are the corners I want to cut to get something out now.  These 
are all things we'll want to fix in a later revision.

- Use a very simple rule to decide validity - a revision is valid if 
it's signed by one of the valid keys, no matter what its history.
- Don't try and support namespaces or branch renames - use the existing 
branch names
   (this also means that we'll enforce a tree through the namespace)
- Don't try and use policy to give users names - use existing 
infrastructure for that
   (we will want to fix this, but policy branches will be useful before 
we do)
- Use a dumb implementation of ACLs

I've checked in some sample policy branches.  I haven't used the names 
these branches would have in a real implementation, though.

"net.venge.monotone.experimental.policy-branches.examples.example-user-policy"
- should really be called "address@hidden" or another user name
- This might be a user's personal policy branch.  It delegates all 
authority on all Monotone branches to
"net.venge.monotone-policy.founder" as signed by Graydon.

"net.venge.monotone.experimental.policy-branches.examples.monotone-policy.founder"
- should really be called "net.venge.monotone-policy.founder"
- Delegates authority to "net.venge.monotone-policy.main" as signed by 
Graydon or Nathaniel

"net.venge.monotone.experimental.policy-branches.examples.monotone-policy.main"
- should really be called "net.venge.monotone-policy.main"
- has a big list of keys which are allowed to commit to any Monotone 
branch.  I got this list by running "mtn automate keys" over my local 
Monotone database.

The file format is designed to be extensible, to minimize the need for 
backward incompatible changes.  I'll go through an example now.

 * ./README

Each policy can contain a human-readable README file.

 * ./version_1

The rest of the policy lives under this directory.  This gives us the 
freedom to add new names at the top level without worrying about collisions

 * ./version_1/monotone

This is a policy.  The name is arbitrary - you can call a policy 
anything you like, the system ignores it.  A policy branch can contain 
more than one policy

 * ./version_1/monotone/branches

A directory that lists the branch names the policy refers to

 * ./version_1/monotone/branches/net.venge.monotone

As far as I know a branch name can contain any character, so rather than 
using a filename to reference them we use the contents of a file.  For 
clarity this file has the same name as content, but you can call the 
file anything, the system doesn't care.  If you want to reference two 
branches, create two files.

 * ./version_1/monotone/branch_prefixes

This is similar to branches, but it states that the policy applies to 
all branches that have a particular prefix.  No branch_prefix in a 
policy may be a prefix of any branch_prefix or branch anywhere else in 
that policy branch.

 * ./version_1/monotone/branch_prefixes/net.venge.monotone.

Again, it is the contents of the file that specify the prefix rather 
than the name.  Note that this policy does not apply to, for example, 
net.venge.monotone-viz.  Because net.venge.monotone-viz is a prefix of 
net.venge.monotone, we have to support both naming explicit branches and 
naming prefixes, and we have to let the same policy apply to both.

 * ./version_1/monotone/defer_to

States which policy branch this policy defers all decisions to.  This 
must be a branch for which policy is specified elsewhere in the policy 
branch, as in the examples.

defer_to is present in, for example, the founder branch.  In the main 
branch we have something different:

 * version_1/monotone/head

sets direct conditions that revisions must meet in order to be 
considered part of the "head" of monotone.  The idea is that we can 
later add, for example, conditions on the ancestry.

 * version_1/monotone/head/any_of

In order to be considered part of the head, it must be signed by any of 
the keys in this directory

 * version_1/monotone/head/any_of/475b5e52f544b996f657c143b897287b87b61978

The file contains a key fingerprint.  Again, the name of the file is 
arbitrary; for convenience it has the same name as content.

ACLs: I imagine that for a first pass, the user will simply specify the 
name and keys for their personal policy branch in their .monotonerc. 
Again, we can think about greater sophistication later.

This is all of course highly provisional.  It's only a proposal. 
However, hopefully a fully-worked proposal on how we can move things 
forward will help.
--
  __
\/ o\ Paul Crowley, address@hidden
/\__/ http://www.ciphergoth.org/