06 — Roadmap

Drei Phasen. Jede liefert für sich.

Die Reihenfolge ist keine Dekoration: Jede Phase setzt technisch auf der vorherigen auf. Federation ohne funktionierendes Protokoll wäre sinnlos, Threshold-Konsens ohne mehrere Mirrors unmöglich.

Phase 1 · läuft · ~10 Wochen

Reach & Runtime MVP

Registry-Scraping über npm, PyPI, Maven Central, crates.io und Go Modules
Self-Instrumentation-SDKs mit vier Event-Typen
Ein Bootstrap-Mirror in der EU
Open-Data-Snapshots als Parquet und CSV.gz — ab Tag 1
Public Audit Log über Sigstore Rekor — ab Tag 1
K1–K7 als verbindliche Akzeptanztests vor dem Launch

DE EN

Phase 2 · geplant · ~Q3 2026

Federation & Zero Knowledge

Endnutzer-Agent (Modus B) mit k ≥ 25
Hybrid-Aggregator (Modus C)
ZK-SNARK-Attestation für k-Anonymität — dann Pflicht
Zweiter unabhängiger Mirror
Gossip-Federation zwischen den Mirrors
Mix-Net-Submission als opt-in-Transport — ergänzt die direkte Egress, ersetzt sie nicht
mTLS als Pflicht für die Federation

DE EN

Phase 3 · geplant · ~Q1 2027

Threshold-Konsens

Mindestens drei unabhängige Mirrors
Threshold-Konsens über akzeptierte Aggregate
Sybil- und Eclipse-Resistenz als Akzeptanzkriterium

DE EN

Vorgezogen und bereits in P1-Ph3 geliefert: die SDK-Sprachen Java, Go, Rust und .NET, die Build-Tool-Plugins für Maven, Gradle, cargo und npm sowie die sprachübergreifende Conformance-Suite.

Zeitangaben für Phase 2 und 3 sind Planung, keine Zusage. Sie hängen unmittelbar daran, ob sich Mirror-Betreiber und Pilot-Bibliotheken finden.

Vor dem Launch

Die Entscheidungs-Blocker sind geschlossen.

Vier der Punkte, die den Phase-1-Launch blockiert haben, wurden am 2026-05-29 entschieden — drei davon per ADR, die DSGVO-Zuordnung über die Verantwortungs-Matrix in der Infrastruktur-Dokumentation. Sie stehen hier mit ihrer Entscheidung, nicht als offene Fragen. Was offen bleibt, steht darunter.

Anti-Sybil — entschieden

Rate-Limit pro DID (≤ 24 in 24 h für die Modi A, B und C), Cross-Mode-Plausibilitätsflag zwischen Track A und Track D sowie ein 7-tägiger Burn-In als trust_tier: "new". Proof-of-Work wurde ausdrücklich verworfen — es verschwendet Endnutzer-CPU und wirkt gegen Botnetze asymmetrisch. Phase 2 ergänzt ein Maintainer-Web-of-Trust.

DSGVO je Mirror — entschieden

Der Mirror-Betreiber ist alleiniger Verantwortlicher für die in seinem Mirror gespeicherten und publizierten Aggregate. Der Melder ist betroffene Person mit eigener DID; ein Joint-Controllership entsteht nicht. Jeder Eintrag in mirrors.json braucht eine veröffentlichte Datenschutzerklärung.

PURL und Aliase — entschieden

PURL strikt nach Registry-Vergabe, ohne Mutation. Forks und Umbenennungen laufen über eine separat signierte Alias-Tabelle; die Auflösung ist reine View-Layer-Funktion, weshalb Aggregat-Speicher und Audit-Log unverändert bleiben. Aggregate in __small_cohorts dürfen dabei nie namentlich aufgelöst werden.

Open-Data-Lizenz — beschlossen, Freigabe ausstehend

Phase-1-Snapshots werden unter CC-BY-4.0 publiziert und tragen im Manifest zusätzlich eine Provisional-Klausel. Der Launch ist dadurch ausdrücklich nicht blockiert. Offen ist allein die Foundation-Rechtsfreigabe; fällt sie ablehnend aus, bleibt der bereits publizierte Snapshot gültig und es erscheint ein neu lizenzierter Re-Issue unter neuer Snapshot-ID.

Offen vor dem Mirror-Launch: die Bootstrap-Finanzierung. Wer trägt die Hosting-Kosten des Phase-1-Referenz-Mirrors von rund 50 € im Monat — Foundation-Sponsoring, Hochschul-Rechenzentrum oder Crowdfunding? Der Punkt ist terminiert auf „bevor der Mirror produktiv läuft" und damit der letzte echte Launch-Blocker. Dazu beitragen →

Zusätzlich laufend kalibriert, aber nicht launch-blockierend: die konkreten Schwellenwerte der Anti-Sybil-Heuristik — Faktor-10-Schwelle zwischen Track A und Track D, Burn-In-Frist und Rate-Limit-Werte werden quartalsweise überprüft.

Zu den offenen Beiträgen →