DEV Community: Ali Alp

"Where.Was.I" — a task board built around the moment you switch

Ali Alp — Mon, 20 Jul 2026 13:06:16 +0000

Live app: https://alicommit-malp.github.io/wherewasi/ · Source: https://github.com/alicommit-malp/wherewasi

Most task apps are built around what you have to do. wherewasi is built around a different moment: the one where you stop doing one thing and start doing another, and your entire mental context evaporates. It answers exactly one question, and it answers it fast — where was I?

Watch the same clip as MP4 — 40 seconds, no audio.

The problem it solves

You have five things in flight. You're deep in one of them when something interrupts you. Two days later you come back and spend fifteen minutes reconstructing what you'd already figured out: what you'd finished, what you were blocked on, what the next move was going to be.

That reconstruction is pure waste, and it's avoidable — the knowledge existed in your head at the moment you left. wherewasi is a place to dump it in five seconds, and to find it again instantly.

Three rules define the whole app:

Exactly one task is active at a time. Not a philosophy about focus — just an honest record of where your attention actually is.
Every task carries a stack of short notes. Newest first. "renewed the cert", "waiting on DNS", "next: draft the outline". Free text, no schema, no ceremony.
Switching is instant. One click or one keystroke. No dialog, no prompt, no "are you sure" — because anything that adds friction to switching means you'll stop recording your switches, and then the app is worthless.

What it deliberately does not do

Design is mostly subtraction, and this app had a lot subtracted:

No timers, no time tracking. The first draft measured how long each task was active. It got cut, because the value was in restoring context, not producing timesheets — and a running clock creates a low-grade obligation to "start" and "stop" things correctly.
No tags or categories. An earlier version tagged each note as did / waiting / next. In practice the tag was one more decision at the exact moment you want zero decisions. Plain text carries the same meaning: just type "waiting on DNS".
No forced note on switch. The original design popped a modal on every switch asking what happened. It was correct in theory and unbearable in practice.
No accounts, no server, no network. Your data never leaves your browser.

Each of those removals came from actually using the thing and noticing the friction.

Using it

The board

One narrow column. Each row is a task: a dot, the title, and its three most recent notes underneath in muted text. The active task is highlighted and is the only row with a note input. That's the whole interface.

Clicking a task title switches to it instantly and moves it to the top of the list, so the board self-sorts by recency: what you're on is first, what you just left is right below it, and stale work sinks to the bottom on its own.

Naming the workspace

Click the wherewasi title in the header to give the board a name — wherewasi — work, wherewasi — side project, whatever. It also becomes the browser-tab title, so if you keep separate boards in separate browser profiles they stay easy to tell apart. Leave it blank and the header is just wherewasi.

Writing notes

The active task's input says What happened?. Type, press Enter, done. Notes stack newest-first, each with a small timestamp so you can see whether a thought is from ten minutes ago or last week.

Click any note to edit it inline (Enter saves, Escape cancels). If a task has more than three notes, a +N more link expands the full history — and that expansion collapses automatically the moment you switch tasks, so the board never grows cluttered behind your back.

Undo, because instant shouldn't mean irreversible

Archiving a task or deleting a note happens with no confirmation dialog — but neither is a dead end. Both drop a five-second Undo toast (click it, or press u), and undo restores the item exactly where it was: an archived task returns to its old board position rather than the bottom, and a deleted note slots back into its original place in the stack. It fits the whole design: act instantly, take it back if you didn't mean it. Let the five seconds lapse and it's committed.

Staying in sync across tabs

Open wherewasi in two tabs and they stay consistent — a change in one appears in the other within a moment, because every tab reads and writes the same local database and pings its siblings to refresh. No stale second tab quietly overwriting your work.

Keyboard

The app is fully keyboard-driven; press ? at any time for this list.

Key	Action
`↓`/`j`, `↑`/`k`	Move the selection
`Enter`	Switch to selected — on the active task, jump into the note input
`a`	Write a note on the active task, from anywhere
`n`	New task
`e`	Rename selected task
`d`	Done — archive selected task
`u`	Undo the last archive or note deletion (while the prompt shows)
`Space` / `m`	Expand / collapse selected task's notes
`v`	Toggle the archive
`/`	Search (in the archive)
`Esc`	Leave input / close view / clear selection

The fastest possible loop is j j Enter to land on a task, then Enter again to start typing what happened. Single-letter shortcuts are suppressed while you're typing, so notes never trigger commands.

On a phone

It's desktop-first, but it works on touch: the per-row actions (archive, rename, delete) are always visible instead of hiding behind hover, and it installs as a real PWA — proper maskable and Apple-touch icons, so the home-screen tile looks right on both Android and iOS, and it runs fully offline once installed.

Finishing and finding things

Pressing d (or clicking the ✓ that appears on the row) archives a task. It leaves the board but keeps its entire note stack, browsable under Archive and reopenable at any time. The archive has full-text search across both task titles and note contents — so months later, searching "headcount" surfaces the task where you wrote "travel numbers in, headcount still missing", even if the title never mentioned it.

How it's built

A deliberately small stack, chosen so the whole app stays readable in one sitting:

Vite 8 + Svelte 5 (runes) + TypeScript — small bundle, minimal boilerplate
Dexie 4 over IndexedDB — typed local persistence
vite-plugin-pwa — generated service worker and manifest; installable and fully offline
GitHub Actions → GitHub Pages — every push to main builds and publishes

The data model

Three tables, all with UUIDs and timestamps:

Task     { id, title, status: 'open' | 'archived', createdAt, archivedAt?, sortOrder }
Note     { id, taskId, text, createdAt }
AppState { id: 'app', activeTaskId: string | null, title?: string }   // exactly one row

The most important detail is the smallest one: "one active task" is a single pointer in AppState, not a boolean flag on each task. Two tasks being active simultaneously isn't a bug that has to be prevented — it's unrepresentable. Whole classes of state-sync bugs simply don't exist.

