DEV Community: Rolan Lobo

I Built an AI Architectural Blueprint & Civil Feasibility Engine with $0 Paid APIs (Here's How)

Rolan Lobo — Sun, 18 Oct 2026 09:38:21 +0000

"Hey ChatGPT, design me a house."

ChatGPT: "Sure! Here is a lovely 3-bedroom house where the only toilet is inside the oven, the front door opens into an elevator void, and the staircase ascends directly into the ceiling slab." 🫠

If you’ve ever tried using modern GenAI to generate architectural plans or evaluate a piece of real estate, you know the pain. Large Language Models are brilliant poets and witty coders, but when it comes to spatial geometry, civil building codes, and structural physics, they hallucinate like a sleep-deprived toddler playing with Minecraft blocks.

Meanwhile, the traditional workflow of buying a plot of land and getting it vetted is practically medieval:

Pay $1,500 for a topological survey.
Wait 3 weeks for an environmental and flood risk assessment.
Consult a structural engineer to cross-reference seismic code tables (IS 1893).
Pay an architect $3,000 for CAD drafts that end up violating municipal setbacks (NBC 2016).
Wonder why your bank account is weeping before a single brick has been laid.

I decided to solve this. Alone. In code.

Meet BuildWise AI — an open-source, sovereign platform where you drop a single pin on an interactive 3D globe and receive an enterprise-grade civil engineering dossier, structural risk analysis, CPWD cost estimate, and a generative, constraint-checked architectural blueprint in under 3 seconds.

Oh, and the entire geospatial pipeline costs exactly $0.00 in paid API fees. No Google Maps billing, no Mapbox metered charges, no commercial satellite subscriptions.

Here is the deep dive into how it works under the hood — from the math of Spatial Constraint Satisfaction Problems (CSP) to 5-Factor MCDA Land Suitability, and how ancient Indian Vastu Shastra turned out to be an exquisite bioclimatic optimization matrix.

⚡ The 3-Second Magic: What Happens on Click?

Here is what happens the instant a user clicks a coordinate on the map:

[ User Drops Pin on Map ]
         │
         ├───► 1. Sliding-Window Rate Limiter (30 req/min)
         │
         ├───► 2. Parallel Telemetry Ingestion (All Free / Open-Access!)
         │        ├── Digital Elevation Model (USGS / Copernicus GLO-30 DEM)
         │        ├── Microclimate & Wind Vectors (Open-Meteo Forecast)
         │        ├── Seismic History (USGS FDSN Earthquake Catalog)
         │        └── Hydrological Flow (Copernicus GloFAS River Discharge)
         │
         ├───► 3. Deterministic Civil Calculation Core
         │        ├── 5-Factor Weighted MCDA Land Suitability Matrix
         │        ├── IS 1893:2016 Zone & Peak Ground Acceleration (PGA)
         │        ├── NBC 2016 Automated Setbacks & Plinth Envelopes
         │        ├── CPWD Delhi Schedule of Rates (DSR) Cost Estimator
         │        └── Vastu Purusha Mandala 9-Zone Bioclimatic Vector
         │
         ├───► 4. Generative Blueprint Engine (CF-HSA Slicing Tree)
         │        ├── Vertical Cores & Wet Plumbing Shafts Locked (G to G+3)
         │        ├── Topological Invariants Enforced (Leaf Rule, Central Box)
         │        └── L1–L14 Deterministic Validation Gate
         │
         └───► 5. Synthesis & Vector Delivery
                  ├── Ultra-Crisp Interactive SVG Blueprint (Pan/Zoom/Layers)
                  └── Print-Ready 174mm Vector PDF Dossier (ReportLab)

Total round-trip time: ~2.4 to 3.1 seconds. 🚀

Let’s look at the UI in action:

┌─────────────────────────────────────────────────────────────────────────────┐
│ 🗺️ BuildWise AI                                      [ 🛰️ Satellite ] [ 📐 3D ]│
├──────────────────────────────────────┬──────────────────────────────────────┤
│                                      │  📋 SITE FEASIBILITY DOSSIER         │
│               [ PIN ]                │  ──────────────────────────────────  │
│        12.9716° N, 77.5946° E        │  🎯 Overall Suitability: 84/100      │
│                                      │  🌊 Flood Inundation Risk: LOW (0.12)│
│                                      │  ⚡ Seismic Zone: II (Z = 0.10)       │
│                                      │  💰 Est. Plinth Cost: ₹ 2,450 / sq.ft│
│                                      │  ──────────────────────────────────  │
│                                      │  [ 📐 GENERATE BLUEPRINT (G+1) ]     │
├──────────────────────────────────────┴──────────────────────────────────────┤
│  ✨ Architectural Blueprint (Level G):                                       │
│  ┌─────────────────────────┬──────────────────────────┬──────────────────┐  │
│  │   POOJA ROOM (NE)       │    LIVING & FOYER (N)    │  KITCHEN (SE)    │  │
│  │   4.2 m² [LEAF NODE]    │    24.5 m² [HUB NODE]    │  11.2 m² [VENT]  │  │
│  ├─────────────────────────┼──────────────────────────┼──────────────────┤
│  │   STAIRCASE CORE        │   CENTRAL SPINE          │  DINING ROOM     │  │
│  │   (Vertical Anchor)     │   (Brahmasthan Open)     │  14.0 m²         │  │
│  ├─────────────────────────┼──────────────────────────┼──────────────────┤
│  │   MASTER BEDROOM (SW)   │   ATTACHED BATH (W)      │  COMMON BATH     │  │
│  │   18.5 m² [PRIVATE]     │   4.8 m² [EXTERIOR WALL] │  3.6 m² [LEAF]   │  │
│  └─────────────────────────┴──────────────────────────┴──────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘

💸 The "Zero-Paid API" Stack: Surviving Without Google Maps

Most SaaS apps slap the Google Maps JavaScript API on their frontend and call it a day — until their monthly bill arrives with 4 zeroes at the end.

For BuildWise AI, I made a strict rule: Zero Paid APIs. Every geospatial query, satellite tile, elevation reading, and climate metric must run on open-data infrastructure.

Here is the exact provider matrix:

Feature	The Expensive Commercial Way	The BuildWise Zero-Cost Way	Open Source / Data License
Base Vector Tiles	Mapbox GL ($$$)	OpenFreeMap (Liberty & Dark styles)	OpenMapTiles / ODbL
Satellite Imagery	Google Satellite ($$$)	Esri World Imagery (Maxar/USGS)	Free for Public Web Apps
3D Topographic Relief	Mapbox Terrain-RGB	OpenTopoMap + AWS Terrarium DEM	CC-BY-SA 3.0 / AWS Open Data
Digital Elevation & Slope	Google Elevation API	Open-Meteo (Copernicus DEM 30m GLO-30)	Public Domain / CC0
Historical Earthquakes	Proprietary Catastrophe APIs	USGS FDSN Earthquake Catalog	US Public Domain
River Floods & Discharge	Commercial Hydrology Data	Copernicus GloFAS via Open-Meteo	Copernicus Open Access
Multispectral Satellite	Sentinel Hub Paid Tiers	Copernicus Sentinel-2 L2A API	European Space Agency (ESA)

Calculating Slope from Space (For Free!)

How do you calculate whether a plot is buildable or prone to landslides without sending a surveyor with a theodolite?

We query 5 points: the site centroid $(x, y)$ plus four cardinal offsets 33 meters out $(x \pm 33\text{m}, y \pm 33\text{m})$. We fetch their elevations using the Copernicus 30m Global DEM and compute the maximum slope gradient:

# app/services/external_data_service.py
def calculate_topographic_slope(elevations: List[float], offset_meters: float = 33.0) -> float:
    """
    Computes the true ground gradient across cardinal samples:
    Slope (%) = (Δh_max / horizontal_distance) * 100
    """
    center_elev = elevations[0]
    deltas = [abs(e - center_elev) for e in elevations[1:]]
    max_delta_h = max(deltas)

    slope_pct = (max_delta_h / offset_meters) * 100.0
    return round(slope_pct, 2)

If the slope exceeds 15%, the system immediately triggers foundation excavation multipliers and flags slope-stabilization retaining wall requirements under IS 14458.

🧠 Why Pure LLMs Can't Draw Blueprints (And How CSP Fixes It)

If you ask an LLM to generate a JSON blueprint, it will happily invent coordinates where:

The bathroom has no exterior walls, suffocating anyone who enters.
The toilet shares a wall with the holy altar room (Pooja room).
You have to walk through the master bedroom to reach the kitchen.
On the 2nd floor, the upstairs bathroom sits directly above the living room ceiling fan, with zero plumbing shafts connecting to the ground. 💀

Architectural layout is not a language completion problem. It is a Spatial Constraint Satisfaction Problem (CSP) with strict topological graph invariants.

In BuildWise AI, we built the Core-First Hierarchical Allocation (CF-HSA) engine (app/services/floorplan/multi_floor_solver.py):

graph TD
    subgraph MultiStoreySolver ["Core-First Hierarchical Allocation (CF-HSA)"]
        Req[User Specs & Plot Dimensions] --> Setbacks[NBC 2016 Setback Subtraction]
        Setbacks --> CoreLock[1. Anchor Phase: Lock Vertical Stair/Lift Cores at x,y]
        CoreLock --> ShaftLock[2. Lock Continuous Plumbing Wet Stacks]
        ShaftLock --> PlateSlice[3. Slicing-Tree Space Partitioner]
        PlateSlice --> TopoFilter[4. Topological Invariant Filters]
        TopoFilter --> ValGate[5. Deterministic Validation Gate L1-L14]
        ValGate --> Success[Mathematical Validity Certificate Issued ✅]
    end

The 5 Non-Negotiable Architectural Invariants

Every single blueprint must satisfy these 5 mathematical invariants, or the plate is rejected:

1. The Leaf Rule ($\text{degree} = 1$)

In our circulation door graph, sensitive rooms (bathrooms, toilets, walk-in closets, pooja rooms) must be leaf nodes. They can only have an edge incident to a hallway or their parent room. Through-traffic is mathematically banned:

$$\text{degree}(v) = 1 \quad \forall v \in {\text{bath}, \text{wc}, \text{pooja}}$$

2. The Peripheral Service Rule

Every bathroom and kitchen must touch the building's exterior perimeter boundary:

$$\text{edge}(v) \cap \partial(\text{Envelope}) \neq \emptyset$$

No exterior wall = no natural ventilation shaft = instant code violation.

3. The Central-Box Exclusion (Brahmasthan)

Under ancient Vastu canon, the central 40% of a home (the Brahmasthan) must remain open for light, ventilation, and circulation. We codified this as a geometric bounding box:

$$C_{\text{box}} = [x_{\text{min}} + 0.30W, x_{\text{min}} + 0.70W] \times [y_{\text{min}} + 0.30D, y_{\text{min}} + 0.70D]$$

No service room centroid (bathroom, WC, kitchen) is permitted to lie within this box.

4. The Circulation Hub & Entry Axis

The main entrance must open strictly into the Living Room / Foyer. An entrance door that opens into a private bedroom or toilet fails the solver.

5. The Forbidden Adjacency Matrix

Bathrooms and sacred spaces cannot share a wall segment. We compute polygon boundary intersections:

$$\text{Wall}(\text{bath}) \cap \text{Wall}(\text{pooja}) = \emptyset$$

🏢 Multi-Storey Harmony: The "Rule of Cores" (G to G+3)

Building a multi-storey house isn't just generating 3 random floorplans and stacking them. If your staircase moves 2 meters to the left on the 2nd floor, your stairs lead straight into thin air!

Our multi-floor solver locks the vertical anatomy first:

Level G+2  ┌────────────────┬───────────────┬────────────────┐
           │ Master Bedroom │ STAIRCASE (Z) │ Balcony        │
           │ [Wet Stack ▼]  │ [LOCKED x, y] │                │
Level G+1  ├────────────────┼───────────────┼────────────────┤
           │ Bedroom 2      │ STAIRCASE (Z) │ Study Room     │
           │ [Wet Stack ▼]  │ [LOCKED x, y] │                │
Level G    ├────────────────┼───────────────┼────────────────┤
           │ Kitchen/Bath   │ STAIRCASE (Z) │ Living Foyer   │
           │ [Wet Stack █]  │ [LOCKED x, y] │ Main Entrance  │
           └────────────────┴───────────────┴────────────────┘
             ▲                                ▲
        Plumbing Shafts                  Core Stays Frozen
      aligned within 0.05m               across all floors!

Vertical Anchor Locking: The primary staircase core and elevator chase are computed on Ground Level and frozen at the identical $(x, y, w, d)$ coordinates across all upper levels.
Plumbing Wet-Wall Stacking: Bathrooms on upper levels must align over ground-level sanitary shafts within a 0.05 meter tolerance. No leaky pipes through living rooms!
Graceful Degradation Protocol: If a plot is too small to fit the user's dream wishlist (e.g., trying to cram 6 bedrooms, 4 baths, and a gym into a 60 m² envelope), the solver doesn't crash. It climbs a 5-level relaxation ladder, relaxing aspect ratios first before gracefully returning an exact diagnostic shortfall: "Plot envelope short by 14.2 m² for requested program."

🧭 Vastu Shastra Meets Bioclimatic Optimization

In South Asian construction, up to 90% of residential clients demand compliance with Vastu Shastra (an ancient architectural canon). Many modern engineers dismiss it as superstition.

When you analyze Vastu through the lens of passive solar bioclimatic architecture, however, the brilliance emerges:

               NORTH (Kubera - Wealth / Diffuse Daylight)
          ┌─────────────────┬─────────────────┬─────────────────┐
          │   POOJA ROOM    │  LIVING / ENTR  │  WATER STORAGE  │
          │  NE (Ishanya)   │      NORTH      │   NW (Vayu)     │
          │ Morning Sunlight│ Indirect Light  │ Cross Wind      │
          ├─────────────────┼─────────────────┼─────────────────┤
WEST      │  BEDROOM / STUDY│   BRAHMASTHAN   │   DINING ROOM   │  EAST
(Varuna)  │      WEST       │  (Open Center)  │      EAST       │ (Indra)
          │ Evening Breeze  │  Zero Load      │ Sunrise Light   │
          ├─────────────────┼─────────────────┼─────────────────┤
          │ MASTER BEDROOM  │  SERVICE / ELEV │     KITCHEN     │
          │  SW (Nairutya)  │      SOUTH      │   SE (Agneya)   │
          │ Heavy Thermal   │  Blocks Heat    │ Morning Heat/   │
          │ Mass (No Sun)   │                 │ Kitchen Exhaust │
          └─────────────────┴─────────────────┴─────────────────┘
                                   SOUTH

Kitchen in SE (Agneya / Fire): In the Northern Hemisphere, prevailing morning winds from the south-east push cooking heat and smoke away from the rest of the house.
Master Bedroom in SW (Nairutya / Earth): The south-west quadrant receives the harsh, scorching afternoon sun. Using this zone for heavy wardrobe walls and master suites provides a thermal buffer for the rest of the dwelling.
Pooja in NE (Ishanya / Water): Bathed in germicidal, soft morning ultraviolet light at sunrise.

In BuildWise AI, we codified this into a 9-Zone Purusha Mandala Matrix (app/services/vastu_service.py) that computes the exact cosine vector between the road access angle, sun azimuth, and the room placement score!

🎨 The UI: Apple Vibrancy & Native SVG Rendering

We wanted the interface to look like an Apple design award winner, not a dusty 1998 AutoCAD utility:

React 19 + Vite + Tailwind CSS: Zero lag, lightning fast hot-module reload.
Glassmorphism & Vibrancy Tokens: Translucent frosted acrylic panels (backdrop-blur-md, subtle borders, iOS-style spring animations).
Interactive SVG Blueprint Viewer (BlueprintViewer.tsx):
- Full vector pan/zoom with mouse wheel and pinch-to-zoom.
- Interactive layer toggles: Furniture, Architectural Dimensions, Vastu Quadrants, Plumbing Shafts, Column Structural Grids, and Fire Egress Paths.
- Room hover inspection showing exact floor areas, hygiene ratings, and ventilation percentages.
Server-Side ReportLab PDF Pipeline:
- Forget ugly window.print() hacks that break CSS grids.
- The FastAPI backend compiles a true, print-grade 174mm vector drawing with technical title blocks, QR code site hashes, and an executive cost scorecard directly into a download-ready PDF.

🧪 Rigorous Testing: 236 Unit Tests & 9-Viewport Audits

A civil engineering tool cannot afford "silent fails". If a floorplan generator silently drops a bedroom or generates an overlapping room, contractors waste real concrete.

We built a bulletproof testing pipeline:

# Frontend: Oxlint + TypeScript + 9-Viewport Puppeteer DOM audit
cd frontend
npm run lint          # Ultra-fast static analysis via Oxlint
npm run build         # Strict tsc type verification + Vite bundle
npm run audit:ui      # Puppeteer audits DOM integrity across 9 viewports

# Backend: 236 Pytest suites covering geometry, codes, and PDF rendering
cd ../backend
python -m pytest tests/

145-test placement regression suite: Validates that zero rooms overlap, all doors connect, and leaf invariants never break across 1,000 randomized plot aspect ratios.
L1–L14 Deterministic Validation Gate: Every single generated layout must pass a 14-layer inspection (validation_gate.py) before being marked with a MathematicalValidityCertificate.

🚀 Key Takeaways & Try It Yourself!

Building BuildWise AI proved three crucial engineering principles:

You don't need expensive mapping APIs to build world-class geospatial tech. OpenFreeMap, OpenTopoMap, USGS, and Copernicus offer petabytes of pristine public telemetry if you take the time to wire them properly.
LLMs should be the narrators, not the architects. Use deterministic algorithms and Constraint Satisfaction Solvers (CSP) for geometry, math, and building codes. Use LLMs for what they excel at: synthesizing executive summaries and explaining engineering trade-offs to human clients.
Cultural constraints are just mathematical rules in disguise. Whether it's the International Building Code, the National Building Code of India, or Vastu Shastra, all architectural lore can be codified into typed models and solved with graph theory.

🌟 Explore the Code & Contribute

BuildWise AI is 100% open-source under the MIT License.

GitHub Repository: https://github.com/Mrtracker-new/BuildWise_AI
Give it a Star ⭐ if you love open-source geospatial tools, civil engineering, or generative algorithms!
Try running it locally in 2 minutes:

  git clone https://github.com/Mrtracker-new/BuildWise_AI.git
  cd BuildWise_AI
  ./run_project.bat   # Or spin up backend & frontend via standard CLI

Got questions about spatial CSP, MapLibre GL styling, or Copernicus satellite queries? Drop them in the comments below — I’ll be hanging out and answering every single one! 👇

The Spy in the Barcode: Engineering Stealth QR Code Steganography published

Rolan Lobo — Fri, 18 Sep 2026 19:25:40 +0000

How I evolved ordinary QR codes into double agents: from fragile URL fragments to pure visual module structural isolation and a real-time WebRTC scanner.

The Core Challenge: Plausible Deniability

Standard QR codes are completely transparent. When you point your smartphone camera at a barcode, the decoded string (usually a URL or text block) is visible to every scanner and onlooker in the room.

If you embed sensitive data—such as cryptographic seed phrases, private credentials, or confidential memos—directly into the barcode, anyone who glances at or captures the code with their phone camera has full access to the plaintext.

Encrypting the text before generating the QR code doesn't solve the problem either. A QR code containing raw Base64 ciphertext screams: "I am hiding something!" That defeats the fundamental goal of steganography: plausible deniability.

The engineering challenge for InvisioVault was clear:

Can we generate a QR code that scans identically to a normal, innocent web address (e.g. https://example.com) on any smartphone camera in the world, while secretly concealing an authenticated, encrypted payload that only InvisioVault can detect and reveal?

The Journey: Three Failures Before the Breakthrough

Getting this right required navigating the harsh realities of physical optics, camera auto-exposure, and barcode parsing standards. Here is the path of failures that led to the final architecture.

Attempt 1: Null-Byte String Delimitation (`\x00`)

My first experiment was simple: separate the public URL from the hidden payload using a null byte:

https://example.com/\x00ENCRYPTED_SECRET

Why it failed: Mobile QR decoders handled this inconsistently. iOS Camera URL-encoded the byte as %00, producing a broken 404 URL. Android barcode decoders truncated the string at the first null character, permanently discarding the secret.

Attempt 2: Direct LSB Pixel Modification

Next, I treated the rendered QR code PNG like an ordinary carrier image, modifying the least-significant bit (LSB) of individual black and white pixel blocks.

Why it failed: Scanning a printed piece of paper or a laptop screen with a handheld camera introduces physical noise: ambient room lighting, lens blur, perspective tilt, and sensor color subsampling. LSB pixel values were destroyed before the image even reached the decoder.

Attempt 3: The URL Fragment Scheme (`#IVDATA:`)

I then leveraged RFC 3986 URI Fragments. Under web specifications, the fragment identifier (everything following the #) is processed client-side by browsers and is never transmitted to the host server in HTTP requests.

https://your-public-site.com/#IVDATA:<base64-fernet-encrypted-payload>

When scanned by a standard smartphone, the browser opened https://your-public-site.com/ and ignored the #IVDATA: fragment.

The Fatal Flaw: While functionally working, it failed modern steganographic muster:

Camera UI Leakage: iOS Camera and Google Lens display a popup bubble showing the decoded URL—including #IVDATA:.... Anyone observing the screen immediately saw an encrypted blob.
Social Preview Crawlers: Messaging apps (WhatsApp, Slack, Telegram, Discord, iMessage) generate link previews, exposing or caching the fragment.

Concealment was compromised. I needed a technique where the decoded barcode text contained 0% steganographic trace.

The Solution: Visual Module Steganography (Structural Isolation)

To achieve true stealth, the public data and the secret payload had to be separated at the matrix module level, not the URL string level.

In QR codes, individual black and white squares are called modules. A QR code is not just arbitrary pixels—it contains rigid geometric functional patterns that decoders require to locate, orient, and interpret the matrix:

┌─────────┐                ┌─────────┐
│ █ █ █ █ │ █  █  █  █  █  │ █ █ █ █ │  <-- Finder Patterns (7x7)
│ █     █ │                │ █     █ │
│ █ █ █ █ │ █  █  █  █  █  │ █ █ █ █ │
└─────────┘                └─────────┘
  █  █  █   [ Timing Line ]  █  █  █
  █         [ Safe  Modules]         █
┌─────────┐                ┌─────────┐
│ █ █ █ █ │ █  █  █  █  █  │ █ █ █ █ │  <-- Alignment Pattern (5x5)
│ █     █ │                │ █     █ │
│ █ █ █ █ │ █  █  █  █  █  │ █ █ █ █ │
└─────────┘                └─────────┘

If you alter a module in a functional pattern, standard decoders fail completely.

1. Structural Isolation Bitmask

InvisioVault generates an explicit boolean bitmask of the QR matrix and strictly protects:

Finder Patterns: The three $7\times7$ corner squares and their 1-module separators.
Timing Patterns: The alternating row and column lines synchronizing module spacing.
Alignment Patterns: Version-dependent $5\times5$ squares for perspective correction.
Format & Version Blocks: Modules defining Error Correction Level and QR Version.
Quiet Zone: The mandatory 4-module blank border.

2. Reed-Solomon Redundancy Parity Exploitation

With structural modules isolated, the remaining data space is governed by Reed-Solomon (RS) Error Correction Code (ECC).

By generating the base QR code with High Error Correction (Level H, offering up to 30% error recovery), we can systematically embed compressed, authenticated ciphertext bits into safe non-structural modules using deterministic pseudo-random distribution.

When scanned:

Everyday Camera Decoders (iOS Camera, Google Lens, ZXing): The RS decoder detects the steganographic modifications as recoverable "noise" or parity variations, corrects them seamlessly, and displays only the clean public URL:

   https://invisio-vault.vercel.app

No URL fragment. No #IVDATA:. Zero indication that anything is hidden.

InvisioVault Scanner: Reads the public matrix, calculates the exact module layout and cryptographic key, extracts the hidden bitstream, and decrypts the payload.

The Cryptographic Pipeline

A stealth carrier is useless if the payload is vulnerable to cryptanalysis. InvisioVault secures the hidden data before module embedding:

Secret Plaintext
       │
       ▼
PBKDF2-HMAC-SHA256 (480,000 Iterations + 16-byte Cryptographic Salt)
       │
       ▼
Fernet Symmetric Cipher (AES-128-CBC + HMAC-SHA256 Authentication)
       │
       ▼
zlib Deflate Compression (Level 9)
       │
       ▼
Reed-Solomon Parity Module Embedding (Safe Matrix Channels)

Key Derivation: A user password is stretched via PBKDF2 with 480,000 SHA-256 iterations and a cryptographically secure salt.
Authenticated Encryption: Fernet provides both AES-128-CBC confidentiality and an HMAC-SHA256 signature to prevent tampering.
Capacity Compression: Payloads are compressed with zlib (Level 9) to minimize the footprint inside the QR data modules.

Real-Time WebRTC Camera Pipeline Under 512 MB Constraints

Building live camera scanning into the browser requires extreme memory discipline. Uploading raw uncompressed camera video frames (which can be 70+ MB uncompressed at high resolutions) to a backend server on Render's free tier (512 MB RAM ceiling) would immediately trigger Linux OOM (Out Of Memory) kills.

I engineered a multi-stage hybrid edge-client pipeline:

Camera Video Stream (getUserMedia @ 1080p)
                   │
                   ▼
       Native Resolution Capture
                   │
         ┌─────────┴─────────┐
         ▼                   ▼
  Original Canvas     Enhanced Canvas
 (Color fidelity)   (2x Bilinear Upscale +
                     Grayscale + 50% Contrast)
         │                   │
         ▼                   ▼
   jsQR Detection      jsQR Detection
         │                   │
         └─────────┬─────────┘
                   │
        [ QR Code Detected? ]
          ├── Yes ──> Extract Locally in Browser Memory
          └── No  ──> Check SHA-256 Frame Deduplication Cache
                      └── Fallback to Server zxing-cpp Engine

1. Dual-Canvas Client-Side Enhancement

Camera video streams often suffer from low light, motion blur, or poor contrast. The client creates two off-screen canvases:

Canvas 1 (Native): Preserves subtle color variations and logo overlays.
Canvas 2 (Enhanced): Applies a 2x bilinear upscale, grayscales the frame, and stretches contrast by 50% to extract distant or skewed barcodes.

2. Browser-First Decoding (`jsQR`)

The frontend attempts to decode both canvases locally using WebAssembly/pure JavaScript jsQR. If decoded, it extracts the data entirely in-browser without sending a single byte over the wire.

3. SHA-256 Frame Deduplication Cache

If a frame is too distorted for jsQR, the frame is sent to the backend's C++ zxing-cpp engine. To prevent redundant computation during a 30 fps stream:

The backend computes an in-memory SHA-256 digest of incoming frame buffers.
Duplicate or nearly identical camera frames immediately return cached results in < 2ms, reducing server CPU load by 60–80%.

Why Stream Mode is Kept as Read-Only

In InvisioVault v2.0+, Stream Mode generation has been retired. The UI only produces clean Visual Module QR codes.

However, backwards compatibility is a core engineering principle. If a user encounters an older v1.x QR code that utilizes #IVDATA:, both the frontend scanner and the backend /api/qr/scan route recognize the # fragment and decrypt the legacy payload seamlessly.

Capability	Visual Module Mode (v2.0+)	Legacy Stream Mode (v1.x)
Generation Status	Active (Default & Exclusive)	Retired (Intentional)
Scanner Support	Full Support	Full Support (Backward compatible)
Public Decoded URL	`https://example.com` (Clean)	`https://example.com#IVDATA:...`
Plausible Deniability	100% (Indistinguishable from normal QR)	Compromised (Fragment visible)

Takeaways

Steganography requires plausible deniability: If a third party knows data is hidden, the steganographic guarantee is broken.
Work with the specification, not against it: Exploiting Reed-Solomon error correction and module bitmasks produces clean, standardized barcodes that scan on any standard phone.
Optimize the edge before hitting the server: Running dual-canvas preprocessing in client JavaScript saves immense server memory and allows production deployments even on resource-constrained 512 MB instances.

Try generating and scanning your own stealth QR code live at InvisioVault or explore the complete open-source implementation on GitHub.

I Built a Privacy-First, Human-Friendly Alternative to Wireshark in Rust & Tauri 🚀

Rolan Lobo — Mon, 10 Aug 2026 13:04:36 +0000

Have you ever opened Wireshark to figure out why your app is failing to connect, only to be greeted by a terrifying wall of 50,000 raw packet hex bytes? 😅

Don't get me wrong — Wireshark is an engineering masterpiece. But for most developers, debugging a network issue shouldn't require a Ph.D. in Wireshark display filters just to answer three simple questions:

What actually happened on my network?
Which app or process caused it?
Is it dangerous or normal?

That's why I've been building NetPulse (formerly NetPlus) — a local-first, privacy-focused, beginner-friendly Internet observability platform built from scratch in Rust and React/Tauri.

Our goal? Making the Invisible Internet Visible. 🌐✨

💥 The Problem: Raw Data vs. Actual Understanding

When something goes wrong on the wire, traditional tools throw raw bytes at you first and leave the interpretation to you:

14:02:01.482019 IP 192.168.1.45.52412 > 1.1.1.1.53: 41203+ A? api.github.com. (32)
14:02:01.501923 IP 1.1.1.1.53 > 192.168.1.45.52412: 41203 1/0/0 A 140.82.121.4 (48)

Unless you process packet traces in your sleep, translating raw 5-tuples into human concepts takes cognitive effort:

You have to correlate TCP handshake SYN/ACK flags to spot latency.
You have to cross-reference IP addresses with netstat or lsof to find out which process made the request.
Cloud-based telemetry tools solve this, but at a huge cost: they upload your private network traffic to someone else's server.

NetPulse was designed from the ground up to solve all three issues: deliver understanding first, correlate processes automatically, and keep 100% of your data on your machine.

✨ Meet NetPulse: Understanding First, Deep Inspection One Click Away

NetPulse reconstructs, explains, and teaches the complete story behind network events on your computer.

Here is what makes it different:

1. 🪜 Progressive Disclosure (Beginner → Intermediate → Expert)

Instead of forcing everyone into an expert-only interface, NetPulse serves one rich data model across three distinct depth levels:

🟢 Beginner Mode: Human narrative cards. Plain-English summaries like: > "Spotify requested audio stream data from Fastly CDN over encrypted TLS 1.3 (1.2 MB transferred in 45ms)."
🟡 Intermediate Mode: Interactive flow diagrams, connection latency metrics, protocol distribution, and local OS process attribution (e.g., spotify.exe PID 4812).
🔴 Expert Mode: Zero-copy packet hex dump, frame disassembly, raw TCP state machine inspection, and PCAP export.

2. 🧠 Narrative Engine: Turning Packets into Stories

Under the hood, netpulse-narrative correlates packets into bi-directional flows, synthesizes causal HTTP transactions and TLS handshakes, and projects them into human-understandable Story Cards.

No more guessing if a burst of UDP traffic was a DNS lookup or a video stream — NetPulse groups related events into single coherent timelines.

3. 🛡️ Calibrated Security & Anomaly Detection

Security findings shouldn't be binary "good/bad" guesses that generate alert fatigue.

NetPulse includes built-in engines for:

DNS Tunneling & Data Exfiltration Detection
Port Scanning & Reconnaissance Analysis
Statistical Bandwidth & Latency Anomaly Engine

Every finding carries an explicit, calibrated confidence score (e.g., 92% Confidence — DNS Tunneling pattern detected based on entropy & query frequency) directly linked to exact packet evidence.

4. 🎓 Built-in Education & The "Website Load Journey"

One of my favorite features in NetPulse is the Interactive Curriculum (netpulse-learn):

Website Load Journey: Hit a button to visually simulate and explain everything that happens when you type https://google.com into your browser — from OS socket creation, DNS resolution, ARP table resolution, TCP 3-way handshake, TLS 1.3 key exchange, to HTTP GET requests.
Protocol Explorer: An interactive reference guide built right into the app to learn how Ethernet, IP, TCP, UDP, DNS, TLS, and HTTP work under the hood.

5. 🔒 Local-First & 100% Private

Privacy isn't an afterthought; it's an architectural invariant:

Zero Remote Egress: All parsing, flow aggregation, and anomaly detection happen offline in Rust.
Auditable Egress Boundary: The entire backend has a strict rule prohibiting outbound network calls. The only exception is netpulse-ai, an opt-in local/remote LLM assistant boundary that you explicitly control.

🛠️ The Architecture: How It's Built

NetPulse is built as a multi-crate Rust workspace paired with a high-performance React + Tauri v2 frontend.

┌─────────────────────────────────────────────────────────────────────────┐
│                           Desktop User UI                               │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │                    Vite + React Application                       │  │
│  │     (@netpulse/app, @netpulse/components, @netpulse/viz)          │  │
│  └─────────────────────────────────┬─────────────────────────────────┘  │
│                                    │ IPC (Tauri v2 invoke / events)     │
│  ┌─────────────────────────────────▼─────────────────────────────────┐  │
│  │                    Tauri Desktop Shell (`src-tauri`)              │  │
│  └─────────────────────────────────┬─────────────────────────────────┘  │
└────────────────────────────────────┼────────────────────────────────────┘
                                     │ Query / Command (netpulse-api v4)
┌────────────────────────────────────▼────────────────────────────────────┐
│                        Engine Process (`netpulse-engine`)               │
│                                                                         │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────┐  │
│  │  narrative   │   │    intel     │   │    learn     │   │    ai    │  │
│  └──────┬───────┘   └──────┬───────┘   └──────┬───────┘   └────┬─────┘  │
│         └──────────────────┼──────────────────┘                │        │
│                            ▼                                   │        │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐        │        │
│  │    storage   │◀──│     flow     │◀─│    decode    │        │        │
│  └──────────────┘   └──────────────┘   └──────┬───────┘        │        │
│                            ▲                  │                │        │
└────────────────────────────┼──────────────────┼────────────────┼────────┘

The Tech Stack Highlights:

Rust (14 Workspace Crates):
- netpulse-decode: Zero-copy protocol dissectors (Ethernet, IPv4/v6, TCP, UDP, DNS, HTTP, TLS) fuzzed with cargo-fuzz.
- netpulse-flow: 5-tuple flow aggregation state machine with causal event ordering.
- netpulse-platform: Cross-platform OS bindings (Npcap on Windows, AF_PACKET on Linux, BPF on macOS) and socket process attribution (GetExtendedTcpTable).
TypeScript & React 18 Workspace:
- @netpulse/contract: Auto-generated TypeScript DTOs from Rust structs, enforced in CI to prevent drift.
- @netpulse/viz: WebGL and Canvas graphics for real-time sparklines, flow diagrams, and bandwidth meters.
- Tauri v2 Shell: Ultra-lightweight native desktop window with tiny memory footprint compared to Electron.

💡 Key Lessons Learned

Building a high-throughput network engine in Rust taught us a few crucial lessons:

Zero-Copy Everything Matters: Parsing gigabytes of packet data per second will shred your CPU if you allocate heap memory per frame. Slicing raw bytes directly with Rust lifetimes keeps memory usage flat.
Type Safety Across IPC: Generating TypeScript types directly from Rust DTOs (netpulse-api → @netpulse/contract) eliminated an entire class of serialization bugs between Tauri and React.
Privilege Separation: Capturing raw network sockets requires elevated privileges (Administrator/CAP_NET_RAW). Instead of running the entire UI and engine as admin, NetPulse isolates packet capture into a tiny daemon (netpulse-capture-svc), keeping the main engine and webview at normal user privileges.

🎯 What's Next?

NetPulse is actively developing live Npcap capture streaming, WASM plugin loaders, and an offline local ONNX model backend for offline conversational packet queries.

If you love network engineering, Rust, React, or privacy-first software, we'd love for you to check out the project, star the repository, or contribute!

⭐ GitHub Repository: NetPulse on GitHub

💬 Over to You!

How do you currently debug network issues in your stack? Would a human-readable, progressive packet analyzer fit into your workflow?

Let me know in the comments below! 👇

Building a Native Desktop Video Downloader with Rust and Tauri — What I Learned the Hard Way

Rolan Lobo — Sat, 27 Jun 2026 12:28:30 +0000

Every developer has a tool they wish existed. Mine was a video downloader that wasn't a bloated Electron app, didn't require a terminal setup ritual, and didn't look like it was designed in 2008. So I built it.

YT Downloader is a desktop app built with Tauri 2, Rust, and React. It wraps yt-dlp — the gold standard for video downloading — in a clean native interface. Support for YouTube, Vimeo, Instagram, Twitter/X, and 1000+ other sites. Video up to 8K. Audio in MP3, FLAC, Opus, and WAV. SponsorBlock integration. Concurrent downloads with a real queue. A hand-drawn sketch aesthetic because why not.

This post isn't a tutorial on how to use it. It's about the engineering decisions and bugs I had to fight through to ship something that actually feels like a production app.

Why Tauri Instead of Electron

The honest reason is bundle size. An Electron app ships an entire Chromium browser — your "desktop app" is a 150MB zip file for the installer alone. Tauri uses the operating system's native WebView, which means the same app ships as a 4MB installer.

The tradeoff: you write a real Rust backend. The IPC boundary between JavaScript and the OS is typed and explicit. There's no require('fs') — every system call goes through a Tauri command handler. It's more work, but the result is an app that launches in under a second and uses roughly 30MB of RAM at idle. For a utility tool you open and close dozens of times a day, that matters.

The Stack

The backend is Rust with tokio for async, rusqlite (bundled SQLite) for history and settings persistence, reqwest for HTTP, and the Windows Job Objects API for process management. The frontend is React 18 with TypeScript, Zustand for state, MUI v5 for components, and Framer Motion for animations.

yt-dlp and ffmpeg are the actual download engines. The app manages them — spawning, monitoring, killing — rather than simply calling them and hoping for the best.

Problem 1: Making the App Work Without Any Prerequisites

Most users will never run pip install yt-dlp before opening a desktop app. They'll just double-click and expect it to work. If it doesn't, they'll close it and move on.

The solution was to make the app download its own tools on first run. On startup, the Rust backend checks for yt-dlp and ffmpeg in a local app data directory. If they're missing, a setup screen appears and streams the downloads directly from GitHub Releases — with a real progress bar, not a spinner.

#[tauri::command]
pub async fn download_ytdlp(app_handle: AppHandle) -> Result<String, String> {
    let url = if cfg!(windows) {
        "https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp.exe"
    } else if cfg!(target_os = "macos") {
        "https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp_macos"
    } else {
        "https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp"
    };

    let mut stream = response.bytes_stream();
    while let Some(chunk) = stream.next().await {
        file.write_all(&chunk)?;
        emit_progress(&app_handle, "yt-dlp", pct, "downloading", &msg);
    }
}

There was a subtle bug in the initial version: it only downloaded ffmpeg.exe. SponsorBlock segment removal also needs ffprobe to read video durations. Without it, cutting sponsors would silently fail. The fix was a single check at startup:

// A partial install breaks SponsorBlock. Treat it as needing full setup.
let partial_ffmpeg = ffmpeg.is_some() && ffprobe.is_none();
let needs_setup = ytdlp.is_none() || partial_ffmpeg;

Now if ffprobe is missing, the setup wizard re-runs and grabs both binaries together.

Problem 2: Killing a Child Process on Windows Is Harder Than It Sounds

When a user pauses or cancels a download, you need to stop yt-dlp. That seems straightforward — call .kill() on the child process. The problem is that yt-dlp spawns ffmpeg as its own child for merging video and audio streams. When you kill yt-dlp, ffmpeg keeps running in the background, holding file locks. The next download attempt fails with a cryptic "file in use" error.

On Linux and macOS, the fix is simple — send SIGKILL to the entire process group:

#[cfg(not(windows))]
fn kill_process_tree(pid: Option<u32>, _job: Option<()>) {
    use nix::sys::signal::{killpg, Signal};
    let _ = killpg(Pid::from_raw(pid as i32), Signal::SIGKILL);
}

Windows doesn't have Unix process groups. The tempting shortcut is taskkill /F /T, but that spawns yet another process — there's a race window where ffmpeg can escape the kill. The correct OS-level tool is a Windows Job Object.

#[cfg(windows)]
fn create_job_object_for_pid(pid: Option<u32>) -> Option<HANDLE> {
    unsafe {
        let job = CreateJobObjectW(None, PCWSTR::null())?;

        // If our process dies unexpectedly, the OS kills the tree anyway
        let mut info = JOBOBJECT_EXTENDED_LIMIT_INFORMATION::default();
        info.BasicLimitInformation.LimitFlags = JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE;
        SetInformationJobObject(job, ...);

        // Must happen immediately after spawn, before yt-dlp forks ffmpeg
        AssignProcessToJobObject(job, proc_handle)?;
        Some(job)
    }
}

The critical detail: AssignProcessToJobObject must be called immediately after spawning yt-dlp, before it has a chance to fork ffmpeg. Any process spawned after the parent is assigned to a Job Object is automatically included. Calling TerminateJobObject then kills the entire tree atomically — no race, no orphaned processes.

Problem 3: A Race Condition Hidden Inside the Pause Feature

This was the most embarrassing bug to track down, because it only appeared under a specific timing condition.

The symptom: press Pause, the UI shows "Paused", press Resume, and... nothing happens. The download sits there forever.

The root cause was a 100ms poll loop checking a shared AtomicBool flag. When pause was triggered:

The UI optimistically set the job status to Paused.
The poll loop woke up on the next 100ms tick, killed the process, and the tokio task returned.
The task cleanup removed the job handle from active_handles.

But the resume handler called advance_queue() immediately, while step 3 was still running in the background. The handle hadn't been removed yet. advance_queue saw no free slots and left the job stuck in Queued forever.

The fix had two parts. First, replace the poll loop with a tokio::watch channel and tokio::select!, which reacts to signals immediately rather than waiting for a tick:

let control_watcher = tokio::spawn(async move {
    loop {
        watcher_rx.changed().await?; // wakes immediately on signal
        match *watcher_rx.borrow() {
            ControlSignal::Pause => {
                kill_process_tree(child_pid, job_handle);
                // Emit AFTER the process is dead — no race with progress events
                app.emit("download://paused", PausedEventPayload { job_id });
                break;
            }
            ControlSignal::Cancel => {
                kill_process_tree(child_pid, job_handle);
                cleanup_temp_files(&output_dir);
                app.emit("download://cancelled", CancelledEventPayload { job_id });
                break;
            }
            ControlSignal::Run => continue,
        }
    }
});

Second, the resume handler now takes the lingering task handle out of the map and waits for it in a background task — never holding the manager mutex across an await:

pub async fn resume_download(&mut self, job_id: &str, ...) -> Result<()> {
    job.status = JobStatus::Queued;
    let lingering_handle = self.active_handles.remove(job_id); // take it out

    tokio::spawn(async move {
        if let Some(handle) = lingering_handle {
            // Wait for old task to finish cleanup (max 3 seconds)
            let _ = tokio::time::timeout(Duration::from_secs(3), handle).await;
        }
        // Slot is now guaranteed free
        let mut mgr = self_arc.lock().await;
        mgr.advance_queue(app_handle, db, self_arc.clone());
    });

    Ok(())
}

Problem 4: `--continue` Causes ffmpeg to Hang at 99%

yt-dlp has a --continue flag designed to resume partial downloads. It sounds like exactly what a pause/resume feature should use. It isn't.

When a partial file is in an inconsistent state — network dropped mid-stream, user forced-closed the app — resuming with --continue hands ffmpeg a corrupt input. ffmpeg dutifully tries to process it, stalls, and never exits. The progress bar sits frozen at 99% indefinitely. This was the "long video stuck on a purple bar" problem mentioned in the README.

The counterintuitive fix: always restart downloads from scratch. Pass --no-part to prevent yt-dlp from writing .part files entirely, accept that pausing means a full restart, and in exchange get a merge step that is 100% reliable every time.

cmd_args.extend([
    "--no-part",      // no partial files = no corrupt partial files
    "--retries", "5",
    "--fragment-retries", "5",
    // --continue intentionally absent
]);

Problem 5: Keeping the UI and Backend in Sync

The frontend subscribes to a stream of Tauri events: download://progress, download://paused, download://complete, and so on. This creates a classic distributed state problem. When a user pauses a download:

The UI does an optimistic update and marks the job "Paused."
A progress event that was already in-flight arrives from the Rust backend.
The progress event overwrites the status back to "Downloading."
The actual download://paused event arrives and fixes it.

The UI flickered. Users thought the pause hadn't registered.

The fix was a queue://updated event — a canonical snapshot of all job states emitted from the backend after every state change:

fn emit_queue_updated(&self, app_handle: &AppHandle) {
    let payload = QueueUpdatedPayload {
        active_count: self.active_handles.len(),
        jobs: self.jobs.values().map(|j| QueueJobDto {
            job_id:   j.job_id.clone(),
            status:   j.status.as_str().to_string(),
            progress: j.progress,
            // ...
        }).collect(),
    };
    app_handle.emit("queue://updated", payload);
}

The frontend treats queue://updated as the authoritative source of truth for job statuses. Individual progress events update the progress bar, but status fields are only updated by the canonical snapshot. Since the snapshot is emitted after the process is confirmed dead, a stale in-flight progress event can never win a race against it.

A Few Other Things Worth Mentioning

Cancel vs. Pause cleanup: When a download is cancelled, yt-dlp's intermediate stream files (Video.f137.mp4, Video.f140.m4a) are deleted. On pause, they're left alone. The cleanup function uses a pattern match to identify stream fragments:

fn is_ytdlp_stream_fragment(path: &Path) -> bool {
    // Matches "Title.f137.mp4" — stem ends with ".fNNN"
    let stem = path.file_stem()?.to_str()?;
    if let Some(dot_pos) = stem.rfind('.') {
        let suffix = &stem[dot_pos + 1..];
        return suffix.starts_with('f') && suffix[1..].chars().all(|c| c.is_ascii_digit());
    }
    false
}

Cookie handling on Windows: Chrome and Edge use App-Bound Encryption to protect cookies, which means yt-dlp's --cookies-from-browser chrome flag often fails on Windows. The app supports a cookies.txt fallback that users can export from a browser extension. The file-based path sidesteps DPAPI entirely and works universally across sites.

Security: URLs are sanitized before writing to log files. Download paths are validated against a base directory to prevent traversal. Job IDs are validated against a UUID pattern in every command handler that accepts one. yt-dlp is always spawned with an explicit argument array — never via shell interpolation.

What This Taught Me

Writing a desktop app with Tauri is rewarding, but the hard problems aren't in the Tauri API itself. They're in the gaps between layers: between the OS process model and your async runtime, between your backend state and your frontend state, between what a flag's documentation says and what it actually does in edge cases.

The biggest lesson: poll loops are almost always the wrong tool for reactive signaling. Every bug that started with "it works 90% of the time" in this project traced back to a poll loop with a tick delay. tokio::watch with tokio::select! is not significantly harder to write and eliminates an entire class of timing bugs.

Try It

The full source is on GitHub at github.com/Mrtracker-new/YT_Download.

If you have Node 18+ and Rust installed, getting it running takes about a minute:

git clone https://github.com/Mrtracker-new/YT_Download.git
cd YT_Download
npm install
npm run dev

yt-dlp and ffmpeg auto-download on first run. No prerequisites beyond the two build tools.

The project has had some interesting engineering decisions baked into it. If any of the problems above are familiar from your own work, or if you've solved them differently, I'd be curious to hear about it in the comments.

I Built a Chat App That Deletes Itself (Because I Was Bored at 2am)

Rolan Lobo — Sat, 30 May 2026 16:54:46 +0000

I'm going to be honest with you.

It started because I watched a spy movie, thought "this message will self-destruct in 5 seconds" was the coolest thing ever, and immediately opened VS Code instead of going to sleep like a normal person.

Seven days, one developer (me, just me, no team, no co-founder, no intern, nobody — just me, my laptop, and an unhealthy amount of coffee), I had Burn Chat running.

Here's what it does: you create a chat room with a countdown timer. Share the link. People join. You talk. When the timer hits zero, every single message on every single screen disappears. The server deletes everything. There's no history, no logs, no exports, no "deleted messages" folder. It's just... gone. Forever.

This is the story of how I built it, what I got completely wrong, and the parts I'm actually proud of.

👉 Try it live: bar-rnr.vercel.app/burn-chat

What I Was Actually Going For

The feature list I had in my head at 2am:

⏱️ Set a countdown timer (5 min to 24 hr)
🔐 End-to-end encryption — the server should never be able to read messages
🔥 When the timer hits zero, everyone sees a fire animation simultaneously
🔗 One link to share, no accounts, no sign-up
👑 A PIN so the creator can kick people, lock the room, extend the timer
🚫 Absolutely nothing stored on disk or in a database

That last one is important. If I'm going to call this "ephemeral", it had better actually be ephemeral. Not "ephemeral but we keep logs for 30 days for compliance reasons." Actually gone.

The Architecture (Or: What I Drew on a Napkin)

Your Browser                 My Server                  Their Browser
────────────────             ──────────────             ──────────────
Generate keys                                           Generate keys
Send public key  ──────────► store in RAM ────────────► get public key

Encrypt message  ──────────► relay blob   ────────────► decrypt message
(AES-GCM)        server sees ????base64????              (AES-GCM)
                 literally has no idea
                 what it says

The server is a blind courier. It sees base64 blobs going in one WebSocket and coming out another. It has no idea what the messages say. It stores nothing on disk.

This is not a marketing claim. The server genuinely cannot decrypt the messages because it never has the keys.

Part 1: The Backend — Python, FastAPI, and Some Questionable Choices

I Used a Dictionary to Store Sessions

# I could have used Redis. I used this.
_SESSIONS: Dict[str, _ChatSession] = {}

Yes. A plain Python dictionary. In memory. On one process.

You might be thinking: "that's not scalable."

You're right. It's also exactly what I needed. Here's my thinking:

If I store sessions in Redis, Redis is a database. Databases write to disk. If data touches disk, it can be recovered. I'm building a feature whose entire selling point is that data CANNOT be recovered. A plain in-memory dict that disappears when the process restarts is a feature, not a bug.

I'm one person. I have one dyno. It works. When I need to scale, I'll figure out sticky sessions + Redis with a EXPIRE key. That day is not today.

Each Session Gets a Timer

async def _countdown_loop(token: str, session: _ChatSession) -> None:
    try:
        while True:
            now = datetime.now(timezone.utc)
            remaining = (session.expires_at - now).total_seconds()

            if remaining <= 0:
                break

            # Coarse ticks when there's plenty of time.
            # 1-second ticks in the final minute for smooth UI animation.
            interval = 1.0 if remaining <= 60 else 10.0
            sleep_for = max(0.05, min(interval, remaining))
            await asyncio.sleep(sleep_for)

            # ⚠️ Always recompute from the wall clock.
            # Never trust sleep() duration — it drifts under load.
            remaining = (session.expires_at - datetime.now(timezone.utc)).total_seconds()

            await _broadcast(session, {
                "type": "countdown",
                "seconds_remaining": max(0, int(remaining))
            })

    except asyncio.CancelledError:
        return

    await _destroy_session(token)

The important bit: always recompute remaining from the actual wall clock. Never decrement a counter. Python's asyncio.sleep() can sleep longer than you asked if the event loop is busy. If you accumulate sleep durations, your 10-minute timer ends up being 11 minutes. Recomputing from expires_at - now every tick keeps it accurate.

Burning the Session

async def _destroy_session(token: str) -> None:
    session = _SESSIONS.get(token)
    if session is None:
        return  # already gone, nothing to do

    # Step 1: Tell EVERYONE to show the fire animation.
    await _broadcast(session, {"type": "destroyed"})

    # Step 2: Close every WebSocket connection.
    for participant in list(session.participants.values()):
        try:
            await participant.ws.close(code=1000, reason="Session expired")
        except Exception:
            pass

    # Step 3: Delete from memory. This IS the burn.
    _SESSIONS.pop(token, None)

Order is important here. Broadcast first — otherwise you'd close the connections before clients know to show the animation. Everyone sees the fire at the same time because the broadcast goes out in a single loop before any connections are closed.

Part 2: The Crypto — The Part That Made My Brain Hurt

I want to be upfront: cryptography is hard. I read a lot. I tested a lot. I still probably got some edge case wrong. But here's what I implemented and why.

Key Generation

Every person who joins generates an ECDH P-256 keypair in their own browser:

const keypair = await crypto.subtle.generateKey(
  { name: 'ECDH', namedCurve: 'P-256' },
  false,         // ← this means the private key CANNOT be exported
  ['deriveKey']
);

See that false? That's extractable: false. The Web Crypto API gives you a hard guarantee: even if some JavaScript on the page tries to export that private key, the browser will refuse. The private key is born in your browser and dies in your browser.

The Key Exchange

Each participant broadcasts their public key to the server. The server stores it (as an opaque blob it can't use for anything) and relays it to everyone else:

// You send this when you connect
ws.send(JSON.stringify({
  type: 'pubkey',
  public_key: await exportPublicKey(myKeypair)
}));

The creator then derives a shared ECDH secret with each participant, generates one AES-GCM-256 session key, and sends each person a version wrapped (encrypted) with their specific shared secret:

async function wrapSessionKey(sessionKey, peerPublicKeyB64, myPrivateKey) {
  // Derive a shared secret using our private key + their public key
  const sharedSecret = await crypto.subtle.deriveKey(
    { name: 'ECDH', public: await importPeerPublicKey(peerPublicKeyB64) },
    myPrivateKey,
    { name: 'AES-KW', length: 256 },
    false,
    ['wrapKey']
  );

  // Wrap the session key with the shared secret
  const wrapped = await crypto.subtle.wrapKey('raw', sessionKey, sharedSecret, 'AES-KW');
  return btoa(String.fromCharCode(...new Uint8Array(wrapped)));
}

The server receives an opaque blob for each recipient and delivers it. It has no idea what's inside. Even if someone hacked my server right now while you were chatting, they'd get base64 they can't do anything with.

Encrypting Messages

Every message gets a fresh 12-byte random IV:

async function encryptMessage(text, sessionKey) {
  const iv = crypto.getRandomValues(new Uint8Array(12));  // fresh every time
  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    sessionKey,
    new TextEncoder().encode(text)
  );

  return {
    ciphertext: btoa(String.fromCharCode(...new Uint8Array(ciphertext))),
    iv: btoa(String.fromCharCode(...iv)),
  };
}

Fresh IV per message is non-negotiable. I'll explain why in the mistakes section.

The Session Fingerprint

After key exchange, everyone computes this:

async function deriveFingerprint(sessionKey) {
  const raw = await crypto.subtle.exportKey('raw', sessionKey);
  const hash = await crypto.subtle.digest('SHA-256', raw);
  const bytes = new Uint8Array(hash);
  return Array.from(bytes.slice(0, 3))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');  // something like "a3f9c2"
}

Everyone in the session sees the same 6-character hex code. If you're paranoid, read it out loud to the other person. If your codes match, the key exchange wasn't tampered with. Is it perfect? No. Is it better than nothing? Absolutely.

Part 3: The Frontend — React, Fire, and a State Machine

Three Phases, One Component

The entire chat UI lives in one state variable:

const [phase, setPhase] = useState('join');
// 'join'      → name entry, waiting to connect
// 'chat'      → connected, messaging, countdown ticking
// 'destroyed' → fire animation, then... nothing

Simple. No routing. No URL changes. Just a state string that drives which thing you see.

The Burn Animation

The part I spent way too long on and absolutely do not regret:

// BurningAnimation.jsx
// mode="chat" for Burn Chat, mode="file" for file destruction

{mode === 'chat' ? (
  <div className="text-center">
    <Flame size={56} className="text-orange-400 animate-pulse mx-auto" />
    <h2 className="text-2xl font-bold text-orange-400 mt-4">
      Session Burned
    </h2>
    <p className="text-gray-400 text-sm mt-2">
      All messages have been permanently erased. No trace remains.
    </p>
  </div>
) : (
  <div className="text-center">
    <FileX size={56} className="text-red-400 mx-auto" />
    <h2 className="text-2xl font-bold text-red-400 mt-4">
      File Destroyed
    </h2>
  </div>
)}

I reused the same animation component for file destruction and chat destruction, added a mode prop, and now it knows which version to show. The timing, the progress bar, the fade — all identical. Different icon, different text, different feeling.

Creator Controls

When you create a session, you get a PIN. Enter it when you connect and you unlock: kick participants, lock the room so no one new can join, and extend the countdown. The PIN is sent over the WebSocket (under TLS) and compared server-side with secrets.compare_digest() — constant-time comparison so you can't do timing attacks to guess digits one by one.

Three wrong PINs in 10 minutes and you're locked out. I'm not taking any chances with brute force.

The Mistakes (a.k.a. The Educational Section)

Mistake 1: I Reused the IV

Early version. I generated one IV when the session was created and reused it for every message.

This is catastrophically wrong with AES-GCM.

Reusing an IV with the same key doesn't just "weaken" the encryption. It breaks it completely. An attacker who collects two messages encrypted with the same key and same IV can XOR the ciphertexts and recover the XOR of the plaintexts — which combined with any knowledge of one message's content, reveals the other. The 96-bit IV space with fresh random IVs per message means you'd need to send ~4 billion messages before a collision becomes likely. Fine.

Fresh IV every single time. No exceptions.

Mistake 2: I Forgot About Late Joiners

Alice creates the session. Bob joins. They exchange public keys. The session key is distributed.

Then Carol joins.

Carol never received Bob's public key broadcast. Bob's not going to re-send it — he already sent it. Carol can't decrypt anything Bob sent before she joined.

The fix: store every participant's public key on the server-side participant object. When anyone joins, the server includes every existing participant's public key in the joined response. Carol gets everyone's keys in one message the moment she connects, no matter when she joins.

@dataclass
class _Participant:
    ws: WebSocket
    ws_id: str
    name: str
    is_creator: bool = False
    public_key: Optional[str] = None  # ← stored here, sent to late joiners

Mistake 3: I Decremented the Timer Instead of Using the Wall Clock

First implementation:

# WRONG — don't do this
remaining = ttl_seconds
while remaining > 0:
    await asyncio.sleep(1)
    remaining -= 1  # ← this drifts

Under any real server load, asyncio.sleep(1) sleeps for 1.003 seconds, or 1.01 seconds, or however long the event loop was busy. Multiply that over 600 ticks for a 10-minute session and your timer is off by 6–10 seconds.

The fix is what I showed earlier — always compute remaining = expires_at - datetime.now(). The wall clock doesn't drift.

What Actually Happens When It Burns

Let's trace the exact moment a session ends:

_countdown_loop wakes up, computes remaining ≤ 0
Calls _destroy_session(token)
Server broadcasts {"type": "destroyed"} to every WebSocket simultaneously
Every browser receives the message in the same event loop iteration
Every client's React state changes to phase = 'destroyed'
Every screen shows the flame animation at the same moment
Server closes all WebSocket connections
_SESSIONS.pop(token) — Python garbage collects the dict entry

From step 3 to step 8, the real-world time is milliseconds. There's no race where one person sees the burn and another doesn't for a few seconds.

The Honest Security Section

I'm not going to pretend this is Signal. Here's what it actually does:

Protects you from:

✅ Someone hacking my server and reading messages (server only has ciphertext)
✅ Passive network interception (TLS + E2E encryption)
✅ Accidentally leaving a chat history lying around
✅ The "I sent that to the wrong person" anxiety (it's gone in 5 minutes anyway)

Does NOT protect you from:

❌ The other person screenshotting your messages (classic)
❌ Someone compromising your browser specifically
❌ A sufficiently motivated adversary with physical access to a device
❌ The session fingerprint requires you to actually compare codes out loud — if you skip that step, technically MITM is possible

Use this for: private conversations you genuinely want to disappear.

Don't use this for: evading law enforcement, anything actually illegal, evidence tampering.

If I Had More Time (And More Energy)

Things I'd add if I weren't one person doing this in my spare time:

Redis + sticky sessions — right now the in-memory dict means one server instance. Horizontal scaling would need Redis (but with careful thought about what goes in Redis vs. stays ephemeral).

A proper ratchet — the current design uses one session key for all messages. The Double Ratchet algorithm (what Signal uses) gives each message its own key derived from the previous one — compromise of one message doesn't reveal any others. Cool. Complex. Maybe v2.

Forward secrecy at the server layer — currently if somehow the session key leaked, all past messages in that session could be decrypted. A proper ratchet would fix this.

The fingerprint experience — right now it's a code you can optionally compare. It should be more prominent, maybe with a visual comparison like Signal's Safety Numbers.

Try It

Two tabs. Open them both.

Go to bar-rnr.vercel.app/burn-chat
Create a session with a 5-minute timer
Copy the link, open it in the second tab
Send some messages between the tabs
Wait for the timer, or just wait for the fire

Everything disappears. Both tabs. At the same time.

It's a small thing but it never gets old.

Source code: github.com/Mrtracker-new/BAR_RYY

Built by one person, alone, late at night, because spy movies are inspiring and sleep is overrated. If you find a bug, open an issue. If you find a security hole, please tell me before you do anything fun with it. 🔥

Your Backend Is Leaking Secrets (Mine Was Too)

Rolan Lobo — Fri, 17 Apr 2026 16:11:52 +0000

Ever had that feeling where your app works perfectly… but deep down you know it's kinda unsafe?

Yeah — that was me.

So I went all-in on fixing some serious backend security flaws in my project:
👉 BAR (Burn After Reading) — a secure file system with self-destruct capabilities.

And honestly? This round of fixes made the project feel 10x more production-ready.

Let me walk you through what I fixed — in a way that actually makes sense 👇

🚨 The Problem

The app was functional, but under the hood:

Sensitive error messages were leaking 😬
Debug print() statements were everywhere
Logging wasn’t structured
Some code paths were… let’s say “questionable choices”

Nothing was breaking — but from a security perspective?
It needed serious tightening.

🛠️ What I Fixed (The Real Stuff)

1. 💀 Killing Error Leaks (Big One)

Before:

detail=str(e)

Yeah… that means if something fails, users might see internal errors, stack traces, even SMTP failures.

After:

detail=security.OPAQUE_500_DETAIL

Now:

Users get a generic safe message
Real errors go to logs (where they belong)

👉 Result: No internal system info leaks to clients

2. 🧼 Cleaning Up a Dead Function Parameter

There was this:

sanitize_error_message(error: str)

But… the parameter wasn’t even used properly 🤦‍♂️

So I:

Removed the useless parameter
Exported a clean constant:

OPAQUE_500_DETAIL

👉 Cleaner code, less confusion, fewer mistakes.

3. 📧 Fixing OTP Email Leak

This one was sneaky.

If OTP sending failed, the API returned:

detail=error_msg

Which could expose:

SMTP issues
Email service internals

After fix:

logger.error(...)
detail=security.OPAQUE_500_DETAIL

👉 Now:

Users see nothing sensitive
Devs still get full logs

4. 🕵️ Tamper Detection Logging (Finally Useful)

Before:

print(f"🚨 tamper detected: {tamper_exc}")

After:

logger.warning("[SECURITY] Possible tamper detected …")

👉 Why this matters:

Works with logging systems
Can trigger alerts
Actually usable in production

5. ⚠️ Logger Setup Order Fix

Yeah… this was subtle.

Before:

router = APIRouter()
logger = get_logger()

After:

logger = get_logger()
router = APIRouter()

👉 Prevents weird initialization issues and keeps things clean.

6. 🧯 Removing All `print()` From Security Logic

This was a big cleanup.

Replaced things like:

print("Wrong password")
print("File destroyed")
print("Brute force attempt")

With:

logger.warning(...)
logger.info(...)

👉 Why this matters:

print() = invisible in production
logger = structured, searchable, monitorable

✅ Verification (No Guesswork)

I didn’t just “hope it works” — I verified everything:

✅ No sanitize_error_message() calls left
✅ No detail=str(e) anywhere
✅ No security-related print() calls
✅ OTP leaks completely removed
✅ All files compile cleanly
✅ Logging is consistent across modules

🧠 What I Learned

Honestly, this round of fixes taught me something important:

Secure code isn’t about big features — it’s about small decisions done right.

Things like:

Not exposing errors
Logging properly
Keeping APIs predictable

These are the details that separate:
👉 a “working app”
from
👉 a production-ready system

🚀 Final Thoughts

This wasn’t a flashy update.

No UI changes.
No new features.

But under the hood?

👉 It made the app way more solid, safer, and professional

🔗 Check Out the Project

If you’re curious or want to explore the code:

👉 https://github.com/Mrtracker-new/BAR_RYY

💬 If You’re Building Something…

Take this as a reminder:

Don’t trust raw error messages
Never leave print() in security logic
Logging is your best friend
Small fixes = big impact

🔐 AES-256 Finally Makes Sense (And It’s Way Simpler Than You Think)

Rolan Lobo — Wed, 01 Apr 2026 17:11:12 +0000

Let’s be honest…

We’ve all heard this everywhere:

“Your data is secured with AES-256 encryption”

Cool… but what does that even mean?

I used to just nod like:
“Yeah yeah… sounds secure 😌”

But recently, I actually understood it — and trust me, it’s not as scary as it sounds.

So let me explain it to you in the simplest (and fun) way possible 👇

🧠 First, What is Encryption?

Encryption is basically:

👉 Turning your readable data into gibberish so no one else can understand it.

Example:


Hello → X7#pL@9!

Only someone with the correct key can turn it back into "Hello".

🔑 So What is AES?

AES stands for:

Advanced Encryption Standard

It’s one of the most secure encryption methods used today.

Used in:

Banking systems 💳
WhatsApp messages 💬
Wi-Fi passwords 📶
Even governments 🏛️

Yeah… it’s that serious.

💪 What Does “256” Mean?

AES comes in 3 types:

AES-128
AES-192
AES-256

👉 The number = key size (in bits)

So AES-256 = 256-bit key

Which basically means:

🔐 There are 2^256 possible keys

That number is insanely huge.

Like… even if you had the fastest computer in the world,
it would take billions of years to brute-force it.

🎯 Imagine This (Simple Analogy)

Think of AES-256 like this:

You have:

A super strong locker
A 256-digit password
And inside it → your data

Now imagine someone trying to guess that password…

Yeah… not happening anytime soon 😂

⚙️ How AES-256 Actually Works (Simple Version)

Okay, no boring math — just the idea:

Step 1: Data is split into blocks

Your data is divided into chunks (16 bytes each)

Step 2: Multiple rounds of scrambling (14 rounds!)

Each round does things like:

Mixing data
Shuffling bits
Substituting values

Basically:
👉 It completely scrambles your data again and again

Step 3: Secret key is applied

A 256-bit key is used in every round

This is what makes it secure 🔥

Step 4: Final Output

You get encrypted data like:


k9@Lm#2!zPq8...

Completely unreadable.

🔓 How Decryption Works

To get the original data back:

👉 You MUST have the same key

Then the process runs in reverse

And boom 💥


k9@Lm#2!zPq8... → Hello

🚫 Why Hackers Can’t Easily Break AES-256

Because:

Too many possible keys (2^256 🤯)
Too many transformation rounds
No shortcut to guess the correct key

Even supercomputers struggle.

💡 Where You See AES-256 in Real Life

You’re already using it daily:

🔐 HTTPS websites (the lock icon in browser)
💬 Messaging apps
💾 File encryption tools
☁️ Cloud storage

🧑‍💻 Why I Learned This

While working on my project InvisioVault (a file-hiding tool),
I realized:

👉 Hiding data is cool

👉 But securing it is next level

That’s when I explored AES-256.

✨ Final Thoughts

AES-256 sounds complicated…

But in reality, it’s just:

🔐 A super powerful way to scramble data using a secret key

If you’re a developer,
understanding this gives you a huge edge.

🚀 If You Made It This Far…

You officially understand AES-256 better than most beginners 💯

If this helped you, drop a like ❤️ or share it!

👋 Let’s Connect

I’m a beginner dev building cool stuff and learning every day.

More blogs coming soon 🚀

🧨 The Bugs That Almost Broke Sortify (And How I Crushed Them)

Rolan Lobo — Sun, 15 Feb 2026 15:03:43 +0000

Let me tell you something.

Apps don’t usually break because of complex algorithms.

They break because of:

A 0-byte file.
A random binary blob pretending to be text.
A filename like report:final*version?.docx
Or an undo operation that travels back in time… badly.

Sortify ran into all of these.
So I did what every developer eventually has to do:

I went into defensive programming mode.

This is the story of how I hardened Sortify’s invalid input handling — and made it way more stable in the process.

Check it out on GitHub:
🔗 Sortify — automatic file organizer

🗂️ 1. The “Empty File” Problem

You’d think an empty file wouldn’t be dangerous.

It’s literally nothing.

But that’s the problem.

No content → extraction logic behaves weirdly → AI categorization becomes unreliable.

So now we explicitly detect 0-byte files before doing anything:

if file_size_bytes == 0:
    logging.warning(f"Empty file detected (0 bytes): {file_path}")

What happens now?

✅ Empty files are detected instantly
✅ Logged properly
✅ Categorized using filename only
✅ No crashes
✅ No silent weirdness

Instead of “why did this behave strangely?”
Now it’s “Ah, it’s empty. Makes sense.”

Predictable > Magical.

💣 2. Binary Files Pretending to Be Text

This one was sneaky.

Some files looked harmless.

But internally?

Binary junk.

And when text extraction libraries try to read binary data…

You get:

Exceptions
Garbage output
Or mysterious failures

So I built a binary detector.

🧠 How It Works

We check:

First 8KB of the file
Presence of null bytes (\x00)
Ratio of non-printable characters

If more than 30% of characters are non-printable, we treat it as binary.

Why 30%?

Because real text files don’t look like corrupted alien transmissions.

If file is binary:

logging.info("Binary file detected, skipping content extraction")

And we:

✅ Skip text extraction
✅ Fall back to filename-based categorization
✅ Log everything
✅ Avoid crashes completely

Even if the file extension lies.

Doesn’t matter if it’s .txt, .md, or .conf.

Binary is binary.

No more surprise explosions.

😩 3. Windows Filename Rage

Previously, if someone tried to rename a file using invalid Windows characters…

They got a boring, unhelpful error.

Now?

We explain exactly what Windows hates:

Windows does not allow these characters in filenames:
  \ (backslash)  / (forward slash)  : (colon)
  * (asterisk)   ? (question mark)  " (quote)
  < (less than)  > (greater than)  | (pipe)

Plus a clear:

Please remove these characters and try again.

Simple change.

Massive UX improvement.

No more guessing what went wrong.

🕰️ 4. The Undo Operation That Could Have Been Dangerous

Undo is supposed to feel magical.

But under the hood, it’s risky.

What if:

The moved file was deleted?
The original location now has a new file?
Something changed between operations?

Previously, this could cause crashes or accidental overwrites.

Now?

We check everything.

Before undoing:

✅ Does the moved file still exist?
✅ Is the original location free?

If not?

We stop and clearly explain why:

Cannot undo: Original location is already occupied.
A file already exists at: ...
Please manually verify and move the file if needed.

No corruption.
No overwriting.
No chaos.

This one was a critical-level fix.

📊 Before vs After

Before

Empty files behaved weirdly
Binary files could crash extraction
Error messages were vague
Undo could break in edge cases

After

Empty files detected and logged
Binary files safely skipped
Clear, human-readable error messages
Undo operations protected and safe

It feels like the app matured overnight.

💡 What This Really Is

This wasn’t a “new feature” release.

This was a stability hardening phase.

The kind of work users never see.

But they feel it.

Because the app stops:

Crashing randomly
Acting unpredictably
Failing silently

Instead, it behaves like a professional desktop application.

🚀 Final Thought

The difference between a prototype and a production-ready app?

Not fancy AI.
Not cool UI.

It’s this:

Handling weird, messy, real-world input gracefully.

Users will always find edge cases.

Your job is to make sure they don’t break everything when they do.

Sortify is now much harder to break.

And honestly?

That feels better than shipping a new feature. 💙

Fixing a Frozen UI & a Sneaky Scheduler Crash — A Tale of Threads, Signals, and Defensive Code 🧵🔥

Rolan Lobo — Tue, 03 Feb 2026 14:43:07 +0000

If your app looks alive but feels dead… congratulations 🎉

You’ve probably blocked the main thread.

This post is a walkthrough of two real bugs I fixed recently:

A UI freeze caused by blocking file I/O on the main thread
A nasty crash where a scheduler ran before it was initialized

Both bugs were invisible during “small tests” and brutally obvious in real usage.

Let’s break down what went wrong, how I fixed it, and what I learned.

🧊 Problem #1: The UI Freeze from Hell

Symptoms

Clicking Organize Files froze the entire UI
Large file sets (50+ files) caused 5+ seconds of silence
No progress bar movement
Users thought the app had crashed (fair assumption)

Root Cause

I was doing exactly what every GUI app should never do:

Running file operations directly on the main GUI thread

Here’s the original code 😬

# Preview mode - BLOCKING code
temp_file_ops = FileOperations(dest_dir, "Organized Files", dry_run=True)
temp_file_ops.start_operations()

# 🚨 This loop blocks the UI
for file_path in self.selected_files:
    category_path = temp_file_ops.categorize_file(file_path)
    temp_file_ops.move_file(file_path, category_path)

temp_file_ops.finalize_operations()

That innocent-looking for loop?
Yeah… that was freezing everything.

✅ The Fix: Move Work Off the Main Thread

Instead of doing file I/O directly, I refactored preview mode to use the same background threading system already working for real file moves.

New Approach (Non-Blocking)

# Preview mode - NON-BLOCKING code
self.preview_file_ops = FileOperations(dest_dir, "Organized Files", dry_run=True)

self.processing_thread = ProcessingThread(
    self.selected_files,
    self.preview_file_ops
)

self.processing_thread.progress.connect(self.update_progress)
self.processing_thread.finished.connect(
    lambda: self._on_preview_finished(dest_dir)
)
self.processing_thread.error.connect(self.on_processing_error)

self.processing_thread.start()

Why This Works

File processing runs in a background thread
UI stays responsive
Progress bar updates in real time
Errors are handled safely via signals

✨ Chef’s kiss.

🪄 Showing the Preview After the Work Is Done

Instead of showing the preview dialog immediately, I added a new handler that fires only after the background thread finishes:

def _on_preview_finished(self, dest_dir):
    self.progress_bar.setVisible(False)

    if self.preview_file_ops.dry_run_manager.has_operations():
        dialog = PreviewDialog(
            self.preview_file_ops.dry_run_manager,
            self
        )

        if dialog.exec() == QDialog.DialogCode.Accepted:
            self._execute_organization(dest_dir)
        else:
            self.status_bar.showMessage("Preview cancelled")

Result:

No frozen UI
No half-ready preview
Clean, predictable flow

📊 Before vs After (Quick Visual)

❌ Before (Blocking)

Main Thread
 └── Loop over files
     └── UI freezes 😵

✅ After (Non-Blocking)

Main Thread        Background Thread
 ├── UI alive 🟢    └── File processing
 ├── Progress bar  └── Categorization
 └── Signals       └── Dry-run tracking

🧨 Problem #2: The Scheduler That Crashed on Startup

This one was sneakier.

The Crash

Sometimes the app would crash when:

Auto-sort was enabled before manual organization
Scheduled jobs ran on fresh app start
The app reopened with existing schedules

The Culprit

The scheduler was created like this:

self.scheduler = SortScheduler(None, self.categorizer)

That None?
Yeah… file_ops wasn’t initialized yet.

So when the scheduler tried to move files:

💥 NoneType crash

🛡️ The Fix: Lazy Initialization + Defensive Guards

Step 1: Don’t Initialize Too Early

# Delay scheduler creation
self.scheduler = None

Step 2: Centralize Setup with `_ensure_file_ops()`

if self.scheduler is None:
    self.scheduler = SortScheduler(self.file_ops, self.categorizer)
    self.scheduler.start()
else:
    self.scheduler.file_ops = self.file_ops

Now:

Scheduler only exists when file_ops exists
No duplicated setup logic
No race conditions

🧯 Step 3: Defense in Depth (Crash Prevention)

Even with good initialization, I added guards inside the scheduler and watcher:

if self.file_ops is None:
    logging.error("FileOperations not initialized")
    return False

This ensures:

No crashes
Errors are logged
App degrades gracefully instead of exploding

🎯 Final Results

Before

❌ Frozen UI
❌ No progress feedback
❌ Random crashes
❌ Users panic

After

✅ Fully responsive UI
✅ Smooth progress updates
✅ Safe background execution
✅ Stable scheduler & watcher
✅ App feels professional

🧪 Testing Still Matters

I manually tested:

Small file sets
Large file sets
Preview ON / OFF
Auto-sort before manual use
Scheduled jobs on restart

Everything behaved exactly as expected 🎉

🧠 Takeaways

Never block the GUI thread
Reuse proven threading patterns
Lazy initialization beats eager crashes
Defensive checks save your future self
If the UI freezes, users will assume the worst

If you’re building desktop apps with Python + Qt:
Threads + signals are not optional — they’re survival tools.

Happy coding 🧑‍💻🔥
And may your UI never freeze again.

I Eliminated SQLite Race Conditions in a Multi-Threaded Python App 🚀

Rolan Lobo — Sun, 01 Feb 2026 14:59:13 +0000

Random crashes. Database corruption. “database is locked” errors.

That’s how my app Sortify behaved when multiple threads hit SQLite at the same time.

This post is how I fixed it properly — and made the database production-ready.

🧠 The Problem: SQLite + Threads = Trouble

SQLite is lightweight and fast — but it has a big footgun:

❌ A single database connection shared across threads is NOT safe

In my app Sortify, multiple components were running concurrently:

Auto-sort watcher
Manual file operations
Scheduler tasks
Background processing threads

All of them were touching the same SQLite connection.

Symptoms I Saw

Random crashes
database is locked errors
Inconsistent history data
Risk of database corruption
App instability during concurrent operations

This line was the silent killer 👇

sqlite3.connect(db_path, check_same_thread=False)

It disables safety, but does not make SQLite thread-safe.

💥 Why This Happens

SQLite allows multiple connections, but each connection must stay in one thread.

Sharing:

❌ cursors
❌ connections
❌ transactions

across threads causes race conditions.

✅ The Solution: Thread-Local Database Manager

I implemented a proper thread-safe architecture using:

threading.local()
Per-thread SQLite connections
Automatic retry logic
Centralized DB access layer

🧩 Introducing `DatabaseManager`

A brand-new module:

core/database_manager.py

Key Design Idea

Each thread gets its own SQLite connection

self._local = threading.local()

Connections are:

Created on demand
Stored per thread
Automatically reused inside that thread

🔐 Enforced Safety

sqlite3.connect(
    db_path,
    timeout=10.0,
    check_same_thread=True  # ✅ SAFE
)

If a thread tries to use another thread’s connection → SQLite blocks it immediately.

That’s what we want.

⚙️ Features of `DatabaseManager`

✔ Thread-Local Connection Pooling

Each thread has its own isolated connection

✔ Automatic Retry on Locks

Handles SQLite’s infamous:

OperationalError: database is locked

with retry + backoff logic.

✔ Transaction Support

execute_transaction(operations)

Ensures atomic writes even under load.

✔ Clean Shutdown

close_all_connections()

No leaked file handles. No corrupted DBs.

🔁 Fixing Existing Code

❌ Before: Shared Connection

self.conn = sqlite3.connect(db_path, check_same_thread=False)
self.cursor = self.conn.cursor()

✅ After: Thread-Safe Manager

from .database_manager import DatabaseManager
self.db_manager = DatabaseManager(self.db_path)

Every database call now goes through one safe gateway.

🧼 Removing Direct Cursor Access

❌ UI Code Touching DB Directly

cursor = self.history_manager.conn.cursor()
cursor.execute("DELETE FROM history")

✅ Proper Encapsulation

self.history_manager.clear_operations()
self.history_manager.clear_history()

No more hidden race conditions.

🧪 Stress Testing the Fix

I didn’t trust this blindly — I stress tested it hard.

Test Setup

5 threads
50 DB operations each
250 total concurrent writes

Results

Total operations: 250
Successful: 250
Failed: 0
Database records: 250

🎉 Zero failures. Zero locks. Zero corruption.

🧠 Thread-Local Connections Verified

✓ Number of unique connections: 3
✓ Each thread has its own connection

Exactly as designed.

📈 Impact

Before ❌

Random crashes
Locked database errors
Unsafe concurrent writes
App unstable under load

After ✅

Fully thread-safe database access
Stable concurrent operations
No corruption risk
Production-ready SQLite usage

🗂️ Files Changed

File	Description
`core/database_manager.py`	New thread-safe DB layer
`core/history.py`	Migrated all queries
`ui/main_window.py`	Removed direct DB access
`tests/test_database_threading.py`	Stress test suite

🚀 Lessons Learned

SQLite is thread-friendly, not thread-safe
check_same_thread=False is a trap
One connection per thread is the correct model
Centralizing DB access prevents future bugs
Stress tests reveal bugs unit tests won’t

🔗 Source Code

📦 GitHub Repository:
👉 https://github.com/Mrtracker-new/Sortify

🏁 Final Thoughts

This wasn’t just a bug fix — it was a foundational stability upgrade.

If your Python app:

Uses SQLite
Has background threads
Randomly crashes under load

👉 This pattern will save you.

Happy coding! 🚀

Introducing QR Code Steganography: Because Normal QR Codes Are Too Mainstream

Rolan Lobo — Sun, 25 Jan 2026 14:28:27 +0000

The Problem Nobody Knew They Had

You know what's boring? Regular QR codes. You scan them, they take you to a website. Yawn. 😴

You know what's exciting? QR codes that look totally normal to everyone else, but secretly contain hidden messages that only you can read. Spy level: 100. 🕵️‍♂️

So I built exactly that into InvisioVault. Because why should images have all the steganography fun?

What Makes This Different?

Most QR code generators can add text. Cool. But that text is in the QR data itself - anyone with a scanner can see it.

InvisioVault's QR codes are double agents. They have:

📱 Public data - What normal scanners see (your URL, contact info, whatever)
🔐 Hidden secret - Only visible when scanned with InvisioVault

Scan it with your phone? Goes to your website.

Scan it with InvisioVault? Reveals your secret message.

Same QR code. Two completely different experiences. Magic? No. URL fragments? Yes.

How It Works (The Nerdy Bits)

When you generate a QR code with InvisioVault, we encode it like this:

https://yourwebsite.com/#IVDATA:encrypted_secret_goes_here

Here's the clever part:

Normal QR scanners read the URL and open your browser
Browsers ignore everything after the # (it's a URL fragment)
Your website loads perfectly - no weird data, no errors
InvisioVault reads the full QR data including the fragment
We decrypt and display your hidden message 🎉

It's like hiding a secret note inside a birthday card, except the birthday card is a QR code and the note is encrypted with AES-256. As one does.

The Journey: A Tale of Trial and Error

Attempt 1: Null Byte Separation

"Let's use \x00 to separate public and private data!"

Result: Some scanners URL-encoded it. URLs looked like website.com%00garbage. Fail. ❌

Attempt 2: LSB Image Steganography

"Hide the secret in the QR code pixels!"

Result: Camera captures recompress images. Pixel data destroyed. Hidden message? Gone. Double fail. ❌❌

Attempt 3: URL Fragments

"What if we just... use URL fragments?"

Result: IT ACTUALLY WORKS. ✅

Sometimes the simple solution is the right solution. Sometimes you just need to fail twice first.

Live Camera Scanning 📷

But wait, there's more! You can now scan QR codes directly with your webcam. No screenshots, no uploads, just point and scan.

The technical magic:

5-tier progressive camera fallback (works on 95%+ devices)
Dual-canvas processing:
- Original canvas: Preserves color for extraction
- Enhanced canvas: 2x upscaling + grayscale + 50% contrast boost
Adaptive scan intervals (500ms → 2000ms with exponential backoff)
MD5-based request caching (60-80% cache hit rate)

Translation: It works fast, on almost any device, and doesn't murder your server. Success! 🎊

Show Me The Goods! 📸

Generating a QR Code

Here's what it looks like when you create a secret QR code:

Just a normal-looking QR code generator... or is it? 😏

Scanning & Extracting the Secret

And here's what happens when you scan it with InvisioVault:

Public data? Check. Hidden secret message? Double check. Mission accomplished! ✨

Why This Is Actually Useful

"Okay cool, but when would I actually use this?"

Glad you asked! Here are some totally-not-made-up scenarios:

Business Cards 📇
- Public: Your LinkedIn profile
- Secret: Your actual phone number (for select people who scan it right)
Event Tickets 🎫
- Public: Event website
- Secret: VIP access code or exclusive content link
Product Packaging 📦
- Public: Product information
- Secret: Warranty details or customer support portal
Marketing Materials 📰
- Public: Standard landing page
- Secret: Special discount code for InvisioVault users
Just Because You Can 🎉
- Public: Rick Roll link
- Secret: Actual content you wanted to share
- (Okay this one might be real)

Performance Stats 📊

Because numbers make everything more credible:

Metric	Result
QR Detection Rate	80%+ in good lighting
Device Compatibility	95%+
Backend Load Reduction	60-80% (thanks to caching)
Normal Scanner Compatibility	100% (they just ignore the secret)
Times I Thought This Wouldn't Work	47
Times I Was Wrong	1 (this time it worked!)

The Code Journey

This feature went through more iterations than I'd like to admit:

- Attempt 1: Data encoding with null bytes
+ Attempt 2: LSB pixel steganography
+ Attempt 3: URL fragment encoding ✓

Shoutout to:

Segno for QR generation
Pyzbar for QR scanning
URL fragments for existing and being perfect for this
Coffee for existing

Try It Yourself!

Head over to InvisioVault and give it a spin!

Generate a QR code with a hidden message
Scan it with your phone - see the public data
Scan it with InvisioVault - see the secret
Feel like a spy
Repeat until you've hidden secrets everywhere

What's Next?

Some ideas I'm considering (read: may or may not implement):

🎨 More QR customization options (logos, colors, patterns)
📊 Analytics to see who scanned your QR codes
🔗 QR code chaining (scan one, get led to another, treasure hunt style!)
🎭 Multiple hidden messages in one QR (because why not?)

Final Thoughts

Building this feature taught me several things:

The simple solution is often hidden behind two complicated ones
URL fragments are more useful than you think
Camera APIs are surprisingly well-supported now
LSB steganography is fragile and I should stop trying to make it work for everything

If you made it this far, congrats! You're either really interested in steganography, procrastinating on actual work, or both. Either way, thanks for reading! 🎉

Now go forth and hide secrets in QR codes. The world is your oyster. Or QR code. Same thing.

Technical Details (For the Curious)

If you want to dive deep into how this works:

Encryption:

AES-256-CBC with PBKDF2 key derivation
100,000 iterations (industry standard)
Random 16-byte salt and IV for each generation

QR Format:

{public_data}#IVDATA:{base64_encrypted_secret}

Camera Processing:

MediaStream API for webcam access
Canvas API for frame capture and enhancement
Dual-canvas approach for quality preservation
Real-time QR detection with adaptive intervals

Performance Optimizations:

MD5 hashing for request deduplication
In-memory caching with 1-second TTL
Exponential backoff to reduce unnecessary processing
Progressive camera configuration fallback

Made with 💜 by Rolan

P.S. - If you find any bugs, they're not bugs, they're undocumented features. But please tell me anyway. 😅

Share Your Creations!

If you create something cool with this feature, tag me! I'd love to see what creative uses people come up with for hidden QR messages.

GitHub: @Mrtracker-new

Email: rolanlobo901@gmail.com

Happy hiding! 🎭✨

Stop Making Your Users Play 'Will It Fit?'

Rolan Lobo — Fri, 23 Jan 2026 16:43:07 +0000

Stop Making Your Users Play 'Will It Fit?'

The Problem

My steganography app lets users hide files inside images. Cool, right? Except users kept getting this:

❌ Error: Image doesn't have enough capacity.

After uploading everything. After waiting. After clicking the button.

So they'd try a bigger image. Upload again. Click. Fail. Repeat until rage-quit.

Not great for retention. 📉

The Solution

I added a real-time capacity calculator that shows users if their file will fit before they click anything.

It's just a React component that:

Calculates capacity when files are selected
Shows a color-coded progress bar
Tells users upfront: "✅ File will fit comfortably" or "❌ Too big buddy"

The Code (The Interesting Bits)

Backend - Calculate how much fits in an image:

@api.route('/calculate-capacity', methods=['POST'])
def calculate_capacity():
    img = Image.open(image_path).convert("RGB")
    total_pixels = len(list(img.getdata()))

    # LSB stego: 3 bits per pixel / 8 = bytes
    capacity = (total_pixels * 3) // 8

    return jsonify({'totalCapacityBytes': capacity})

Frontend - Debounce so we don't spam the API:

useEffect(() => {
    // Wait 500ms after user stops typing
    const timeout = setTimeout(() => {
        calculateCapacity()
    }, 500)

    return () => clearTimeout(timeout)
}, [image, file, text, password])

The Pretty Part - Color-coded status:

const getStatus = (percentage) => {
    if (percentage > 100) return { icon: '❌', message: 'Too large!' }
    if (percentage > 90)  return { icon: '⚠️', message: 'Barely fits' }
    if (percentage > 70)  return { icon: '⚡', message: 'High capacity' }
    return { icon: '✅', message: 'Fits comfortably' }
}

The Plot Twist

I deployed it. Users loved it. Then:

❌ Failed to calculate capacity

Turns out my 50 req/hour rate limit couldn't handle users actually using the feature. Whoops.

Fix: Bumped to 100 req/hour + added debouncing = happy users.

The Results

Zero "file too large" complaints (down from many)
Users understand capacity limits without reading docs
App feels way more professional
I learned about debouncing the hard way

Key Takeaways

1. Show, don't tell - Real-time feedback > documentation

2. Debounce everything - Users type fast. Your API can't keep up. Plan accordingly.

3. Polish matters - That shine animation on the progress bar? Totally unnecessary. Users love it anyway.

4. Watch your rate limits - Good features get used. A lot. Be ready.

Try It Yourself

The full code is on GitHub. Feel free to steal, improve, or roast my implementation.

Sometimes the best features aren't the flashy new capabilities - they're the tiny UX tweaks that make users go "oh thank god, finally."

What small feature transformed your app's UX? Drop it in the comments! 👇

Building steganography tools at 3 AM with too much coffee ☕

Follow: @Mrtracker-new

DEV Community: Rolan Lobo

I Built an AI Architectural Blueprint & Civil Feasibility Engine with $0 Paid APIs (Here's How)

⚡ The 3-Second Magic: What Happens on Click?

💸 The "Zero-Paid API" Stack: Surviving Without Google Maps

Calculating Slope from Space (For Free!)

🧠 Why Pure LLMs Can't Draw Blueprints (And How CSP Fixes It)

The 5 Non-Negotiable Architectural Invariants

1. The Leaf Rule ($\text{degree} = 1$)

2. The Peripheral Service Rule

3. The Central-Box Exclusion (Brahmasthan)

4. The Circulation Hub & Entry Axis

5. The Forbidden Adjacency Matrix

🏢 Multi-Storey Harmony: The "Rule of Cores" (G to G+3)

🧭 Vastu Shastra Meets Bioclimatic Optimization

🎨 The UI: Apple Vibrancy & Native SVG Rendering

🧪 Rigorous Testing: 236 Unit Tests & 9-Viewport Audits

🚀 Key Takeaways & Try It Yourself!

🌟 Explore the Code & Contribute

The Spy in the Barcode: Engineering Stealth QR Code Steganography published

The Core Challenge: Plausible Deniability

The Journey: Three Failures Before the Breakthrough

Attempt 1: Null-Byte String Delimitation (\x00)

Attempt 2: Direct LSB Pixel Modification

Attempt 3: The URL Fragment Scheme (#IVDATA:)

The Solution: Visual Module Steganography (Structural Isolation)

1. Structural Isolation Bitmask

2. Reed-Solomon Redundancy Parity Exploitation

The Cryptographic Pipeline

Real-Time WebRTC Camera Pipeline Under 512 MB Constraints

1. Dual-Canvas Client-Side Enhancement

2. Browser-First Decoding (jsQR)

3. SHA-256 Frame Deduplication Cache

Why Stream Mode is Kept as Read-Only

Takeaways

I Built a Privacy-First, Human-Friendly Alternative to Wireshark in Rust & Tauri 🚀

💥 The Problem: Raw Data vs. Actual Understanding

✨ Meet NetPulse: Understanding First, Deep Inspection One Click Away

1. 🪜 Progressive Disclosure (Beginner → Intermediate → Expert)

2. 🧠 Narrative Engine: Turning Packets into Stories

3. 🛡️ Calibrated Security & Anomaly Detection

4. 🎓 Built-in Education & The "Website Load Journey"

5. 🔒 Local-First & 100% Private

🛠️ The Architecture: How It's Built

The Tech Stack Highlights:

💡 Key Lessons Learned

🎯 What's Next?

💬 Over to You!

Building a Native Desktop Video Downloader with Rust and Tauri — What I Learned the Hard Way

Why Tauri Instead of Electron

The Stack

Problem 1: Making the App Work Without Any Prerequisites

Problem 2: Killing a Child Process on Windows Is Harder Than It Sounds

Problem 3: A Race Condition Hidden Inside the Pause Feature

Problem 4: --continue Causes ffmpeg to Hang at 99%

Problem 5: Keeping the UI and Backend in Sync

A Few Other Things Worth Mentioning

What This Taught Me

Try It

I Built a Chat App That Deletes Itself (Because I Was Bored at 2am)

What I Was Actually Going For

The Architecture (Or: What I Drew on a Napkin)

Part 1: The Backend — Python, FastAPI, and Some Questionable Choices

I Used a Dictionary to Store Sessions

Each Session Gets a Timer

Burning the Session

Part 2: The Crypto — The Part That Made My Brain Hurt

Key Generation

The Key Exchange

Encrypting Messages

The Session Fingerprint

Part 3: The Frontend — React, Fire, and a State Machine

Three Phases, One Component

The Burn Animation

Creator Controls

The Mistakes (a.k.a. The Educational Section)

Mistake 1: I Reused the IV

Mistake 2: I Forgot About Late Joiners

Mistake 3: I Decremented the Timer Instead of Using the Wall Clock

What Actually Happens When It Burns

The Honest Security Section

Attempt 1: Null-Byte String Delimitation (`\x00`)

Attempt 3: The URL Fragment Scheme (`#IVDATA:`)

2. Browser-First Decoding (`jsQR`)

Problem 4: `--continue` Causes ffmpeg to Hang at 99%

6. 🧯 Removing All `print()` From Security Logic

Step 2: Centralize Setup with `_ensure_file_ops()`