# MeshForge — Codex-Spezifikation: Bootstrap, Releases und Governance

**Stand:** 25.10.2026 · **Status:** Zielarchitektur, nicht implementiert  
**Software:** MeshForge · **Initiator:** SteveCo AI · **Portfolio:** decentrealhub.de  
**Pflichttext im Webfrontend:** `Initialised by SteveCo AI` (exakt, sichtbar im Footer/About der Standardoberfläche).

> Diese Datei ergänzt `DECENTRALHUB_CODEX_MASTERPLAN.md`. Der neue Produktname ist **MeshForge**. `decentrealhub.de` ist eine Projekt-/Portfolio-Domain, keine zwingende Infrastrukturabhängigkeit.

## 1. Verbindlicher Codex-Arbeitsauftrag

- Zuerst vorhandene Go-Quellen, Tests, README und SECURITY lesen. Das bisherige v1.0.0-Archiv ist ausdrücklich **Development Preview**, nicht produktionsreif. Es unterstützt lokale Snapshots, signierte Discovery-Metadaten und experimentelle Peer-Synchronisierung, **aber kein sicheres Remote-Clone/Push/Pull**.
- Nicht vorhandene Features nicht als implementiert ausgeben. Vor jeder Änderung Tests und Sicherheitsgrenzen spezifizieren. In kleinen, reviewbaren Schritten implementieren; keine Komplett-Neuschreibung ohne Grund.
- Go-Standardbibliothek bevorzugen; keine eigene Kryptografie erfinden. Wo Sicherheit ohne geprüfte Bibliothek nicht vertretbar ist, Feature blockieren und Entscheidung dokumentieren.
- Offline-first, private-by-default. Keine Metadaten privater Repositories ungefragt verbreiten. Kein automatisches Ausführen fremden Codes oder ungeprüfter Updates.
- Nach jedem Schritt: `go test ./...`, `go test -race ./...` soweit verfügbar, `go vet ./...`, Linux-/Windows-Cross-Builds und gezielte E2E-Tests. Ergebnisse und nicht ausgeführte Tests dokumentieren.

## 2. Marken- und Frontend-Vorgaben

- MeshForge: Produktname, CLI/Server, Repo-Protokoll, Discovery und Release-Verifikation.
- SteveCo AI: Initiator. Der Text **`Initialised by SteveCo AI`** muss in der standardmäßigen öffentlichen Weboberfläche erscheinen (Startseite, Repository-Ansichten, About; vorzugsweise Footer). Exakte Schreibweise, nicht automatisch übersetzen. Er ist keine Aussage, dass SteveCo AI fremde Repositories besitzt.
- Decentrealhub (`decentrealhub.de`): Präsentation der eigenen Projekte, optionaler Einstiegspunkt, **kein** verpflichtender Login-, Update- oder Bootstrap-Server.
- CLI-Namen als Ziel `mf` für Entwickler und `meshforge` für Node; alte `decentralhub`-Befehle nur mit dokumentiertem Migrationspfad ändern.
- Frontend: minimalistische Templates/Vanilla JS, responsiv, barrierearm, Deutsch/Englisch; sichtbare Statusanzeige `Offline-Modus`, `Intranet-Modus`, `Netzwerk verbunden`, `Synchronisierung`, `Netzwerk gestört` anhand tatsächlicher Konnektivität. Lokaler Discover-Cache muss als unvollständig/alt erkennbar sein.

## 3. Peer-Origin Bootstrap

**Idee:** Nutzer laden MeshForge von einem bereits erreichbaren MeshForge-Peer herunter. Die Downloadquelle dient als **erster Peer-Kandidat**. Nach der Installation kann der Client weitere Peer-Kandidaten abfragen und sich unabhängig vom Ursprung vernetzen.

