Für Technikbegeisterte

Das Aufregendste am Bau von Hashiverse ist, dass es nicht wie traditionelle Software gebaut werden konnte. Seine absolute Unabhängigkeit von jedem souveränen Staat oder Unternehmen bedeutete, dass wir uns nicht auf zentralisierte Cloud-Anbieter, Server oder Datenbanken stützen konnten. Verdammt — nicht einmal auf DNS und Standard-Web-Zertifikate!

Jeder kann den Quellcode der Server oder Clients ändern und am Hashiverse-Protokoll teilnehmen, also muss sogar das Protokoll selbst gegen schlechte Akteure immun sein.

Hier sind einige Implementierungs­details, die uns an Hashiverse besonders gefallen. Jedes verweist auf den Quellcode, sodass du der Idee direkt in den Code folgen kannst.

Likes und Dislikes zählen sich selbst — keine zentralen Server nötig

Zählen in einem verteilten Netzwerk ist eklig. Wir wenden uns der Statistik zu, um verteiltes Zählen für unsere Feedback-Mechanismen zu erledigen. Jedes Feedback-Signal trägt seine eigene PoW, und jedes zusätzliche PoW-Bit verdoppelt die geschätzte Anzahl der Feedback-Klicks. Clients fusionieren Feedback von mehreren Servern, indem sie das stärkste Signal pro Beitrag nehmen, und heilen dann schwächere Peers. Das Netzwerk konvergiert ohne Koordinator. Exakte Zahlen kümmern uns nicht — bei ausreichend großen Zahlen sind wir im richtigen statistischen Bereich, und es ist verdammt schwer zu manipulieren.

Quelle: encoded_post_feedback.rs, post_bundle_feedback_healing.rs

Ein viraler Beitrag rekrutiert das ganze Netzwerk als CDN

Wenn ein Server genug Abrufe für denselben Inhalt sieht, beginnt er ihn zu cachen. Der abrufende Client lädt die Daten hoch, um diesen Cache zu befüllen. Bei einem viralen Beitrag wird jeder Server entlang jedes Client-Suchpfads zu einem Cache-Knoten. Je beliebter der Inhalt, desto mehr Server cachen ihn — das Netzwerk skaliert sich selbst.

Quelle: post_bundle_caching.rs

Trending-Hashtags entstehen aus dem Nichts

Keine zentralen Zähler. Da „im Trend" bedeutet, dass viele Nutzer posten, approximiert die lokale Sicht eines beliebigen Servers bereits die globale Wahrheit. Jeder Server verfolgt einzigartige Autoren pro Hashtag mit einem winzigen probabilistischen Zähler. Zählungen werden auf den Server des Posters „bezogen" — du kannst also nur den Zähler deines eigenen Servers aufblähen, und selbst dann zählt derselbe Autor, der 1.000 Mal postet, als einer. Dadurch ist das Trending eines Hashtags fast unmöglich zu manipulieren.

Quelle: dispatch.rs, hyper_log_log.rs

Vergessene Inhalte sterben an Vernachlässigung, nicht an Alter

Kein TTL. Kein Ablauf-Timer. Wenn der Speicher eines Servers voll wird, verdrängt er den am wenigsten kürzlich aufgerufenen Inhalt. Beliebter Inhalt wird ständig berührt und überlebt unbegrenzt. Inhalte, die niemand liest, verschwinden leise durch natürliche Auslese gemäß Zugriffsmuster.

Quelle: environment.rs

Heilung passiert nur, wenn jemand sich kümmert

Wenn ein Client Inhalte von mehreren Servern abruft und feststellt, dass einem Beiträge fehlen, die ein anderer hat, schließt er die Lücke — aber nur, weil er gerade gelesen hat. Inhalte, die niemand liest, werden nie geheilt. Inhalte unter aktivem Konsum werden bei jedem Client-Abruf geheilt. Leserschaft ist der Replikationsfaktor.

Quelle: post_bundle_healing.rs

Bootstrap traut niemandem — nicht einmal DNS

Drei Bootstrap-Domains über drei Regionen, jede über drei unabhängige DNS-over-HTTPS-Anbieter mit DNSSEC-Validierung aufgelöst. Ergebnisse werden dedupliziert und gemischt. Selbst dann muss jeder empfangene Peer eine vollständige kryptografische Verifikation bestehen, bevor der Client ihm vertraut. Ein kompromittierter DNS-Anbieter kann keine gefälschten Peers einschleusen, weil er die Milliarden Hashes, die jede Server-Identität erfordert, nicht fälschen kann.

Quelle: dnssec_bootstrap_provider.rs, peer_tracker.rs

TLS-Zertifikate für reine IP-Adressen — kein DNS nötig

Browser verweigern HTTPS gegen eine bloße IP, wenn das Zertifikat diese IP nicht abdeckt. Traditionelle CAs gaben nur Zertifikate für Domainnamen aus — was jeden Server vom DNS abhängig machen würde. Ende 2025 begann Let's Encrypt, IP-Zertifikate auszustellen. Wir hielten dafür den Atem an. Jeder Server stellt sein eigenes IP-Zertifikat im Hintergrund automatisch bereit und erneuert es. Browser- Clients können die DHT direkt per IP über vertrauenswürdiges HTTPS durchlaufen.

