= Db storage organization for CryptoPlugin = Right now I can think of only two requirements for plugin-specific information: * user <--> key associations * (detached) signature storage == Common "parasite" storage == Entries in `session_attribute` seem like a perfect match for the first requirement. I've chosen the following dedicated names for related association types: * 'sign_key' * 'crypt_key' * 'auth_key' (''future'') == Dedicated "private" storage == For storing signature data we could resort to inline signed data, but I felt that this choice would restrict possible use cases too much. So I chose detached signatures as the default. Resources stay unaltered by signing, and you will be able to sign text content as well as arbitrary binary/file data. After 3 internal iterations current db schema draft is like so: {{{ table `crypto_sign` * realm, * id, * version, * fragment, i* key_id, signature i time, * primary key i has dedicated index: }}} Discussion welcome.