**Sicherer Ablauf:**
1. Einen minimalen Installer/Verifier **vor der Ausführung** anhand separat bekannter, vertrauenswürdiger Release-Schlüssel und signierter Manifeste prüfen. Ein unbekannter Download-Peer darf den vertrauenswürdigen Root-Key **nicht selbst festlegen**.
2. Signierte und zeitlich begrenzte Bootstrap-Metadaten von `/.well-known/meshforge/bootstrap.json` laden. Felder: Protokollversion, Peer-ID, URL(s), Netzkennung, Ablaufzeit, signierende Identität, höchstens begrenzte Anzahl Peer-Kandidaten. Signatur über kanonisch serialisierte Daten.
3. Peer-Kandidaten zunächst **nicht** als vertrauenswürdig markieren. Peer-ID gegen Signaturen/Handshake prüfen; Adressen gegen SSRF, interne IP-Ziele (bei öffentlichen Peers), DNS-Rebinding, Timeouts, Größe, Rate Limits und Weiterleitungsketten absichern. Intranet-Discovery als separate Option behandeln.
4. Kandidaten aus möglichst unabhängigen Quellen auswählen; nicht ausschließlich die vom Ursprung vorgeschlagenen Peers kontaktieren (Eclipse-Angriff). Peerstore persistent mit ID, Adressen, Provenienz, Beobachtungszeit, Erreichbarkeit, Warnungen.
5. Gossip von signierten Event-IDs, Nachladen unbekannter Events, Anti-Entropy-Abgleich in Intervallen mit Backoff/Jitter. **Keine** ständige Vollabfrage aller Peers.
6. Offline-Installation bleibt möglich. Ein Knoten ohne Kontakte kann das globale Netz nicht aus dem Nichts finden. Isolierte Intranet-Knoten sind **nicht automatisch bösartig**.

## 4. Distributed Release Verification (DRC)

**Zwei unabhängige Signale:**
- **Release-Verbreitung:** Wie viele beobachtete Peers bieten einen bestimmten Hash an? Nur Verfügbarkeits-/Anomalieindikator, leicht per Sybil-Farm manipulierbar.
- **Release-Authentizität:** Stimmen Hash, signiertes Release-Manifest, gültige Maintainer-Delegationen, notwendige Schwellenfreigaben und lokale Update-Policy überein?

**Harte Regel:** Niemals die von den meisten Peers angebotene Version allein deshalb als Standard installieren. Die neueste **autorisierte und kompatible** Version auswählen. Ein Release mit 100 Peers kann gültig, einer mit 10.000 manipulierten Peers ungültig sein.

Release-Manifest (Version 1 spezifizieren): Quellrevision, Release-Version, Plattform/Architektur, Binärhash, Protokollkompatibilität, signierte Freigaben, vorherige autorisierte Version/Checkpoint, Ablauf, Build-Provenienz. Root-/Maintainer-Schlüssel und Rotation müssen gegen Rollback, Freeze und Kompromittierung geschützt werden. Release-Artefakte dürfen über beliebige Peers transportiert werden, solange sie lokal verifiziert werden.

**Gründeridentität:** Öffentlicher kryptografischer Fingerabdruck des SteveCo-AI-Initiators als *anfänglicher* Vertrauensanker. **Nicht** nur in einem beliebigen Installer mitliefern: Fingerabdruck muss über unabhängigen Kanal prüfbar sein. Langfristig verteilte Freigabeautorität und Notfall-Recovery ermöglichen.

## 5. Governance: Qualität statt Mehrheitsabstimmung

**Ziel:** Keine Bot-Demokratie, kein Unternehmensmonopol und keine Bürokratie für triviale Änderungen.

### 5.1 Stufen

- **Phase A: Gründergeführt.** Kleine Gruppe autorisierter Maintainer signiert Releases. Alle dürfen Issues, Tests und Patches einreichen.
- **Phase B: Maintainergeführt.** Übergang erst nach dokumentierten Reifekriterien: unabhängige Maintainer, Betriebsdauer, überprüfte Sicherheitsprozesse, wiederholt erfolgreiche Releases. **Nicht** automatisch nach Peerzahl/Sternen.
- **Phase C: Verteilt.** Versioniertes, signiertes Governance-Manifest mit unabhängigen Release-Freigaben, transparenten Rollen und lokalen Update-Policies. Keine automatische „51 % der Peers“-Regel.

### 5.2 Review und Zeitfenster

| Änderung | Vorschlag für Review | Vorschlag für Mindestfenster |
|---|---|---|
| Dokumentation/UI | 1 Maintainer + Tests | 24 h |
| Normale Funktion/Bugfix | 2 Maintainer + Regressionstests | 72 h |
| Kryptografie, Identität, Update, Peer-Vertrauen | 3 qualifizierte Freigaben aus mindestens 2 unabhängigen Gruppen + Sicherheitsprüfung | 7 Tage |

Werte sind **Startvorschläge**, nicht automatisch sichere Garantien. Für aktiv ausgenutzte Schwachstellen einen separaten, streng kontrollierten Notfallpfad entwerfen. Das Zeitfenster bezieht sich auf **exakt denselben Kandidatenhash**; jede inhaltliche Änderung startet die betroffenen Prüfungen erneut. Abgelehnte Patches müssen nicht immer wieder dieselben Prüfschleifen auslösen.

