updates to NIP-70

70.md

@@ -32,10 +32,18 @@ The treasurers wish to improve and streamline the process using Nostr and user-f
 This feature set could replace common legal document approval/signature applications such as DocuSign or Adobe Sign. Instead of a PSBT, the content could be markdown, plain text, or content such as [OpenLaw](https://docs.openlaw.io/) markup, the [Accord project](https://accordproject.org/projects/cicero/), or other types of [Ricardian contracts](https://iang.org/papers/ricardian_contract.html).
 
 ## Notes & RFC
+#### Privacy
 - The content may or may not be encrypted. Some public DAO treasuries may desire open approvals, although most will likely be encrypted.
 - It will likely be common for this feature to be used on private or permissioned relays.
+
+### Tagging Prospective Approvers
 - The `p` tag is for tagging a specific account, presuming requesting approval from that user. If it is common for non-approval pubkeys to also be tagged, then a new `tag` type spec for `requested_signer` should be added. (TBD)
+
+### Bitcoin PSBT and Payload Decoding
 - Bitcoin signature request URIs have been proposed over the years but it is unclear how many wallets support them. The content in a `10010` event may contain a URI encoded PSBT or a non-URI encoded PSBT.
+- Some legal agreement specifications provide templated or `handlebars`-style hydration. In these cases, an event may reference an commonly adopted template (via URL, namespace, or hash) and provide the data in the Event tags (e.g. NDA template with a name and expiration date as data fields). 
+
+### Fields Specifications
 - Kind `10010` MUST have a tag where the first array element is `to_sign`. If that does not parse, the `content` is assumed to be the payload to sign.
 - Kind `10011` MUST have a tag where the first array element is `signature`. If that does not parse, the `content` is assumed to be the signature.