DEV Community: numq

Kempo: Real-Time Audio Time-Stretching, Pitch-Shifting, and Formant Control in Pure Kotlin Multiplatform

numq — Wed, 14 Oct 2026 07:00:21 +0000

Zero-allocation streaming, phase-locked clarity, and multichannel spatial coherence across JVM, Android, iOS, and WebAssembly.

Whether you are building a podcast player with variable playback speed, a music practice app that slows down a complex guitar solo without dropping the tuning, a real-time voice modulator, or a spatial audio engine for a game, you eventually hit the same fundamental challenge: decoupling time from pitch.

In raw digital audio, playback speed and pitch are locked together. Play a buffer twice as fast, and the pitch jumps up a full octave. Slow it down, and everything drags into a muddy baritone.

Breaking that link—while keeping drums punchy, vocals natural, and the stereo image intact—requires a dedicated Digital Signal Processing (DSP) engine.

Meet Kempo (io.github.numq:kempo): an open-source, pure Kotlin Multiplatform audio time-stretching and pitch-shifting library built for studio-grade acoustic transparency and sub-millisecond real-time streaming across JVM, Android, iOS, and WebAssembly (Wasm/JS).

What Kempo Brings to Your Audio Stack

Kempo is designed to be drop-in simple for high-level application code while exposing full, granular control for low-level audio threads:

Independent Time, Pitch, and Formant Control: Speed up or slow down audio (0.25x to 3.0x and beyond), transpose musical pitch in semitones, and shift vocal timbre independently.
Zero-Allocation Real-Time Streaming: Once configured, the block-by-block processing loop allocates 0 bytes on the heap, eliminating Garbage Collection pauses on high-priority audio threads.
Vertical Harmonic Phase-Locking: Keeps transients crisp and eliminates the hollow, "underwater" phasing artifacts common in basic time-stretchers.
Multichannel & 5.1 Surround Coherence: Preserves exact inter-channel phase relationships across stereo and surround tracks so the soundstage never collapses.
Sample-Accurate Offline Rendering: Built-in pre-roll warm-up, algorithmic latency compensation, and automatic overlap-add tail flushing.
Built-In PCM-16 Serialization: Convert raw little-endian or big-endian WAV/PCM byte arrays directly into normalized floating-point tracks and back.

How Kempo Keeps Audio Crisp (Without the Artifacts)

If you have ever used a naive time-stretching algorithm, you probably recognize three classic audio defects: smeared drum hits, "chipmunk" vocals, and a collapsing stereo field. Kempo solves all three at the engine level.

1. Eliminating Transient Smearing with Vertical Phase-Locking

Standard phase vocoders split audio into hundreds of narrow frequency bins and advance the phase of each bin over time. Because each bin is updated in isolation, the natural harmonic alignment between a fundamental note and its overtones quickly drifts apart. Percussive attacks lose their snap, and instruments sound phasey and diffuse.

Kempo continuously analyzes the smoothed spectral energy contour of each frame to locate prominent spectral peaks. Instead of letting neighboring bins drift, Kempo performs vertical phase-locking—anchoring the phase trajectories of surrounding frequency bins to their dominant harmonic peaks. Harmonics move together as a unified acoustic event, keeping transients tight.

When stretching audio to extreme lengths (beyond 2.0x), Kempo automatically transitions into controlled stochastic phase dispersion, preventing the metallic ringing that usually plagues ultra-slow playback.

2. Fixing the "Chipmunk" Effect with Formant Decoupling

When you pitch a human voice up by +5 semitones, you aren't just raising the pitch of the vocal cords—you are also shrinking the perceived size of the singer's vocal tract. The result is the notorious "chipmunk" effect (or the "monster" effect when pitching down).

In Kempo, pitch and vocal timbre (formants) are decoupled. Kempo extracts the spectral envelope of the signal and allows you to shift or lock formants independently of the musical transposition:

Natural Pitch Shifting: Enable formant compensation (compensatePitch = true) to keep a singer's vocal tract resonance anchored while changing their melody.
Creative Voice Design: Shift formants up or down while keeping pitch at 0 st to transform the character and age of a voice without changing the note being sung.

3. Preserving Stereo Width and 5.1 Surround Imaging

Our ears localize sound in space by detecting tiny timing and phase differences between the left and right channels. If an audio processor stretches the Left and Right channels independently, their relative phases drift apart—causing the stereo image to wobble and center-panned vocals to hollow out when downmixed.

Kempo processes multichannel audio coherently. At every frequency band, it identifies the dominant channel and locks the Inter-channel Phase Differences (IPD) of all remaining channels to that reference. Whether you are processing a stereo master or a discrete 6-channel 5.1 surround mix, panning stays locked and center dialogue remains phase-aligned.

Getting Started

Kempo is published on Maven Central. Add the dependency to your build.gradle.kts:

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation("io.github.numq:kempo:1.0.0")
        }
    }
}

Or for a single-platform JVM/Android module:

dependencies {
    implementation("io.github.numq:kempo:1.0.0")
}

1. The One-Liner: Offline Track Processing

If you have raw 16-bit PCM bytes (from a WAV file, network stream, or microphone recording) and want to stretch or transpose them in a background coroutine, PcmConverter and AudioTrack handle the entire pipeline in a few lines:

import io.github.numq.kempo.PcmConverter

// 1. Decode interleaved 16-bit PCM bytes into a normalized [-1.0f, 1.0f] AudioTrack
val track = PcmConverter.fromPcm16(
    bytes = rawWavBytes,
    channels = 2,
    sampleRate = 44100f,
    isLittleEndian = true
)

// 2. Speed up by 25%, pitch up by 3 semitones, keep natural formants
val stretchedTrack = track.stretch(
    timeRatio = 1.25f,
    pitchSemitones = 3.0f,
    formantSemitones = 0.0f
)

// 3. Convert back to 16-bit PCM bytes for playback or file export
val outputBytes = PcmConverter.toPcm16(stretchedTrack, isLittleEndian = true)

2. Zero-Allocation Real-Time Streaming

Real-time audio callbacks operate under strict deadlines. Allocating arrays or objects inside the render loop will eventually trigger the garbage collector and cause audible clicks.

KempoStretch pre-allocates all ring buffers, FFT plans, twiddle factors, and spectral workspaces upfront during presetDefault() or configure(). Inside your audio callback, process() mutates pre-allocated buffers in place:

import io.github.numq.kempo.KempoStretch
import kotlin.math.max

class LiveAudioProcessor(
    channels: Int = 2,
    sampleRate: Float = 48000f
) {
    private val stretch = KempoStretch().apply {
        presetDefault(channels, sampleRate)
    }

    val outBlockSize: Int = stretch.defaultInterval
    private val outBuffer = Array(channels) { FloatArray(outBlockSize) }

    fun updateParameters(pitchSemitones: Float, formantSemitones: Float) {
        stretch.setTransposeSemitones(pitchSemitones)
        stretch.setFormantSemitones(formantSemitones, compensatePitch = true)
    }

    // Safe for high-priority audio threads: 0 B heap allocations
    fun processFrame(
        inputChannels: Array<FloatArray>,
        playbackSpeed: Float
    ): Array<FloatArray> {
        val inSamples = max(1, (outBlockSize * playbackSpeed).toInt())
        stretch.process(
            inputs = inputChannels,
            inputSamples = inSamples,
            outputs = outBuffer,
            outputSamples = outBlockSize
        )
        return outBuffer
    }
}