### 5.3 Rollen und Diskussionsgewicht

- Signierte Kommentare von verifizierten Unternehmen und großen Betreibern sichtbar hervorheben, inklusive nachvollziehbarer Betriebserfahrung und Testbelege. **Unternehmensgröße allein verleiht keine Release-Stimmrechte.**
- Verifizierte Firmenidentität, Domainkontrolle und technische Kompetenz sind getrennte Attribute. Impressum-Link ist **keine** amtliche Unternehmensverifikation.
- Community-Sterne, Popularität und KI-Kommentare sind **Meinungssignale**, keine autorisierenden Signaturen. Review-Autorität muss explizit delegiert werden.
- KI-Agenten dürfen Patches und Tests einreichen, aber nicht allein durch Anzahl ihrer Identitäten einen Release autorisieren. Ihre Ergebnisse müssen nachvollziehbar und möglichst reproduzierbar sein.
- Interessenkonflikte und Organisationszugehörigkeiten offenlegen; Freigaben aus mehreren unabhängigen Gruppen anstreben. Die tatsächliche Unabhängigkeit ist nicht allein kryptografisch beweisbar.
- Transparente Diskussion ohne Zwang zu Abstimmungen für jede Kleinigkeit; risikobasierte Prozessstufen und klar definierte Maintainer-Verantwortung.

### 5.4 Governance-Manifest

Versioniertes, signiertes Dokument mit Phase, Rollen, Schlüsseln, Delegationen, Risikoklassen, Review-Fristen, Quoren, Notfallverfahren und Aktivierungsregeln. Änderungen an Governance-/Root-Key-Regeln erfordern **strengere** Prüfung als normale Releases. Jeder Knoten behält die letzte Entscheidung über Updates.

## 6. Produktgrundsätze aus den bisherigen Entscheidungen

- **Eigene Repo-IDs statt Domainbindung:** `mf:repo:<hash>` (schematisch). Eigene Entwicklerdomain als HTTPS-Zugang, jeder autorisierte Peer kann bei Replikation denselben Inhalt bereitstellen.
- **Offline-first:** native, Git-unabhängige Objekte, Snapshots/Commits/Branches, sichere Merge-/Konfliktlogik, später authentifizierte Remote-Synchronisierung. Windows-CLI ohne Linux/WSL, Linux-Node auf VPS, Heimserver oder NAS.
- **Private-by-default:** private/intranet/public mit klaren Berechtigungen; private Metadaten und Dateien nicht ins globale Discovery-Netz.
- **Discovery/Pulse:** neue Repos nur einmal in „Neu“; Commits pushen sie nicht wieder nach oben. Separate Feeds für wichtige Releases und beliebte Projekte; Sterne/Follows signiert, nicht als Sybil-sichere Wahlen missverstehen. Push/Gossip für Ereignisse, Batch/Debounce und gelegentlicher Abgleich statt Dauerpolling.
- **Attribution:** signierte Verweise `inspired_by`, `derived_from`, `depends_on`, `forked_from`, `improves_on`, `fixes`; Herkunftsangabe ersetzt keine Lizenzprüfung.
- **MCP/AI Bridge:** kleine native MCP-Schnittstelle, zunächst lesend; optionale lokale/VPS-Agenten mit granularen Rechten. Kein eingebauter Zwangs-LLM, keine ungeprüfte Codeausführung.
- **Workspaces/Buzz:** Agenten und Menschen können Repos anheften, Aufgaben, Reviews und Diskussionen verwalten; Buzz/Nostr nur als optionaler Adapter nach API-/Lizenzprüfung.
- **Identität:** Ed25519-Entwickleridentität, gerätespezifische Schlüssel, Rotation/Widerruf/Recovery; Signaturen beweisen Schlüsselkontrolle, nicht automatisch reale Identität.
- **Wallets/Spenden:** BTC, BCH, BSV optional als getrennte Wallet-Credentials; signierte Challenge pro Chain korrekt spezifizieren. Spendenadressen, SEPA/Banküberweisung, PayPal und Karten über externe Anbieter; keine private Wallet-Seeds oder Kartendaten im MeshForge-Core speichern.
- **Firmenprofile:** Impressumslink, signierte Datei oder geführtes Formular; klare Stufen „selbst angegeben“, „Domain kontrolliert“, „extern verifiziert“. Datenschutz und länderspezifische Rechtsanforderungen berücksichtigen.