Quelle: https_transport_cert_refresher.rs

Dein Spam-Filter läuft auf Thermodynamik, nicht auf Datenbanken

Jede RPC-Hülle trägt eine Proof-of-Work-Lösung. Server lehnen alles unter dem Schwellwert ab, bevor sie überhaupt die Nutzlast parsen. Kein CAPTCHA, keine Rate-Limit-Datenbank, keine Konto­verifizierung. Die Kosten sind für einen legitimen Nutzer unsichtbar, ruinieren aber einen Spammer. Und diese PoW dient zusätzlich dazu, die Reputation der Server zu stärken, um schlechte Akteure abzuwehren.

Quelle: rpc_request.rs

Sensible Endpoints kosten exponentiell mehr zum Aufrufen (und Spammen)

Ein Routine-RPC kostet ~65K Hashes. Mit einem unbekannten Server zu reden kostet 4× mehr. Posten kostet 16× den Grundwert. Feedback kostet 32×. Eine Server-Identität zu erstellen kostet Milliarden Hashes (Stunden Arbeit). Jede Schicht ist präzise auf ihr Missbrauchspotenzial skaliert.

Quelle: config.rs

Der Cache-Radius dehnt sich aus wie eine Schockwelle

Clients verfolgen, wie weit von den Ursprungs­servern aus gecachte Daten propagiert sind. Jeder Cache-Treffer drückt den Radius weiter. Künftige Suchen starten jenseits des Radius und treffen frische Server, statt den Ursprung zu bombardieren. Beliebte Inhalte strahlen nach außen, sodass andere Clients früh in ihrem Walk auf gecachte Daten treffen. Obskure Inhalte bleiben lokal und ungecacht. Keine Konfiguration, kein Tuning — das Protokoll passt sich durch reine Beobachtung an.

Quelle: cache_radius_tracker.rs

Mehrere Granularitäts­ebenen der Beitrags-Buckets bändigen das Potenzgesetz

Jahr → Monat → Woche → Tag → 6 Stunden → 1 Stunde → 15 Min → 5 Min → 1 Min. Ein Nutzer, der einmal im Monat postet, kostet einen groben Bucket-Abruf. Ein Nutzer, der 100-mal am Tag postet, steigt in minutengenaue, parallel abgerufene Buckets ab. Dasselbe Protokoll, derselbe Code, wild unterschiedliche Lastprofile, anmutig gehandhabt.

Quelle: buckets.rs

Volle Buckets teilen sich — sie brechen nicht

Wenn ein Timeline-Bucket voll wird, versiegelt er. Clients sehen das Flag und steigen in feinkörnigere Kinder ab. Ein Trending-Hashtag kaskadiert von stündlich zu 15-Minuten- zu 1-Minuten-Buckets, während das Volumen ansteigt, und verteilt die Last automatisch auf verschiedene Server.

Quelle: dispatch.rs, buckets.rs

Eine Codebasis, jede Plattform — wirklich

hashiverse-lib kompiliert zu nativem Rust (Server) und WebAssembly (Browser). Die Protokolllogik, Kryptografie und Client-API sind derselbe Code, der in beiden Umgebungen läuft. Der Browser lädt es in einem Web Worker, sodass der Hauptthread nie blockiert. Wenn du den Server testest, testest du denselben Code, den der Browser ausführt.

Quelle: hashiverse-lib/, hashiverse-client-wasm/

100-Server-Integrationstests in Sekunden fertig

In-Memory-Transport ersetzt HTTP — null Netzwerk-Latenz, keine Ports, kein Aufräumen. Die Zeit läuft mit 300× Echtzeit, was 30 Minuten Peer-Discovery in 6 Wanduhr-Sekunden komprimiert. 100 Server, 3 Clients, voller Bootstrap, Beitragsabgabe, Heilung und Verifikation — ein Prozess, unter 30 Sekunden.

Quelle: client_meets_servers.rs

ASICs verschwinde! Die PoW-Kette ist selbstreferentiell

Fünf Runden verkettetes Hashing über 17 hochmoderne Hash-Algorithmen. Algorithmus und Wiederholungs­zahl jeder Runde leiten sich aus der Ausgabe der vorherigen Runde ab. Die Sequenz ist datenabhängig — ein ASIC, der für einen Algorithmus schnell ist, gewinnt nichts, wenn die Kette durch fünf andere routet. Wir freuen uns auf den Tag, an dem Hashiverse so erfolgreich ist, dass maßgeschneiderte ASICs wirtschaftlich genug werden, um es zu vereiteln.

Quelle: pow.rs

Quanten­sichere Identität, heute schon zugesagt