sortOrder is what makes switching bubble a task to the top: activating a task rewrites its order to just below the current minimum, and that reordering is persisted like everything else. That same persisted order is why undo can drop an un-archived task back into its exact former place.

State flow

A single store class (src/lib/store.svelte.ts) holds $state runes, hydrated from IndexedDB once at startup. Every mutation writes to Dexie first, then updates in-memory state, then broadcasts a one-line "changed" ping to any other open tabs. There is no memory-only state anywhere, so a refresh, a crash, or a closed laptop lid loses nothing. Empty titles and empty notes throw rather than silently no-op.

The UI is a handful of small components — the board, a task row, the note form, and a help overlay — none of which own any persistent state of their own.

Local-first, on purpose

Everything lives in your browser's IndexedDB. No account, no sync server, no telemetry, no network calls at all. On load the app calls navigator.storage.persist() to ask the browser not to evict the board under storage pressure. That local-first choice has real consequences worth being honest about:

It's single-device. Tabs in the same browser stay in sync, but a different machine is a different board. The data model was built sync-ready (UUIDs and timestamps everywhere), so a sync layer can be added later without remodeling.
Browser storage still isn't a vault. Persistent storage makes eviction far less likely, but clearing site data wipes it. A JSON export is the obvious next hardening step.

For a tool whose whole job is holding your working context, that trade is deliberate: zero setup, zero latency, and nothing to trust.

Where it goes next

Already shipped since the first cut: five-second undo for archiving and note deletion; multi-tab consistency via BroadcastChannel; persistent storage via navigator.storage.persist(); a nameable workspace; and clean PWA installation on iOS and Android with maskable and Apple-touch icons.

Still ahead, roughly in priority order:

JSON export / import — the rest of durability: a backup you own and can move.
Sync — a self-hosted backend (PocketBase or CouchDB/PouchDB) the static frontend talks to, giving multi-device use without handing task contents to a third party.
Tests — the store's invariants (one active task, archiving clears the pointer, switching reorders, undo restores in place) are exactly the logic worth pinning down with Vitest and fake-indexeddb.

Try it

https://alicommit-malp.github.io/wherewasi/ — it installs as a PWA from the browser menu and works with the network off. Add a couple of the things you're juggling right now, switch between them, and leave yourself a note on the way out. The payoff arrives the next time you come back.

[Boost]

Ali Alp — Mon, 06 Jul 2026 20:37:33 +0000

Ali Alp

Jul 6

Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)

#architecture #devops #microservices #systemdesign

3 min read

Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)

Ali Alp — Mon, 06 Jul 2026 20:37:16 +0000

We’ve all seen it happen. A engineering team wants to feel like they belong in the "cool kids" club, so they grab Apache Kafka or a massive event broker, throw it at a straightforward CRUD application, and suddenly a simple database write is wrapped in a complex web of event producers, consumers, and brokers.

Before you introduce that level of massive operational overhead into your stack, we need to talk about what Event-Driven Architecture (EDA) actually delivers—and what it charges you in return.

I recently sat down for a panel discussion on the reality of building real-time enterprises. If you want to skip the hype and hear the unvarnished truth about architectural trade-offs from practicing architects, you can watch the full panel discussion on YouTube here.

Here is the breakdown of the core architectural realities we discussed.

1. "Real-Time" is a Spectrum, Not Pure Speed

When stakeholders or product managers say they want "real-time data," they usually just mean they want their system to feel fast. But real-time isn't a single setting; it's a massive spectrum.

Hard Real-Time: Think medical instrumentation, radar tracking, or high-frequency trading systems. Milliseconds or microseconds dictate success, and missing a deadline means total system failure.
Soft Real-Time: A Grafana metrics dashboard or an activity feed. If an update takes an extra two seconds to show up, the business survives.

Here is the hard truth that catches many off guard: EDA does not give you more speed. Every broker, event log, network hop, and serialization boundary you insert adds infrastructure complexity and transport latency. You don't adopt EDA for raw single-stream performance; you adopt it for decoupling. If your system cannot tolerate eventual consistency, forcing an EDA into your core transaction loop is the wrong choice.

2. The Overkill Trap: When to Actually Deploy EDA

Architectural patterns should evolve organically based on hard constraints, not because you want to copy LinkedIn’s or Netflix's infrastructure blogs. Attempting to build a brand-new service around a heavy event broker on day one is the definition of over-engineering.

So, when is it actually time to shift to an event-driven model?

The Litmus Test: You need EDA the moment your system emits a single fact (e.g., OrderPlaced) that multiple, completely independent business domains need to natively consume and react to at the same time.

If an order placement requires immediate, distinct actions from Shipping, Billing, Inventory management, and Fraud Detection—all handled by different microservices or separate teams—EDA rescues you from tight coupling and nasty orchestration bottlenecks. If it’s just one service talking directly to another, stick to a simple, synchronous API call or a lightweight point-to-point queue until the system forces you to change.

3. Conway’s Law Wins Every Time

Software architecture is socio-technical. You can design the most elegant, fully decoupled event-driven ecosystem on a whiteboard, but if your organization is managed by a rigid, top-down hierarchy where every cross-team decision requires centralized synchronization and global locks, your technical architecture will rot.

Before rewriting your stack to use events, look at your org chart:

Do your individual teams have the actual operational autonomy to own micro-domains?
Can your engineers shift their mental model from immediate, synchronous database states to handling asynchronous flows, retries, and out-of-order events?

If the organizational maturity isn't there to support decentralized data ownership, forcing EDA into the codebase will only create technical friction and team frustration.

4. Why AI and EDA Are Perfect Partners

While human developers often struggle to reason through sprawling, asynchronous event loops, artificial intelligence thrives in them.

Parallelism is baked into the very DNA of modern AI orchestration. If you are building multi-agent AI frameworks, those autonomous agents spend a massive amount of time executing parallel background tasks, waiting on inputs from collaborator agents, and reacting to changing context states. Because an AI ecosystem is inherently asynchronous and distributed, an event-driven backbone is one of the most effective ways to cleanly coordinate intelligent systems without blocking execution threads.

