Voor de techneuten

Het leukste aan het bouwen van Hashiverse is dat het niet kon worden gebouwd zoals traditionele software. De absolute onafhankelijkheid van enige soevereine overheid of bedrijf betekende dat we niet konden vertrouwen op gecentraliseerde cloudproviders of servers of databases. Verdorie — zelfs niet op DNS en standaard webcertificaten!

Iedereen kan de broncode van de servers of de clients aanpassen en deelnemen aan het Hashiverse-protocol, dus zelfs het protocol zelf moet immuun zijn voor kwaadwillenden.

Hier zijn enkele van de implementatiedetails waar we bij Hashiverse vooral van genieten. Elk verwijst naar de bron zodat je het idee rechtstreeks de code in kunt volgen.

Likes en dislikes tellen zichzelf — geen centrale servers vereist

Tellen in een gedistribueerd netwerk is walgelijk. We wenden ons tot statistiek om gedistribueerd tellen te doen voor onze feedbackmechanismen. Elk feedbacksignaal draagt zijn eigen PoW, en elke extra PoW-bit verdubbelt het geschatte aantal feedback-clicks. Clients voegen feedback van meerdere servers samen door per bericht het sterkste signaal te nemen, en helen vervolgens zwakkere peers. Het netwerk convergeert zonder enige coördinator. Exacte tellingen interesseren ons niet — bij voldoende grote aantallen zitten we in de juiste statistische orde van grootte, en het is verdomd lastig te manipuleren.

Bron: encoded_post_feedback.rs, post_bundle_feedback_healing.rs

Een viraal bericht recruteert het hele netwerk als zijn CDN

Wanneer een server genoeg fetch-verzoeken voor dezelfde inhoud ziet, begint hij die te cachen. De ophalende client uploadt de data om die cache te vullen. Voor een viraal bericht wordt elke server langs het lookup-pad van elke client een cache-knooppunt. Hoe populairder de inhoud, hoe meer servers hem cachen — het netwerk schaalt zichzelf.

Bron: post_bundle_caching.rs

Trending hashtags ontstaan uit het niets

Geen centrale tellers. Aangezien "trending" betekent dat veel gebruikers posten, benadert de lokale weergave van een willekeurige server al de globale waarheid. Elke server volgt unieke auteurs per hashtag met een kleine probabilistische teller. Tellingen zijn thuisgebracht op de server van de poster — je kunt dus alleen je eigen server-telling opblazen, en zelfs dan telt dezelfde auteur die 1.000 keer post als één. Dit betekent dat een hashtag laten trenden vrijwel onmogelijk te manipuleren is.

Bron: dispatch.rs, hyper_log_log.rs

Vergeten inhoud sterft door verwaarlozing, niet door ouderdom

Geen TTL. Geen vervaltimer. Wanneer de opslag van een server vol raakt, verwijdert hij de minst recent benaderde inhoud. Populaire inhoud wordt voortdurend aangeraakt en overleeft voor onbepaalde tijd. Inhoud die niemand leest verdwijnt stilletjes via natuurlijke selectie op toegangspatroon.

Bron: environment.rs

Healing gebeurt alleen als iemand erom geeft

Wanneer een client inhoud van meerdere servers ophaalt en ontdekt dat één server berichten mist die een andere wel heeft, heelt hij het gat — maar alleen omdat hij aan het lezen was. Inhoud die niemand leest wordt nooit geheeld. Inhoud onder actieve consumptie wordt geheeld telkens wanneer een client hem ophaalt. Lezerschap is de replicatiefactor.

Bron: post_bundle_healing.rs

Bootstrappen vertrouwt niemand — zelfs DNS niet

Drie bootstrap-domeinen verspreid over drie regio's, elk opgelost via drie onafhankelijke DNS-over-HTTPS-providers met DNSSEC-validatie. Resultaten worden ontdubbeld en geschud. Zelfs dan moet elke ontvangen peer volledige cryptografische verificatie doorstaan voordat de client hem vertrouwt. Een gecompromitteerde DNS-provider kan geen nep-peers injecteren omdat ze de miljarden hashes die elke server-identiteit vereist niet kunnen vervalsen.

Bron: dnssec_bootstrap_provider.rs, peer_tracker.rs

TLS-certificaten voor kale IP-adressen — geen DNS vereist

Browsers weigeren HTTPS naar een kaal IP tenzij het certificaat dat IP omvat. Traditionele CA's gaven alleen certificaten uit voor domeinnamen — wat elke server afhankelijk zou maken van DNS. Eind 2025 begon Let's Encrypt IP-certificaten uit te geven. We hielden onze adem in voor dit moment. Elke server levert en vernieuwt zijn eigen IP-certificaat automatisch op de achtergrond. Browserclients kunnen direct via IP over vertrouwde HTTPS de DHT bewandelen.

Bron: https_transport_cert_refresher.rs

Je spamfilter draait op thermodynamica, niet op databases

Elke RPC-envelope draagt een proof-of-work-oplossing. Servers wijzen alles onder de drempel af voordat de payload zelfs maar wordt geparseerd. Geen CAPTCHA, geen rate-limit-database, geen accountverificatie. De kost is onzichtbaar voor een legitieme gebruiker maar maakt een spammer bankroet. En deze PoW dient er bovendien toe om de reputatie van de servers te versterken om kwaadwillenden af te weren.

Bron: rpc_request.rs

Gevoelige endpoints kosten exponentieel meer om aan te roepen (en te spammen)

Een routine-RPC kost ~65K hashes. Praten met een onbekende server kost 4× meer. Posten kost 16× basislijn. Feedback kost 32×. Het aanmaken van een server-identiteit kost miljarden hashes (uren werk). Elke laag is precies geschaald aan zijn misbruikpotentieel.

Bron: config.rs

De cache-straal breidt zich uit als een schokgolf

Clients houden bij hoe ver vanuit de oorsprongsservers gecachte data is verspreid. Elke cache-hit duwt de straal verder. Toekomstige lookups beginnen voorbij de straal en raken verse servers in plaats van de oorsprong te hameren. Populaire inhoud straalt naar buiten, wat betekent dat andere clients vroeg in hun walk gecachte data raken. Obscure inhoud blijft lokaal en ongecached. Geen configuratie, geen tuning — het protocol past zich aan via eenvoudige observatie.

Bron: cache_radius_tracker.rs

Meerdere niveaus van bucket-granulariteit temmen de machtswet

Jaar → maand → week → dag → 6 uur → 1 uur → 15 min → 5 min → 1 min. Een gebruiker die eens per maand post kost één grove bucket-fetch. Een gebruiker die 100 keer per dag post drilt naar minuut-niveau-buckets die parallel worden opgehaald. Hetzelfde protocol, dezelfde code, wild verschillende belastingsprofielen die soepel worden afgehandeld.

Bron: buckets.rs

Volle buckets splitsen — ze breken niet

Wanneer een tijdlijn-bucket volraakt, wordt hij verzegeld. Clients zien de vlag en drillen in fijner gegranuleerde kinderen. Een trending hashtag cascadeert van uurlijks naar 15 minuten naar 1 minuut buckets als het volume piekt, en spreidt de belasting automatisch over verschillende servers.

Bron: dispatch.rs, buckets.rs

Eén codebase, elk platform — echt waar

hashiverse-lib compileert naar native Rust (server) en WebAssembly (browser). De protocol-logica, cryptografie en client-API zijn dezelfde code die in beide omgevingen draait. De browser laadt het in een Web Worker zodat de hoofdthread nooit blokkeert. Wanneer je de server test, test je dezelfde code die de browser draait.

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

Integratietests met 100 servers eindigen in seconden

In-memory transport vervangt HTTP — nul netwerklatentie, geen poorten, geen opruim. De tijd loopt op 300× werkelijke snelheid, en perst 30 minuten peer-discovery samen tot 6 wandkloksecondes. 100 servers, 3 clients, volledige bootstrap, bericht-indiening, healing en verificatie — één proces, onder de 30 seconden.

Bron: client_meets_servers.rs

ASIC's wegwezen! De PoW-keten is zelfreferentieel

Vijf ronden van geketende hashing over 17 state-of-the-art hashing-algoritmen. Het algoritme en het herhalingstal van elke ronde worden afgeleid uit de uitvoer van de vorige ronde. De volgorde is data-afhankelijk — een ASIC die ontworpen is om snel te zijn in één algoritme wint niets als de keten via vijf andere routeert. We kijken uit naar de dag waarop Hashiverse zo succesvol is dat aangepaste ASIC's economisch genoeg worden om hem te dwarsbomen.

Bron: pow.rs

Quantum-bestendige identiteit, vandaag al vastgelegd

