Vitor Pamplona on Nostr: Here are my comments on jb55 's NIP-94 alternative Intro: The proposal adds the ...
Here are my comments on jb55 (npub1xts…kk5s) 's NIP-94 alternative
Intro: The proposal adds the existing NIP-94 tags (Will calls them image metadata) into Kind 1 event tags directly.
You can see an example here: https://www.nostr.guru/e/f89181db5a8ca1b469a9bce65f72e5640afb598e194fb9320e70edc634ea3a96
This means:
1. If we do only 1 tag per url for all metadata attributes, we might be tied to only 3 attributes per image or some relays will crash: Some relays use a regular relational model for tags with limited columns in their tables. We can't just add as many tag attributes as we want per url. And 3 is deffinatelly not enough if we want to provide good metadata (hash, accessibility descriptor, blurhash, size, decryption info, etc)
['imeta', 'url1', 'hash<hash>', 'descriptor<descriptor>', 'size<size>','blurhash<blurhash>', ..]
['imeta', 'url2', 'hash<hash>', 'descriptor<descriptor>', 'size<size>','blurhash<blurhash>', ..]
2. If we do n tags, 1 for each attribute, we can have as many attributes we want, but it duplicates the url string in each attribute to allow the client to reassemble the group of attributes to the same url.
Like this:
['r', 'url1', 'hash', '...']
['r', 'url1', 'descriptor', '...']
['r', 'url2', 'hash', '...']
['r', 'url2', 'descriptor', '...']
3. On NIP-94 the event and it's metadata are created only once and reused in all kind 1 messages that use that Event ID. In Will's proposal, every kind 1 that includes the same URL must duplicate all the metadata related to that URL. This means significantly more data storage needs for relays and more data plan use for folks that are receiving the same url in many posts.
4. The proposal uses an encoding scheme for tags that we have not seen in Nostr yet. Essentially instead of having the content directly, every tag attribute will be <label+content> (see example 1). So, clients now must parse these tags differently than everything else. And in order to parse them, they must know the prefix of every option available.
Summary:
I don't this is a good idea:
1. It requires significantly more data. No matter which option we choose, there will be duplicated metadata everywhere.
2. It requires a new custom encoding inside tags that we need to get a good review on.
3. There is not enough space to add the minimum tags Amethyst already works with in every image.
4. It duplicates the specification of the metadata (field names, possible values, semantic meanings, etc) from NIP-94. We don't need two ways of doing the same thing.
5. It's also not a NIP yet.
Intro: The proposal adds the existing NIP-94 tags (Will calls them image metadata) into Kind 1 event tags directly.
You can see an example here: https://www.nostr.guru/e/f89181db5a8ca1b469a9bce65f72e5640afb598e194fb9320e70edc634ea3a96
This means:
1. If we do only 1 tag per url for all metadata attributes, we might be tied to only 3 attributes per image or some relays will crash: Some relays use a regular relational model for tags with limited columns in their tables. We can't just add as many tag attributes as we want per url. And 3 is deffinatelly not enough if we want to provide good metadata (hash, accessibility descriptor, blurhash, size, decryption info, etc)
['imeta', 'url1', 'hash<hash>', 'descriptor<descriptor>', 'size<size>','blurhash<blurhash>', ..]
['imeta', 'url2', 'hash<hash>', 'descriptor<descriptor>', 'size<size>','blurhash<blurhash>', ..]
2. If we do n tags, 1 for each attribute, we can have as many attributes we want, but it duplicates the url string in each attribute to allow the client to reassemble the group of attributes to the same url.
Like this:
['r', 'url1', 'hash', '...']
['r', 'url1', 'descriptor', '...']
['r', 'url2', 'hash', '...']
['r', 'url2', 'descriptor', '...']
3. On NIP-94 the event and it's metadata are created only once and reused in all kind 1 messages that use that Event ID. In Will's proposal, every kind 1 that includes the same URL must duplicate all the metadata related to that URL. This means significantly more data storage needs for relays and more data plan use for folks that are receiving the same url in many posts.
4. The proposal uses an encoding scheme for tags that we have not seen in Nostr yet. Essentially instead of having the content directly, every tag attribute will be <label+content> (see example 1). So, clients now must parse these tags differently than everything else. And in order to parse them, they must know the prefix of every option available.
Summary:
I don't this is a good idea:
1. It requires significantly more data. No matter which option we choose, there will be duplicated metadata everywhere.
2. It requires a new custom encoding inside tags that we need to get a good review on.
3. There is not enough space to add the minimum tags Amethyst already works with in every image.
4. It duplicates the specification of the metadata (field names, possible values, semantic meanings, etc) from NIP-94. We don't need two ways of doing the same thing.
5. It's also not a NIP yet.