Need to support interactive scrubbing on a timeline without clicks or phase resets? Use stretch.seek() before resuming playback to pre-seed the internal phase accumulators with the audio frames right before the new cursor position:

val seekPreRoll = minOf(stretch.seekLength(), targetSampleIndex)
stretch.seek(
    inputs = track.channels,
    inputSamples = seekPreRoll,
    playbackRate = 1.0,
    inputOffset = (targetSampleIndex - seekPreRoll).coerceAtLeast(0)
)

3. Sample-Accurate Offline Rendering with `exact()`

When rendering an audio clip for a DAW timeline or a game asset pipeline, you often need the output buffer to match an exact target sample count—without leading silence from the STFT window latency or cut-off reverb tails at the end.

KempoStretch.exact() automates the entire offline lifecycle: it calculates the required pre-roll (outputSeekLength), warms up the vocoder state (outputSeek), processes the body of the track, and flushes the final synthesis tails (flush):

import io.github.numq.kempo.KempoStretch
import kotlin.math.roundToInt

fun renderExactClip(
    input: Array<FloatArray>,
    sampleRate: Float,
    timeRatio: Float,
    pitchSemitones: Float
): Array<FloatArray> {
    val channels = input.size
    val inSamples = input[0].size
    val outSamples = (inSamples / timeRatio).roundToInt().coerceAtLeast(1)
    val output = Array(channels) { FloatArray(outSamples) }

    val stretch = KempoStretch().apply {
        presetDefault(channels, sampleRate)
        setTransposeSemitones(pitchSemitones)
    }

    stretch.exact(
        inputs = input,
        inputSamples = inSamples,
        outputs = output,
        outputSamples = outSamples
    )
    return output
}

4. Custom Frequency Mapping & Tonality Limits

For experimental sound design, spectral effects, or specialized speech conditioning, Kempo lets you bypass standard semitone math entirely:

Tonality Limits: When transposing speech or vocals up, multiplying high-frequency sibilance ("s" and "sh" sounds) can make them sound lispy or artificial. Passing a tonalityLimit to setTransposeSemitones(semitones, tonalityLimit) transitions the upper spectrum from multiplicative harmonic scaling to a clean linear shift.
Custom Transfer Functions: Pass any lambda to setFreqMap to warp normalized frequencies [0.0f, 0.5f] non-linearly:

stretch.setFreqMap { normalizedFreq ->
    // Custom non-linear spectral warping
    (normalizedFreq * 1.15f).coerceIn(0f, 0.5f)
}

Engineered for Speed in Pure Kotlin

Writing high-throughput DSP in pure Kotlin without falling back to platform-specific C/C++ libraries requires careful attention to memory layout and CPU cache locality:

Flat Power-of-Two Ring Buffers (MultiChannelBuffer): Instead of nested object arrays or modulo arithmetic, Kempo backs all channels with a single flat FloatArray. Wrap-around indices are resolved via bitwise masks ((head + offset) and mask), and overlap-add accumulation uses 4x unrolled loops.
In-Place Mixed-Radix FFT (FastFft & ModifiedRealFFT): Supports radix-2, radix-3, radix-4, and composite window sizes with precomputed twiddle tables. Real signals are evaluated on a half-bin shifted grid (k + 0.5) / N, avoiding DC and Nyquist edge singularities and cutting transform overhead in half.
Split Computation Mode (split = true): In real-time audio, doing a full STFT analysis and synthesis every N samples can cause periodic CPU spikes. Enabling split = true in configure() or presetCheaper() slices the spectral workload into small incremental steps distributed evenly across every sample frame.
Automatic Silence Bypass: When input energy drops below the noise floor, Kempo automatically bypasses heavy spectral math while keeping ring buffers synchronized.

In JMH benchmarks on standard desktop JVM hardware (44.1 kHz audio), Kempo processes a real-time streaming block in ~220 μs (mono) and ~484 μs (stereo), and renders offline audio at over 128x real-time speed for mono and ~70x real-time for stereo.

Try It Live: The Compose Desktop Studio App

Want to hear how Kempo handles your own audio files before writing a line of code?

The repository includes an interactive Compose Multiplatform Desktop Studio application (:example). Drop any .wav file onto the window to inspect its waveform, scrub through the timeline in real time, and tweak live parameters on the fly:

Playback Speed (0.25x – 3.00x) with instant presets (0.50x, 0.75x, 1.25x, 1.50x, 2.00x)
Pitch Shift (-12 st to +12 st) in semitone steps
Formant Shift (-12 st to +12 st) for real-time vocal timbre shaping

Explore the Code

Check out the full source code, architecture docs, and the runnable CLI attack simulation on GitHub.

Why HTTPS Won’t Save Your Checkout Flow: Building Zero-Trust State Machines in Kotlin Multiplatform

numq — Wed, 14 Oct 2026 06:26:49 +0000

How to protect multi-step workflows, fintech funnels, and Server-Driven UI from step-skipping, state tampering, and replay attacks — with zero runtime dependencies.

Imagine a standard e-commerce checkout flow: Shopping Cart → Shipping Address → Promo Code → Payment Authorization.

You use HTTPS. You validate JWT tokens on every request. Your backend endpoints are covered with unit tests. You feel safe.

Then someone opens your app on a rooted device, hooks into memory with Frida, or simply manipulates an internal deep link. Instead of going from Cart to Shipping (where a $50 express delivery fee is calculated), the client dispatches a transition straight from Cart to Payment. Or worse, in a Server-Driven UI (SDUI) flow, an attacker replays a cached JSON payload from five minutes ago where a KYC verification flag was temporarily set to true.

HTTPS only encrypts the pipe. JWTs only verify who is holding the token. Neither guarantees that your client-side state machine actually followed the legal sequence of steps to reach its current screen.

To fix this at the architectural level without littering business logic with endless if-else checks, I built TrustChain — a pure functional, cryptographically verifiable state machine ledger for Kotlin Multiplatform (KMP).

The Mental Model: Think "Git Commits" for Your App State

You don’t need a PhD in cryptography or heavy blockchain consensus algorithms to secure a user journey. You just need strict lineage.

Think about how Git works: every commit contains a hash of its own content plus the exact hash of the parent commit. If you try to alter history or insert a commit out of nowhere, the hashes don't match, and Git rejects the tree immediately.

TrustChain brings this exact mechanism to your application’s navigation and state stack:

Every screen or workflow step has a unique hash representing its current state, and a previousHash pointing to the exact step that preceded it.
When the user moves forward, the incoming step’s previousHash must match the hash of the currently active step on top of the stack.
Partial state updates (like applying a promo code or updating live order status over WebSockets) arrive as signed deltas (DeltaBlock). They verify the current hash, check the server’s asymmetric digital signature, mutate the state, and verify the new hash.

If an attacker tries to skip a screen, inject a fake discount, or replay an old state, the hash chain breaks. The state machine fails fast before a single pixel is rendered or a network call is fired.