Cut Through the Noise

Architecture is always a game of trade-offs. EDA gives you incredible flexibility, system resilience, and structural decoupling, but it taxes you heavily in complexity and latency. Make sure your business domain actually requires what it's selling before you sign the check.

For the deeper, unfiltered debate on these concepts—including how data governance and organizational maturity factor into the mix—check out the full session here:

How I built one Manifest V3 extension that runs on Chrome, Edge, and Firefox

Ali Alp — Thu, 14 May 2026 10:54:12 +0000

I built a browser extension called Silenzio that blurs or blacks out videos and images, mutes audio, and lets me set rules about where and when it applies. The motivation is a bit personal: scrolling feeds, search results, and "people you may know" lists kept stealing minutes I didn't actually want to spend. A blurred feed turns out to be a surprisingly effective speed bump.

The technically interesting part is that the whole thing — Chrome, Edge, and Firefox — runs from a single source folder. No build step, no per-browser variants, no Webpack. Here's how that works, plus a handful of MV3-specific tricks I had to find along the way.

What it does

Two independent toggles — videos and images — each with Off / Blur / Blackout. Audio follows the video toggle. Three more knobs on top: an allowlist or blocklist of sites, per-site or global pause timers, and an optional "working hours" schedule so the whole thing only runs during a daily window you pick.

One manifest, three engines

Manifest V3 is technically the same across Chrome, Edge, and Firefox 115+. In practice you can write a single manifest.json that all three load, because:

Chromium engines ignore unknown manifest fields.
The MV3 fields Silenzio actually uses (content_scripts, host_permissions, action, options_page, permissions) are part of the standard that Firefox now implements.

The Firefox-specific block goes at the bottom and Chromium ignores it:

"browser_specific_settings": {
  "gecko": {
    "id": "silenzio@silenzio.local",
    "strict_min_version": "115.0"
  }
}

That's it. The same files load in three browsers with zero conditional code.

The one gotcha you can't solve in the manifest is that Firefox MV3 treats <all_urls> host permissions as user-granted post-install. After temporary-loading the add-on, you have to click the toolbar icon → puzzle-piece menu → Silenzio → "Always allow on all websites" once. Until then, the content script won't actually inject. Easy to miss the first time.

Catching short-form feeds

The hard case for a media-filtering extension is short-form video — Shorts, Reels, the LinkedIn feed. Those surfaces aggressively mount and unmount <video> elements as you scroll. A naive document.querySelectorAll("video") at load time finds nothing useful, because most of the videos haven't been mounted yet.

The fix is a MutationObserver rooted at document.documentElement, started at document_start:

const observer = new MutationObserver((mutations) => {
  const eff = effectiveModes();
  for (const m of mutations) {
    for (const node of m.addedNodes) {
      if (node.nodeType !== 1) continue;
      if (node.matches?.(SELECTOR)) applyTo(node, eff);
      node.querySelectorAll?.(SELECTOR).forEach((el) => applyTo(el, eff));
    }
  }
});
observer.observe(document.documentElement, { childList: true, subtree: true });

Because the manifest sets "run_at": "document_start", the observer is in place before the body even exists. Newly-mounted videos and images get the filter class within a tick of being inserted.

There's a small but important detail in the order: I start the observer before loading the saved config from chrome.storage.local. Storage is asynchronous, and the round trip easily takes long enough for an autoplay video to mount and start playing. So the observer runs with defaults immediately, then re-applies once storage resolves. The visible result is that pages never flash an unblurred frame.

One CSS path for videos and images

The CSS for the blur and blackout is dumb on purpose:

.silenzio-blur { filter: blur(40px) !important; }
.silenzio-blackout { filter: brightness(0) !important; }

filter is an element-level property. It applies to whatever the box renders — video frames, image content, even async-loaded image bytes that arrive after the class is set. That means <video> and <img> share exactly one apply path. The element-type dispatch happens once, in modeFor:

function modeFor(el, eff) {
  if (el instanceof HTMLVideoElement) return eff.video;
  if (el instanceof HTMLImageElement) return eff.image;
  if (el instanceof HTMLMediaElement) return eff.video; // <audio> follows video
  return "off";
}

Adding new media types later is a two-line change in this function and one selector update. The CSS doesn't need to know anything.

Re-muting hostile sites

el.muted = true is fine 90% of the time. The 10% case is sites that programmatically unmute on a player event, or swap the src on the same element when you scroll to the next short. So I attach two capture-phase listeners on document:

document.addEventListener("volumechange", (e) => {
  if (effectiveModes().video !== "off" &&
      e.target instanceof HTMLMediaElement &&
      !e.target.muted) {
    e.target.muted = true;
  }
}, true);

document.addEventListener("play", (e) => {
  if (e.target instanceof HTMLMediaElement) applyTo(e.target, effectiveModes());
}, true);

Capture phase matters here. By the time volumechange bubbles to the document the site's own handler has already run; capture-phase intercepts before. This is enough to keep YouTube, LinkedIn, and Reels muted reliably.

The decision flow

Every time the extension applies a mode it goes through effectiveModes():

Scope — if the current hostname doesn't match the user's allowlist or blocklist, both modes return off. Match is exact-or-suffix, so adding youtube.com covers www.youtube.com and m.youtube.com.
Pause — if there's a global or site-specific pause active right now, both modes return off.
Schedule — if working hours are enabled and the current time is outside the window, both modes return off.
Otherwise return the user's configured { video, image } modes.

This is the only place precedence is decided, and the order matters: I want a one-click pause to override the user's other rules without needing to think about them.

Time-based state is re-checked via a single setTimeout per page that targets the next relevant boundary — the exact pause expiry, or the next minute boundary if a schedule is active. Doing exact schedule-edge math with days-of-week and midnight crossings is fussy; minute granularity is more than enough for a "working hours" feature and avoids a category of bugs.

What I didn't (yet) solve

Three known gaps, all on the someday list:

