18 KiB
18 KiB
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=stationim Ü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_atin 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():
// 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:
noindexMeta-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
- Verifiable Listings — geringster Aufwand, sofort sichtbarer Wert, keine neue Dependency
- Selbstzerstörende Listings — baut auf bestehendem Flow auf, starkes Marketingmerkmal
- Blind Meeting Points — höchster Aufwand, aber stärkstes Alleinstellungsmerkmal