ソースタイプ

このページの内容

タイプとは
よく使う名前と混同しやすい名前
YouTube ShortsとEvent Flow
Instagram LiveとInstagramのコメント
汎用、カスタム、名前なしのソース
デスクトップアプリのスクリプト挿入
ソースへの返信と中継
詳しい仕様の参照先

次の値とは： `type`?

type は、受信したSocial Streamペイロードの標準のソース識別子です。オーバーレイ、URLフィルター、API、Event Flowが、プラットフォームやソースの種類を区別するために使用します。

{
  "type": "youtubeshorts",
  "chatname": "Ava",
  "chatmessage": "Hello from Shorts"
}

名前	意味	混同しないでください
`type`	受信ペイロードのソース。例： `youtube` または `instagramlive`.	表示ラベル、接続モード、イベント名。
`event`	発生した出来事。例： `superchat`, `gift`、または `viewer_update`.	そのイベントを生成したプラットフォーム。
`sourceName`	任意のチャネル名、ルーム名、ソース表示名。	From Sourceトリガーが使う一貫した値。
`tid`	返信や送信元の除外に使用する、送信元タブまたはデスクトップのソースウィンドウのID。	プラットフォームのタイプ。
デスクトップアプリ `target`	URL、モード、キャプチャスクリプトの選択に使う保存済みカテゴリ。	送信されるすべてのペイロードが同じ文字列になるという保証。

重要： Event Flowの ソース指定（From Source） トリガーは、設定された値を次と直接比較します： message.type。ペイロードの小文字の値を正確に使用してください。

よく使うタイプと混同しやすいタイプ

取得方法またはUI名	ペイロードのタイプ	混乱しやすい理由
YouTubeのライブチャット	`youtube`	DOM、APIポーリング、WebSocket/ストリーミングは通信方式であり、別のタイプではありません。
YouTube Shortsのライブチャット	`youtubeshorts`	受信フィルターとEvent Flowの中継先では別々に扱われます。一方、共通のYouTube操作では、必要に応じて両方を同じグループとして扱います。
Instagram Live / InstaFeedライブ	`instagramlive`	Instagramの投稿やフィードのコメントには、次を使用します： `instagram`.
TikFinity	`tiktok`	TikFinityは接続ツールであり、正規化されたプラットフォーム名はTikTokのままです。
X	`x`、または従来の `twitter` にTwitterブランド表示のオプションを適用した場合	既存のフィルターでは、意図的に古い名前を維持している場合があります。
Bilibiliの地域別選択肢	`bilibili`	デスクトップのターゲットやスクリプトでは、次の名前を使用する場合があります： `bilibilicom` または `bilibilitv`ですが、ペイロードは正規化されます。
OBSシステムイベント	`obs`	これらはチャットソースではありませんが、次のようなイベントでEvent Flowに入ることがあります： `scene_changed`.

使用するもの：イベントリファレンスでフィールド仕様を、次で対応サイトで公開されているプラットフォームの設定名を確認できます。

YouTube ShortsとEvent Flow

受信時は完全一致で照合します： 使用するもの： youtubeshorts をShortsメッセージ用のFrom Sourceトリガーに使い、 youtube は通常のYouTubeライブチャットに使います。

送信時も完全一致で照合します： Relay Chatはそれぞれを別の送信先として扱います。

送信先 youtube は通常のYouTubeライブチャットウィンドウにのみ送信します。
送信先 youtubeshorts はYouTube Shortsのライブチャットウィンドウにのみ送信します。
両方に送信するには、送信先ごとにアクションを1つ追加するか、送信元を除く全プラットフォームへ中継してください。

YouTube全体に適用する他の操作では、意図的に両方のタイプを同じプラットフォームのグループとして扱うことがあります。上記のEvent Flowの完全一致による照合は変わりません。

古いバージョンのトラブルシューティング

古いバージョンでは両方の中継先をまとめて扱っていたため、アクションを2つ設定すると各YouTubeウィンドウへ2回ずつ送信する場合がありました。この現象が起きる場合はSocial Stream Ninjaを更新してください。Reflection Filterは中継ループを防ぎますが、古いバージョンで送信先の照合が重複する問題は修正しません。

トリガー、フィルター、アクションの各ノードが接続されたSocial Stream NinjaのEvent Flowエディタ — From Sourceは受信ペイロードのタイプを読み取り、Relay Chatは送信先のソースウィンドウを選択します。

詳しくは次をご覧ください： Event Flowガイドまたは YouTube設定ガイド.

Instagram LiveとInstagramコメントの違い

使う項目： instagramlive は、Instagram LiveまたはInstaFeedライブのソースから取得したライブルームのチャットに使います。次を使用してください： instagram は、ライブ以外のフィード、投稿、静的なコメントに使います。

ライブチャットのフロー： From Source = instagramlive.
投稿/コメントのフロー： From Source = instagram.
両方： 2つのトリガーを1つの共通アクションへ接続するか、Any Sourceトリガーの後にタイプを判別するフィルターを置きます。

表示上のInstagramブランド名だけではタイプを選べません。コンテンツの種類によって両者が区別されます。

汎用、カスタム、名前なしのソース

