DEV Community: Altug Tatlisu

Why I Chose Rust Over Python for My AI Research Agent (3-Week Build)

Altug Tatlisu — Sun, 22 Mar 2026 19:58:18 +0000

The Problem: Reading Research Papers is Soul-Crushing

Picture this: You're deep in blockchain research. You need to understand consensus mechanisms. So you:

Search arXiv for "blockchain consensus"
Get 847 results
Download 50 PDFs
Realize you need to read all of them
Cry

Then it hit me: What if an AI could do this entire workflow autonomously?

Not just "summarize papers" like ChatGPT. I mean:

Search academic databases
Download papers automatically
Parse PDFs and extract knowledge
Build a searchable knowledge base
Generate hypotheses for novel protocols
Run simulations to test ideas
Write research papers with proper citations

All by itself. While I sleep.

That's ConsensusMind.

The Controversial Decision: Pure Rust (No Python)

Everyone builds AI tools in Python. Everyone.

I chose Rust.

"Are you insane?"

That's what I thought too. But here's the thing:

Python is slow:

# Python: PDF parsing
start = time.time()
text = extract_text("paper.pdf")
print(f"Took {time.time() - start}s")
# Output: Took 0.5s

Rust is fast:

// Rust: Same PDF
let start = Instant::now();
let text = parser.extract_text(&pdf_path)?;
println!("Took {:?}", start.elapsed());
// Output: Took 100ms

5x faster. And that's just parsing ONE paper.

When you're processing thousands of papers, this compounds.

"But Python has better AI libraries!"

True. But I don't need them.

LLM? Self-hosted vLLM via REST API (language-agnostic)
Vector search? SQLite with vec0 extension (pure Rust)
PDF parsing? pdf-extract crate (pure Rust)
Everything else? Rust ecosystem has it

The real kicker: Rust gives me a single binary deployment.

# Python deployment
pip install -r requirements.txt
# Result: 50 packages, version conflicts, pray it works

# Rust deployment  
./consensusmind
# Result: One file. Just works.

Week 1: Foundation (Avoiding Analysis Paralysis)

Day 1 was rough. I had two choices:

Spend weeks designing the perfect architecture
Ship something that works, iterate fast

I chose option 2.

The Minimum Viable Foundation

// Day 1: Just make it compile
pub struct ConsensusMind {
    config: Config,
    logger: Logger,
    llm_client: LlmClient,
}

impl ConsensusMind {
    pub fn new() -> Result {
        // Load config, setup logging, that's it
        Ok(Self { /* ... */ })
    }
}

Quality rule from day 1: Zero compiler warnings.

Not "we'll fix it later." Not "technical debt is fine for MVP."

Zero. Warnings.

This decision saved me later.

Week 2: The arXiv Integration (When APIs Fight Back)

The Challenge

Build a client that:

Searches arXiv for papers
Downloads PDFs
Doesn't get rate-limited
Doesn't crash
Actually works

The Reality

// First attempt - DON'T DO THIS
pub async fn search(&self, query: &str) -> Result<Vec> {
    let response = self.client.get(&url).send().await?;
    // ... parse XML ...
    // Works! Ship it!
}

What happened: Got rate-limited after 10 requests. arXiv blocked me.

The Fix

// What actually works
pub async fn search(&self, query: &str) -> Result<Vec> {
    let response = self.client.get(&url).send().await?;
    let papers = self.parse_response(&response)?;

    // The magic: respect rate limits
    sleep(Duration::from_secs(3)).await;

    Ok(papers)
}

Lesson learned: Read the API docs. All of them. Twice.

The Payoff

First successful test:

$ cargo test test_arxiv_search -- --ignored --nocapture

Downloaded: "Byzantine Fault Tolerance in Practice"
Downloaded: "Consensus in the Age of Blockchains"  
Downloaded: "Practical Byzantine Fault Tolerance Revisited"

✓ 3 papers in 12 seconds

That moment when it works: Chef's kiss.

Week 2.5: PDF Parsing Hell

The Problem

Some PDFs are... weird.

Scanned images (no text)
Encrypted
Malformed
In Comic Sans (okay, not really, but felt like it)

My First Naive Attempt

let text = extract_text(&pdf_path)?;
// Assumes it just works

Spoiler: It didn't.

What Actually Worked

pub fn extract_text(&self, pdf_path: &Path) -> Result {
    // Check file exists (obvious but important)
    if !pdf_path.exists() {
        return Err(ParserError::FileNotFound);
    }

    // Try extraction
    let text = extract_text(pdf_path)
        .map_err(|e| ParserError::ExtractionFailed(e.to_string()))?;

    // Sanity check
    if text.trim().is_empty() {
        warn!("Empty PDF or scanned document: {}", pdf_path.display());
        return Err(ParserError::EmptyDocument);
    }

    // More sanity
    let word_count = text.split_whitespace().count();
    if word_count < 100 {
        warn!("Suspiciously short: {} words", word_count);
    }

    Ok(text)
}

Real test result:

Paper: 20 pages, dense academic writing
Extracted: 12,973 words, 83,063 characters
Time: 100ms
Accuracy: Near-perfect

Victory.

Week 3: Vector Search (Making Papers Searchable)

The Vision

"Show me papers about Byzantine fault tolerance that mention network partitions"

Not keyword search. Semantic search.

The Implementation

// Store papers as vectors
pub struct VectorStore {
    db: Connection,
    embeddings: HashMap>,
}

impl VectorStore {
    pub fn search(&self, query: &str, top_k: usize) -> Result<Vec> {
        // Convert query to vector
        let query_vec = self.embed(query)?;

        // Find similar vectors using cosine similarity
        let results = self.db.query(
            "SELECT * FROM papers 
             ORDER BY vec_distance_cosine(embedding, ?) 
             LIMIT ?",
            params![query_vec, top_k],
        )?;

        Ok(results)
    }
}

The "Holy Shit It Works" Moment

// Query: "consensus under network partition"
let results = store.search("consensus under network partition", 5)?;

// Results (paraphrased):
// 1. "Partition-tolerant consensus protocols"
// 2. "Byzantine agreement with network delays"  
// 3. "Consensus in asynchronous systems"
// 4. "Network partition recovery in distributed systems"
// 5. "Fault tolerance under partial connectivity"

Not a single result mentioned "network partition" explicitly in the title.

Semantic search works. Mind = blown.

The Brutal Truth: What Almost Killed The Project

Problem 1: Scope Creep

Week 2, 3am: "What if it also analyzed tweets and Reddit posts and—"

Solution: Slapped myself. Stuck to the plan.

Problem 2: Perfect Code Paralysis

Week 2, day 4: Spent 6 hours debating enum vs struct for error types.

Solution: Picked one. Shipped it. Moved on.

Problem 3: "Should I Use Python?"

Week 2, day 6: Seriously considered rewriting in Python because "that's what everyone uses."

Solution: Looked at my Rust code. Zero warnings. Fast as hell. Single binary.

Stayed with Rust.

The Numbers (Because People Love Numbers)

Development Timeline

Week 1: Foundation + arXiv integration
Week 2: PDF parsing + metadata tracking
Week 3: Vector search + agent core
Total: 3 weeks, ~150 hours

Code Quality

$ cargo clippy
# Result: 0 warnings

$ cargo test  
# Result: 15 tests, 15 passed, 0 failed

$ cargo build --release
# Result: Binary size: 20MB (single file!)

Performance Benchmarks

Task	Rust	Python	Speedup
PDF parsing	100ms	500ms	5x faster
Vector search	10ms	100ms	10x faster
Full pipeline	2s	10s+	5x faster
Memory usage	50MB	500MB	10x less

Business Metrics (Projected)

Development cost: $0 (solo project)
Hosting cost: ~$280/month (RunPod GPU)
Year 1 revenue target: $140,000
Break-even: 2-6 paying users

What I Learned

1. Rust Is Ready for AI

Myth: "You need Python for AI."

Reality: You need good libraries and APIs. Language doesn't matter.

Rust has:

Excellent HTTP clients (reqwest)
PDF processing (pdf-extract)
Vector databases (SQLite + vec0)
Async runtime (tokio)
Everything you need

2. Quality Compounds

Day 1 decision: Zero warnings allowed.

Week 3 result: Zero refactoring needed. Code just worked.

The math:

Fix warnings daily: 10 min/day × 21 days = 210 minutes
Fix warnings at the end: 3-5 days of hell

Front-load the pain. Thank yourself later.

3. Ship Fast, But Ship Quality

Fast ≠ Sloppy

Fast = Efficient

I shipped in 3 weeks by:

Making quick decisions (not perfect ones)
Writing tests immediately (not "later")
Maintaining quality gates (zero warnings)
Iterating rapidly (ship, measure, improve)

4. Self-Hosted LLMs Work

RunPod + vLLM:

$0.39/hour for A40 GPU
DeepSeek-R1 quality responses
Full control over prompts
No OpenAI API bills

Total LLM cost during development: $47

vs. OpenAI API for same workload: $300+

5. Open Source Builds Credibility

Released on GitHub from day 1:

Forces clean code (people will see it)
Builds portfolio
Attracts contributors
Creates trust with users

Side benefit: Looks great on LinkedIn.

The Tech Stack (For the Curious)

Core Technologies:

Language: Rust 2021
Async Runtime: Tokio
HTTP Client: Reqwest + Rustls (HTTPS only)
Database: SQLite
Vector Database: vec0 extension
PDF Processing: pdf-extract
XML Parsing: quick-xml
LLM: Self-hosted vLLM (RunPod)
Deployment: Single binary
CI/CD: GitHub Actions
Hosting: RunPod (GPU) + GitHub Pages (landing)

Notable absences: Python, Docker (for core app), Kubernetes, microservices

Why? They weren't needed. Simplicity wins.

What's Next?

Short Term (This Month)

[x] GitHub release v1.0.0
[ ] Landing page launch
[ ] Waitlist setup
[ ] First 100 signups

Q1 2026

[ ] Authentication (GitHub, Google, Email)
[ ] SaaS infrastructure
[ ] Beta launch
[ ] First paying customers

