Esegui Social Stream Ninja in modalità headless

Sì — usa la normale AppImage Linux

Scarica la normale app Linux e rendila eseguibile. Su un VPS senza desktop, avviare solo l'AppImage non basta: usa uno schermo virtuale e il parametro --ssapp-headless-control parametro. I passaggi sotto mantengono attiva l'acquisizione chat dopo la disconnessione SSH e dopo un riavvio del server.

La modalità headless mantiene nascoste le finestre Electron di SSApp, ma le pagine sorgente restano vere finestre browser. Linux richiede quindi uno schermo virtuale come Xvfb. Non è un piccolo demone chat che funziona solo in background.

Prima di iniziare

• Usa Ubuntu 22.04+, Debian 12+ o una distribuzione Linux simile.
• Prevedi almeno 2 GB di memoria per una piccola configurazione e di più per diverse finestre sorgente.
• Scegli una cartella profilo persistente per impostazioni, sorgenti, sessioni e dati del browser.
• Prevedi una sessione desktop o VNC iniziale per gli accessi e le altre configurazioni private.

Gli URL delle sorgenti pubbliche che non richiedono accesso sono i più semplici da gestire da remoto. OAuth, CAPTCHA, password, cookie e configurazione degli account richiedono comunque una persona.

1. Installa Xvfb e l'AppImage

sudo apt-get update
sudo apt-get install -y xvfb x11-utils xauth curl
sudo mkdir -p /opt/socialstream
sudo mv ./YOUR_DOWNLOADED_FILE.AppImage /opt/socialstream/socialstreamninja.AppImage
sudo chmod 755 /opt/socialstream/socialstreamninja.AppImage

Scarica l'AppImage Linux attuale dalla pagina dei download di Social Stream Ninja. Scegli il download corrispondente all'architettura del server (uname -m), poi sostituisci YOUR_DOWNLOADED_FILE.AppImage sopra con il suo nome file esatto. Non sono richiesti un checkout dei sorgenti né un'installazione Node separata.

2. Prepara il profilo e accedi una volta

Usa lo stesso account e la stessa cartella dati per la configurazione e il servizio in background. Crea un account dedicato:

id ssapp >/dev/null 2>&1 || sudo useradd --system --create-home --home-dir /var/lib/ssapp --shell /usr/sbin/nologin ssapp
sudo install -d -o ssapp -g ssapp -m 700 /var/lib/ssapp
sudo apt-get install -y x11vnc
sudo -u ssapp Xvfb :99 -screen 0 1920x1080x24 -nolisten tcp -extension GLX

Lascia in esecuzione quel terminale. In un secondo terminale SSH, apri SSApp in modo visibile su quello schermo virtuale:

sudo -u ssapp env DISPLAY=:99 SSAPP_USER_DATA_DIR=/var/lib/ssapp SSAPP_HEADLESS_CONTROL=0 \
  /opt/socialstream/socialstreamninja.AppImage --ozone-platform=x11 --no-hwa

In un terzo terminale SSH, avvia un accesso VNC temporaneo, limitato al server stesso:

sudo -u ssapp x11vnc -display :99 -localhost -rfbport 5900 -nopw -forever

Sul tuo computer, apri un tunnel SSH:

ssh -N -L 5900:127.0.0.1:5900 you@your-server

Connetti il visualizzatore VNC a localhost:5900. Imposta l'ID sessione Social Stream e la password facoltativa, aggiungi sorgenti e completa gli eventuali accessi. Abilita Attiva automaticamente sulle sorgenti che vuoi avviare all'avvio di SSApp. Copia i link del dock chat e dell'overlay in primo piano per usarli in seguito.

Esci da SSApp dopo la configurazione, poi arresta VNC, il tunnel e Xvfb con Ctrl+C nei rispettivi terminali. Non eseguire contemporaneamente configurazione e servizio sullo stesso profilo. VNC collegato a un'istanza già headless mostrerà normalmente uno schermo vuoto perché le finestre sono nascoste.

Usa SSAPP_USER_DATA_DIR, non il parametro di Chromium --user-data-dir. Completa gli accessi sul VPS; i cookie del browser copiati da un altro sistema operativo potrebbero non essere decifrabili.

3. Avvia l'app senza interfaccia visibile

sudo -u ssapp env SSAPP_USER_DATA_DIR=/var/lib/ssapp xvfb-run -a -s "-screen 0 1920x1080x24 -nolisten tcp -extension GLX" \
  /opt/socialstream/socialstreamninja.AppImage \
  --ozone-platform=x11 --ssapp-headless-control --no-hwa

Il --ssapp-headless-control mantiene nascoste le finestre dell'app. Questo comando in primo piano termina quando lo arresti; usa il servizio systemd descritto sotto per il funzionamento senza supervisione. L'applicazione principale richiede comunque Xvfb; --ozone-platform=headless non sostituisce lo schermo virtuale.

