DEV Community: Haidar Esber

PrivaSVG: image-to-SVG vectorization in the browser with Rust and WebAssembly

Haidar Esber — Sun, 08 Nov 2026 22:42:22 +0000

Most image-to-SVG converters are upload forms: your file goes to a server, gets traced, and comes back. PrivaSVG does the whole job in the browser tab. There is no backend. Here's how it's built, with the parts that were actually tricky.

The pipeline

Raster image -> AI background removal -> Manual retouch -> Upscale (2x / 4x) -> Vectorize (Rust -> WASM) -> SVG

Every stage is optional except the last, so you can jump straight to vectorization. A bulk page runs up to 50 images through a fixed chain and downloads a single ZIP.

Vectorization: a Rust engine compiled to WebAssembly with wasm-bindgen.
Background removal: @imgly/background-removal, which runs the isnet_fp16 segmentation model on ONNX Runtime Web. The model is fetched once, cached, and then works offline.
Upscaling: 2x or 4x canvas resampling to recover detail before tracing.
Retouch: a brush-based remove/restore tool to fix edges the model missed.

Credit where it's due

The tracing core is not from scratch. The Rust engine is built on VTracer and the visioncortex crate (the app depends on visioncortex 0.8.1). What PrivaSVG puts around it is the browser pipeline: the background-removal and retouch stages, upscaling and bulk processing. The keying approach described below follows the same idea as the upstream VTracer web app. The project is dual-licensed MIT OR Apache-2.0.

Tracing as an incremental state machine

Tracing a large image is slow work, so the converter is an incremental state machine that the UI drives with repeated tick() calls:

pub enum Stage {
    New,
    Clustering(IncrementalBuilder),
    Reclustering(IncrementalBuilder),
    Vectorize(Clusters),
}

Each tick() does a small slice of work and returns whether it's finished. Clustering groups pixels into color clusters. In cutout mode a second Reclustering pass runs on the cluster view. Vectorize then converts one cluster per tick into a compound path and prepends it to the target <svg>. A progress() method maps the stages onto 0 to 100 (clustering is the first half, vectorizing the second), so the UI can show a real progress bar. Because the work is split into small slices, control returns to the caller between ticks.

Parameters arrive as JSON (new_with_string) and are deserialized with serde. They are the same knobs the settings panel exposes: curve-fitting mode (pixel, polygon, spline), speckle filter, color precision, layer difference, corner threshold, splice threshold and path precision, plus a stacked or cutout hierarchy.

The transparency problem

Background removal produces transparent pixels, but a clustering tracer wants colors. If you let transparent pixels through as black, you get a black blob behind your subject in the SVG.

The converter handles this with a key color. In init() it finds a color that isn't used anywhere in the image, replaces transparent pixels with it (including near-transparent black pixels, which the canvas API can produce when it flattens alpha), and tells the clustering runner to Discard that color. The key color never appears in the output, so transparent regions stay transparent. If no unused color can be found, it falls back to a fixed, very unlikely cyan (1, 254, 253). The source comments also record a lesson learned: red as the first-choice key color caused visible red backgrounds, so less common colors are tried first.

Privacy is the architecture, not a policy

There's no server to trust because there's no server. Images never leave the tab, and there are no accounts or tracking. The WASM engine and the ONNX model both run on your device. That's a stronger guarantee than a privacy policy, and it's why the project shares its visual language with my other privacy project, PrivaSearch.

Honest limits

The tracing quality is the visioncortex/VTracer algorithm's. It works well for logos, illustrations and cut-out subjects, and it will not turn a photograph into a faithful vector.
The first background removal downloads the model, so it needs the network once.
The cutout-mode transparency handling is heuristic, as the "fallback key color" above shows.

Try it

Live demo: https://haidaresber.github.io/privasvg/

Source (Rust, WASM, webpack): https://github.com/HaidarESBER/privasvg

Building an Arabic-first RTL news platform with Next.js 16 and Express

Haidar Esber — Sun, 08 Nov 2026 22:41:59 +0000

Majal Post (مجال بوست) is an Arabic-first news and media platform focused on Lebanese social, economic and environmental issues. I built it as a monorepo: a Next.js frontend, an Express/MongoDB REST API, and a shared TypeScript types package. This post covers the decisions that mattered most, and what I'd still improve.

