Social Stream Ninja ohne sichtbare Oberfläche ausführen

Ja — verwende die normale Linux-AppImage

Lade die normale Linux-App herunter und mache sie ausführbar. Auf einem VPS ohne Desktop reicht der AppImage-Start allein nicht aus: Verwende eine virtuelle Anzeige und die --ssapp-headless-control Option. Die folgenden Schritte halten die Chaterfassung nach dem Trennen von SSH und nach einem Serverneustart aktiv.

Im Headless-Modus bleiben SSApps Electron-Fenster verborgen, aber die Quellseiten sind weiterhin echte Browserfenster. Linux benötigt daher eine virtuelle Anzeige wie Xvfb. Dies ist kein kleiner reiner Hintergrunddienst für Chat.

Vor dem Start

• Verwende Ubuntu 22.04+, Debian 12+ oder eine ähnliche Linux-Distribution.
• Plane mindestens 2 GB Arbeitsspeicher für eine kleine Einrichtung und mehr für mehrere Quellfenster ein.
• Wähle einen dauerhaften Profilordner für Einstellungen, Quellen, Sitzungen und Browserdaten.
• Plane für Anmeldungen und weitere private Einrichtung eine einmalige Desktop- oder VNC-Sitzung ein.

Öffentliche Quell-URLs ohne Anmeldung lassen sich am einfachsten fernbetreiben. OAuth, CAPTCHA, Passwörter, Cookies und Kontoeinrichtung benötigen weiterhin einen Menschen.

1. Xvfb und die AppImage installieren

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

Lade die aktuelle Linux-AppImage von der Social Stream Ninja Downloadseite. Wähle den Download passend zur Serverarchitektur (uname -m), und ersetze dann YOUR_DOWNLOADED_FILE.AppImage oben durch den genauen Dateinamen. Ein Quellcode-Checkout und eine separate Node-Installation sind nicht erforderlich.

2. Profil vorbereiten und einmal anmelden

Verwende für Einrichtung und Hintergrunddienst dasselbe Konto und Datenverzeichnis. Erstelle ein eigenes Konto:

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

Lass dieses Terminal laufen. Öffne SSApp in einem zweiten SSH-Terminal sichtbar auf dieser virtuellen Anzeige:

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

Starte in einem dritten SSH-Terminal einen vorübergehenden VNC-Zugang, der auf den Server selbst beschränkt ist:

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

Öffne auf deinem eigenen Computer einen SSH-Tunnel:

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

Verbinde deinen VNC-Viewer mit localhost:5900. Lege Social-Stream-Sitzungs-ID und optionales Passwort fest, füge Quellen hinzu und schließe erforderliche Anmeldungen ab. Aktiviere Automatisch aktivieren (Auto-activate) bei den Quellen, die beim Start von SSApp starten sollen. Kopiere deine Chat-Dock- und Featured-Overlay-Links für später.

Beende SSApp nach der Einrichtung und stoppe dann VNC, den Tunnel und Xvfb mit Strg+C in ihren Terminals. Führe Einrichtung und Dienst nicht gleichzeitig mit demselben Profil aus. Ein VNC-Zugang an einer bereits headless laufenden Instanz zeigt normalerweise eine leere Anzeige, weil deren Fenster verborgen sind.

Verwende SSAPP_USER_DATA_DIR, nicht Chromiums --user-data-dir. Führe Anmeldungen auf dem VPS durch; von einem anderen Betriebssystem kopierte Browsercookies lassen sich möglicherweise nicht entschlüsseln.

3. App ohne sichtbare Oberfläche starten

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

Der --ssapp-headless-control Option hält die App-Fenster verborgen. Dieser Vordergrundbefehl endet, wenn du ihn stoppst; verwende für unbeaufsichtigten Betrieb den systemd-Dienst unten. Die Hauptanwendung benötigt weiterhin Xvfb; --ozone-platform=headless ist kein Ersatz für die virtuelle Anzeige.

4. Von einem anderen Computer steuern