Q2 2026

[ ] Public launch
[ ] Enterprise tier
[ ] Academic paper publication
[ ] $10k MRR (Monthly Recurring Revenue)

The Dream

Platform for autonomous research. Not just blockchain. Any technical domain.

Imagine:

AI researching quantum computing papers
AI analyzing medical research
AI exploring ML architectures
All autonomous. All documented. All open source.

Try It Yourself

# Clone the repository
git clone https://github.com/ChronoCoders/consensusmind.git
cd consensusmind

# Build (requires Rust)
cargo build --release

# Run
./target/release/consensusmind

# Or just explore the code

Fair warning: You'll see that AI tools don't need Python. This might change your perspective on everything.

The Real Lesson

You don't need:

Python for AI
Months to build production software
A team to ship something real
Venture capital to start
Permission to build the future

You DO need:

A clear vision
Quality standards
Execution speed
Willingness to learn
Guts to ship

I built ConsensusMind in 3 weeks, solo, with zero budget.

What's your excuse?

Links and Resources

Live Demo: chronocoders.github.io/consensusmind
GitHub Repository: github.com/ChronoCoders/consensusmind
Documentation: GitHub README
Contact: hello@dslabs.network

Built something cool with Rust? Drop a comment. Let's talk.

About the Author

Altug Tatlisu builds autonomous research tools at Distributed Systems Labs. He believes the future is written in Rust, not Python. Follow him on GitHub to watch the journey unfold.

P.S. If you're still reading, you're probably going to build something awesome. When you do, tag me. I want to see it.

StarReaper: Cleaning Star-Farming Bots from Your GitHub Followers

Altug Tatlisu — Mon, 02 Mar 2026 20:30:19 +0000

GitHub stars and followers are supposed to be trust signals.

But increasingly, they’re being gamed.

If you maintain public repositories, you’ve probably seen accounts that:

Follow thousands of users
Have zero repositories
Were created last week
Contain bios like “star for star” or “follow back”

These aren’t contributors.
They’re engagement manipulators.

So I built StarReaper — a small Rust CLI tool that detects and blocks star-farming and follow-manipulation accounts automatically.

The Problem: Artificial Signal Inflation

Stars and followers shape perception:

Open-source credibility
Project discoverability
Hiring signals
Investor optics

Star-farming accounts distort that signal.

Most of them operate using predictable patterns:

“S4S” / “F4F” bios
Following thousands of accounts
Zero public repositories
Recently created accounts
Extremely skewed follow ratios

Individually, these signals aren’t conclusive.
Combined, they form a reliable heuristic profile.

Design Goals

StarReaper was built with four constraints:

Deterministic — no machine learning guesswork
Transparent — every flag has a reason
Safe — dry-run mode before enforcement
Lightweight — no database, no server, no OAuth app

It’s a standalone Rust binary.

How StarReaper Works

The execution pipeline is simple:

Fetch followers
→ Fetch profile data
→ Score heuristics
→ Flag accounts above threshold
→ Optionally block

Each profile is scored using weighted signals:

Signal	Score
Bio contains star-farming keywords	+3
Suspicious following/follower ratio	+2
Zero public repositories	+1
Account younger than 90 days	+1
Zero followers + active following	+1

Default block threshold: 3

This means a bio like “star for star” triggers immediate blocking.
Weaker signals must stack to trigger enforcement.

Safety First: Dry Run Mode

Before blocking anyone, you can audit:

export GITHUB_PAT=ghp_yourtoken
starreaper --dry-run

Output includes:

Username
Risk score
Exact reasons

Only when you’re satisfied:

starreaper --threshold 3

Why Rust?

StarReaper is written in Rust because:

Predictable async networking (reqwest + tokio)
Strong type safety
Clean static binary distribution
No runtime dependencies
Reliable TLS via rustls

It uses GitHub’s REST API with proper pagination and rate-aware delays.

Technical Details

API Endpoints Used

GET /user/followers
GET /users/{username}
PUT /user/blocks/{username}

Authentication requires a classic PAT with:

user

No repository access required.

Pagination Support

GitHub limits responses to 100 per page.

StarReaper automatically paginates until:

It reaches your specified limit
Or no more followers remain

Rate Limiting

The tool inserts a controlled delay between requests and stays within authenticated GitHub API limits (5,000 requests/hour).

It’s designed for periodic execution — not continuous polling.

Why Not Just Ignore Bots?

You can.

But artificial engagement has subtle effects:

Inflates follower count artificially
Distorts trust perception
Pollutes notification streams
Degrades signal integrity

StarReaper restores authenticity.

It doesn’t optimize growth.
It removes manipulation.

Is It Perfect?

No heuristic system is.

That’s why:

Default threshold is conservative
Bio keyword match alone is strong
Weak signals must stack
Dry-run mode exists

This is a hygiene tool — not a ban hammer.

Installation

Build from source:

cargo build --release

Run:

export GITHUB_PAT=ghp_yourtoken
./target/release/starreaper --dry-run

Future Directions

StarReaper currently focuses on follower hygiene.

Possible extensions:

GitHub Action integration
Scheduled execution
Whitelist support
JSON output mode
Cross-platform reputation scoring

This could evolve into a broader reputation integrity engine.

For now, it’s focused and intentional.

Final Thoughts

Stars are social proof.
Social proof only works when it’s authentic.

StarReaper doesn’t grow your numbers.
It protects their integrity.

If you care about signal over noise, this tool is for you.

StarReaper is open source.

🔗 GitHub Repository: https://github.com/chronocoders/starreaper

Why My Windows Transparent Proxy Failed on Wi-Fi (and Worked on Ethernet)

Altug Tatlisu — Wed, 21 Jan 2026 20:14:19 +0000

TL;DR:

My transparent proxy was architecturally correct, fully implemented, and thoroughly tested — yet it silently failed on Wi-Fi. The reason wasn’t a bug, a missing flag, or bad code. It was a Windows + Wi-Fi driver boundary that user-mode tools like WinDivert simply cannot cross.

This article documents the journey, the dead ends, the hard evidence, and the final, correct conclusion.

Background

I was building a transparent TCP proxy on Windows using:

Rust
WinDivert (user-mode packet capture/injection)
SOCKS5 upstream
Full DNAT / SNAT redirection
No explicit proxy configuration on the client

The goal was simple:

Intercept outbound TCP connections (ports 80/443), transparently redirect them to a local proxy, and forward traffic upstream — without breaking applications or TCP semantics.

This is a solved problem on Linux (iptables + REDIRECT).
On Windows, it’s much harder.

Phase 1: The Wrong Idea (Packet Forging)

The initial design attempted to:

Intercept outbound SYN packets
Drop them
Forge a SYN-ACK pretending to be the real server
Maintain a user-space TCP state machine
Relay data via SOCKS5

On paper, everything worked:

Correct TCP flags
Correct SEQ/ACK numbers
Correct IP + TCP checksums
Verified hex dumps
Passing unit tests

Reality:
Windows silently dropped every forged SYN-ACK.

No ACK.
No handshake.
No error.

Root Cause

Windows enforces TCP anti-spoofing below WinDivert.

User-mode code cannot inject packets claiming to originate from external IPs and expect the TCP stack to accept them.

This is not configurable.
No WinDivert layer fixes this.
Not Impostor, not REFLECT, not FORWARD.

Conclusion:
Forging TCP peers in user mode on Windows is architecturally impossible.

Phase 2: The Correct Architecture (Redirection)

After discarding packet forging entirely, I implemented the only correct approach:

Transparent Redirection (DNAT / SNAT)

Intercept outbound SYN
Record original destination (dst_ip, dst_port)
Rewrite destination → LOCAL_IP:8899
Flip packet direction to INBOUND
Let Windows complete a real TCP handshake
Proxy connects upstream via SOCKS5
Rewrite source on return packets back to original server
Flip direction to OUTBOUND
Clean up mappings on FIN/RST

Key rules:

No forged packets
No custom TCP state machine
Windows owns TCP semantics

This is how all real transparent proxies work on Windows.

Everything Was Correct — Yet Nothing Worked

Even with the correct architecture:

curl hung
No outbound SYN visible
WinDivert captured only inbound packets
Outbound=1 never appeared
NETWORK_FORWARD layer captured nothing
Filters were correct
Injection logic was correct

At this point, the usual suspects were gone.

The Critical Discovery: Wi-Fi Fast-Path

The system used an Intel Wi-Fi adapter.

After exhaustive testing:

WinDivert never saw outbound TCP packets
Even with filter "tcp"
Even after disabling all configurable offloads
Even after restarting the adapter
Even at different WinDivert layers

PowerShell confirmed it:

Get-NetAdapterAdvancedProperty -Name "Wi-Fi"

Only WoWLAN offloads existed.
No TCP offload toggles.
No segmentation controls.

What This Means

On this Wi-Fi adapter:

Outbound TCP packets are constructed below NDIS
They bypass filter drivers entirely
They never appear as discrete IP packets
User-mode tools cannot intercept them

Inbound packets still appear — because they must traverse the receive path.

This is a driver + firmware fast-path, not a bug.

Why Ethernet Works (and Wi-Fi Doesn’t)

Ethernet drivers typically:

Do not use hard fast-paths
Expose outbound packets through NDIS
Allow WinDivert to see and modify traffic

Wi-Fi drivers often:

Offload TCP construction to firmware
Skip NDIS filter layers
Make outbound interception impossible in user mode

This is why:

Commercial VPNs use kernel-mode WFP drivers
User-mode tools work reliably on Ethernet
Wi-Fi support requires deeper hooks

Final Resolution

I chose the most pragmatic and correct next step:

USB-to-Ethernet Adapter

~$15
Zero code changes
Immediate validation

This isn’t a workaround — it’s crossing a known platform boundary.

On Ethernet:

Outbound packets appear
DNAT/SNAT works
TCP handshake completes
Proxy exit IP is visible
Architecture is fully validated

Key Takeaways

1. You cannot forge TCP peers on Windows in user mode

Anti-spoofing is enforced below WinDivert.

