Add nfile

[staab]

This adds a new entity that points to a static file hosted at one or more urls.

[arthurfranca]

from NIP 94

[arthurfranca]

NIP-96 has <server-url> that leads to a config file at <server-url>/.well-known/nostr/nip96.json.
The config has the <download-url> that is equal to config.download_url || config.api_url.
Then to download the file one can do <download-url>/<ox>.

So which url of these two below do you think should be inside the nfile?

1. <server-url>: useful to get other routes from the config like the upload one and to kind of advertise NIP-96 compatible servers existence. Although one could rely just on

   nips/96.md

   Line 304 in d67c4c2

   "kind": 10096,

   to discover new servers
2. <download-url>: is faster because you just need to append ox to this. downside is you can't rely on it to extract the <server-url>

For the NIP-94 ox tag I picked the <server-url> (as third tag array element) but could change it to the <download-url>. I'm unsure

[staab]

The way NIPs 94/96 are written, it's hard to point to a "host" without coupling to it. What I'm proposing is that urls are fully-resolved download urls. ox would be used to search NIP 94 events, which would in turn point to the hosting provider. However this is not currently possible because ox is not a single-letter tag — why was this not supported?

[arthurfranca]

With nip95 one would search by x hash on relays for nip94-like events.

While nip96 idea was to searchdownload from servers (not relays) by the ox hash. The hard part is to find out which servers to pick.
Maybe there isn't even a nip94 event, maybe just a nip54 url like https://first-url-from-server-A.jpg#ox=hash&ox=server-B-url&ox=server-C-url inlined in the note's .content (with just one backwards compatible fully-resolved download url).

If you already have a bunch of fully-resolved download urls there isn't much need for the ox hash.

[staab]

If you already have a bunch of fully-resolved download urls there isn't much need for the ox hash.

This would allow you to still dereference the hash and find the image if all alt urls in the nfile are dead, and the image has been replicated to another host.

I am starting to feel like nips 94/95/96 need to be combined into a single NIP that operates based on the same mental model. I feel like there are many conflicting visions here.

[staab]

An alternative approach, that actually exists in the wild: #904