nitrix
80d79c3596
Spec, research, data model, API contract, implementation plan, and task breakdown for the public event detail page. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
82 lines
5.3 KiB
Markdown
82 lines
5.3 KiB
Markdown
# fete
|
|
|
|
## Grundsätze
|
|
* Soll als PWA im Browser laufen
|
|
* Damit es sich wie eine normale app anfühlt
|
|
* Soll ein kleiner Helfer sein, den man schnell mal nutzen kann
|
|
* Ich will es mir selbst hosten können
|
|
* Das schließt eigentlich schon AI features aus und das ist okay
|
|
* Privacy als first class citizen
|
|
* Schon das Produktdesign muss mit privacy im sinn entworfen werden
|
|
* Keine Registrierung, kein login notwendig (nur z.B. einen code, um den "raum" zu finden oder so)
|
|
* Alternativ könnten etwaige anfallende Daten auch im local storage gespeichert werden
|
|
|
|
## Die Idee
|
|
Eine alternative zu Facebook Event Gruppen oder Telegram Gruppen, in denen eine Veranstaltung bekanntgegeben wird und Teilnahmen bestätigt werden
|
|
|
|
### Zielbild
|
|
Person erstellt via App eine Veranstaltung und schickt seine Freunden irgendwie via Link eine Einladung. Freunde können zurückmelden, ob sie kommen oder nicht.
|
|
|
|
## Gedankensammlung
|
|
* So ne Art Landingpage zu jedem Event
|
|
* Ein Link pro Event, den man z.B. in ne WhatsApp-Gruppe werfen kann
|
|
* Was, wie, wann, wo?
|
|
* Irgendwie auch Designbar, sofern man das will
|
|
* RSVP: "Ich komme" (mit Name) / "Ich komme nicht" (optional mit Name)
|
|
* Wird serverseitig gespeichert + im LocalStorage gemerkt
|
|
* Duplikatschutz: Kein perfekter Schutz ohne Accounts, aber gegen versehentliche Doppeleinträge reicht Gerätebindung via LocalStorage
|
|
* Gegen malicious actors (Fake-Namen spammen etc.) kann man ohne Accounts wenig machen — akzeptables Risiko (vgl. spliit)
|
|
* "Veranstaltung merken/folgen": Rein lokal, kein Serverkontakt, kein Name nötig
|
|
* Löst das Multi-Geräte-Problem: Am Handy zugesagt, am Laptop einfach "Folgen" drücken
|
|
* Auch nützlich für Unentschlossene, die sich das Event erstmal merken wollen
|
|
* View für den Veranstalter:
|
|
* Updaten der Veranstaltung
|
|
* Einsicht angemeldete Gäste, kann bei Bedarf Einträge entfernen
|
|
* Featureideen:
|
|
* Link-Previews (OpenGraph Meta-Tags): Generische OG-Tags mit App-Branding (z.B. "fete — Du wurdest eingeladen") damit geteilte Links in WhatsApp/Signal/Telegram hübsch aussehen. Keine Event-Daten an Crawler aus Privacy-Gründen. → Eigene User Story.
|
|
* Kalender-Integration: .ics-Download + optional webcal:// für Live-Updates bei Änderungen
|
|
* Änderungen zum ursprünglichen Inhalt (z.b. geändertes datum/ort) werden iwi hervorgehoben
|
|
* Veranstalter kann Updatenachrichten im Event posten, pro Device wird via LocalStorage gemerkt was man schon gesehen hat (Badge/Hervorhebung für neue Updates)
|
|
* QR Code generieren (z.B. für Plakate/Flyer)
|
|
* Ablaufdatum als Pflichtfeld, nach dem alle gespeicherten Daten gelöscht werden
|
|
* Übersichtsliste im LocalStorage: Alle Events die man zugesagt oder gemerkt hat (vgl. spliit)
|
|
* Sicherheit/Missbrauchsschutz:
|
|
* Nicht-erratbare Event-Tokens (z.B. UUIDs)
|
|
* Event-Erstellung ist offen, kein Login/Passwort/Invite-Code nötig
|
|
* Max aktive Events als serverseitige Konfiguration (env variable)
|
|
* Honeypot-Felder in Formularen (verstecktes Feld das nur Bots ausfüllen → Anfrage ignorieren)
|
|
* Abgrenzungskriterien
|
|
* KEIN Chat
|
|
* KEIN Discovery Feature über die App: Ohne Zugangslink geht nichts
|
|
* KEINE Planung des Events! Also kein "wer macht/bringt was?", "was machen wir überhaupt?"
|
|
|
|
## Getroffene Designentscheidungen
|
|
|
|
Die folgenden Punkte wurden in Diskussionen bereits geklärt und sind verbindlich.
|
|
|
|
* RSVP-System:
|
|
* Ein Link pro Event (NICHT individuelle Einladungslinks pro Person — zu umständlich für den Veranstalter)
|
|
* Gäste geben beim RSVP einen Namen an, das reicht
|
|
* Duplikate durch versehentliche Mehrfachanmeldung: LocalStorage-Gerätebindung reicht als Schutz
|
|
* Bewusste Doppelanmeldung/Spam: Akzeptables Risiko, Veranstalter kann Einträge manuell löschen
|
|
* Geräte-Sync ohne Account ist nicht sauber lösbar und das ist okay
|
|
* Missbrauchsschutz:
|
|
* Rate Limiting: Bewusst rausgelassen — zu viel Infra-Overhead für den Scope
|
|
* Captcha: Bewusst rausgelassen — entweder Privacy-Problem (Google) oder hässlich
|
|
* Admin-Passwort/Invite-Code für Event-Erstellung: Bewusst rausgelassen — die App soll organisch weitergegeben werden können
|
|
* Erfahrungswert: Spliit-Instanz läuft auch komplett offen ohne nennenswerte Probleme
|
|
* Stattdessen pragmatische Maßnahmen: Nicht-erratbare Tokens, Ablaufdatum als Pflichtfeld, Max Events per Konfiguration, Honeypot-Felder
|
|
* Zielgruppe:
|
|
* Primär Freundeskreise, nicht die breite Öffentlichkeit
|
|
* Trotzdem: Die App hängt im Internet, also muss man grundlegende Absicherung haben
|
|
* Architektur (bereits entschieden):
|
|
* SPA + RESTful API Backend, kein SSR
|
|
* Datenbank: PostgreSQL, wird separat gehostet (nicht im App-Container — der Hoster betreibt seinen eigenen Postgres)
|
|
* Organizer-Authentifizierung: Zwei separate UUIDs pro Event — ein öffentliches Event-Token (in der URL, für Gäste) und ein geheimes Organizer-Token (in localStorage, für Verwaltung). Interne DB-ID ist ein Implementierungsdetail.
|
|
* App wird als einzelner Docker-Container ausgeliefert, verbindet sich per Konfiguration (env variable) mit der externen Postgres-Instanz
|
|
* Techstack:
|
|
* Backend: Java (neuste LTS Version), Spring Boot, Maven, Hexagonal/Onion Architecture
|
|
* Frontend: Vue 3 (mit Vite als Bundler, TypeScript, Vue Router)
|
|
* Architekturentscheidungen die NOCH NICHT getroffen wurden (hier darf nichts eigenmächtig entschieden werden!):
|
|
* (derzeit keine offenen Architekturentscheidungen)
|