PeerTube

ActivityPubで独立インスタンスを連合し、動画とチャンネルをFediverseへ広げる

PeerTubeは一つの中央サービスではなく、独立したvideo hosting providerが相互運用する連合型の構成です。動画に説明やタグを付けて公開すると、自インスタンスだけでなくvideo fediverseから検索・発見できる設計です。

視聴者はPeerTube上だけでなく、MastodonやPleromaなどのActivityPub対応サービスからチャンネルをフォローできます。RSSも提供されるため、視聴・購読の入口を一つのサイトへ固定しません。

出典：[2]

VOD・ライブ配信・埋め込み・APIまで、動画公開の基本機能を一つの基盤で持つ

通常の動画アップロードに加えてライブ配信と常設ストリームを扱え、外部サイトへplayerを埋め込めます。管理者は見た目やインスタンス間の表示・購読方針を調整できます。

技術面ではREST APIのOpenAPI schemaとActivityPub documentationが公開され、独自clientや周辺toolから操作できる拡張面も用意されています。

出典：[2]

WebRTC P2Pとインスタンス間cacheで、originだけに集中する配信負荷を分散する

視聴者同士がWebRTC P2Pでvideo dataを共有し、同時視聴時のserver帯域を分散できます。さらに友好インスタンスが互いの動画をcacheするredundancyも利用できます。

これはorigin serverやstorageを不要にする仕組みではありません。P2P参加率、NATやnetwork条件、cache設定によって効果は変わるため、想定視聴数とbitrateを前提に回線・storage容量を設計する必要があります。

出典：[2][4]

コミュニティ・教育・独立メディアなど、運営ポリシーとデータを自分で持ちながら外部へ連合したい用途に

YouTube互換の巨大サービスを一つ作るより、組織やコミュニティごとに動画基盤を運営しつつ、外部のPeerTubeやFediverseと発見・購読をつなげたいケースに向きます。広告ネットワークや単一ベンダーへ依存せず、公開方針やUI、連合範囲を運営者が決めたい場合に比較価値があります。

動画self-hostは重量級。FFmpeg・PostgreSQL・Redis・Nginx・帯域とstorageを含めて運用する

v8.3.0の公式dependenciesはNode.js 22 LTS、pnpm 10以上、PostgreSQL 14以上、Redis 6.2以上、FFmpeg 4.3以上などを要求します。production guideは低帯域回線上でのproduction運用を避けるよう明記しています。

transcodingはCPUを使い、動画本体・thumbnail・torrent/HLSなどはstorageを消費します。公開環境ではTLS、reverse proxy、backup、monitoring、SMTP、容量監視まで含めてvideo serviceとして運用設計する必要があります。

出典：[5][4]

v8.3.0へのupgradeはDB migrationに加え、起動後の手動migration scriptが必要

v8.3.0 release notesは、動画件数が多いdatabaseでは起動時migrationに数分かかり得るため短時間のdowntimeを計画するよう案内しています。

さらにdatabase migration完了後、PeerTube稼働中に8.3専用migration scriptを手動実行する必要があります。upgrade前にbackupと手順確認を行い、API変更を利用するpluginやclientも検証対象に含めるべきです。

出典：[3]

連合は到達範囲を広げる一方、インスタンス間ポリシーとmoderationの設計が必要

PeerTubeは管理者が他インスタンスの動画を一覧へ出すか、ユーザーの購読だけを許可するかなどを調整できます。分散型だから自動的に運用負荷がなくなるわけではなく、どのインスタンスと連合し、何を自サイトへ表示するかを決める必要があります。

公開コミュニティで使う場合は、利用規約、通報対応、remote contentの扱い、block/follow方針を技術設定とセットで決めておく方が安全です。

出典：[2]

AGPL-3.0。変更版をnetwork serviceとして提供する場合はsource提供要件を確認する

PeerTubeのcodeはGNU Affero General Public License v3.0 or laterで公開されています。AGPLはnetwork server softwareでの改変利用もsource availabilityを重視するlicenseです。

そのまま利用する場合と改変して公開serviceとして提供する場合では確認事項が変わるため、forkや独自改修を運用する組織はAGPLの条件を事前に確認してください。

出典：[2][6]