Nostr Web Client

Here are my comments on nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s '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', 'descriptor', 'size','blurhash', ..]

['imeta', 'url2', 'hash', 'descriptor', 'size','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 (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.

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 2y ago

TLDR

cloud fodder 2y ago

🤔 as a relay operator, I'll be 👀 #teamstrfry

xuerong 2y ago

# 真的非常棒

Blake 2y ago

I think we’re talking about two distinct use cases here. Hence the contention.

1. Better media handling for kind 1 events.

2. Generic hash addressable file mapping events

It would be ideal if we can somehow share much of the implementation, and at least overlap in language.

For #1, querying for a second event when a single image is the most popular with a blur-hash for nicer UX is a 90% use case. Querying for a kind 1 event, and then parsing and then querying for a kind 1063, and then either http/torrent fetch isn’t likely to perform well for clients with timeline views rendering.

Not all Nostr referenced files need

a kind 1 event pair/parent.

There is the option for relays to optionally embed related/child events, say in a new parent event key, like related_events: [] or similar. I suspect we need something like this anyway. Similar to how the first event a relay sends for that pubkey could embed the profile/meta event - as it’s always desirable (ignoring dupe response data across relay connections).

For #2, it’s building a file system like mapping inode that can be used for all file types and different hosting/access approaches. It’s more usable by all event kinds in future.

I think we will likely end up with two separate approaches. If a kind 1 wants greater redundancy or media access methods, it should likely then default to the kind 1063 approach - basically advanced mode. Else, it can use simple mode.

However, it’s also worth research other exisiting projects and approaches more.. as we may not the approach angle correct.