Security Concern	Standard REST + HTTPS	JWT Tokens	TrustChain
Data In-Transit Encryption	Yes (TLS)	Yes (TLS)	Yes (TLS)
Prevent Step Skipping (Deep Links)	No (Complex backend checks)	No	Yes (Parent Hash Check)
Detect Tampered State Deltas	No	Partially	Yes (Asymmetric Signatures)
Replay Attack Prevention	Manual nonces required	No	Yes (Strict Hash Lineage)
Zero Runtime Dependencies	N/A	Often heavy	Yes (Pure KMP)

Designing for Zero Bloat: The Core Primitives

One of my main goals with TrustChain was keeping the core completely free of third-party runtime dependencies so it drops cleanly into Android, iOS, Desktop, Web, or backend KMP targets.

1. `VerifiableBlock`

Any screen, workflow step, or state snapshot in your domain simply implements a three-property interface:

interface VerifiableBlock {
    val id: String
    val hash: String
    val previousHash: String? // null only for the root (genesis) step
}

2. `DeltaBlock` (Signed Partial Updates)

Why re-fetch an entire screen when a user applies a 10% coupon or an order changes status? Instead of sending full state trees, the server sends a lightweight DeltaBlock:

@Serializable
data class DeltaBlock<P>(
    @SerialName("patches") val patches: P,
    @SerialName("previous_hash") val previousHash: String,
    @SerialName("new_hash") val newHash: String,
    @SerialName("signature") val signature: String = ""
)

Notice how DeltaBlock locks the mutation from both sides:

It can only be applied if the client is currently sitting on previousHash.
Its newHash is signed by the server's private key (RSA, Ed25519, or ECDSA).
Once the client applies patches via a BlockPatcher, the resulting block must produce newHash.

3. Pure Functional Reduction

TrustChain is completely immutable. There are no hidden side effects, mutable singletons, or uncaught exceptions flying across coroutines. You send a ChainEvent (Push, Pop, Replace, or ApplyDeltas), and reduce() returns a standard Kotlin Result:

sealed interface ChainEvent<out B : VerifiableBlock, out P> {
    data class Push<B : VerifiableBlock>(val block: B) : ChainEvent<B, Nothing>
    data object Pop : ChainEvent<Nothing, Nothing>
    data class Replace<B : VerifiableBlock>(val block: B) : ChainEvent<B, Nothing>
    data class ApplyDeltas<P>(val blocks: List<DeltaBlock<P>>) : ChainEvent<Nothing, P>
}

If a batch of 5 deltas is applied and the 4th delta has a broken hash link or invalid signature, atomicity is preserved — the entire reduction fails cleanly with a typed ChainError, leaving your original TrustChain untouched.

Real-World Walkthrough: The Unbreakable Checkout

Let’s look at how this works in practice using a multi-step checkout flow.

First, we define our domain step:

@Serializable
data class CheckoutStep(
    override val id: String,
    val title: String,
    val state: Map<String, String> = emptyMap(),
    override val hash: String,
    override val previousHash: String? = null
) : VerifiableBlock

Next, we initialize TrustChain on the client. Notice how cryptography and state patching are injected via simple functional interfaces (SignatureVerifier and BlockPatcher). You aren't locked into any specific crypto library:

var clientChain = TrustChain<CheckoutStep, Map<String, String>>(
    strictMode = true,
    verifier = SignatureVerifier { payload, signatureBase64 ->
        // Plug in your platform's Ed25519 / RSA / ECDSA verifier
        CryptoEngine.verify(serverPublicKey, payload, signatureBase64)
    },
    patcher = { step, patches, newHash ->
        step.copy(
            state = step.state + patches,
            hash = newHash
        )
    }
)

The Legitimate User Journey

As the user progresses through the checkout, every step returned by the server references the exact hash of the previous state:

// 1. User opens the Shopping Cart (Genesis block, previousHash = null)
val cartStep = server.startCheckout(sessionId)
clientChain = clientChain.reduce(ChainEvent.Push(cartStep)).getOrThrow()
// Active: Shopping Cart | Hash: h_c2c1a28598b8ad69

// 2. User confirms Shipping Address (Chained to Cart's hash)
val shippingStep = server.submitShipping(sessionId, "Baker St 221B")
clientChain = clientChain.reduce(ChainEvent.Push(shippingStep)).getOrThrow()
// Active: Shipping & Address | Hash: h_50bda3ba68cced0d | Prev: h_c2c1a28598b8ad69

// 3. User applies a 10% Promo Code (Signed DeltaBlock mutation)
val promoDelta = server.applyPromoCode(sessionId, "10%")
clientChain = clientChain.reduce(ChainEvent.ApplyDeltas(listOf(promoDelta))).getOrThrow()
// Active: Shipping & Address (Patched) | New Total: $1890 | New Hash: h_6471c5f0c53a644b

// 4. User proceeds to Payment (Chained to the patched Shipping hash)
val paymentStep = server.proceedToPayment(sessionId)
clientChain = clientChain.reduce(ChainEvent.Push(paymentStep)).getOrThrow()
// Active: Payment Authorization | Hash: h_6a6fd155e392f7ef

Simulating the Attack: Skipping Shipping

Now, let’s see what happens when an attacker loads the Cart (h_c2c1a28598b8ad69) and tries to jump straight to the paymentStep (bypassing shipping calculation):

var attackedChain = TrustChain<CheckoutStep, Map<String, String>>(strictMode = true)
attackedChain = attackedChain.reduce(ChainEvent.Push(cartStep)).getOrThrow()

// Attacker tries to force-push the Payment step directly onto the Cart
val attackResult = attackedChain.reduce(ChainEvent.Push(paymentStep))

attackResult.fold(
    onSuccess = {
        println("VULNERABILITY: Attack succeeded!")
    },
    onFailure = { error ->
        when (error) {
            is ChainError.HashMismatch -> {
                println("[!] BLOCKED BY TRUSTCHAIN: State machine integrity preserved.")
                println("    Expected parent: ${error.expected}, Actual: ${error.actual}")
            }
            is ChainError.SignatureVerificationFailed -> {
                println("[!] BLOCKED: Invalid server signature for block ${error.blockHash}")
            }
            else -> println("[!] Blocked: ${error.message}")
        }
    }
)

Console Output:

------------------------------------------------------
  Simulating Attack: Attacker tries to skip shipping  
------------------------------------------------------
Attacker has Cart loaded.
Attacker attempts to directly apply Payment step (bypassing Shipping)...
[!] BLOCKED BY TRUSTCHAIN: State machine integrity preserved.
Expected parent: h_c2c1a28598b8ad69, Actual: h_6471c5f0c53a644b

Because paymentStep expects its parent to be the patched shipping step (h_6471c5f0c53a644b), pushing it onto the cart (h_c2c1a28598b8ad69) triggers an immediate ChainError.HashMismatch. The state transition is rejected atomically.

Built for Developer Ergonomics

Security tools often fail because they make local development painful. Nobody wants to spin up a signing server just to preview a Compose Multiplatform screen or write a quick UI test.

