# Aufnahme- und Vetting-Politik für fremde Knoten und Authorities

Stand 2026-09-19 · gilt für Verkehrsknoten (Mix, Gateway, Entry-Relay, Notifier) und Directory-Authorities.
Ergänzt `OPERATOR_ONBOARDING.md` (wie man einen Knoten betreibt) und `DA_ONBOARDING.md` (wie eine Authority
entsteht) um die Frage, **wer** aufgenommen wird und **warum jemand abgelehnt** wird.

## 1. Warum es diese Politik gibt

Die Anonymität im Mixnetz beruht darauf, dass die drei Hops eines Pfads bei **verschiedenen** Betreibern
liegen. Die App erzwingt das über die Deskriptor-Felder `operator` und `jurisdiction` — beides
Selbstauskunft. Ein Angreifer, der zehn Knoten unter zehn erfundenen Betreibernamen einbringt (Sybil),
hebelt die Regel aus, ohne ein einziges Bit zu brechen. Die Diversitätsregeln sind deshalb exakt so
viel wert wie diese Politik. „Wer will, ist drin" ist keine Option.

Zweite Grenze, ehrlich benannt: Heute betreibt eine juristische Person alle zwölf Knoten und alle drei
Authorities. Die Politik beschreibt ein **Verfahren**, noch keinen Zustand. Sie wird zum Zustand mit dem
ersten fremden Knoten, der sie durchläuft.

## 2. Wer aufgenommen werden kann

| Voraussetzung | Verkehrsknoten | Directory-Authority |
|---|---|---|
| Identität | benannte natürliche oder juristische Person; Kontaktweg, der binnen 48 h antwortet | juristische Person oder benannte Person mit öffentlichem Track-Record (Infrastruktur, Freie Software, Bürgerrechte) |
| Unabhängigkeit | kein gemeinsames Hoster-Konto, keine gemeinsame Rechnungsadresse, keine Beteiligung > 25 % an einem bestehenden Betreiber | zusätzlich: nicht derselbe Hoster wie eine bestehende Authority; kein gemeinsamer Rechtsraum, wenn vermeidbar |
| Rechtsraum | offengelegt; Entry-Relays nur in Rechtsräumen ohne Vorratsdatenspeicherung für Diensteanbieter dieser Art (Einschätzung in `IP_BLINDNESS_PROVIDERS.md`) | offengelegt; mindestens zwei Rechtsräume unter den Authorities |
| Betrieb | No-Log nachweisbar (`journalctl --disk-usage` = 0 B, keine Weiterleitung), kein SSH oder gleichwertig gehärteter Zugang, statisches Binary aus der Registry oder eigener reproduzierbarer Build | zusätzlich: Schlüssel entstehen auf dem Host (Ceremony), Rollback-Schutz aktiv (`/var/lib/hokono` existiert) |
| Lizenz | AGPL-3.0-or-later akzeptiert; eigene Änderungen am Knoten werden veröffentlicht | dito |
| Reziprozität | keine Bezahlung, kein Vertrag; wer Knoten stellt, bekommt nichts außer der Aufnahme | dito |

Ausgeschlossen sind: Betreiber, die anonym bleiben wollen (Anonymität gilt für Nutzer, nicht für
Betreiber); Betreiber, die eine Zweitentität eines bestehenden Betreibers sind; Hoster mit
Intercept-Pflichten, die der Betreiber nicht offenlegen darf.

## 3. Verfahren

1. **Anfrage** mit Selbstauskunft: Identität, Hoster, Rechtsraum, Rolle, Kontaktweg, Nachweis der
   Unabhängigkeit (z. B. Handelsregisterauszug, Rechnung des Hosters mit geschwärzten Beträgen).
2. **Technischer Nachweis**: Deskriptor-Zeile aus `nodetool`, Hash des laufenden Binaries
   (`sha256sum /proc/$(pidof hokono-mixnode)/exe`), `journalctl --disk-usage`, offene Ports (`ss -tlnp`).
   Nichts davon erfordert Zugriff der Authority auf den Knoten.
