NIP-88: First draft about products classification

88.md

@@ -0,0 +1,91 @@
+NIP-88
+======
+
+Products classification
+--------------------------
+
+`draft` `optional`
+
+This NIP defines the use of some tags in metadata (kind:0) events to offer the possibility to have profile for products. Products have their own key-pair and the private key is typically controlled by the manufacturer.
+
+## Use cases
+
+There are several uses case for product events:
+
+- Manufacturers would own the identity of their products, for free, without be locked in the proprietary GTIN (UPC/EAN/JAN/ISBN/etc) market;
+
+- It would be possible for buyers follow products they own and be alerted about production problems, updates, news and suggestions;
+
+- Nostr e-commerce/reviews apps would have a better integration for products, with a news live feed from the manufacturers;
+
+- Manufacturers could offer specialized customer support via DM using the product profile;
+
+- Manufacturers could promote resellers, and possibily onboard them on Nostr;
+
+- Manufacturers or sellers could cryptographically certify the purchase of a product to issue a warranty;
+
+Identity attestation is easy: the public key is stamped as qrcode on the product or its packaging.
+
+### Metadata tags
+
+If a metadata event wants to refers to a product it MUST self-reports with the following NIP-32 labeling:
+
+```json
+{
+  "tags": [
+    ["L", "#t"],
+    ["l", "products", "#t"],
+  ],
+}
+```
+
+The event SHOULD include a `p` tag that refers to the product manufacturer, having the 4th position marked as `manufacturer`
+
+```json
+{
+  "tags": [
+    ["p", "<id>", "<relay>", "<producer-name>", "manufacturer"],
+  ],
+}
+```
+
+The event SHOULD include one or more `p` tag that refer to the resellers, having the 4th position marked as `reseller`:
+
+```json
+{
+  "tags": [
+    ["p", "<id>", "<relay>", "<reseller-name>", "reseller"],
+    ["p", "<id>", "<relay>", "<reseller-name>", "reseller"],
+  ],
+}
+```
+If the producer is also a (or the only) reseller, it can be used duplicated with both markers.
+
+If the product has a GTIN (EAN/UPC/JAN/ISBN/etc) code the event SHOULD refers to it using the NIP-32 labeling with [ISO/IEC-6523](https://en.wikipedia.org/wiki/ISO/IEC_6523) namespace:
+
+```json
+{
+  "tags": [
+    ["L", "ISO/IEC-6523"],
+    ["l", "<code>", "ISO/IEC-6523"]
+  ],
+}
+```
+
+### Metadata content
+
+The content is set to a stringified JSON object that support the following fields:
+
+| Kind         | Type           | Description
+| ---          | ---            | -----------------------------------------------------
+| `name`       | `<string>`     | The name of the the product, including the brand
+| `about`      | `<string>`     | A description of the product
+| `picture`    | `<url>`        | Main image of the product
+| `gallery`    | `<url,url,...>`| List of urls for a product gallery
+| `website`    | `<url>`        | An url pointing to the product web page
+| `started_at` | `<YYYY-MM-DD>` | The date when the production started
+| `ended_at`   | `<YYYY-MM-DD>` | The date when the production ended
+
+### Sharable nproduct entity
+
+This NIP also define a new `nproduct` bech32 shareable identifiers analogue to _nprofile_. The `nproduct` can be shared as qrcode and added to the products or their packaging, attesting the identity, and it is useful to distinguish a product without fetching the metadata event. However, products are backward compatible to the _nprofile_, as is the whole profile.