## 7. Priorisierte Umsetzungstickets für Codex

**P0 — vor öffentlichem Betrieb**
1. Inventar, Namensmigration und Branding inklusive exakt `Initialised by SteveCo AI` mit Frontend-Test.
2. Sichere Speicherung, atomare Objekte, Crash-/Concurrent-Writer-Tests und Private-by-default-Invarianten.
3. Lokaler Identity-Key-Store mit sicheren Defaults; Geräte-/Schlüsselkonzept spezifizieren.
4. Authentifizierte und autorisierte Remote-Clone/Push/Pull-E2E-Strecke Windows ↔ Linux, inklusive Konfliktfall.
5. Öffentliche HTTP-/MCP-Endpunkte härten: Auth, Limits, Timeouts, SSRF-Schutz, Replay, Quoten, Logging ohne Secrets.

**P1 — Netzwerk- und Release-Vertrauen**
6. Peerstore, signierter Bootstrap-Entwurf, Peer-Origin Installer-Verifikationskonzept und Tests gegen manipulierte Peerlisten.
7. Peer Exchange, Gossip, Anti-Entropy, LAN-Modus und realer Verbindungsstatus.
8. Signierte Release-Manifeste, Root-Key-/Maintainer-Delegationen, Verifikation **vor** Installation, Rollback-Schutz.
9. Governance-Manifest, risikobasierte Reviews, signierte Testbelege, definierte Notfall-Freigabe.

**P2 — Produktfunktionen**
10. Discover/Pulse mit getrennten Feeds, Kategorisierung, Sterne/Follows und Rate Limits.
11. Attribution, Issues, Reviews, Workspaces und agentische Berechtigungen.
12. Wallet-Verknüpfungen, Spenden und Firmenverifikation in klar getrennten optionalen Modulen.
13. Buzz-/Nostr-Adapter nach Upstream-Prüfung.

## 8. Abnahmekriterien und Negativtests

- Offline-Client kann Repository erstellen, committen, prüfen und exportieren, ohne Netzwerkverbindung oder Metadatenabfluss.
- Zwei Geräte können mit signierten Identitäten einen privaten Repo-Stand über einen autorisierten Linux-Node synchronisieren; unautorisierter Peer erhält weder Inhalt noch sensible Metadaten.
- Manipulierte Binärdatei oder Release-Signatur wird **vor Ausführung** abgewiesen; Peermehrheit kann Freigabe nicht ersetzen.
- 1.000 künstliche Peers dürfen keinen unautorisierten Release als gültig markieren; Verbindungsgraph und bekannte Peer-IDs sind nur Hinweise.
- Neue Installation kann Origin-Peer und unabhängige weitere Peers entdecken; bei fehlendem Netz funktioniert Offline-Modus weiter.
- 1.000 Commits innerhalb kurzer Zeit erzeugen **keine** 1.000 Discover-Promotions. Neues Repository und wichtige Releases erscheinen in getrennten Feeds.
- Geänderte Patch-Bytes erzeugen neuen Kandidatenhash und erneute notwendige Review-/Warteprüfung.
- Unternehmenskommentar wird als solcher angezeigt, aber verleiht nicht automatisch Release-Rechte.
- Standard-Frontend zeigt exakt `Initialised by SteveCo AI`; Text ist in UI-Tests nachweisbar.
- README, SECURITY, THREAT_MODEL, PROTOCOL und RELEASE_POLICY nennen offene Risiken; kein „production ready“, solange P0-Sicherheitslücken offen sind.

## 9. Sofort ausführbarer Codex-Prompt

> Lies diese Datei und den vorhandenen MeshForge-/Decentralhub-Code vollständig. Erstelle zuerst ein überprüfbares IST/ZIEL-Gap-Inventar. Implementiere dann P0-Ticket 1 (Namensmigration und Frontend-Branding `Initialised by SteveCo AI`) inklusive Tests und Dokumentation. Arbeite anschließend P0-Ticket 2 in kleinen, testbaren Schritten ab. Gib nach jedem Ticket Dateiliste, Designentscheidungen, Tests, Risiken und offene Fragen an. Behaupte keine Produktionsreife und installiere keine externen Abhängigkeiten ohne begründete Entscheidung. Beginne nicht mit automatischem Release-Konsens oder Update-Ausführung, bevor Signaturverifikation, Root-Key-Vertrauen und sichere Update-Policies spezifiziert und getestet sind.