That’s why TrustChain includes a strictMode flag:

strictMode = true (Default / Production): Enforces parent hash lineage on Push and Replace, verifies digital signatures via SignatureVerifier, and ensures BlockPatcher updates block hashes accurately.
strictMode = false (Previews / UI Prototyping): Bypasses cryptographic and lineage checks while keeping the exact same ChainEvent reducer API, allowing you to mock and jump between screens freely during development.

Where Does TrustChain Shine?

Server-Driven UI (SDUI): Guarantee that screens and dynamic patches pushed by the backend are rendered in the exact sequence intended by the server.
E-Commerce & Checkouts: Make it impossible to bypass delivery calculation, tax steps, or terms acceptance before payment.
Fintech & Banking: Enforce strict step ordering for wire transfers, credit limit increases, and multi-factor challenges.
KYC & Onboarding Funnels: Maintain a verifiable, tamper-proof progression through document capture and liveness checks.

Try It in Your Project

TrustChain is open-source under the Apache 2.0 License and published directly to Maven Central.

Check out the full source code, architecture docs, and the runnable CLI attack simulation on GitHub.

Stop Trusting Your UI: Why Zero-Trust Server-Driven UI is the Next Industry Standard

numq — Tue, 28 Jul 2026 11:55:41 +0000

TLS is not enough. Your JSON payloads are a ticking time bomb. Here is how Blueprint makes UI manipulation mathematically impossible - and why your compliance team will soon demand it.

Part 1: The Billion-Dollar Blind Spot

Server-Driven UI won. Airbnb, Spotify, and Uber proved that shipping UI from the backend gives you superpowers: instant A/B tests, zero-day fixes, and a single source of truth for business logic. The industry is racing to adopt it.

But there's a problem nobody talks about at conferences: you've moved your business logic to the wire, but your security model is still "pray the TLS holds."

Skeptical? Think TLS is a silver bullet? In the real world, TLS is routinely bypassed or terminated early. SSL inspection on corporate devices (Enterprise MDM), compromised edge nodes or CDNs, malicious proxy extensions, and internal lateral movement within your own microservice architecture can all manipulate traffic while it's in plain text.

This isn't theoretical. OWASP Mobile Top 10 lists "Insufficient Cryptography" (M9) as a critical vulnerability. NIST SP 800–207 defines Zero Trust Architecture as the gold standard. And PSD3 is pushing financial apps toward cryptographic proof of transaction integrity - including the UI that initiates those transactions.

Imagine this real-world attack:

User taps: [ ☕ Buy Coffee - $5.00 ]

🔴 Traditional SDUI (Vulnerable)

Server → MITM Proxy / Compromised CDN → Client
Original payload: "action": "api/charge?amount=5"
Modified payload: "action": "api/charge?amount=5000"
The button still says "Buy Coffee"
The user sees nothing suspicious
Result: $5,000 leaves their account

🟢 Blueprint Zero-Trust SDUI (Immune)

Server → [RSA Signature + Hash Chain] → Client
Client checks: incoming.previousHash == current.hash
Client checks: RSA.verify(newHash, signature)
Modified payload? → MISMATCH - rejected
Replayed payload? → BROKEN CHAIN - rejected
Result: UI refuses to render, attack neutralized

The difference is mathematical proof versus blind faith. And in regulated industries - FinTech, Healthcare, Enterprise - regulators are already asking the question: "How do you guarantee the UI your customer sees is exactly what your backend generated?"

Blueprint is the answer. It's not just another SDUI framework. It's a cryptographic protocol for user interfaces.

Part 2: The Blueprint Chain - Your UI on a Blockchain

Blueprint treats every screen as a block in an immutable chain. The client doesn't "request a screen." It validates a state transition.

Hash Chaining: Every Screen Knows Its Parent

// Core data model - note the cryptographic fields
@Serializable
data class Blueprint(
    val id: String,
    val state: Map<String, String> = emptyMap(),
    val root: BlueprintNode,
    val hash: String = "",           // SHA-256 of this screen's content
    val previousHash: String? = null // Cryptographic link to previous screen
)

When the server pushes a new screen, the client executes:

// BlueprintChain.kt - the zero-trust gatekeeper
is ChainEvent.Push -> when {
    strictMode && links.isNotEmpty() -> when (val currentHash = current?.hash) {
        event.blueprint.previousHash -> 
            copy(links = links + event.blueprint).right() // ✅ Chain intact

        else -> ChainError.HashMismatch(
            expected = currentHash ?: "null",
            actual = event.blueprint.previousHash
        ).left() // 🚫 Chain broken
    }
}

This is the gamechanger. You cannot inject a phishing screen. You cannot replay an old "success" screen to hide an error. The chain must be unbroken, or the UI stops dead.

Performance That Does Not Sacrifice UX

Security like this must be invisible to the user. Blueprint delivers:

Performance impact - imperceptible to users:

SHA-256 hashing (1 KB payload): < 0.3 ms - negligible
RSA-2048 signature verification: < 2.1 ms - imperceptible
Full chain push + verify: < 3.8 ms - single frame at 60 FPS
State delta apply + verify: < 2.5 ms - sub-frame

All verification happens locally. No network calls. No server round-trips. The chain validates on-device, ensuring zero latency impact on navigation.

State Deltas with RSA Signatures: Surgical, Signed Updates

Full screen reloads are wasteful. Blueprint uses StateDeltaBlock for surgical state patches:

@Serializable
data class StateDeltaBlock(
    val patches: Map<String, String>,  // Only the changed key-value pairs
    val previousHash: String,          // Must match current state hash
    val newHash: String,               // Hash of the new state
    val signature: String              // RSA-signed by server's private key
)

The verification is absolute:

strictMode && verifier != null && !verifier.verify(
    payload = block.newHash,
    signatureBase64 = block.signature
) -> ChainError.SignatureVerificationFailed(blockHash = block.newHash).left()

Even if an attacker compromises your CDN, they cannot forge a valid StateDeltaBlock. The RSA private key lives in your Hardware Security Module or Vault. The client holds only the public key. Without a valid signature, the state machine returns Either.Left(ChainError) - a type-safe rejection that never crashes the app, but definitively blocks the tampered update.

Key rotation is built in. The SignatureVerifier interface supports pinning multiple public keys simultaneously, enabling graceful rotation during security incidents without breaking existing clients.

This is what enterprise security teams dream about: mathematical proof that every state transition is authorized.

Part 3: Developer Experience Without Compromise

"Security is critical. But if the developer experience isn't frictionless, adoption dies in the pull request."

We heard that. Blueprint wraps its cryptographic engine in a Kotlin DSL so natural, it feels like writing Compose.

Server: Build UIs Like You're Writing Jetpack Compose

