fete/Ideen.md

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)