d4rkbot/docs/konzept-zwei-seiten.md

Konzept: Bot-Produktseite und Community-Hub trennen

Stand: 31.07.2026 · Entwurf zur Abstimmung, noch nichts umgesetzt.

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 (Community, Moderation, Feeds, Server)
/commands	Slash-Command-Referenz, aus dem Code erzeugt
/docs	Kurzanleitungen: API v1, SSO, Webhooks, Design-System
/dashboard	die heutige Setup-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)
/feed.xml	RSS

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. Setup-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.

Offene Fragen

• Soll die Bot-Seite den Bot zum Einladen anbieten? Ein „Auf deinen Server einladen"-Button hieße, dass Fremde den Bot nutzen können. Dafür müsste er mit mehreren Servern umgehen — aktuell ist er auf einen ausgelegt. Ohne Button wird die Seite zur Visitenkarte („so ist er gebaut"), was für ein Portfolio auch Sinn ergibt.
• Gehört /commits auf den Hub oder auf die Bot-Seite? Vorschlag: Hub, es gehört zur Projekt-Entwicklung.
• Braucht die Bot-Seite eine eigene Farbnote, um sich vom Hub abzuheben — oder bleibt beides identisch gebrandet?