There are two use-cases on gpg and opmsg that can be greatly facilitated by having our own crypto-wrapper:
when writing gpg emails to recipients whose email is not contained in the gpg id, manual selection of the right gpg key is cumbersome
when importing opmsg keys, persona linking may be done using a default id to start (and can be changed manually) or could be randomised creating a disposable new key
the first point can be solved having a very simple config file that matches keyid and email on two columns, then wrap the encrypt phase of gpg when looking for keys with our own crypto-wrapper
the second can be solved wrapping the import and encrypt phases in opmux with something that will setup the default persona on import but also allow mapping of personas from a config file (perhaps the same file for gpg) and have also an option to generate disposable random keys for some recipients
There are two use-cases on gpg and opmsg that can be greatly facilitated by having our own crypto-wrapper:
the first point can be solved having a very simple config file that matches keyid and email on two columns, then wrap the encrypt phase of gpg when looking for keys with our own crypto-wrapper
the second can be solved wrapping the import and encrypt phases in opmux with something that will setup the default persona on import but also allow mapping of personas from a config file (perhaps the same file for gpg) and have also an option to generate disposable random keys for some recipients
About persona-linking: https://github.com/stealth/opmsg#persona-linking