// Ktor backend - type-safe, auto-completed, cryptographically secure
val ordersScreen = blueprint("order_list") {
    metadata(title = "My Orders", description = "Active orders")

    // Server-owned state that drives dynamic UI
    state("total_orders" to "5", "username" to "John")

    root {
        Column(
            verticalArrangement = LayoutArrangement.START, modifiers = {
                background("#F8F9FA")
                fillMaxSize()
            }) {
            // Binds to state["username"] - server changes this instantly
            Text(
                content = bindString("username"), size = TextSize.HEADLINE_LARGE
            )

            LazyColumn(contentPadding = 24f) {
                Card(
                    variant = CardVariant.FILLED,
                    onClickIntentId = "navigate_detail:1",
                    modifiers = { cornerRadius(20f); padding(bottom = 16f) }) {
                    Text("Order #1", size = TextSize.TITLE_MEDIUM)
                }
            }

            Button(
                text = "Refresh", variant = ButtonVariant.FILLED, onClickIntentId = "refresh_orders"
            )
        }
    }
}

// One line to seal it cryptographically
val signedBlueprint = CryptoUtils.createSignedBlueprint(ordersScreen, currentHash)

No manual hashing. No signature boilerplate. The framework handles the chain automatically.

Client: Native Compose Rendering with Built-in Verification

@Composable
fun Application(store: ApplicationStore) {
    val state by store.state.collectAsState()

    val renderer = remember { createDefaultBlueprintRegistry() }

    MaterialTheme {
        when (val blueprint = state.chain.current) {
            null -> LoadingScreen()

            else -> renderer.render(blueprint = blueprint, intentHandler = { intent -> store.dispatch(intent) })
        }
    }
}

The BlueprintComposeRegistry maps ComponentPayload directly to Material 3 Compose components. No WebViews. No JavaScript bridges. 100% native rendering, 100% cryptographically verified.

Part 4: Pure Functional Core - Predictable, Testable, Crash-Free

Blueprint's state machine is built on pure functional programming principles. Every operation returns Either<ChainError, BlueprintChain> - a monadic type that makes failure a first-class citizen, not an exception.

// ApplicationStore.kt - the entire state reduction pipeline
private fun handleResolution(resolution: Resolution) {
    val events = buildList {
        resolution.effects.forEach { effect ->
            when (effect) {
                is Effect.Navigation -> {
                    when (effect.type) {
                        Type.PUSH -> effect.blueprint?.let { add(ChainEvent.Push(it)) }
                        Type.REPLACE -> effect.blueprint?.let { add(ChainEvent.Replace(it)) }
                        Type.POP -> add(ChainEvent.Pop)
                    }
                }
            }
        }
        if (resolution.deltaBlocks.isNotEmpty()) {
            add(ChainEvent.ApplyDeltas(resolution.deltaBlocks))
        }
    }

    // Fail-fast monadic fold - any error halts the entire chain update
    _state.update { currentState ->
        when (val result = events.foldEither(currentState.chain) { chain, event ->
            chain.reduce(event)
        }) {
            is Either.Left -> {
                // Security breach or navigation error - safe, typed, no crash
                currentState.copy(
                    error = "Chain integrity violation: ${result.value}", isLoading = false
                )
            }

            is Either.Right -> {
                // All transitions validated, chain updated atomically
                currentState.copy(chain = result.value, isLoading = false)
            }
        }
    }
}

This architecture gives you:

Deterministic behavior - same inputs always produce same outputs.
Trivial unit testing - no mocking, just data in, data out.
Zero runtime crashes from invalid state - Either enforces error handling at compile time.
Mathematical immunity to garbage payloads - because the state machine is purely functional and strictly typed, it is mathematically impossible for a malicious payload to force the UI into an undefined, exploitable state. If the payload doesn't fold cleanly into the existing chain, the transition simply doesn't happen.

Part 5: Why This Becomes the Standard

The trajectory is clear:
2024: Regulators in EU and US signal stricter requirements for financial app integrity.
2025: Major banks mandate cryptographic proof of UI authenticity in vendor RFPs.
2026: Zero-Trust SDUI becomes an industry compliance checkbox - like SOC 2 or PCI DSS.

Blueprint is ready today. It's the only Kotlin Multiplatform framework that:

✅ Treats UI as a cryptographically verifiable state machine
✅ Provides hash chaining to prevent screen injection and replay attacks
✅ Signs all state mutations with industry-standard RSA
✅ Delivers native Compose performance on Android, iOS, and Desktop
✅ Offers a type-safe DSL that eliminates an entire class of serialization bugs
✅ Aligns with NIST SP 800–207 Zero Trust Architecture principles
✅ Supports key rotation for enterprise key management policies

This is not a niche security feature. It's the missing layer between "dynamic UI" and "auditable UI."

Security FAQ

Q: Does this add latency to navigation?
A: No. All verification is local. SHA-256 hashing adds < 0.3ms. RSA signature verification adds < 2ms. The entire chain validation completes in under 4ms - less than a single frame at 60 FPS.

Q: What if the private key leaks?
A: Same as any PKI system - key rotation. Blueprint's SignatureVerifier interface supports pinning multiple public keys simultaneously. During rotation, the server signs with the new key while clients accept both old and new public keys. Once all clients update, the old key is revoked.

Q: Does this work offline?
A: The chain validates locally with zero network calls. Navigation between cached screens is fully verified offline. Only new state mutations require fresh server signatures - exactly like JWT validation, but for your UI.

Q: Can I use this without the cryptographic features?
A: Yes. Set strictMode = false and the chain operates as a standard navigation stack. You can adopt the SDUI patterns first, then enable cryptographic verification when your compliance requirements demand it.

Q: What attack vectors does this actually prevent?
A: Blueprint prevents five critical attack classes:

Payload injection - Malicious screens inserted via compromised CDN or proxy
UI replay attacks - Old "success" screens replayed to hide errors or fraud
State tampering - Runtime modification of bound values (account numbers, amounts)
Screen spoofing - Phishing screens injected into the navigation flow
Internal lateral movement - Compromised microservice injecting malicious UI payloads

Getting Started

Blueprint is open-source under Apache 2.0. The repository includes a fully functional example with a Ktor backend and Compose Desktop client demonstrating the complete cryptographic flow.

→ GitHub Repository
→ Full Documentation & Architecture Guide
→ Example: Order Tracking App with Zero-Trust Chain

The Bottom Line

Every time you deserialize a JSON UI payload without cryptographic verification, you're handing a blank check to any attacker who compromises your transport layer. TLS encrypts the pipe. It doesn't prove the payload is authentic.

Blueprint changes the equation. It transforms your client from a "trusting renderer" into a verifying validator - mathematically certain that every pixel, every button, every state transition originates from your authorized backend.

Don't take my word for it. Clone the repository, launch the example app, and try to intercept and modify the JSON payload on the fly using Charles Proxy or Proxyman. You'll see Blueprint stop the attack dead in its tracks.

Don't just ship dynamic UIs. Ship verifiable UIs. Ship Blueprint.

Building High-Performance Text Editors in Kotlin Multiplatform with Krope

numq — Fri, 24 Jul 2026 13:02:16 +0000

If you have ever tried building a text editor, an IDE, or a collaborative document tool, you quickly run into a fundamental wall: how do you store the text?

At first glance, a standard String seems fine. But Strings are immutable; changing a single character in a 1MB file requires allocating a brand new 1MB array. So, you move to StringBuilder. It’s mutable and fast for simple appends, but inserting or deleting text in the middle of a massive document still requires shifting hundreds of thousands of characters in memory — an O(N) operation that causes UI stuttering as your document grows.

