Zukünftige Richtungen

Hashiverse ist ein laufendes Protokoll, kein abgeschlossenes. Mehrere wichtige Bereiche sind entweder teilweise gelöst oder bekanntermaßen verbesserungs­bedürftig, während das Netzwerk skaliert. Diese Seite beschreibt die bedeutendsten geplanten Richtungen.

Schlüssel-Wiederherstellung und -Verwaltung

Selbst-souveräne Identität hat eine fundamentale Schwachstelle: Verlierst du deinen privaten Schlüssel, verlierst du deine Identität. Es gibt kein „Passwort vergessen" bei einem kryptografischen Schlüsselpaar. Das ist die größte Benutzbarkeits-Hürde für eine echte Verbreitung von Hashiverse.

Der geplante Ansatz ist Shamirs Secret Sharing: deinen privaten Schlüssel in N Anteile aufteilen, sodass je M davon (M ≤ N) den Schlüssel rekonstruieren können, M-1 Anteile aber nichts verraten. Du verteilst Anteile an vertrauenswürdige Parteien — Freunde, Familie, institutionelle Schlüssel­halter — und kannst deinen Schlüssel wiederherstellen, wenn M von ihnen kooperieren. Die Sicherheits­annahme: dass keine M-1 deiner Schlüssel­halter sich gegen dich verschwören.

Variationen dieses Themas umfassen:

• Drittanbieter-Schlüssel­halter: spezialisierte Dienste, die einen Anteil halten und nach Identitäts­prüfung (Biometrie, Wiederherstellungs-Code usw.) freigeben, was einen vertrauten Wiederherstellungs­mechanismus bietet, ohne den ganzen Schlüssel zu halten.
• Hardware-Token: Yubikeys und ähnliche Geräte können einen Anteil oder direkt den Wurzel­schlüssel halten, wobei die Hardware Manipulations­widerstand und PIN-Schutz bietet.
• Delegierte Schlüssel: bereits teilweise umgesetzt — ein Wurzel­schlüssel kann delegierte Schlüssel für die tägliche Signierung autorisieren, ohne den Wurzelschlüssel offenzulegen. Ein verlorenes Gerät bedeutet, seinen delegierten Schlüssel zu widerrufen, nicht deine Identität zu verlieren.

Interoperabilität

Hashiverse muss bestehende soziale Netzwerke nicht ersetzen, um nützlich zu sein. Brücken, die bestehende soziale Graphen importieren — Twitter/X-Verlauf, Mastodon/ActivityPub-Feeds, Bluesky-AT-Protocol-Daten — senken die Wechselkosten für Nutzer, die anderswo bereits Communities haben. Das ist eine bewusste Wachstumsstrategie: Hashiverse zum Ort machen, an dem deine Identität souverän ist, und bestehenden Netzwerken erlauben, hineinzuströmen, statt von Nutzern zu verlangen, von vorne anzufangen.

Erweiterte Signatur­schemata für die Beitrags­autorenschaft

Derzeit muss jeder Beitrag direkt von dem Schlüssel signiert werden, der die client_id des Posters erzeugt. Zwei wichtige reale Muster erfordern mehr Flexibilität.

Ephemere Schlüssel

Ein Client möchte vielleicht nicht jedes Mal seinen Master-Signierschlüssel entsperren, wenn er postet — etwa auf einem Mobilgerät, wo der Master­schlüssel in einer Hardware-Enklave oder hinter einer langsamen biometrischen Prüfung sitzt. Ephemere Schlüssel lösen das: Der Client erzeugt ein kurzlebiges Schlüsselpaar, signiert den ephemeren öffentlichen Schlüssel einmal mit dem Master­schlüssel und nutzt dann den ephemeren Schlüssel für das tägliche Posten, ohne den Master­schlüssel erneut anzufassen.

Server würden solche Beiträge über eine dreistufige Prüfung akzeptieren:

1. Verifizieren, dass die Signatur des Beitrags­körpers unter der gelieferten ephemeral_signature_pub gültig ist.
2. Verifizieren, dass ephemeral_signature_pub selbst eine Signatur trägt, die unter der gelieferten signature_pub (dem öffentlichen Master­schlüssel) gültig ist.
3. Verifizieren, dass signature_pub auf die client_id des Posters hasht und damit bestätigt, dass die Vertrauenskette zur deklarierten Identität zurückführt.

Ephemere Schlüssel können einen mit dem öffentlichen Schlüssel signierten Ablauf-Timestamp tragen, sodass ein durchgesickerter oder gestohlener Geräteschlüssel nach einem begrenzten Fenster ungültig wird, selbst wenn der Widerruf verzögert ist.

Organisationelle Delegation

