Homegrown ``identity management'' for irreverent tech collectives.

*** _users

For couchdb, we use the built-in user database, which allows for authentication tokens. This simply tracks id/password, and allows us to avoid storing plaintext passwords anywhere.

*** the_truth

We will have a dynamic interface by storing instructional metadata within couch:

A databsae with these types should be immutably visable to every user:

person - id ([a-z_]) - cabals - email - joined-date - parent - pubkeyssh - pubkey_gpg - status: (REQUEST | PENDING | ACTIVE | DELETED)

transaction - date - from: FOREIGN_KEY(person) || recipient - to: FOREIGN_KEY(person) || recipient - responsible: FOREIGN_KEY(person || cabal) - amount (USD) - note - status: (REQUEST | PENDING | CONFIRMED | CANCELED)

volume - _id ([a-z_]) - size - used-size - owner - status: (REQUEST | PENDING | ACTIVE | DELETED)

container - _id ([a-z_]) - volumes: [FOREIGN_KEY(volume)] - owner - status: (REQUEST | PENDING | ACTIVE | DELETED)

*** ${PERSON}-db

Additionally, each user has their own database that only they can read/write, where they can make requests and send commands, which mirror the doctype in the master DB:

person transaction volume

The fields very closely mirror those in the master db, but may also include an ERROR field if they are not accepted into mainline.

*** ${VOLUME}-db

There is also a database for each volume with metadata for the files, such that experimental and search interfaces can be created.

file id: path - parent: FOREIGNKEY(folder) - size - user - groups - md5

folder - id: path - parent: FOREIGNKEY(folder) - user - groups

XXX: It's easy to imagine renaming files based on a hook here, but

if folders are identified by their path, renaming them would involve

renaming all of the children. That's a bit heavy, but maybe OK;

perhaps the bulk document update should be used for

pseudo-transactional coherency.

*** ownership_list

We can make some global DBs for files to allow for ad-hoc ACL structures. This one shows access for each file:

file - _id: md5 - users # NB - this must be a list here, in case - groups

This DB should be restricted from alldocs queries; you need to know the file's _id to learn about it.

*** interlace_metadata

And finally, we can make a database that indexes by md5, such that InterLace, elasticsearch, &c can run on people's files.

file - _id: md5 - duration - type: (AUDIO | VIDEO | PDF)

git clone git://