This is where the Rope data structure comes in.

Today, I want to introduce Krope, a high-performance, memory-safe, and reactive Rope library built entirely in Kotlin Multiplatform. Whether you are targeting JVM, Android, iOS, or WASM, Krope provides the engine you need to build next-generation text editing tools.

What is a Rope?

Instead of storing text as a single massive, contiguous array of characters, a Rope stores text as a balanced binary tree (in Krope’s case, utilizing a Red-Black tree variant). The leaves of the tree contain short chunks of strings.

When you insert text in the middle of a document, a Rope doesn’t copy the whole string. Instead, it splits a leaf node and inserts a new branch. This gives operations like insertion, deletion, and replacement a time complexity of O(log N).

Furthermore, Krope implements structural sharing. When a modification occurs, Krope doesn’t mutate the existing tree; it returns a new tree that shares the untouched branches with the old one. This provides safe concurrent access, cheap undo/redo history.

Why I Built Krope

The idea for Krope was born while building haskcore — a full-featured IDE for Haskell written in Compose Desktop. It uses Skia for rendering, Tree-sitter for incremental syntax parsing, and the Language Server Protocol for code intelligence. It’s a real editor with 40+ modules, handling everything from syntax highlighting to code completion and project-wide diagnostics.

Very quickly, I hit a wall: Kotlin’s standard StringBuilder couldn't keep up. Editing large Haskell modules meant shifting massive text buffers on every keystroke, causing visible lag during syntax highlighting and LSP synchronization. I needed something better — and the rope data structure, battle-tested in editors like Emacs and Vim since the 90s, was the obvious answer.

But Kotlin Multiplatform lacked a modern, reactive, and fully-featured rope implementation. So I built Krope to solve the specific pain points I encountered:

Cross-Platform Consistency: haskcore targets the desktop, but the same text engine should work on Android, iOS, and WASM for future ports or companion apps.
Reactive by Design: Compose Multiplatform thrives on reactive state. Krope exposes every edit as a SharedFlow event and every document state as a StateFlow, making UI integration seamless.
Byte-Level Encoding Awareness: LSP servers speak in byte offsets, not character positions. Krope natively tracks UTF-8, UTF-16, and UTF-32, giving you efficient access to byte coordinates backed by an LRU cache.
Functional & Safe: Invalid operations shouldn’t crash your editor. Krope uses an Either<Throwable, Result> pattern, so out-of-bounds inserts return errors you can handle gracefully — critical when processing remote edits from LSP or collaborative peers.

Inside the Krope API

Krope separates the underlying data structure from the editor API. The primary interface you interact with is the TextBuffer.

Here is how simple it is to get started:

import io.github.numq.krope.core.Encoding
import io.github.numq.krope.text.*
import kotlinx.coroutines.launch

// 1. Initialize the buffer
val factory = RopeTextBufferFactory()
val buffer = factory.create(
    text = "Hello World",
    encoding = Encoding.UTF8,
    lineEnding = TextLineEnding.LF,
    enablePooling = true // Enables internal string interning to save memory
).fold(
    onLeft = { error -> throw error },
    onRight = { it }
)

The Reactive Paradigm

In a standard text editor, the UI needs to know exactly what changed to update the screen or send a diff over the network for collaborative editing. Krope exposes two flows:

snapshot: StateFlow<TextSnapshot>: Represents the immutable current state of the document.
data: SharedFlow<TextEdit.Data>: Emits granular events whenever the text changes.

// Observe all changes in real-time
launch {
    buffer.data.collect { editData ->
        when (editData) {
            is TextEdit.Data.Single.Insert -> 
                println("Inserted '${editData.insertedText}' at ${editData.startPosition}")
            is TextEdit.Data.Single.Delete -> 
                println("Deleted text ending at ${editData.oldEndPosition}")
            is TextEdit.Data.Single.Replace -> 
                println("Replaced '${editData.oldText}' with '${editData.newText}'")
            is TextEdit.Data.Batch -> 
                println("Batch processed ${editData.singles.size} operations atomically")
        }
    }
}

Line and Column Awareness

Most ropes just deal with raw character offsets. Krope natively understands Lines and Columns through TextPosition.

// "Hello Beautiful World"
buffer.insert(TextPosition(line = 0, column = 5), " Beautiful")

// Querying the snapshot is instantaneous thanks to cached tree node metadata
val snapshot = buffer.snapshot.value
println("Total Lines: ${snapshot.lines}")
println("Max Line Length: ${snapshot.maxLineLength}")

// Get byte offset for an LSP (Language Server Protocol)
val byteOffset = snapshot.getBytePosition(TextPosition(line = 0, column = 6))

Atomic Batch Operations

When you refactor code (like renaming a variable that appears 10 times in a file), you don’t want to trigger 10 separate UI redraws or clutter the undo stack. Krope supports withBatch:

buffer.withBatch { batch ->
    batch.replace(TextRange(TextPosition(0, 39), TextPosition(0, 42)), "vatAmount")
    batch.replace(TextRange(TextPosition(1, 19), TextPosition(1, 22)), "vatAmount")
}

This applies all edits internally, rebalances the tree once, and emits a single TextEdit.Data.Batch event to your listeners.

Performance: The 100 Megabyte Test

To answer the age-old question - "How does it perform with very large files?" - I ran JMH benchmarks on the JVM comparing Krope to StringBuilder.

We simulated the "Real Editor Scenario": 100 consecutive edits (insertions) occurring right in the middle of a document. We scaled the document size from 100,000 characters all the way to 100,000,000 characters (approximately 200 MB of text).

Here are the results (in milliseconds per 100 operations):

100,000 symbols

Krope: ~0.05 ms
StringBuilder: ~0.16 ms
Krope Advantage: ~3x faster

1,000,000 symbols

Krope: ~0.19 ms
StringBuilder: ~1.74 ms
Krope Advantage: ~9x faster

10,000,000 symbols

Krope: ~2.07 ms
StringBuilder: ~17.86 ms
Krope Advantage: ~8.5x faster

100,000,000 symbols

Krope: ~19.32 ms
StringBuilder: ~186.41 ms
Krope Advantage: ~9.6x faster

Why does StringBuilder choke?

Look at how the StringBuilder time multiplies by 10 every time the file size multiplies by 10. This is the curse of O(N) complexity. When you insert a single character in the middle of a 200MB StringBuilder, Java has to use System.arraycopy to physically shift 100MB of data in RAM to make room. Doing this 100 times forces the CPU to move 10 gigabytes of memory. This is exactly what causes UI thread stuttering and input lag in text editors.

Why does Krope win?

Because of structural sharing and its Red-Black tree foundation. When making 100 edits, Krope doesn't copy 100MB of arrays. It simply splits a small leaf node, updates a few pointers up to the root, and does a lightning-fast O(log N) tree rebalance.

(Note: In the benchmark above, the ~19.32 ms for Krope actually included the time to parse the 200MB string into a Rope tree from scratch on every iteration! The edits themselves are nearly instantaneous).

In a real-world typing or refactoring scenario, Krope maintains incredibly flat, predictable latency regardless of whether your file is 10 Kilobytes or 200 Megabytes, keeping your UI perfectly smooth while drastically reducing heap allocations.