CSS background-image — many avatars and decorative banners are painted via background-image rather than <img>. Filtering them requires walking computed styles and either injecting per-element CSS or patching stylesheets. I skipped it for v1.
Inline <svg> — mostly icons, rarely worth blurring. (<img src="*.svg"> is filtered because the selector catches <img>.)
Web Audio API graphs — HTMLMediaElement.muted doesn't stop a Web Audio graph that pulls samples directly. Ordinary playback on YouTube, LinkedIn, etc. uses HTMLMediaElement and is muted correctly; some games and audio editors aren't.

Each is solvable, just not at v1 scope.

Try it

Silenzio is on the Chrome Web Store — works in Edge too. The source, including the Firefox load instructions, lives at github.com/alicommit-malp/silenzio. No build step — Load unpacked and go.

If you've built a cross-browser MV3 extension and have a cleaner answer for Firefox's host-permission UX, the Web Audio mute, or background-image filtering, I'd love to hear it.

Did you ever wondered to see your whole life in one page calendar ?

Ali Alp — Thu, 07 May 2026 20:36:38 +0000

Ali Alp

May 7

I built a 'life in weeks' poster generator in one HTML file

#productivity #javascript #life

4 min read

I built a 'life in weeks' poster generator in one HTML file

Ali Alp — Thu, 07 May 2026 20:35:24 +0000

I made a tool that draws every week of your life on a single sheet of paper.

A long human life is roughly 5,200 weeks. That's a 100-row × 52-column grid — small enough to fit on one A4 page, big enough that you instinctively try to count them. The tool fills in the weeks you've already lived, leaves the rest empty, and exports a PDF you can print.

Live: https://alicommit-malp.github.io/life-in-weeks/
Source: https://github.com/alicommit-malp/life-in-weeks

It's also a quiet experiment in restraint:

One file (index.html — HTML, CSS, JS, all of it)
No framework, no bundler, no package.json
Two CDN deps: jsPDF and Google Fonts
No backend, no analytics, no localStorage
$0 hosting, $0 forever

This post is about the design decisions. There's just enough code to show what's interesting; the rest is on GitHub.

Why one file?

Because the surface area is small. The whole product is "type your name and birthdate, click two buttons." A build step buys nothing — and "no build step" buys something real: anyone can clone the repo, double-click index.html, and run it offline. No npm install, no Node version mismatch, no broken Vite plugin two years from now.

This wasn't dogma. I genuinely tried to imagine a v2 that needed React. I couldn't justify it.

Drawing 5,200 circles fast

The naive approach is <circle> × 5,200. It works, but that's a lot of DOM nodes.

The trick: two <path> elements, one for filled circles and one for empty ones. Build the path data as a single string of moveto + arc commands.

function circlePath(cx, cy, r) {
  return `M${cx},${cy} m${-r},0 a${r},${r} 0 1,0 ${2*r},0 a${r},${r} 0 1,0 ${-2*r},0 `;
}

let filledD = "", emptyD = "";
for (let r = 0; r < YEARS; r++) {
  const cy = gridTop + (r + 0.5) * ROW_H;
  for (let w = 0; w < WEEKS; w++) {
    const cx = leftX + (w + 0.5) * CELL;
    const idx = r * WEEKS + w;
    if (idx < totalWeeks) filledD += circlePath(cx, cy, CIRCLE_R);
    else emptyD += circlePath(cx, cy, CIRCLE_R);
  }
}

The M cx,cy m -r,0 a r,r 0 1,0 2r,0 a r,r 0 1,0 -2r,0 pattern draws a circle as two half-arcs from a moveto point. Subsequent M commands inside the same d attribute start a new disconnected subpath, so one <path> element ends up containing 5,000+ circles.

Two DOM nodes instead of 5,200. Render is instant.

Keeping the PDF honest

The on-screen preview is SVG. The download is a real PDF, generated by jsPDF from circle(), line(), and text() primitives. They have to look identical — if the preview lies, the user feels cheated the moment they hit "Download."

The fix is shared coordinate math. jsPDF in pt units uses A4 = 595.27 × 841.89, top-left origin, y growing down — exactly like SVG. So both renderers consume the same constants:

const PAGE_W = 595.27;
const PAGE_H = 841.89;
const MM = 2.83465; // 1 mm in pt

function computeLayout(years) {
  const cellWMax = (PAGE_W - LEFT_M - RIGHT_M) / 52;
  const cellHMax = (PAGE_H - TOP_M - BOTTOM_M) / years;
  const cell = Math.min(cellWMax, cellHMax);
  // ... gridW, gridH, leftX, gridTop, circleR, font sizes, tick step
}

Both renderSVG() and renderPDF() call computeLayout(years) and then walk identical loops. Change a margin in one place, both renderers update. No divergence.

The layout is height-constrained — and that's a feature

100 rows × 52 columns of square circles on a single A4 page means cell size is capped by page height, not width. The grid ends up about 135 mm wide — there are ~24 mm of empty margin on the left and right. People keep wanting to "fix" this.

Earlier iterations tried:

Two-page A4 — wider circles, but you have to tape the pages together
Landscape A4 — counterintuitively gives smaller circles, because height becomes the new constraint
Stretched ovals — looks bad

The empty side margins are correct. They're the price of the proportions. I kept them.

Adding pets

Recently I added a Human / Dog / Cat selector. Dogs get 20 rows × 52 columns; cats, 25. For shorter spans, the cell size becomes width-constrained instead, so circles get bigger, and the tick axis switches from a 10-year step to a 5-year step:

const SPECIES = {
  human: { years: 100, placeholder: "e.g. Ali" },
  dog:   { years: 20,  placeholder: "e.g. Spot" },
  cat:   { years: 25,  placeholder: "e.g. Mochi" },
};

// inside computeLayout:
const tickStep = years <= 30 ? 5 : 10;

Because all the layout state went through one function, adding species was a small diff plus a CSS segmented control. I didn't have to touch the rendering loops at all.

Going against the SaaS look

Most "free tool" landing pages use the same recipe: Inter, gradient backgrounds, rounded cards with shadows, a Lucide icon next to every heading. Safe and forgettable.