Verwende dieselbe Social-Stream-Sitzungs-ID und dasselbe optionale Passwort in der Headless-App und der Fernsteuerung. WebRTC ist der normale Transport. Wenn es für die Umgebung ungeeignet ist, verwende Social Streams gehosteten WebSocket-Servermodus.

Unterstützte Fernsteuerungsbefehle können öffentliche Quellen hinzufügen, starten, stoppen, neu starten, stummschalten und ausblenden. Sie führen keine Anmeldung, OAuth-, CAPTCHA-, Cookie-, Zugangsdaten- oder andere private Kontoeinrichtung aus der Ferne durch.

Siehe Sitzungen, Passwörter, Relay- und Servermodi wenn sich die Fernsteuerung verbindet, aber keine Nachrichten oder Befehle ankommen.

Mit systemd dauerhaft ausführen

Stoppe zuerst die Vordergrund-App mit Strg+C. Erstelle /etc/systemd/system/ssapp.service mit sudo nano /etc/systemd/system/ssapp.service und füge diese Unit ein:

[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

Der Dienst verwendet das in Schritt 2 erstellte Konto und Profil. Er startet beim Booten und nach einem App-Absturz neu. Wenn du den Installationspfad geändert hast, passe ExecStart entsprechend an.

Optionale HTTP-API für Skripte auf dem VPS

Der Headless-Modus aktiviert die Steuerungs-API nicht. Führe zum Aktivieren für deinen Dienst sudo systemctl edit ssapp und speichere diese Überschreibung:

[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

Füge für einen manuellen Start --ssapp-control-api stattdessen zum App-Befehl hinzu. Führe die folgenden Befehle in einer SSH-Shell aus auf dem VPS läuft. Die API hat bewusst kein Token und bindet ausschließlich an 127.0.0.1; sie ist von deinem Owncast- oder Rocket.Chat-Webserver getrennt. Halte sie lokal.

Lies ssappVersion, apiVersion, und zuerst die unterstützten Plattformen in den Fähigkeiten. Wenn beispielsweise Twitch unterstützt wird, füge eine Quelle hinzu (ersetze 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":{}}' 

Kopiere die stabile id aus der zurückgegebenen Quellenliste und ersetze SOURCE_ID unten. Das Hinzufügen einer Quelle lässt sie inaktiv; autoActivate steuert zukünftige App-Starts.

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"}}' 

Prüfe ok und payload in jeder Antwort; Fehler geben error. Lies nach einer Änderung den Zustand aus. Wenn eine Anfrage ein Zeitlimit erreicht, prüfe vor dem Wiederholen den Zustand. Stoppe eine Quelle, bevor du ihre Verbindungsfelder änderst. Befehle zum Neuladen, Entfernen und Herunterfahren erfordern confirm: true.

curl -N http://127.0.0.1:17777/api/v1/events folgt dem Server-Sent-Events-Feed bis Strg+C. Siehe den API- und MCP-Leitfaden für die vollständige Referenz. Dies sind App-/Quellensteuerungen; Overlay-Aktionen wie das Hervorheben einer Chatnachricht verwenden das Social-Stream-Dock und Social-Stream-Befehle.

Optionales MCP für einen KI-Client auf dem VPS

MCP ermöglicht einem kompatiblen KI-Client, SSApp-Steuerungsfunktionen als Werkzeuge aufzurufen. Aktiviere die API oben und lass den Haupt-App-Dienst laufen. Registriere diese Konfiguration in einem Client, der auf dem VPS läuft:

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

Der Konfigurationsort hängt vom Client ab. Dies startet einen separaten Adapter über Standardein-/ausgabe, nicht die Haupt-App zur Erfassung. Ein Client auf deinem Heimcomputer würde seinen eigenen localhost ansprechen, nicht deinen VPS. Verwende von einem anderen Computer die normale Social-Stream-Fernsteuerung.

Der mitgelieferte Adapter ist ab SSApp 0.4.7 verfügbar; Version 0.4.14 und neuer melden den vollständigen Werkzeugsatz bereits, bevor die App verfügbar ist. Die aktuellen Fähigkeiten entscheiden weiterhin, welche Aufrufe funktionieren. Eine separate Node-Installation ist nicht erforderlich. Die Headless-Ozone-Option hier gilt nur für den MCP-Adapter; behalte Xvfb für die Haupt-App.

Versuche: „Rufe ssapp_get_capabilities auf, dann ssapp_get_status und ssapp_list_sources. Sage mir, welche Quellen erfassen und ob eine davon Fehler meldet.“ Die Werkzeuge umfassen außerdem Start/Stopp von Quellen, Diagnose, erfasste Ereignisse, Screenshots und genehmigte Interaktionen mit App-Fenstern. Private Anmeldungen und CAPTCHA benötigen weiterhin einen Menschen.

Siehe Leitfaden zur lokalen Steuerungs-API und MCP für den optionalen Agent-Skill, Versionskompatibilität und weitere Steuerelemente.

Owncast, Rocket.Chat und hervorgehobene Nachrichten

Du kannst SSApp auf demselben VPS wie Owncast und Rocket.Chat ausführen, wenn genügend Ressourcen vorhanden sind. Die Installation von SSApp allein verbindet Rocket.Chat nicht und fügt keine Overlays in das Video ein.

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

In den für diesen Leitfaden geprüften Quellbäumen gibt es keinen integrierten Rocket.Chat-Connector. Eine separate Integration ist nötig, um diese Nachrichten in Social Stream zu bringen. Prüfe, dass Nachrichten das Dock erreichen, bevor du das Video-Overlay einrichtest.

Verwende die bei der Einrichtung kopierten Dock- und Featured-Overlay-URLs mit derselben Sitzung/demselben Passwort und Transport. Wähle im Dock eine erfasste Nachricht, um sie hervorzuheben. Dein Videosender auf dem Server benötigt Browserquellen-Rendering, um diese Seiten über das Video zu legen, bevor er den kombinierten Stream an Owncast sendet. Siehe Owncasts Sendeanleitung. SSApp ist nicht dieser Videosender.

Ein Overlay über einem eingebetteten Player auf deiner Website ist eine andere Möglichkeit: Es erscheint auf dieser Seite und ist nicht Teil des Videos, das andere Player oder Aufzeichnungen erhalten. Owncast dokumentiert Einbetten von Video und Chat.

Damit du deinen Heimcomputer ausschalten kannst, müssen Videoquelle, Sender, Chaterfassung und eine eventuelle Rocket.Chat-Integration unabhängig davon weiterlaufen. Plane Videorendering und -kodierung getrennt vom Arbeitsspeicher für SSApps Chaterfassung ein.

Gesamten Ablauf vor unbeaufsichtigtem Betrieb prüfen

1. Sende eine echte Nachricht in einem verbundenen Chat und prüfe, ob sie im Social-Stream-Dock ankommt.
2. Hebe diese Nachricht hervor und prüfe, ob sich das Featured-Overlay ändert. Prüfe bei Owncast auch das tatsächlich beim Zuschauer ankommende Video.
3. Trenne VNC und SSH und sende über mehrere Minuten weitere Nachrichten. Die Erfassung sollte fortgesetzt werden.
4. Führe sudo systemctl restart ssapp, und prüfe dann, ob dieselbe Sitzung und dieselben Quellen wieder vorhanden sind und automatisch aktivierte Quellen neue Nachrichten erhalten.
5. Starte den VPS während eines Wartungsfensters neu und wiederhole die Nachrichtenprüfung. Ein laufender Prozess oder eine erfolgreiche API-Antwort allein belegt nicht, dass die Chaterfassung funktioniert.

Verwende sudo systemctl status ssapp und sudo journalctl -u ssapp -n 100 --no-pager für Dienststatus und aktuelle Protokolle. Verwende zum gezielten Stoppen sudo systemctl stop ssapp.

Stoppe für Aktualisierungen den Dienst, sichere /var/lib/ssapp, ersetze die AppImage am selben Pfad und starte den Dienst erneut. Behalte die vorherige ausführbare Datei, bis die neue Version die Nachrichtenprüfungen bestanden hat.

Fehlerbehebung

Verwandte Leitfäden

• Lokale Server und Dienste erklärt
• Lokale Steuerungs-API und MCP
• Modi der eigenständigen App