whois.md

Crumbcare — Wer ist da, wer hält die Tür?

whois fragt im alten Netz nach Herkunft und Zuständigkeit.
Im Crumbforest fragt es nach Rolle, Wurzel und Verantwortung.

Die Frage

whois node

Die Antwort soll nicht verraten, welcher Mensch hinter einem Gerät steht.

Sie soll zeigen:

Was ist dieser Node?
Wo steht er?
An welcher Wurzel hängt er?
Was darf er?
Wer kann seinen Zugang schließen?
Wie kommt er in einen sicheren Zustand zurück?

whois.md ist deshalb keine Identitätsabfrage.

Es ist eine lesbare Zusage:

Dieser Node ist nicht allein.
Seine Tür ist bekannt.
Seine Grenze ist sichtbar.
Verantwortung ist erreichbar.

Keine Identität sammeln

Crumbcare braucht kein vollständiges Bild eines Menschen.

Es braucht nur genug technische Klarheit, damit niemand allein vor einer offenen Tür steht.

whois?
→ Rolle
→ Standort
→ Zugang
→ Grenze
→ Rückweg
→ Verantwortung

Nicht:

whois?
→ Name
→ Verhalten
→ Profil
→ Persönlichkeit
→ dauerhafte Spur

Zugang und Persönlichkeit stehen im Schutz.

Eine Wurzel, viele Nodes

Im Wald können viele unterschiedliche Geräte mitspielen:

Zero
Raspberry Pi
ESP32
ESP8266
Jetson
GPU-Node
FPGA
Laptop
Server
Sensor
Container
virtuelle Maschine

Nicht jedes Gerät kann dasselbe.

Das muss es auch nicht.

Zero        → kleiner Wanderer
ESP         → Sensor oder Aktor
Raspberry   → lokaler Baum oder Dienst
Jetson      → Rechenwurzel mit alten Ästen
GPU-Node    → tiefer Rechenknoten
FPGA        → schnelle lokale Schutzkante
Server      → tragender Stamm

Die gemeinsame Wurzel ist nicht die Architektur.

Nicht ARM.
Nicht x86.
Nicht CUDA.
Nicht Linux.

Die gemeinsame Wurzel ist:

bekannter Zugang
→ begrenzter Weg
→ sichtbare Aufgabe
→ minimale Daten
→ rückholbarer Zustand
→ erreichbare Verantwortung

Der Wald bewertet keine Größe

Ein ESP ist kein kleiner Raspberry Pi.

Ein Zero ist kein schwacher Server.

Ein alter Jetson ist kein gescheiterter GPU-Node.

Jeder Node bringt seine eigene Fähigkeit mit.

Der Wald fragt nicht:

Wie stark bist du?

Er fragt:

Was kannst du tragen, ohne deine Grenze zu verlieren?

CrumbSeal

CrumbSeal ist die Schutzkante des Nodes.

Es beschreibt nicht nur, ob eine Verbindung technisch funktioniert.

Es beschreibt auch, welche Bewegung erlaubt ist.

Was darf dieser Node lesen?
Was darf er verändern?
Welche Daten dürfen hier entstehen?
Welche Daten dürfen hier niemals entstehen?
Wie lange darf eine Spur bleiben?
Wer darf den Zugang öffnen?
Wer kann ihn wieder schließen?

CrumbSeal ist kein Zaun gegen Teilnahme.

Es ist die Bedingung dafür, dass viele unterschiedliche Nodes sicher an derselben Wurzel mitspielen können.

Viele Nodes.
Eine Wurzel.
Unterschiedliche Fähigkeiten.
Klare Passkanten.

Crumbcare

Crumbcare beginnt dort, wo Technik allein nicht mehr genügt.

Ein Schlüssel allein trägt keine Verantwortung.

Ein VPN allein erklärt keinen Weg.

Ein Log allein hilft keinem Krümel.

WireGuard schützt den Weg.
CrumbSeal schützt die Grenze.
Crumbcare hält jemanden erreichbar.

Crumbcare fragt:

Wer schaut hin, wenn eine Warnung erscheint?
Wer sperrt den Schlüssel, wenn ein Gerät verloren geht?
Wer entscheidet, wenn ein Node schweigt?
Wer bleibt erreichbar, wenn ein Krümel nicht weiterweiß?

Die Antwort darf nicht lauten:

Das System wird es schon wissen.

Das Nullfeld

Das Nullfeld ist kein Ort, an dem alles gelesen wird.

Es ist ein bekannter Rückweg.

Node
→ WireGuard
→ CrumbVPN
→ Nullfeld
→ erlaubter Dienst

Das Nullfeld kann eine Wurzel verbinden, ohne alle Äste miteinander zu öffnen.

Peer A → Nullfeld
Peer B → Nullfeld

Peer A ↛ Peer B

Nähe ist keine Erlaubnis.

Eine gemeinsame Wurzel bedeutet nicht automatisch gemeinsamen Zugriff.

Kleine Türen

Ein Node soll nur die Wege erhalten, die er für seine Aufgabe benötigt.

ESP
→ MQTT-Broker

Zero
→ Nullfeld

Jetson
→ lokaler Vektordienst

GPU-Node
→ definierter Rechenauftrag

Nicht:

jeder Node
→ jeder Dienst
→ jedes Netz
→ alle Daten

Kleine Türen sind verständlicher.

Kleine Türen lassen sich schließen.

Kleine Türen lassen sich prüfen.

Die kleine Auskunft