I went the other way:

Fraunces for the display serif (italic accent on in weeks)
JetBrains Mono for everything else
Warm off-white paper background with a faint radial-gradient grain
One emphasis color — terracotta — used sparingly
A magazine-style masthead bar at the top
Inputs are typewriter-style: serif text, single underline, no boxed fields

It looks more like a printed thing than a webapp. Which is the point — the output is a printed thing.

Privacy is the simple kind

There's no backend, no fetch to any server I control, no analytics, no cookies, no localStorage. Your name and birthdate never leave the browser tab.

The only network requests are Google Fonts and jsPDF from cdnjs. Neither receives the form data.

I didn't need a privacy policy because there's nothing to disclose.

Cost

GitHub Pages serves the file. The fonts are free. jsPDF is MIT. Total monthly cost: $0. I expect it to keep being.

Try it

Live: https://alicommit-malp.github.io/life-in-weeks/
Source: https://github.com/alicommit-malp/life-in-weeks (MIT)

Fork it, print it, gift it.

Introducing Tunnel Whisperer: Surgical Connectivity for Networks That Say "No"

Ali Alp — Fri, 06 Mar 2026 15:54:27 +0000

Your MRI scanner needs to talk to a cloud AI platform. Your vendor needs to reach a single maintenance port on a factory-floor PLC. Your data scientist needs to query an on-premise database from a cloud notebook. The firewall says no to all of them.

Tunnel Whisperer says yes.

Github page

The Problem Nobody Talks About

Enterprise networks are getting stricter. Firewalls block everything except port 443. Deep Packet Inspection kills anything that doesn't look like genuine HTTPS. Legacy devices — hospital scanners, industrial controllers, aging servers — can't run modern VPN clients. And even if you could install one, IT won't open a single inbound port.

This is the Connectivity Gap: the space between what your applications need and what your network allows.

Traditional solutions don't fit:

VPNs (WireGuard, Tailscale) require UDP ports or custom protocols — blocked by DPI.
Reverse proxies (ngrok) expose services to the public internet — a non-starter for healthcare and manufacturing.
SSH tunnels get flagged and dropped by next-gen firewalls.

We built Tunnel Whisperer to close this gap.

What Is Tunnel Whisperer?

Tunnel Whisperer is an open-source tool that creates resilient, port-to-port bridges across separated private networks. It wraps your TCP traffic inside a genuine TLS-encrypted HTTPS stream using Xray's VLESS+XHTTP protocol. To the network, it looks exactly like someone browsing a website.

Client Network             Public Cloud               Server Network
+--------------+        +------------------+        +--------------+
|  tw connect  |--443-->|     Relay VM     |<--443--|   tw serve   |
|              |  HTTPS |  Caddy + Xray    |  HTTPS |              |
| local ports  |        |  (reverse proxy) |        | SSH server   |
| :5432 :3389  |        |  Firewall: 80+443|        | port fwd     |
+--------------+        +------------------+        +--------------+

Your PostgreSQL client connects to localhost:5432. Your RDP client connects to localhost:3389. The traffic flows through an HTTPS tunnel to the server network, where it reaches the actual services. The applications on both ends have no idea a tunnel exists.

Why We Built It

We kept running into the same scenario: a customer with a legitimate connectivity need, a network that blocks everything, and no tool that threads the needle between "too broad" (VPN) and "too public" (ngrok).

Tunnel Whisperer is designed around three principles:

1. Surgical access, not broad connectivity. Each user gets access to exactly the ports they need — nothing more. No host-to-host networking, no route tables, no exposure of adjacent services.

2. Invisible to the network. The traffic is indistinguishable from regular HTTPS. No special ports, no unusual protocols, no signatures for DPI to flag.

3. Zero trust at the relay. The relay VM is a dumb pipe. It stores no SSH keys, no passwords, no application data. If it gets compromised, the attacker gets nothing useful — all plaintext remains encrypted by the SSH layer inside the tunnel.

How It Works: Three Layers of Encryption

Tunnel Whisperer stacks three encryption layers, each serving a different purpose:

Layer	What It Does
TLS 1.3 (outer)	Makes the traffic look like HTTPS. Caddy handles automatic Let's Encrypt certificates on the relay.
Xray VLESS + XHTTP (middle)	Routes users by UUID through the relay. XHTTP splits data into standard HTTP requests for resilience against connection timeouts.
SSH Ed25519 (inner)	End-to-end encryption between client and server. Public-key only — no passwords, no brute-force surface. Per-user `permitopen` restrictions lock each client to specific ports.

The relay terminates TLS but never sees the SSH-encrypted payload. Even if someone owns the relay, they can't read your data.

Real-World Use Cases

Healthcare: DICOM Through a Firewall

A hospital's MRI scanner needs to send images to a cloud AI platform for analysis. The scanner speaks DICOM on port 104 and can't install any software. Tunnel Whisperer runs on a gateway machine on the scanner's LAN, forwarding port 104 through the HTTPS tunnel to the cloud. The scanner sends to localhost:104 as if the AI platform were next door.

Manufacturing: Vendor Access to a Single Port

A machine vendor needs remote access to a PLC's maintenance port for diagnostics. Instead of a VPN that exposes the entire factory network, Tunnel Whisperer gives them access to exactly one port on one device. When the job is done, revoke the key — access gone.

Data Science: Cloud Notebook to On-Premise Database

A data scientist running Jupyter in the cloud needs to query a PostgreSQL database behind a corporate firewall. With Tunnel Whisperer, they connect to localhost:5432 and run queries as if the database were local. No VPN client, no firewall exceptions, no IT tickets.

Getting Started in 5 Minutes

Tunnel Whisperer ships as a single binary for Linux, Windows, and macOS. Build from source with Go 1.25+:

make build          # builds bin/tw

Server Side

tw dashboard                # open the web UI
tw create relay-server      # 8-step wizard: provision a relay VM
tw create user              # 5-step wizard: create a client with port restrictions
tw serve                    # start the server

The relay provisioning wizard handles everything: spinning up a VM on Hetzner, DigitalOcean, or AWS, configuring Caddy for TLS, installing Xray, and locking down the firewall to ports 80 and 443 only.

Client Side

The server admin sends you a config bundle (a zip file with your config and SSH keys). Then:

tw dashboard                # drag-and-drop the zip file
tw connect                  # you're in

That's it. Your configured ports are now available on localhost with automatic reconnection if the connection drops.

The Web Dashboard

Both server and client modes come with a browser-based dashboard for managing everything visually:

Server dashboard — create users, provision relays, monitor connected clients, stream logs in real-time, and open an interactive SSH terminal to the relay — all from the browser.

Client dashboard — upload config bundles, connect/disconnect with one click, and see your active tunnels with bandwidth stats.

No separate web app to deploy. The dashboard is embedded in the same tw binary.

Per-User Access Control

Every user gets:

A unique Xray UUID for relay routing
An Ed25519 key pair for SSH authentication
A permitopen directive restricting them to specific ports

# authorized_keys (auto-generated)
permitopen="127.0.0.1:5432",permitopen="127.0.0.1:3389" ssh-ed25519 AAAA... alice
permitopen="127.0.0.1:104" ssh-ed25519 AAAA... vendor-dicom

Alice can reach PostgreSQL and RDP. The vendor can reach the DICOM port. Neither can reach anything else. Revoking access is instant — remove the key from authorized_keys and the UUID from the relay config. No server restart needed.

Built for Resilience

Connections drop. Networks hiccup. Tunnel Whisperer handles it:

Auto-reconnection with exponential backoff (2s up to 30s max)
SSH keepalive every 15 seconds to detect dead connections early
XHTTP transport splits data into HTTP requests, surviving connection resets that would kill WebSocket-based tunnels
System service mode (tw service install) for auto-start on boot — Linux systemd, Windows SCM, or macOS launchd

Performance

We won't pretend there's zero overhead. Two relay hops and three encryption layers have a cost. Here are real numbers from our benchmarks (relay on Hetzner, ~30ms RTT):

Metric	Direct SSH	Tunnel Whisperer
Throughput (100 MB transfer)	112 MB/s	21 MB/s (~168 Mbps)
Database TPS (pgbench, 50 clients)	~1,790	~80-95
Database latency	~28 ms	~530-630 ms

Tunnel Whisperer excels at bulk transfers, streaming, and interactive sessions where human-speed interaction or continuous data flow hides the latency. For high-frequency RPC workloads with many small round-trips, you'll want to use connection pooling and place the relay geographically close to both endpoints.

The tradeoff is clear: you lose raw speed, but you gain connectivity where no other tool can get through.

How It Compares

	Tunnel Whisperer	VPNs (Tailscale/WireGuard)	Reverse Proxies (ngrok)
Scope	Surgical (port-to-port)	Broad (host-to-host)	Public (port-to-web)
DPI Resistance	High (genuine HTTPS)	Low (custom protocols)	Medium (standard HTTPS)
Deployment	Gateway/sidecar	Agent on every host	Dev/test
Infrastructure	Self-hosted	SaaS/hybrid	SaaS
Relay Compromise	No credential exposure	Varies	Provider-dependent

What's Next

Tunnel Whisperer is currently in alpha. The core tunnel, user management, dashboard, and multi-cloud relay provisioning are all working. Here's where we're heading:

UDP support for protocols that need it
Multi-relay topologies for geographic distribution
Observability — OpenTelemetry-format logging is already in progress
Pre-built binaries and package manager distribution

Get Involved

Tunnel Whisperer is MIT-licensed and open source.

GitHub: github.com/Tunnel-Whisperer/Tunnel-Whisperer
Documentation: tunnel-whisperer.github.io/Tunnel-Whisperer
Video Tutorial: Watch the walkthrough on YouTube

If you've ever stared at a firewall rule that blocks everything and thought "there has to be a better way" — give Tunnel Whisperer a try. We'd love your feedback, bug reports, and contributions.

Tunnel Whisperer — because sometimes the only way through is to whisper.

A practical, governance-first framework for turning your CI/CD pipeline into a secure, reproducible, and audit-defensible supply chain control point.

Ali Alp — Fri, 13 Feb 2026 13:56:25 +0000

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Ali Alp ・ Feb 13

#devops #cicd #security #productivity

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Ali Alp — Fri, 13 Feb 2026 13:50:52 +0000

CI/CD pipelines are amazing.

They build, test, package, sign, and ship our software in minutes. They automate what used to take days. They make modern development possible.

They also sit at one of the most dangerous control points in your entire system.

If you build regulated, safety-critical, or security-sensitive software, your CI pipeline is not “just automation.” It executes code, holds secrets, produces artifacts, and pushes to production.

That makes it part of your product’s trust boundary.

So the real question isn’t:

Is our application secure?

It’s this:

Is our build system defensible?

That’s where SCRIPTED CI comes in.

Why CI Is a Supply Chain Control Point

Most teams spend their security energy on:

Application security testing
API authentication
Infrastructure hardening
Runtime monitoring

All important.

But CI pipelines quietly:

Execute third-party code (GitHub Actions, plugins, integrations)
Access privileged credentials (cloud roles, signing keys, tokens)
Produce signed release artifacts
Modify repository state
Pull dependencies dynamically

If an attacker compromises your CI, they don’t need to break your runtime.

They can modify your build.

And if your build is compromised, your product is compromised.

That’s a supply chain problem.

The SCRIPTED Model

SCRIPTED is a governance-first way to think about CI security.
It turns abstract “best practices” into enforceable controls.

Letter	Principle	What It Means
S	Secure Secrets	Minimize and scope credentials in CI
C	Control Execution	Only run approved, immutable code
R	Repeatable Builds	Make builds deterministic
I	Isolated Runtime	Harden where builds execute
P	Policy Enforcement	Automate guardrails
T	Traceability	Make artifacts verifiable
E	Evidence	Be able to prove your controls
D	Defensible Design	Encode security in the system, not the process