The stack

Frontend: Next.js 16 (App Router), React 19, TypeScript, Tailwind CSS 4
Backend: Node.js with Express 5 (ESM), TypeScript, MongoDB via Mongoose, JWT auth with bcrypt
Media: Cloudinary, Multer and Sharp for upload, resizing and thumbnails
Email: Nodemailer over SMTP, silently skipped when SMTP isn't configured so the rest of the app keeps working
Shared: a private @majalpost/shared package so the frontend and backend agree on types

The product side covers themed categories (Environment & Climate, Society, Economy, Education, Technology, Health), articles with slugs and tags, search, comments, an admin dashboard, and a contributor workflow: a public "become a contributor" application plus per-author "my articles" pages.

Arabic-first means RTL at the root

The simplest RTL decision was also the most important one: set it once, at the top of the tree.

<html lang="ar" dir="rtl">

With dir="rtl" on <html>, flexbox and text flow mirror automatically, so most layouts need no per-component handling. Fonts are loaded through next/font/google with the Arabic subset: Almarai (weights 300 to 800) and IBM Plex Sans Arabic (300 to 700), exposed as CSS variables.

Where it's not finished: I didn't use Tailwind's logical utilities (ms-*, me-*, ps-*, pe-*). A handful of physical ml-/mr-/pl-/pr- utilities remain, and the header uses space-x-reverse. They work today because the site is RTL-only, but logical properties would be the right move if I ever add a left-to-right locale.

An API that assumes the internet is hostile

The backend is where most of the hardening lives, all visible in index.ts and middleware/:

Helmet with a content security policy (defaultSrc: 'self', images allowed from self, data:, blob: and the frontend origin) and HSTS (one year, including subdomains, preload).
A CORS allowlist driven by FRONTEND_URL (comma-separated), rejecting any other origin.
Three rate limiters: 100 requests per 15 minutes on the general API, a stricter 20 per 15 minutes on auth that doesn't count successful requests, and 10 uploads per hour.
A 10 MB body limit on JSON and URL-encoded bodies.
Role-based access: authorize.ts provides requireAdmin and requireAdminOrEditor middleware that runs after JWT authentication.

Sanitize on the server, not just in the editor

Article bodies and comments are HTML, which is an XSS risk. Article routes sanitize on write: titles and excerpts go through sanitizeText (all markup stripped), and content goes through sanitizeHtml, a DOMPurify instance running on a jsdom window with an allowlist of tags (p, br, strong, em, h1-h6, lists, blockquote, a, img, code, pre) and attributes (href, src, alt, title, class). Comments are sanitized the same way.

This is covered by backend unit tests (run in CI): script tags and inline handlers are stripped, javascript: URLs are blocked, safe links and formatting survive, and Arabic text is preserved unchanged.

What's honestly not done

The test suite is small: 11 backend unit tests (sanitization and ObjectId validation). The frontend has none yet.
The frontend lint was failing with 11 errors until recently. They're fixed and lint is now a blocking CI step, but 45 warnings remain.
The auth rate limiter's comment notes the limit was raised for testing, and it's worth revisiting before treating it as final.

Run it

docker-compose up -d        # MongoDB 7 on localhost:27017
cd backend && npm install && npm run dev     # http://localhost:5000/api
cd frontend && npm install && npm run dev    # http://localhost:3000

Source: https://github.com/HaidarESBER/majalpost

PrivaSearch: private AI search with SearXNG and a local LLM

Haidar Esber — Sun, 08 Nov 2026 22:35:38 +0000

I wanted AI-synthesized search answers without sending my queries to anyone. PrivaSearch is the result: SearXNG for metasearch, a local LLM served by Ollama for cited answers, and a small Node/Express API in between. Here's how it's put together and what it does and doesn't guarantee.

The architecture is the privacy model

Four containers on one internal Docker network (privanet):

frontend: nginx serving a React/Vite UI and proxying /api
api: Node + Express orchestration, streaming over SSE
searxng: the metasearch backend, with a JSON API
ollama: the local LLM

Only the frontend publishes a host port (8080 by default). SearXNG, Ollama and the API have no ports: mapping, so they're unreachable from outside Docker. The only routine outbound traffic is SearXNG querying upstream search engines, which is the fundamental job of a metasearch engine.