Get Involved

If you are building text-heavy applications in Compose Multiplatform, writing a code editor, or experimenting with CRDTs for collaborative editing, give Krope a try.

The architecture is highly modular, separating the core data structures from the TextBuffer API, and includes built-in support for kotlinx.serialization.

Check out the source code, play with the examples, and star the repository on GitHub!

🔗 GitHub Repository: Krope

JetBrains Just Changed KMP Structure. Here's What They Didn't Tell You.

numq — Mon, 18 May 2026 18:18:29 +0000

JetBrains announced a new default project structure for KMP. Two shared modules — sharedLogic and sharedUI — plus separate application modules for each platform. Clean. Simple. Obvious.

It's also a trap.

The problem with `sharedLogic` and `sharedUI`

A fresh sharedLogic module looks innocent. Business logic, models, repositories. sharedUI holds your Composables. What could go wrong?

Three months later sharedLogic contains:

Business logic
Network clients
Database models
Constants
Utility functions
Something called CommonUtils.kt that nobody understands but everyone is afraid to delete

sharedLogic has no internal boundaries. Everything depends on everything. You can import a database model from a use case and nobody stops you. The compiler certainly won't.

JetBrains tells you where to start. They don't tell you what happens when two modules become 50,000 lines.

What actually happens

You try to split sharedLogic into more modules. But there are no rules. So you end up with:

:sharedLogic:core — the new dumping ground
:sharedLogic:data — which also contains business logic somehow

The dependencies look like spaghetti. Changing one module breaks three others. You didn't enforce boundaries early, and now every refactoring is a gamble.

FLIP: the next step after `sharedLogic`

FLIP is an architectural pattern that gives you rules for splitting sharedLogic before it becomes a problem.

Five layers. One direction. Zero horizontal dependencies.

Layer	Purpose	Depends on
`:common:core`	Foundation	Nothing
`:service`	Domain logic without UI	`:common:core`
`:feature`	UI features	`:service`, `:common:core`
`:entrypoint`	DI assembly + slot composition	Everything above
`:platform`	Platform entry point	`:entrypoint`

The rule is simple: features don't know about other features. services don't know about other services. Dependencies only flow down.

Your IDE enforces this. You literally cannot import a feature from another feature — Gradle won't compile. The structure prevents the dumpster fire before it starts.

Start with JetBrains. Grow with FLIP.

The new KMP structure is a great starting point. Two modules is better than one. But when sharedLogic starts feeling like a junk drawer, you know what to do.

FLIP is at github.com/numq/flip. Template included. Konsist tests included. Rules over conventions.

Stop Fighting Your State. Reduce And Conquer It.

numq — Wed, 13 May 2026 18:16:46 +0000

MVVM seemed simple. Then you added ten MutableStateFlow properties to your ViewModel. MVI promised purity. Then you wrote a middleware for side effects.

There’s a better way.

The Problem With MVVM

A typical ViewModel looks like this:

class ProfileViewModel : ViewModel() {
    val name = MutableStateFlow("")
    val email = MutableStateFlow("")
    val isLoading = MutableStateFlow(false)
    val error = MutableStateFlow<String?>(null)

    fun updateProfile(name: String) {
        viewModelScope.launch {
            isLoading.value = true
            try {
                profileService.update(name)
                this@ProfileViewModel.name.value = name
            } catch (e: Exception) {
                error.value = e.message
            } finally {
                isLoading.value = false
            }
        }
    }
}

Five mutable properties. Loading state scattered across three places. Error handling duplicated in every method. And the ViewModel doesn’t own its side effects — viewModelScope does.

The Problem With MVI

MVI fixes the state explosion by putting everything in a sealed interface:

sealed interface ProfileState {
    data object Loading : ProfileState
    data class Loaded(val name: String, val email: String) : ProfileState
    data class Error(val message: String) : ProfileState
}

But MVI doesn’t tell you how to handle side effects. Some use middleware. Some use Channel. Some hack it with LaunchedEffect. Every project reinvents the wheel.

Reduce & Conquer

The core idea: a reducer is a pure function that returns more than just state.

data class Transition<State, Event>(
    val state: State,
    val events: List<Event> = emptyList(),
    val effects: List<Effect> = emptyList()
)

A transition has three outputs:

State - the new state
Events - one-shot notifications (navigation, snackbar)
Effects - long-running or async work

Effects are first-class citizens:

sealed interface Effect {
    data class Stream<Command>(
        val key: Any,
        val flow: Flow<Command>,
        val strategy: Strategy = Strategy.Sequential,
        val fallback: (suspend (Throwable) -> Command)? = null
    ) : Effect

    data class Action<Command>(
        val key: Any,
        val fallback: (suspend (Throwable) -> Command)? = null,
        val block: suspend () -> Command
    ) : Effect

    data class Cancel(val key: Any) : Effect
}

Stream - subscribes to a flow, emits commands back
Action - runs one async operation, emits a command
Cancel - cancels by key, preventing leaks

A Reducer in Practice

class ProfileReducer(
    private val profileService: ProfileService
) : Reducer<ProfileState, ProfileCommand, ProfileEvent> {

    override fun reduce(
        state: ProfileState,
        command: ProfileCommand
    ): Transition<ProfileState, ProfileEvent> = when (command) {
        is ProfileCommand.UpdateProfile -> transition(
            state.copy(isLoading = true)
        ).effect(
            action(
                key = "update_profile",
                fallback = { ProfileCommand.ProfileError(it) },
                block = {
                    profileService.update(command.name)
                    ProfileCommand.ProfileUpdated
                }
            )
        )

        is ProfileCommand.ProfileUpdated -> transition(
            state.copy(isLoading = false)
        ).event(ProfileEvent.NavigateBack)

        is ProfileCommand.ProfileError -> transition(
            state.copy(
                isLoading = false,
                error = command.throwable.message
            )
        )
    }
}

No viewModelScope. No LaunchedEffect. No mutable properties. One pure function.

Why This Is The Benchmark

MVVM

State: Multiple MutableStateFlow
Side effects: viewModelScope.launch
Cancellation: Manual
Testing: Mock ViewModel

MVI

State: Single sealed class/interface
Side effects: Ad-hoc (middleware, Channel)
Cancellation: Manual
Testing: Mock reducer + middleware

Reduce & Conquer

State: Single sealed interface
Side effects: Built-in (Effect)
Cancellation: Automatic by key
Testing: One pure function call

Testing a reducer:

@Test
fun `update profile sets loading and fires effect`() {
    val transition = reducer.reduce(
        state = ProfileState(),
        command = ProfileCommand.UpdateProfile("Alice")
    )

    assertTrue(transition.state.isLoading)
    assertEquals(1, transition.effects.size)
    assertEquals(0, transition.events.size)
}

One call. No coroutines. No mocks.

The Rule

State flows down. Commands flow up. Effects manage the rest.

The View sends Commands. The Reducer returns a Transition with new State, Events, and Effects. The Feature executes Effects and feeds resulting Commands back into the Reducer. That's it.

Full implementation in the GitHub repository.

A recipe for the Perfect Use Case

