# 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:
	* 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)