Prometheus
DE EN
DE EN

07 — Roadmap

Die drei Phasen

Jede Phase liefert für sich, und 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

Stand 2026-08-13: Die Erfassungsseite ist vollständig geliefert, und der Mirror nimmt Submissions an — mit vollständiger Prüfkette und Persistenz, bislang auf der Entwicklungsumgebung. Offen sind Audit-Log, Snapshots, Federation-Registry und Dashboard. Stand im Detail →

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

Vorgezogen und bereits gebaut: der Endnutzer-Agent, der Hybrid-Aggregator, die ZK-Attestation und der Mix-Net-Transport. Alle vier sind implementiert und getestet — in Betrieb gehen sie trotzdem erst in Phase 2, weil sie einen laufenden Mirror und einen zweiten Betreiber voraussetzen.

Phase 3 · geplant · ~Q1 2027

Threshold-Konsens

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

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.

Stand der Umsetzung

Was heute steht — und was nicht

Eine Roadmap ohne Lieferstand ist eine Absichtserklärung. Deshalb hier der Ist-Stand vom 2026-08-13, Baustein für Baustein. „Geliefert“ heißt: gebaut, getestet und durch das Review-Gate. Es heißt nicht, dass die Sache öffentlich läuft — dafür fehlt bis heute ein erreichbarer Mirror.

Bausteine und ihr Lieferstand
BausteinStand
SDK — Modus AGeliefert. Sechs Sprachen mit byte-identischer kanonischer Ausgabe, abgesichert durch eine sprachübergreifende Conformance-Suite.
Registry-Scraper — Modus DGeliefert. Fünf Registry-Adapter und ein GitHub-Manifest-Crawl. Gemessen bisher gegen feste Testdaten, noch nicht gegen die echten Registries.
Endnutzer-Agent — Modus BGeliefert, nicht im Betrieb. Daemon mit Betriebssystem-Hooks für Linux, macOS und Windows; k ≥ 25 wird vor jedem Egress erzwungen.
Hybrid-Aggregator — Modus CGeliefert, nicht im Betrieb. Inklusive Signatur- und Egress-Weg, end-to-end gegen einen Mock-Mirror geprüft.
ZK-Attestation für k-AnonymitätFundament geliefert. Der Beweis ist 896 Byte groß und bindet 25 paarweise verschiedene Sitzungs-Token. Bis zur Pflicht in Phase 2 bleibt die lokale Prüfung das verbindliche Gate.
Mix-Net-TransportGeliefert. Dieselben Bytes in drei unabhängigen Implementierungen; der Submission-Inhalt bleibt davon unberührt.
Mirror — Submission-AnnahmeGeliefert, auf Entwicklungsumgebung. Vollständige Prüfkette am Ingress — Signatur, PII-Schema, k-Anonymität, Zeitfenster, Duplikate — und Persistenz. Die Erkennung von Duplikaten übersteht einen Neustart.
Public Audit LogOffen. Nächster Sprint auf dem kritischen Pfad.
Snapshot-WorkerOffen. Ohne ihn gibt es noch keine Open-Data-Dateien.
Federation-RegistryOffen. Die Liste der Mirrors ist spezifiziert, aber noch nicht signiert veröffentlicht.
Open-Data-API und DashboardOffen. Die lesenden Endpunkte antworten heute ausdrücklich „noch nicht implementiert“ statt „unbekannt“ — damit ein Gegenüber beides unterscheiden kann.
Öffentlich erreichbarer MirrorOffen. Hängt an der Bootstrap-Finanzierung, dem letzten echten Launch-Blocker.

Akzeptanzkriterien

K1 bis K7 im Ist-Stand

Die sieben Kriterien entscheiden über den Phase-1-Launch. Sie stehen hier mit ihrem tatsächlichen Messstand, nicht mit ihrem Zielwert.

Akzeptanzkriterien K1 bis K7 mit Messstand
KriteriumMessstand
K1 — ReichweiteErfüllt gegen feste Testdaten. Der Lauf gegen die produktiven Registries steht aus.
K2 — PURL-AuflösungErfüllt gegen feste Testdaten, mit deutlichem Abstand zur Schwelle. Live-Lauf ebenfalls offen.
K3 — keine PIIEndgültig erfüllt. Beide Gates greifen unabhängig; am Mirror wird gegen die vollständige Verbotsliste geprüft und mit dem betroffenen Feldnamen abgelehnt.
K4 — keine zu kleine KohorteLokal und am Mirror-Ingress erfüllt. Die Prüfung am veröffentlichten Snapshot fehlt noch, weil es noch keinen gibt.
K5 — Ausfall ohne DatenverlustDer Wiederanlauf des Mirrors ist belegt. Das vollständige 30-Minuten-Szenario steht aus.
K6 — Auswertung in unter zwei MinutenNoch nie gemessen. Das Kriterium läuft über das Dashboard, und das ist noch nicht gebaut.
K7 — Laufzeit-Budget des SDKErfüllt in allen sechs Sprachen, jeweils weit unter der Schwelle.

Der Restweg bis zum Phase-1-Launch ist als „Projekt 1.0“ in sieben Wellen sequenziert und läuft öffentlich nachvollziehbar über den Issue-Tracker des Projekts — einschließlich der Abhängigkeiten zwischen den Wellen. Repository auf Codeberg →

Vor dem Launch

Stand der offenen Entscheidungen

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 →