This is fairly heavily based on http://www.venge.net/monotone/wiki/VersionedPolicy .
Here I'm assuming that we want to allow multiple projects (trust seeds) per db. I think that not allowing this is overly restrictive and probably unworkable, and especially not workable for shared hosting. This allows for both hierarchical branch renaming and project renaming. It also allows for project names to be forced, in case of a collision. It allows for anyone to merge the policy branch, as long as they have permission to edit any files that have conflicts. ==================== policy branch: /policy-root -- file with the base policy rules; delegates -- authority (including the authority to change -- this file) to certain users /name -- file containing the default name of this project /users/ -- directory containing user directories /users/foo/ -- user directory for 'foo' /users/foo/rules -- file with policy rules authorized by 'foo' /users/foo/keys -- file listing keys that 'foo' owns /users/foo/* -- random other user data (name, IRC nick, ...) /servers/ -- like /users/, but for servers instead of people /servers/foo/keys -- keys that this server might use /servers/foo/admin -- says who can change this server's info; -- should be whoever has shell access to the -- server process /servers/foo/branches -- what branches are served (globs/ids/etc) /servers/foo/address -- DNS name / IP address of this server /servers/foo/rules -- a *copy of* the rules this server uses to -- accept/drop incoming revisions; for sanity -- this should not be less permissive than -- project commit policy. The *actual* rules -- are in a file on the server; this is just -- informative, so people know what to send /servers/foo/* -- random other server data /branches/ -- representation of the branch hierarchy /branches/foo/ -- directory for branch foo /branches/foo:id -- used in branch certs /branches/foo:status -- used for marking branches as finished /branches/foo/* -- random branch metadata /branches/foo/*/ -- subbranches of foo /branches/foo/bar:import -- (instead of having :id) give the id -- of another projects (policy branch), -- whose branches are to be included -- under this name /keys/ -- directory holding key data /keys/[EMAIL PROTECTED] -- pubkey packet /keys/REVOKED/ -- directory that revoked keys get moved to /keys/REVOKED/<id>/pubkey -- revoked key /keys/REVOKED/<id>/valid -- valid certs signed by that key Should /users/*/keys and /servers/*/keys be hashes or names? Files under /keys/ are immutable. (possible exception for REVOKED/*/valid ?) /users/foo/rules is *only* editable by foo. /servers/bar/* is *only* editable by the server admin. Revisions which violate this are ignored completely (dropped at sync time?) as inconsistent, and there is no commit switch to allow such commits. /users/foo/keys should probably be editably by (some) admins (what if your key gets lost, say by disk failure?), but how to prevent them impersonating someone? Maybe say that if you hold any private keys for a user, and the keys file for that user is edited by someone using a key not listed in the pre-edit version of it, monotone will print a big fat warning for you? /policy-root is only editable by people given that permission. If someone else edits it (this requires a commit switch to enable), there is a silent fork. If two admins edit it to exclude eachother, there is a noisy fork (all users are informed and must choose which side to accept). The previous three paragraphs use the permissions and identities from the parent revision. Other checks use those from the current revision. If a file other than /policy-root is edited by someone without permission, that revision is silently ignored (dropped at sync time?) as inconsistent. Such commits are refused, and there is no override switch (the "override" is to edit /policy-root to give yourself permission). Anyone can do a clean merge of the policy branch. Anyone can do a non-clean merge of the policy branch, provided that only files they are permitted to edit have conflicts (this includes automatically resolvable conflicts). Specifically, a node (file/dir) in the policy branch is acceptable if at least one mark from each set (name, content, each attr) is from a revision signed (branch cert) by someone authorized (or enough of the right someones) at that time to edit that node; a revision on the policy branch is acceptable if all its nodes are acceptable. Once we have the subgraph of acceptable policy branch revisions, we can pick which one to use (the simplest way is "use the head; if there are multiple heads, throw an error", but this wouldn't work for the Alice/Tom situation in njs' bootstrapping email.). branch certs would be of the form "<project id> <branch id>". branch certs for policy branches are "<project id>" (ie, empty branch id). There are db vars giving the trust seed for each project id. These are made available over netsync, but not routinely actually sent (or maybe the are always sent, but not stored; they just cause the client to print a message if they differ). Each policy branch has /name that says what name it wants; if two projects want the same name an advanced user could override this with a db var project id <=> project name. branch names would be displayed as <project name>.<branch name>, possibly with the ability to omit the project name if the project is already known. ==================== commit should take a --new-project=(given|wizard) switch, saying that either what is being committed is a new policy branch and should be given a new project id, or that what is being committed is a normal branch, and monotone should ask a few questions and generate a new policy branch to use. --new-project=given is also what you'd use for a friendly fork. Ideally it would also be (eventually) used on one side of an antagonistic fork, so both sides could be trusted in the same db. There should also be a "mtn new_project" command, that just asks questions and generates a new policy branch. Netsync should allow queries of "what project id does this name map to" (also the "what trust seed does this project id map to" mentioned earlier). These would be useful for initial pull, or if the user wanted to defer to the admin of their chosen netsync server in choosing a side of any antagonistic forks. Tim -- Free (experimental) public monotone hosting: http://mtn-host.prjek.net _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel