PROMARIS

Technologie

In Rust gebaut.

Kein WordPress. Kein PHP. Kein JavaScript-Framework. Diese Website ist — vom HTTP-Server bis zur Animation im Browser — vollständig in Rust geschrieben, typsicher kompiliert und als WebAssembly ausgeliefert.

Sprachanteile

Beim Build aus dem eigenen Quellbaum gemessen — inklusive dieser Seite.

Rust62,9 %
TOML26,8 %
SCSS10,3 %

Was nicht drin ist

0Zeilen handgeschriebenes HTML
0Zeilen JavaScript
0Zeilen PHP

Das HTML entsteht zur Laufzeit aus Rust-Code. Das einzige JavaScript ist die von der Rust→WebAssembly-Toolchain generierte Ladebrücke — davon schreiben wir keine Zeile selbst.

Eingesetzte Crates

Auf ein Crate zeigen blendet die ausführliche Erklärung ein. Ein Klick öffnet es auf crates.io — der offiziellen Paketregistrierung von Rust, inklusive Quellcode und Dokumentation. Nachlesen ausdrücklich erwünscht.

  • leptosReaktives Fullstack-UI (SSR + WASM)Leptos ist das Fullstack-Framework, auf dem diese Website aufbaut. Die Oberfläche wird als reaktive Komponenten in Rust beschrieben und sowohl auf dem Server gerendert (für eine schnelle erste Auslieferung und für Suchmaschinen) als auch im Browser als WebAssembly ausgeführt. Dieselbe Rust-Codebasis läuft damit auf beiden Seiten — ganz ohne separates JavaScript-Frontend.
  • leptos_routerRouting zwischen den SeitenDer Router von Leptos bestimmt, welche Seite zu welcher Adresse gehört. Seitenwechsel geschehen im Browser ohne vollständiges Neuladen, sodass die Navigation flüssig bleibt — während der Server jede Adresse zusätzlich direkt ausliefern kann.
  • leptos_metaTitel und Meta-Tags im <head>Verwaltet die Angaben im <head> des Dokuments: Seitentitel, Meta-Beschreibung und weitere Kopfdaten. So erhält jede Seite die richtigen Informationen für Browser-Tab, Suchmaschinen und Link-Vorschauen.
  • serdeSerialisierung der Inhalteserde ist das Standardwerkzeug in Rust, um Datenstrukturen zwischen Rust-Typen und Formaten wie TOML zu übersetzen. Hier verwandelt es die als Text hinterlegten Inhalte in typsichere Rust-Objekte — und bei Bedarf wieder zurück.
  • serde_jsonJSON-Serialisierungserde_json ist die JSON-Umsetzung von serde. Die Nachrichten der verschlüsselten API werden als JSON transportiert; dieses Crate wandelt sie zwischen Rust-Strukturen und JSON hin und zurück.
  • ml-kemPost-Quantum-Schlüsselkapselung (ML-KEM-1024, FIPS 203)ml-kem (RustCrypto) implementiert ML-KEM-1024 nach FIPS 203 — das von der US-Normungsbehörde NIST standardisierte Post-Quantum-Verfahren zur Schlüsselkapselung. Damit einigen sich Browser und Server auf ein gemeinsames Geheimnis, das auch gegen künftige Quantencomputer sicher sein soll. Es ist die Basis unserer zusätzlich verschlüsselten API.
  • kemTrait-Abstraktion für Schlüsselkapselung (KEM)Die schlanke Trait-Abstraktion (Encapsulate/Decapsulate), über die wir ml-kem ansprechen — sie hält den Krypto-Code sauber austauschbar.
  • chacha20poly1305Authentisierte Verschlüsselung (AEAD)ChaCha20-Poly1305 ist ein modernes AEAD-Verfahren (authentisierte Verschlüsselung). Es verschlüsselt jede API-Nachricht und stellt zugleich sicher, dass sie unterwegs nicht unbemerkt verändert werden kann.
  • hkdfSchlüsselableitung (HKDF)HKDF leitet aus dem rohen ML-KEM-Geheimnis einen sauberen, zweckgebundenen Sitzungsschlüssel ab (RFC 5869) — statt das Geheimnis direkt zu verwenden. Das schafft Domain-Separation und eine klare Prüf-Spur.
  • sha2SHA-512-Hashsha2 stellt die SHA-512-Hashfunktion bereit, auf der die Schlüsselableitung der verschlüsselten API (HKDF-SHA512) aufsetzt.
  • rand_coreKryptografischer Zufall (OsRng)rand_core liefert die kryptografisch sichere Zufallsquelle (OsRng). Im Browser stammt der Zufall aus der Web-Crypto-API — die Grundlage für Schlüssel und Nonces.
  • ed25519-dalekSignatur des Serverschlüssels (Ed25519)ed25519-dalek beglaubigt den Post-Quantum-Schlüssel des Servers. Ohne diese Unterschrift könnte ein zwischengeschaltetes System — ein CDN, ein Reverse-Proxy — seinen eigenen Schlüssel unterschieben und alles mitlesen. Ihr Browser prüft die Unterschrift gegen einen fest einkompilierten Prüfschlüssel, bevor er irgendetwas verschlüsselt; schlägt sie fehl, bricht er ab. Einen Rückfall auf „dann eben unsigniert“ gibt es nicht.
  • rand_chachaDeterministischer CSPRNG (ChaCha20)rand_chacha erzeugt einen kryptografisch sicheren Zufallsstrom nach dem ChaCha20-Verfahren — hier bewusst deterministisch: Aus einem einzigen hinterlegten Startwert leitet er immer dasselbe ML-KEM-Schlüsselpaar des Servers ab. Nur deshalb passt der Schlüssel, den Ihr Browser abholt, auch zu der Instanz, die danach Ihre Anfrage entschlüsselt. Echten Zufall — Nonces und die kurzlebigen Schlüssel Ihrer Seite — liefert dagegen rand_core.
  • base64Base64-Kodierungbase64 kodiert die binären Krypto-Bausteine (Schlüssel, Ciphertext, Nonce) als Text, damit sie sich bequem als JSON übertragen lassen.
  • leptos_wasiLeptos-SSR als wasi:http-Componentleptos_wasi verbindet das serverseitige Rendern und die Server-Funktionen von Leptos mit der wasi:http-Schnittstelle. Statt eines klassischen HTTP-Servers läuft die Serverseite dadurch als WebAssembly-Component in einer ringfreien WASI-Laufzeit (wasmtime) — Frontend wie Backend sind ein einziges Rust-Programm, beide als WebAssembly.
  • wasiWASI-Schnittstellen (wasi:http, Zufall)Die wasi-Bindings stellen die standardisierten WASI-Schnittstellen bereit, über die die Component mit ihrer Umgebung spricht — eingehende HTTP-Anfragen (wasi:http), Zufall (wasi:random) und Dateizugriff. TLS und Netzwerk übernimmt dabei die Laufzeit, nicht die Anwendung.
  • any_spawnerSingle-Thread-Future-Executorany_spawner stellt den Future-Executor, der die asynchrone Render-Arbeit der Component abarbeitet. WASI ist (noch) einfädig, daher ein schlanker, kooperativer Executor statt einer vielfädigen Laufzeit.
  • wakiHTTP-Client über wasi:httpwaki ist der HTTP-Client der Serverseite — umgesetzt über wasi:http statt über eine eigene TLS-Bibliothek. Eine Anfrage aus dem Kontaktformular legt er so als Ticket im Ticketsystem an, während die Verschlüsselung der Verbindung bei der WASI-Laufzeit liegt.
  • tomlInhalte als Code einlesenTOML ist ein schlankes, gut lesbares Textformat. Die Inhalte dieser Website liegen als TOML-Dateien vor; dieses Crate liest sie ein. Texte lassen sich so ändern, ohne Programmcode anzufassen — Inhalt als Code.
  • anyhowFehlerbehandlunganyhow vereinfacht die Fehlerbehandlung in Rust. Unterschiedliche Fehlerquellen werden zu einem einheitlichen Typ zusammengefasst, was den Servercode übersichtlich und robust hält.
  • httpHTTP-Basistypen (Status/Header)http liefert die grundlegenden HTTP-Typen (Statuscodes, Header, Methoden) als gemeinsame Sprache zwischen der Anwendung und der wasi:http-Schnittstelle.
  • bytesEffiziente Byte-Pufferbytes stellt effiziente, teilbare Byte-Puffer bereit — hier für die Körper eingehender Anfragen und ausgehender Antworten der WebAssembly-Component.
  • gloo-netHTTP-Anfragen im Browsergloo-net stellt HTTP-Anfragen direkt aus dem WebAssembly-Code. Damit holt der Browser den Server-Pubkey und sendet die verschlüsselten API-Requests.
  • console_error_panic_hookPanics in der Browser-KonsoleEin kleines Hilfsmittel für die WebAssembly-Seite: Tritt im Browser-Code ein unerwarteter Fehler (Panic) auf, wird er verständlich in der Entwicklerkonsole ausgegeben, statt stumm zu verschwinden — das erleichtert die Fehlersuche erheblich.
  • wasm-bindgenBrücke Rust ↔ Browserwasm-bindgen schlägt die Brücke zwischen dem in Rust geschriebenen WebAssembly und den Funktionen des Browsers. Es sorgt dafür, dass Rust-Code Browser-Schnittstellen aufrufen kann und umgekehrt — die Grundlage dafür, dass das Programm überhaupt im Browser läuft.
  • js-sysBrücke Rust ↔ JavaScriptjs-sys bildet die eingebauten Typen von JavaScript — Felder, Objekte, Promises — in Rust ab. Darüber greift der WebAssembly-Code auf das zu, was der Browser von Haus aus mitbringt: Eine Rechnung, die Sie ins Prüfwerkzeug legen, erreicht den Rust-Code als Byte-Feld über genau diese Brücke.
  • web-sysBrowser-APIs (Canvas u. a.)web-sys stellt die Programmierschnittstellen des Browsers als Rust-Funktionen bereit — etwa Fenster, Dokument oder Canvas. Damit zeichnet Rust unter anderem das animierte Splitterfeld direkt im Browser.