Jede Identität bettet Commitments zu zwei Post-Quanten-Schlüsselalgorithmen (Falcon und Dilithium) neben dem klassischen Ed25519-Schlüssel ein. Der Upgrade-Pfad ist in jeder Identität im Netzwerk eingebacken — bevor Quantencomputer existieren. Zwei unabhängige Gitter-Annahmen; beide müssten gleichzeitig brechen. Kurz gesagt: deine Hashiverse-Identität bricht nicht, wenn Quantencomputer Mainstream werden.

Quelle: keys_post_quantum.rs

Keine Passwörter, keine E-Mails, kein Problem

Keine zentralen Server bedeutet keine Passwortdatenbank und keine E-Mail, mit der du gespammt wirst. Du verwaltest deine eigenen Schlüssel — und wir geben dir drei Wege. Gastmodus: null Einrichtung, nur Lesezugriff, einfach loslegen. Schlüssel-Phrase: Passphrase eingeben, dieselbe Phrase liefert dieselbe Identität auf jedem Gerät. Passkey: dein Fingerabdruck oder Face ID wird zu deinem Schlüssel über die sichere Enklave deines Geräts — hardware-gesichert, geräteübergreifend synchronisiert, null Passwörter zu merken.

Quelle: key_locker.rs, login/

Ein Geheimtext, 32 Schlüssel

Beiträge sind im Ruhezustand und im Transit verschlüsselt. Kein Schnüffeln oder Nachbearbeiten durch hinterhältige Server. Ein einziger verschlüsselter Beitrag kann mit bis zu 32 verschiedenen Passphrasen entschlüsselt werden — eine pro Kontext, in dem er erscheint. Der Header ist selbstbeschreibend, sodass jede zukünftige Entschlüsselung die exakte Verschlüsselungs­konfiguration allein aus dem Geheimtext rekonstruiert.

Quelle: encryption.rs

Fünf DDoS-Verteidigungsschichten, bevor du den Anwendungscode erreichst

Schicht 1: PoW auf jeder RPC-Hülle. Schicht 2: Pro-IP-Score mit Zeitverfall. Schicht 3: Pro-IP-Verbindungs­obergrenze. Schicht 4: IP-Blacklisting auf Kernel-Ebene, wenn der Score den Schwellwert kreuzt. Schicht 5: Transport-Timeouts für TLS-Handshake, Header-Lesen und Body-Lesen (Slow-Loris-Verteidigung).

Quelle: ipset_ddos.rs, config.rs

Läuft auf einem 5-$-VPS — nach Plan, nicht zufällig

Komprimierter LSM-Tree-Speicher auf der Festplatte. Begrenzte In-Memory-Caches. Lock-gestripte gleichzeitige Schreibvorgänge. Probabilistische Zähler für Trends (64 Bytes pro Hashtag). Und die DHT bedeutet, dass jeder Server nur Daten in der Nähe seiner eigenen ID speichert — nicht das ganze Netzwerk.

Quelle: environment/, config.rs

Jede Naht im System ist ein austauschbarer Trait

Transport (mem-Kanäle vs HTTP vs WASM-Fetch). Zeit (echte Uhr vs 300×- Beschleunigung). Speicher (IndexedDB vs in-memory). DDoS-Schutz (Kernel-ipset vs In-Memory-Score). Schlüsselverwaltung (Web-Crypto-Enklave vs Test-Stubs). Tausche irgendeinen davon, ohne die Protokolllogik zu berühren. Tests verwenden die günstigen, die Produktion die echten; gleicher Codepfad.

Quelle: transport/, time_provider/, environment/

Browser-PoW über isolierte Web Workers

Der WASM-Client nutzt all deine Kerne, indem er Proof-of-Work über Web Workers verteilt. Jeder gleichzeitige PoW-Job ist isoliert, sodass sie sich nicht stören können. Ergebnisse brücken zurück von JavaScript Promises zu Rust Futures. Der Hauptthread des Browsers berührt nie einen Hash und wird nie langsamer.

Quelle: wasm_parallel_pow_generator.rs

Heilung verschwendet null Bandbreite

Der Client sendet einen Header, der beschreibt, was er hat. Der Server antwortet nur mit den IDs, die ihm fehlen. Der Client sendet genau diese Bytes. Hat der Server bereits alles, ist es ein einziger Roundtrip von Headern.

Quelle: dispatch.rs

Zwei Kompressions­algorithmen, ein Versions-Byte

LZ4 für RPC-Pakete (Geschwindigkeit). Brotli auf maximaler Qualität für gespeicherte Beiträge (Größe). Ein einzelnes führendes Versions-Byte erlaubt Algorithmus-Evolution, ohne bestehende Daten zu brechen. Unterhalb einer Mindestgröße wird Kompression komplett übersprungen — der Overhead würde die Einsparungen übersteigen.

Quelle: compression.rs

Der rekursive Bucket-Visitor rekursiert nie

Der Timeline-Walker verwendet explizite Stack-Frames statt Funktions-Rekursion. Ein Callback auf jeder Ebene entscheidet, ob tiefer gebohrt, übersprungen oder gestoppt wird. Dünne Timelines überspringen verschachtelte Ebenen ganz. Dichte Timelines bohren nur dort hinab, wo Inhalte existieren.

Quelle: recursive_bucket_visitor.rs