4. Controllala da un altro computer

Usa lo stesso ID sessione Social Stream e la stessa password facoltativa nell'app headless e nel controller remoto. WebRTC è il trasporto normale. Se non è adatto all'ambiente, usa la modalità server WebSocket ospitata di Social Stream.

I controlli remoti supportati possono aggiungere, avviare, arrestare, riavviare, silenziare e nascondere sorgenti pubbliche. Non completano da remoto accessi, OAuth, CAPTCHA, cookie, credenziali o altre configurazioni private degli account.

Consulta Sessioni, password, relay e modalità server quando il controller remoto si connette ma messaggi o comandi non arrivano.

Mantienila in esecuzione con systemd

Arresta prima l'app in primo piano con Ctrl+C. Crea /etc/systemd/system/ssapp.service con sudo nano /etc/systemd/system/ssapp.service e incolla questa unità:

[Unit]
Description=Social Stream Ninja (headless)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ssapp
StateDirectory=ssapp
WorkingDirectory=/opt/socialstream
Environment=SSAPP_USER_DATA_DIR=/var/lib/ssapp
ExecStart=/usr/bin/xvfb-run -a -s "-screen 0 1920x1080x24 -nolisten tcp -extension GLX" /opt/socialstream/socialstreamninja.AppImage --ozone-platform=x11 --ssapp-headless-control --no-hwa
Restart=on-failure
RestartSec=10
KillSignal=SIGTERM
TimeoutStopSec=30

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now ssapp
journalctl -u ssapp -f

Il servizio usa l'account e il profilo creati al passaggio 2. Parte all'avvio del sistema e si riavvia dopo un errore dell'app. Se hai cambiato il percorso di installazione, aggiorna ExecStart in modo che corrisponda.

API HTTP facoltativa per gli script sul VPS

La modalità headless non abilita l'API di controllo. Per abilitarla nel servizio, esegui sudo systemctl edit ssapp e salva questa configurazione aggiuntiva:

[Service]
Environment=SSAPP_CONTROL_API=1

sudo systemctl daemon-reload
sudo systemctl restart ssapp
curl -sS http://127.0.0.1:17777/api/v1/capabilities
curl -sS http://127.0.0.1:17777/api/v1/status

Per un avvio manuale, aggiungi --ssapp-control-api al comando dell'app. Esegui i comandi seguenti in una shell SSH sul VPS. L'API è intenzionalmente senza token e si associa solo a 127.0.0.1; è separato dal tuo server web Owncast o Rocket.Chat. Mantienilo locale.

Leggi ssappVersion, apiVersion, e prima le piattaforme supportate nelle capacità. Ad esempio, se Twitch è supportato, aggiungi una sorgente (sostituisci CHANNEL_NAME):

curl -sS http://127.0.0.1:17777/api/v1/command \
  -H 'Content-Type: application/json' \
  -d '{"action":"addSource","value":{"target":"twitch","username":"CHANNEL_NAME","autoActivate":true}}'

curl -sS http://127.0.0.1:17777/api/v1/command \
  -H 'Content-Type: application/json' \
  -d '{"action":"getSources","value":{}}' 

Copia l'identificatore stabile della sorgente id dall'elenco delle sorgenti restituito e sostituisci SOURCE_ID sotto. Aggiungere una sorgente la lascia inattiva; autoActivate controlla i futuri avvii dell'app.

curl -sS http://127.0.0.1:17777/api/v1/command \
  -H 'Content-Type: application/json' \
  -d '{"action":"startSource","value":{"sourceId":"SOURCE_ID"}}'

curl -sS http://127.0.0.1:17777/api/v1/command \
  -H 'Content-Type: application/json' \
  -d '{"action":"getSourceDiagnostics","value":{"sourceId":"SOURCE_ID"}}'

curl -sS http://127.0.0.1:17777/api/v1/command \
  -H 'Content-Type: application/json' \
  -d '{"action":"stopSource","value":{"sourceId":"SOURCE_ID"}}' 

Controlla ok e payload in ogni risposta; gli errori restituiscono error. Leggi lo stato dopo una modifica. Se una richiesta scade, controlla lo stato prima di riprovarla. Arresta una sorgente prima di modificarne i campi di connessione. I comandi di ricaricamento, rimozione e spegnimento richiedono confirm: true.

curl -N http://127.0.0.1:17777/api/v1/events segue il feed Server-Sent Events fino a Ctrl+C. Vedi la Guida API e MCP per il riferimento completo. Sono controlli dell'app/delle sorgenti; le azioni overlay, come portare un messaggio chat in primo piano, usano il dock Social Stream e comandi Social Stream.

MCP facoltativo per un client IA sul VPS

MCP consente a un client IA compatibile di chiamare i controlli SSApp come strumenti. Abilita l'API descritta sopra e mantieni in esecuzione il servizio dell'app principale. Registra questa configurazione in un client in esecuzione sul VPS:

