A proposal for signing documents in a secure and private way. Implemented by https://sigit.io
## Agreement
A signing round may occur for one or more documents, and involve one or more counterparties. This collection of documents, counterparties, and associated metadata constitutes a single "Agreement".
It is possible to complete an Agreement offline, or online without any external observer knowing that a counterparty was involved in an Agreement.
## Roles
When it comes to signing documents, the following roles (counterparties) are relevant:
* Creator - uploads the files, defines the remaining counterparties and signing order
* Signer - validates previous signatures and adds their own
* Viewer - has ability to view the Agreement
## Privacy
It should not be possible for observers to know the members or contents of an Agreement. This is achieved by using ephemeral keys for each counterparty, and encrypting all documents (before uploading to blossom) and metadata (before uploading to relays).
## Creation Process
The files themselves are zipped, and this `files.zip` file is then encrypted and uploaded to Blossom.
The Creator prepares an Agreement by creating and signing (but NOT publishing) a `Kind 938` event. The content field contains an object with the following information:
*`title` (string)
*`signers` (array) - list of npubs which can sign the Agreement
*`viewers` (array) - list of npubs which can view the Agreement
*`filehashes` (array) - series of objects containing the file name and file hash
*`zipUrl` (string) - the location of the encrypted zip file (blossom server)
*`markConfig` (object) - the template by which counterparties will make [Annotations](/#annotations) in any PDFs
Once the creator has signed, the `meta.json` file will contain the `createObject` (above) and a `keys` object that contains the decryption key for the zip file, NIP-44 encrypted to each counterparty.
This `meta.json` file is now sealed (using unsigned `Kind 938` to differentiate from DMs and speed up decryptions) and gift wrapped (with some PoW) per NIP-59, for each recipient, and the gift wrap is broadcast to each recipients relays.
Before signing, the client should first verify the signature from the create event, ensure the create event has a timestamp in the past, download / decrypt the `files.zip` from the `zipUrl`, and verify the hashes of each document.
A `Kind 938` event can now be signed that contains an object with the following attributes:
*`prevSig` (string) - the signature of the previous `Kind 938` event (mandatory)
*`marks` (object) - any pdf annotations, as described in the Annotations section
After signing, the `meta.json` can now be updated, eg as follows:
After each signature, this file is sealed using `Kind 938` and gift wrapped to each counterparty.
## Storing App Data
App data (list of all sigits) is stored as an encrypted file on Blossom. The file also contains a list of 'processed' `id`'s from `Kind 1059` events (to avoid having to continually decrypt when logging in, as well as enabling notifications).
A `Kind 30078` is also created, which contains a link to the blossom server, and an ephemeral key pair that can be used to sign the blossom requests. The user should be shown this `npub` so they can whitelist it on their blossom server.
NIP-78 requires a d-tag to provide some application context. To avoid revealing metadata, the d tag will be the first 32 chars of the encrypted result of the string "938" plus the users npub.