Verschlüsselte API (Post-Quantum)

Klassische Web-Verschlüsselung (RSA, elliptische Kurven) gilt heute als sicher — bis leistungsfähige Quantencomputer sie brechen. Wer heute schon mitgeschnittenen Datenverkehr aufbewahrt, könnte ihn dann rückwirkend entschlüsseln („harvest now, decrypt later“). Deshalb sichern wir die Verbindung zwischen Ihrem Browser und unserem Server zusätzlich mit einem Verfahren, das auch Quantencomputern standhalten soll.

Zum Einsatz kommt ML-KEM-1024 (FIPS 203) — das von der US-Normungsbehörde NIST standardisierte Post-Quantum-Verfahren für den Schlüsselaustausch. Diese Schicht liegt zusätzlich über der ohnehin aktiven TLS-Verschlüsselung: ein doppelter Boden, kein Ersatz.

  1. Schlüsselkapselung. Browser und Server einigen sich über ML-KEM-1024 auf ein gemeinsames Geheimnis — nach heutigem Stand auch gegen Quantencomputer sicher.
  2. Schlüsselableitung. Aus diesem Geheimnis wird per HKDF-SHA512 ein frischer Sitzungsschlüssel abgeleitet.
  3. Verschlüsselung. Jede Nachricht wird mit ChaCha20-Poly1305 authentisiert verschlüsselt. Der Client-Schlüssel ist fest an den Inhalt gebunden — so lässt sich die Antwort nicht heimlich umlenken.

