D4rkst3randClaude Fable 5
a32c267dda
/features zeigte bisher dieselbe Landing wie /, obwohl die Navigation und ein Knopf auf der Startseite eine echte Funktionsliste versprachen. Die Seite listet jetzt alle 35 Bot-Funktionen, nach denselben Gruppen sortiert wie im Panel, dazu sechs Punkte zum Drumherum (Webinterface, Texte, API/SSO, eigene Seiten, Team-Rechte, Betrieb). Die Einträge kommen über das neue öffentliche /api/features aus src/modules.js — derselben Quelle, aus der die Modul-Schalter kommen. Eine neue Funktion erscheint damit automatisch auf der Produktseite, statt dass jemand daran denken muss. Der Endpunkt gibt bewusst nur Name, Beschreibung und Gruppe heraus, nicht welche Module hier gerade laufen. Auch die Zahl auf der Startseite kommt von dort, damit nicht zwei Stellen dieselbe Zahl pflegen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
209 lines
9.1 KiB
Markdown
209 lines
9.1 KiB
Markdown
# 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).
|