2. Transparent proxies must use redirection, not forgery

Let the OS own TCP.

3. WinDivert is correct — but limited by NIC drivers

Especially on Wi-Fi.

4. Absence of packets can be a hardware truth, not a bug

Empirical testing matters more than assumptions.

5. Ethernet validates architecture; Wi-Fi dictates tooling

User mode vs kernel mode is not a preference — it’s a requirement.

When Do You Need WFP?

Only if:

Transparent interception over Wi-Fi is mandatory
Production deployment is required
Kernel development is acceptable

Otherwise:

User-mode + Ethernet is sufficient
Architecture is sound
Complexity stays manageable

Closing

This project did not fail.

It reached a correct architectural conclusion, backed by:

Clean code
Empirical testing
Layer isolation
Hardware-level evidence

Sometimes the hardest bugs aren’t bugs at all — they’re boundaries.

If this saves you weeks of chasing ghosts, it did its job.

Physical Proof of Proximity (PoPI): Making Sybil Attacks Physically Expensive

Altug Tatlisu — Sat, 17 Jan 2026 03:40:13 +0000

Sybil attacks are not a cryptographic problem.

They are an economic problem.

If a single machine can cheaply generate thousands of identities,

any distributed system that relies purely on digital identity will eventually be gamed.

Physical Proof of Proximity (PoPI) is an attempt to change that equation by introducing
real-world physical constraints into decentralized systems.

This post explains what PoPI is, what it is not, and where it actually makes sense.

The Core Problem: Digital Identity Is Too Cheap

In most distributed systems:

Creating a new identity costs almost nothing
Spinning up thousands of nodes is trivial in the cloud
Identity has no physical anchor

This enables:

Sybil attacks
Fake participation
Artificial consensus influence

The issue is not weak cryptography.
It’s that software scales faster than reality.

Why Existing Approaches Don’t Fully Solve This

Proof of Work

Makes attacks expensive via energy
Wastes resources
Centralizes around specialized hardware

Proof of Stake

Ties influence to capital
Concentrates power
Assumes fair initial distribution

Both approaches assume attackers are remote and abstract.

They do not consider physical presence as a constraint.

What Is Physical Proof of Proximity?

Physical Proof of Proximity (PoPI) is a constraint-based mechanism.

Instead of asking:

“Who are you?”

PoPI asks:

“Can you physically react within real-world limits?”

It relies on the fact that physical signals obey physics:

They propagate at finite speed
They weaken with distance
They require hardware to measure

PoPI does not replace cryptography.
It adds a physical cost layer on top of it.

High-Level PoPI Flow


1. A node emits a short-lived physical challenge
2. Nearby nodes measure the challenge in real time
3. Nodes respond with time-bounded measurements
4. Responses are verified against physical constraints
5. Invalid or delayed responses are rejected

The key property:
You cannot fake proximity without being physically present.

What Counts as a Physical Signal?

PoPI is intentionally multi-modal. Examples include:

Radio signal strength (WiFi / BLE RSSI)
Time-of-flight constraints
Acoustic or ultrasonic signals
Synchronized sensor challenges (motion, orientation)

No single signal is trusted alone.
The system relies on combined constraints.

Threat Model

PoPI assumes:

Attackers can automate software
Attackers can rent cloud infrastructure
Attackers cannot cheaply scale physical presence

PoPI does not protect against:

Well-funded local attackers
Nation-state adversaries
Physical device theft

This is a cost-increase mechanism, not a silver bullet.

Why This Helps Against Sybil Attacks

To fake N identities under PoPI, an attacker must provide:

N physically present devices
N real-time responses
N independent signal measurements

This shifts attacks from:

“Write more code”

to:

“Deploy more hardware in physical space”

The attack surface becomes logistics, not computation.

Where PoPI Makes Sense

PoPI is not for global permissionless blockchains.

It works best in environments where physical locality already exists:

Local mesh networks
Emergency communication systems
Research labs
Community networks
IoT clusters
Offline-first systems

In these contexts, physical presence is already a given.
PoPI simply formalizes it.

Limitations and Open Problems

PoPI introduces new challenges:

Coordination overhead
Hardware variability
Calibration and false positives
Scalability beyond local regions

Global-scale PoPI remains an open research problem.

Any implementation must be honest about these trade-offs.

Final Thoughts

PoPI is not about replacing cryptography.

It is about reintroducing physical reality into systems that have ignored it for too long.

Sometimes the strongest defense is not perfect security,
but making attacks physically inconvenient.

This post describes an ongoing research direction.
Critical feedback and alternative approaches are welcome.

The Arbitrage Bot Arms Race: What We Learned Running FlashArb in Production

Altug Tatlisu — Fri, 19 Dec 2025 00:46:30 +0000

Let me tell you something nobody else will: running a profitable arbitrage bot in 2025 is like playing chess against a thousand grandmasters who all move simultaneously.

I've been running a production arbitrage trading platform for over a year now. It executes profitable trades across multiple DEXs using flash loans, and I've learned some brutal lessons that the YouTube "passive income" crowd conveniently forgets to mention.

This isn't theory. This is what actually happens when your code meets mainnet.

What Flash Loan Arbitrage Actually Is (For The Uninitiated)

Let's start simple. Imagine you notice that on Uniswap, 1 ETH costs $3,000, but on SushiSwap, you can sell that same 1 ETH for $3,010. Free money, right?

The problem: You need ETH to buy ETH. Classic chicken-and-egg.

