nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-13 23:39:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity
2b3f5ba0eb
nips/94.md
Michael Hall 2b3f5ba0eb
NIP-94: Add optional 'download' flag 
In Stemstr, we have notes that present the same audio file as both a downloadable wav file and a streamable m3u8. We would like other clients to know that the wav is meant to be downloaded and the m3u8 is meant to be played inline.

The proposed change is adding a "download" flag to NIP-94 to signal this intent.
2023-07-08 12:31:17 -04:00

2.4 KiB
Raw Blame History

NIP-94

File Metadata

draft optional author:frbitten author:kieran author:lovvtide author:fiatjaf author:staab

The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by longform clients that deal with kind:30023 articles.

Event format

This NIP specifies the use of the 1063 event type, having in content a description of the file content, and a list of tags described below:

  • url the url to download the file
  • m a string indicating the data type of the file. The MIME types format must be used (https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types)
  • "aes-256-gcm" (optional) key and nonce for AES-GCM encryption with tagSize always 128bits
  • x containing the SHA-256 hexencoded string of the file.
  • size (optional) size of file in bytes
  • dim (optional) size of file in pixels in the form <width>x<height>
  • magnet (optional) URI to magnet file
  • i (optional) torrent infohash
  • blurhash(optional) the blurhash to show while the file is being loaded by the client
  • download expresses that this file is intended to be presented as a download link, rather than played inline. Client's may choose to ignore this.
{
  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>,
  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
  "created_at": <unix timestamp in seconds>,
  "kind": 1063,
  "tags": [
    ["url",<string with URI of file>],
    ["aes-256-gcm",<key>, <iv>],
    ["m", <MIME type>],
    ["x",<Hash SHA-256>],
    ["size", <size of file in bytes>],
    ["dim", <size of file in pixels>],
    ["magnet",<magnet URI> ],
    ["i",<torrent infohash>],
    ["blurhash", <value>],
    ["download", <boolean>]
  ],
  "content": <description>,
  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}

Suggested use cases

  • A relay for indexing shared files. For example, to promote torrents.
  • A pinterest-like client where people can share their portfolio and inspire others.
  • A simple way to distribute configurations and software updates.