27 lines
2.3 KiB
Markdown
27 lines
2.3 KiB
Markdown
# Web-Wallet: Mindestumfang ab erstem funktionalem MVP
|
|
|
|
**Beschlossene Priorität:** WebGUI von Beginn an, nicht erst nach dem Mining-Release. Das mitgelieferte `web/wallet/index.html` ist ausdrücklich **nur Layout/Vorschau**.
|
|
|
|
## Sichtbare Seiten und Funktionen
|
|
|
|
1. **Start / Wallet anlegen:** sichere Erzeugung, Passwort und Backup-Hinweise; Import/Recovery einer bestehenden Wallet.
|
|
2. **Übersicht:** Wallet-Adresse kopieren, verfügbares PTM-Guthaben (nur aus vertrauenswürdig überprüfter Node-Antwort), Höhe/Netzwerkstatus.
|
|
3. **Empfangen:** Adresse plus QR optional; Betrag darf optional als URI vorgeschlagen werden, falls Protokoll entschieden.
|
|
4. **Senden:** Empfängeradresse validieren, Betrag in exakt definierter Basis-Einheit, Fee-/Total-Vorschau, explizite Bestätigung, Signieren im Browser, Submit an Node.
|
|
5. **Historie:** Transaktionen mit Hash, Uhrzeit/Blockhöhe, Eingang/Ausgang, Bestätigungsstatus; leere oder Offlinezustände korrekt anzeigen.
|
|
6. **Sicherheit:** sperren/entsperren, sicheres Export-/Backup-Verfahren, klare Warnung bei Verlust des Backups.
|
|
|
|
## Sicherheits- und UX-Vertrag
|
|
|
|
- Keine serverseitige Schlüsselverwaltung. Clientseitige Kryptografie auf Basis geprüfter, gepflegter Bibliotheken und dokumentierter Standardformate.
|
|
- Keine Schlüssel, Mnemonics, Signaturgeheimnisse oder Klartext-Backups in HTTP-Requests, Logs, Telemetrie oder Git.
|
|
- Keys verschlüsselt ablegen, starke Passwortableitung/KDF mit überprüfbaren Parametern, keine ungesicherten `localStorage`-Seeds; Backup/Recovery durch Tests prüfen.
|
|
- Browser-XSS als Key-Leak-Risiko behandeln, strikte CSP, keine fremden Inline-Skripte oder CDN-Abhängigkeiten bei Wallet-Code; Third-Party-Libraries pinnen und auditieren.
|
|
- Entwicklungsserver standardmäßig 127.0.0.1; für entfernten Zugriff VS-Code-Portforwarding/SSH. Später HTTPS mit geeigneter Authentifizierung und CORS-Regeln.
|
|
- UI nie „Transaktion bestätigt“ anzeigen, bevor der konsensgeprüfte Status tatsächlich vorliegt. Keine erfundenen Zahlen, keine Demo-Schlüssel als echte Wallet ausgeben.
|
|
- Mobile, Desktop und Tastaturnutzung berücksichtigen.
|
|
|
|
## Design-Entscheidungen vor echter Implementierung
|
|
|
|
Adressschema, Schlüsselsuite, Signing-Bytes, Nonce/Sequenz, Chain-ID, Gebühren, Unlock-Lebensdauer, Recovery-Standard, Wallet-Storage und API-Version als ADR dokumentieren.
|