I seem to remember there being a request for private messages in the forum. If we really want this feature (and I really doubt we do), the only way I can think to do it within the architecture we have is to encrypt the private message using the recipient's public key. The recipient can then decrypt using the corresponding private key.

For this to work, Fossil would need to be extended to store each participating user's public key. As a convenience, Fossil could store private keys as well, but only if those private keys are themselves encrypted with a passphrase known only to the user.

Aside from enabling private messages, this feature could be used to sign manifests and other artifacts. Fossil already has PGP support, though I'm not sure it still works because I don't see anyone using it. (Update: drh uses it for TH3)

Perhaps Fossil could implement its own signature system so as to avoid depending on PGP. We've already got good SHA* code, we wouldn't have to worry about PKI or trust or anything beyond the one keyring, and we wouldn't have to be PGP-compatible. Though we'd need to add AES code. We probably would also want Fossil to be capable of generating keys in the first place, which means picking huge prime numbers and so forth. (Last year I successfully implemented all this same stuff in Tcl using the Tcllib pki module, so I know it can be done.)

Fossil could reject artifacts lacking a signature, having an invalid signature, or signed by someone whose public key is (no longer) in the keyring.

For extra fanciness, Fossil could also reject artifacts that accomplish a change the signing user doesn't have permission to make. For example, maybe a project might want only certain people to be able to modify certain directories, or commit to certain branches, or create/modify symbolic tags matching (or not matching) certain regular expressions, or edit certain wiki pages, or post to certain sub-forums (assuming we'll get that feature someday), or change tickets from/to certain states, etc.

This is a big can of worms, for many reasons. It's a massive increase in the complexity of the capability system. I imagine rules might be written in TH1.

Should a user try to change a file that user isn't allowed to change, or do anything else that's not permitted, the Fossil client would have to reject the commit (or artifact) without ever trying to push it to the server. Otherwise forks will be created which cannot be sync'ed upstream, just like when a user doesn't have blanket commit access and tries to commit anyway. Yet, if the client and server disagree on user capabilities, this problem will occur anyway. Maybe this could be solved by sync'ing the user capabilities and associated rules during the pull that occurs just before actually performing the commit. That might end up being a lot of data to repeatedly fling around, becoming a problem unto itself.

The ability to create forum posts, wiki pages, etc. can currently be limited by capabilities. In addition to the web interface being hidden when denied, I imagine the current Fossil server rejects artifacts matching those schemas (formats) corresponding to capabilities denied to the user. Otherwise anyone could push forum posts, etc. they're not allowed to make, just by granting themselves the necessary capabilities in their local clone, then sync'ing upstream. If my guess is correct (and I'm not curious enough to try it myself right now), it's not possible for a user who is not allowed to create forum posts to push upstream forum posts made by another person who legitimately has that capability. Furthermore, someone who does have that capability can push upstream forum posts made by someone who doesn't. Having the individual artifacts be signed by their originator and accepted/rejected according to capabilities associated with the signature key (rather than the person doing the push) could solve these issues.

One more thought on private messages. Only mirrors/backups would be interested in downloading encrypted artifacts they will never be able to read. Everyone else would probably prefer to not receive encrypted artifacts for which they don't have the key. However, this determination is a bit tricky. Just because an artifact resembles an encrypted private message doesn't mean it's not a checked-in file. Thus some graph analysis would be needed to check if the artifact is unreferenced by any manifest (or ticket or wiki or forum attachment, etc.), in addition to checking if its schema corresponds to private message (or more generically, encrypted artifact), and cannot be decrypted by the user's private key (or doesn't contain the user's name, public key, or fingerprint, depending on how we design the format). One possible approach would be to have the private message and its "envelope" be separate artifacts. The private message would be a blob that only gets sync'ed if referenced by something other than what's recognized as an unopenable envelope. There's a lot involved here.

Okay, another thought on private messages. How would they ever be deleted? If only the recipient can read them, the recipient might decide they are no longer of use and ask that they be deleted. How does that delete operation propagate through the network? I'd hate to have to invoke the shun logic for this. Does a non-nuclear option exist?

And a third thought. I know it's possible to encrypt a message such that it can be decrypted by multiple private keys. (I'm pretty sure the algorithm is to use AES, etc. symmetric encryption for the message then asymmetrically encrypt the randomly-chosen AES key using each private key.) I'm pretty sure we'll want private messages to be readable not only by the recipient but also the sender. So if we already have to implement two people being able to read a message, why not more? This gets really fancy really quick.

There's a lot of bloat and complexity here, and my ideas are all half-baked or worse. But they are ideas I wish to write down and share.

I think the bottom line is we don't want this stuff, yet it seems exciting enough to me that maybe it can nevertheless be kept as a back-of-the-mind goal to gradually work toward in the years to come. In particular, prior to widespread adoption of Fossil, my organization would need much tighter control of permissions, such as the examples given above.