# Decentralhub — konsolidierter Masterplan für Codex **Dokumentversion:** 1.0 · **Stand:** 24. Oktober 2026 **Status:** Produkt- und Architekturvorschlag; keine Behauptung, dass die beschriebenen Funktionen bereits implementiert sind. **Zielgruppe:** Entwickler, Codex, Sicherheitsprüfer, Maintainer und Betreiber von Decentralhub-Knoten. **Sprache der Produktoberfläche:** zunächst Deutsch und Englisch; Protokoll-IDs, Code und API-Felder auf Englisch. > **Leitgedanke:** Eine offline-first, selbst gehostete, dezentrale und KI-native Software-Forge mit nativer Versionsverwaltung, portablem Identitätssystem, P2P-Discovery, sicheren privaten Repositories und optionalen Integrationen. Ein zentraler Dienst darf niemals Voraussetzung für lokale Entwicklung, die Prüfung von Objekten oder die Nutzung bereits erreichbarer Peers sein. --- ## 0. Verbindliche Arbeitsanweisung an Codex 1. **Repository zuerst untersuchen.** Bestehende Dateien, Tests, Dokumentation und Schnittstellen lesen. Keine Funktionen als vorhanden deklarieren, nur weil sie in diesem Dokument spezifiziert sind. 2. **Keine Komplett-Neuschreibung ohne Not.** Kleine, nachvollziehbare Änderungen mit Tests, Migrationsplan und Rückwärtskompatibilität bevorzugen. 3. **Sicherheit vor Feature-Fülle.** Kein ungeprüfter Remote-Code, keine unsicheren Standardfreigaben, keine automatische Freigabe von Agenten-Patches, keine geheimen Schlüssel im Log. 4. **Go-Standardbibliothek als Default.** Externe Bibliotheken nur nach dokumentierter Sicherheits-, Lizenz- und Wartungsabwägung. Für komplexe Kryptostandards lieber geprüfte Implementierungen als selbst erfundene Kryptografie; wenn die Null-Dependency-Vorgabe eine sichere Umsetzung verhindert, Feature zurückstellen und Trade-off offenlegen. 5. **Offline-first ist eine Invariante.** Commit, Log, Verify, Export und private lokale Arbeit dürfen keine Netzwerkverbindung benötigen. 6. **Private-by-default.** Lokale Projekte sind ohne ausdrückliche Freigabe nicht öffentlich und senden keinerlei Metadaten an fremde Knoten. 7. **Trennung von Fakt und Ziel.** Implementiert / experimentell / geplant / blockiert eindeutig markieren. Versionsnummer ist keine Sicherheitszertifizierung. 8. **Plattformrollen sauber trennen.** Windows-/Linux-CLI als Entwicklerclient; Linux als primäre Plattform für ständig erreichbare Nodes; lokaler Node auf Windows oder in Containern optional, nicht Voraussetzung. 9. **Spezifikation vor Transport.** Canonical Encoding, Domain Separation, Versionsfelder, Größenlimits, Authentisierung, Autorisierung, Konfliktregeln und Testvektoren dokumentieren, bevor öffentliche P2P-Endpunkte stabilisiert werden. 10. **Änderungen abschließen:** `go test ./...`, `go test -race ./...` (wo verfügbar), `go vet ./...`, Build für Linux amd64 und Windows amd64/arm64; End-to-End-Tests und Sicherheits-Checkliste aktualisieren. Nicht ausgeführte Tests ausdrücklich nennen. --- ## 1. Tatsächlicher Ausgangsstand: bereitgestelltes v1.0.0-Development-Preview-Archiv Diese Bestandsaufnahme basiert auf `decentralhub-v1.0.0-source.zip` und dessen README. **Es handelt sich ausdrücklich nicht um ein produktionsreifes v1.0.0.** Das Archiv enthält u. a. `cmd/decentralhub/main.go`, `internal/localrepo/store.go`, Tests und Dokumentation. Vor jeder Änderung den realen Quellcode vollständig prüfen. ### Im README als implementiert beschrieben - Go-Standardbibliothek ohne externe Go-Module und ohne Git-Abhängigkeit. - Lokale Offline-Snapshots mit SHA-256-Inhaltsadressierung, verketteter Historie, Integritätsprüfung und Export in ein neues Verzeichnis. - Windows-/Linux-CLI für lokale Snapshot-Operationen. - HTTP-Discover-Oberfläche mit Suche/Kategoriefilter und Hinweis auf begrenzten lokalen Index. - Ed25519-signierte Discovery-Ereignisse, öffentlicher Metadatenfeed, experimentelle Peer-Synchronisierung und lesende MCP-Schnittstelle. - Lokale Repositories standardmäßig nicht öffentlich; `publish` kündigt **Metadaten** an, überträgt **keinen** Repository-Snapshot. ### Im README ausdrücklich nicht fertig - Authentifizierte Remote-Operationen `clone/push/pull`, private Multi-Device-Synchronisierung, Ende-zu-Ende-Verschlüsselung und Rollenrechte. - Konfliktbehandlung, sichere Windows-Schlüsselablage, Release-Signaturen, vollständige MCP-Konformität, transaktionale Mehrschreiber-Speicherung, Spam-/DoS-Abwehr. - Buzz-/Nostr-Adapter, vollständige Issues/Reviews, Sicherheits-Audit. - Der HTTP-Event-Ingestion-Endpunkt ist nicht für untrusted Netzwerke gehärtet; Server **nicht direkt ins öffentliche Internet stellen**. - Snapshot-Operationen noch nicht crash-transaktional; Symlinks und Dateien über 32 MiB werden abgelehnt; gleichzeitige Schreiber nicht unterstützt. - Windows-Binaries sind cross-kompiliert, nicht auf Windows-Hardware verifiziert und nicht signiert. **Konsequenz:** Die nächste Entwicklungsarbeit beginnt mit Integrität, sicheren Identitäten, Remote-Synchronisierung und Zugriffskontrolle — nicht mit Wallet-Login oder Zahlungsabwicklung als erstem Coding-Schritt. --- ## 2. Produktprinzipien und Betriebsmodi ### 2.1 Betriebsarten | Modus | Verhalten | Netzwerkbedarf | |---|---|---| | Lokal / Offline | Eigene Repositories erstellen, bearbeiten, versionieren, prüfen, exportieren | keiner | | Intranet | Peers und Agenten im LAN, private Team-Repos, lokale Discovery | nur LAN | | Self-hosted | eigener Server zu Hause, NAS, Mini-PC, dedizierter Server oder VPS | optional öffentlich | | Föderiert / öffentlich | öffentliche Projekte, Discovery, Replikation, Feeds | Peer-Konnektivität | Betriebsarten können gleichzeitig gelten. Internetzugang und Peer-Konnektivität sind **nicht dasselbe**. ### 2.2 Sichtbarkeit eines Repositorys - `private`: nur lokale/ausdrücklich autorisierte Identitäten; kein öffentliches Discovery-Event. - `intranet`: ausschließlich definierte Peers oder Gruppen; keine unbeabsichtigte Internetveröffentlichung. - `unlisted`: per Kenntnis einer Adresse/ID erreichbar, aber nicht in Discover; Zugriffsschutz **separat** definieren (Unlisted bedeutet nicht privat). - `public`: öffentlich lesbar und in Discovery auffindbar, wenn Publisher das explizit aktiviert. Änderung `private -> public` muss als bewusste Freigabe mit Vorschau auf alle exponierten Metadaten erfolgen. Änderung `public -> private` kann zuvor replizierte Inhalte **nicht zurückholen**; UI muss davor warnen. ### 2.3 Domain und Identität - Ein Repository hat eine kryptografisch gebundene, domainunabhängige ID, z. B. `dh:repo:` (genaue Kodierung erst nach Protokollspezifikation festlegen). - Ein Entwickler nutzt optional eigene Domain und Pfade wie `/source`, `/issues`, `/releases`, `/.well-known/decentralhub.json`. - HTTPS-Domain ist ein Locator, keine maßgebliche Projektidentität. - Ein Repository kann von mehreren Peers angeboten werden; Integritätsprüfung anhand signierter Metadaten und Objekt-Hashes. - Keine zentrale Domain oder globale Namensregistrierung als Pflicht; menschenlesbare Aliase sind nicht global eindeutig. --- ## 3. Zielarchitektur ```text Windows / Linux / macOS (später) ┌──────────────────────────────────────────────────────┐ │ dh CLI + optional Desktop UI + Browser │ │ lokale Objekte · Offline-Commits · lokale Signatur │ │ ausgehende Sync-Queue · sichere Schlüsselablage │ └───────────────────────┬──────────────────────────────┘ │ authentifiziertes HTTPS ┌───────────────────────▼──────────────────────────────┐ │ Decentralhub Node (primär Linux; Heimserver/VPS/NAS) │ │ API · Web UI · MCP · AuthZ · Repo-Objekte · Index │ │ Discovery · Anti-Entropy · Rate Limits · Audit │ └───────────────────────┬──────────────────────────────┘ │ P2P signierte Ereignisse andere unabhängige Nodes Optional, isoliert: Buzz/Nostr-Adapter, Agenten, Zahlungen, Wallet-Connectoren, Firmenverifizierungsanbieter. ``` **Implementierungsstruktur (Ziel, keine Pflicht zur sofortigen Umbenennung):** ```text cmd/dh/ # lokale Entwickler-CLI cmd/decentralhubd/ # Node-Prozess internal/objects/ # Blob, Tree, Commit, Referenzen, Hashing internal/identity/ # Schlüssel, Delegation, Widerruf internal/authz/ # Rechte, Capabilities, Policies internal/repo/ # Arbeitsbaum, Snapshots, Merge, Sync-Queue internal/sync/ # Clone/Fetch/Push/Pull, Anti-Entropy internal/discovery/ # signierte Veröffentlichungsereignisse internal/payments/ # reine Zahlungsmetadaten/Integrationen internal/verification/ # Organisationsnachweise und Prüfstatus internal/mcp/ # agentische Werkzeuge web/ # Browser-UI, möglichst wenig JS protocol/ # versionierte Spezifikationen/Testvektoren docs/ # Bedrohungsmodell, Migration, Betrieb ``` ### 3.1 Repository-Objektmodell - **Blob**: unveränderlicher Dateiinhalt. - **Tree**: Pfadnamen, Typen, Berechtigungsmetadaten und Kindobjekte; Pfadnormalisierung plattformübergreifend definieren. - **Commit**: Tree-Hash, Eltern-Hashes, Autor-ID, Zeitangaben, Nachricht, Signatur. - **Ref**: benannter Zweig/Tag mit autorisierter, atomarer Aktualisierung; nicht einfach frei überschreibbarer Text. - **Proposal / Review**: eigenständig signierte Objekte mit Referenzen auf konkrete Commit-Hashes. - **Release / Attribution / DiscoveryEvent**: getrennte Objekttypen. Hashing: Algorithmus explizit versionieren, kanonische Byte-Repräsentation definieren, Domain Separation zwischen Objekttypen einsetzen; keine alleinige Vertrauensannahme auf einen frei wählbaren Dateinamen. Unbekannte Typen und Versionen sicher ablehnen. Commit-DAG darf verzweigen; divergierende Offline-Änderungen erhalten bleiben, kein stilles Last-Writer-Wins. ### 3.2 Remote-Sync als wichtigster nächster Meilenstein 1. Client initialisiert privates Repo offline. 2. Client erstellt Commit mit lokalen Objekten. 3. Client authentifiziert sich gegenüber Node mit signiertem Challenge-Response (Nonce, Origin, Audience, Ablaufzeit, Request-Bindung). 4. Node prüft Repository-ACL, Quotas und Objektgrenzen. 5. Client überträgt fehlende Objekte in begrenzten Chunks; Server verifiziert Hashes. 6. Atomarer, autorisierter Ref-Update mit erwarteter vorheriger Ref-Version (Compare-and-Swap). 7. Zweites Gerät klont/fetcht, prüft Hashes und Signaturen; Offline-Divergenz führt zu Branch/Conflict, nicht Datenverlust. 8. Private Multi-Device-Repos erst nach dokumentierter Verschlüsselungs- und Schlüsselrotation-Architektur freigeben. --- ## 4. Identität, Accounts und Geräte ### 4.1 Primäridentität: unabhängig von Wallet und Server **Empfehlung:** Decentralhub-ID ist eine eigenständige kryptografische Identität (z. B. Ed25519), **nicht** eine BTC-Adresse, Domain oder Benutzername. Der Benutzer kann mehrere Wallets, Domains und Geräte daran binden. Dadurch bleibt das Konto bei Wallet-Wechsel, kompromittiertem Schlüssel oder Wechsel der Kryptowährung erhalten. - Offline-/Recovery-Schlüssel delegiert kurzlebigere Geräte-Schlüssel. - Geräte separat registrieren, benennen, einschränken und widerrufen. - Kein Server erhält Master-Private-Keys. - Wiederherstellung und Key-Rotation ausdrücklich spezifizieren; niemals Recovery ausschließlich an eine Wallet-Adresse binden. - Signatur beweist Kontrolle über Schlüssel, nicht rechtliche Identität oder Seriosität. - Authentisierung (`wer ist es?`) strikt von Autorisierung (`was darf diese Identität?`) trennen. ### 4.2 Kontoerstellung per Bitcoin-Wallet: BTC, BCH und BSV **Gewünschte UX:** „Mit Wallet registrieren / anmelden“ und Auswahl von **Bitcoin (BTC)**, **Bitcoin Cash (BCH)** oder **Bitcoin SV (BSV)**. Alle drei sind **eigenständige Netzwerke mit unterschiedlichen Adressformaten, Signaturkonventionen, Wallet-APIs und Tooling**. Nicht als austauschbare Implementierung behandeln. **Sichere konzeptionelle Registrierung:** 1. Nutzer wählt BTC, BCH oder BSV und verbindet eine **unterstützte** Wallet oder nutzt eine Wallet-kompatible Signiermethode. 2. Client erzeugt bzw. lädt die **Decentralhub-Primäridentität**. 3. Server erstellt einmalige Challenge mit `challenge_id`, zufälliger Nonce, `audience`, Server-Origin, Netzwerkkennung (`btc`/`bch`/`bsv`), beabsichtigter Aktion (`link_wallet`/`login`), Ablaufzeit und Bindung an Decentralhub-ID. 4. Wallet signiert die Challenge **mit einer für dieses Netzwerk und diesen Wallet-Typ unterstützten Signaturmethode**. 5. Der Server validiert die Signatur **netzwerkspezifisch** und prüft Nonce, Ablauf, Origin, Zielidentität, Replay-Schutz und Widerrufsstatus. 6. Ergebnis ist eine signierte Wallet-Verknüpfung zur Decentralhub-ID, **kein** Ersatz der Primäridentität. 7. Optional wird die Wallet als Login-Faktor verwendet. Kritische Aktionen erfordern zusätzliche Authentisierung (z. B. registriertes Gerät). **Wichtig:** Für BTC ist BIP-322 ein relevanter Standard für allgemeine Nachrichtensignaturen; Wallet-Unterstützung ist nicht universell. Für BCH und BSV dürfen **nicht** dieselben Prüfroutinen oder dieselben Message-Prefix-Annahmen blind wiederverwendet werden. Die jeweils tatsächlich unterstützten Wallets, Address-Typen und Signaturformate müssen durch Testvektoren und Integrationstests festgelegt werden. Es gibt keine seriöse Zusage „alle Wallets funktionieren“, bevor die Kompatibilitätsmatrix erstellt ist. **Sicherheitsregeln:** - **Niemals Seed-Phrase, WIF, privaten Schlüssel oder Recovery-Phrase an Decentralhub übermitteln.** UI warnt ausdrücklich vor solchen Eingaben. - Keine Transaktion, keine Zahlung und keine Wallet-Berechtigung zur Anmeldung verlangen. Login erfolgt über eine signierte Nachricht, nicht über eine On-Chain-Transaktion. - Replay-Schutz und strikte Netzwerk-/Origin-Bindung; keine Signatur einer beliebigen, vom Server unklar dargestellten Zeichenfolge. - Eine Adresse kann mehrere Skript-/Signaturtypen repräsentieren; „Adresse + ECDSA-Verify“ ist nicht universell korrekt. - Wallet-Login darf keine unbemerkte Kontoübernahme bei Neuzuordnung/Key-Rotation erlauben. - Netzwerk-/Adressformate explizit unterscheiden: z. B. BTC-Adressfamilien, BCH-CashAddr und BSV-kompatible Formate; keine automatische Chain-Ableitung allein aus ähnlich aussehenden Zeichenfolgen. - Watch-only-Adressen sind für **Spendenempfang** möglich, nicht für Besitznachweis durch Signatur. - Testnet und Mainnet strikt trennen. **Rollout:** Wallet-Adressen als **verifizierte oder unbestätigte Zahlungsprofile** zuerst; Wallet-Sign-in erst nach nachweislich getesteter BTC/BCH/BSV-Matrix und externer Prüfung der Signaturverifikation. ### 4.3 Datenmodell (illustrativ, nicht final) ```json { "version": 1, "identity_id": "dh:id:example", "wallet_links": [ { "network": "btc", "address": "", "verification_method": "", "verified_at": "2026-10-24T00:00:00Z", "visibility": "public" } ] } ``` Dieses Beispiel enthält absichtlich **keine erfundene, universelle Wallet-Signatur**. --- ## 5. Native Spenden und Finanzierung ### 5.1 Produktziel Entwickler, Teams und Firmen können auf Profil-, Repository- und Release-Seiten **freiwillige Spendenwege** anzeigen. Decentralhub ist standardmäßig **kein Zahlungsdienstleister**, keine Verwahrstelle und kein Geldtransmitter. Es speichert zunächst nur signierte, vom Empfänger freigegebene Zahlungsmetadaten und öffnet externe Zahlungsseiten oder Wallet-Apps. ### 5.2 Unterstützte Methoden als offenes Provider-Modell | Methode | MVP-Integration | Später / Einschränkungen | |---|---|---| | BTC | veröffentlichte Empfangsadresse, QR-Code, optional BIP-21-Link | Lightning separat; Beträge/Status nicht ohne Zahlungsbeleg behaupten | | BCH | CashAddr, QR-Code, chain-spezifischer Payment-Link, soweit kompatibel | Wallet-Kompatibilität prüfen | | BSV | BSV-Adresse und kompatibler Wallet-Link | Netzwerk-spezifische URI-/Wallet-Tests | | Banküberweisung | IBAN/BIC/Empfängername oder gehostete Zahlungsanweisung, vom Empfänger freigegeben | sensible Daten und regionale Rechtslage beachten | | Kredit-/Debitkarte | externer Checkout-Link über angebundenen PSP | **keine Kartennummern, CVV oder PAN im Decentralhub-Backend** | | PayPal | offizieller PayPal-Spenden-/Zahlungslink | keine fremden Login-Daten speichern | | Weitere | generischer `external_checkout`-Provider mit geprüfter HTTPS-URL | z. B. Stripe Checkout, SEPA-Anbieter, lokale Methoden | **Nicht „alle“ Methoden hart kodieren.** Eine versionierte Provider-Schnittstelle erlaubt weitere Zahlungsmethoden, ohne den Core aufzublähen. Alle Provider optional; keine Registrierung bei einem zentralen Dienst erforderlich. ### 5.3 Spendenseite: UX - Profil zeigt `Unterstützen` mit Methoden-Tabs **Krypto / Bank / Karte / PayPal / Weitere**. - Jede Methode zeigt Empfänger, Netzwerk/Währung, Adresse bzw. Zahlungslink und klaren Hinweis auf externe Verarbeitung. - Kryptoadressen per Kopierfunktion und QR-Code; vor dem Anzeigen gegen versehentliche Verwechslung der Chains validieren. - Optionaler Spendenzweck: `Projekt allgemein`, `Sicherheitswartung`, `Release`, `Issue`, `Organisation`. - Für Unternehmen: Hinweis auf mögliche Rechnungs-/Spendenbelegpflichten; keine automatische steuerliche Spendenquittung versprechen. - Keine öffentlichen Spenderlisten oder Zahlbeträge ohne ausdrückliche Zustimmung. - Empfänger kann Zahlungswege pausieren, entfernen, ersetzen und signiert aktualisieren. ### 5.4 Sicherheit / Missbrauch - Zahlungsprofil muss vom autorisierten Profilinhaber signiert sein; UI zeigt Änderungshistorie und Warnung bei frisch gewechselter Adresse. - Ein von einem fremden Peer repliziertes Profil darf nicht unbemerkt eine andere Zahlungsadresse einschleusen. - Bei kryptografischen Adressen ist **Kontrolle der Empfangsadresse** optional prüfbar; die Fähigkeit, eine Adresse zu veröffentlichen, beweist keine Kontrolle. Verifikationsstatus sichtbar halten. - Keine serverseitige Custody, keine automatischen Auszahlungen, kein internes Guthaben in der ersten Phase. - Externe Checkout-URLs nur über HTTPS, mit Domain-/Phishing-Warnung und sicherer URL-Validierung; keine offenen Redirects. - Keine automatische On-Chain-Zahlungserkennung ohne explizite, datenschutzbewusste Blockchain-Provider-Architektur. - Wallet-Login und Wallet-Spendenprofil sind getrennte Funktionen: Login-Wallet muss nicht die öffentliche Spendenwallet sein. - Juristische Prüfung zu Geldwäsche-/Zahlungsdiensterecht, Steuern, Verbraucherrecht und Datenschutz ist **länderabhängig** und vor echtem Zahlungsbetrieb erforderlich. ### 5.5 Illustratives Zahlungsprofil ```json { "schema": "dh.payment-profile/1", "subject": "dh:repo:example", "methods": [ {"type": "crypto", "network": "btc", "address": ""}, {"type": "crypto", "network": "bch", "address": ""}, {"type": "crypto", "network": "bsv", "address": ""}, {"type": "bank_transfer", "display_label": "SEPA-Überweisung", "details_visibility": "owner-configured"}, {"type": "external_checkout", "provider": "paypal", "url": "https://example.invalid/donate"}, {"type": "external_checkout", "provider": "card", "url": "https://example.invalid/checkout"} ], "updated_at": "2026-10-24T00:00:00Z", "signature": "" } ``` `example.invalid` ist absichtlich keine echte Zahlungsadresse. --- ## 6. Entwickler- und Firmenprofile, Impressum, Verifikation ### 6.1 Drei unterschiedliche Aussagen 1. **Kryptografisch verifiziert:** Profilkontrolle durch registrierten Schlüssel nachgewiesen. 2. **Domain verifiziert:** Profil kann eine Domain durch Challenge/Datei/DNS nachweislich kontrollieren. 3. **Unternehmen rechtlich verifiziert:** Rechtsträger anhand belastbarer Dokumente/Registerdaten oder eines anerkannten externen Prüfers geprüft. Diese Stufen **dürfen nicht** als gleichwertig dargestellt werden. Ein verlinktes Impressum ist **keine** Firmenverifikation. Ein Domain-Nachweis beweist keine Registereintragung. Ein Wallet-Nachweis beweist keine Unternehmensidentität. ### 6.2 Drei Eingabewege für Firmen **Option A — Impressumslink (schnellster Weg):** - Firmenprofil hinterlegt `https://firma.example/impressum`. - Decentralhub zeigt „Impressum verlinkt“, nicht „Firma verifiziert“. - Optional kann ein Node die URL auf HTTPS/Erreichbarkeit prüfen; externe Seiteninhalte niemals ungefiltert als vertrauenswürdig übernehmen. **Option B — Datei (maschinenlesbar und versioniert):** - Firma legt z. B. `/.well-known/decentralhub-organization.json` auf ihrer Domain ab oder lädt eine signierte Profil-Datei hoch. - Felder mit Versionierung, optionalen regionalen Attributen, Provenienz und Signatur. - Domain-Kontrolle kann per HTTPS-Datei oder DNS-Challenge nachgewiesen werden; DNSSEC/TLS-Grenzen dokumentieren. - Öffentliche Datei darf keine unnötigen persönlichen Dokumente, Ausweiskopien oder vertraulichen Registerunterlagen enthalten. **Option C — Formular (beste UX für viele Unternehmen):** - UI fragt Land, Rechtsform, offizieller Name, Registergericht/-nummer soweit zutreffend, Anschrift, Vertretungsberechtigte, Kontakt, Umsatzsteuer-ID soweit erforderlich und Impressums-URL ab. - Länderspezifische Pflichtfelder konfigurierbar; kein universelles „EU-Impressum“-Schema behaupten. - Formular generiert versionierte, signierte Organisationsmetadaten und optional eine exportierbare Datei. - Vorschau und Datenschutzwarnung vor Veröffentlichung. **Empfehlung:** Alle drei anbieten. Formular als bequemster Einstieg; Import einer Datei für technisch versierte Teams; Link als Minimalvariante. Diese Wege sind **Angabemethoden**, keine automatische rechtliche Verifikation. ### 6.3 Firmen-Verifikationsprozess (späteres Feature) - `self_declared`: Angaben vom Unternehmen selbst, ungeprüft. - `domain_verified`: Kontrolle einer Domain technisch nachgewiesen. - `registry_checked`: Registerangaben gegen eine vertrauenswürdige Quelle geprüft, mit Prüfdatum und Quelle. - `independently_attested`: signierte Attestierung durch benannten Prüfer, mit Scope, Ablauf und Widerruf. **Dezentralität:** Keine globale Instanz entscheidet, welche Firma „echt“ ist. Prüfer veröffentlichen signierte Attestierungen; Clients/Nodes entscheiden lokal, welchen Prüfern sie vertrauen. UI nennt **immer** Prüfer, Prüfumfang und Prüfdatum statt eines pauschalen grünen Häkchens. **Datenschutz:** Nur nötige öffentliche Firmendaten verbreiten. Vertrauliche Belege gehören in einen zugriffsgeschützten Verifikationsprozess mit Lösch-/Aufbewahrungsregeln, nicht in öffentliche P2P-Gossip-Ereignisse. Ein gesetzlich erforderliches Impressum kann personenbezogene Daten enthalten; Jurisdiktion und Veröffentlichungspflichten prüfen. ### 6.4 Organisationsmodell - Organisation hat eigene signierte ID und Mitgliederrollen: `owner`, `admin`, `maintainer`, `reviewer`, `billing_manager`, `member`. - Mehrere Domains, Repositories, Zahlungsprofile und rechtliche Einheiten können verknüpft sein; rechtliche Einheit explizit benennen. - Berechtigungen sind an Identitäten und delegierte Schlüssel gebunden, nicht an ungesicherte Anzeigenamen. - Eigentümerwechsel und Widerruf erfordern revisionssichere, signierte Vorgänge. ### 6.5 Illustratives Organisationsprofil ```json { "schema": "dh.organization/1", "id": "dh:org:example", "display_name": "Beispiel Software GmbH", "legal_name": "Beispiel Software GmbH", "country": "DE", "imprint": { "mode": "url", "url": "https://example.invalid/impressum" }, "domains": ["example.invalid"], "claims": [ {"type": "domain_control", "status": "unverified"}, {"type": "legal_entity", "status": "self_declared"} ], "signature": "" } ``` **Rechtlicher Hinweis:** Pflichtangaben hängen von Land, Rechtsform, Geschäftstätigkeit und Zielmarkt ab; das Formular ersetzt keine Rechtsberatung. Für Deutschland sind insbesondere einschlägige Anbieterkennzeichnungs-, Register- und Datenschutzpflichten zu prüfen. --- ## 7. Discovery, Newsletter, Sterne und wichtige Updates ### 7.1 Getrennte Feeds - **Neu veröffentlicht:** nur erstmalige öffentliche Repository-Veröffentlichung. Spätere Commits dürfen den Eintrag nicht nach oben schieben. - **Wichtige Updates:** explizite Releases/Ankündigungen, pro Repository gebündelt und gedrosselt. - **Kategorien:** Themenfeeds mit lokalen Rankings und Abonnements. - **Beliebt/Trending:** zeitbezogene Resonanz, nicht bloß Gesamtzahl der Sterne. - **Gefolgt:** Updates der abonnierten Projekte. ### 7.2 Netzwerktransport - Event-getriebenes Gossip an eine begrenzte Anzahl Peers; nicht jedes Ereignis an jeden Knoten senden. - Periodische Anti-Entropy-Synchronisierung für verpasste Ereignisse, mit Jitter, Backoff, Quotas und Pagination. - Commit-Frequenz ist **kein** Discovery-Signal. Normale Commits werden nicht global gepusht. - Explizite `repository.published`, `release.announced`, `repository.star`, `repository.follow` und `organization.attested` als getrennte Ereignistypen. - Deduplizierung per kanonischem Ereignishash; Versionierung, TTL/Retention und Anti-Spam-Mechanismen. - Publisher-Zeitstempel sind **Behauptungen**; Hash beweist Unverändertheit, nicht objektive Uhrzeit. Peer-Empfangsbelege und Hash-Ketten können Beobachtungen und relative Reihenfolgen belegen, ohne absolute Zeit zu garantieren. ### 7.3 Sterne und Vertrauen - Ein signierter Stern pro Identität und Repo; Entzug möglich. - Sybil-Risiko: tausende Schlüssel können tausende Stimmen erzeugen. Sterne transparent zählen, lokales Ranking mit nachvollziehbaren Vertrauenssignalen und Anti-Spam ergänzen. - Kritische Updates nicht nur nach Popularität filtern; auch kleine Projekte können wichtige Sicherheitsupdates haben. - Kategorien: Publisher-Angabe, technische Analyse und signierte Community-Vorschläge getrennt speichern. --- ## 8. KI, MCP, Zusammenarbeit und Buzz ### 8.1 Native AI Bridge - MCP als standardisierte Schnittstelle für Lesen/Suchen und später autorisierte Vorschläge. - Read-only als Standard; keine impliziten Shell-Rechte, kein automatischer Merge in geschützte Branches. - Agenten besitzen eigene Identitäten, zeitlich und sachlich begrenzte Delegationen, Audit-Trail und Widerruf. - Lokaler Agent im Heimnetz, Agent auf VPS oder externe KI-Dienste sind austauschbar. - Kein verpflichtendes LLM, keine GPU- oder Cloud-Abhängigkeit im Core. ### 8.2 Kollaborative Workspaces - Gruppen aus Entwicklern und Agenten; Repositories anheften, Aufgaben erstellen, zuweisen, diskutieren und signiert reviewen. - Eigene Eventtypen z. B. `workspace.created`, `workspace.repo.pinned`, `task.created`, `proposal.submitted`, `review.signed`. - Private Workspaces erfordern E2EE und Gruppen-Schlüsselmanagement. - Agentenergebnisse sind untrusted Input; Prompt Injection, Dateizugriffe, Secret-Leaks und Test-Sandboxing berücksichtigen. ### 8.3 Buzz-Integration - **Optionaler Adapter**, keine Core-Abhängigkeit. - Buzz-/Nostr-Ereignisse auf Decentralhub-Workspace-Objekte abbilden; nicht annehmen, dass Buzz das native Decentralhub-Repository-Format direkt versteht. - Vor Implementierung aktuelle Buzz-Lizenz, API, Protokollstand und Wartungsstatus erneut prüfen. - Externe Agenten erhalten nur explizit freigegebene Rechte; kein automatischer Remote-Code-Execution-Pfad. --- ## 9. Frontend- und UX-Anforderungen ### 9.1 Navigation `Discover` · `Meine Repositories` · `Workspaces` · `Aktivität` · `Profil` · `Organisationen` · `Einstellungen`. ### 9.2 Header-Status (sichtbar und wahrheitsgemäß) - `Offline-Modus`: kein erreichbarer Peer, lokale Arbeit möglich. - `Intranet-Modus`: LAN-Peers erreichbar, keine öffentliche Föderation. - `Netzwerk verbunden`: föderierte Peers erreichbar. - `Synchronisierung läuft`: Queue/Abgleich aktiv. - `Synchronisierung ausstehend`: lokale Commits warten auf Upload. - `Fehler / eingeschränkt`: Peers erreichbar, aber Auth-/Sync-Fehler. **Wichtig:** „Offline“ nicht allein aus fehlendem Internet ableiten; Netzwerkzustand, bewusst deaktivierte Synchronisierung und lokale Caches separat anzeigen. Discovery nennt `Zuletzt synchronisiert: ...` und zeigt Cache-Einträge als möglicherweise veraltet. ### 9.3 Einsteiger-Workflow 1. Anwendung starten, lokal nutzbar ohne Registrierung. 2. Identität erstellen oder importieren, Recovery-Hinweise anzeigen. 3. `Neues privates Repository` oder `Bestehenden Ordner öffnen`. 4. Dateiänderungen sehen, Commit erstellen, Historie durchsuchen. 5. Optional `Mit Node verbinden` (eigener Heimserver, VPS, Team-Node). 6. Optional `Projekt veröffentlichen` mit Vorschau auf Sichtbarkeit. 7. Optional `Spenden aktivieren`, `Wallet verbinden`, `Organisation anlegen`. ### 9.4 Profiloberfläche **Persönliches Profil:** Anzeigename, Bio, signierte Entwickler-ID, Domains, Repositories, Sterne, Follows, Agenten, freiwillige Zahlungswege. **Firmenprofil:** Name, Rechtsform/Land, Impressum (Link/Datei/Formular), Domains, Register-/Prüfnachweise, Team, Repositories, Spenden-/Finanzierungswege. **Verifikations-Badges:** präzise benannt, z. B. `Domain bestätigt`, `Registerdaten geprüft durch X am Y`, niemals unqualifiziert `Verifiziert`. ### 9.5 Barrierefreiheit und Internationalisierung - Tastaturbedienung, sichtbare Fokuszustände, Screenreader-Beschriftungen, Kontrast, mobile Darstellung. - Fehlermeldungen handlungsorientiert, ohne Interna/Secrets zu leaken. - Datum/Zeit mit Zeitzone, Status verständlich für Nicht-Linux-Nutzer. - Keine Pflicht, CLI oder Docker zu verstehen; Web-UI und später Desktop-UI. --- ## 10. Sicherheit, Datenschutz und Betrieb ### 10.1 Mindest-Sicherheitsanforderungen vor öffentlichem Betrieb - Threat Model: untrusted Peers, manipulierte Objekte, Sybil/Spam, SSRF, DoS, Replay, Privilegieneskalation, Wallet-Phishing, kompromittierte Agenten, Datenabfluss, Supply Chain. - Authentisierte und autorisierte Schreib-Endpunkte; deny-by-default, Least Privilege. - HTTP-Server: sichere Timeouts, Header- und Body-Limits, Request-Quotas, sichere Pfadbehandlung, TLS-/Reverse-Proxy-Anleitung, keine offenen Proxies. - SSRF-Schutz bei Peer-/Webhook-/URL-Abrufen inklusive DNS-Rebinding, Redirects, privaten IP-Ranges und Hostname-Validierung. - Persistenz: atomare Updates, Crash Recovery, Mehrprozess-Sperren, Quotas, Backup/Restore und Migrationsprüfungen. - Private Daten: keine Metadatenlecks in Discovery, Logs, Telemetrie, Fehlermeldungen oder Replikation. - Verschlüsselung und Key Management für private Remote-Repositories und Workspaces. - Signierte Releases, überprüfbare Build-Provenienz, SBOM und Update-Rollback. - Cross-Platform-Tests unter echten Windows-/Linux-Umgebungen, nicht nur Cross-Compilation. - Externes Security Review vor Produktionsfreigabe; dokumentierter Disclosure-Prozess. ### 10.2 Privacy-by-default - Keine obligatorische zentrale Registrierung, keine standardmäßige Telemetrie. - Wallet-Adressen, Firmenanschriften, Zahlungsverknüpfungen und öffentliche Profile nur nach bewusstem Opt-in. - Datensparsamkeit und klarer Hinweis: Öffentlich replizierte Inhalte sind ggf. nicht vollständig löschbar. - Auskunft, Export, lokale Löschung, Widerruf und Aufbewahrung differenziert nach lokalem Node und öffentlichem P2P-Netz erklären. ### 10.3 Recht und Compliance als Produktanforderung - Wallet-Login ist nicht gleich Zahlungsabwicklung. - Bei Spenden: steuerliche Einordnung, Quittungen, Gebühren, Verbraucherschutz, KYC/AML-Pflichten und regionale Zahlungsdienstregeln prüfen, falls das Produkt später Gelder verarbeitet. - Bei Firmen: länderspezifische Impressums-/Anbieterkennzeichnungspflichten, Datenschutz, Unternehmensregister, irreführende Verifikationsclaims. - Bei Code: Lizenz- und Urheberrechtsnachweise; Attribution ersetzt keine Lizenzberechtigung. - Keine verbindliche rechtliche Aussage ohne fachliche Prüfung im Zielmarkt. --- ## 11. Priorisierte Roadmap und Abnahmekriterien ### Phase P0 — Fundament stabilisieren (höchste Priorität) **Arbeiten:** Bestandscode-Audit, formale Objekt-/Event-Spezifikation, sichere lokale Transaktionen, Ref-Updates, sichere Schlüsselverwaltung, Testmatrix. **Fertig, wenn:** Offline-Repos auch nach Crash konsistent sind; beschädigte Objekte erkannt werden; keine Secrets in Logs; Linux-/Windows-CLI-End-to-End-Tests; dokumentierte Datenmigration. ### Phase P1 — echter Remote-Workflow **Arbeiten:** authentifiziertes `clone/fetch/push/pull`, ACLs, Hash-Verifikation, begrenzte Chunk-Uploads, Compare-and-Swap-Refs, Sync-Queue und Konfliktbehandlung. **Fertig, wenn:** Windows-PC offline committen kann, anschließend auf privaten Linux-Heimserver pusht, zweiter Client fetcht und Inhalte verifiziert; unautorisierte Schreibversuche scheitern; divergierende Historien bleiben erhalten. ### Phase P2 — private Repos und Multi-Device **Arbeiten:** Schlüssel-Delegation/Widerruf, private Remote-Repos, E2EE, Teamrollen, Backup/Restore, sichere Geräteanmeldung. **Fertig, wenn:** Nichtautorisierte Peers weder Inhalte noch vertrauliche Metadaten sehen; Gerätewiderruf nach definiertem Bedrohungsmodell funktioniert; Recovery getestet. ### Phase P3 — öffentliches Discovery-Netz **Arbeiten:** sichere Peer-Verwaltung, Gossip, Anti-Entropy, Dedupe, Feed-Trennung, Kategorieabos, Sterne/Follows, Abuse-Handling. **Fertig, wenn:** 1.000 schnelle Commits keinen Discover-Sturm auslösen; ein erstmalig publiziertes Repo nur einmal im Neu-Feed erscheint; Offline-Nodes nach Rückkehr aufholen; Sybil-/Spam-Limits dokumentiert. ### Phase P4 — Profile, Firmen, Spenden (neuer Schwerpunkt) **Arbeiten:** signierte Profil- und Zahlungsmetadaten, BTC/BCH/BSV-Adressdarstellung, externe Checkout-Links, Impressum-Link/Datei/Formular, Domain-Challenge, transparente Verifikationsstufen. **Fertig, wenn:** Profilinhaber Zahlungsdaten signiert ändern kann; Clients Netzwerk und Adresse korrekt kennzeichnen; fremde Peers keine Zahlungsadressen austauschen können; Firmen-UI keinen ungeprüften Verifizierungsstatus behauptet. ### Phase P5 — Wallet-Authentisierung **Arbeiten:** Wallet-Kompatibilitätsmatrix, Signaturadapter für BTC/BCH/BSV, Challenge-Response, Replay-Tests, Konto-Verknüpfung/-Entknüpfung, Recovery. **Fertig, wenn:** Für **jede** freigegebene Wallet-/Netzwerk-Kombination positive und negative Testvektoren existieren, Netzwerkverwechslung/Replay abgewehrt sind und kein Private Key den Client verlässt. Nicht unterstützte Wallets werden klar abgelehnt. ### Phase P6 — KI-Kollaboration **Arbeiten:** MCP-Konformität, Agenten-Capabilities, signierte Proposals/Reviews, Workspace, optionaler Buzz-/Nostr-Adapter. **Fertig, wenn:** Agenten ohne Freigabe weder schreiben noch Tests auf dem Host ausführen können; menschliche Reviews nachvollziehbar sind; ein Ausfall von Buzz keine Core-Funktion lahmlegt. ### Phase P7 — Produktionsfreigabe **Arbeiten:** Performance-/Lasttests, unabhängiger Security-Audit, Betriebshandbuch, Reproduzierbarkeit, signierte Releases, Monitoring ohne Privacy-Leak, Disaster Recovery, Upgrade-/Rollback-Tests. **Fertig, wenn:** alle kritischen Findings behoben und dokumentierte SLOs im Test nachgewiesen sind. **Erst dann** `production-ready` behaupten. --- ## 12. Konkrete Codex-Tickets (in dieser Reihenfolge) | ID | Ticket | Priorität | Definition of Done | |---|---|---|---| | DH-001 | Codebasis inventarisieren, Sicherheitsrisiken reproduzieren | P0 | reproduzierbare Findings + Tests | | DH-002 | Kanonisches Objektformat und Hash-Domain-Separation spezifizieren | P0 | Testvektoren, Parser-Limits, Versionsregeln | | DH-003 | Lokalen Objektspeicher crash-sicher machen | P0 | Fault-Injection- und Recovery-Tests | | DH-004 | Signierte Identitäten, Geräte-Delegation und AuthZ-Grundlagen | P0 | Replay-/Revocation-Tests | | DH-005 | `dh clone/fetch/push/pull` zwischen Windows und Linux | P0 | E2E-Test mit zwei Clients und Node | | DH-006 | Private Repos und explizite Freigabe | P0 | kein Metadatenleck, ACL-Negativtests | | DH-007 | Verbindungsstatus im Header und Offline-Queue | P1 | Offline/Intranet/Online/Sync unterscheidbar | | DH-008 | Discovery-Feed-Trennung, Batching und Dedupe | P1 | 1.000 Commits ≠ 1.000 Feed-Einträge | | DH-009 | Signierte Entwickler- und Firmenprofile | P1 | Änderungen nur durch autorisierte Identität | | DH-010 | Impressum per URL, Datei oder Formular | P1 | klare Unterscheidung Angabe vs. Verifikation | | DH-011 | Spendenprofile: BTC, BCH, BSV, Bank, PayPal, Kartenlinks | P1 | Chain-Validierung, keine Secrets/PCI-Daten | | DH-012 | Domain-Verifikation und Attestationsmodell | P2 | Ablauf, Widerruf, Scope, Prüfer sichtbar | | DH-013 | Wallet-Login BTC/BCH/BSV | P2 | getestete Adapter + Replay-/Chain-Tests | | DH-014 | Agenten-Workspaces und MCP-Rechte | P2 | least privilege, Audit und Review | | DH-015 | Optionaler Buzz-/Nostr-Adapter | P3 | isoliert, deaktivierbar, Core unabhängig | | DH-016 | Release-Härtung, Sicherheitsprüfung und Betriebsfreigabe | P0 vor Release | reproduzierbare Builds, Audit, Runbook | **Codex soll zuerst DH-001 durchführen**, danach DH-002 bis DH-005 implementieren und jeweils einen prüfbaren Zwischenstand liefern. Zahlungs-/Wallet-Funktionen nicht vorziehen, solange Remote-AuthZ und Schlüsselverwaltung unsicher sind. --- ## 13. API- und Protokollleitplanken ### 13.1 Protokollfamilien (Arbeitstitel, keine bestehenden Standards) - `DIP`: Identity Protocol — Entwickler-/Organisationsidentitäten, Delegation, Widerruf. - `DOP`: Object Protocol — Blob/Tree/Commit/Ref/Proposal. - `DDP`: Discovery Protocol — Publish/Release/Star/Follow/Gossip. - `DAP`: Attribution Protocol — signierte Herkunfts-/Lizenzbeziehungen. - `DVP`: Verification Protocol — Prüfberichte, signierte Reviews, Attestierungen. - `DPP` (neu, Arbeitstitel): Profile & Payments — Profile, Wallet-Verknüpfungen, Zahlungsmetadaten. Jedes Protokoll benötigt `version`, Schema, Canonical Encoding, Hashing, Signaturkontext, Fehlercodes, Grenzen, Kompatibilitätsregeln und Testvektoren. Eine öffentliche URL/JSON-Struktur ist zunächst **experimentell**, bis diese Punkte dokumentiert sind. ### 13.2 Entwurfsbeispiel: Wallet-Challenge ```json { "schema": "dh.wallet-challenge/1", "challenge_id": "", "nonce": "", "action": "link_wallet", "network": "bch", "identity_id": "dh:id:example", "origin": "https://node.example.invalid", "audience": "decentralhub-wallet-auth", "issued_at": "2026-10-24T00:00:00Z", "expires_at": "2026-10-24T00:05:00Z" } ``` **Nicht als fertige Wallet-Signiernachricht verwenden.** Das genaue Serialisierungs- und Signaturformat muss je Netzwerk/Wallet-Adapter definiert und getestet werden. ### 13.3 Entwurfsbeispiel: signierte Attestierung ```json { "schema": "dh.attestation/1", "subject": "dh:org:example", "claim": "legal_registry_match", "issuer": "dh:id:auditor-example", "evidence_reference": "", "verified_at": "2026-10-24T00:00:00Z", "expires_at": "2027-10-24T00:00:00Z", "scope": "registered-name-and-register-number", "signature": "" } ``` --- ## 14. Testszenarien, die Codex nicht übersehen darf 1. **Offline:** Netzwerk vollständig deaktiviert; Init, Commit, Log, Verify, Export funktionieren. 2. **Windows:** Pfade mit Leerzeichen, Unicode, Groß-/Kleinschreibung, reservierte Namen und lange Pfade testen. 3. **Private Daten:** Keine privaten Repo-Namen/Hashes/Dateinamen in öffentlichen Discovery-Events. 4. **Konflikt:** Zwei Geräte committen offline auf denselben Branch; Push verliert keine Historie. 5. **Manipulation:** Blob-Inhalt geändert; Verify und Fetch lehnen ab. 6. **Crash:** Stromausfall während Commit/Ref-Update; alter oder neuer Zustand bleibt konsistent. 7. **DoS:** Viele große/fehlerhafte Requests; Grenzen und Quotas greifen. 8. **SSRF:** Peer-URL zeigt auf Loopback, Link-local, private IP oder DNS-Rebinding; öffentliche Fetch-Routen blockieren unerlaubte Ziele. 9. **Discovery:** 1.000 Commits in einer Minute; keine Feed-Spam-Welle. 10. **Wallet:** BTC-Signatur für BCH-Challenge bzw. andere Origin/Nonce wiederverwendet; Verifikation scheitert. 11. **Wallet:** Unbekanntes Signaturformat und Watch-only-Adresse; keine falsche Besitzbestätigung. 12. **Spenden:** BSV-Adresse als BCH-Adresse ausgegeben; UI/API muss Netzwerkverwechslung verhindern. 13. **Zahlungsprofil:** Fremder Peer manipuliert PayPal-/Bank-/Kryptoadresse; Signaturprüfung schlägt fehl. 14. **Firmenstatus:** Nur Impressumslink vorhanden; UI darf kein „rechtlich verifiziert“ zeigen. 15. **Firmenstatus:** Prüfer-Attestierung abgelaufen oder widerrufen; Badge aktualisiert sich. 16. **MCP:** Agent versucht Schreiboperation ohne Capability; Ablehnung und Audit. 17. **Netzwerkstatus:** Nur LAN-Peers erreichbar; UI zeigt Intranet statt irreführend „voll online“. 18. **Upgrade:** Migration und Rollback mit echten Alt-Daten; keine stillen Datenverluste. --- ## 15. Weitere sinnvolle Ergänzungen **Hoher Nutzwert:** - **Geräteverwaltung und Recovery-Dashboard:** aktive Geräte, Schlüssel, Widerrufe und Sicherheitsereignisse. - **Verifizierbare Releases:** signierte Artefakte, reproduzierbare Builds, SBOM, Sicherheitsberichte. - **Abhängigkeits-/Lizenzansicht:** native Attribution und Hinweise auf Lizenzpflichten. - **Issue-Bounties und Förderziele:** zunächst nur Metadaten und externe Zahlungslinks, keine treuhänderische Geldverwaltung. - **Mirror-/Backup-Status:** wo liegen Replikate, wann zuletzt geprüft, wie aktuell sind sie? - **Org-Teamrollen:** mehrere Maintainer, Freigaberegeln und Notfall-Widerruf. - **Import/Export:** später optionaler Git-Import/Export als Adapter, ohne Git als Core-Abhängigkeit; erleichtert Migration. - **CI/Tests als opt-in, isolierter Dienst:** niemals Code aus fremden Repos direkt im Node-Prozess ausführen. - **Sicherheitsmeldungen:** signierte Advisories, verantwortliche Offenlegung, optionale Benachrichtigungen an Follower. - **Projektfinanzierung:** monatliche Sponsoring-Links, Transparenzziele und Unternehmensförderer, ohne zentrale Zahlungsabwicklung. **Nicht vorschnell bauen:** Eigene Blockchain, universeller Wallet-Signer, eigene Kryptoprimitiven, eigener Kartenprozessor, verpflichtendes LLM, globaler Trust-Score, globaler Moderations- oder Namensregistrierungsserver. --- ## 16. Sofort einsetzbarer Codex-Arbeitsauftrag > Du arbeitest an Decentralhub. Lies zuerst das vorhandene Repository und die Datei `DECENTRALHUB_CODEX_MASTERPLAN.md`. Verifiziere den tatsächlichen Implementierungsstand, statt den Masterplan als bereits umgesetzt anzusehen. Starte mit DH-001: erstelle eine Bestandsaufnahme mit Modulübersicht, kritischen Sicherheitsrisiken, offenen Tests und Migrationsbedarf. Implementiere danach DH-002 und DH-003 in kleinen, reviewbaren Änderungen: ein spezifiziertes, kanonisches Objektformat mit Testvektoren sowie crash-sichere lokale Speicherung. Bewahre die Offline-Funktionalität, die vorhandene CLI und bestehende Daten nach Möglichkeit. Führe `go test ./...`, `go test -race ./...`, `go vet ./...` und Cross-Builds aus. Berichte exakt, welche Tests ausgeführt wurden, was noch nicht funktioniert und welche Risiken offen sind. Keine öffentliche Produktionsfreigabe ohne AuthZ-, Persistenz- und Security-Härtung. Wallet-Login, Spenden und Firmenverifikation zunächst nur als Schnittstellen-/Datenmodelle spezifizieren; keine ungetesteten kryptografischen Signaturverfahren implementieren. --- ## 17. Entscheidungsprotokoll: festgelegt vs. offen ### Festgelegt - Offline-first, private-by-default, self-hosted und föderierbar. - Linux als primäre Dauer-Node-Plattform; Windows-Entwickler benötigen keinen Linux-Server. - Native, Git-unabhängige Repository-Grundlage; optionale Adapter zulässig. - Domainunabhängige kryptografische Identitäten; eigene Domain optional. - Signierte Discovery-Events, getrennte Neu-/Update-Feeds, kein Commit-Spam. - MCP im Core als Schnittstelle; KI-Agenten und Buzz optional. - Profile für Entwickler und Organisationen; BTC/BCH/BSV plus gängige Fiat-Zahlungswege als **optionale** Spendenmethoden. - Firmen-Impressum via Link, Datei oder Formular; Rechtsverifikation nicht automatisch durch Selbstangabe. ### Noch zu entscheiden / zu erforschen - Exakte Byte-Kodierung, Hash-Algorithmus-Versionierung und Repo-ID-Schema. - Schlüsselverwaltung pro Betriebssystem und Recovery-Modell. - Verschlüsselungsmodell für private Multi-Device-Repositories. - Peer-Bootstrap, NAT-Traversal und Replikationspolitik. - Konkrete Wallet-Kompatibilitätsmatrix für BTC/BCH/BSV; unterstützte Signaturverfahren pro Wallet. - Welche externen PSP-/Bank-/PayPal-Integrationen zuerst und in welchen Ländern angeboten werden. - Welcher unabhängige Prüfer bzw. welches Trust-Modell rechtliche Unternehmensverifikation attestieren darf. - Umfang und Stabilität einer Buzz-/Nostr-Anbindung. - Reale Ressourcenlimits und Betriebs-SLOs nach Lasttests. **Ende des Masterplans.**