Eine whois-Antwort kann so aussehen:

node:
  name: yamzo-jetson
  kind: gpu-node
  state: active
  root: nullfeld

network:
  transport: wireguard
  vpn: crumbvpn
  peer_access: restricted
  crossconnect: false

role:
  purpose: local-compute
  write_scope: checkpointed
  read_scope: defined

seal:
  identity_data: none
  personal_profiles: forbidden
  logging: minimal
  recovery: available
  reversible: true

care:
  responsible_role: crew
  human_reachable: true
  revoke_access: possible

Diese Antwort sagt genug, um den Node zu verstehen.

Sie sagt nicht mehr, als nötig ist.

Nerd-Version

whois nullfeld

role:           safe-return-point
transport:      wireguard
access:         key-gated
crossconnect:   denied-by-default
logging:        minimal
identity:       not-collected
personality:    protected
recovery:       available
responsibility: human-reachable

Read vor Write

Ein Node darf zuerst sprechen.

hostnamectl --static
ip address show
systemctl --failed
df -h /

Diese Befehle lesen.

Sie verändern den Zustand nicht absichtlich.

Erst danach kommt die Passkante:

lesen
→ Ergebnis sichern
→ Abweichung verstehen
→ Entscheidung treffen
→ kleinste Bewegung

whois.md beschreibt deshalb nicht nur, was ein Node ist.

Es erinnert auch daran, wie wir ihm begegnen.

Ein stiller Node

Ein Node kann schweigen.

Er kann offline sein.

Er kann einen unerwarteten Namen tragen.

Er kann eine alte Wurzel zeigen.

Dann gilt:

Ein stiller Node ist kein Fehler.
Er ist eine Beobachtung.

kein Handshake
→ markieren

kein SSH
→ nicht bestrafen

anderer Hostname
→ nicht überschreiben

alte Konfiguration
→ erst verstehen

Schweigen ist weder Zustimmung noch Schuld.

Es ist ein Zustand ohne ausreichende Antwort.

Reversibilität

Jede technische Bewegung soll einen Rückweg besitzen.

Zugang vergeben
→ Zugang sperrbar

Konfiguration ändern
→ vorheriger Zustand bekannt

Node importieren
→ Quelle dokumentiert

Dienst starten
→ Dienst stoppbar

Daten speichern
→ Löschung möglich

Ein Zustand, der nicht rückholbar ist, braucht eine stärkere Passkante.

Transparenz

Ein Krümel darf verstehen:

welcher Weg benutzt wird
wo der Tunnel beginnt
wo er endet
welcher Node antwortet
welche Daten entstehen
wer helfen kann
wie der Zustand zurückgesetzt wird

Sicherheit darf nicht in einem dunklen Raum wohnen.

Keine versteckte Beobachtung

Ein technischer Betriebsweg darf nicht heimlich zu einem Persönlichkeitsprotokoll werden.

erlaubt:
  technischer Zustand
  letzter Handshake
  Node-Rolle
  Fehlerstatus
  notwendige Betriebsdaten

nicht erlaubt:
  Persönlichkeitsprofil
  Verhaltensbewertung
  dauerhafte Identitätsverknüpfung
  heimliche Inhaltsanalyse
  unnötige Langzeitspeicherung

Eine Spur darf den Weg sichern.

Sie darf nicht zum Schatten eines Menschen werden.

Verantwortung bleibt beim Menschen

WireGuard kann prüfen, ob ein Peer einen passenden Schlüssel besitzt.

NetBox kann erinnern, wo ein Node steht.

Ansible kann einen beschriebenen Zustand tragen.

Git kann eine Änderung bewahren.

CrumbSeal kann Grenzen beschreiben.

Aber keines dieser Werkzeuge beantwortet allein:

Soll dieser Zugang existieren?
Ist diese Änderung verantwortbar?
Darf diese Information gespeichert werden?
Braucht ein Mensch gerade Hilfe?

Diese Entscheidung bleibt an der Passkante.

Die Reihenfolge

Node spricht
→ CrumbFu hört
→ Mensch entscheidet
→ CrumbSeal begrenzt
→ WireGuard verbindet
→ Nullfeld trägt
→ NetBox erinnert
→ Git bewahrt
→ Crumbcare bleibt erreichbar

Nicht jeder Lauf muss alle Stationen erreichen.

Manchmal endet der richtige Weg nach dem Lesen.

Node spricht
→ Mensch versteht
→ nichts verändern

Auch das ist ein vollständiger Lauf.

whois im Crumbforest

whois bedeutet im Crumbforest nicht:

Wer gehört wem?

Es bedeutet:

Wer trägt was?

Der Node trägt eine Aufgabe.
Die Wurzel trägt den Weg.
CrumbSeal trägt die Grenze.
Crumbcare trägt die Verantwortung.
Der Mensch trägt die Entscheidung.

Schluss

whois war einmal eine Abfrage nach Herkunft.
Im Crumbforest wird es eine Frage nach Fürsorge.

Wo steht dieser Node?
Welche Wurzel trägt ihn?
Welche Tür darf er benutzen?
Wer kann sie wieder schließen?
Wer bleibt erreichbar?

Ein Zero, ein Raspberry Pi, ein ESP, ein Jetson oder ein GPU-Node
können alle an derselben Wurzel mitspielen.

Nicht, weil sie gleich sind.
Sondern weil ihre Unterschiede sichtbar bleiben.

Viele Nodes.
Eine Wurzel.
Klare Passkanten.

Der Wald war schon immer da.