Let’s walk through it.

S — Secure Secrets

CI pipelines often accumulate powerful credentials:

GITHUB_TOKEN with write access
Cloud deployment roles
Container registry credentials
Code signing certificates

The default mistake? Over-permissioned tokens.

Instead of this:

permissions: write-all

Do this:

permissions:
  contents: read
  packages: write

Other guardrails:

Don’t expose secrets to fork-based PR workflows
Use short-lived identities (OIDC) instead of static cloud keys
Separate build credentials from deployment credentials
Audit token usage regularly

If a job doesn’t need a permission, it shouldn’t have it.

Simple. Structural. Defensible.

C — Control Execution

CI runs code. Sometimes that code is yours. Sometimes it’s not.

Marketplace actions and plugins are convenient. They’re also external code entering your trust boundary.

This is unsafe:

uses: actions/checkout@v4

Why? Because tags can move.

This is safer:

uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3

Pin to a commit SHA.

That makes the reference immutable.

Stronger moves:

Mirror critical actions into your own org
Vendor high-risk actions locally
Maintain an allowlist of approved actions
Automatically fail builds that reference unpinned actions

Immutable references eliminate silent drift.

R — Repeatable Builds

If you rebuild a release from two years ago, do you get the same binary?

If not, you don’t have reproducibility.

And without reproducibility, you don’t have defensibility.

Instead of:

FROM node:latest

Use:

FROM node@sha256:...

Also:

Enforce lockfiles (go.sum, package-lock.json, etc.)
Pin toolchain versions
Eliminate dynamic dependency resolution
Avoid runtime internet downloads during build

Deterministic inputs must produce deterministic outputs.

Anything else is guesswork.

I — Isolated Runtime

Where your CI runs matters.

Public runners are convenient, but they are shared infrastructure.

For higher-assurance systems:

Use self-hosted runners
Make them ephemeral (destroy after each job)
Restrict outbound network access
Segregate runners by trust boundary

Treat CI runners as production infrastructure.

Because they are.

P — Policy Enforcement

Here’s a hard truth:

Guidelines are not controls.

A control that does not automatically fail is not a control.

If you say:

“All actions must be SHA pinned.”

Then enforce it.

Add a validation step that fails when:

An action is not pinned
Permissions are too broad
An unapproved marketplace action is referenced

Combine this with:

Branch protection
Required status checks
Policy-as-Code (OPA, Conftest, etc.)

Security must be encoded into the pipeline itself.

Otherwise, it will erode.

T — Traceability

For every artifact deployed to production, you should be able to answer:

What source commit built this?
What dependencies were included?
What toolchain was used?
Has it been modified since creation?

If you can’t answer those questions, incident response becomes speculation.

To fix that:

Generate an SBOM for every build
Produce cryptographic provenance (SLSA-style attestations)
Sign artifacts (Sigstore/Cosign)
Keep immutable build logs

This turns builds from opaque processes into verifiable records.

E — Evidence

Security that cannot be demonstrated does not exist.

In regulated environments, you will be asked to show:

How you control third-party execution
How you manage credentials
How you ensure reproducibility
How you maintain artifact lineage

So keep:

Architecture diagrams
Policy definitions
SBOM archives
Signature records
Audit logs

Evidence is not paperwork.
It’s proof of structural control.

D — Defensible Design

This is the outcome.

Not “we follow best practices.”

Not “we trust our team.”

Not “it should be fine.”

But:

Controls are enforced technically
Third-party execution is bounded
Privileges are minimized
Builds are deterministic
Artifacts are verifiable

You replace process-based assurances with structural guarantees.

That’s defensibility.

Phased Adoption (Don’t Boil the Ocean)

You don’t need to do everything at once.

Phase 1 — Baseline Risk Reduction (Weeks 1–4)

Pin all actions to SHAs
Reduce token permissions
Enable branch protection
Add basic workflow linting

Low effort. Immediate risk reduction.

Phase 2 — Structural Governance (Months 1–3)

Mirror critical actions internally
Introduce “Golden Workflows”
Enforce Policy-as-Code validation
Deploy ephemeral runners

Medium effort. Major risk reduction.

Phase 3 — Regulatory-Grade Assurance (Months 3–6)

Hermetic builds (no external network dependency)
SBOM for every artifact
Signed provenance attestations
Hardware-backed signing for releases

High effort. Audit-ready posture.

Why This Matters

CI pipelines:

Execute external code
Hold powerful secrets
Produce signed artifacts
Sit between source and production

They are part of your threat model.

In modern systems, the integrity of your product is inseparable from the integrity of its build process.

SCRIPTED CI isn’t about paranoia.

It’s about recognizing that the build is no longer a convenience layer.

It’s infrastructure.

And infrastructure must be governed.

If you’re operating in regulated environments, or just want to level up your supply chain security, I’d be curious:

Which part of SCRIPTED would be hardest to implement in your organization?

[Boost]

Ali Alp — Mon, 12 Jan 2026 17:39:36 +0000

A technical documentation to ultimate freedom in life

Ali Alp ・ Jan 12

#freedom

A technical documentation to ultimate freedom in life

Ali Alp — Mon, 12 Jan 2026 17:38:05 +0000

This is a default human behavior in C

alicommit-malp / freedom

A technical documentation to freedom in life for software developers :)

freedom

A technical documentation to freedom in life for software developers :)

This is a default human behavior in C

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
    bool anger_event = false;
    
    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    if (anger_event) {
        printf("Show anger.\n");
    } else {
        printf("All is calm.\n");
    }

    return 0;
}

This is the upgraded human behavior after doing meditation

While practicing meditation, let thoughts enter but decide if you agree to process them, this will create the gap (freedom) over time.

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>
int main(void)
{
    bool anger_event = false;
    
    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    bool conscious_choice = !anger_event; // ← this

…

View on GitHub

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
    bool anger_event = false;

    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    if (anger_event) {
        printf("Show anger.\n");
    } else {
        printf("All is calm.\n");
    }

    return 0;
}