3. **Prüfung durch mindestens zwei Authorities** (nicht eine): Beide bestätigen die Selbstauskunft
   unabhängig (WHOIS/ASN des Hosters, Registerauskunft, Kontaktprobe). Eine einzelne Authority nimmt
   niemanden allein auf — das ist der Sinn von m-von-n.
4. **Probezeit 14 Tage** als Mix ohne `stable`-Flag: Der Knoten wird in Pfade genommen, die App bevorzugt
   aber stabile Knoten. Erreichbarkeit und Build-Hash werden stündlich vom Consensus-Lauf geprüft
   (`running`-Flag). Fällt der Knoten in der Probezeit länger als 24 h aus, endet die Probe.
5. **Aufnahme**: `stable` wird gesetzt, der Betreiber erscheint auf der Betreiberliste der Website mit
   Name, Rechtsraum und Hoster. Wer nicht gelistet werden will, wird nicht aufgenommen.
6. **Für Authorities zusätzlich**: Aufnahme in die Pin-Liste der App ist ein App-Release; der Index in der
   Authority-Reihenfolge ist dauerhaft. Vorher Ceremony nach `DA_ONBOARDING.md` §3 mit zwei bestehenden
   Authorities als Zeugen der öffentlichen Schlüssel (nicht der privaten).

## 4. Obergrenzen (Sybil-Schutz)

- Ein Betreiber stellt höchstens **2 Verkehrsknoten** und **1 Authority**.
- Ein Hoster (Autonomes System) trägt höchstens **ein Drittel** der Mixes und höchstens eine Authority.
- Ein Rechtsraum trägt höchstens die Hälfte der Entry-Relays.
- Neue Betreiber werden **ratenbegrenzt** aufgenommen: höchstens zwei pro Monat, damit ein plötzlicher
  Schub gleichartiger Anfragen auffällt (Ramp-up-Härtung, TASKS #79).

Diese Grenzen sind seit 2026-09-19 im Consensus-Lauf durchgesetzt (`consensus_mp.py`, `check_limits`): Ein
fremder Knoten, der eine Grenze reißt, wird **nicht aufgenommen** (laut im Log, der Consensus der übrigen
läuft weiter); neue Betreiber werden mit Datum in `consensus/owners.json` geführt (Ramp-up, Probezeit ohne
`stable`). Der Bootstrap-Betreiber ist ausgenommen, solange er das Netz allein trägt — Verstöße erscheinen
als Warnung. Der Betreiber steht als `owner` in `/hokono/mp/nodes`. Dazu die Pfadauswahl der App
(Betreiber-Disjunktheit).

## 5. Ausschluss und Entzug

Sofortiger Entzug (Knoten fällt aus der nächsten Epoche, 48 h Restgültigkeit des alten Dokuments):
- Logging von Verkehrsdaten nachgewiesen oder eingeräumt;
- Binary weicht vom gemeldeten Hash ab und der Betreiber kann es nicht erklären;
- Nachweis, dass die Unabhängigkeitsangabe falsch war;
- der Betreiber ist 14 Tage nicht erreichbar.

Der Entzug wird begründet und auf der Betreiberliste vermerkt. Widerspruch geht an alle Authorities;
zwei von drei entscheiden.

## 6. Was diese Politik nicht leistet

Sie erkennt keinen Betreiber, der lügt und dessen Lüge alle Prüfungen übersteht (gefälschte Register,
Strohmann). Dagegen hilft nur Zeit (Track-Record) und die Obergrenze je Betreiber. Sie ersetzt auch keine
Attestierung: Ob ein Knoten das Binary wirklich unverändert ausführt, ist heute ein Nachweis per Befehl,
den der Betreiber selbst absetzt (`NODE_INTEGRITY.md`).