# Konzept: Bot-Produktseite und Community-Hub trennen **Stand:** 31.07.2026 umgesetzt, seither aktiv — `bot.d4rkst3r.de` und `hub.d4rkst3r.de` laufen getrennt. Die Anleitung unten steht für den Fall, dass die Trennung neu aufgesetzt oder rückgängig gemacht werden soll. ## 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).