Eine Organisation möchte vielleicht unter einer geteilten Identität veröffentlichen und gleichzeitig die Fähigkeit zu posten auf mehrere Einzelkonten verteilen — ein Nachrichtenmedium, dessen Journalisten jeweils eine eigene client_id halten, aber alle unter der Identität des Mediums schreiben.

Das geplante Modell: Die Wurzel­identität der Organisation veröffentlicht eine signierte Delegationsliste — eine Menge von client_ids, die berechtigt sind, in ihrem Namen zu posten. Server, die einen Beitrag eines delegierten Autors akzeptieren, würden prüfen, dass der Signierschlüssel zu einer delegierten client_id gehört und dass der Delegations­datensatz eine gültige Signatur vom Wurzel­schlüssel der Organisation trägt. Jeder der delegierten Clients kann posten; keiner braucht den Master­schlüssel der Organisation.

Client-Reputation und Real-World-Attestierung

Proof-of-Work erhöht die Kosten der Erstellung großer Mengen falscher Identitäten, ist aber nicht das einzige verfügbare Werkzeug. Eine ergänzende Richtung ist Client-Reputation: Mechanismen, die einem Client erlauben, neben einem Beitrag oder einem Feedback zu zeigen, dass er ein echter, langjähriger oder extern verifizierter Teilnehmer ist. Mehrere Ansätze werden geprüft.

Externe Identitäts­attestierung

Drittanbieter-Identitätsdienste können bezeugen, dass ein Hashiverse-Schlüssel zu einem verifizierten Menschen gehört, ohne preiszugeben, wer dieser Mensch ist. Zwei breite Modelle werden erwogen:

• OIDC-Anbieter: ein OpenID-Connect-Fluss, in dem der Client den Besitz eines Kontos bei einem renommierten Anbieter (Google, Apple, einem nationalen Identitätssystem usw.) nachweist und eine signierte Attestierung erhält, die dieses Konto an seine Hashiverse-client_id bindet. Die Attestierung reist mit Beiträgen als optionales Anti-Sybil-Signal mit; Server und Leser können wählen, wie viel Gewicht sie ihm geben.
• Staatlich ausgestellte Identität: an Yivi und Digidentity (niederländische eID-Anbieter) angelehnte Modelle erlauben es einem Staat oder einer regulierten Institution, bestimmte Attribute — Alter, Staatsangehörigkeit, eindeutige Bürgernummer — gegenüber einem kryptografischen Schlüssel zu bezeugen, ohne dem Netzwerk die zugrunde liegenden persönlichen Daten preiszugeben. Ein Client könnte „verifizierter, einzigartiger Mensch in Jurisdiktion X" gegenüber einem Server beweisen, ohne seinen Namen oder seine Dokumentnummer zu enthüllen.

Beide Ansätze sind strikt opt-in: Clients ohne Attestierung nehmen weiterhin auf Basis-PoW-Niveau teil. Attestierungen sind Signale, keine Türsteher.

Akkumulierte PoW als Reputation

Jedes Mal, wenn ein Client einen RPC ausführt, muss er eine frische Proof-of-Work beilegen. Die wird heute verbraucht und verworfen, repräsentiert aber eine beobachtbare Bilanz: Ein Client, der seit Monaten aktiv ist, hat zwangsläufig weit mehr kumulierte PoW geleistet als einer, der gestern erstellt wurde.

Eine geplante Erweiterung speichert die beste gesehene PoW eines Clients in einem Tag- und Monats-Verfalls­modell — dasselbe Halbwertszeit-Schema, das heute für die Server-Reputation verwendet wird. Ein Client, der regelmäßig postet, sammelt einen starken verfallenden Score; ein frisch eingerichteter Bot, der erst seit Stunden existiert, hat einen nahezu null Score und muss durch höhere Pro-Anfrage-PoW kompensieren, um akzeptiert zu werden. Das verschiebt die Ökonomie gegen Sybil-Farmen: Der Angreifer muss entweder erhebliche reale Zeit in das Aufwärmen jeder Identität investieren oder eine kontinuierlich höhere PoW-Steuer pro Anfrage zahlen für jede Identität, die die Aufwärmperiode überspringt.

Da der akkumulierte Score über die Zeit verfällt statt unbeschränkt zu wachsen, bekäme ein ruhendes Konto, das nach langer Abwesenheit zurückkehrt, einen mäßigen PoW-Aufschlag, bis es wieder aktuelle Aktivität aufgebaut hat — eine kleine Unannehmlichkeit für legitime Nutzer und eine spürbare Hürde für Bots, die erstellt, in einem Schub genutzt und dann verworfen werden.

Verschiedene Verbesserungen

• Async-Traits: Async-Traits werden in aktuellem Rust-Nightly nativ unterstützt, aber async_trait wird weiterhin für korrekte Send + Sync-Bindungen über Trait-Objekte hinweg gebraucht. Wenn die Standardbibliothek das stabilisiert, kann das Macro entfernt werden.