{
  "mcpServers": {
    "social-stream": {
      "command": "/opt/socialstream/socialstreamninja.AppImage",
      "args": ["--ssapp-mcp", "--ozone-platform=headless"],
      "env": {
        "SSAPP_CONTROL_URL": "http://127.0.0.1:17777"
      }
    }
  }
}

La posizione della configurazione dipende dal client. Questo avvia un adattatore separato tramite input/output standard; non avvia l'app principale di acquisizione. Un client sul tuo computer di casa punterebbe al proprio localhost, non al VPS. Da un altro computer, usa i normali controlli remoti di Social Stream.

L'adattatore incluso è disponibile da SSApp 0.4.7; la versione 0.4.14 e successive dichiarano l'insieme completo degli strumenti anche prima che l'app sia disponibile. Le capacità effettive determinano comunque quali chiamate funzionano. Non serve un'installazione Node separata. Il parametro headless Ozone qui si applica solo all'adattatore MCP; mantieni Xvfb per l'app principale.

Prova: “Chiama ssapp_get_capabilities, poi ssapp_get_status e ssapp_list_sources. Dimmi quali sorgenti stanno acquisendo e se qualcuna segnala errori.” Gli strumenti coprono anche avvio/arresto delle sorgenti, diagnostica, eventi acquisiti, screenshot e interazioni approvate con le finestre dell'app. Gli accessi privati e i CAPTCHA richiedono comunque una persona.

Consulta Guida all'API di controllo locale e a MCP per la skill facoltativa dell'agente, la compatibilità delle versioni e altri controlli.

Owncast, Rocket.Chat e messaggi in primo piano

Puoi eseguire SSApp sullo stesso VPS di Owncast e Rocket.Chat se dispone di risorse sufficienti. Installare SSApp da solo non connette Rocket.Chat e non inserisce overlay nel video.

Supported chat source → SSApp → Social Stream dock / featured overlay
                                           ↓
Video input → server broadcaster renders overlays → Owncast → viewers

Nei sorgenti controllati per questa guida non esiste un connettore Rocket.Chat integrato. Serve un'integrazione separata per portare quei messaggi in Social Stream. Verifica che i messaggi arrivino al dock prima di configurare l'overlay video.

Usa gli URL del dock e dell'overlay in primo piano copiati durante la configurazione, con la stessa sessione/password e lo stesso trasporto. Seleziona un messaggio acquisito nel dock per portarlo in primo piano. Il software di trasmissione sul server deve renderizzare sorgenti browser per sovrapporre queste pagine al video prima di inviare la diretta combinata a Owncast. Vedi istruzioni di trasmissione di Owncast. SSApp non è quel software di trasmissione video.

Un overlay posizionato sopra un lettore incorporato nel tuo sito è un'opzione diversa: compare su quella pagina, invece di far parte del video ricevuto dagli altri lettori o dalle registrazioni. Owncast documenta incorporamento di video e chat.

Per spegnere il computer di casa, la sorgente video, il software di trasmissione, l'acquisizione chat e l'eventuale integrazione Rocket.Chat devono continuare a funzionare indipendentemente da esso. Prevedi risorse per rendering e codifica video separatamente dalla memoria di SSApp per l'acquisizione chat.

Controlla l'intero flusso prima di lasciarlo senza supervisione

1. Invia un messaggio reale in una chat connessa e conferma che arrivi nel tuo dock Social Stream.
2. Porta quel messaggio in primo piano e conferma che l'overlay in primo piano cambi. Per Owncast, verificalo anche nel video effettivamente visto dal pubblico.
3. Disconnetti VNC e SSH, poi invia altri messaggi per diversi minuti. L'acquisizione dovrebbe continuare.
4. Esegui sudo systemctl restart ssapp, poi conferma che tornino la stessa sessione e le stesse sorgenti e che le sorgenti attivate automaticamente ricevano nuovi messaggi.
5. Durante una finestra di manutenzione, riavvia il VPS e ripeti il controllo dei messaggi. Un processo in esecuzione o una risposta API riuscita, da soli, non dimostrano che l'acquisizione chat funzioni.

Usa sudo systemctl status ssapp e sudo journalctl -u ssapp -n 100 --no-pager per lo stato del servizio e i log recenti. Per arrestarlo intenzionalmente, usa sudo systemctl stop ssapp.

Per gli aggiornamenti, arresta il servizio, salva un backup di /var/lib/ssapp, sostituisci l'AppImage nello stesso percorso e riavvia il servizio. Conserva l'eseguibile precedente finché la nuova versione non supera i controlli dei messaggi.

Risoluzione dei problemi

Guide correlate

• Spiegazione dei server e servizi locali
• API di controllo locale e MCP
• Modalità dell'app autonoma