Search and answer are two separate calls

The browser first asks GET /api/results for paginated SearXNG results, then calls POST /api/answer with the top N of those results to stream a RAG answer. Splitting them means you can change how many sources the model considers and regenerate the answer without re-querying the web.

The answer handler is short. It takes the caller's sources, builds the prompt, and streams tokens as they arrive from Ollama:

for await (const token of streamChat(messages, { model: MODEL, temperature: TEMPERATURE, signal: ac.signal })) {
  send('token', { text: token });
}

Ollama's /api/chat returns newline-delimited JSON when stream: true, and ollama.js parses it line by line. If the client disconnects, an AbortController cancels the generation.

Prompt discipline instead of hope

The system prompt (in prompt.js) constrains the model to the numbered results: write one direct answer in your own words, don't summarize sources one by one, cite each claim with [n], never add outside knowledge, and if the results don't contain enough information, reply with exactly "Insufficient information in the results." Each source is reduced to one line, [index] title — snippet, with no URLs, because the model doesn't need them and echoing them encourages source-by-source listing. The default temperature is 0.2 for factual answers. These prompt builders have unit tests that run in CI.

If the LLM is down or the model isn't pulled, the raw SearXNG results still render with a notice. If there are no results, you get an explicit "no results" message rather than a generated answer.

Few dependencies on purpose

The API's only runtime dependency is Express. Node's built-in fetch covers HTTP. Even the SOCKS5 client used to discover the Tor exit IP is a small dependency-free module (socks.js, about 60 lines). For a privacy project, fewer dependencies means less attack surface and less to audit.

Optional: hide from the engines too

By default, upstream engines see your real IP. Two optional overrides route SearXNG through a tunnel:

Tor (npm run up-tor): SearXNG goes through Tor's SOCKS proxy using socks5h://, so DNS also resolves through Tor. The trade-off is that it's slower, and some engines block Tor exit nodes.
VPN (npm run up-vpn): SearXNG runs inside Gluetun's network namespace. Gluetun's kill switch is on by default, so if the tunnel drops, searches fail closed rather than leaking your real IP.

What touches disk

Per the privacy statement in the README: your query lives only in API and SearXNG process memory, search results are held only for the request, and generated answers are streamed to your browser and not stored. What is persisted is the model weights (the ollama-models volume) and the SearXNG config. SearXNG is hardened with query logging off, no Redis attached, autocomplete off (no per-keystroke leakage) and remote images proxied. Thumbnails go through /api/image_proxy, so your browser never contacts remote image hosts, and the API refuses to proxy anything that isn't an image.

The honest exceptions

Two opt-in features make extra requests, and both can be disabled: Summarize fetches the one page you click (ALLOW_PAGE_FETCH=false turns it off), and the exit-location widget does one cached geo-IP lookup (SHOW_LOCATION=false turns it off). Both are disclosed in the app's privacy panel.

Performance reality

The default model is qwen2.5:1.5b (about 1 GB), chosen for CPU: it loads in seconds and the README reports about 8 s per warm answer. qwen2.5:0.5b is faster but weaker at citations, and llama3.1:8b gives better answers but is slow on CPU. The model is kept resident for 30 minutes (OLLAMA_KEEP_ALIVE) so you only pay the load cost once.

Try it

npm run setup
npm run pull-model
docker compose up -d

Then open http://localhost:8080. Source: https://github.com/HaidarESBER/privasearch

Making browser perception cheap for LLM agents: snapshots, caching and diffs

Haidar Esber — Sun, 08 Nov 2026 22:35:07 +0000

Most "give the model a browser" setups hand it one of two things: a screenshot, or a dump of the full accessibility tree. Both are expensive, and both get re-sent in full after every action.

I've been building ecobrowser, a TypeScript library and MCP server on top of Playwright whose whole job is to make perception cheap for a model. This post walks through three pieces of it, using the real code: a compact snapshot format, a cache keyed on the DOM, and a diff for re-perceiving after an action.

1. A snapshot the model can act on

A snapshot is not a picture of the page. It's a list of interactive elements:

interface SnapshotElement {
  id: string;         // durable id, e.g. "e3"
  role: string;
  name: string;
  tag: string;
  value?: string;
  state?: string[];   // disabled, checked, expanded, obscured, ...
  options?: string[]; // a <select>'s choices
}

