NIP-54
======

Inline Resource Metadata
------------------------

`draft` `optional` `author:arthurfranca` `author:Giszmo` `author:jb55` `author:vitorpamplona`

Inline resource metadata is additional information associated with urls in notes that clients can optionally use to enhance resource loading.

It uses [URI Fragment](https://en.wikipedia.org/wiki/URI_fragment) that agents (such as web browsers) never send to the server. Because of this, the url is fetched **without** the fragment parameters, unlike using query parameters.

The URI fragment follows [media fragments structure](https://www.w3.org/TR/media-frags/#general-structure). For example, one could use `t=number_of_seconds` to start playing a video at the specified position along with an extra [percent-encoded](https://www.ietf.org/rfc/rfc3986.txt) name-value pair separated by `&` char like `https://xyz.com/a-video.mp4#t=24&a%20name=a%20value`. **Notice the usage of `#` instead of `?`.**

The metadata can be appended to any url, like this [NIP-21](21.md) one: `nostr:nevent1qq...pm#a-metadata-name=a-metadata-value`.

One may also add `url` tags to events to aid in loading resource placeholders on clients that postpone or don't do event `.content` parsing.

## NIP-94 File Fragments

Besides available w3c and proprietary URI fragment usage, nostr uses existing [NIP-94](94.md) tags as file fragment name-value pairs. NIP-94 event `.content` is equivalent to `alt` fragment field. For example, one could join the following strings to form an image url with inline metadata:

- `https://nostr.build/i/863321bb1ae68830ebcf9a343ca0a5e0ce2323d0a55b7fbe86f7a886cf61db8d.jpg`
- `#`
- `m=image%2Fjpeg`
- `&`
- `dim=3024x4032`
- `&`
- `alt=A%20scenic%20photo%20overlooking%20the%20coast%20of%20Costa%20Rica`
- `&`
- `blurhash=eVF%24%5EOI%3A%24%7BM%7Bo%23*0-nNFxakD-%3FxVM%7DWEWB%25iNKxvR-oetmo%23R-aen%24`

Multiple array values use repeated names and are positioned in the same order of ocurrence in the tag array. For instance, `["aes-256-gcm", 'i-am-a-key', 'i-am-an-iv']` becomes `aes-256-gcm=i-am-a-key&aes-256-gcm=i-am-an-iv`.

### Event Example:

```js
{
  "kind": 1,
  "content": "What a great place! https://xyz.com/example.jpg#m=image%2Fjpeg&dim=3024x4032&alt=A%20scenic%20photo%20overlooking%20the%20coast%20of%20Costa%20Rica&blurhash=eVF%24%5EOI%3A%24%7BM%7Bo%23*0-nNFxakD-%3FxVM%7DWEWB%25iNKxvR-oetmo%23R-aen%24`",
  // ... other event fields
}
```

## Tag Usage

Some event kinds may have been designed with urls inside tags instead of in `.content`. For these cases, use `url` tags (or `r` tags if it needs to be indexed by relays – in this case, metadata fragment keys and query parameter keys SHOULD be arranged in ascending order).

### Tag Examples:

A kind 30023 event JSON file (with `nostr/30023` MIME type):
`["url", "https://xyz.com/example.json#m=nostr%2F30023"]`

A PDF file without extension with added MIME type information:
`["r", "https://xyz.com/article02#m=application%2Fpdf"]`

## Recommended client behavior

When uploading images during a new post, clients can collect metadata
after the image is uploaded and then include the url with inline metadata in the post.

When pasting urls during post composition, the client could download the image
and add some metadata before the post is sent.

Clients can use `alt` value to add accessible text for people who prefer not to
load images, visibility-impaired users, or text clients.