NIP-79
======

Digital Contracts
-----------------

`draft` `optional` `author:vpirato` `collaborator:vitorpamplona` `collaborator:brandenespinoza`

### Abstract

This NIP proposes a new event type, `kind:900`, to represent digital contracts, covenants, and agreements within the Nostr protocol. These classifications are conceptual and aim to categorize the content of the contract. These can be signed, verified, and referenced by other events in the protocol.

### Motivation

As digital transactions, promises, and agreements become more prevalent, it's essential to have a standardized representation of contracts, covenants, and agreements in Nostr. This NIP aims to provide a structure and guidelines for creating, signing, and managing these within Nostr.

### Specification

1. **Types**: Following [NIP-32](32.md) for label structure:
   - **Contract**: A legally binding agreement between two or more parties.
   - **Covenant**: A written promise or restriction within a contract or agreement.
   - **Agreement**: A mutual understanding between parties regarding their relative rights and responsibilities.

2. **Format**: Following [NIP-23](23.md) (Long-form Content), the content should be in Markdown format to structure and present the content in a human-readable manner.

3. **Metadata**: Specific application metadata fields can be added to the event, such as:
   - `title`: Title of the contract, covenant, or agreement.
   - `parties`: Parties involved.
   - `signed_date`: Date it was signed.
   - `expiry_date`: Expiration date, if applicable.
   - `type`: Whether it's a Contract, Covenant, or Agreement.

4. **Timestamping with OpenTimestamps**: Following [NIP-03](03.md) (OpenTimestamps Attestations for Events), once signed, OpenTimestamps can be used to create a cryptographic proof of existence at a specific moment. This proof is stored on the Bitcoin blockchain, providing immutable evidence of the date and time of signing. For those unfamiliar with OpenTimestamps, it's a system for creating provable timestamps recorded on the Bitcoin blockchain.

5. **References and Linking**: Can reference other events in Nostr, such as annexes, terms and conditions, or any other relevant document.

6. **New `kind` Definitions**: 
   - `kind:900` for Contract Invitation
   - `kind:901` for Signature
   - `kind:902` for Signing Witness
   - `kind:903` for Contract Execution

### Contract Signing Invitation

```json
{
  "kind": 900,
  "created_at": [Creation Timestamp],
  "content": "[Content in Markdown]",
  "tags": [
    ["title", "<Contract Title>"],
    ["summary", "<Short Description>"],  // Optional: Short Description for preview
    ["valid_from", "Timestamp"], // Optional: Start date of the contract 
    ["valid_to", "Timestamp"],   // Optional: End date of the contract 
    ["L", "nostr_contracts"],
    ["l", "Contract", "nostr_contracts"], // One could use "Covenant", "Agreement", or another type according to your specifications.
    ["p", "party", "<party's 1 pubkey>"],
    ["p", "party", "<party's 2 pubkey>"],
    ["p", "party", "<party's 3 pubkey>"],
    ["expiration", "<Time stamp limit to sign>"],
  ],
  "pubkey": "[Signer's Public Key]",
  "id": "[Event ID]",
}
```

### Signature

```json
{
  "kind": 901,
  "tags": [
    [ "e", "<Contract's (kind:900) Event ID>" ]
  ],
  "pubkey": "[Party's Public Key]",
  "created_at": [Creation Timestamp],
  "content": "",
  "id": "[Event ID]",
  "ots": "<base64-encoded OTS file data>"
}
```

### Signing Witness

The role of witnesses is to provide an additional layer of verification for the contract signing process. They attest to the authenticity of the signatures involved.

```json
{
  "kind": 902,
  "tags": [
    [ "e", "<Contract's (kind:900) Event ID>" ]
    [ "on_behalf_of", "<Name/Title for the Contract>" ] // optional for Power Of Attorney
  ],
  "pubkey": "[Party's Public Key]",
  "created_at": [Creation Timestamp],
  "content": "<Name/Title for the Contract>",
  "id": "[Event ID]",
}
```

### Contract Execution

The contract execution represents the finalization and activation of the contract after all parties have signed.

```json
{
  "kind": 903,
  "created_at": [Creation Timestamp],
  "content": "<Stringified JSON of the signed kind:900>",
  "tags": [
    ["title", "<Contract Title>"],
    ["summary", "<Short Description>"], // Optional: Short Description for preview
    ["valid_from", "Timestamp"], // Optional: Start date of the contract 
    ["valid_to", "Timestamp"],   // Optional: End date of the contract 
    ["e", "<Contract's (kind:900) Event ID>" ], // Base text. 
    ["p", "party", "<party's 1 pubkey>", "Stringified JSON of the signed kind:901"],
    ["p", "party", "<party's 2 pubkey>", "Stringified JSON of the signed kind:901"],
    ["p", "party", "<party's 3 pubkey>", "Stringified JSON of the signed kind:901"],
    ["p", "witness", "<party's 4 pubkey>", "Stringified JSON of the signed kind:902"],
    ["p", "witness", "<party's 5 pubkey>", "Stringified JSON of the signed kind:902"],
    ["p", "witness", "<party's 6 pubkey>", "Stringified JSON of the signed kind:902"]
  ],
  "pubkey": "[Signer's Public Key]",
  "id": "[Event ID]",
  "ots": "<base64-encoded OTS file data>"
}
```

### Considerations

- Should be treated with a high level of security and privacy. Protect the private keys used for signing, as outlined in [NIP-24](24.md).
- Verifying the authenticity and integrity is crucial. Ensure the public key used to verify a signature genuinely belongs to the indicated signer.
- Recommended to consult with legal experts when using the Nostr protocol for these purposes.