NIP-94は、共有ファイルを整理し分類するためのfile metadata event（kind 1063）を定義します。これによりrelayはcontentを効果的にfilterし、整理できます。

仕組み

NIP-94は、ファイル向けの独立したmetadata eventとしてkind 1063を使います。eventのcontentには人間向け説明が入り、tagにはdownload URL、MIME type、hash、dimensions、preview hintのようなmachine-readable fieldが入ります。

この分離が重要なのは、metadata eventが、そのファイルへリンクするnoteとは独立にindex、filter、再利用できるからです。clientはkind 1063イベントをassetの正規記述として扱え、自由文の投稿本文からmetadataをこじ開ける必要がありません。

必須タグと任意タグ

Core tags:

  • url - ファイルのdownload link
  • m - MIME type（小文字形式が必須）
  • x - ファイルのSHA-256 hash

Optional tags:

  • ox - server変換前の元ファイルのSHA-256 hash
  • size - バイト単位のファイルサイズ
  • dim - 画像や動画のdimensions（width x height）
  • magnet - torrent配布向けMagnet URI
  • i - torrent infohash
  • blurhash - preview用placeholder image
  • thumb - thumbnail URL
  • image - preview image URL
  • summary - テキスト抜粋
  • alt - accessibility description
  • fallback - 代替download source
  • service - NIP-96のようなstorage protocolまたはservice type

oxとxタグは見落とされやすいものの、実際には有用です。oxは元のアップロードファイルを識別し、xはserverが実際に配信する変換後バージョンを識別できます。media hostがuploadを圧縮またはresizeしても、clientは変換後blobを元ファイルと同一だと偽らずに、元ファイルidentityを保持できます。

いつ使うべきか

NIP-94は、social clientやlongform clientよりも、file-sharing application向けに設計されています。想定される用途には次があります。

  • Torrent indexing relay
  • Portfolio-sharing platform（Pinterestに近い）
  • ソフトウェア設定や更新の配布
  • Media libraryやarchive

ファイルmetadataが、別イベント内のURLを飾るだけでよいなら、NIP-92: Media Attachmentsのほうが軽量です。ファイル自体をfirst-class objectとしてquery可能にしたいなら、NIP-94のほうが適しています。

相互運用メモ

NIP-94はstorage backendをまたいで機能します。ファイルはNIP-96: HTTP File Storage、Blossom、そのほかのservice経由でuploadされた後でも、同じkind 1063 event shapeで記述できます。だからこそ、このmetadata formatは1つのupload protocolを超えて生き残ります。

Primary sources:

Mentioned in:

See also: