# DPP / DVP / DAP und optionale Integrationen

Status: **Schnittstellenentwürfe**, keine aktivierten Zahlungs-, Wallet- oder
Firmenverifikationsfunktionen. Diese Datei integriert die Produktanforderungen
des Masterplans ohne ungetestete Signatur-/Zahlungsversprechen.

## Profile und Organisationen — DH-009/010

Geplantes gemeinsames Envelope: `schema`, `subject`, `revision`, `previous`,
`issued_at`, `payload`, `issuer`, `delegation`, `signature`. Der Signaturkontext
ist je Typ getrennt; genaue kanonische Bytes und Vektoren müssen vor Parser-
Aktivierung festgelegt werden. Eine Änderung benötigt aktuelle Subject-AuthZ,
CAS der Revision und einen überprüfbaren Vorgänger. Public nur nach Vorschau.

`dh.developer-profile/1`: Anzeigename/Bio, Domain-Claims, öffentliche Repo-IDs,
optionale Zahlungsprofil-Referenz. Keine verpflichtende zentrale Registrierung.
`dh.organization/1`: Anzeigename, rechtlicher Name, Land/Rechtsform, optionale
regionale Register-/Kontaktfelder, Domains, Mitgliederrollen und Impressum.
Rollen: owner/admin/maintainer/reviewer/billing_manager/member, jede Aktion eng
an Identitäten gebunden. Besitzerwechsel braucht signierte Autorisierung.

Impressum ist eine explizite Union:

| mode | Inhalt | UI-Aussage |
|---|---|---|
| `url` | HTTPS-URL, URL validiert, kein automatischer Fetch | „Impressum verlinkt“ |
| `file` | versionierte öffentliche Profil-Datei/Hash, Herkunft | „Angaben importiert“ |
| `form` | landesspezifisch konfigurierte Angaben, vor Veröffentlichung bestätigt | „Selbstangabe“ |

Keiner dieser Eingabewege belegt eine rechtliche Prüfung. Keine vertraulichen
Ausweiskopien/Registerbelege in öffentliche Profile, DDP oder Logs. Explizite
Vorschau, Export und lokale Löschung; bereits replizierte öffentliche Daten
können bei fremden Nodes verbleiben. Regionale Rechtsprüfung ist ein eigenes Gate.

## Zahlungsmethoden — DH-011

Geplantes Zahlungsprofil bindet Subject, geordnete Methoden, Revision,
Änderungszeit, Signatur und vorheriges Profil. Provider-Schnittstelle:
`type`, `provider`, `network`, `environment`, `recipient`, `details`, `status`.
Jeder Adapter deklariert seine begrenzten Felder, Größenlimits, Kompatibilitäten
und Testvektoren. Kein universeller Krypto-Adressvalidator wird vorgetäuscht.

| Methode | Zulässiges Zielmodell | Vor Aktivierung zu prüfen |
|---|---|---|
| BTC | Netzwerk+Main/Testnet+Empfangsadresse, optional Zahlungs-URI | Addressfamilie/URI/Wallet-Testvektoren |
| BCH | explizites BCH-Netzwerk, CashAddr-kompatible Darstellung | getrennte Chain-/URI-/Adressprüfung |
| BSV | explizites BSV-Netzwerk, passende Adresse/URI | eigenständiger Adapter und Tests |
| Bank | explizit freigegebene Empfänger-/IBAN/BIC-Angaben oder Anleitung | Datensparsamkeit, Formate, Jurisdiktion |
| PayPal | offizieller externer HTTPS-Zahlungslink | Host-/URL-/Phishing-Prüfung, Provider-Policy |
| Karte | externer PSP-Checkout-Link | keine PAN/CVV/Kartendaten im Node |
| Weitere | optionaler `external_checkout` HTTPS-Adapter | Credentials, Redirects, unsichere Ziele ablehnen |

UI: freiwillig „Unterstützen“, Tabs Krypto/Bank/Karte/PayPal/Weitere;
Empfänger/Netzwerk, Kopieren/QR erst nach adapterbezogener Validierung;
Zweck Projekt/Sicherheitswartung/Release/Issue/Organisation. Wechselhistorie und
Hinweis auf frisch geänderte Ziele. Ein signiertes Profil beweist nur autorisierte
Profiländerung, keine Kontrolle über die angegebene Empfangsadresse. Deren
Verifikation separat sichtbar halten; Watch-only ist Empfang, kein Besitzbeweis.

Keine Gelder, Custody, automatischen Auszahlungen, internen Guthaben,
Blockchain-Beobachtung, automatischen Steuerbelege oder öffentlichen Spenderlisten.
Keine externen Requests bei bloßer Profilanzeige. Externer Checkout ist sichtbar
extern; keine offenen Redirects und keine fremden Login-Daten speichern.
Provider-/Rechts-/Datenschutzprüfung vor echtem Betrieb bleibt erforderlich.

## Wallet-Authentisierung — DH-013

Decentralhub-Root-ID bleibt walletunabhängig. Primär-ID + Gerät + Recovery müssen
vor Wallet-Linking funktionieren. Der Entwurf einer Challenge bindet schema,
challenge_id, Nonce, action(link_wallet/login/unlink), network(btc/bch/bsv),
environment(mainnet/testnet), Identity-ID, Origin, Audience, Issued/Expires,
Session/Request-Hash. Typisierte Signaturformate pro Wallet-Adapter festlegen.

Adaptervertrag: unterstützte Wallet-Versionen, Netzwerke, Adresstypen,
Message-Signature-Schema, Positive-/Negativvektoren, Replay-/Cross-Chain-/Origin-
Tests. Nichtunterstütztes Format ist Fehler; keine ECDSA-Universalroutine und
kein gleiches Message-Prefix für BTC/BCH/BSV. BIP-322 ist ein Prüfgegenstand
für BTC, keine implizite universelle Unterstützung. Kritische Änderungen brauchen
zusätzliche Geräteauthentisierung. Persistierter Replay-Schutz vor jeder Route.

UI darf niemals Seed/WIF/Private-/Recovery-Key oder eine Zahlung/Transaktion zur
Anmeldung verlangen. Keine Wallet-Connectoren installiert/aufgerufen. Die aktuelle
Kompatibilitätsmatrix enthält **null freigegebene Wallet-/Netzwerk-Kombinationen**.
Wallet-Login erst nach Adaptertests und externer Signaturprüfung aktivieren.

## Domain und rechtliche Attestierungen — DH-012

Geplantes DVP-Envelope bindet Subject, Claim, Issuer, Evidence-Referenz, Scope,
Prüfzeit, Ablauf, Revision, Widerrufsreferenz und Signatur. Domain-Challenge über
HTTPS-Datei/DNS beweist nur zeitgebundene Domain-Kontrolle; SSRF/TLS/DNS-Grenzen
und Redirect-Policy gehören ins Protokoll. Keine Netzabfrage ist implementiert.

Status `self_declared`, `domain_verified`, `registry_checked`,
`independently_attested` sind verschieden. Anzeige nennt Prüfer, Scope, Zeitpunkt,
Ablauf und Widerruf; abgelaufene/widerrufene Claims verlieren ihr Badge. Kein
globaler Trust-Score und keine zentrale Pflichtprüfstelle. Client wählt lokal
vertrauenswürdige Prüfer; Firmenkontrolle, Walletkontrolle und Rechtsträger sind
unterschiedliche Aussagen. Evidence bleibt datensparsam außerhalb Gossip.

## KI, Attribution und Adapter — DH-014/015

Agenten besitzen separat widerrufbare, befristete Capabilities, keine implizite
Shell-Berechtigung. Signierte Proposals/Reviews binden genaue Commit-/Tree-IDs,
Autor/Agent, Testresultate, Scope, Zeitpunkt und menschliche Entscheidung.
Agenten-Output und Repo-Inhalt sind untrusted Input; Prompt Injection, Secret-
Exfiltration und Testsandbox müssen vor Write/Run-Tools behandelt werden.
MCP bleibt derzeit nur Public-Discovery-Lesen. Unbekannte/schreibende Tools werden
abgelehnt; vollständige MCP-Transport-/Auth-Konformität ist nicht behauptet.

Workspace-Entwurf: Gruppen, Repo-Pins, Aufgaben, Zuweisung, Diskussion, Proposal,
Review; private Workspace-Inhalte erst nach E2EE/Gruppenschlüsselkonzept.
Buzz/Nostr wird optionaler deaktivierbarer Adapter mit eigener Identity-/Event-
Abbildung. Lizenz/API/Wartungsstatus vor Aktivierung erneut prüfen; kein Netz-
oder LLM-Zwang im Core. Keine Implementierung gegen unüberprüfte Fremd-APIs.

DAP-Attribution referenziert konkrete Objekte für derived_from/forked_from/
depends_on/inspired_by und getrennte Lizenznachweise. Attribution ersetzt keine
Lizenzberechtigung. Signierte Advisories/Release-Provenienz und CI-Ergebnisse
brauchen separate Kontexte; niemals fremden Code im Node-Prozess ausführen.