Nostr distributed product information

[Happyzippy]

I am pondering about the creation of a distributed product data database, and an eventual implementation on Nostr.

Key features for using nostr

• Suppliers could publish and distribute product information without necessarily going through a central authority, while still ensuring there is a common space where everybody can access information
• Identities of data publishers are known and verifiable
• Everybody can subscribe to specific interesting products / categories

I see the following previous work:

• Supply Chain EPCIS NIP-128 & NIP-420 #375; A somewhat similar usecase, the status is unknown to me
• nip99 e-commerce use case extension #1784; @GammaMarkets; Classified listings would be very close in concept, with a difference that the author is not necessarily the seller. kind:30402 could link to external product information, by adding GTIN identifiers as customary on amazon / ebay, etc.
• NIP-73 - External Content IDs #1185, NIP-73 specifies some extra external identifiers, but not gtin (which contains EAN/UPC barcodes)

Given that i am new to Nostr / NIPs development, I have started to create some draft updates, for either a new NIP, or an extension of the existing NIP-99 given the close link in substance.

DRAFT NIP / extension to NIP-99

Product Information

This NIP defines a standardized way to share product information on the Nostr network, with the intention of enabling the creation of a distributed product database for e.g. product descriptions, nutritional data, and supply chain information.
This could enable use cases such as price comparison, and consumer review sharing, supply chain analytics etc.

Specification

Event Kind

This NIP defines the use of event kind 30401 for product information events.
adjacent to NIP-99 classified listings

Event Format

Product information events contain structured data about commercial products, split by a type tag (content schema) to allow for future extension without polluting Nostr kinds (alternatively, it could make sense to have description as one kind, and extra info as another (which would also split json and markdown content)

Current types are:

• Product description ["type", "description"]
• Nutritional information ["type", "nutrition"]
• Supply Chain Information ["type", "supply-chain"]

Event types must all contain the tags:

• ["type", "<string>"], to signal the event kind of other tags / content to expect.
• ["i", "<external-identity>"] One or more external identities (NIP-73), used to link the information to real world products. NIP-73 must be amended to include "gtin:xxx" as GTIN identifiers
• ["l", "<language>", "ISO-639-1"] Language, to specify what language the information is in.

Optionally:
Events can have

• link (a)
• image (image)
• tags (t)
• labels (l)

Product Description (type: description)

Basic product information including name, description, brand...

Example:

{
  "kind": 30401,
  "tags": [
    ["type", "description"],
    ["i", "<product-code>"],
    ["l", "<language-code>", "ISO-639-1"],
    ["title", "<product-name>"],
    ["location", "<location>"], // Sales location, (could be more than one)
    ["brand", "<product-brand>"], // Optional brand name
    ["summary", "<short summary>"], // Optional summary
    ["quantity", "<product-quantity>"], // Optional quantity, eg 100g
    ["t", "<product-category>"], // Optional product categories
    // ... additional tags
  ],
  "content": "<product-details>", // Markdown description
  // ... other required fields
}

Nutritional Information (type: nutrition)

Detailed nutritional data, ingredients, and allergen information.

Content: JSON object with nutritional data

Example:

{
  "kind": 30401,
  "tags": [
    ["type", "nutrition"],
    ["i", "<product-code>"], // One or more product codes (often gtin:xxx)
    ["l", "<language-code>", "ISO-639-1"],
    // ... additional tags
  ],
  "content": "<JSON: nutritional info>",
  // ... other required fields
}

Supply Chain Information (type: supply-chain)

Information about product origin, manufacturing, and supply chain transparency.

Content: JSON object with supply chain data

Example:

{
  "kind": 30401,
  "tags": [
    ["type", "supply-chain"],
    ["i", "<product-code>"], // One or more product codes (often gtin:xxx)
    ["l", "<language-code>", "ISO-639-1"],
    // ... additional tags
  ],
  "content": "<JSON: supply chain info>",
  // ... other required fields
}

Implementation Notes

• Clients/relays can aggregate information from multiple sources for the same product, for updating faulty entries, ignore spam
• External identities are used to group information about the same products
• ean-search contains 950 million items. Is specific relays needed to scale? (according to nostr.band 600 million notes have been published so far).

TODOs

• Product variations (groups of products) are not supported
• Specification of type content schemas

Considerations

• Product information could be verified / updated by authoritative sources (owners of the GTIN numbers)
• Users should be cautious of potentially misleading or fraudulent product information
• Clients may implement reputation systems for product information contributors
• How are events best sorted / prioritized to collaboratively get the most correct product data

[Happyzippy]

Extra information (Nutrition, packaging, supply chain, ...) Could be inserted as a kind: 1985 Label if nostr-nips.com/nip-32 was ammended to allow external references tags i

[Happyzippy]

Closed by mistake :/