diff --git a/docs/konzept-zwei-seiten.md b/docs/konzept-zwei-seiten.md new file mode 100644 index 0000000..2d2dc40 --- /dev/null +++ b/docs/konzept-zwei-seiten.md @@ -0,0 +1,165 @@ +# 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?