Basically, what I want to do is glue together a tool-chain that creates/manages/interacts with a maildir folder, which would be tucked inside a git repository. Every message would be encrypted. Inside the repo would be all of the public keys of the participants. When you post, you're posting an encrypted message to the maildir folder(s). Then, the toolchain does a fetch from whichever repos you have it set up to automatically interact with, merges in your changes, and pushes it back to those repos. If new people get added in, the toolchain prompts you to re-encrypt your older messages with the new user's key, assuming they have gained enough signatures to pass the web-of-trust test (or you have signed their key.)

The idea is to accomplish a few things.

1. A fully encrypted messageboard, adaptable to the addition of new participants.
2. Independent of any network. Theoretically, the entire "network" could be sneaker-net. Of course this also means it would be distributed, in the same sense that git is distributed.
3. Robust, both in the hard-to-spoof sense and in the extremely-hard-to-shut-down-by-force sense. GPG will provide the former, while git will provide the latter.
4. Encapsulated. The entire package (probably sans GPG because of export restrictions, but the installer could get that from the web or prompt the user for the executable directory) should be in the git repository, and it should be platform-independent.
5. Dead easy. The default settings should provide acceptable levels of encryption security. The user should be prompted to make a key or import one, and the only other interaction the "uninitiated" user should have with GPG directly would be entering the passphrase or occasionally the prompt to re-encrypt older posts. Likewise, git interaction should have a "un-savvy user" mode which does everything automagically. Then as the user needs more access, they would need to learn how to do more advanced stuff like sign keys, etc. Advanced users would do things like add/remove repo URLs from the list, manage the repo's self-contained documentation/wiki/whatever, be able to customize the repo settings (if someone made a naughty commit, it could be rolled back, which is good.)
6. Encryption should be enforced at the email-client level. There should be no easy way to use the tools in the toolchain to put an unencrypted message in the maildir. Obviously, if the user used some other email client to interact with the maildir folder, then they could put unencrypted messages into it, but this would take purposeful action.
7. Because git uses ssh for it's net interactions, there would be no need for the messageboard to ever be sent unencrypted through a computer network. It would (or could) be essentially invisible, even if it used the Internet for transmission (as long as no-one posts the repo to Github.)

The system would not scale gracefully as far as the size of the maildir. However, a purge mechanism could be built in to remove from the git branch any message files older than X days and do a

git gc --prune=now

which would then filter through all the clones as the users' toolchains did git-pulls.

I'd love to eventually get to the point where a user could run a command to create a bootable linux image, which would have his/her private key, OR a new private key (for bootstrapping a new user) and a clone of the repository, so that at any point, the user could boot a CD and the scripts would pull from origin (or many repositories) into a RAMdisk, let the user do his thing, then when finished push to origin (or many repositories.) Only the user's private key would need to be on the image, because any time a user signs another person's key, that signed key would be stored in the repository, so any and all keys would be loaded into the keyring upon pulling the repo next time they booted the CD. Booting linux this way would be far more secure cryptographically than running the toolchain under Windows (because Windows can't be convinced not to write the contents of RAM out to the harddrive, and because keyloggers, and spyware, and viruses, and nasty invasive admin auditing tools, and a thousand other little "gotchas.") In fact, I'm tempted to stick solely to linux for the entire project. But it would be more useful, and therefore more used, if it were cross-platform.

I'm aware that the weak link in the system is that each new person makes the repository more vulnerable to being compromised, and that one user with a crappy password could compromise the entire repo for everyone. But that's always been the case with PGP, and it's why web-of-trust is such an important part of GnuPG. So it doesn't change anything one way or another as far as that goes, it just makes the imperative for solid web-of-trust management more visible.

At it's most basic, it would need:

• Git
• GnuPG
• a mail program (MUA) that speaks GnuPG and can be configured to require encryption
• a MTA (OfflineImap?) that can fetch mail from and send mail to maildir
• Some custom scripts to handle things like automagic git interactions, automatic GnuPG interactions, git database cleanup, and overall repository setup/maintenance. Essentially nothing that couldn't be handled with shell scripting, or Python/Ruby.

A slightly more involved project would be:

• Git
• GnuPG
• Ruby (RVM, so it would be a self-contained ruby installation)
• Rails
• All interactions would be via RubyOnRails; one command/launcher would fire up the rails application and launch the browser pointed at localhost, and the rails app would handle every interaction with any settings or auxilliary files, Git, GnuPG, and maildir (or whatever; using RubyonRails would allow for some seriously entertaining scenarios.)

So does anyone else think this is a good idea? Anyone see any major flaws? Should I kick off a github repo, or stew on this one for a bit longer?