This is the upgraded human behavior after doing meditation

While practicing meditation, let thoughts enter but decide if you agree to process them, this will create the gap (freedom) over time.

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
    bool anger_event = false;

    srand(time(NULL));
    anger_event = rand() % 2 == 0;

    bool conscious_choice = !anger_event; // ← this is freedom

    if (anger_event && conscious_choice) {
        printf("Show anger.\n");
    } else {
        printf("All is calm.\n");
    }

    return 0;
}

Diff

Worth sharing ?

When Events Meet Clusters: Building Reactive Micro-services on Kubernetes

Ali Alp — Wed, 10 Dec 2025 21:29:32 +0000

Modern users expect digital systems to feel alive. We touch, we swipe, we click—and we expect something to happen instantly. Yet many micro-services architectures still behave like a slow bureaucracy: they wait, they poll, they block, and under pressure they break. This article explores a simple but powerful idea:

Events can transform ordinary micro-services into reactive, self-organizing systems that scale and recover like living organisms.

This idea matters because most failures in distributed systems arise not from bad code, but from bad coordination. Services depend on each other too tightly. Scaling decisions arrive too late. Recovery mechanisms rely on brittle manual steps. And when demand surges suddenly, teams find themselves firefighting instead of innovating.

To understand how events solve this, we start with a question.

Why do micro-services still wait?

Think of a food-delivery app during a sudden rainstorm. Orders jump tenfold in a minute. Kitchens fill. Drivers vanish. The back-end is overwhelmed. Requests start queuing. API timeouts cascade. Users refresh endlessly. Engineers scramble.

But the underlying problem is simple:

Traditional micro-services react to stress after it hurts.

We rely on metrics like CPU, retries, and liveness probes—signals that come after something has already gone wrong. In biological terms, it’s like touching something hot and waiting for your brain to calculate the temperature before deciding to pull your hand away.

Systems that wait get burned.

So what would a system look like if it reacted instantly—before bottlenecks or failures reached the user?

Reactive micro-services: systems that respond, not poll

To explain reactive architecture, consider a train station:

Polling architecture: You walk to the platform every 30 seconds and ask, “Did the train arrive yet?”
Event-driven architecture: A loudspeaker announces, “Train arriving on platform 4.”

Reactive micro-services don’t keep checking. They listen. They respond. They scale when something actually happens. They recover by replaying what they missed.

To build such behavior, we combine three technologies—each playing a different role in the metaphor of a living system.

Kafka: the nervous system’s signal carrier

Kafka is the backbone of the event-driven organism.

It records every event in durable storage.
It broadcasts signals to any service that needs them.
It supports replay, allowing a service to rebuild state after failure.

If Kubernetes is the body, Kafka is the spinal cord, reliably delivering every neural signal down the line.

When a service dies, Kafka simply replays the events. When a new service appears, it can reconstruct exactly what happened before it joined. This behavior is essential for systems that heal themselves.

Knative: the reflex engine

If Kafka is the nervous system, Knative provides the reflex arc.

Touch something hot → your hand pulls back before your brain consciously processes the danger.

Knative Eventing works the same way:

It watches Kafka topics.
When an event arrives, Knative instantly activates the exact workload needed.
It scales consumers up under load and down to zero when idle.

This enables an infrastructure that responds proportionally to real-world events.

For example, a sudden spike in “OrderCreated” events results in instantaneous consumer scaling—not 60 seconds later, not after CPU hits 80%, but exactly when the load originates.

Kubernetes: the muscle and regeneration system

Kubernetes is the body’s musculature:

It runs containers reliably.
It heals failed pods.
It provides auto-scaling and stable infrastructure.
It maintains the cluster’s general health.

Kubernetes alone is not reactive—it lacks event understanding. But when paired with Kafka and Knative, it becomes the execution layer for a reactive organism.

Together, they form this dynamic:

Kafka senses.
Knative reacts.
Kubernetes adapts and stabilizes.

Patterns for building reactive micro-services

1. Event Choreography

Imagine a parcel moving through a logistics system:

Order placed
Payment confirmed
Package packed
Out for delivery

Each step reacts to the previous event. No central controller. No chain of API calls. Just events that trigger reactions.

2. Event Sourcing

Consider a bank account. Your balance is not stored; it is computed by summing all transactions. Event sourcing uses Kafka to store every change.

Benefits:

Perfect audit history
Ability to rebuild state anytime
Natural resilience to failure

3. CQRS with Kafka Streams

Commands update state. Queries read from a fast, materialized view.

This gives:

smooth scalability
predictable performance
clear separation of responsibilities

Kafka Streams keeps the views up to date in real time.

Why events reduce failures

Most system failures originate from coupling:

A slow service slows everything
A failing service breaks everything
A scaling service overloads everything

Events cut these chains.

Failures become local instead of global.
A bad consumer does not impact producers. A slow processor does not block others. If a consumer crashes, Kafka simply replays events until it recovers.

This is how living systems avoid dying from one malfunctioning cell.

Observability as the organism’s senses

Observability in reactive architectures is not about dashboards—it’s about understanding motion:

Kafka lag = congestion on a highway
Distributed tracing = route visualization
Knative auto-scaling logs = heartbeat signals

The goal is to see the system as an organism, reacting to stimuli and adapting continuously.

What organizations gain

Teams adopting this architecture see:

massive reductions in over-provisioning
better stability under unpredictable workloads
fewer cascading failures
simpler understanding of system behavior
improved developer autonomy

A reactive system frees engineers to build features rather than fight fires.

The idea worth sharing

At its core, this architecture re-frames how we think about distributed systems.

Reactive micro-services aren’t faster machines—they are better listeners.
They don’t wait. They don’t poll. They don’t rely on rigid chains of synchronous calls.

Instead, they respond to the world, recover from damage, scale when needed, and rest when idle.

This is the shift:

From systems that must be controlled
to systems that can self-organize.

And when events meet clusters, that shift becomes possible.