From 03ee3a33343bd109623c564c8c67870a3864a332 Mon Sep 17 00:00:00 2001
From: Sergio Ovalle <sergio@lynx.com.gt>
Date: Wed, 30 Aug 2023 12:14:53 -0600
Subject: [PATCH] Add NIP-79: Digital Contracts, Covenants, and Agreements

Introduces a new proposal (NIP-79) to standardize the representation of digital contracts, covenants, and agreements within the Nostr protocol. This NIP provides guidelines for creating, signing, and managing these entities, enhancing the protocol's capabilities for secure digital transactions.
---
 79.md | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)
 create mode 100644 79.md

diff --git a/79.md b/79.md
new file mode 100644
index 0000000..97a0ca1
--- /dev/null
+++ b/79.md
@@ -0,0 +1,133 @@
+NIP-79
+======
+
+Digital Contracts
+-----------------
+
+`draft` `optional` `author:vpirato` `author:vitorpamplona`
+
+### 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**:
+   - **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 (Long-form Content), the content should be in Markdown format to structure and present the content in a human-readable manner.
+
+3. **Metadata**: Using NIP-78 (Application-specific data), 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 (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 
+    ["type", "Contract"],
+    ["party_pubkey", "<party's 1 pubkey>"],
+    ["party_pubkey", "<party's 2 pubkey>"],
+    ["party_pubkey", "<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>" ],
+    [ "e", "<Signature (kind:901) Event ID>" ]
+  ],
+  "pubkey": "[Party's Public Key]",
+  "created_at": [Creation Timestamp],
+  "content": "",
+  "id": "[Event ID]",
+  "ots": "<base64-encoded OTS file data>"
+}
+```
+
+### 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. 
+    ["party_pubkey", "<party's 1 pubkey>", "Stringified JSON of the signed kind:901"],
+    ["party_pubkey", "<party's 2 pubkey>", "Stringified JSON of the signed kind:901"],
+    ["party_pubkey", "<party's 3 pubkey>", "Stringified JSON of the signed kind:901"],
+    ["witness_pubkey", "<party's 4 pubkey>", "Stringified JSON of the signed kind:902"],
+    ["witness_pubkey", "<party's 5 pubkey>", "Stringified JSON of the signed kind:902"],
+    ["witness_pubkey", "<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.
+- 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.