sources/generic.js は、幅広いページに対応するDOM取得の代替手段です。よく使われるチャット行、名前、メッセージ、アバター、入力欄を探します。最初の値は generic。通常は、既知のプラットフォームまたはページのホスト名から小文字のタイプを決定します。

専用ソースを作成する前に、一般的なDOMチャットを取得できるか確認するために使用してください。
イベント、モデレーション、削除、仮想化リスト、閉じたShadow DOMへの確実な対応は期待しないでください。
ホスト名から生成したタイプは便利ですが、永続的な公開仕様ではありません。それを使ったフィルターを作成する前に、実際に送信されるペイロードを確認してください。
ソースに定まったプラットフォーム名がない場合は、小文字で一貫した次の値を1つ選んでください： type。使う項目： sourceName は、人が読むためのルーム名やチャネル名に使います。
まだ一貫した識別名がない場合は、 generic を使う方が、メッセージごとにタイプを変更するより安全です。外部連携では通常、次のような意図的に選んだ値を使用します： external.

ユーザー、オーバーレイ、フローが新しいタイプに依存するようになったら、次に記載してください：イベントリファレンス。名前だけを黙って変更しないでください。

デスクトップアプリのスクリプト挿入

デスクトップアプリはソースの次の値を保存します： targetを選択し、1つ以上の次の項目を決定します： sourceFile/sourceFiles。ソースウィンドウを開き、このプロジェクトの共通キャプチャスクリプトを挿入します。Chromeランタイム互換ブリッジが、取得したメッセージと返信コマンドをページとアプリの間で受け渡します。

ターゲットやスクリプトのファイル名は、ペイロードのタイプと一致するとは限りません。 youtubeshorts ターゲットは次を読み込みます： sources/youtube.js。出力される値は youtube または youtubeshorts をページコンテキストから取得します。
Bilibiliのターゲットも同様に共通または地域別のスクリプトへ対応付けられますが、送信される値は bilibili.
sources/inject/*.js ファイルは、ソケットやページ変数を扱うページコンテキスト用ヘルパーです。標準ペイロードの生成は引き続きソースラッパーが担当します。
複数のスクリプトを挿入する場合、すべてのヘルパーが同じ送信先への対応を宣言しないようにしてください。取得元の識別と返信機能は別々に扱います。
ソースの取得処理の変更は、このリポジトリの次の場所で行います： sources/ ファイルです。デスクトップアプリはこれらを使用します。アプリに同梱された代替コピーは正本ではありません。

接続モードを表示したSocial Stream Ninjaデスクトップアプリのソース一覧 — デスクトップの各ソースは、個別のターゲット、URL、接続モード、キャプチャスクリプトを保持します。

メンテナーは、デスクトップアプリの次の箇所から設定処理を追跡できます： index.html でソースウィンドウの作成を確認し、その後、 main.js および preload.js で挿入とブリッジ処理を確認できます。

ソースへの返信と中継

受信元の識別と送信能力は関連していますが、同じ仕様ではありません。

操作	選択方法	よくある失敗
送信元へ返信	使用する値： `tid` で送信元のタブ/ウィンドウを正確に指定します。	不要 `tid`、またはその取得モードがチャット送信に対応していません。
プラットフォームへ中継	開いているソースに、その送信先へ送信できるか問い合わせます。	選択した種類に一致するソースウィンドウが開いていないか、ソースがチャットを送信できません。
送信元以外のすべてへ中継	送信可能なソースへ一斉送信し、送信元の次の値を除外します： `tid`.	ソースが自動入力を受け付けない、または反射したメッセージを再び取得してしまいます。

ソーススクリプトの getSource という応答は、その送信先に送信可能であることを示します。共通のYouTube操作は両方の種類をまとめて扱う場合がありますが、Relay Chatは送信先の照合に正確なShorts URLのコンテキストを加えます。
汎用取得は入力欄らしい要素を探してフォーカスできますが、そのサイトが自動送信を受け付ける保証はありません。
API/WebSocketモードでは、表示中のページに文字を入力する代わりに、プラットフォームのAPIで送信する場合があります。
デスクトップアプリでは、 ボット返信専用（取得なし）（Bot reply-only） は、通常の取得メッセージを抑制しながら、そのソースを返信やステータス取得に利用できる状態に保ちます。
複数プラットフォームの中継を作成する前に、1つのソースウィンドウで返信対応をテストしてください。

詳しい仕様の参照先

イベントリファレンス：標準フィールドとプラットフォームのイベント名。
Event Flowガイド：トリガー、アクション、テンプレート、反射メッセージの処理、テスト。
単体アプリのモード：ソースウィンドウと接続モードの動作。
対応サイト：プラットフォーム名と設定要件。
汎用ソースとカスタムソース：代替手段と外部からの取得。
デスクトップアプリのソースウィンドウ：ターゲット、スクリプト、ブリッジ、返信専用モードの内部処理。
ソースの追加：ソース仕様、挿入用ヘルパー、マニフェスト、ドキュメント。

デバッグする際は、生のペイロードを1件確認し、次の値を記録してください： type, event, sourceName、および tid。通常、これで受信時の照合、送信先の振り分け、重複取得を切り分けられます。