d4rkbot/docs/konzept-zwei-seiten.md

Konzept: Bot-Produktseite und Community-Hub trennen

Stand: 31.07.2026 · Umgesetzt. Zum Aktivieren müssen nur noch die beiden Adressen in der Config eingetragen werden (System → Zwei Seiten).

Aktivieren

1. Config → System → Zwei Seiten ausfüllen:
   • Community-Hub: https://hub.d4rkst3r.de
   • Bot-Produktseite: https://bot.d4rkst3r.de
   • Login-Domain: .d4rkst3r.de (damit die Anmeldung auf beiden gilt)
2. Discord-Portal: unter OAuth2 → Redirects zusätzlich https://hub.d4rkst3r.de/auth/callback eintragen
3. Fertig — ab dem Speichern greift die Trennung sofort.

Solange die Felder leer bleiben, verhält sich alles wie vorher. Das Umschalten ist jederzeit reversibel: Felder leeren, und beide Domains zeigen wieder dieselbe Seite.

---

Warum

Heute liegt alles auf bot.d4rkst3r.de: Devlogs, Roadmap, Galerie, Level, Events, Member-Profile — und die Bot-Einstellungen. Die Adresse führt in die Irre. Wer bot. liest, erwartet eine Bot-Dokumentation und klickt vielleicht gar nicht erst, obwohl dahinter der Community-Hub steckt.

Vorbild sind MEE6 und Carl-bot: eine Produktseite erklärt den Bot und bietet das Dashboard — die Community-Inhalte leben woanders.

Aufteilung

bot.d4rkst3r.de — Produktseite

Zielgruppe: Leute, die wissen wollen, was der Bot kann, und du selbst zum Konfigurieren.

Route	Inhalt
/	Landing: „Das kann der Bot" — Hero, Feature-Kacheln, Einladen-Button
/features	Alle Funktionen ausführlich, gruppiert — die Liste kommt aus /api/features und damit aus dem Modul-Register, kann also nicht veralten
/commands	Slash-Command-Referenz, aus dem Code erzeugt
/docs	Kurzanleitungen: API v1, SSO, Webhooks, Design-System
/dashboard	die heutige Config-Seite (Login + Berechtigung nötig)
/impressum, /datenschutz	Rechtstexte (auf beiden Domains identisch)

Die 16 Slash-Commands, die es aktuell gibt: ping, bug, wunsch, geburtstag, giveaway, rank, remind, tag, warn, warns, timeout, purge, devlog-backfill, galerie-backfill, playtester-setup, ticket-setup.

hub.d4rkst3r.de — Community

Zielgruppe: Member und Interessierte.

Route	Inhalt
/	Startseite mit Live-Zahlen, Bereichs-Kacheln, neuestem Devlog
/devlogs, /devlogs/:id	Archiv mit Volltextsuche und Permalinks
/roadmap	Meilensteine, Community-Wünsche, Heatmap
/server	Live-Status der Game-Server
/galerie	Community-Screenshots
/level	XP-Bestenliste und Aktivitäts-Chart
/events	Discord-Events
/changelog	Releases
/profil	eigenes Profil, Rollen-Selfservice, Datenlöschung
/commits	Commit-Archiv (nur Owner)
/:slug	frei angelegte Seiten — Regeln, Über uns, Mitmachen, FAQ
/feed.xml	RSS

Seiten-Editor

Aus der Community kam der Wunsch nach einem CMS im Stil von Burning Board. Ein Forum neben einem aktiven Discord würde erfahrungsgemäß nach wenigen Wochen verwaisen — und ein totes Forum wirkt schlechter als keins. Dazu käme Moderationsaufwand und Verantwortung für fremde Inhalte.

Der berechtigte Kern des Wunsches ist ein anderer: Inhalte pflegen können, ohne dass jemand Code anfassen muss. Heute lässt sich auf der Seite keine Zeile ändern, ohne dass ein Commit nötig wird.

Deshalb ein schlanker Seiten-Editor statt eines Forums:

• Seiten werden in der Config angelegt: Titel, Adress-Kürzel, Inhalt in Markdown
• Live-Vorschau wie im Composer, gerendert mit dem vorhandenen Markdown-Parser
• pro Seite wählbar: veröffentlicht oder Entwurf, im Menü sichtbar oder nur über den Direktlink erreichbar, Reihenfolge im Menü
• die Rechtstexte bleiben davon unberührt — die haben ihre eigene Logik

Datenmodell: eine Tabelle pages (slug, title, content, published, in_menu, sort). Öffentlich lesbar sind nur veröffentlichte Seiten; bearbeiten darf, wer den content-Bereich hat.

Ein Repo oder zwei?

Naheliegend wäre, für den Hub ein eigenes Repository anzulegen. Davon rate ich ab — nicht aus Bequemlichkeit, sondern weil die Community-Seite ohne den laufenden Bot gar nicht funktioniert:

• /api/profile holt Rollen und Beitrittsdatum live über guild.members.fetch()
• /api/myroles/toggle vergibt Discord-Rollen über den Client
• POST /api/wishes postet den Wunsch als Embed in den Voting-Kanal
• /api/servers liest die letzten Monitor-Ergebnisse aus dem Arbeitsspeicher des Bot-Prozesses
• Devlogs, Level, Galerie, Commits und Events kommen direkt aus der SQLite-Datei, die der Bot schreibt

