# Discovery, Beobachtungen und öffentliche Outbox — experimentell

25. Oktober 2026. DDP ist öffentliche Metadatenverteilung, kein privater
Repository-Transport. Lokale Commits erzeugen keine Discovery-Ereignisse.
Keine Produktionsfreigabe oder Sybil-resistente Personenidentität.

## Unveränderte Legacy-Signaturen und neue Erweiterung

DDP/0.1 bleibt bytekompatibel: die Signatur bindet Go-JSON des `Payload` in
bestehender Feldreihenfolge. Die Ereignis-ID ist lowercase SHA256 von
`ddp/0.1/event\0` || PayloadJSON || SignatureBytes. Bestehende signierte
Payloads, IDs, Timestamps und Repo-IDs werden nicht umgeschrieben.

DDP/0.2 ist eine ausdrücklich experimentelle Erweiterung für Sternentzug:
Ed25519 signiert `decentralhub/ddp/0.2/event-signature\0` || PayloadJSON;
ID = SHA256(`ddp/0.2/event\0` || PayloadJSON || SignatureBytes).
`protocol` im Payload ist `ddp/0.2`. Keys und Signaturen müssen kanonisches
unpadded base64url sein. Unterstützte Typen:

| Version | Ereignisse |
|---|---|
| ddp/0.1 | repository.published, release.announced, repository.star |
| ddp/0.2 | dieselben sowie repository.unstar |

`/.well-known/decentralhub.json` nennt die tatsächlichen Versionen/Typen.
Ältere Peers können den Entzug nicht anwenden und frühere Sterne weiter anzeigen;
eine Freigabe lässt sich nicht von allen alten Kopien zurückholen. Keine stille
Uminterpretation von 0.1. Der CLI-Befehl `unstar` verwendet automatisch 0.2.

Legacy-base64-Paddingbit-Aliase bleiben verifizierbar, damit historische
Signaturen gültig bleiben. Eigentümervergleiche und Sterne zählen **dekodierte
Schlüsselbytes**, keine Textaliase. Mehrere verschiedene Schlüssel können dennoch
derselben Person gehören. Node-Publisher-Key, DIP-Root-ID und neue Public-Sync-
Repo-ID werden nicht automatisch gleichgesetzt; signierte Bindings fehlen noch.

## Persistenz und Batching

Alte `events.json`-Listen und `config.json` werden einschließlich Einrückung
gelesen. Startup bewahrt die ursprünglichen Event-Dateibytes. Beim nächsten
bewussten Update wird nur die JSON-Dateihülle kanonisch/sortiert neu geschrieben;
signierte Eventstrukturen und IDs bleiben unverändert. OS-Prozesslock, atomarer
File-/Directory-Sync und Reload nach ungewissem Commit verhindern verlorene
parallele Schreiber und falsches Zurückrollen des Speichercaches.

`node-store.json` markiert vollständige Initialisierung. Fehlen danach Events
oder Konfiguration, wird nicht still eine leere Datenbank erzeugt. Legacy-
Bestände über 16 MiB werden mit Fehler abgewiesen, nicht gekürzt oder migriert.
Ereigniscache: höchstens 16 MiB und 100.000 IDs; Peer-Konfiguration: 256 KiB,
64 explizite Peers. Je Abgleichseite werden höchstens 250 signierte Ereignisse
gemeinsam gespeichert. Bekannte identische Strukturen können bereits geprüfte
Signaturen wiederverwenden; geänderte Bytes werden erneut geprüft.

`/api/events` begrenzt Seiten zusätzlich auf 2 MiB. Ein vorzeitig wegen Bytes
gekürztes Ergebnis enthält `X-Decentralhub-Next`; der Client prüft dessen Überein-
stimmung mit der letzten ID. Eingehende Events: maximal 64 KiB, vier parallele
Prüfungen, 256 Requests/IP/Minute, 2048 global, 4096 begrenzte IP-Zähler.
Unbekannte Felder und zusätzliche JSON-Dokumente werden abgewiesen.

## Öffentliche Versandwarteschlange

`public-outbox.json` enthält ausschließlich IDs bereits persistierter gültiger
öffentlicher Ereignisse, ausgewählte konfigurierte Ziele und Retry-Metadaten.
Keine Schlüssel, privaten Snapshots oder Registry-Inhalte. Maximal 1024 Jobs,
100.000 persistente Seen-IDs, 16 MiB Gesamtzustand. Pro Ereignis deterministisch
höchstens drei konfigurierte Ziele. Lease vor Versand, nach 90 Sekunden erneuerbar;
Abbruch nach Remote-ACK führt zu idempotentem Retry. Dauerhaft gespeicherte
Seen-IDs verhindern Gossip-Schleifen nach bestätigten Wiederholungen.

