D4rkst3randClaude Opus 5
2292dedeaa
Die Funktionsliste war eine einzige Tabelle mit 46 Zeilen — in der Reihenfolge, in der die Sachen entstanden sind, also in keiner. Jetzt ist sie nach denselben Bereichen sortiert wie das Panel: Inhalte, Community, Moderation, Server, dazu Plattform fuer alles, was keine Discord-Funktion ist. Wer im Panel etwas sucht, findet den Abschnitt in der README am selben Platz. Nachgetragen, was seither dazugekommen ist: AutoMod, Raid-Schutz, verknuepfte Rollen, native Umfragen, Statusseite, Herzschlag, Seiten-Editor, Englisch fuer die oeffentlichen Seiten. Und die Trennung in zwei Domains stand bisher gar nicht drin, obwohl sie das Erste ist, was man verstehen muss — sie steht jetzt ganz oben, mit einer Tabelle welche Seite was zeigt. Korrigiert: 35 Module waren es mal, es sind 39. 15 Config-Bereiche waren es mal, es sind 16. Die Seitentabelle fuehrte Hub-Seiten unter der Bot-Domain. Die Projektstruktur kannte die Haelfte der Dateien nicht. In der Ersteinrichtung fehlten die Rechte fuer AutoMod und Kanal-Anlegen sowie die zusaetzlichen OAuth-Redirects. Dazu ein Inhaltsverzeichnis, eine docs/README.md als Wegweiser, und in konzept-zwei-seiten.md steht nicht mehr "muss noch aktiviert werden" — es laeuft seit Ende Juli. Geprueft mit einem kleinen Skript: 11 Markdown-Dateien, keine toten Datei-Links, keine toten Anker, keine Tabelle mit falscher Spaltenzahl. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
210 lines
9.2 KiB
Markdown
210 lines
9.2 KiB
Markdown
# 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).
|