NIP-88: First draft about products classification

[dtonon]

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.

[fernandolguevara]

keep brand value on a different field

[dtonon]

I was thinking about it, I opted for this solution for backward compatibility with standard profiles

[staab]

Why overload kind 0 instead of creating a new kind? It seems very weird to give a product an identity.

[dtonon]

@staab

Why overload kind 0 instead of creating a new kind? It seems very weird to give a product an identity.

If using a different kind was the first point I thought of of course, I preferred to start with kind:0 for backward compatibility, if profiles exist as bots, projects or companies, I don't see why they couldn't exist as products, and could be nice to have "talking" products that work smoothly in plain NIP-01 clients. It could be useful for marketing activities, too.
Of course it has to be checked if it is sustainable, if not we can always use a new kind, and so rethink (empty) the content section.

Do you foresee any special problems?

[staab]

It's an interesting idea, I considered a similar one when I originally started working on groups. A group as an "agent" seemed kind of neat, because any group member could basically post on behalf of the group. That didn't work out for other reasons, but I think the basic litmus test here is: would it make sense to visit the pubkey's profile page on a normal social client? Bots, projects, companies, yes, groups maybe, but products? I suppose anything is possible, but it seems to me that it would be hard to make it intelligible, at least under the assumptions people bring to "social media" (which may or may not hold up long term on nostr). The flipside of the same issue is that the more a kind is semantically overloaded, the less it means. If kind 0 can mean "product", people will start to code product-specific support into their clients, which increases the barrier to entry to making a client that supports kind 0.

So really, I don't know, but I'm against it. I don't see any problem with making products a separate kind, and creating each one with a separate key + regular profile if that's really what the implementer wants to do.

Another question I have is why this couldn't just be added to NIP 99?

[dtonon]

If kind 0 can mean "product", people will start to code product-specific support into their clients, which increases the barrier to entry to making a client that supports kind 0.

The product structure is optional and backward compatible, so basic clients will just see the product as a standard profile, and they are not obliged to support NIP-88 in any way to adhere to kind:0. Or am I missing something?
But I understand that adding stuff to the kind:0, even if via an optional NIP, could be confusing.
I just like the simplicity to have products profiles that can create their own feeds, be mentioned, etc without touching too much the protocol.
Pros and cons, I will think about it.

Another question I have is why this couldn't just be added to NIP 99?

Because this NIP is not about selling a product, but giving it a digital identity.
NIP-99 and NIP-15 can link to a NIP-88 product when necessary.

[staab]

I just like the simplicity to have products profiles that can create their own feeds, be mentioned, etc without touching too much the protocol.

I think this can all be accomplished with a tags. The benefit of that is that clients can know whether or not they support the thing they're trying to render, which isn't true of bare pubkeys.

[arthurfranca]

Great to have an alternative global product id considering GTINs need permission/payment to be created and maintained.

But the more products a manufacturer have, higher the chance of leaking a product privkey leading to defaced product profiles.

Maybe it is better to go the Brand + MPN route, cause its easier to keep just the brand privkey safe.

A brand could list each product with many events like the one below:

{
  kinds: 30088,
  pubkey: "<current_brand_pubkey>",
  tags: [
   // This never changes for old products, even if brand privkey is lost or leaked.
   // New products though would use the current brand pubkey prefix
    ["d", "<brand_pubkey>:<mpn>"],
    // some standardized product tags, e.g.: an indexable category tag would be useful
  ],
  // other fields
}

The brand kind0 could have previous leaked or lost pubkeys in an indexable tag (p?). This may be useful for regular profiles too.

[alltheseas]

I love the real world problem/use case thinking @dtonon.

Left-curve product question from me: why do we need a NIP for products? Why not just

1. create a new keypair for each product, and
2. associate above product keypair as a child key under a parent company key (I think there was a delegation NIP - not sure the state of it)

You can add the ISBN/UPC/similar in one of the profile fields, similar to how the nostr or LN address is added.

[dtonon]

@arthurfranca your one is a interesting alternative, I also thought a similar more structured scenario. But adding a generic custom MPN make the product code less standardized, I would avoid that. And we lose the possibility that the product entity can sign. When we find a good way to rotate keys, a product can be also transferred to a new manufacturer while maintaining cryptographic proof.
Managing multiple keys is more complex of course, but we can use something like an xpub scheme to solve this issue; for large catalogs a product management software will be necessary, of course.

The brand kind0 could have previous leaked or lost pubkeys in an indexable tag (p?). This may be useful for regular profiles too.

What do you mean?

[dtonon]

@alltheseas

associate above product keypair as a child key under a parent company key (I think there was a delegation NIP - not sure the state of it)

Delegation (NIP-26) is dead. And it is not strictly needed, if the manufacturer control the keys can simply add itself to the product event and thus attest to the ownership.

You can add the ISBN/UPC/similar in one of the profile fields, similar to how the nostr or LN address is added.

This way you cannot search them via a relay query, and this is critical from a GTIN to NPRODUCT migration perspective.
I use this approach for the basic data just to keep the kind:0 compatibility.

[arthurfranca]

• The brand kind0 could have previous leaked or lost pubkeys in an indexable tag (p?). This may be useful for regular profiles too.

What do you mean?

In a scenario of leaked/lost brand privkey, it was just an idea to enable a client to check (by filtering kind:0s by specific p tag) if some brand's new pubkey is claiming to be the current one to replace a previous brand pubkey. The previous (leaked or lost privkey) pubkey(s) would be the p tag(s).

Of course for clients to trust that info, there would need to have other hints like if reputable merchants are reselling/had sold items that are linked to both the new and old pubkeys somehow.

[gzuuus]

It is a very interesting idea, but I can see some potential problems. For example, the loss, compromise or leakage of product keys, and the fact that a manufacturer with a large catalogue would have to keep all the private keys of its products, which can be difficult to manage. I think that to improve this, we could do something like BIP-85, so that a manufacturer can control its entire catalogue (or part of it) with just one key. Also, to make this as robust as possible, we need a standard way of rotating the keys.
Another thing that comes to mind is that currently with nip15 we have coordinates, expressed as naddrs, for the products that could serve as a barcode or product identity, but with the current implementation we would not have the role of 'manufacturer'.