numq — Wed, 13 May 2026 18:05:16 +0000

Today we’re cooking the perfect Use Case — and CQRS will be our recipe.

Ingredients

Action — fire and forget (logout, clear cache)
Query — read data (list products)
Command — write data (update profile)
Exchange — transform data (login)

All four types extend a sealed interface:

sealed interface UseCase<Input, Output> {
    interface Action : UseCase<Unit, Unit>

    interface Query<Output> : UseCase<Unit, Output>

    interface Command<Input> : UseCase<Input, Unit>

    interface Exchange<Input, Output> : UseCase<Input, Output>
}

Three Ways to Season It

Arrow (Typed Errors) — the chef’s choice:

class GenerateSeed(
    private val seedService: SeedService
) : UseCase.Action {
    override suspend fun Raise<Throwable>.action() =
        seedService.generateSeed().bind()
}

Result (Standard Wrapper) — zero dependencies:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed().getOrThrow()
}

Raw (Direct Execution) — zero overhead:

class GenerateSeed(private val service: SeedService) : UseCase.Action {
    override suspend fun action() = service.generateSeed()
}

Why This Recipe Works

No more UseCase<Unit, Unit> noise
Every use case follows the same structure
Query or Command makes intent obvious

Full implementation in the GitHub repository.

FLIP: Modular Architecture for KMP

numq — Wed, 13 May 2026 17:53:17 +0000

While building haskcore - an IDE for Haskell on Compose Desktop - I extracted rules that allowed me to create an architecture of 40 isolated modules, where each module knows only what it needs.

That's how FLIP - Feature-Layered Isolated Platform - was born.

The main problem I faced during development: horizontal dependencies make the system fragile. The solution - strict vertical hierarchy.

FLIP consists of the following isolated modules:

:common:core - common logic components.
:common:presentation - common UI components.
:service - UI-less domain module. Provides a service interface.

interface SeedService : AutoCloseable {
    val seed: Flow<Seed>

    suspend fun generateSeed(): Either<Throwable, Unit>
}

:feature:core — logic module of a UI-feature. Knows nothing about other features. Uses services from :service. Provides use cases.

class GenerateRemoteRandomSeed(private val seedService: SeedService) : UseCase.Action {
    override suspend fun Raise<Throwable>.action() = seedService.generateSeed().bind()
}

:feature:presentation — UI module of a UI-feature. Knows only about its :feature:core and uses its use cases. Provides the view. Knows only about its own :feature:core.
:entrypoint — module where dependency configuration and composition of views from :feature:presentation into a single Composable happens.
:platform — module that initializes the Composable provided by :entrypoint for each platform.

Arrows show the direction of dependencies.

How to structure your system?

Decide which features your app should have, then determine whether each feature has a UI:

If it does — it’s a feature.
If it doesn’t — it’s a service.
If one feature’s logic is needed by another — extract it into a separate service.

Important: both :service and :feature:core contain domain logic:

:service — core domain.
:feature:core — presentation domain (use cases).

Wrong:

:service:foo
:feature:foo:core
:feature:foo:presentation

Right:

:service:foo
:feature:bar:core
:feature:bar:presentation

Navigation in FLIP is just another feature. It aggregates and routes views passed as lambda slots, keeping it independent from other features.

NavigationView(
    splash = {
        SplashView(applicationScope = applicationScope)
    },
    profile = {
        ProfileView(applicationScope = applicationScope)
    }
)

This approach lets you add new screens without touching existing features.

A complete example is available in the official GitHub repository.

DEV Community: numq

Kempo: Real-Time Audio Time-Stretching, Pitch-Shifting, and Formant Control in Pure Kotlin Multiplatform

Zero-allocation streaming, phase-locked clarity, and multichannel spatial coherence across JVM, Android, iOS, and WebAssembly.

What Kempo Brings to Your Audio Stack

How Kempo Keeps Audio Crisp (Without the Artifacts)

1. Eliminating Transient Smearing with Vertical Phase-Locking

2. Fixing the "Chipmunk" Effect with Formant Decoupling

3. Preserving Stereo Width and 5.1 Surround Imaging

Getting Started

1. The One-Liner: Offline Track Processing

2. Zero-Allocation Real-Time Streaming

3. Sample-Accurate Offline Rendering with exact()

4. Custom Frequency Mapping & Tonality Limits

Engineered for Speed in Pure Kotlin

Try It Live: The Compose Desktop Studio App

Explore the Code

Why HTTPS Won’t Save Your Checkout Flow: Building Zero-Trust State Machines in Kotlin Multiplatform

How to protect multi-step workflows, fintech funnels, and Server-Driven UI from step-skipping, state tampering, and replay attacks — with zero runtime dependencies.

The Mental Model: Think "Git Commits" for Your App State

Designing for Zero Bloat: The Core Primitives

1. VerifiableBlock

2. DeltaBlock (Signed Partial Updates)

3. Pure Functional Reduction

Real-World Walkthrough: The Unbreakable Checkout

The Legitimate User Journey

Simulating the Attack: Skipping Shipping

Built for Developer Ergonomics

Where Does TrustChain Shine?

Try It in Your Project

Stop Trusting Your UI: Why Zero-Trust Server-Driven UI is the Next Industry Standard

Part 1: The Billion-Dollar Blind Spot

🔴 Traditional SDUI (Vulnerable)

🟢 Blueprint Zero-Trust SDUI (Immune)

Part 2: The Blueprint Chain - Your UI on a Blockchain

Hash Chaining: Every Screen Knows Its Parent

Performance That Does Not Sacrifice UX

State Deltas with RSA Signatures: Surgical, Signed Updates

Part 3: Developer Experience Without Compromise

Server: Build UIs Like You're Writing Jetpack Compose

Client: Native Compose Rendering with Built-in Verification

Part 4: Pure Functional Core - Predictable, Testable, Crash-Free

Part 5: Why This Becomes the Standard

Security FAQ

Getting Started

The Bottom Line

Building High-Performance Text Editors in Kotlin Multiplatform with Krope

What is a Rope?

Why I Built Krope

Inside the Krope API

The Reactive Paradigm

Line and Column Awareness

Atomic Batch Operations

Performance: The 100 Megabyte Test

Why does StringBuilder choke?

Why does Krope win?

Get Involved

JetBrains Just Changed KMP Structure. Here's What They Didn't Tell You.

The problem with sharedLogic and sharedUI

What actually happens

FLIP: the next step after sharedLogic

Start with JetBrains. Grow with FLIP.

Stop Fighting Your State. Reduce And Conquer It.

The Problem With MVVM

The Problem With MVI

Reduce & Conquer

A Reducer in Practice

Why This Is The Benchmark

MVVM

MVI

Reduce & Conquer

The Rule

A recipe for the Perfect Use Case

Ingredients

Three Ways to Season It

Why This Recipe Works

FLIP: Modular Architecture for KMP

How to structure your system?

3. Sample-Accurate Offline Rendering with `exact()`

1. `VerifiableBlock`

2. `DeltaBlock` (Signed Partial Updates)

The problem with `sharedLogic` and `sharedUI`

FLIP: the next step after `sharedLogic`