interface Snapshot { url: string; title: string; elements: SnapshotElement[] }

Each element is stamped with a durable data-ai-id, and the model acts by id (click e3), never by CSS selector or pixel coordinate. The state array carries what the model needs to act correctly, and covered elements are flagged obscured. Password values are never captured and show as [redacted].

The snapshot is capped at 250 elements, and it only covers interactive elements. That's a deliberate scope choice, and it matters for the benchmark below.

2. Cache the snapshot until the DOM changes

Re-walking the DOM and re-serializing on every call is wasteful when nothing changed. The engine runs a MutationObserver that counts real DOM changes (ignoring its own data-ai-id stamping), and snapshot() serves the previous result when the DOM version and URL match:

async snapshot(opts: { cache?: boolean } = {}) {
  const version = await this.domVersion();
  if (opts.cache && this.lastCacheable && this.lastSnapshot &&
      version === this.lastDomVersion &&
      this.lastSnapshot.url === this.page.url()) {
    return this.lastSnapshot; // skip the full DOM walk + serialization
  }
  // ...otherwise build a fresh snapshot
}

3. Re-perceive with a diff, not a full page

After a click, the model rarely needs the whole page again. changes() returns only the delta:

interface SnapshotDiff {
  added: SnapshotElement[];
  removed: SnapshotElement[];
  changed: { id: string; name: string; from?: string; to?: string }[];
  unchanged: number;
}

The interesting part is how elements are matched between the two snapshots. Ids that appear exactly once in both are matched by id, so a relabelled button shows up as changed rather than as one removal plus one addition. Everything else is matched by a semantic signature (tag|role|name) plus an occurrence index, so five identical buttons are matched positionally instead of collapsing into one key. A toggled checkbox counts as changed because the comparison includes value and the state flags, not just the label.

4. `find()` without an LLM

For "just give me the search box", there's a deterministic scorer, elementMatchScore. Words like box, field, button and link are treated as kind hints and matched against tag and role. The remaining words are scored against the accessible name: exact beats prefix beats substring beats all-words-present. A kind match boosts the score and a kind mismatch demotes it, so "search box" ranks the search input above a "Search" button. It's cheap precisely because no model is involved.