Insgesamt greift die Web-API an 33 Stellen auf den laufenden Discord-Client zu. Bei getrennten Repos müsste all das über HTTP laufen: Der Hub bräuchte für jede dieser Stellen einen API-Endpunkt beim Bot, dazu Authentifizierung, Fehlerbehandlung und Zeitüberschreitungen. Die Alternative — beide Anwendungen schreiben dieselbe SQLite-Datei — funktioniert nur auf demselben Host und ist bei gleichzeitigen Schreibzugriffen fehleranfällig.

Das hieße: deutlich mehr Code, zwei Deployments, zwei Update-Zyklen — für einen Betreiber, der alles allein pflegt.

Vorschlag stattdessen: ein Repository, aber sauber getrennte Ordner.

src/                 Bot, API, Datenbank  (unverändert)
frontend/
  shared/            Design-System, Icons, gemeinsame Komponenten
  hub/               Community-Seite       → eigener Build
  bot/               Produktseite          → eigener Build

Zwei getrennte Builds, ein Server liefert je nach Domain den passenden aus. Das gibt die gewünschte Klarheit — jede Seite hat ihren eigenen Ordner und ihr eigenes Bundle — ohne die Kosten einer echten Trennung. Und falls du den Hub später doch herauslösen willst, ist die Grenze dann schon gezogen.

Technischer Ansatz

Eine Anwendung, zwei Gesichter. Ein Container, eine Datenbank. Der Server erkennt am Host-Header, welche Seite gefragt ist:

• Backend (src/web/server.js): liefert je nach Host die passenden Open-Graph-Tags aus. Die Injektion dafür gibt es schon, sie bekommt nur eine Fallunterscheidung.
• Frontend: zwei Builds aus frontend/hub/ und frontend/bot/, die sich Design-System und Komponenten aus frontend/shared/ teilen. Der Server liefert je nach Domain das passende index.html aus.
• API bleibt unverändert und für beide Domains erreichbar.

Alte Links auffangen

Geteilte Devlog-Permalinks zeigen heute auf bot.d4rkst3r.de/devlogs/…. Diese Adressen dürfen nicht ins Leere laufen: Ruft jemand eine Community-Route auf der Bot-Domain auf, antwortet der Server mit einer dauerhaften Weiterleitung (301) auf dieselbe Route unter hub.. Umgekehrt ebenso für /dashboard.

Login über beide Domains

Damit man sich nur einmal anmeldet, wird das Sitzungs-Cookie künftig für .d4rkst3r.de gesetzt statt nur für bot.. Dann gilt es auf beiden Subdomains.

Was das bedeutet: Das Cookie wird technisch auch an git. und cdn. mitgesendet. Die ignorieren es, aber es verlässt damit die eine Anwendung. Vertretbar ist das, weil es signiert und für JavaScript unlesbar ist (httpOnly) — mitlesen könnte es nur, wer bereits Serverzugriff auf einer Subdomain hat. Umgesetzt wird es als Einstellung, damit es sich zurückdrehen lässt.

Neue Einstellungen

Heute gibt es genau eine „Öffentliche URL". Nach der Trennung braucht es zwei:

Einstellung	Zweck
hub_url	Community-Adresse — speist Devlog-Buttons, RSS, Open-Graph-Bilder, brand-nav.js
bot_url	Produktseite — Ziel für Dashboard-Links und OAuth-Rücksprung

Alles, was heute publicUrl() benutzt, wird auf hubUrl() umgestellt; nur die Login-Umleitung und Dashboard-Verweise nutzen botUrl().

Was zu tun ist

1. Kanban von hub. entfernen — dort läuft noch das alte Board.
2. Proxy: hub.d4rkst3r.de auf denselben Container zeigen lassen wie bot.
3. Discord-Portal: Redirect-URI für beide Domains eintragen
4. Frontend in shared/, hub/ und bot/ aufteilen, zwei Builds einrichten
5. Host-Routing in Backend und Frontend (siehe oben)
6. Bot-Landing, Feature- und Command-Seite bauen
7. Config-Seite nach /dashboard umhängen
8. Weiterleitungen für alte Links
9. Cookie-Domain umstellen
10. hub_url/bot_url in den Einstellungen ergänzen und alle Verwendungen umziehen

Schritte 1–3 machst du, 4–10 übernehme ich. Aufwand geschätzt: Schritt 4 und 5 sind der größte Block (Umbau der Ordnerstruktur), 6 ist reine Neuentwicklung, der Rest sind Kleinigkeiten.

Entschieden

• Kein „Einladen"-Button. Der Bot ist auf einen Discord-Server ausgelegt; ihn mandantenfähig zu machen wäre ein eigenes Projekt. Die Produktseite ist vorerst Visitenkarte und Dashboard. Später möglich, dann aber bewusst geplant.
• /commits gehört auf den Hub — es ist Projekt-Entwicklung, keine Bot-Verwaltung.
• Die Bot-Seite bekommt Orange als Leitfarbe (--neon2) statt Gelb. Gleiche Schriften, gleiche Flächen, gleiche Bausteine — nur der Akzent wechselt. So merkt man beim Domainwechsel sofort, dass man woanders ist, ohne dass es nach zwei verschiedenen Marken aussieht.
• Kein Forum, stattdessen ein Seiten-Editor (siehe oben).