439 lines
18 KiB
Markdown
439 lines
18 KiB
Markdown
# Killer-Features — kashilo.com
|
||
|
||
Differenzierung gegenüber eBay Kleinanzeigen, Tutti, XMRBazaar.
|
||
Drei Features, die kein Konkurrent hat.
|
||
|
||
Status: **Planung** (noch nicht implementiert)
|
||
|
||
---
|
||
|
||
## 1. Blind Meeting Points
|
||
|
||
**Problem:** Bei lokalen Deals muss eine Seite ihre Adresse preisgeben. Privacy-bewusste User vermeiden das — oder treffen sich an zufälligen, unsicheren Orten.
|
||
|
||
**Lösung:** Beide Parteien geben einen ungefähren Radius an (z.B. "Zürich HB ± 1 km"). Die App berechnet einen **öffentlichen, neutralen Treffpunkt** im Überschneidungsbereich (Bahnhof, Einkaufszentrum, Café). Keine Seite gibt ihre echte Adresse preis.
|
||
|
||
### Datenquelle
|
||
|
||
- **OpenStreetMap Overpass API** (kostenlos, kein API-Key)
|
||
- Query: POIs mit Tags wie `amenity=cafe`, `shop=mall`, `railway=station` im Überschneidungskreis
|
||
- Fallback: Mittelpunkt der beiden Radien als generischer Treffpunkt
|
||
|
||
### Algorithmus
|
||
|
||
```
|
||
1. Seller setzt Punkt A + Radius rA (z.B. 1 km)
|
||
2. Buyer setzt Punkt B + Radius rB (z.B. 1.5 km)
|
||
3. Berechne Überschneidungsfläche der beiden Kreise
|
||
4. Falls keine Überschneidung: Mittelpunkt A↔B vorschlagen, Radien vergrößern
|
||
5. Query Overpass API für geeignete POIs in der Überschnittfläche
|
||
6. Filtere nach Kategorien (priorisiert):
|
||
a. Bahnhöfe / ÖV-Haltestellen (öffentlich, belebt)
|
||
b. Einkaufszentren (überdacht, sicher)
|
||
c. Cafés / Restaurants (neutral)
|
||
d. Parks / Plätze (Fallback)
|
||
7. Wähle den POI, der am nächsten zum Mittelpunkt liegt
|
||
8. Zeige Kartenausschnitt (Leaflet + OSM-Tiles) mit dem Treffpunkt
|
||
```
|
||
|
||
### UX-Flow
|
||
|
||
```
|
||
Chat-Widget:
|
||
┌─────────────────────────────────────┐
|
||
│ 💬 Chat mit Käufer │
|
||
│ │
|
||
│ ... Nachrichten ... │
|
||
│ │
|
||
│ ┌─────────────────────────────┐ │
|
||
│ │ 📍 Treffpunkt vorschlagen │ │
|
||
│ └─────────────────────────────┘ │
|
||
│ │
|
||
│ → Klick öffnet Modal: │
|
||
│ ┌─────────────────────────────┐ │
|
||
│ │ 🗺 Karte (Leaflet/OSM) │ │
|
||
│ │ │ │
|
||
│ │ [Pin auf Karte setzen] │ │
|
||
│ │ Radius: [====●===] 1 km │ │
|
||
│ │ │ │
|
||
│ │ [Treffpunkt berechnen] │ │
|
||
│ └─────────────────────────────┘ │
|
||
│ │
|
||
│ Ergebnis wird als Chat-Nachricht │
|
||
│ gesendet (E2E verschlüsselt): │
|
||
│ ┌─────────────────────────────┐ │
|
||
│ │ 📍 Vorschlag: Zürich HB │ │
|
||
│ │ Bahnhofstrasse 1 │ │
|
||
│ │ [Auf Karte anzeigen] │ │
|
||
│ └─────────────────────────────┘ │
|
||
└─────────────────────────────────────┘
|
||
```
|
||
|
||
### Technische Umsetzung
|
||
|
||
| Komponente | Datei | Beschreibung |
|
||
|------------|-------|--------------|
|
||
| Service | `js/services/meeting-points.js` | Geo-Berechnung, Overpass-API-Query, POI-Filterung |
|
||
| Component | `js/components/meeting-point-modal.js` | Karte (Leaflet), Radius-Slider, Ergebnis-Anzeige |
|
||
| Integration | `js/components/chat-widget.js` | Button "Treffpunkt vorschlagen", Ergebnis als Nachricht |
|
||
| CSS | `css/components.css` | Karten-Styles, Modal-Styles |
|
||
| Vendor | `js/vendor/leaflet/` | Leaflet.js (self-hosted, ~40 KB gzip) |
|
||
|
||
### Overpass API Query (Beispiel)
|
||
|
||
```
|
||
[out:json][timeout:10];
|
||
(
|
||
node["railway"="station"](around:500,47.3769,8.5417);
|
||
node["amenity"="cafe"](around:500,47.3769,8.5417);
|
||
node["shop"="mall"](around:500,47.3769,8.5417);
|
||
);
|
||
out center 5;
|
||
```
|
||
|
||
### Privacy-Aspekte
|
||
|
||
- **Kein serverseitiger Standort**: Berechnung komplett im Browser (Client-Side)
|
||
- **Overpass-Query**: Geht direkt an OSM-Server (kein Proxy nötig, keine Logs bei uns)
|
||
- **Treffpunkt im Chat**: E2E verschlüsselt, Server sieht nur Ciphertext
|
||
- **Kein GPS nötig**: User setzt Pin manuell auf der Karte
|
||
- Seller-Standort ≠ Treffpunkt (Treffpunkt ist immer ein öffentlicher Ort)
|
||
|
||
### i18n Keys
|
||
|
||
```
|
||
meeting.suggest = "Treffpunkt vorschlagen"
|
||
meeting.setLocation = "Deinen ungefähren Standort wählen"
|
||
meeting.radius = "Radius"
|
||
meeting.calculate = "Treffpunkt berechnen"
|
||
meeting.result = "Vorgeschlagener Treffpunkt"
|
||
meeting.noOverlap = "Kein gemeinsamer Bereich — Mittelpunkt wird vorgeschlagen"
|
||
meeting.noPoi = "Kein öffentlicher Ort gefunden — Punkt auf der Karte"
|
||
meeting.send = "Im Chat senden"
|
||
meeting.showMap = "Auf Karte anzeigen"
|
||
meeting.types.station = "Bahnhof"
|
||
meeting.types.mall = "Einkaufszentrum"
|
||
meeting.types.cafe = "Café"
|
||
meeting.types.park = "Park / Platz"
|
||
```
|
||
|
||
### Aufwand
|
||
|
||
- **Geschätzt**: 2–3 Tage
|
||
- **Dependencies**: Leaflet.js (self-hosted), Overpass API (kostenlos)
|
||
- **Risiko**: Overpass API Rate-Limits (Fallback: Mittelpunkt ohne POI-Suche)
|
||
|
||
---
|
||
|
||
## 2. Verifiable Listings (Proof of Possession)
|
||
|
||
**Problem:** Auf anonymen Marktplätzen ist Scam ein Hauptproblem. Seller können Bilder aus dem Internet nehmen und Artikel listen, die sie nicht besitzen. Ohne KYC gibt es keine Konsequenzen.
|
||
|
||
**Lösung:** Seller können optional ein Foto hochladen, auf dem ein von der App generierter **Einmal-Verifizierungscode** sichtbar ist (auf Zettel, Display, etc.). Das beweist: "Dieser Artikel war zum Zeitpunkt X physisch vorhanden."
|
||
|
||
### Verfahren
|
||
|
||
```
|
||
1. Seller klickt "Besitz verifizieren" beim Listing erstellen/bearbeiten
|
||
2. App generiert einen 6-stelligen Code + QR-Code + Zeitstempel
|
||
- Code: kryptografisch zufällig (crypto.getRandomValues)
|
||
- Gültig: 10 Minuten (danach neuer Code)
|
||
3. Seller fotografiert den Artikel MIT dem Code (auf Zettel, Handy-Display daneben, etc.)
|
||
4. Foto wird hochgeladen als spezielles Verifikations-Bild
|
||
5. App speichert: Code + Zeitstempel + Foto-ID als Verifikationsnachweis
|
||
6. Listing zeigt Badge: "✓ Besitz verifiziert am [Datum]"
|
||
```
|
||
|
||
### Verifikations-Sicherheit
|
||
|
||
| Aspekt | Lösung |
|
||
|--------|--------|
|
||
| Fake-Code auf echtem Bild | Code ist nur 10 Min gültig, Zeitfenster wird angezeigt |
|
||
| Photoshop / Bildbearbeitung | EXIF-Metadaten prüfen (optional), Hash des Originalbilds speichern |
|
||
| Fremdes Foto mit Code | Nicht 100% verhinderbar, aber Aufwand steigt deutlich |
|
||
| Wiederverwendung | Code ist einmalig, an Listing-ID gebunden |
|
||
|
||
**Wichtig:** Das ist kein perfekter Beweis, sondern ein **Vertrauenssignal**. Es erhöht den Aufwand für Scammer signifikant.
|
||
|
||
### Datenmodell (Directus)
|
||
|
||
Neues Feld auf `listings`:
|
||
|
||
| Feld | Typ | Beschreibung |
|
||
|------|-----|--------------|
|
||
| `verification_code` | String (6) | Der generierte Code |
|
||
| `verification_image` | UUID, FK → directus_files | Das Verifikationsfoto |
|
||
| `verification_date` | DateTime | Zeitpunkt der Verifikation |
|
||
| `verified` | Boolean | `true` wenn Verifikation abgeschlossen |
|
||
|
||
### UX-Flow
|
||
|
||
```
|
||
Listing erstellen / bearbeiten:
|
||
┌─────────────────────────────────────┐
|
||
│ 📷 Bilder hochladen │
|
||
│ [Bild 1] [Bild 2] [+] │
|
||
│ │
|
||
│ ───────────────────────────── │
|
||
│ │
|
||
│ ✓ Besitz verifizieren (optional) │
|
||
│ │
|
||
│ → Klick öffnet Verifikation: │
|
||
│ ┌─────────────────────────────┐ │
|
||
│ │ │ │
|
||
│ │ Dein Code: 4 8 2 7 1 5 │ │
|
||
│ │ Gültig noch: 08:42 │ │
|
||
│ │ │ │
|
||
│ │ Schreibe diesen Code auf │ │
|
||
│ │ einen Zettel und fotografiere│ │
|
||
│ │ deinen Artikel zusammen │ │
|
||
│ │ mit dem Code. │ │
|
||
│ │ │ │
|
||
│ │ [📷 Verifikationsfoto │ │
|
||
│ │ hochladen] │ │
|
||
│ │ │ │
|
||
│ └─────────────────────────────┘ │
|
||
│ │
|
||
│ Nach Upload: │
|
||
│ ✅ Besitz verifiziert │
|
||
└─────────────────────────────────────┘
|
||
|
||
Auf dem Listing (für Käufer):
|
||
┌──────────────────────┐
|
||
│ 📷 Bild │
|
||
│ Titel der Anzeige │
|
||
│ 50.00 EUR │
|
||
│ ✓ Besitz verifiziert│ ← Badge
|
||
│ 📍 Zürich 🟢 10+ │
|
||
└──────────────────────┘
|
||
```
|
||
|
||
### Technische Umsetzung
|
||
|
||
| Komponente | Datei | Beschreibung |
|
||
|------------|-------|--------------|
|
||
| Service | `js/services/verification.js` | Code-Generierung, Validierung, Directus CRUD |
|
||
| Component | `js/components/verification-widget.js` | Code-Anzeige, Countdown, Upload |
|
||
| Integration | `js/components/pages/page-create.js` | Einbettung in Listing-Formular |
|
||
| Integration | `js/components/pages/page-listing.js` | Badge-Anzeige für Käufer |
|
||
| CSS | `css/components.css` | Badge-Styles, Verifikations-Widget |
|
||
|
||
### Privacy-Aspekte
|
||
|
||
- **Freiwillig**: Keine Pflicht, reines Opt-in
|
||
- **Kein KYC**: Code beweist Besitz, nicht Identität
|
||
- **Foto-Metadaten**: EXIF wird beim Upload gestrippt (wie bei normalen Listing-Bildern)
|
||
- **Code serverseitig**: Nur der Hash des Codes wird gespeichert (nicht der Klartext)
|
||
|
||
### i18n Keys
|
||
|
||
```
|
||
verification.verify = "Besitz verifizieren"
|
||
verification.optional = "Optional — erhöht das Vertrauen"
|
||
verification.code = "Dein Code"
|
||
verification.validFor = "Gültig noch"
|
||
verification.instructions = "Schreibe diesen Code auf einen Zettel und fotografiere deinen Artikel zusammen mit dem Code."
|
||
verification.upload = "Verifikationsfoto hochladen"
|
||
verification.verified = "Besitz verifiziert"
|
||
verification.verifiedDate = "Verifiziert am {{date}}"
|
||
verification.expired = "Code abgelaufen — neuen generieren"
|
||
verification.badge = "✓ Verifiziert"
|
||
```
|
||
|
||
### Aufwand
|
||
|
||
- **Geschätzt**: 1–2 Tage
|
||
- **Dependencies**: Keine neuen (Directus File-Upload existiert bereits)
|
||
- **Risiko**: Gering — Feature ist optional und unabhängig
|
||
|
||
---
|
||
|
||
## 3. Selbstzerstörende Listings
|
||
|
||
**Problem:** Auf klassischen Plattformen bleiben Anzeigen und Nutzerspuren ewig gespeichert. Archivierte Listings sind oft noch über Suchmaschinen auffindbar. Für Privacy-bewusste User ist das ein Dealbreaker.
|
||
|
||
**Lösung:** Seller können ein Listing als **selbstzerstörend** markieren. Nach Ablauf oder Deal-Abschluss werden alle Daten (Bilder, Beschreibung, Verifikation) **unwiderruflich gelöscht** — nicht archiviert.
|
||
|
||
### Modi
|
||
|
||
| Modus | Trigger | Effekt |
|
||
|-------|---------|--------|
|
||
| **Zeitbasiert** | Seller wählt Lebensdauer: 24h, 48h, 7 Tage, 30 Tage | Listing + Bilder werden nach Ablauf gelöscht |
|
||
| **Deal-basiert** | Deal wird beidseitig bestätigt | Listing wird X Stunden nach Deal-Bestätigung gelöscht |
|
||
| **Manuell** | Seller klickt "Jetzt zerstören" | Sofortige Löschung |
|
||
|
||
**Standard-Listings** (ohne Selbstzerstörung) verhalten sich wie bisher: Archivierung nach 30 Tagen.
|
||
|
||
### Löschung — was wird gelöscht?
|
||
|
||
```
|
||
1. Listing-Datensatz (Directus: items.delete)
|
||
2. Alle verknüpften Bilder (Directus Files: files.delete)
|
||
3. Verifikationsfoto (falls vorhanden)
|
||
4. Junction-Table-Einträge (listings_files)
|
||
5. Conversations + Messages werden NICHT gelöscht
|
||
(die sind E2E verschlüsselt und gehören beiden Parteien)
|
||
```
|
||
|
||
### Datenmodell (Directus)
|
||
|
||
Neue Felder auf `listings`:
|
||
|
||
| Feld | Typ | Beschreibung |
|
||
|------|-----|--------------|
|
||
| `self_destruct` | Boolean | `true` wenn Selbstzerstörung aktiv |
|
||
| `destruct_mode` | String | `time`, `deal`, `manual` |
|
||
| `destruct_at` | DateTime | Zeitpunkt der geplanten Löschung |
|
||
| `destruct_after_deal_hours` | Integer | Stunden nach Deal-Bestätigung (Default: 24) |
|
||
|
||
### Implementierung: Löschung
|
||
|
||
**Option A: Directus Flow (empfohlen)**
|
||
- Neuer Scheduled Flow: alle 15 Minuten (wie Expired-Listings-Flow)
|
||
- Query: `self_destruct = true AND destruct_at <= NOW()`
|
||
- Action: Delete Listing + zugehörige Files
|
||
- Vorteil: Serverseitig, zuverlässig
|
||
|
||
**Option B: Frontend-Trigger (Fallback)**
|
||
- Bei App-Start prüfen: Gibt es eigene Listings mit `destruct_at` in der Vergangenheit?
|
||
- Falls ja: Delete-Request an Directus
|
||
- Nachteil: Funktioniert nur wenn Seller die App öffnet
|
||
|
||
**Empfehlung:** Option A als Primär, Option B als zusätzliche Absicherung.
|
||
|
||
### UX-Flow
|
||
|
||
```
|
||
Listing erstellen:
|
||
┌─────────────────────────────────────┐
|
||
│ Titel: [___________________] │
|
||
│ Preis: [___] Währung: [EUR ▼] │
|
||
│ ... │
|
||
│ │
|
||
│ ───────────────────────────── │
|
||
│ 🔥 Selbstzerstörung │
|
||
│ │
|
||
│ [●] Aus (Standard: Archivierung) │
|
||
│ [ ] Nach Zeitablauf │
|
||
│ → [24h ▼] / 48h / 7d / 30d │
|
||
│ [ ] Nach Deal-Abschluss │
|
||
│ → [24] Stunden danach │
|
||
│ │
|
||
│ ⚠ Achtung: Gelöschte Anzeigen │
|
||
│ können nicht wiederhergestellt │
|
||
│ werden. │
|
||
└─────────────────────────────────────┘
|
||
|
||
Auf dem Listing (für Käufer):
|
||
┌──────────────────────┐
|
||
│ 📷 Bild │
|
||
│ Titel der Anzeige │
|
||
│ 50.00 EUR │
|
||
│ 🔥 Läuft ab in 23h │ ← Countdown
|
||
│ 📍 Zürich │
|
||
└──────────────────────┘
|
||
|
||
Für Seller (eigenes Listing):
|
||
┌──────────────────────────────┐
|
||
│ 🔥 Selbstzerstörung aktiv │
|
||
│ Wird gelöscht am: 12.02.26 │
|
||
│ [Jetzt zerstören] │
|
||
└──────────────────────────────┘
|
||
```
|
||
|
||
### Technische Umsetzung
|
||
|
||
| Komponente | Datei | Beschreibung |
|
||
|------------|-------|--------------|
|
||
| Service | `js/services/self-destruct.js` | Countdown-Berechnung, Delete-Requests, Deal-Trigger |
|
||
| Directus Flow | (Server-Config) | Scheduled Flow: Listings mit `destruct_at <= NOW()` löschen |
|
||
| Integration | `js/components/pages/page-create.js` | Selbstzerstörungs-Optionen im Formular |
|
||
| Integration | `js/components/pages/page-listing.js` | Countdown-Anzeige, "Jetzt zerstören"-Button |
|
||
| Integration | `js/components/listing-card.js` | Countdown-Badge auf Karten |
|
||
| CSS | `css/components.css` | Countdown-Badge, Warnungs-Styles |
|
||
|
||
### Directus Flow: Auto-Delete
|
||
|
||
```
|
||
Trigger: Schedule (*/15 * * * *)
|
||
Bedingung: listings WHERE self_destruct = true AND destruct_at <= NOW()
|
||
|
||
Aktionen:
|
||
1. Read: Betroffene Listings + deren File-IDs laden
|
||
2. Delete: Files löschen (directus_files)
|
||
3. Delete: Junction-Einträge löschen (listings_files)
|
||
4. Delete: Listings löschen
|
||
```
|
||
|
||
### Deal-basierte Zerstörung
|
||
|
||
```
|
||
Wenn Deal status → confirmed:
|
||
1. Prüfe: Hat das Listing self_destruct = true UND destruct_mode = 'deal'?
|
||
2. Ja → Setze destruct_at = NOW() + destruct_after_deal_hours
|
||
3. Ab dann greift der Scheduled Flow
|
||
```
|
||
|
||
Integration in `js/services/reputation.js` → `confirmDeal()`:
|
||
|
||
```js
|
||
// Nach beidseitiger Bestätigung:
|
||
if (listing.self_destruct && listing.destruct_mode === 'deal') {
|
||
const destructAt = new Date()
|
||
destructAt.setHours(destructAt.getHours() + (listing.destruct_after_deal_hours || 24))
|
||
await directus.updateItem('listings', listing.id, { destruct_at: destructAt.toISOString() })
|
||
}
|
||
```
|
||
|
||
### Privacy-Aspekte
|
||
|
||
- **Echte Löschung**: Kein Soft-Delete, kein Archiv — Daten werden unwiderruflich entfernt
|
||
- **Bilder inklusive**: Files werden aus Directus Storage gelöscht (nicht nur DB-Einträge)
|
||
- **Keine Suchmaschinen-Spuren**: `noindex` Meta-Tag für Listings mit Selbstzerstörung
|
||
- **Countdown sichtbar**: Käufer sehen, dass das Listing zeitlich begrenzt ist (schafft Urgency)
|
||
|
||
### i18n Keys
|
||
|
||
```
|
||
destruct.title = "Selbstzerstörung"
|
||
destruct.off = "Aus (Standard)"
|
||
destruct.time = "Nach Zeitablauf"
|
||
destruct.deal = "Nach Deal-Abschluss"
|
||
destruct.manual = "Jetzt zerstören"
|
||
destruct.duration.24h = "24 Stunden"
|
||
destruct.duration.48h = "48 Stunden"
|
||
destruct.duration.7d = "7 Tage"
|
||
destruct.duration.30d = "30 Tage"
|
||
destruct.afterDeal = "{{hours}} Stunden nach Deal"
|
||
destruct.warning = "Gelöschte Anzeigen können nicht wiederhergestellt werden."
|
||
destruct.active = "Selbstzerstörung aktiv"
|
||
destruct.expiresIn = "Läuft ab in {{time}}"
|
||
destruct.deletedAt = "Wird gelöscht am {{date}}"
|
||
destruct.confirm = "Anzeige unwiderruflich löschen?"
|
||
destruct.destroyed = "Diese Anzeige wurde gelöscht"
|
||
```
|
||
|
||
### Aufwand
|
||
|
||
- **Geschätzt**: 1.5–2 Tage
|
||
- **Dependencies**: Directus Flow (analog zu bestehender Expired-Listings-Flow)
|
||
- **Risiko**: Directus File-Löschung muss getestet werden (Cascade)
|
||
|
||
---
|
||
|
||
## Zusammenfassung
|
||
|
||
| # | Feature | Aufwand | Einzigartigkeit | Privacy-Impact |
|
||
|---|---------|---------|-----------------|----------------|
|
||
| 1 | Blind Meeting Points | 2–3 Tage | Sehr hoch — kein Konkurrent hat das | Hoch |
|
||
| 2 | Verifiable Listings | 1–2 Tage | Hoch — innovative Lösung ohne KYC | Mittel |
|
||
| 3 | Selbstzerstörende Listings | 1.5–2 Tage | Hoch — starkes Privacy-Signal | Sehr hoch |
|
||
|
||
**Gesamt: ~5–7 Tage Implementierung**
|
||
|
||
### Empfohlene Reihenfolge
|
||
|
||
1. **Verifiable Listings** — geringster Aufwand, sofort sichtbarer Wert, keine neue Dependency
|
||
2. **Selbstzerstörende Listings** — baut auf bestehendem Flow auf, starkes Marketingmerkmal
|
||
3. **Blind Meeting Points** — höchster Aufwand, aber stärkstes Alleinstellungsmerkmal
|