What the numbers say (and don't)

The repo includes a head-to-head benchmark against Playwright MCP (npm run bench) on the same page, measuring bytes returned to the model and tool latency:

	ecobrowser	Playwright MCP
Full page snapshot	~41 KB (~10K tokens)	~128 KB (~32K tokens)
Re-perceive latency	~5 ms (cache hit)	~150 ms
Re-perceive after an action	delta only	full page again

The caveats matter, and they're in the README too:

This measures perception payload and tool latency, not end-to-end LLM wall-clock. No live model ran.
Part of the size gap is scope: ecobrowser captures interactive elements only, while Playwright MCP captures the full accessibility tree.
It's faster than the wrapper (Playwright MCP), not than Playwright itself, which is the shared engine under both. The wins are caching, diffing and a leaner format, all of which a competitor could adopt.

Honest limits

It's a young, single-user developer tool, tested on its own paths (34 unit tests, 21 browser regression tests and 7 MCP-level regression tests, all run in CI) but not battle-hardened across thousands of real sites. It's meant to be pointed at your own or authorized sites.

Try it

claude mcp add ecobrowser -- npx -y ecobrowser-mcp

or npm install ecobrowser and use it as a library. Source: https://github.com/HaidarESBER/ai-browser

Self-healing browser actions for AI agents (and why they must refuse to guess)

Haidar Esber — Sun, 08 Nov 2026 22:29:39 +0000

When an LLM drives a browser, the classic failure isn't "the model is dumb". It's that the page
moved under its feet. The agent reads the page, decides to click e3, and by the time the click
lands, a framework re-render has replaced that DOM node with an identical-looking new one. The id is
gone, the click fails, and the model burns tokens re-reading the page and re-deciding.

ecobrowser handles this in code, not in the prompt. The principle is: do work in code so the model
doesn't spend tokens and reasoning on it. Here's how the self-healing path works, and the one rule that
makes it safe.

1. Give elements durable ids

Perception runs a script inside every frame and open shadow root, collects interactive elements, and
stamps each with a durable data-ai-id. Ids are never reused, even across pages, so "e3" means the
same thing five steps later. The agent acts by id, never by guessed CSS selector or pixel
coordinate.

2. Try the action, then heal only if the id vanished

// reliableOnElement (simplified)
const first = await reliable(`${verb} ${id}`, () => act(sel(id)), { retries: 1 });
if (first.ok || first.maybeApplied || cancelRequested) return first;

const newId = await healId(id);
if (!newId) return first;               // refuse to guess
return reliable(`${verb} ${id} (re-located as ${newId})`, () => act(sel(newId)));

Three details matter:

One cheap retry first. Most flakiness is timing, not a moved id.
maybeApplied is never retried. If a click's handler hung after the event was dispatched, the action may already have happened. Retrying could submit a form twice. The result is reported honestly as maybeApplied and the agent decides.
Healing is a second phase, not the default. It only runs when the first attempt failed outright.

3. Re-locate by identity, and refuse when it's ambiguous

healId re-snapshots the page and looks for an element with the same identity: tag, role and
accessible name. It returns null, meaning "I won't guess", in four cases:

The id still exists. Then the failure is real (covered, disabled, off-screen), not a moved id.
The page is a different document. After a navigation there is nothing to re-locate.
The identity was ambiguous before. If the previous snapshot had two "Delete" buttons, the match is meaningless.
The identity is ambiguous after. If the new snapshot has zero or several matches, same problem.

Only when exactly one element matches before and after does it hand back the new id.

const same = (e) => e.tag === prev.tag && e.role === prev.role && e.name === prev.name;
if (prevSnap.elements.filter(same).length !== 1) return null;   // ambiguous before
const matches = fresh.elements.filter(same);
return matches.length === 1 ? matches[0].id : null;             // ambiguous after

The comment in the source says it best: acting on the wrong one is worse than failing. A failed action
the agent can see and reason about is cheap. A confident click on the wrong "Delete" button is not.

4. Return a verdict, not a hope

Every action returns an ActionResult: did it work, and did the page change. That distinguishes
success, silent no-op (the click landed, nothing happened) and failure. A MutationObserver
tracks a DOM version, and a fingerprint of each interactive element's label, value and state means a
toggled checkbox or opened menu counts as a change even when no element was added or removed.

What I'd tell someone building a similar layer

Make "the id moved" a recoverable condition, but make recovery conservative.
Treat ambiguity as a hard stop. Self-healing that guesses is a bug generator.
Separate "failed before dispatch" (safe to retry) from "may have applied" (never retry).
Report outcomes as data the model can use, not just exceptions.

Honest limits

Identity is tag + role + name, so two genuinely different elements with the same label are never
healed (by design), and a renamed element won't be re-found. It's a young, single-user developer tool,
not yet battle-tested across thousands of real sites.

Code: https://github.com/HaidarESBER/ai-browser

DEV Community: Haidar Esber

PrivaSVG: image-to-SVG vectorization in the browser with Rust and WebAssembly

The pipeline

Credit where it's due

Tracing as an incremental state machine

The transparency problem

Privacy is the architecture, not a policy

Honest limits

Try it

Building an Arabic-first RTL news platform with Next.js 16 and Express

The stack

Arabic-first means RTL at the root

An API that assumes the internet is hostile

Sanitize on the server, not just in the editor

What's honestly not done

Run it

PrivaSearch: private AI search with SearXNG and a local LLM

The architecture is the privacy model

Search and answer are two separate calls

Prompt discipline instead of hope

Few dependencies on purpose

Optional: hide from the engines too

What touches disk

The honest exceptions

Performance reality

Try it

Making browser perception cheap for LLM agents: snapshots, caching and diffs

1. A snapshot the model can act on

2. Cache the snapshot until the DOM changes

3. Re-perceive with a diff, not a full page

4. find() without an LLM

What the numbers say (and don't)

Honest limits

Try it

Self-healing browser actions for AI agents (and why they must refuse to guess)

1. Give elements durable ids

2. Try the action, then heal only if the id vanished

3. Re-locate by identity, and refuse when it's ambiguous

4. Return a verdict, not a hope

What I'd tell someone building a similar layer

Honest limits

4. `find()` without an LLM