In questa pagina
Che cos'è un type?
type è l'identificatore canonico della sorgente in un payload Social Stream in arrivo. Overlay, filtri URL, API ed Event Flow lo usano per distinguere piattaforme e varianti delle sorgenti.
{
"type": "youtubeshorts",
"chatname": "Ava",
"chatmessage": "Hello from Shorts"
}
| Nome | Significato | Non confonderlo con |
|---|---|---|
type |
La sorgente del payload in arrivo, come youtube oppure instagramlive. |
Un'etichetta visualizzata, una modalità di connessione o un nome evento. |
event |
Cosa è successo, ad esempio superchat, gift, oppure viewer_update. |
La piattaforma che lo ha prodotto. |
sourceName |
Un nome visualizzato facoltativo di canale, stanza o sorgente. | Il valore stabile usato da un trigger From Source. |
tid |
L'ID della scheda o della finestra sorgente desktop di origine, usato per rispondere ed escludere la sorgente. | Un tipo di piattaforma. |
App desktop target |
La categoria salvata usata per scegliere URL, modalità e script di acquisizione. | Una garanzia che ogni payload emesso abbia la stessa stringa. |
Importante: Il trigger di Event Flow Dalla sorgente (From Source) confronta direttamente il valore configurato con message.type. Usa il valore esatto in minuscolo del payload.
Tipi comuni e ambigui
| Nome nell'acquisizione o nell'interfaccia | Tipo del payload | Perché può sorprendere |
|---|---|---|
| Chat dal vivo YouTube | youtube |
DOM, polling API e WebSocket/streaming descrivono il trasporto, non tipi separati. |
| Chat dal vivo YouTube Shorts | youtubeshorts |
È distinto per i filtri in arrivo e le destinazioni relay Event Flow, mentre i controlli YouTube condivisi trattano entrambe le varianti come un'unica famiglia quando necessario. |
| Instagram Live / InstaFeed live | instagramlive |
I commenti dei post e del feed Instagram usano instagram. |
| TikFinity | tiktok |
TikFinity è il connettore; la piattaforma normalizzata resta TikTok. |
| X | x, oppure il precedente twitter con l'opzione del marchio Twitter |
I filtri esistenti possono mantenere intenzionalmente il vecchio nome. |
| Scelte regionali Bilibili | bilibili |
Destinazioni e script desktop possono chiamarsi bilibilicom oppure bilibilitv, mentre i payload vengono normalizzati. |
| Eventi di sistema OBS | obs |
Non sono sorgenti chat, ma possono entrare in Event Flow con eventi come scene_changed. |
Usa: Riferimento degli eventi per il contratto dei campi e Siti supportati per i nomi pubblici di configurazione delle piattaforme.
YouTube Shorts ed Event Flow
La corrispondenza in arrivo è esatta: usa youtubeshorts in un trigger From Source per i messaggi Shorts, e youtube per la normale chat dal vivo YouTube.
Anche la corrispondenza in uscita è esatta: Relay Chat li tratta come destinazioni separate.
- Destinazione
youtubeinvia solo alle normali finestre chat dal vivo YouTube. - Destinazione
youtubeshortsinvia solo alle finestre chat dal vivo YouTube Shorts. - Per raggiungere entrambi, aggiungi un'azione per ogni destinazione oppure inoltra a tutte le piattaforme escludendo la sorgente.
Altri controlli generali di YouTube possono gestire intenzionalmente entrambi i tipi come un'unica famiglia di piattaforma. Questo non cambia la corrispondenza esatta Event Flow descritta sopra.
Risoluzione dei problemi delle versioni precedenti
Le versioni precedenti raggruppavano entrambe le destinazioni relay, quindi due azioni potevano inviare due volte a ogni finestra YouTube. Aggiorna Social Stream Ninja se succede. Reflection Filter previene i cicli del relay, ma non corregge la sovrapposizione delle destinazioni nelle versioni precedenti.
Prosegui con la Guida a Event Flow oppure Guida alla configurazione YouTube.
Instagram Live e commenti Instagram
Usa instagramlive per la chat delle stanze live acquisita dalla sorgente Instagram Live o InstaFeed live. Usa instagram per feed non live, post o commenti statici.
- Flusso chat dal vivo: From Source =
instagramlive. - Flusso post/commenti: From Source =
instagram. - Entrambi: usa due trigger che alimentano un'unica azione condivisa, oppure un trigger Any Source seguito da un filtro che tenga conto del tipo.
Il marchio Instagram visibile non basta per scegliere il tipo; il contesto del contenuto distingue i due.
Sorgenti generiche, personalizzate e senza nome
sources/generic.js è un'alternativa generale di acquisizione DOM. Cerca righe chat, nomi, messaggi, avatar e input comuni. Inizia con generic, poi normalmente ricava un tipo in minuscolo da una piattaforma nota o dal nome host della pagina.
- Usalo per verificare che una normale chat DOM possa essere acquisita prima di scrivere una sorgente dedicata.
- Non aspettarti un supporto affidabile per eventi, moderazione, eliminazioni, elenchi virtualizzati o shadow DOM chiuso.
- Un tipo ricavato dal nome host è comodo, ma non è un contratto pubblico permanente. Conferma il payload emesso prima di costruirvi intorno dei filtri.
- Se una sorgente non ha un nome di piattaforma stabilito, scegli un valore stabile in minuscolo per
type. UsasourceNameper l'etichetta della stanza o del canale destinata alle persone. - Se non esiste ancora un'identità stabile,
genericè più sicuro che cambiare tipo a ogni messaggio. Le integrazioni esterne usano comunemente un valore deliberato comeexternal.
Quando utenti, overlay o flussi dipendono da un nuovo tipo, documentalo nel Riferimento degli eventi invece di rinominarlo silenziosamente.
Iniezione degli script nell'app desktop
L'app desktop salva per la sorgente un target, sceglie uno o più sourceFile/sourceFiles, apre una finestra sorgente e inietta gli script di acquisizione condivisi di questo progetto. Un bridge di compatibilità con Chrome runtime trasporta messaggi acquisiti e comandi di risposta tra pagina e app.
- Una destinazione e un nome file script non devono necessariamente corrispondere al tipo del payload. La destinazione
youtubeshortscaricasources/youtube.js, che emetteyoutubeoppureyoutubeshortsdal contesto della pagina. - Le destinazioni Bilibili sono analogamente associate a script condivisi/regionali, emettendo
bilibili. sources/inject/*.jssono helper nel contesto della pagina per socket o variabili della pagina. Il wrapper della sorgente resta responsabile del payload canonico.- Quando vengono iniettati più script, evita che ogni helper dichiari la stessa destinazione in uscita. L'identità di acquisizione e la capacità di risposta sono aspetti separati.
- Le modifiche all'acquisizione delle sorgenti vanno nei file di questo repository
sources/. L'app desktop li usa; la sua copia di ripiego inclusa non è la fonte autorevole.
I manutentori possono seguire la configurazione nel file dell'app desktop index.html creazione della finestra sorgente, poi main.js e preload.js per iniezione e bridge.
Rispondere e inoltrare alle sorgenti
L'identità in arrivo e la capacità di invio sono correlate, ma non hanno lo stesso contratto.
| Azione | Come sceglie | Problema comune |
|---|---|---|
| Rispondi alla sorgente | Usa tid per indirizzare la scheda/finestra di origine esatta. |
No tid, oppure quella modalità di acquisizione non può inviare messaggi chat. |
| Inoltra a una piattaforma | Chiede alle sorgenti aperte se supportano quella destinazione in uscita. | La variante selezionata non ha una finestra sorgente aperta corrispondente, oppure la sorgente non può inviare chat. |
| Inoltra a tutti tranne la sorgente | Trasmette alle sorgenti instradabili ed esclude quella di origine tid. |
Una sorgente non può accettare input automatico, oppure un messaggio di ritorno viene acquisito di nuovo. |
- Il campo di uno script sorgente
getSourceè un segnale di instradabilità in uscita. I controlli YouTube condivisi possono raggruppare entrambe le varianti, mentre Relay Chat aggiunge il contesto URL esatto degli Shorts per la corrispondenza delle destinazioni. - L'acquisizione generica può trovare e mettere a fuoco gli input probabili, ma non garantisce che il sito accetti un invio automatico.
- Le modalità API/WebSocket possono inviare tramite API della piattaforma invece di digitare nella pagina visibile.
- Nell'app desktop, Bot solo risposte (nessuna acquisizione) mantiene una sorgente disponibile per risposte/stato sopprimendo i normali messaggi acquisiti.
- Prova il supporto delle risposte con una finestra sorgente prima di creare un relay multipiattaforma.
Dove trovare i dettagli esatti
- Riferimento degli eventi: campi canonici e nomi degli eventi delle piattaforme.
- Guida a Event Flow: trigger, azioni, template, gestione dei messaggi di ritorno e test.
- Modalità dell'app autonoma: comportamento delle finestre sorgente e delle modalità di connessione.
- Siti supportati: nomi delle piattaforme e requisiti di configurazione.
- Sorgenti generiche e personalizzate: acquisizione alternativa ed esterna.
- Finestre sorgente dell'app desktop: dettagli interni di destinazioni, script, bridge e modalità solo risposte.
- Aggiungere una sorgente: contratti delle sorgenti, helper di iniezione, manifest e documentazione.
Durante il debug, esamina un payload grezzo e annota il suo type, event, sourceName, e tid. Di solito permette di distinguere corrispondenza in arrivo, instradamento in uscita e duplicazione dell'acquisizione.