Elke identiteit bevat verbintenissen aan twee post-quantum sleutel-algoritmen (Falcon en Dilithium) naast de klassieke Ed25519-sleutel. Het opgradepad is in elke identiteit in het netwerk gebakken — vóórdat quantumcomputers bestaan. Twee onafhankelijke roosteraannames; beide moeten tegelijk breken. Kortom, jouw Hashiverse-identiteit zal niet breken als quantumcomputers mainstream worden.

Bron: keys_post_quantum.rs

Geen wachtwoorden, geen e-mail, geen probleem

Geen centrale servers betekent geen wachtwoorddatabase en geen e-mail om je mee te spammen. Je beheert je eigen sleutels — en we geven je drie manieren. Gastmodus: nul setup, alleen-lezen, gewoon beginnen met rondkijken. Sleutelzin: voer een wachtzin in, dezelfde zin geeft op elk apparaat dezelfde identiteit. Passkey: jouw vingerafdruk of Face ID wordt jouw sleutel via de secure enclave van je apparaat — hardware-ondersteund, gesynchroniseerd over apparaten, geen wachtwoorden te onthouden.

Bron: key_locker.rs, login/

Eén ciphertext, 32 sleutels

Berichten worden in rust en tijdens transport versleuteld. Geen gluren of nabewerking door duistere servers. Een enkel versleuteld bericht kan worden ontsleuteld door tot 32 verschillende wachtwoordzinnen — één per context waarin het verschijnt. De header is zelfbeschrijvend, dus elke toekomstige ontsleuteling reconstrueert de exacte versleutelingsconfiguratie alleen uit de ciphertext.

Bron: encryption.rs

Vijf lagen DDoS-verdediging voordat je de applicatiecode bereikt

Laag 1: PoW op elke RPC-envelope. Laag 2: per-IP-scoring met tijdsverval. Laag 3: per-IP-verbindingscap. Laag 4: zwarte lijst op IP op kernel-niveau wanneer de score de drempel overschrijdt. Laag 5: transport-time-outs voor TLS-handshake, header-lezing en body-lezing (Slow Loris-verdediging).

Bron: ipset_ddos.rs, config.rs

Draait op een $5-VPS — door ontwerp, niet bij toeval

Gecomprimeerde LSM-tree-opslag op schijf. Begrensde in-memory-caches. Lock-striped gelijktijdige schrijfacties. Probabilistische tellers voor trending (64 bytes per hashtag). En de DHT betekent dat elke server alleen data opslaat in de buurt van zijn eigen ID — niet het hele netwerk.

Bron: environment/, config.rs

Elke naad in het systeem is een uitwisselbare trait

Transport (mem-channels vs HTTP vs WASM-fetch). Tijd (echte klok vs 300×-versnelling). Opslag (IndexedDB vs in-memory). DDoS-bescherming (kernel-ipset vs in-memory-scoring). Sleutelbeheer (Web Crypto-enclave vs test-stubs). Wissel een van deze uit zonder de protocol-logica te raken. Tests gebruiken de goedkope; productie gebruikt de echte; zelfde code-pad.

Bron: transport/, time_provider/, environment/

Browser-PoW over geïsoleerde Web Workers

De WASM-client benut al je cores door proof-of-work over Web Workers te verdelen. Elke gelijktijdige PoW-job is geïsoleerd zodat ze elkaar niet kunnen verstoren. Resultaten overbruggen terug van JavaScript Promises naar Rust Futures. De hoofdthread van de browser raakt nooit een hash en wordt nooit trager.

Bron: wasm_parallel_pow_generator.rs

Healing verspilt nul bandbreedte

De client stuurt een header die beschrijft wat hij heeft. De server reageert met alleen de ID's die hij mist. De client stuurt precies die bytes. Als de server al alles heeft, is het een enkele heen-en-weer van headers.

Bron: dispatch.rs

Twee compressie-algoritmen, één versie-byte

LZ4 voor RPC-pakketten (snelheid). Brotli op maximale kwaliteit voor opgeslagen berichten (grootte). Een enkele leidende versie-byte maakt evolutie van het algoritme mogelijk zonder bestaande data te breken. Onder een minimumgrootte wordt compressie volledig overgeslagen — de overhead zou de besparingen overschrijden.

Bron: compression.rs

De recursieve bucket-visitor recursiet nooit

De tijdlijn-walker gebruikt expliciete stack-frames in plaats van functierecursie. Een callback op elk niveau beslist of er dieper gedrild, overgeslagen of gestopt wordt. Spaarzame tijdlijnen slaan geneste niveaus volledig over. Dichte tijdlijnen drillen alleen naar beneden waar inhoud bestaat.

Bron: recursive_bucket_visitor.rs