🤔 How interesting! What if we used this Vitor's proposal as a DAO manager, where the account could act as a bot and facilitate Monero voting transactions? It could be an exciting combination! 👥💼

I'm millionaire

Done in the last commit

Same here but since I have Kindle I love books again

https://apklord.com/en/zlib-apk

Zlib app

This could work?

```json

{

"kind": 900,

"created_at": "[Creation Timestamp]",

"content": "[Content in Markdown]",

"tags": [

["title", ""],

["summary", ""], // 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", ""],

["p", "party", ""],

["p", "party", ""],

["expiration", ""],

["jurisdiction", {

"country": "USA",

"state": "California",

"city": "San Francisco",

"court": "Superior Court of California"

}]

],

"pubkey": "[Signer's Public Key]",

"id": "[Event ID]",

}

```

Talking with a friend of mine (lawyer) about nip79 he pointed this

"Clearly establish in the contract terms which jurisdiction will be applicable in case of disputes. This reduces ambiguity and provides certainty to all parties involved"

### Non-Technical Explanation of NIP-79

NIP-79 is a proposal that seeks to introduce a standardized way of handling digital contracts, covenants, and agreements within the Nostr protocol. In simple terms, this protocol acts as a digital platform that allows parties involved in a contract to interact in a more secure and verifiable manner. Here is a detailed explanation of each section:

1. Types of Documents:

- 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: The documents will be in Markdown format, allowing for structured and human-readable presentation.

3. Metadata: Specific metadata fields can be added to the event, such as the title of the contract, the parties involved, the signing date, the expiration date, etc.

4. Timestamping with OpenTimestamps: Once signed, OpenTimestamps can be used to create a cryptographic proof of the contract's existence at a specific moment, stored on the Bitcoin blockchain.

5. References and Linking: Documents can reference other events in Nostr, such as annexes, terms and conditions, or other relevant documents.

6. New 'kind' Definitions: New definitions are introduced to categorize different stages and elements of the contractual process.

### Usage Example:

Imagine that two companies, Company A and Company B, decide to enter into a collaboration contract. Here is how they might use this protocol:

1. Contract Creation: Company A creates a draft of the contract on the platform, detailing the terms and conditions of their collaboration with Company B.

2. Review and Signature: Company B reviews the contract, and once they are satisfied with the terms, both parties digitally sign the contract on the platform.

3. Signature Witnesses: Witnesses can be designated to verify the authenticity of the signatures involved, adding an additional layer of verification to the signing process.

4. Contract Execution: Once all parties have signed, the contract is officially activated on the platform, marking the beginning of the collaboration.

5. Verification and Security: At any time, the parties can verify the authenticity and integrity of the contract on the platform, ensuring that the agreed terms remain intact and secure.

This protocol, therefore, facilitates a more secure, transparent, and efficient contractual process, which could be of great value in the legal world.

CC nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk

Or math but in language

I love this language is like coding

Not NIP-03

https://github.com/xemuj/nips/blob/DigitalContracts/79.md

Please check the last version

I want my ⚡⚡⚡⚡

nostr:nevent1qqsvzxn8x75qyzsqz6mmjykh2qvpz45xxfd8ahldzdz6th8p2ud090cpz9mhxue69uhkummnw3ezuamfdejj7q3qutx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4sxpqqqqqqzmhrnku

Thank you for the coverage nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk

https://habla.news/nostreport/Nostr-Tech-Weekly-2023-09-03

New discussion about secret voting

https://github.com/nostr-protocol/nips/discussions/758

CC nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s tell me if this makes sense

Interesting! What do you think about this label structure?

```

["L", "tipopakto"]

["l", "Contract", "tipopakto"]

["l", "Agreement", "tipopakto"]

["l", "Covenant", "tipopakto"]

```

I've chosen to use "tipopakto" as a namespace, which translates from Esperanto to "type of pact." I find using Esperanto for primary namespaces to be more neutral, given its universal and non-nationalistic nature.

Mom, look, I'm in the news! 😎📰🗞️

nostr:nevent1qqsdxmmfrcw5yey3pd94wpprlgha8pfgh47zd02f9fakpg32yzj668cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpwm082d9x3v33fs499ykp5tr7km9jmzc0rcj9405a07qv5q4vgsspsgqqqqqqsc4maqa

Regarding the rationale behind specifying the types of contracts upfront:

Standardization: By defining types, you create a standardized way to categorize and interpret contracts within the Nostr protocol. This can make it easier for applications built on top of Nostr to understand and process different contract types.

Clarity: Specifying types can provide clarity to the parties involved. Knowing whether an agreement is a legally binding "Contract" versus a less formal "Agreement" or a specific "Covenant" can set clear expectations for all parties.

Filtering & Searching: If there are many contracts within the Nostr network, having predefined types can make filtering and searching more efficient. Users or applications can quickly find all "Covenants" or all "Agreements" without having to parse the content of every contract.

Extensibility: While the initial types are predefined, the system can be designed to be extensible, allowing for the addition of new types in the future as the needs of the community evolve.

However, there are also arguments against specifying types upfront:

Flexibility: Restricting to predefined types might limit the flexibility of the system. Some contracts might not fit neatly into one of the predefined categories.

Overhead: Introducing types adds an additional layer of complexity to the system. Every contract will need to be categorized, and disputes might arise over which category is appropriate.

Evolution: As the protocol and its use cases evolve, the initially defined types might become obsolete or insufficient, requiring updates or revisions to the NIP.

In the end, the decision to specify contract types upfront depends on the goals of the Nostr protocol and the needs of its user community. If the aim is to keep things simple and flexible, it might be better to avoid predefined types. If the goal is to provide structure and standardization, then defining types can be beneficial.

No, is an array of parties the witnesses are optionals