Hilfe zum Online-Portal & Live-Signaling

1. Öffentliche Ansicht vs. verifizierte Nutzer

Das Online-Portal kennt zwei Zustände:

• Öffentliche Ansicht („public-view“): Standard, wenn du die Seite direkt im Browser öffnest.
• Verifizierte Ansicht: Wird aktiv, wenn du aus dem Offline-Manifest über „Portal öffnen (verifiziert)“ kommst oder manuell einen gültigen Token einträgst.

Die Verifikation läuft über einen Hash in der URL:

#mot=DEIN-TOKEN&ts=ZEITSTEMPEL&sig=HMAC-SIGNATUR

Das Portal prüft:

• Ist der Zeitstempel frisch (z. B. maximal 5 Minuten alt)?
• Stimmt die Signatur mit dem erwarteten HMAC über token + "." + ts überein?

Erst dann wird der Zustand „verifiziert“ aktiviert und Live-Funktionen können freigeschaltet werden.

2. Daten laden: JSON & API

Rechts im Portal findest du den Block „Daten laden“ mit:

• JSON importieren – lädt eine manifest-forum.json direkt in das Portal.
• Payload anzeigen – zeigt die aktuell geladenen Daten als JSON an.
• API URL (https://deine-seite.tld/api/manifest/list) – hier kannst du eine eigene API angeben, die eine Liste von Beiträgen zurückliefert.
• Von API laden – ruft diese URL auf (GET, JSON erwartet) und rendert die Beiträge im Feed.
• Feed leeren – setzt die Ansicht zurück.

Die API-Struktur sollte kompatibel sein mit der JSON-Struktur des Offline-Manifestes (also ein Objekt mit posts-Array oder direkt ein passendes Objekt).

3. Live-Funktionen & Signaling-Server (WSS)

Der Abschnitt „Live-Funktionen (für verifizierte Nutzer)“ listet mögliche Echtzeitfunktionen:

• Video-Chat Räume
• Text-Chat
• Datei-Transfer mit Freigabe
• Signierte Kontrakte

Technisch brauchst du dafür einen Signaling-Server, der über eine wss://-Adresse erreichbar ist. Im Portal gibt es dafür das Feld Signaling URL (wss://...) und den Button Live initialisieren.

Beispiele für Signaling-Optionen:

• Eigenes WebSocket-Backend:
  • Node.js mit ws oder socket.io.
  • WSS-Endpunkt, z. B. wss://signaling.deine-seite.tld.
  • Nachrichtenformat kannst du frei definieren (z. B. JSON mit Raum-ID, Nutzertyp, Offer/Answer).
• RTC-Plattformen (Beispiele, extern):
  • Twilio Programmable Video.
  • Ably Realtime.
  • Pusher Channels.
  • Selbst gehostete Lösungen wie Matrix + Bridges.

Beispiel-Konfiguration (vereinfacht):\n Signaling URL: wss://signaling.deine-seite.tld\n Raum-ID: wird aus dem Manifest (z.B. Post-ID) abgeleitet\n Nachrichtenformat: { type: "offer" | "answer" | "candidate", roomId, payload }

Wichtig: Die aktuelle Demoversion zeigt beim Initialisieren nur einen Hinweis-Dialog. Die eigentliche WebRTC-/Chat-Logik musst du serverseitig und ggf. clientseitig ergänzen.

4. TDL / Raum-Definitionen – wie strukturiere ich meine Live-Räume?

Viele Systeme benutzen eine Art Task / Room Definition Language (TDL) – also Regeln, wie ein Raum oder eine Aufgabe beschrieben wird. Für dieses Portal kannst du dir z. B. folgendes Vorgehen merken:

• Raum-Typ: Text, Video, Datei, Vertrag.
• Raum-ID: z. B. post-{ID} aus dem Manifest oder eine Waben-ID aus den Wabenräumen.
• Rollen: Initiator, Gast, Beobachter.
• Rechte: Wer darf senden, wer darf unterschreiben, wer darf nur lesen?

Beispiel-JSON für eine Raumdefinition:\n {\n \t"type": "contract-signing",\n \t"roomId": "post-12345",\n \t"participants": [\n \t\t{"role":"initiator","id":"userA"},\n \t\t{"role":"signer","id":"userB"}\n \t],\n \t"permissions": {\n \t\t"uploadSignedPdf": ["initiator","signer"],\n \t\t"chat": ["initiator","signer"],\n \t\t"viewOnly": ["observer"]\n \t}\n }

Solche Strukturen können vom Signaling-Server ausgewertet werden, um zu entscheiden, welche Benutzer was tun dürfen. Die App selbst ist dafür vorbereitet, aber die konkrete Logik musst du in deinem Backend implementieren.

5. Woher bekomme ich die benötigten Backend-Bausteine?

Du brauchst drei Komponenten:

• API für Daten (Manifest, Feeds):
  • Eigener REST-Server (Node, Python, PHP, Go, …).
  • Oder Managed-Backends wie Supabase, Firebase, etc.
• Signaling-Server (WSS):
  • Eigener Node.js-WebSocket-Server.
  • Oder Realtime-Plattformen wie Twilio, Ably, Pusher.
• Speicher für Dateien & signierte Dokumente:
  • Objektspeicher (z. B. S3-kompatibel, MinIO, Backblaze B2).
  • Oder klassische Web-Storage-Systeme mit Zugriffsschutz.

Die App selbst zwingt dich zu nichts davon – sie gibt dir nur die Felder (API-URL, Signaling-URL), in die du deine eigene Infrastruktur einträgst.

6. Kurzfassung für Nicht-Techniker:innen

• Nutze das Online-Portal zum Ansehen deiner Manifest-Beiträge – per JSON-Import oder API.
• Für Echtzeitfunktionen (Chat, Video, Datei, Verträge) brauchst du oder dein Team einen eigenen Signaling-Server und ggf. einen Juristen/Administrator.
• Trage die bereitgestellten URLs (API & WSS) einfach in die Felder im Portal ein.
• Teste alles zuerst mit Testdaten, bevor du echte, sensible Inhalte überträgst.