Der folgende Handshake läuft gerade live in Ihrem Browser:

Kanal wird aufgebaut…

Wie diese Seite zu Ihnen kam

Diese Seite ist nicht irgendwo in einer Cloud entstanden. Sie wird in unserem eigenen Büro ausgeliefert — von einem Rust-Gateway auf echter Hardware. Der Weg dorthin ist kurz und real: Ihr Browser landet direkt auf einem von drei Internet-Ankern (Codenamen Caraxes · Meleys · Sunfyre), und der reicht die Anfrage an unser Büro-Gateway Balerion weiter. Kein CDN, kein fremder Edge-Dienst dazwischen — auf den Ankern läuft nur unser eigener TCP-Vorlauf, der die Verbindung ungeöffnet weitergibt. Dort endet der Weg: Balerion ist zugleich der WASI-Host, der diese WebAssembly-Component ausführt — sie hat genau diese Seite gerendert.

  1. EndpunktIhr Browser
  2. einer von drei AnkernCaraxes · Meleys · Sunfyre
  3. Büro-Gateway · führt diese Seite ausBalerion WASI-Host

Verbindung wird aufgebaut… Ohne JavaScript bleibt der Pfad oben als Liste bestehen — korrekt, nur ohne Live-Zahlen.

Wie es zusammenspielt

  1. Server. Dieselbe Rust-Codebasis läuft als WASI-WebAssembly-Component in der Laufzeit wasmtime (Ziel wasm32-wasip2) und rendert jede Seite vorab (SSR) — kein klassischer Server-Prozess, keine C-Krypto-Bibliothek.
  2. Inhalte. Texte liegen als Code vor und werden beim Start in eine In-Memory-Datenbank geladen.
  3. Browser. Dasselbe Rust-Programm läuft — zu WebAssembly übersetzt (Ziel wasm32-unknown-unknown) — im Browser weiter und übernimmt die Seite (Hydration). Seitenwechsel blenden per View-Transitions weich über, ganz ohne Neuladen.
  4. Grafik. Das Splitterfeld zeichnet Rust direkt auf ein Canvas — kein Bild, kein Video.
  5. Auslieferung. Jeder Build erzeugt eine neue WebAssembly-Component. Ausgeführt wird sie auf unserem eigenen Rust-Gateway auf echter Hardware im Büro — gerendert wird ausschließlich dort. Davor liegt kein CDN und kein Edge-Dienst; drei von uns betriebene Internet-Anker reichen den Verkehr durch, ohne ihn zu entschlüsseln.

Was der Build kostet

Gemessen beim Bauen genau dieser Component — nicht geschätzt und nicht aus einem Testlauf übernommen.

Kennzahlen nur in der ausgelieferten Component verfügbar.

Wie schnell es bei Ihnen lud

Kein Labor, kein Durchschnittswert: Diese drei Zahlen hat Ihr eigener Browser gemessen.

…

Das HTML kommt fertig gerendert vom Server — lesbar, noch bevor das WebAssembly überhaupt geladen ist. Deshalb steht die Seite auch dann, wenn das WASM nie ankommt.

Eine Website in Rust zu bauen ist ungewöhnlich — und genau das ist der Punkt. Wer eine Homepage so umsetzt, baut auch Ihre Systeme mit derselben Sorgfalt. Wenn Sie Technik auf diesem Niveau für Ihr Haus wollen: Sprechen Sie mit uns

Nach oben