DEV Community: Rolan Lobo

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

Stop Lying to Your Users With Spinning Circles

Rolan Lobo — Thu, 22 Jan 2026 16:28:32 +0000

I Gave My Loading Screens a Glow-Up (And You Can Too!) 💅

You know that awkward moment when your app is loading and all your users see is a lonely spinning circle? Yeah, me too. So I decided to do something about it.

The Problem: Spinners Are Liars 🤥

Picture this: You're building a file encryption app (yes, that's what I do for fun), and your backend is sleeping on Render's free tier. When someone tries to access a file, they click the button and... nothing. Just a spinner. For 15 seconds.

No feedback. No progress. Just vibes. ✨

Users are left wondering:

Is it working?
Did I break it?
Should I refresh?
Is it time to panic yet?

Spoiler: They always panic.

The Solution: Multi-Stage Loading Indicators 🎯

Instead of a basic spinner that screams "I'm working, trust me bro," I built a loading component that actually communicates with users. Here's what it does:

🔵 Stage 1: Connecting

"Waking up server..." (because yes, it's literally waking up from a nap)

🟣 Stage 2: Authenticating

"Authenticating request..." (fancy words for checking if you're allowed in)

🟡 Stage 3: Decrypting

"Decrypting file..." (the actual magic happens here)

🟢 Stage 4: Rendering

"Rendering preview..." (almost there!)

Each stage gets its own:

Icon (Server → Shield → Lock → Eye)
Color (Blue → Purple → Amber → Green)
Progress percentage (0% → 25% → 50% → 75% → 100%)
Smooth animations (because we're fancy like that)

The Code: Let's Get Spicy 🌶️

I created a reusable LoadingStages component that takes the current stage and progress as props:

<LoadingStages
  currentStage="connecting"
  progress={25}
  estimatedTime={15}
/>

The component cycles through stages automatically based on your app's actual loading process. No fake progress bars here! (We're honest people.)

Cold Start Detection 🥶

The best part? It detects when the server is cold-starting and shows an estimated time:

const responseTime = (Date.now() - startTime) / 1000;
if (responseTime > 3) {
  setEstimatedTime(15); // "~15s" appears on screen
}

This way, users know they're in for a wait and can grab their coffee ☕

The Results: Happy Users 😊

Instead of anxious button-mashing, users now:

See exactly what's happening at each stage
Know how long it'll take during cold starts
Feel confident the app is working
Don't spam refresh (my server thanks them)

Plus, it looks gorgeous. The glassmorphic design with color transitions makes loading actually pleasant to watch.

Want to Try It? 🚀

Check out the full implementation in my repo:
BAR_RYY

The magic lives in:

frontend/src/components/LoadingStages.jsx (the star of the show)
frontend/src/components/SharePage.jsx (where it's integrated)

Key Takeaways 💡

Loading screens are prime real estate - Use them to communicate!
Users tolerate waits better when they know what's happening
Cold start detection turns frustration into understanding
Pretty animations make everything better (scientific fact)

Final Thoughts 🎨

We spend so much time optimizing for speed, but sometimes the wait is unavoidable (looking at me, free tier cold starts). When you can't eliminate the wait, make it informative and beautiful.

Your users will appreciate knowing that yes, the app is working, and no, they don't need to panic.

Now if you'll excuse me, I'm off to give all my loading screens glow-ups. This is addicting. 💅✨

What's the most creative loading indicator you've seen? Drop it in the comments! 👇

P.S. - If you're building anything with file encryption, 2FA, or self-destructing links, definitely check out the repo. It's got some cool security features too!

How I Stopped Worrying and Learned to Love Organization

Rolan Lobo — Wed, 21 Jan 2026 15:57:03 +0000

The Before Times (aka The Dark Ages)

Picture this: You open your backend folder. It's like walking into a teenager's room. Files everywhere. No rhyme. No reason. Just pure, unadulterated chaos.

database.py living next to upload.py, hanging out with security.py, while cleanup.py just vibes in the corner. Everyone's at the same level, nobody has their own space, and finding anything requires either:

A prayer 🙏
Ctrl+P like your life depends on it
Or acceptance that you'll spend 10 minutes scrolling

Sound familiar? Yeah, I thought so.

The Intervention

One day, I looked at my backend folder and had an epiphany. Or maybe it was just caffeine-induced clarity. Either way, I realized something profound:

My files were adults. They deserved their own rooms.

So I did what any responsible developer would do: I created folders. ACTUAL. FOLDERS.

backend/
├── core/           # The VIPs
├── services/       # The workers
├── storage/        # The file hoarders
└── utils/          # The helpful folks

Revolutionary? No. Overdue? Absolutely.

The Great Migration (aka Moving Day)

Moving files is like playing Tetris, but with imports. You move one file and suddenly 47 things break. It's beautiful.

Step 1: Create folders

✅ Easy mode

Step 2: Move files into folders

✅ Still easy

Step 3: Update all the imports

⚠️ BOSS BATTLE INITIATED

# Before
from database import Database

# After
from core.database import Database

# My brain
from please.work.i.beg.you import Sanity

I spent quality time with find-and-replace. We bonded. We grew together. I may have shed a tear when all the imports finally worked.

What Actually Changed

Here's what I inflicted upon my codebase:

🎯 core/ - The Foundation

database.py - Because databases are core, obviously
config.py - All the environment variables in one place
auth.py - Security matters, folks

⚙️ services/ - The Doers

upload_service.py - Handles uploads
share_service.py - Handles sharing
cleanup_service.py - Cleans up after everyone else (the real MVP)

💾 storage/ - The Packrats

file_manager.py - Manages files (shocking, I know)
storage_handler.py - Stores things

🛠️ utils/ - The Helpers

security.py - Security utilities
validators.py - Validates stuff
helpers.py - Helps with... stuff

The Fallout

The Good:

Finding files is now actually possible
New team members don't look at me with fear and confusion
I can pretend I know what I'm doing
Separation of concerns is no longer just a buzzword I throw around

The Bad:

My muscle memory is completely wrecked
I still type old import paths
Had to update the mental map in my brain

The Ugly:

That one time I forgot to update an import and the server crashed in production
Just kidding! (Or am I? 😅)

Lessons Learned

Start with folders. Don't be like me. Don't wait until you have 30 files in the root directory.
Your IDE's refactoring tools are your friends. Use them. Love them. They'll save you from import hell.
Test after moving EVERYTHING. I mean it. Test it all. Then test it again.
It's never too late to organize. Even if your codebase is a disaster, you can fix it. I believe in you.
Document the structure. Future you will thank present you. Past you is already disappointed, but that's okay.

The Commit Message That Started It All

refactor: finally convinced my files to use folders like adults

- Created proper folder structure (core, services, storage, utils)
- Moved files from root to appropriate directories
- Updated all import statements
- Celebrated with coffee

Final Thoughts

Is my backend perfect now? No.

Is it better? Absolutely.

Did I learn something? Maybe.

Will I do this again? Already planning the frontend refactor.

Remember folks: Organization is not about being perfect. It's about being less chaotic than you were yesterday.

And if you're sitting there with a messy backend folder, take this as your sign. Your files deserve their own rooms too.

Now go forth and mkdir! 🚀

Have you ever done a massive refactor? Share your horror stories in the comments! I promise mine was worse. Probably.

Why Let Users Choose Between Being Nice and Being Paranoid? 🔄

Rolan Lobo — Tue, 20 Jan 2026 18:17:41 +0000

The Problem: My App Had Commitment Issues 💔

So I built this file-sharing web-app called BAR Web that lets you send files that self-destruct after being viewed (think Mission Impossible but for PDFs). Cool, right?

But here's where things got weird: I added two features to control how page refreshes work:

View Refresh Threshold - "Hey, if the same person refreshes within 5 minutes, don't count it as a new view"
Auto-Refresh Interval - "Force the page to reload every 30 seconds so the file disappears"

And like a fool, I let users enable both at the same time. 🤦‍♂️

What Could Go Wrong?

Imagine this conversation:

User: "I want to be nice! Let people refresh without wasting views!"

Also User: "But also force them to reload every 30 seconds!"

Me: "...that's like wearing a belt AND suspenders, my friend."

It made zero sense. If you're auto-reloading the page, why care about refresh thresholds? If you're being forgiving with refreshes, why force reloads?

It was like trying to be both chill and paranoid at the same time. Pick a lane, buddy!

The Solution: Couples Therapy for UI Elements 💑

I made them mutually exclusive using radio buttons. Now users have to choose ONE:

Option 1: View Refresh Threshold (The Nice One)

"I trust you not to spam refresh. Take your time!"

Perfect for:

Recipients who might have slow internet 📶
People who need to scroll through long documents
When you're feeling generous

Options:

0 minutes (every refresh counts - default)
5 minutes (recommended)
Up to 1 hour (very forgiving)

Example:

User refreshes 3 times in 4 minutes → Still counts as 1 view 🎯

Option 2: Auto-Refresh Interval (The Paranoid One)

"You have 30 seconds. Make them count. ⏱️"

Perfect for:

Super sensitive stuff
Time-limited access codes
Maximum security theater

Options:

10 seconds (ruthless)
30 seconds (recommended)
Up to 5 minutes (generous for paranoia mode)

Example:

User opens file → Has 30 seconds to read → Page reloads → File might be gone 💨

The Implementation (For the Nerds) 🤓

Frontend Magic

I used radio buttons styled like cards (same pattern as my storage mode selector):

// When "View Refresh Threshold" is selected
onChange={() => onRulesChange({
  ...rules,
  viewRefreshMinutes: 5,        // Enable this one
  autoRefreshSeconds: 0          // Disable the other
})}

// When "Auto-Refresh Interval" is selected  
onChange={() => onRulesChange({
  ...rules,
  viewRefreshMinutes: 0,         // Disable this one
  autoRefreshSeconds: 30         // Enable the other
})}

Then I show the dropdown settings only for the selected option. One choice, one settings panel. Clean and simple.

Backend Wisdom

The backend was already handling both features separately. I just had to make sure only one value is non-zero at a time:

# In the database
view_refresh_minutes: int = 0
auto_refresh_seconds: int = 0

# Only one should be > 0

The fingerprinting logic checks if enough time has passed, and the auto-refresh header tells the browser when to reload. Easy peasy.

Lessons Learned 🎓

Don't give users contradictory choices - It's our job to prevent foot-shooting
UI should reflect reality - If two options fight each other, make them exclusive
Good UX is about constraints - Sometimes the best feature is the one you don't include
Radio buttons > Checkboxes for mutually exclusive stuff (duh)

The Result 🎉

Now my app has a clear UI that says:

"Pick your personality: Nice or Paranoid. You can't be both, Karen."

Users love it. No more confusion. No more contradictory settings. Just clean, simple choices.

Try It Yourself!

The feature is live at bar-rnr.vercel.app

And if you want to see the code or contribute:

👉 GitHub: BAR_RYY

Fun fact: I committed this in 4 separate commits with increasingly silly commit messages. Because if you're not having fun while coding, what's the point? 😄

The last commit was literally:

"Docs got the memo! 📝 README and FEATURES.md now explain the new Smart Refresh Control with examples, emojis, and a healthy reminder that you can't enable both options because that'd be like wearing a belt AND suspenders 👖"

Have you ever built conflicting features into your app? Share your "oops" moments in the comments! 👇

How I Accidentally Became a Performance Guru

Rolan Lobo — Sun, 18 Jan 2026 15:51:58 +0000

The Classic Beginner Move: Doing Everything Backwards

You know that feeling when you're building your portfolio as a beginner and you suddenly think:

“THIS is going to be legendary.”

Yeah. That was me.

I planned everything with extreme seriousness:

✅ Cool animations
✅ Smooth transitions
✅ Project showcase
✅ Fancy tech stack badges
✅ Blog section
❌ Resume… eventually?

Here’s the thing about being a beginner:

You overthink the simple stuff

and underthink the important stuff.

I spent days perfecting my hero section animation.

But adding my actual resume to my portfolio?

“Eh… I’ll do it later.”

So naturally, I added my resume dead last.

You know —

the ONE thing employers might actually want to see.

By the time I got to it, I had already:

implemented three color themes
refactored my components twice
memorized half of the React docs
emotionally bonded with my CSS

Classic beginner behavior. 🤦‍♂️

The React-PDF Rabbit Hole 🕳️🐇

When I finally decided to add my resume, I told myself:

“I’m a developer now.

I must do this the developer way.”

So I did what any self-respecting beginner does:

🔍 Googled: “How to add PDF to React website”

And there it was.

✨ react-pdf ✨

A whole library just for PDFs?

Perfect.

Libraries = Professional.

More code = Smarter developer.

Right?

import { Document, Page } from 'react-pdf';

// Look at me using a library 😎
<Document file="/Rolan_Resume.pdf">
  <Page pageNumber={1} />
</Document>

I felt unstoppable.

Installed dependencies
Configured webpack
read 15 Stack Overflow answers
Fought canvas rendering errors
Questioned my life choices

This was REAL development, right?

The Wake-Up Call 😱

Then I ran Lighthouse.

Performance: 67

💀💀💀

My beautifully crafted portfolio — the one I spent weeks polishing — was being absolutely murdered by a PDF renderer.

Mobile users were probably aging in real time
Resume loading slower than my motivation on Mondays
And for WHAT?

The PDF:

wasn’t interactive
didn’t zoom properly
took forever to load

I had officially used a sledgehammer to hang a photo frame.

The “Duh” Moment: WebP to the Rescue 🧠✨

One day, while optimizing my project images (you know… the things I optimized before my resume 🙃), I converted everything to WebP.

File sizes dropped like my hopes during a failed npm install.

And suddenly…

💡 It hit me.

“Wait…
Why am I rendering a PDF…
when I could just show an image?”

🤯🤯🤯

Groundbreaking thinking, I know.
Someone call the Nobel committee.

So I did the most un-developer thing possible:

Opened my resume PDF
Exported it as a high-quality image
Converted it to WebP
Deleted react-pdf like it owed me money

Replaced all of this complexity with:

<img 
  src="/resume-preview.webp" 
  alt="Resume Preview"
  loading="lazy"
/>

That’s it.

No library.
No config.
No pain.
Just ✨ a native <img> tag no libraries involved ✨.

The Results Were… Embarrassingly Good 😐

Before (react-pdf)

📦 Bundle size: +500KB
⏱️ Load time (3G): 3.2s
🎨 Lighthouse score: 67
😤 Stress level: High

After (WebP)

📦 File size: ~45KB
⏱️ Load time (3G): 0.3s
🎨 Lighthouse score: 95
😎 Stress level: Chill

I accidentally made my site 10x faster by doing the simplest thing possible.

What This Taught Me (Besides Humility)

1️⃣ Not Everything Needs a Library

Just because a library exists doesn’t mean you need it.

Sometimes the browser already does the job perfectly fine.

Using a library for this felt like buying a smart electric can opener…
when you have hands.

2️⃣ WebP Is a Game Changer

If you’re not using WebP yet… why? 😭

25–35% smaller than PNG/JPEG
Better quality at lower sizes
Supported by all modern browsers (sorry IE11, this party isn’t for you)

WebP is basically a free performance upgrade.

3️⃣ The Beginner Advantage 🧠

As a beginner, I wasn’t emotionally attached to “the right way”.

When something didn’t work well, I didn’t defend it.

I just went:

“This sucks.”
Delete.
Try something simpler.

That mindset saved my performance.

4️⃣ Performance > Complexity

No recruiter will ever say:

“Wow… you used react-pdf.”

But they will notice when your site loads faster than their coffee machine.

Users don’t see your code.
They feel your performance.

The Irony of It All 🎭

I thought being a “real developer” meant:

more libraries
more configs
more complexity

But the biggest improvement to my portfolio came from:

Converting a file
and using an <img> tag.

Sometimes the best code
is the code you don’t write.

How You Can Do This Too (Dead Simple)

Export your resume as a high-quality image
Convert it to WebP
Use this:

<img src="resume-preview.webp" alt="Resume" loading="lazy" />

Still offer the PDF download:

<a href="/resume.pdf" download>Download PDF</a>

Done. 🎉

You’ve now avoided:

PDF.js headaches
Webpack nightmares
“canvas is not defined” errors
Performance crimes

Final Thoughts

Building a portfolio as a beginner is basically:

doing things backwards
learning the hard way
accidentally discovering best practices

I added my resume last.
I over-engineered a simple problem.
But I learned something valuable:

Simple beats fancy.
Fast beats clever.
Users beat libraries.

If my Lighthouse score went from 67 → 95 just by using WebP…

Imagine what yours could be.

Now if you’ll excuse me, I need to refactor something that’s working perfectly fine —
you know, as developers do. 😅

TL;DR
Tried to be fancy with react-pdf, murdered performance.
Switched to WebP image preview, became accidentally fast.
WebP is magic. Simple is better.

Got similar over-engineering stories?
Drop them in the comments — let’s laugh at our beginner mistakes together 👇

P.S. Yes, my resume is still downloadable as a PDF.
I’m not a monster. But the preview?
That’s pure WebP goodness. 😌

This message will self-destruct in 5 seconds...

Rolan Lobo — Tue, 16 Dec 2025 17:44:01 +0000

You know that scene in Mission Impossible where Ethan Hunt gets his briefing and then—poof—the tape/phone/hologram bursts into flames?

Yeah, I wanted that. But for files. On the internet. Without the fire hazard. 🔥

So, I built BAR-Web (Burn After Reading) - a file-sharing app where your secrets actually stay secret and then disappear forever. No "oops, I can recover that from the recycle bin." No "let me just use this recovery tool." Just... gone.

The Origin Story (aka "Why Did I Do This?")

It started with a simple problem: I needed to share a password with someone. Email? Nah, that stays in their inbox forever. WhatsApp? Now it's on their cloud backup. Signal? Better, but still... what if they screenshot it?

I wanted something that would:

✅ Self-destruct after being read
✅ Have ACTUAL security (not just vibes)
✅ Give ME control over who sees what, and when
✅ Make me feel like a secret agent

Spoiler: No good free options existed. So I made one. Twice. (First a desktop exe, then this web version because I got addicted to the idea.)

What Does It Actually Do?

Think Snapchat for files, but with actual teeth and bank-level encryption.

Here's the deal:

📤 Upload Anything

PDFs, images, videos, your secret cookie recipe—up to 100MB. No judgment.

🔒 Fort Knox Encryption

AES-256 encryption (the same stuff governments use to protect classified docs). Your files are turned into digital gibberish that would take a supercomputer billions of years to crack. No pressure.

🔑 Zero-Knowledge Security

Here's the cool part: Even I can't read your files. When you password-protect something, the encryption key is derived from your password and NEVER stored anywhere. No password? No file. It's that simple.

(This is the same tech 1Password, Bitwarden, and Signal use. If it's good enough for Edward Snowden, it's good enough for us.)

⏱️ Time Bombs

Set files to expire in:

5 minutes (for the truly paranoid)
24 hours (for the casually paranoid)
Or custom times (for the "I know what I'm doing" folks)

👁️ View Limits

"This file will self-destruct after 1 view."
Or 5 views. Or 100. Your call. Once the limit hits? POOF. File deletes itself. No takebacks.

🚀 Two Ways to Share

Option 1: Download a .bar File
Send someone an encrypted file they can decrypt later. Good for offline sharing or when you don't trust servers (fair).

Option 2: Magic Link
Share a link. We host the encrypted file and enforce the rules. Once it hits the view limit or expires? It's gone forever. We even overwrite it 3 times with random data to make sure nobody's recovering it.

🔔 Webhook Alerts (The Fun Part)

Want to know when someone tries to access your file? Set up a webhook! Get a Discord or Slack notification when:

Someone views your file
Someone enters the wrong password
Someone hits the view limit

I don't know about you, but getting a ping that says "⚠️ Wrong password attempt #3" is oddly satisfying.

🛡️ Brute-Force Protection

Try to guess the password? Cute. Here's what happens:

Wrong password = delays (1s, 2s, 4s, 8s...)
5 wrong attempts? Locked out for 60 minutes.
Try to cheat by re-uploading? Nope. We track that.

Hackers hate this one simple trick. (It's called "making them give up.")

The Tech Stack (For My Fellow Nerds 🤓)

Backend:

FastAPI (because Python is still king for APIs)
Cryptography library (the heavy lifter)
PBKDF2 for key derivation (100,000 iterations, because we're not amateurs)
HMAC-SHA256 for tamper detection

Frontend:

React 18 + Vite (blazing fast dev experience)
Tailwind CSS (looking good without the pain)
Lucide React icons (because they're clean AF)

Hosting:

Frontend on Vercel (because it just works)
Backend on Render Free Tier (warning: it takes 50 seconds to wake up from hibernation, so be patient!)

The Desktop Version (Plot Twist!)

Before I built the web version, I made a Windows desktop app (exe) that's honestly even MORE paranoid. Same core security, but with some extra spicy features:

🚨 Desktop-Only Features:

Panic Button: Someone walking up behind you? Hit the button. Your files? Gone in seconds. Three destruction levels:
- Selective: Just clear session data
- Aggressive: Nuke 98%+ of BAR data
- Scorched Earth: Maximum destruction + anti-forensics (nuclear option)
Deadman Switch: Don't log in for a week? Files auto-delete themselves. Spooky but useful.
Hardware Binding: Lock files to your specific PC. Try to copy them elsewhere? They won't decrypt.
100% Offline: No internet. No cloud. Your files NEVER leave your machine.
Security Levels: Choose your paranoia level:
- Standard: 5 wrong passwords = temp lockout
- High: 4 wrong passwords = 24hr lockouts
- Maximum: 3 wrong passwords = EVERYTHING DELETED ☠️

Why did I make a web version then? Because:

Not everyone wants a desktop app
Sharing links is easier than sending .bar files
I wanted to prove the same security works in a browser
I wanted to flex my full-stack muscles 💪

Both versions use the same encryption standards (AES-256-GCM), so pick your poison!

Try It Yourself!

🌐 Live Demo: https://bar-rnr.vercel.app/

Fair warning: The backend is on a free tier that hibernates when not in use. If it's slow to load, give it ~50 seconds to wake up, stretch, and grab some coffee. After that? Lightning fast. ⚡

Want to self-host? The code is on GitHub:
🔗 Web Version: github.com/Mrtracker-new/BAR_RYY

Want the desktop app instead?
🔗 Desktop Version (v2.0.0): github.com/Mrtracker-new/BAR

The desktop version has the panic button and deadman switch—perfect for the truly paranoid! 😈

Things I Learned (The Hard Way)

Encryption is HARD. Like, "I rewrote this 5 times" hard. Don't roll your own crypto. Use battle-tested libraries.
UX matters for security tools. If your security tool is annoying to use, people won't use it. Then they'll go back to emailing passwords in plaintext. 😭
Free hosting has trade-offs. The 50-second wake-up time on Render? Yeah, that's the price of free. Still worth it though!
People LOVE the webhook notifications. I thought it was a silly feature. Turns out everyone wants to know when their file gets accessed. It's like having a security camera for your data.
"Zero-knowledge" is a great pitch. Telling users "I literally CAN'T read your files" is way more reassuring than "I promise I won't read your files."

What's Next?

Some ideas I'm toying with:

Mobile app (because why not go full circle?)
Browser extension (right-click → "Share securely")
Email integration (auto-generate BAR links in Gmail)
Expiring messages (not just files, but text too)

But honestly? I built this mostly because I thought it was cool. If even one person uses it to send a password securely instead of over Slack, I'll call it a win. 🎉

The Real Talk Section

Is this production-ready? For personal use? Absolutely. For enterprise secrets? Maybe test it first. 😅

Can you read my files? Nope! Zero-knowledge means zero-knowledge. I don't have your password, so I can't decrypt anything.

What if the server goes down? If you used client-side mode (downloaded the .bar file), you're fine—it's on your machine. If you used server-side (link sharing), well... RIP. Back up important stuff.

Is this actually secure? I'm not a cryptographer, but I used industry-standard algorithms (AES-256, PBKDF2, HMAC-SHA256) implemented by people way smarter than me. The code is open source, so feel free to audit it!

Try It, Break It, Tell Me About It

Seriously, go play with it: bar-rnr.vercel.app

Upload a file, set it to self-destruct, feel like James Bond for 30 seconds. If you find bugs (or ways to break it), open an issue on GitHub. I accept PRs, feature requests, and memes.

And if you're thinking "this is over-engineered for sharing cat pictures"—you're absolutely right. But wouldn't you rather share those cat pictures with military-grade encryption? 😺🔐

Made with ☕, 💻, and a healthy dose of paranoia.

P.S. - Want the desktop version with the panic button? Check out github.com/Mrtracker-new/BAR for the 100% offline, extra-paranoid version! 🚨

DEV Community: Rolan Lobo

Your Backend Is Leaking Secrets (Mine Was Too)

🚨 The Problem

🛠️ What I Fixed (The Real Stuff)

1. 💀 Killing Error Leaks (Big One)

2. 🧼 Cleaning Up a Dead Function Parameter

3. 📧 Fixing OTP Email Leak

4. 🕵️ Tamper Detection Logging (Finally Useful)

5. ⚠️ Logger Setup Order Fix

6. 🧯 Removing All print() From Security Logic

✅ Verification (No Guesswork)

🧠 What I Learned

🚀 Final Thoughts

🔗 Check Out the Project

💬 If You’re Building Something…

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

🧠 First, What is Encryption?

🔑 So What is AES?

💪 What Does “256” Mean?

🎯 Imagine This (Simple Analogy)

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

Step 1: Data is split into blocks

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

Step 3: Secret key is applied

Step 4: Final Output

🔓 How Decryption Works

🚫 Why Hackers Can’t Easily Break AES-256

💡 Where You See AES-256 in Real Life

🧑‍💻 Why I Learned This

✨ Final Thoughts

🚀 If You Made It This Far…

👋 Let’s Connect

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

🗂️ 1. The “Empty File” Problem

What happens now?

💣 2. Binary Files Pretending to Be Text

🧠 How It Works

If file is binary:

😩 3. Windows Filename Rage

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

📊 Before vs After

Before

After

💡 What This Really Is

🚀 Final Thought

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

🧊 Problem #1: The UI Freeze from Hell

Symptoms

Root Cause

✅ The Fix: Move Work Off the Main Thread

New Approach (Non-Blocking)

Why This Works

🪄 Showing the Preview After the Work Is Done

📊 Before vs After (Quick Visual)

❌ Before (Blocking)

✅ After (Non-Blocking)

🧨 Problem #2: The Scheduler That Crashed on Startup

The Crash

The Culprit

🛡️ The Fix: Lazy Initialization + Defensive Guards

Step 1: Don’t Initialize Too Early

Step 2: Centralize Setup with _ensure_file_ops()

🧯 Step 3: Defense in Depth (Crash Prevention)

🎯 Final Results

Before

After

🧪 Testing Still Matters

🧠 Takeaways

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

🧠 The Problem: SQLite + Threads = Trouble

Symptoms I Saw

💥 Why This Happens

✅ The Solution: Thread-Local Database Manager

🧩 Introducing DatabaseManager

Key Design Idea

🔐 Enforced Safety

⚙️ Features of DatabaseManager

✔ Thread-Local Connection Pooling

✔ Automatic Retry on Locks

✔ Transaction Support

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

Step 2: Centralize Setup with `_ensure_file_ops()`

🧩 Introducing `DatabaseManager`

⚙️ Features of `DatabaseManager`