Ein Worker bearbeitet höchstens drei Jobs pro Zyklus. Fehler erhalten begrenzten
Backoff bis 30 Minuten; entfernte konfigurierte Peers sind keine Versandziele
mehr. Signierte Events bleiben auch bei voller/defekter Queue im öffentlichen
Cache und können über Anti-Entropy übernommen werden; ein Queuefehler wird
gemeldet. Keine unbegrenzten Goroutinen pro eingehendem Ereignis. GC/Retention
für den endlichen Cache/Seen-Satz ist noch offen; Kapazitätsfehler sind explizit.

## Tatsächlich gemessener Status

Discovery prüft höchstens drei rotierende Peers je Zyklus, mit 20 Sekunden
Gesamtbudget pro Peer, Hintergrundprüfung alle 15 Sekunden bei Fälligkeit,
erfolgreicher Probe nach ungefähr fünf Minuten erneut; Fehler mit Backoff/Jitter.
`network.json` enthält lokale Beobachtungen von Versuch, Erfolg, Fehler und
nächster Fälligkeit. Nicht mehr konfigurierte Peers werden aus Beobachtungen
entfernt. Beobachtungszeit ist eine lokale Uhrzeit, keine globale Wahrheit.

Die localhost-Ansicht `/private/network` und der private Header-Status zeigen
keine allgemeine Internetverfügbarkeit: keine Peers, noch nicht aktuell geprüft,
lokale Peers erreichbar, öffentliche Verbindung beobachtet, laufender Abgleich,
Fehler/eingeschränkt. Ein reiner TCP-Verbindungsfehler aller geprüften Peers ist
offline; eine antwortende, aber ablehnende Gegenstelle ist eingeschränkt.
Fehlerkomponenten werden unabhängig erneut geprüft und nach Reparatur sichtbar
zurückgesetzt. LAN-Intranet-Föderation bleibt gesperrt: die bestehende SSRF-
Policy blockiert private Ziele außer bewusst konfiguriertem Loopback.

Bereits vorhandene öffentliche Snapshot-Verbindungen können lokal auf Pending-
Push/Pull überprüft werden. Das liest keine Schlüssel, kontaktiert keinen Node
und erzeugt keine Verbindung. Neue lokale Commits werden **nicht** automatisch
zur Veröffentlichung ausgewählt. Fortsetzen/Abbrechen erfolgt explizit per CLI.

## Feeds und lokale Oberfläche

Neue Projekte bleiben nach erster Veröffentlichung sortiert; Releases/Commits
schieben diesen Feed nicht hoch. RFC3339-Zeitpunkte werden als Instants geparst,
gleiche Zeiten deterministisch nach Event-ID geordnet. Zeitpunkte bleiben
signierte Publisher-Behauptungen. Auch importierte Releases vor dem behaupteten
Veröffentlichungszeitpunkt werden gegen den bekannten Owner geprüft.

Der globale Release-Feed und der wichtige/kritische Feed zeigen die neueste
**passende** Ankündigung je Repo. Ein späterer normaler Release löscht die
historische kritische Ankündigung nicht aus deren Feed; das ist kein Nachweis
einer weiterhin offenen Sicherheitslücke. Explizite Repo-Historie zeigt höchstens
250 Einträge. Tests mit 1000 Releases ergeben einen globalen Eintrag, nicht 1000.

Die private Merkliste ist lokal, nicht signiert/veröffentlicht und kein
öffentlicher Follow. Öffentliche Sterne/Entzüge sind separate lokale Formulare
mit CSRF und ausdrücklicher Checkbox; nur öffentliche Index-Repos sind zulässig.
Signiert wird mit dem lokalen Node-Key. Der localhost-/CSRF-Schutz setzt einen
vertrauenswürdigen Rechner voraus; er ist **keine OS-Benutzeranmeldung** oder
benannte Team-Identität. OS-Keystore/Geräte-Sessions bleiben eigene Gates.

Offen: zeitbezogenes Trending, Kategorie-Abonnements, öffentliche signierte
Follows, vollständige TTL/GC-Retention und echte LAN-Policy. Die vorhandene
Sortierung „Nach Sternen“ ist ausdrücklich Gesamtzählung, kein Trending.