We need a more systematic way to deal with trust in monotone, including delegation ("let the maintainers worry about who gets commit access, I just want to submit patches"), revocation, and such things.
Use cases
Requirements
A clear separation should be made between the concepts of "identity trust" (this key really belongs to the claimed owner) and "authority trust" (the person/owner/key can perform these actions). In the monotone world, where statements move around like gossip, performing an action is equivalent to having particular certs trusted for the given purpose, such as branch membership. I can be very sure of a person's identity, and trust them for nothing.
Identity trust might look like a gpg-style web of trust (or be delegated to it, by having monotone certs signed by well-connected gpg keys). Representation of authority trust depends very heavily upon monotone design (not pki design) in terms of what the trusted statements should mean from each db and users perspective.
Possible designs
trust seeds
check in
Make trust information (only) available on a centralized server -- when online, fetch the latest trust info. It should stay good while you're offline, since it remains as up to date as your actual code...
trustbot
Everyone trusts the trustbot! The trustbot doesn't trust everyone. But people that the trustbot trusts, get their certs automatically re-signed by the trustbot.
Do not anger the trustbot, or they might stop signing your certs!
Relevant links
SPKI: http://world.std.com/~cme/html/spki.html
One discussion: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-11-03,Thu#l176