schmidt1024/kashilo
1
0
Fork 0
Code Issues Pull Requests Releases Activity

docs: update AGENTS.md and DIRECTUS-SCHEMA.md with crypto namespacing, chat polling, buyer_user field and notification flow

Browse Source
This commit is contained in:
Schmidt
2026-02-11 11:27:41 +01:00
parent 227791e8f9
commit f164b833bf
2 changed files with 38 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/DIRECTUS-SCHEMA.md
View File

@@ -141,10 +141,11 @@ Zero-Knowledge Chat-Konversationen zwischen anonymen Usern.
| `public_key_1` | text | NaCl Public Key Teilnehmer 1 |
| `public_key_2` | text | NaCl Public Key Teilnehmer 2 |
| `status` | string | `active`, `closed` |
| `buyer_user` | UUID | FK → directus_users, Buyer's Directus user ID |
| `date_created` | datetime | Erstellungsdatum |
| `date_updated` | datetime | Letzte Nachricht |
**Hinweis:** Die `participant_hash_*` Felder ermöglichen anonyme Zuordnung ohne Directus-User-Accounts.
**Hinweis:** Die `participant_hash_*` Felder ermöglichen anonyme Zuordnung ohne Directus-User-Accounts. Das `buyer_user` Feld speichert die Directus-User-ID des Käufers und wird bei Conversation-Erstellung gesetzt.
---
@@ -309,6 +310,34 @@ module.exports = async function(data) {
**Hinweis:** Ohne diese Absicherung könnte jeder `views` auf beliebige Werte setzen.
### Archive Expired Listings
**Zweck:** Archiviert abgelaufene Listings automatisch.
| Schritt | Typ | Beschreibung |
|---------|-----|--------------|
| 1. Trigger | Schedule `*/15 * * * *` | Alle 15 Minuten |
| 2. Operation | Update Data | `status → archived` wenn `expires_at < NOW` |
### ~~Notify: Listing Published~~ (Deaktiviert)
**Status:** Deaktiviert — wird jetzt direkt von `btcpay-webhook.php` gehandhabt (mit Duplikat-Check: prüft auf existierende Notification bevor eine neue erstellt wird, verarbeitet nur `InvoiceSettled`).
### Notify: New Message
**Zweck:** Erstellt eine Benachrichtigung für den Empfänger einer neuen Chat-Nachricht.
| Schritt | Typ | Beschreibung |
|---------|-----|--------------|
| 1. Trigger | Event Hook | `items.create` auf `messages` |
| 2. Read Data | Read Data | Conversation laden (anhand `conversation` ID aus Payload) |
| 3. Read Data | Read Data | Listing laden (anhand `listing_id` aus Conversation) |
| 4. Run Script | Run Script | Empfänger ermitteln (`sender_hash` ≠ `participant_hash_1/2` → anderer ist Empfänger) |
| 5. Condition | Filter Rule | Prüft ob Empfänger ermittelt wurde |
| 6. Create Data | Create Data | Notification erstellen für Empfänger |
**Wichtig:** Die Read Data und Create Data Operations benötigen **`$full`** Permissions (nicht `$trigger`), da sie auf Collections zugreifen die nicht im Trigger-Context verfügbar sind.
---
## User Role Permissions (Chat)
@@ -320,11 +349,11 @@ Conversations und Messages sind **nicht** über die Public-Rolle zugänglich. Nu
| Aktion | Erlaubt | Filter / Einschränkung |
|--------|:-------:|------------------------|
| Read | ✓ | Alle (Client filtert via `participant_hash`) |
| Create | ✓ | Keine Einschränkung |
| Update | ✓ | Nur `status` Feld, kein Row-Filter |
| Create | ✓ | Felder inkl. `buyer_user` |
| Update | ✓ | Nur `status`, `buyer_user` Felder, kein Row-Filter |
| Delete | - | Nicht erlaubt |
**Hinweis:** Im Zero-Knowledge-Design gibt es kein server-verifizierbares Feld, das beide Teilnehmer identifiziert (`participant_hash` ist nicht an einen Directus-User gebunden). Deshalb kann kein `$CURRENT_USER`-Filter für Read/Update gesetzt werden. Die Absicherung erfolgt durch: (1) Authentifizierungspflicht (Public hat keinen Zugriff), (2) Client-seitige Filterung via `participant_hash`, (3) Update nur auf `status`-Feld beschränkt, (4) Conversation-UUIDs sind nicht erratbar.
**Hinweis:** Im Zero-Knowledge-Design gibt es kein server-verifizierbares Feld, das beide Teilnehmer identifiziert (`participant_hash` ist nicht an einen Directus-User gebunden). Deshalb kann kein `$CURRENT_USER`-Filter für Read/Update gesetzt werden. Die Absicherung erfolgt durch: (1) Authentifizierungspflicht (Public hat keinen Zugriff), (2) Client-seitige Filterung via `participant_hash`, (3) Update nur auf `status` und `buyer_user` Felder beschränkt, (4) Conversation-UUIDs sind nicht erratbar.
### messages (User-Rolle)