The solution: Flash loans let you borrow massive amounts of crypto (we're talking millions) with zero collateral, as long as you pay it back in the same transaction. If you can't pay it back, the entire transaction reverts like it never happened.

So the play is:

Borrow 1000 ETH (flash loan)
Buy cheap on DEX A
Sell high on DEX B
Repay the loan + fees
Keep the profit

Sounds easy. It's not.

The Three Lies They Tell You About Arbitrage Bots

Lie #1: "Opportunities Are Everywhere"

Reality: In our first month, we scanned 2.4 million potential arbitrage opportunities. Want to guess how many were actually profitable after gas fees?

That's a success rate of 0.006%. The rest got eaten by:

Gas fees (the big killer)
Slippage (prices move while your tx is pending)
MEV bots that frontrun your transaction
Failed transactions that still cost you gas

The opportunities exist, but they disappear faster than you can blink. We're talking milliseconds, not minutes.

Lie #2: "It's Risk-Free"

Technically true - if your arbitrage fails, the flash loan reverts and you lose nothing.

Practically false - you still paid gas for a failed transaction. At peak times, we've paid $200+ in gas for transactions that reverted.

In our worst month, we spent $8,400 in gas on failed transactions. That's tuition to the School of Hard Mainnet.

Lie #3: "Just Copy Someone's GitHub Code"

We've reviewed probably 50+ open-source arbitrage bots on GitHub. Here's what we found:

70% don't work at all (outdated, broken dependencies)
25% work but are instantly unprofitable (gas costs more than profit)
4% work but get frontrun by MEV bots within seconds
1% might actually work, but good luck figuring out why

The bots that actually make money? Nobody's open-sourcing those.

What Actually Works: A Production-Ready Stack

After a year of pain, here's what FlashArb actually looks like in production:

1. Multi-DEX Monitoring at Scale

We monitor price differences across:

Uniswap V2/V3
SushiSwap
Balancer
Curve
PancakeSwap (BSC)

The key: We don't query DEXs directly. We run our own archive nodes and index everything locally. Querying APIs is too slow - by the time you get the data, the opportunity is gone.

// Simplified version of our price monitoring
pub struct PriceOracle {
    pools: HashMap<PoolId, Pool>,
    price_cache: Arc<RwLock<PriceCache>>,
}

impl PriceOracle {
    pub async fn find_arbitrage(&self) -> Vec<ArbitrageOpportunity> {
        let mut opportunities = Vec::new();

        // Check all pool pairs in parallel
        for (pool_a, pool_b) in self.get_pool_pairs() {
            if let Some(arb) = self.calculate_profit(pool_a, pool_b).await {
                if arb.profit_after_gas() > MIN_PROFIT_THRESHOLD {
                    opportunities.push(arb);
                }
            }
        }

        opportunities
    }
}

2. Gas Optimization Is Everything

Our average gas cost per transaction: 180,000 - 220,000 gas units

Our competitors' average: 350,000 - 500,000 gas units

That difference matters. At 50 gwei gas prices, that's $5-10 saved per transaction. Over hundreds of transactions, it's the difference between profit and loss.

How we did it:

Custom Solidity contracts optimized to the byte
Batch multiple swaps in single transactions
Smart gas price prediction (we don't blindly use fast gas)

3. The MEV Protection Problem

Here's the thing nobody tells you: even if you find a profitable opportunity, someone can copy your transaction and frontrun you.

This is MEV (Maximal Extractable Value), and it's a nightmare. Bots watch the mempool, see your profitable transaction, copy it, and submit it with higher gas so miners process theirs first.

Our solution (partial):

Use private mempools (Flashbots, Eden Network)
Submit bundles directly to validators
Sometimes we eat the loss and use public mempool anyway

Even with these protections, we still get frontrun ~15% of the time. It's just part of the game now.

The Real Numbers (Things Get Ugly)

Let me show you what three months of FlashArb actually looks like:

Transactions Submitted: 1,247
Successful Arbitrages: 892 (71.5% success rate)
Failed/Reverted: 355 (28.5%)

Gross Profit: $47,320
Gas Costs (successful tx): $12,180
Gas Costs (failed tx): $8,400
Infrastructure Costs: $2,100 (nodes, servers, monitoring)

Net Profit: $24,640

That's about $8,213/month, which sounds great until you realize:

We have two engineers maintaining this full-time
The code breaks every time a DEX updates their contracts
One bug can drain your wallet in seconds
You're competing against teams with way more resources

The Arms Race Never Ends

Here's what kills most arbitrage bots: complacency.

The strategy that works today won't work tomorrow. Why?

More bots enter the market - Your edge gets arbitraged away
DEXs upgrade their routing - Opportunities that existed yesterday vanish
Gas prices fluctuate wildly - Your profitable threshold shifts daily
MEV strategies evolve - The frontrunners get smarter

We update FlashArb's strategies every 2-3 weeks. If you're not constantly adapting, you're dead.

Should You Build An Arbitrage Bot?

Honest answer: Probably not.

If you're thinking "I'll just spin up a bot and make passive income," you're going to lose money. The YouTube tutorials and Medium articles make it sound easy. It's not.

You should build one if:

You want to learn how DeFi actually works at a deep level
You have capital to burn on education (gas fees are expensive lessons)
You're comfortable with Rust/Solidity and async programming
You can dedicate serious time to monitoring and maintenance
You understand you're competing against well-funded teams

You shouldn't build one if:

You think it's "passive income" (lol)
You don't have at least $5k to lose on gas alone
You're not comfortable reading smart contract code
You want something that "just works" without constant attention

What's Next in This Space

The arbitrage game taught me that raw arbitrage is a race to the bottom. The evolution I'm seeing:

Cross-chain arbitrage - Opportunities between chains last longer
Liquidity provision + JIT arbitrage - Provide liquidity, arb your own pools
MEV-aware routing - Help users avoid getting frontrun

The game keeps changing. You either evolve or you lose.

The Bottom Line

Running a production arbitrage bot isn't a money printer. It's a full-time engineering job where you're constantly fighting smarter, faster, better-funded competitors.

But it's also one of the best educations you can get in how DeFi actually works. The lessons I learned building this system directly informed my other blockchain projects - especially around MEV protection and transaction optimization.

If you decide to build your own, go in with eyes open. The opportunities are real, but so is the competition.

And when you inevitably burn $500 in gas on a single failed transaction because you forgot to check slippage? Welcome to the club. We've all been there.

I'm a blockchain engineer who's been building decentralized systems for 7+ years. Currently working on experimental consensus mechanisms and production DeFi infrastructure. Always happy to discuss the technical details - drop a comment if you have questions or want to share your own war stories.

Building a Production-Ready Blind Signature eCash System in Rust

Altug Tatlisu — Sun, 07 Dec 2025 00:34:02 +0000

Ever wondered how anonymous digital cash could work without blockchain? In 1983, cryptographer David Chaum published a groundbreaking paper introducing blind signatures - a protocol that allows someone to get a message signed without revealing its contents. This became the foundation for DigiCash, the world's first digital cash system.

Today, I'm open-sourcing a complete, production-ready implementation of Chaum's protocol in Rust.

🎯 What We Built

GitHub Repository | Live Demo | Crates.io

A full-stack anonymous payment system featuring:

RSA-3072 blind signatures (128-bit security)
Double-spend prevention via atomic Redis + PostgreSQL checks
REST API with Axum framework
Client SDK with wallet functionality
Docker deployment ready for production
Complete documentation including academic whitepaper

🔐 The Magic of Blind Signatures

Here's what makes this protocol brilliant:

Traditional Digital Signature:

Alice → Message → Bob signs → Alice gets signature

Problem: Bob sees the message content

Blind Signature Protocol:

Alice → Blinded Message → Bob signs → Alice unblinds → Valid signature

Bob never sees the original message!

The Math Behind It

Using RSA with modulus n and keypair (e, d):

1. Blinding (Client)

let message = hash(serial_number);
let blinding_factor = random() % n;
let blinded = (message * blinding_factor.pow(e)) % n;

2. Signing (Server)

let blind_signature = blinded.pow(d) % n;

3. Unblinding (Client)

let signature = (blind_signature * blinding_factor.inverse()) % n;

Result: Valid RSA signature on the original message, but the server never saw it!

🏗️ Architecture Overview

┌──────────┐      ┌────────┐      ┌────────────┐
│  Client  │─────▶│ Nginx │────▶ │ API Server │
│ (Wallet) │      │  :80   │      │   :8080    │
└──────────┘      └────────┘      └──────┬─────┘
                                         │
                        ┌────────────────┼────────────┐
                        ▼                ▼            ▼
                   ┌─────────┐    ┌─────────┐   ┌──────┐
                   │  Redis  │    │Postgres │   │ HSM  │
                   │ (Cache) │    │ (Audit) │   │(Keys)│
                   └─────────┘    └─────────┘   └──────┘

💻 Implementation Highlights

1. Core Cryptography (`ecash-core`)

The heart of the system - cryptographic primitives implemented with constant-time operations:

pub struct BlindUser {
    public_key: RsaPublicKey,
}

impl BlindUser {
    pub fn blind_message(&self, message: &[u8]) -> Result<(BigUint, BigUint)> {
        let n = self.public_key.n();
        let e = self.public_key.e();

        // Hash the message
        let m = BigUint::from_bytes_be(&Sha256::digest(message));

        // Generate blinding factor
        let r = loop {
            let candidate = random_biguint(n.bits());
            if candidate > 1 && gcd(&candidate, n) == 1 {
                break candidate;
            }
        };

        // Blind: m' = m * r^e mod n
        let r_e = r.modpow(e, n);
        let blinded = (&m * &r_e) % n;

        Ok((blinded, r))
    }

    pub fn unblind_signature(
        &self, 
        blind_sig: &BigUint, 
        blinding_factor: &BigUint
    ) -> Result<BigUint> {
        let n = self.public_key.n();
        let r_inv = mod_inverse(blinding_factor, n)?;

        // Unblind: s = s' * r^-1 mod n
        Ok((blind_sig * r_inv) % n)
    }
}

2. Double-Spend Prevention

The critical security feature - preventing the same token from being spent twice:

pub async fn redeem_token(&self, token: &Token) -> Result<String> {
    // Two-tier check for maximum reliability

    // 1. Fast check in Redis (O(1))
    if self.cache.exists(&token.serial).await? {
        return Err(Error::TokenAlreadySpent);
    }

    // 2. Reliable check in PostgreSQL
    if self.db.is_token_spent(&token.serial).await? {
        return Err(Error::TokenAlreadySpent);
    }

    // 3. Atomic transaction - both must succeed
    let tx_id = Uuid::new_v4();

    sqlx::query!(
        "INSERT INTO redeemed_tokens (serial, tx_id, timestamp) 
         VALUES ($1, $2, NOW())",
        token.serial,
        tx_id
    )
    .execute(&self.db.pool)
    .await?;

    self.cache.set(&token.serial, tx_id.to_string()).await?;

    Ok(tx_id.to_string())
}

3. REST API with Axum

Clean, type-safe HTTP handlers:

async fn withdraw(
    State(state): State<Arc<AppState>>,
    Json(req): Json<WithdrawRequest>,
) -> Result<Json<WithdrawResponse>> {
    // Verify denomination is valid
    if !state.is_valid_denomination(req.denomination) {
        return Err(ApiError::InvalidDenomination(req.denomination));
    }

    // Sign each blinded token
    let signatures = req.blinded_tokens
        .iter()
        .map(|blinded| {
            state.institution
                .sign_blinded(&BigUint::from_str(blinded)?)
        })
        .collect::<Result<Vec<_>>>()?;

    Ok(Json(WithdrawResponse {
        transaction_id: Uuid::new_v4().to_string(),
        blind_signatures: signatures,
        expires_at: Utc::now() + Duration::days(90),
    }))
}

📊 Performance Benchmarks

Tested on a 4-core, 8GB RAM instance:

Operation	Latency (p50)	Latency (p99)	Throughput
Withdrawal	45ms	120ms	150 req/s
Redemption	25ms	80ms	600 req/s
Verification	5ms	15ms	2000 req/s

The bottleneck is RSA operations (CPU-bound). Horizontal scaling is straightforward since the API servers are stateless.

🚀 Getting Started

Quick Start with Docker

git clone https://github.com/ChronoCoders/ecash-protocol.git
cd ecash-protocol
docker-compose up -d

That's it! You now have:

API server on localhost:8080
PostgreSQL database
Redis cache
Nginx reverse proxy with rate limiting

Using the Client SDK

Add to your Cargo.toml:

[dependencies]
ecash-client = "0.1.0"

Example usage:

use ecash_client::Wallet;

#[tokio::main]
async fn main() -> Result<()> {
    // Initialize wallet
    let mut wallet = Wallet::new(
        "http://localhost:8080".to_string(),
        "wallet.db".to_string(),
    )?;

    wallet.initialize().await?;

    // Withdraw $100 in $10 denominations
    let tokens = wallet.withdraw(100, 10).await?;
    println!("Withdrew {} tokens", tokens.len());

    // Check balance
    let balance = wallet.get_balance()?;
    println!("Balance: ${}", balance);

    // Spend $20
    let tx_id = wallet.spend(20).await?;
    println!("Transaction: {}", tx_id);

    Ok(())
}

🔒 Security Considerations

Cryptographic Guarantees

Unlinkability: The server cannot link a withdrawal to a redemption. Even if the server stores all blinded tokens and later sees them redeemed, the cryptographic unlinkability property holds.

Unforgeability: Creating a valid token requires the server's private key. RSA-3072 provides 128-bit security against forgery.

Double-Spend Prevention: Atomic database operations ensure tokens cannot be spent twice, even under concurrent requests.

Production Hardening

For production deployment, consider:

HSM for private keys - Never store private keys on disk
TLS/HTTPS - All communication should be encrypted
Rate limiting - Prevent DoS attacks (included in Nginx config)
Monitoring - Track failed verifications and double-spend attempts
Key rotation - Implement periodic key rotation (not yet included)

📈 Scaling Strategy

The system is designed for horizontal scaling:

API Servers: Stateless, add more instances behind load balancer
Database: PostgreSQL primary-replica setup (1 primary + 2+ replicas)
Cache: Redis cluster with sharding

Expected capacity per node:

Single node: ~1000 req/s total throughput
3-node cluster: ~3000 req/s
10-node cluster: ~10,000 req/s

Database becomes the bottleneck around 5,000 req/s - at that point, implement read replicas and connection pooling.

🎓 Academic Foundation

This implementation is based on:

Chaum, D. (1983). "Blind Signatures for Untraceable Payments."
Advances in Cryptology - CRYPTO '82, pp. 199-203.

The full academic whitepaper (164KB) is included in the repository, covering:

Mathematical proofs of security properties
Protocol specification
Comparison with blockchain-based systems
Performance analysis

🛠️ Tech Stack

Language: Rust 1.91+
Web Framework: Axum 0.7
Database: PostgreSQL 16
Cache: Redis 7
Crypto: RSA crate with 3072-bit keys
Deployment: Docker, Kubernetes

Why Rust? Memory safety, zero-cost abstractions, and excellent async performance. Perfect for cryptographic applications.

🌟 What's Next?

Current status: Production Ready v1.0.0

Future roadmap:

[ ] Key rotation mechanism
[ ] Multi-denomination optimization
[ ] gRPC API alongside REST
[ ] Hardware wallet support
[ ] Threshold signatures for key management
[ ] Zero-knowledge proofs for enhanced privacy

🤝 Contributing

The project is fully open source (MIT license). Contributions welcome!

Repository: https://github.com/ChronoCoders/ecash-protocol
Docs: https://docs.rs/ecash-core
Live Demo: https://chronocoders.github.io/ecash-protocol

💭 Final Thoughts

Building this system taught me that Chaum's 1983 protocol is remarkably elegant - it solves the privacy problem with pure mathematics, no blockchain required.

The blind signature approach offers:
✅ True anonymity - cryptographically guaranteed unlinkability
✅ Instant finality - no block confirmations needed
✅ Efficiency - orders of magnitude faster than blockchain
✅ Simplicity - can be understood and audited

The main limitation? It requires a trusted central authority (the signer). But for many use cases - corporate payment systems, loyalty points, internal currencies - this is perfectly acceptable.

If you're interested in privacy-preserving cryptography or digital payments, I highly recommend diving into the code. The repository includes extensive documentation, a complete test suite, and a working demo wallet.

Star the repo if you found this interesting! ⭐

Have questions? Drop them in the comments below or open an issue on GitHub!

Resources

📦 Crates.io: ecash-core | ecash-client | ecash-server
📚 Documentation: docs.rs/ecash-core
🌐 Website: chronocoders.github.io/ecash-protocol
📄 Whitepaper: Read on GitHub
💬 Discussions: GitHub Discussions

rust #cryptography #opensource #privacy #security #blockchain #payments #fintech

I Built a Zero-Knowledge VPN That Can't Track You (Even If It Wanted To)

Altug Tatlisu — Thu, 04 Dec 2025 23:11:19 +0000

Hey folks! 👋

So I have a confession: I'm a bit obsessed with privacy-preserving systems. Last month, while reading ExpressVPN's white paper on their Dedicated IP architecture, I had one of those 3 AM moments where you think "wait... I could build this." Four weeks and way too much coffee later, I ended up with a fully functional zero-knowledge VPN system written entirely in Rust.

And here's the cool part: the system literally cannot link your identity to your IP address, even if someone hacks the database or puts a gun to the server's head (metaphorically speaking, of course).

Let me show you how it works.

The Problem: DIPs Are Great, But Privacy Suffers

Traditional VPNs give everyone shared IPs, which is great for anonymity but terrible when you need to access IP-restricted services like banking, streaming platforms, or enterprise systems. That's where Dedicated IPs (DIPs) come in—you get your own persistent IP address.

But here's the catch: in most DIP implementations, there's a database somewhere that looks like this:

user_12345 → 192.168.1.100
user_67890 → 192.168.1.101

One database breach, one subpoena, or one dishonest admin, and boom—all that privacy you paid for vanishes. Your entire browsing history can now be linked back to you.

Not cool.

The Solution: Blind Signatures + Cryptographic Separation

I needed a system where:

Users can prove they have a valid subscription
Users get assigned a dedicated IP
Nobody—not even the server—can link the two together

Enter the magic of blind RSA signatures. 🎩✨

How It Works (The Simple Version)

Think of it like this: imagine you write a secret message, put it in an envelope, and then put that envelope inside another opaque envelope. You hand it to someone who signs the outer envelope without ever seeing what's inside. You then remove the outer envelope, and voila—you have a signed message that the signer never actually saw.

That's essentially what blind signatures do, and it's the foundation of my system.

Here's the flow:

┌─────────────┐
│   Client    │ 
└──────┬──────┘
       │ 1. Generate random token + blind it
       ▼
┌─────────────────────┐
│ Blind Token Service │ (knows your subscription)
└──────┬──────────────┘
       │ 2. Signs blinded token (can't see actual token)
       ▼
┌─────────────┐
│   Client    │ ← Unblinds signature
└──────┬──────┘
       │ 3. Sends unblinded signature
       ▼
┌─────────────────────┐
│    DIP Service      │ (knows the IP, but NOT your subscription)
└──────┬──────────────┘
       │ 4. Assigns IP from pool
       ▼
┌─────────────────────┐
│   Enclave Sim       │ (generates tokens in isolation)
└─────────────────────┘

The beautiful part? No single component ever sees both your subscription ID and your IP address. It's cryptographic separation by design.

Show Me The Code! 🦀

Of course, I built this in Rust because:

Memory safety (no CVEs from buffer overflows, please)
Blazing fast crypto operations
Type safety that catches bugs at compile time
Async runtime that handles thousands of connections

Here's a taste of the blind signature implementation:

pub struct BlindClient {
    public_key: RsaPublicKey,
}

impl BlindClient {
    pub fn blind(&self, message: &[u8]) -> Result<BlindedToken> {
        let mut rng = OsRng;
        let n = BigUint::from_bytes_be(&self.public_key.n().to_bytes_be());
        let e = BigUint::from_bytes_be(&self.public_key.e().to_bytes_be());

        // Generate blinding factor that's coprime with n
        let r = loop {
            let candidate = rng.gen_biguint_range(&BigUint::from(2u32), &n);
            if num_integer::Integer::gcd(&candidate, &n) == BigUint::one() {
                break candidate;
            }
        };

        let message_int = BigUint::from_bytes_be(message);
        let r_e = r.modpow(&e, &n);
        let blinded = (message_int * r_e) % &n;

        Ok(BlindedToken {
            blinded_message: blinded.to_bytes_be(),
            blinding_factor: r.to_bytes_be(),
        })
    }

    pub fn unblind(&self, blind_signature: &[u8], blinding_factor: &[u8]) -> Result<UnblindedSignature> {
        let n = BigUint::from_bytes_be(&self.public_key.n().to_bytes_be());
        let sig = BigUint::from_bytes_be(blind_signature);
        let r = BigUint::from_bytes_be(blinding_factor);

        let r_inv = r.modinv(&n).ok_or(CryptoError::InvalidBlindingFactor)?;
        let unblinded = (sig * r_inv) % &n;

        Ok(UnblindedSignature {
            signature: unblinded.to_bytes_be(),
        })
    }
}

The math is beautiful: we're essentially doing modular arithmetic to hide the message from the signer while still getting a valid signature.

The Token Dance 🎫

The system uses three types of JWT tokens:

1. SRT (Subscription Receipt Token)

{
  "sub": "user_subscription_123",
  "exp": 1735948800,
  "entitlements": {
    "xv.vpn.dip": {
      "did": 0
    }
  }
}

This proves you have a valid subscription. Only the Blind Token Service sees this.

2. DAT (Dedicated IP Access Token)

{
  "exp": 1735948800,
  "xv.vpn.dip.details": {
    "ip": "192.168.1.100"
  }
}

This is what you use to connect to the VPN. Short-lived (3 days).

3. DRT (Dedicated IP Refresh Token)

{
  "sub": "user_subscription_123",
  "exp": 1740960000,
  "xv.vpn.dip.details": {
    "ip": "192.168.1.100"
  },
  "did": 0
}

This lets you refresh your DAT without going through the whole assignment process again. It's encrypted with ECDH-derived keys, so only you and the enclave can read it.

The Database Schema: Zero-Knowledge By Design

Here's what makes me really proud—the database schema itself enforces zero-knowledge:

Blind Token Service Database:

CREATE TABLE subscriptions (
    id UUID PRIMARY KEY,
    subscription_id TEXT UNIQUE,  -- ✅ Has subscription
    redeemed BOOLEAN,
    version INTEGER
);

DIP Service Database:

CREATE TABLE assignments (
    id UUID PRIMARY KEY,
    blinded_token_hash TEXT UNIQUE,  -- ❌ No subscription ID!
    ip TEXT                           -- ✅ Has IP address
);

CREATE TABLE ip_pool (
    id UUID PRIMARY KEY,
    ip TEXT UNIQUE,
    status TEXT,
    reserved_until TIMESTAMPTZ
);

Notice something? No single table contains both subscription_id and ip. Even if an attacker dumps both databases, they can't link them because the blinded_token_hash is cryptographically one-way.

Performance: It's Actually Fast! ⚡

I was worried the cryptographic overhead would make this impractical, but the numbers are solid:

~97ms for complete assignment flow
52ms for RSA blind signature (the bottleneck)
<10ms for token generation in the enclave
1000+ assignments/second throughput
Sub-100ms p95 latency

For a VPN setup that happens once every few days, this is more than acceptable.

Security: What Could Go Wrong?

I spent a lot of time thinking about attack vectors:

✅ Database Breach

Attacker gets subscriptions OR IPs, never both
Cannot link past assignments

✅ Service Compromise

Compromising one service reveals partial info only
Blind signature properties prevent linkability

✅ Replay Attacks

Each signature is hashed and marked as used
Replays detected immediately

❌ Traffic Analysis

Network timing correlation is out of scope
This is an orthogonal problem requiring separate solutions

❌ Quantum Computers

RSA-2048 won't survive quantum computers
Future work: migrate to lattice-based blind signatures

Try It Yourself! 🚀

The entire project is open source. Here's how to run it:

# Clone the repo
git clone https://github.com/ChronoCoders/zero-knowledge-dip.git
cd zero-knowledge-dip

# Setup PostgreSQL
createdb zkdip

# Build everything
cargo build --release

# Run the services (in separate terminals)
cd crates/blind-token-service && cargo run --release
cd crates/enclave-sim && cargo run --release  
cd crates/dip-service && cargo run --release

# Test it!
cd crates/client && cargo run --release -- test

You should see output like:

🚀 Starting DIP Assignment Flow
✅ SRT generated
✅ Public key received
✅ Token blinded
✅ Blind signature received
✅ Signature unblinded
✅ Signature verified
✅ DIP assigned
🎉 Success!
DAT: eyJhbGc...

What I Learned

This project taught me a ton:

Blind signatures are criminally underused. They're perfect for so many use cases but rarely implemented in production systems.
Zero-knowledge is about architecture, not just crypto. The database schema and service separation are just as important as the cryptographic primitives.
Rust makes crypto safer. The type system caught so many potential bugs—invalid key sizes, incorrect modular arithmetic, lifetime issues with sensitive data.
Performance matters for adoption. If this took 5 seconds per assignment, nobody would use it. At 97ms, it's invisible to users.
Testing crypto is hard. I ended up writing 47 unit tests and 12 integration tests. Test coverage on the crypto library is 89%, and every edge case I could think of has a test.

What's Next?

Some ideas I'm exploring:

AWS Nitro Enclaves integration: Replace the enclave simulator with real hardware-backed isolation
Post-quantum crypto: Migrate to lattice-based blind signatures when they mature
IPv6 support: Expand the IP pool to billions of addresses
Anonymous payments: Integrate cryptocurrency for complete end-to-end anonymity
Formal verification: Prove the protocol properties mathematically

The Research Paper

I also wrote a full academic paper on this system (because why not?). It includes:

Formal security proofs
Threat model analysis
Performance benchmarks
Comparison with related work

You can read it in the docs/research directory.

Final Thoughts

Building a zero-knowledge system is like solving a puzzle where you're not allowed to look at the pieces. It's frustrating, mind-bending, and incredibly satisfying when it works.

The key insight is that privacy isn't about trust—it's about math. We shouldn't have to trust VPN providers not to log us. We should build systems where logging is cryptographically impossible.

This project proves that privacy and functionality don't have to be trade-offs. With careful protocol design and modern cryptography, we can have both.

If you're interested in privacy-preserving systems, cryptography, or just want to see how blind signatures work in practice, check out the GitHub repo. Issues and PRs welcome!

And if you build something cool with this, I'd love to hear about it. Hit me up in the comments or on GitHub.

Stay secure, stay private! 🔐

Useful Links

Tech Stack at a Glance

🦀 Rust 1.70+ (memory-safe systems programming)
🔐 RSA-2048 blind signatures (unlinkable authentication)
🔑 X25519 ECDH (key exchange)
🛡️ AES-256-GCM (authenticated encryption)
🎫 HMAC-SHA256 JWT (token validation)
🗄️ PostgreSQL 14+ (zero-knowledge schema)
⚡ Axum (async web framework)
🌐 WireGuard (VPN protocol)

P.S. - If you're wondering why I did this: partly because I'm a privacy nerd, partly because ExpressVPN's white paper was fascinating, and partly because I wanted an excuse to implement blind signatures in Rust. No regrets. 😄

P.P.S. - Yes, the research paper has proper citations, formal security proofs, and everything. I may have gotten slightly carried away. 📚

I Built NetPrune: A Rust Tool to Clean Up My 12,000+ LinkedIn Connections

Altug Tatlisu — Wed, 26 Nov 2025 23:29:10 +0000

How I used Rust to analyze and filter 12,613 LinkedIn connections, and what I learned about automation, ToS violations, and building developer tools

The Problem: 12,613 Connections and Counting

Let me tell you a story about accidentally collecting too many LinkedIn connections and deciding to do something about it.

I run a blockchain company, and over the years, I've been pretty liberal with LinkedIn connection requests. My thinking was simple: more connections equals more opportunities, right?

Wrong.

My feed became a mess. For every interesting blockchain developer or tech entrepreneur, I had 10 crypto scammers, NFT shillers, and completely unrelated professionals. Finding actual valuable content was like searching for a needle in a haystack.

I needed to clean house. But clicking through 7,000+ profiles manually? No thanks.

The Solution: Build It Myself

I'm a Rust developer, so naturally, my solution was to build a tool.

The plan was simple:

Export my LinkedIn connections as CSV
Filter them based on keywords (blockchain, Web3, Rust, and similar terms)
Automatically remove the irrelevant ones

Spoiler alert: Step 3 didn't go as planned. But let's start from the beginning.

Building NetPrune

Part 1: The Analysis Tool (This Actually Worked)

The first part was straightforward. LinkedIn lets you export your connections as a CSV file. I wrote a Rust parser to read it:

pub fn parse_csv(path: &str) -> Result<Vec<Connection>> {
    let mut reader = csv::Reader::from_path(path)?;
    let mut connections = Vec::new();

    for result in reader.deserialize() {
        let connection: Connection = result?;
        connections.push(connection);
    }

    Ok(connections)
}

Then I built a keyword-based filter. If someone's position or company contained terms like "blockchain," "crypto," or "Rust developer," they were marked as "relevant." Everyone else was "unwanted."

The Results:

Total connections: 12,613
Relevant connections (blockchain and tech): 5,101 (40.4%)
Unwanted connections: 7,512 (59.6%)
Ghost connections (deactivated accounts): 2,750

Holy crap. 60% of my network was noise.

Part 2: The Automation Attempt (This Did Not Work)

Here's where things got interesting. I thought I could use headless_chrome to automate the removals.

I spent hours:

Inspecting LinkedIn's DOM structure
Finding CSS selectors
Writing click automation code
Debugging why buttons wouldn't click

fn remove_single_connection(&self, tab: &Tab, profile_url: &str) -> Result<()> {
    tab.navigate_to(profile_url)?;

    // Click "More actions" button
    let more_button = tab.find_element("button[aria-label*='More actions']")?;
    more_button.click()?;

    // Click "Remove connection"
    let remove_button = tab.find_element("div[aria-label*='Remove connection']")?;
    remove_button.click()?;

    // Confirm removal
    let confirm_button = tab.find_element("button[data-test-dialog-primary-btn]")?;
    confirm_button.click()?;

    Ok(())
}

It opened the browser. It navigated to profiles. But the actual removal? Didn't work.

LinkedIn's DOM is a nightmare:

Class names change constantly
Menu items don't exist in the DOM until clicked
Elements disappear when you lose focus
Everything is dynamically rendered with Ember.js

But here's the real problem...

The Wake-Up Call: Terms of Service

I showed my progress to Claude (yes, I use AI assistants for code review), and it hit me with a reality check:

"LinkedIn's User Agreement explicitly prohibits automated access and scraping. Section 8.2 and 8.3. You could get banned."

Oh.

I looked it up. Claude was right. Even if I got the automation working perfectly, I would be:

Violating LinkedIn's Terms of Service
Risking account suspension
Teaching others to do the same

Not cool.

The Pivot: Analysis Tool Only

So I made a decision: NetPrune would be an analysis and filtering tool, not an automation tool.

The automation code is still there for educational purposes, but with prominent warnings everywhere:

Warning: Browser automation violates LinkedIn Terms of Service
Use this tool for ANALYSIS ONLY. Remove connections manually.

The recommended workflow became:

Use NetPrune to analyze your connections
Export the filtered CSV
Use LinkedIn's official bulk selection features
Remove connections manually (spread over days or weeks)

Is it slower? Yes. Is it legal and safe? Also yes.

What I Learned

Sometimes "Good Enough" Beats "Perfect"

My original plan was full automation. The final product is a CSV analysis tool with optional (but risky) automation. And you know what? The analysis part alone is incredibly valuable.

Read The Terms of Service

Seriously. I almost published a tool that could get users banned. Always check if what you're building violates platform policies.

Rust is Perfect for CLI Tools

Zero runtime dependencies, fast CSV parsing, great error handling with anyhow, and clap for CLI parsing made this project enjoyable to build.

Documentation Matters

I built:

A retro-punk styled landing page
GitHub Wiki with detailed guides
Comprehensive Rust documentation
Safety warnings everywhere

Good documentation turns a "cool hack" into a "useful tool."

The Final Product

NetPrune is now live:

Install it:

cargo install netprune

Use it:

netprune analyze --input Connections.csv
netprune export --input Connections.csv --output unwanted.csv

Should You Use It?

If you have thousands of LinkedIn connections and want to:

Analyze your network statistically
Filter by keywords or industries
Export lists for manual review

Then yes! NetPrune is safe, legal, and useful.

If you want to auto-remove 5,000 connections overnight? Please don't. LinkedIn will ban you, and I'll feel guilty.

What's Next?

I'm considering:

Better filtering algorithms (possibly ML-based scoring)
Web UI for easier connection review
Integration with other professional networks
Analytics dashboard

But for now, NetPrune does one thing well: helping you understand your network so you can make informed decisions about who to keep.

Have you ever had to clean up a massive social network? How did you approach it? Drop a comment below!

Post-script: Yes, I'm still manually removing those 7,000+ connections. It's tedious. Send help.

Links

Built with love and Rust by ChronoCoders

How we built Hermes - a military-grade encryption tool that's ready for the quantum computing era

Altug Tatlisu — Mon, 17 Nov 2025 20:02:27 +0000

The Problem That Kept Me Up at Night

Here's something that doesn't get talked about enough: your encrypted data today could be decrypted tomorrow.

It's called "harvest now, decrypt later" - adversaries are collecting encrypted communications right now, waiting for quantum computers powerful enough to break RSA and ECC. When that day comes (and cryptographers say it's not if, but when), all that data becomes readable.

That thought led me to build Hermes - a secure file transfer system that's designed to survive the quantum apocalypse.

What is Hermes?

Hermes is a command-line tool (and now web UI!) for secure file transfer that combines:

RSA-4096 (battle-tested classical encryption)
Kyber-1024 (NIST-selected post-quantum algorithm)
Dilithium-5 (post-quantum digital signatures)
AES-256-GCM (symmetric encryption)
Argon2 (memory-hard key derivation)

Think of it as GPG's paranoid cousin who's been reading too many quantum computing papers.

Why Rust?

Three words: memory safety matters.

When you're building cryptographic software, a single buffer overflow or use-after-free bug can compromise everything. Rust's ownership model eliminates entire classes of vulnerabilities at compile time.

Plus, Rust's ecosystem has excellent cryptography crates:

rsa for RSA operations
pqc_kyber for post-quantum key encapsulation
pqcrypto-dilithium for quantum-safe signatures
aes-gcm for authenticated encryption

No wrestling with OpenSSL bindings. No C memory management. Just safe, readable code.

The Architecture: Defense in Depth

Hybrid Encryption (Why Not Both?)

Here's our approach: we don't trust any single algorithm completely.

// Simplified hybrid encryption flow
pub fn encrypt_hybrid(plaintext: &[u8], recipients: Vec<String>) -> Result<Vec<u8>> {
    // 1. Generate random AES key
    let aes_key = generate_random_key();

    // 2. Encrypt data with AES-256-GCM
    let ciphertext = aes_gcm_encrypt(plaintext, &aes_key)?;

    // 3. For each recipient, encrypt AES key with BOTH:
    //    - RSA-4096 (classical security)
    //    - Kyber-1024 (quantum security)
    let mut encrypted_keys = Vec::new();
    for recipient in recipients {
        let rsa_encrypted = rsa_encrypt(&aes_key, &recipient.rsa_pubkey)?;
        let kyber_encrypted = kyber_encapsulate(&aes_key, &recipient.kyber_pubkey)?;
        encrypted_keys.push((rsa_encrypted, kyber_encrypted));
    }

    // 4. Package it all together
    Ok(package_encrypted_data(ciphertext, encrypted_keys))
}

If RSA gets broken? Kyber has your back.
If Kyber has an undiscovered flaw? RSA is still there.

This is what cryptographers call "hybrid mode" - and it's exactly what NIST recommends for the transition period.

Multi-Recipient Encryption

One of my favorite features: encrypt once, share with many.

# Encrypt for multiple recipients
hermes send-file classified.pdf --recipients alice,bob,charlie --pqc

# Each recipient decrypts with their own key
hermes recv-file classified.pdf.hrms --recipient alice

The magic? We encrypt the symmetric key separately for each recipient. The actual file is only encrypted once (efficient!), but each person gets their own "key wrapper" they can open with their private key.

Features That Make Me Proud

1. Steganography Support

Sometimes encryption isn't enough. Sometimes you need plausible deniability.

# Hide encrypted data inside an innocent photo
hermes stego-hide secrets.txt --cover vacation.png --output vacation_final.png -p mypassword

We use LSB (Least Significant Bit) steganography - modifying the least important bits of image pixels. The changes are invisible to the human eye, but we can store about 3 bytes of data per 8 pixels.

It's like writing in invisible ink, except the ink is math.

2. Key Rotation with Archiving

Security isn't a one-time setup. Keys should be rotated regularly.

# Rotate keys, archive the old ones
hermes key-rotate alice --archive --pqc --sign

This generates fresh keys while preserving the old ones (timestamped in ~/.hermes/keys/archive/). You can still decrypt old files, but new communications use new keys.

The metadata tracks everything:

Last rotated: 2025-11-17T02:15:13Z
RSA fingerprint: f8faa12aab60b171

3. Shamir's Secret Sharing

What if your private key is so sensitive that no single person should have it?

# Split key into 5 shares, require any 3 to recover
hermes key-split alice --threshold 3 --shares 5

This uses GF(256) polynomial interpolation - the same math that protects Bitcoin multisig wallets. Three executives each get a share. Need to decrypt critical files? Get three of them in a room.

No single point of failure. Beautiful.

4. Web UI (New in v2.4.0!)

Not everyone loves the command line. So we built a web interface:

hermes web-ui --port 8080

Open http://localhost:8080 and you get:

Key generation and management
Drag-and-drop file encryption
Digital signature creation/verification
Real-time status monitoring

The frontend is a single embedded HTML file (~900 lines of vanilla JS) that talks to an Axum-powered REST API. No npm, no webpack, no React - just fast, minimal dependencies.

The Hard Parts (Lessons Learned)

Unicode Box Drawing Characters

Sounds trivial, right? Wrong.

// This looks innocent...
let header = format!("─[HERMES]─[{title}]─");
let padding = "─".repeat(INNER_WIDTH - header.len());

Bug: header.len() returns bytes, not characters. That "─" character is 3 bytes in UTF-8. Our box borders were misaligned for days.

Fix:

let header_char_len = header.chars().count();  // Characters, not bytes!

Rust catches many bugs at compile time. This wasn't one of them.

ANSI Color Codes in Terminal Width Calculations

When you colorize terminal output, you add invisible escape sequences:

\x1b[36m│\x1b[0m This looks like 2 chars, but it's actually 11 bytes

We had to write a helper to strip ANSI codes before calculating padding:

fn strip_ansi_codes(s: &str) -> String {
    let mut result = String::new();
    let mut in_escape = false;

    for c in s.chars() {
        if c == '\x1b' {
            in_escape = true;
        } else if in_escape && c == 'm' {
            in_escape = false;
        } else if !in_escape {
            result.push(c);
        }
    }
    result
}

Post-Quantum Key Sizes

Kyber public keys are about 1,568 bytes. Dilithium public keys? 2,592 bytes. RSA-4096 public keys are around 550 bytes.

Suddenly your encrypted packages are much bigger. Worth it for quantum security? Absolutely. But it required redesigning our package format and increasing size limits across the board.

The Package Format (v0x02)

Every encrypted file follows this structure:

[MAGIC: 4 bytes]    "HRMS"
[VERSION: 1 byte]   0x02
[FLAGS: 1 byte]     bit 2 = PQC enabled
[SALT: 16 bytes]    For key derivation
[NONCE: 12 bytes]   For AES-GCM
[RECIPIENT_COUNT]   How many can decrypt
[RECIPIENT_DATA]    Encrypted keys per recipient
[CIPHERTEXT]        The actual encrypted data
[TAG: 16 bytes]     Authentication tag

Everything is versioned. We can add features without breaking old files.

Performance Numbers

On my machine (Ryzen 9 5950X):

Key Generation (RSA-4096 + Kyber + Dilithium): ~3 seconds
File Encryption (1MB, password-based): ~50ms
Hybrid Encryption (1MB, 3 recipients, PQC): ~200ms
Steganography Embed (1KB in 1080p image): ~100ms

Not bad for paranoia-level security.

What's Next?

Ideas brewing for future versions:

Hardware Security Module (HSM) support - Keep private keys in secure hardware
Tor integration - Anonymous file drops
Mobile apps - Because security shouldn't require a laptop
Audit logging - Cryptographic proof of who decrypted what, when
Zero-knowledge proofs - Prove you have access without revealing the key

Try It Yourself

# Clone the repo
git clone https://github.com/ChronoCoders/hermes.git
cd hermes

# Build it
cargo build --release

# Generate your first quantum-safe keypair
./target/release/hermes keygen mykey --pqc --sign

# Encrypt a message
echo "Hello, quantum-safe world!" | ./target/release/hermes send-msg -p secretpassword

# Start the web UI
./target/release/hermes web-ui

The full source is on GitHub with extensive documentation, release notes for each version, and a detailed changelog.

Final Thoughts

Building Hermes taught me that security is never "done." It's layers upon layers of defense, constant vigilance, and planning for threats that don't exist yet.

Is Hermes perfect? No. Will quantum computers break everything tomorrow? Probably not. But when they do arrive, and they will, having tools that are ready feels like the responsible thing to do.

The best time to prepare for quantum computing was yesterday. The second best time is now.

Hermes is open-source and MIT licensed. Star it on GitHub, report issues, contribute features. Let's make secure communication accessible to everyone.

Tech Stack: Rust, Axum, Tokio, CRYSTALS-Kyber, CRYSTALS-Dilithium, RSA, AES-256-GCM, Argon2

Current Version: 2.4.0

What security challenges are you tackling? Have you started thinking about post-quantum cryptography? Drop a comment below - I'd love to hear your thoughts!

How I Fell Down the Rabbit Hole of Dots and Dashes

Altug Tatlisu — Fri, 07 Nov 2025 23:42:01 +0000

The Spark

You know that feeling when you stumble upon an old telegraph machine in a museum and think, "Man, that's cool... but what if it had RGB lighting?"

Okay, maybe that's just me.

But seriously, I've always been fascinated by Morse code. There's something beautifully elegant about reducing human language to just two elements: a dot and a dash. It's like the ultimate compression algorithm, invented in 1836, way before we even had computers.

So I decided to build MorseWave - a modern Morse code encoder/decoder that looks like it fell through a time portal from a cyberpunk 1980s.

Why Rust? Why WebAssembly?

Short answer: Because JavaScript alone felt too... slow for something this nerdy.

Long answer: I wanted this thing to be fast. Like, encode-a-novel-in-under-a-millisecond fast. Rust gives you that near-metal performance while keeping you from shooting yourself in the foot with memory bugs. Plus, compiling to WebAssembly means I can run this speed demon directly in the browser.

The best part? No npm package hell. No framework drama. Just pure, unadulterated performance.

The Tech Stack (Or: My Toolbox of Awesome)

Here's what I threw into this digital blender:

Rust - For the core logic (because speed matters)
WebAssembly - To bring that Rust goodness to the browser
Web Audio API - For those authentic 800Hz beeps
Canvas API - To draw some sick waveforms
Vanilla JavaScript - Yes, really. No React. No Vue. Fight me.
CSS3 - For that sweet CRT monitor aesthetic

The Fun Parts

1. The Encoding Algorithm

At its core, Morse code is just a giant lookup table. 'A' becomes '.-', 'B' becomes '-...', and so on. Simple, right?

pub fn encode(&self, text: &str) -> String {
    text.to_uppercase()
        .chars()
        .filter_map(|ch| self.encode_map.get(&ch))
        .map(|s| s.to_string())
        .collect::<Vec<_>>()
        .join(" ")
}

This beauty converts your text to uppercase, looks up each character in a HashMap, and joins them with spaces. Runs in O(n) time. Chef's kiss 👨‍🍳

2. Audio Synthesis (AKA Making Bleeps)

Turns out, making a computer go "beep" is surprisingly involved. The Web Audio API is powerful but... quirky.

let oscillator = self.context.create_oscillator()?;
oscillator.set_type(OscillatorType::Sine);
oscillator.frequency().set_value(800.0); // Sweet spot for Morse

That 800Hz frequency? That's the traditional Morse code tone. I tried other frequencies. 600Hz sounded too mellow. 1000Hz was too harsh. 800Hz is the Goldilocks zone.

3. The Retro UI

Here's where I went full nostalgia mode. I wanted it to look like a terminal from WarGames or TRON.

Scanlines? Check. ✓
Phosphor green glow? Double check. ✓✓
CRT screen curvature? Okay, I didn't go that far, but the vignette effect is pretty sick.

.scanlines {
    background: linear-gradient(
        to bottom,
        transparent 50%,
        rgba(0, 0, 0, 0.1) 50%
    );
    animation: scan 8s linear infinite;
}

The scanline animation literally scans across your screen. It's completely unnecessary. It's absolutely essential.

The Challenges (Or: What Made Me Question My Life Choices)

WASM + Web Audio = 😅

Getting Rust to play nice with the Web Audio API through WASM bindings was... an adventure. The web-sys crate is amazing, but the type system is strict. Like, "I-will-fight-you-over-a-semicolon" strict.

I spent two hours debugging why audio wasn't playing. The issue? I forgot to call start_with_when() on the oscillator. Two. Hours.

Timing is Everything

Morse code has specific timing rules:

Dot = 1 unit
Dash = 3 units
Space between elements = 1 unit
Space between letters = 3 units
Space between words = 7 units

Getting these timings right while accounting for JavaScript's event loop and audio context timing was like conducting an orchestra while juggling chainsaws.

The "Wait, How Do I Actually Test This?" Moment

Unit testing is great until you realize you're testing... Morse code. How do you verify that your audio playback is correct? Listen to it 500 times?

I ended up creating test cases like:

#[test]
fn test_sos() {
    let codec = MorseCodec::new();
    assert_eq!(codec.encode("SOS"), "... --- ...");
}

Simple. Effective. Saved my sanity.

The Cool Features You Didn't Know You Needed

Manual Telegraph Mode

You can literally tap out Morse code like an old-timey telegraph operator. Press . for dot, - for dash. It's weirdly satisfying. I may have spent 20 minutes just tapping out random messages.

Speed Control

Adjustable from 5 WPM (Words Per Minute) to 40 WPM. Beginners start slow. Pros can go full speed demon. I can barely handle 15 WPM before my brain melts.

Transmission History

Every message you encode gets saved with a timestamp. Why? Because I wanted to see my Morse code journey. It's like a diary, but nerdier.

What I Learned

Rust is amazing - Once you get past the learning curve, it's like programming with guardrails made of titanium.
WebAssembly is the future - Seriously. Near-native performance in the browser? Sign me up.
Retro aesthetics never die - People love that CRT look. Nostalgia is a powerful drug.
Documentation matters - I wrote comprehensive docs because future-me (and other developers) will thank past-me.
Sometimes simple is better - No framework. No build tools beyond wasm-pack. Just pure web technologies working together.

Performance Numbers (Because We're Developers and We Love Benchmarks)

Encoding/Decoding: <1ms for typical messages
WASM bundle size: ~50KB (gzipped)
Initial load time: <100ms
Memory usage: <10MB
Audio latency: <50ms

Not bad for a weekend project that turned into a week-long obsession.

Try It Yourself

The whole thing is open source and live:

🌐 Live Demo: chronocoders.github.io/morsewave
📦 Crates.io: crates.io/crates/morsewave
💻 GitHub: github.com/ChronoCoders/morsewave

Want to add it to your Rust project?

[dependencies]
morsewave = "0.1.0"

What's Next?

Ideas I'm toying with:

WebRTC integration - Real-time Morse code chat, anyone?
Mobile apps - Morse on the go
Game mode - Learn Morse code through challenges
Custom themes - Not everyone wants phosphor green (heathens)

Final Thoughts

Building MorseWave taught me that sometimes the best projects are the ones that make you smile. Yeah, it's a niche tool. Yeah, most people will never use Morse code in real life. But it's fun. It's nostalgic. And it works beautifully.

Plus, now I can tap out "SEND PIZZA" in Morse code when I'm debugging at 3 AM. That's worth something, right?

If you build something with it, or just think it's cool, drop a star on GitHub. And if you find any bugs... well, that's what the issues tab is for. 😄

Built with ❤️, Rust, and an unhealthy amount of caffeine

Comments? Questions? Morse Code Messages?

Drop them below! I'd love to hear what you think or what features you'd like to see.

And if you're wondering: yes, I can now actually read Morse code. Slowly. Very slowly. But I'm getting there!

P.S. - The first person to send me a valid pull request written entirely in Morse code comments gets eternal glory. And probably a mention in the README.

Building cargo-sane: A Better Way to Manage Rust Dependencies

Altug Tatlisu — Sun, 26 Oct 2025 03:05:13 +0000

Have you ever spent hours manually updating dependencies in your Cargo.toml? Copying version numbers from crates.io, wondering which updates are safe, and hoping nothing breaks?

Yeah, me too. That's why I built cargo-sane.

🤔 The Problem

Managing Rust dependencies is tedious:

You need to check crates.io for each dependency manually
You don't know which updates are safe (patch? minor? major?)
Version conflicts are confusing
One wrong update can break your entire build
There's no easy way to preview changes

There had to be a better way.

💡 The Solution

I wanted a tool that would:

✅ Automatically check all dependencies for updates
✅ Categorize updates by risk level
✅ Let me choose which ones to update
✅ Make backups automatically
✅ Preserve my carefully crafted Cargo.toml formatting

So I built cargo-sane.

🚀 What It Does

Smart Dependency Analysis

cargo sane check

This scans your Cargo.toml, hits the crates.io API, and shows you exactly what's available:

🧠 cargo-sane check

📊 Update Summary:
  ✅ Up to date: 3
  🟢 Patch updates available: 5
  🟡 Minor updates available: 2
  🔴 Major updates available: 1

🟢 Patch updates:
  • serde 1.0.195 → 1.0.228
  • anyhow 1.0.89 → 1.0.100

🟡 Minor updates:
  • tokio 1.35.0 → 1.47.2

🔴 Major updates:
  • colored 2.1.0 → 3.0.0

Color-coded by risk:

🟢 Green = Patch updates (bug fixes, likely safe)
🟡 Yellow = Minor updates (new features, should be safe)
🔴 Red = Major updates (breaking changes, be careful!)

Interactive Updates

cargo sane update

This opens a beautiful TUI where you can:

Select which dependencies to update (spacebar to toggle)
See exactly what will change
Preview before applying

And it:

Creates automatic backups (Cargo.toml.backup)
Preserves your formatting and comments
Works with all Cargo.toml formats

# Simple format
serde = "1.0"

# Detailed format with features
tokio = { version = "1.35", features = ["full"] }

# Optional dependencies
clap = { version = "4.5", optional = true }

# Comments are preserved!
regex = "1.11"  # For pattern matching

🛠️ How I Built It

Tech Stack

Language: Rust (obviously!)
CLI Framework: clap for argument parsing
HTTP Client: reqwest for crates.io API
Version Parsing: semver
TUI: dialoguer for interactive prompts
Pretty Output: colored + indicatif

Key Challenges

1. Parsing Cargo.toml

Cargo.toml has many formats:

serde = "1.0"
tokio = { version = "1.35", features = ["full"] }
clap = { version = "4.5", optional = true }

I used the toml crate to parse, then created a custom Manifest struct to handle all variants.

2. Updating While Preserving Format

The tricky part: updating versions WITHOUT destroying formatting and comments.

Solution: Use regex to find and replace only the version string:

let pattern = format!(
    r#"(?m)^(\s*{}\s*=\s*\{{\s*version\s*=\s*")([^"]+)(")"#,
    regex::escape(dep_name)
);

let new_content = re.replace(&content, |caps: &regex::Captures| {
    format!("{}{}{}", &caps[1], new_version, &caps[3])
});

This preserves everything except the version number itself.

3. Concurrent API Calls

Checking 50+ dependencies one-by-one would be slow. Solution: concurrent requests with progress bars:

use indicatif::ProgressBar;

let pb = ProgressBar::new(deps.len() as u64);

for (name, spec) in deps {
    pb.set_message(format!("Checking {}", name));
    // Fetch from crates.io API
    pb.inc(1);
}

📊 Results

After publishing to crates.io, the response has been amazing:

Published just hours ago
Already seeing downloads
Great feedback on design and UX
Ideas for new features flooding in

🎯 What's Next

Future features I'm planning:

Conflict Resolution: Automatically fix version conflicts
Security Scanning: RustSec integration for vulnerability checks
Unused Dependencies: Detect and remove unused crates
Workspace Support: Handle multi-crate workspaces
CI/CD Integration: GitHub Actions support

🚀 Try It Yourself

cargo install cargo-sane

cd your-rust-project
cargo sane check
cargo sane update

Links:

📦 Crates.io
💻 GitHub

💭 Lessons Learned

Building cargo-sane taught me:

Good UX matters in CLI tools - Color coding and progress bars make a huge difference
Start simple - MVP first, then iterate based on feedback
Preserve user data - Automatic backups = peace of mind
Documentation is crucial - Good README = more users
Community feedback is gold - Listen to your users

🤝 Want to Contribute?

cargo-sane is open source! PRs welcome:

🐛 Found a bug? Open an issue
💡 Have an idea? Let's discuss it
🔧 Want to contribute? Fork and PR

What do you think? Would you use cargo-sane? What features would you want to see?

Drop a comment below! 👇

Made with ❤️ by Rust developers, for Rust developers.