Skip to content

Note

このドキュメントは2026-02-27 02:22PLaMo Translation Modelを使用して自動翻訳されました。

Warning

このドキュメントは原文と大きく乖離しているか、内容が原文から欠落している可能性があるため、原文を読むことを推奨します。

FEP-1311: メディア添付ファイル

画像のプロパティ指定

メディア添付物を作成する際には、mediaTypedigestMultibase、およびsizeの値を含めることが推奨されます。メディア添付物を受信する側では、digestMultibaseに基づいてダウンロードした添付物の整合性を確認する必要があります。また、sizemediaTypeを基に、最適な方法で添付物を処理することを決定してください。

sizemediaTypeは、複数バージョンのメディア添付物を提供する場合に特に重要になります。例えば、あるフィードではデフォルトで低画質版のみを表示し、必要に応じて高画質版を選択できるようにするといった使い方が考えられます。

ファイルプロパティの不足点:アクセス制御

現在の仕様では、ファイルプロパティに_アクセス制御情報_が欠けています。これについては、後述する「認証と認可」セクションを参照してください。

画像固有のプロパティ

これまで説明してきた文書のプロパティのうち、widthheightについては未解説です。これらのプロパティは画像および動画にのみ適用され、音声には該当しません。同様に、音声や動画には「duration」(再生時間)というプロパティがありますが、画像は持ちません。また、Mastodonでは以下追加のプロパティが導入されています:

  • focalPoint
  • blurHash このうち、少なくともfocalPointはユーザー定義のプロパティです。メディアに関するその他の考慮すべきプロパティとしては以下が挙げられます:

  • 撮影場所情報(例:location

  • 動画のフレームレート(例:fps
  • 音声用アルバムジャケット画像の提供

これらの標準化にはさらなる検討が必要です。

複数バージョンのメディア添付物

Fediverseでは現在サポートされていない機能ですが、基本的な使用方法を以下に示します:

{
  "type": "Video",
  "name": "牛が餌を食べる様子",
  "url": [
    {
      "type": "Link",
      "size": 54373,
      "digest": "zQmSzK5qEe5tpjwGMhmjx9RvVoPkWhEmCwxP2s7wPMpKMoK",
      "width": 256,
      "height": 144,
      "href": "http://pasture-one-actor/assets/cow_eating.mp4",
      "mediaType": "video/mp4"
    },
    {
      "type": "Link",
      "size": 2271723,
      "digest": "zQme2X4rgWuRdmAtGGMSEbdoeRQ2NAL2VptcdRGTYDZbSKG",
      "width": 1920,
      "height": 1080,
      "href": "http://pasture-one-actor/assets/cow_eating_hd.mp4",
      "mediaType": "video/mp4"
    }
  ],
  "duration": "PT3S"
}

この例が示すように、低画質版(54kb)と高画質版(2.2MB)の両方を動画に添付できる点が有用です。

このような機能をサポートすることで、より豊かなアプリケーション開発が可能になると考えられます。

テスト方法

json-schemaを使用することで、生成されたメディア添付物の正確性を検証できます。関連するスキーマはFediverseスキーマのメディア添付物セクションで利用可能です。これらを組み合わせて機能テストを行うには、Gherkin形式を使用できます(例:Media Format)。

完全な検証を行いたい場合、特にdigestを含むすべての要素を確認する場合は、FunFedi.devで提供されているサンプルデータを利用できます。

未解決課題

以下は、コミュニティが取り組むべき事項をまとめた「やることリスト」です:

コンテンツライセンス情報

例題で使用している画像は、pixabayにて写真家derekmullerによって無料で公開されているこの画像を基に作成されました。残念ながら、現行の標準ではこの情報をメディアオブジェクトに添付する方法が規定されていません。

attributedToプロパティで解決できるという意見もありますが、これには以下のような問題点があります: - derekmullerはActivityPubアクターではない - 自分が切り取った低解像度画像に対して彼を著作者として表示することは、彼が望まない可能性がある - 単に画像を帰属させるだけでは不十分であり、ライセンス情報も明示する必要がある

FEP-c118とその関連議論を参照してください。

認証と認可

現在、画像リンクはいかなる形式の認証も必要とせずにアクセス可能です。これはユーザーとサーバー間の通信には認証が必要で、サーバー間通信にも認証が求められる一方で、画像はS3などのサードパーティサービスに保存されることが多いため、認証機能を追加するのが困難であることが理由です。

この問題を解決するためのアプローチについては、Fediverseディスカッションを参照してください。

既存技術を用いて容易に認証と認可を実現する方法として、Bearcapsが考えられます。

別のアプローチとしては、バイナリFediverse通信方式も参照可能です。

コンテンツアドレス指定型ストレージ

メディア保存にはコストがかかるため、重複を避けることが重要です。digestMultibaseプロパティを通じてすべてのメディアに一意のダイジェストを付与することで、この情報を利用してメディアストレージを索引化できます。つまり、ファイルをダウンロードする前に、既に所有しているかどうかを確認できるわけです。

混合メディアコンテンツ

例えば、夏フェスで演奏された楽曲を投稿する場合、そのアルバムジャケット画像(例えばカラーコード#8ACE00を使用した画像)を添付したい場合があります。さらに、歌詞も添付したいというケースも考えられます。このように、単一のメディアオブジェクトに異なる種類のメディアが含まれる状況が発生します。

このような情報を伝達するため、メディア添付物用スキーマの拡張を検討すべきでしょう。

バイナリFediverse通信方式

ActivityPubの欠点として、通信形式がJSONに制限されている点が挙げられます。このため、Mediaコンテンツを伝えるためには外部手段(例えばファイルをダウンロードするなど)を用いる必要があります。

認証と認可などの問題を解決するため、通信形式でバイナリデータブロックを直接扱えるように拡張することが考えられますが、これにはワイヤフォーマットの変更が必要となります。

メッセージにバイナリデータを直接含められるようにすれば、リッチクライアントを介したメディア共有も容易になります。

参考文献

関連投稿

どうやらStreamsには添付物を保護する仕組みがあるようです。非公開ポストの画像URLは以下のようになります: https://{ドメイン}/photo/{ファイル名}.jpg?token={トークン}

IIRR(私見ですが)、少なくともHubzillaではこのトークンはOpenWebAuthの「魔法的な認証」の一部です。ここでトークンには、ユーザーの身元を確認するためにどのインスタンスに連絡すべきかという情報が含まれていると推測されます。視聴者の情報はメディアサーバーデータベースに保持され、クローン間で同期される仕組みです。

参考文献:Fediverseディスカッション

参考文献:Pixabayユーザー