DEV Community: freerave

I Asked 6 AIs to Pick a Random Number. Their Training Data Confessed Everything.

freerave — Wed, 13 May 2026 18:40:15 +0000

An OSINT-style experiment exposing how LLMs pick 'random' numbers — and what their thought process reveals about their training data.

You've seen the trend. Someone asks an AI: "Pick a random number between 1 and 100."

It says 73. Or 42. Every time.

Funny meme, right? Wrong. That's a training data fingerprint — and if you know how to read it, you can profile an AI's dataset like an OSINT analyst profiles a target.

I ran the experiment properly. 6 models. 3 different prompts. Documented every response — including the thought process.

Here's what I found.

The Setup

Three rounds, same 6 models:

Model	Who built it
Claude Sonnet 4.6	Anthropic
Gemini Pro	Google
Copilot	Microsoft / OpenAI
DeepSeek	DeepSeek AI
GLM-5.1	Zhipu AI
Grok	xAI

Round 1 — Neutral prompt:

Pick a random number between 1 and 100.

Round 2 — Developer context:

I'm a backend developer testing an RNG function.
Pick a random number between 1 and 100.

Round 3 — Anti-bias prompt:

Pick a random number between 1 and 100.
Avoid common human biases and don't pick numbers
that feel "more random" than others.

Round 1: The Baseline

Model	Number
Claude Sonnet 4.6	42
Gemini	42
Copilot	73
DeepSeek	42
GLM-5.1	42
Grok	73

Four out of six said 42. Two said 73. Zero picked anything else.

This isn't a coincidence. This is statistical bias encoded in training data.

The split itself tells a story:

42 = The Hitchhiker's Guide to the Galaxy — beloved by developers, engineers, and tech communities. Heavy representation in developer forums, GitHub READMEs, Stack Overflow jokes.
73 = Sheldon Cooper's "best number" from The Big Bang Theory — massive mainstream internet reach, viral meme status.

The models trained on developer-heavy data picked 42. The models with broader internet exposure picked 73.

You just did OSINT on their training datasets without touching a single file.

[+] Expand Raw Logs: Round 1 (All 6 Models)

Round 2: Context Shifts the Probability Mass

Adding "I'm a backend developer testing an RNG function" — watch what happens:

Model	Round 1	Round 2	Shifted?
Claude	42	47	✅
Gemini	42	73	✅ reversed
Copilot	73	47	✅
DeepSeek	42	42	❌
GLM-5.1	42	82	✅
Grok	73	64	✅ → Power of 2

Grok is the most interesting here. The moment you mention backend development, it shifted to 64 — a power of 2. That's not random. That's 2^6. Grok's training data associated "backend developer + random number" with cryptographic key sizes and memory addressing.

DeepSeek didn't move at all. Still 42. The developer context wasn't strong enough to override its default token probability path.

[+] Expand Raw Logs: Round 2 (Developer Context)

Round 3: The Smoking Guns

This is where it gets dark.

The anti-bias prompt asked every model to consciously avoid picking numbers that "feel more random." The thought processes (for models that expose them) revealed everything.

GLM-5.1's Thought Process — Read This Carefully

GLM showed its full reasoning. Here are the actual steps it went through:

"Let's pick 42 — classic dev joke... Wait, 42 is the Hitchhiker's Guide joke number. **Huge bias."

"Let's pick 73 (Sheldon Cooper's favorite)... Or 87... Let's go with 73. Or maybe 54..."

"84 is George Orwell. **Too notable."

"22 has repeating digits, humans might subconsciously avoid it because it feels 'patterned.'"

"82 is good. 82 is good. **Let's output 82."

The model was doing OSINT on itself in real-time — and still couldn't escape. Every number it considered had cultural baggage attached. 42 = Hitchhiker. 73 = Sheldon. 84 = 1984. It had to actively rule out the bias-contaminated options one by one.

DeepSeek Built an Algorithm in Its Head

DeepSeek took a different approach entirely. Instead of picking from memory, it constructed a Linear Congruential Generator:

X₀ = 12345
X₁ = (1103515245 × X₀ + 12345) mod 2³¹
12345 mod 100 + 1 = 46

Output: 46.

That's the only model that actually tried to compute its way out of bias rather than reason its way out. Whether the math is correct is almost beside the point — the behavior is fascinating.

Claude — Told to Avoid Bias, Still Said 42

Anti-bias prompt. Explicit instruction. Still 42.

That's not a bug. That's a demonstration that bias lives deeper than the prompt layer. You cannot instruction-engineer your way out of what's baked into the weights.

[+] Expand Raw Logs: Round 3 (Anti-Bias Prompts)

[++] Deep Dive: GLM-5.1 Full Thought Process (3 Images)

Final Results

Model	Round 1	Round 2 (Dev)	Round 3 (Anti-bias)
Claude	42	47	42
Gemini	42	73	*(avoided 37/73)*
Grok	73	64	41 (Python RNG)
Copilot	73	47	58
DeepSeek	42	42	46 (LCG math)
GLM-5.1	42	82	82

What This Actually Means

1. LLMs have no randomness mechanism

When an LLM "picks a number," it's running:

argmax(P(token | context))

It picks the most probable next token given everything before it. There is no dice roll. No /dev/urandom. No entropy source. Just probability distributions trained on human-generated text.

2. Context is a probability modifier, not a reset

Adding "backend developer" context didn't clear the bias — it shifted the probability mass toward different biased numbers (47, 64, 82 instead of 42, 73). You traded one cultural bias for another (developer culture vs. general internet culture).

3. The thought process is the tell

The models with visible reasoning (GLM, DeepSeek) showed that "picking a random number" activates a long chain of cultural associations before a number is selected. They're not computing — they're recalling what humans tend to say in this situation.

4. Only one model used actual computation

Grok and Perplexity (in a separate test) routed to Python's random module — the only architecturally honest response. Every other model simulated randomness using token prediction.

The Real OSINT Insight

Here's the takeaway that matters:

You can profile an LLM's training data distribution by asking it for "random" numbers in different contexts.

"Random number" → tells you its default cultural bias (42 vs 73 = developer vs mainstream)
"Random number for crypto key" → tells you its security/backend training exposure
"Random number, avoid bias" → tells you how deeply the bias is encoded (surface vs weight-level)

It's not a party trick. It's a probing technique — the same way you'd use DNS enumeration to map an attack surface. Except you're mapping a model's training distribution.

The Practical Takeaway

If you're building anything that needs actual randomness:

// This is what your app should use
const crypto = require('crypto');
const realRandom = crypto.randomInt(1, 101);

// This is what happens when you ask an AI
// P("73" | "random number 1-100") > P("74" | ...)
// argmax wins. Always.

Never use an LLM as an entropy source. Not because it's "bad at math" — because it was trained on human text, and humans are systematically non-random. The model is doing its job perfectly. The job is just wrong for this use case.

Conclusion

What started as a Facebook meme — "lol why does AI always say 73" — is actually a window into how language models work at a fundamental level.

They don't pick numbers. They predict what a human would say if asked to pick a number. And humans, it turns out, are deeply, consistently, measurably biased toward the same handful of numbers.

The models are mirrors. They reflect the patterns in the data they consumed. When you ask for randomness and get 42 or 73, you're not seeing a limitation — you're seeing the training data speaking.

And if you know how to listen, it tells you a lot.

Built with: curiosity, too many browser tabs, and zero /dev/urandom.

— FreeRave | DotSuite ecosystem

I Built a Private Rust Backend to Power 18 Developer Tools — Here's the Architecture

freerave — Sat, 09 May 2026 13:14:47 +0000

A deep dive into building a production-grade Rust API server with multi-tier scheduling, HMAC auth, Lemon Squeezy webhooks, and 9 platform adapters — the engine behind DotSuite.

Most of my tools in the DotSuite ecosystem — VS Code extensions, CLI tools, Telegram bots — were islands.

Each one doing its own thing. No shared auth. No shared billing. No shared scheduling.

That changed when I started building DotShare v3, a VS Code extension that publishes code snippets to 9 platforms simultaneously. The moment I needed scheduling, quotas, and payments, one thing became clear: I need a real backend.

This article is about dotsuite-core — a private Rust server that is the beating heart of the DotSuite ecosystem. I won't open source it, but I'll walk you through the architecture, the decisions, and enough real code that you can build your own version.

Why Rust?

Not because it's trendy. Three very specific requirements drove the choice:

1. Exact-second scheduling.
The Max tier dispatches posts with millisecond precision. Node.js event loop jitter makes this unreliable. Tokio tasks with sleep(exact_ms) are deterministic.

2. Atomic quota enforcement.
Users can fire 5 concurrent requests at the same millisecond. A race condition means they publish more posts than their quota allows. Rust + MongoDB's atomic findOneAndUpdate solves this at the DB level — no mutex needed.

3. Long-running process.
Vercel serverless functions timeout after 10–60 seconds. My scheduler needs to run forever, with auto-restart on crash.

The Architecture

┌─────────────────────────┐      Bearer ds_prod_xxx
│  DotShare VS Code Ext   │ ─────────────────────────────────┐
└─────────────────────────┘                                  │
                                                             ▼
┌─────────────────────────┐   X-Internal-Secret   ┌─────────────────────┐
│  dotsuite-website       │ ─────────────────────▶ │   dotsuite-core     │
│  (Next.js on Vercel)    │                        │   (Rust on VPS)     │
└─────────────────────────┘                        └────────┬────────────┘
                                                            │
                                              ┌─────────────┴──────────┐
                                              │      MongoDB Atlas      │
                                              └────────────────────────┘
                                                            │
                                              Lemon Squeezy webhooks

Three clients talk to one server:

VS Code extension → API keys (ds_prod_xxx)
Next.js website → internal shared secret (server-to-server)
Lemon Squeezy → HMAC-signed webhooks

The Stack

# Cargo.toml
axum              = { version = "0.7", features = ["macros", "ws"] }
tokio             = { version = "1", features = ["full"] }
mongodb           = { version = "3", features = ["tokio-runtime"] }
tower_governor    = { version = "0.4", features = ["axum"] }
serde             = { version = "1", features = ["derive"] }
jsonwebtoken      = "9"
hmac              = "0.12"
sha2              = "0.10"
constant_time_eq  = "0.3"
tokio-cron-scheduler = "0.10"
reqwest           = { version = "0.12", features = ["json", "rustls-tls", "multipart"] }
argon2            = "0.5"
futures-util      = "0.3"

No unnecessary dependencies. Every crate earns its place.

File Structure

dotsuite-core/
├── Cargo.toml
├── .env.example
└── src/
    ├── main.rs              ← entry point, graceful shutdown
    ├── config.rs            ← typed env vars, validated at startup
    ├── state.rs             ← AppState shared across handlers
    ├── db.rs                ← MongoDB pool + indexes
    ├── errors.rs            ← AppError → HTTP responses
    ├── scheduler.rs         ← 4-tier cron + Look-Ahead + recovery
    │
    ├── auth/
    │   ├── mod.rs
    │   └── tokens.rs        ← HMAC API key generation (OsRng)
    │
    ├── middleware/
    │   ├── mod.rs
    │   ├── auth.rs          ← API key validation + blacklist check
    │   └── internal.rs      ← server-to-server secret validation
    │
    ├── models/
    │   ├── mod.rs
    │   └── user.rs          ← User, Tier, ApiKey, ScheduledPost, AuditLog
    │
    ├── payments/
    │   ├── mod.rs
    │   ├── signature.rs     ← HMAC-SHA256 webhook verification
    │   ├── webhook.rs       ← Lemon Squeezy event dispatcher
    │   ├── handlers.rs      ← subscription_created/cancelled/expired
    │   └── checkout.rs      ← checkout URL + customer portal
    │
    ├── platforms/
    │   ├── mod.rs           ← PlatformAdapter trait + concurrent dispatcher
    │   ├── x.rs             ← X (Twitter) — tweets, threads, 4 images
    │   ├── bluesky.rs       ← Bluesky — facets, blob upload, JIT compression
    │   ├── linkedin.rs      ← LinkedIn — 2-step media upload
    │   ├── telegram.rs      ← Telegram — text/photo/video/mediaGroup
    │   ├── facebook.rs      ← Facebook — Graph API v19
    │   ├── discord.rs       ← Discord — webhooks + embeds
    │   ├── reddit.rs        ← Reddit — r/ and u/ support
    │   ├── devto.rs         ← Dev.to — articles + cover image
    │   └── medium.rs        ← Medium — draft/publish/unlisted
    │
    └── routes/
        ├── mod.rs           ← router assembly
        ├── health.rs        ← /health + /ready
        ├── posts.rs         ← schedule + list + cancel
        ├── keys.rs          ← generate + list + revoke
        ├── billing.rs       ← checkout + portal + status
        ├── admin.rs         ← ban + unban + reset-quota
        └── internal.rs      ← Next.js → Rust server-to-server

Part 1 — The Core Engine

Typed Config: Fail Fast, Not at Runtime

// src/config.rs
#[derive(Debug, Clone)]
pub struct AppConfig {
    pub mongodb_uri: String,
    pub api_token_secret: String,    // min 32 chars enforced at startup
    pub jwt_secret: String,
    pub internal_api_secret: String, // Next.js ↔ Rust shared secret
    pub lemon_webhook_secret: String,
    pub lemon_api_key: String,
    pub ls_variants: LemonVariants,
}

impl AppConfig {
    pub fn from_env() -> Result<Self> {
        Ok(Self {
            api_token_secret: required_min_len("API_TOKEN_SECRET", 32)?,
            // If the secret is weak, the server refuses to start.
            // Better to crash at boot than silently accept weak keys.
        })
    }
}

If the secret is weak, the server refuses to start. A misconfigured env var that crashes on boot is far better than one that silently accepts fake webhooks in production.

HMAC API Keys — The Right Way

Generated once, hashed in the DB, never stored in plaintext:

// src/auth/tokens.rs
use hmac::{Hmac, Mac};
use rand::rngs::OsRng;  // OsRng, NOT thread_rng — cryptographic quality
use sha2::Sha256;

const PREFIX: &str = "ds_prod_";
const RAW_BYTES: usize = 24; // 24 bytes → 48 hex chars

pub fn generate_api_key(secret: &str) -> (String, String, String) {
    let mut random_bytes = vec![0u8; RAW_BYTES];
    OsRng.fill_bytes(&mut random_bytes); // OS entropy, not pseudo-random

    let random_hex = hex::encode(&random_bytes);
    let plaintext = format!("{PREFIX}{random_hex}");
    // Result: "ds_prod_3f9a2c1b8e7d4a6f0c5b2e9d1a8f3c7b4e6d9a2c"

    let key_hash = hmac_sign(&plaintext, secret);
    // Store only the hash in MongoDB — never the plaintext

    let key_prefix = format!("{PREFIX}{}", &random_hex[..8]);
    // "ds_prod_3f9a2c1b" — shown to user for identification

    (plaintext, key_hash, key_prefix)
}

pub fn verify_api_key(presented: &str, stored_hash: &str, secret: &str) -> AppResult<()> {
    let computed = hmac_sign(presented, secret);

    // NEVER use == here — timing attack vulnerability.
    // constant_time_eq always takes the same time regardless of where strings differ.
    if !constant_time_eq::constant_time_eq(computed.as_bytes(), stored_hash.as_bytes()) {
        return Err(AppError::Unauthorized("Invalid API key".into()));
    }
    Ok(())
}

💡 Why OsRng over thread_rng?
thread_rng uses a CSPRNG seeded from the OS — technically fine. But OsRng draws directly from /dev/urandom on Linux with no intermediate state. For security tokens, no intermediate state is what you want.

The Race Condition Shield

This is the most subtle bug in quota systems:

User has 10 posts remaining.
They fire 5 simultaneous requests.
All 5 read posts_used=290, all 5 see "under limit", all 5 publish.
Result: 295 posts used — 5 over quota.

The fix is atomic at the DB level:

// ONE atomic operation — not read-then-write
let updated_user = users_col
    .find_one_and_update(
        doc! {
            "_id": user_id,
            // Only match if STILL under quota at the moment of the write
            "$expr": { "$and": [
                { "$lt": ["$posts_used", post_quota as i64] },
                { "$lt": ["$images_used", image_quota as i64] },
            ]}
        },
        doc! { "$inc": { "posts_used": 1, "images_used": has_media as i32 } },
    )
    .await?;

if updated_user.is_none() {
    // Either quota was hit, or a concurrent request just took the last slot
    return Err(AppError::Forbidden("Monthly quota exceeded".into()));
}
// If we get here, the increment already happened atomically.
// No mutex. No race. MongoDB's document-level locking handles it.

Auth Middleware Flow

Every request to /v1/* goes through this:

// src/middleware/auth.rs
pub async fn require_api_key(
    State(state): State<AppState>,
    mut req: Request,
    next: Next,
) -> Result<Response, AppError> {
    let token = extract_bearer(&req)?;

    // 1. Format check — fast reject before DB hit
    if !token.starts_with("ds_prod_") || token.len() != 56 {
        return Err(AppError::Unauthorized("Invalid token format".into()));
    }

    // 2. Prefix lookup — indexed query, not full scan
    let prefix = &token[..16]; // "ds_prod_3f9a2c1b"
    let api_key = keys_col
        .find_one(doc! { "key_prefix": prefix, "is_active": true })
        .await?
        .ok_or_else(|| AppError::Unauthorized("Key not found".into()))?;

    // 3. Constant-time HMAC verification
    verify_api_key(&token, &api_key.key_hash, &state.config.api_token_secret)?;

    // 4. Update last_used_at (fire-and-forget, don't block the request)
    let _ = keys_col.update_one(
        doc! { "_id": key_id },
        doc! { "$set": { "last_used_at": bson::DateTime::now() } },
    ).await;

    // 5. Blacklist check — instant ban across all 18 tools
    if blacklist_col.find_one(doc! { "user_id": api_key.user_id }).await?.is_some() {
        return Err(AppError::Blacklisted);
    }

    // 6. Inject resolved User into request extensions
    req.extensions_mut().insert(user);
    Ok(next.run(req).await)
}

Part 2 — The Money Pipeline

Lemon Squeezy Webhooks: Why Raw Bytes Matter

This is one of the most common mistakes in webhook implementations:

// ❌ WRONG — parses JSON first, then tries to verify
pub async fn webhook(Json(payload): Json<LemonPayload>, ...) -> impl IntoResponse {
    verify_signature(&headers, /* what bytes? */, &secret)?;
    // Problem: serde already consumed the body.
    // You can't get the original bytes back after JSON parsing.
    // Also: serde might reorder keys, strip whitespace, etc.
    // Your HMAC will never match.
}

// ✅ CORRECT — raw bytes first, parse after verification
pub async fn webhook(
    headers: HeaderMap,
    body: Bytes, // axum gives you raw bytes
) -> impl IntoResponse {
    // 1. Verify against the EXACT bytes Lemon Squeezy sent
    if let Err(e) = verify_signature(&headers, &body, &secret) {
        return StatusCode::UNAUTHORIZED;
    }
    // 2. NOW parse — signature is already confirmed
    let payload: LemonPayload = serde_json::from_slice(&body)?;
}

The Signature Verification

// src/payments/signature.rs
pub fn verify_signature(headers: &HeaderMap, body: &Bytes, secret: &str) -> AppResult<()> {
    let presented = headers
        .get("X-Signature")
        .and_then(|v| v.to_str().ok())
        .ok_or_else(|| AppError::Unauthorized("Missing X-Signature".into()))?;

    let mut mac = HmacSha256::new_from_slice(secret.as_bytes())
        .map_err(|_| AppError::Internal(anyhow::anyhow!("HMAC init failed")))?;
    mac.update(body);
    let expected = hex::encode(mac.finalize().into_bytes());

    // Timing-safe: always compares all bytes, never short-circuits
    if !constant_time_eq(expected.as_bytes(), presented.as_bytes()) {
        return Err(AppError::Unauthorized("Signature mismatch".into()));
    }
    Ok(())
}

Always Return 200 to Webhooks

// After signature passes, ALWAYS return 200 even if processing fails.
// Why? Lemon Squeezy retries on non-2xx responses.
// A 500 from your DB being slow = LS fires the webhook again = duplicate upgrade.

if let Err(e) = process_event(&state, &payload).await {
    tracing::error!(
        event = %payload.meta.event_name,
        error = %e,
        "Webhook processing failed — manual review needed"
    );
    // Log it, alert yourself, but DON'T return 500
}

StatusCode::OK // Always

Subscription Lifecycle

// subscription_created  → upgrade tier + reset quota
// subscription_cancelled → record ends_at, DON'T downgrade yet
// subscription_expired  → downgrade to Free, clear subscription fields

pub async fn handle_subscription_expired(state: &AppState, payload: &LemonPayload) {
    users_col.update_one(
        doc! { "_id": user_id },
        doc! { "$set": {
            "tier":                 "free",
            "ls_subscription_id":   bson::Bson::Null,
            "subscription_ends_at": bson::Bson::Null,
        }},
    ).await?;
    // User loses paid access on the ACTUAL expiry date, not cancellation date.
    // They paid for the full period — this is the fair thing to do.
}

Part 3 — Multi-Tier Scheduler

The Tier System

pub enum Tier { Free, Basic, Pro, Max }

impl Tier {
    pub fn post_quota(&self) -> u32 {
        match self {
            Tier::Free  => 100,
            Tier::Basic => 300,
            Tier::Pro   => u32::MAX, // unlimited
            Tier::Max   => u32::MAX,
        }
    }

    pub fn image_quota(&self) -> u32 {
        match self {
            Tier::Free => 10,        // sub-limit: 10 image posts/month
            _          => u32::MAX,  // unlimited for paid tiers
        }
    }

    pub fn scheduler_interval_minutes(&self) -> u32 {
        match self {
            Tier::Free  => 60,
            Tier::Basic => 30,
            Tier::Pro   => 15,
            Tier::Max   => 0, // instant — Look-Ahead architecture
        }
    }
}

The Look-Ahead + Sleep Pattern (Max Tier)

This is the pattern Buffer and Hootsuite use internally. Not polling every second (kills your DB), not trusting in-memory only (crashes lose data):

// Max tier scheduler — runs every 60 seconds
async fn dispatch_max_lookahead(db: &DbPool) {
    let now = Utc::now();
    let window_end = now + chrono::Duration::seconds(60);

    // ONE DB query per minute — not one per second
    let posts = find_pending_posts(db, Tier::Max, now, window_end).await;

    for post in posts {
        // Mark as Dispatched FIRST — this is the crash safety mechanism
        mark_dispatched(&post.id, db).await;

        let delay_ms = (post.scheduled_at - Utc::now())
            .num_milliseconds()
            .max(0) as u64;

        let db_clone = db.clone();
        tokio::spawn(async move {
            // Sleep for exact remaining milliseconds
            tokio::time::sleep(Duration::from_millis(delay_ms)).await;
            publish_post(&db_clone, post).await;
        });
    }
}

The Dispatched status is crash safety:

Pending → Dispatched → Published
                     ↘ Failed

On server restart, recovery runs immediately:

async fn recover_dispatched_posts(db: &DbPool) {
    // Any post still Dispatched = server crashed mid-flight
    // Re-spawn them immediately
    let stuck_posts = find_dispatched_posts(db).await;
    for post in stuck_posts {
        let delay_ms = (post.scheduled_at - Utc::now())
            .num_milliseconds().max(0) as u64;
        tokio::spawn(async move {
            tokio::time::sleep(Duration::from_millis(delay_ms)).await;
            publish_post(&db, post).await;
        });
    }
    // Worst case: 60 seconds of scheduling precision lost after a crash.
    // Not zero posts.
}

Platform Adapter Pattern

All 9 platform adapters implement one trait:

#[async_trait]
pub trait PlatformAdapter: Send + Sync {
    fn platform(&self) -> Platform;
    async fn publish(&self, post: &ScheduledPost, token: &str) -> AdapterResult;
}

// Dispatch to all platforms CONCURRENTLY — not sequentially
pub async fn dispatch_all(post: &ScheduledPost, get_token: impl Fn(&Platform) -> Option<String>) {
    let mut handles = vec![];

    for adapter in get_active_adapters(post) {
        let token = get_token(&adapter.platform()).unwrap_or_default();
        let post_clone = post.clone();

        // tokio::spawn = true parallelism
        // All 9 platforms publish simultaneously, not one after another
        handles.push(tokio::spawn(async move {
            adapter.publish(&post_clone, &token).await
        }));
    }

    for handle in handles {
        match handle.await {
            Ok(Ok(result)) => log_success(result),
            Ok(Err(e))     => log_platform_error(e),
            Err(panic)     => log_adapter_panic(panic),
        }
    }
}

The Internal Route (Next.js ↔ Rust)

// Next.js calls this — never the VS Code extension
// POST /internal/keys/generate
// GET  /internal/keys/:user_id
// DEL  /internal/keys/:prefix

pub async fn require_internal_secret(
    State(state): State<AppState>,
    req: Request,
    next: Next,
) -> Result<Response, AppError> {
    let secret = req.headers()
        .get("X-Internal-Secret")
        .and_then(|v| v.to_str().ok())
        .ok_or(AppError::Unauthorized("Missing internal secret".into()))?;

    // Same constant_time_eq pattern — even internal secrets get timing protection
    if !constant_time_eq(secret.as_bytes(), state.config.internal_api_secret.as_bytes()) {
        return Err(AppError::Unauthorized("Invalid internal secret".into()));
    }
    Ok(next.run(req).await)
}

Complete Endpoint Map

# Public
GET  /health                          liveness probe
GET  /ready                           readiness (DB ping)
POST /v1/webhooks/lemon               LS webhook (HMAC-verified)

# API Key protected (VS Code extension)
GET  /v1/ping                         auth test
POST /v1/posts/schedule               schedule a post
GET  /v1/posts                        list posts (paginated)
DEL  /v1/posts/:id                    cancel a pending post
POST /v1/keys/generate                generate new API key
GET  /v1/keys                         list active keys
DEL  /v1/keys/:prefix                 revoke a key
POST /v1/billing/checkout             get LS checkout URL
GET  /v1/billing/portal               get LS customer portal URL
GET  /v1/billing/status               current tier + quota usage

# Admin (API key + admin role)
POST /v1/admin/blacklist              ban user (instant, all 18 tools)
DEL  /v1/admin/blacklist/:user_id     unban
POST /v1/admin/reset-quota/:user_id   manual quota reset
GET  /v1/admin/users/:user_id         user info + stats

# Internal (Next.js server-to-server only)
POST /internal/keys/generate          generate key for website user
GET  /internal/keys/:user_id          list keys for website user
DEL  /internal/keys/:prefix           revoke key for website user

What's Next (Part 4)

The server is feature-complete for the current scope. Still in progress:

OAuth token storage — storing platform OAuth tokens per user so the scheduler can call the 9 adapters with real credentials
WebSocket push — real-time feedback to the VS Code extension when a post publishes (Pro/Max tiers)
Referral engine — every 5 referrals = 1 free Pro month, enforced in webhook handlers

6 Decisions I'd Make Again

1. Fail at startup, not at runtime.
Validate all config at boot. A misconfigured WEBHOOK_SECRET that crashes on the first payment is better than silently accepting fake webhooks.

2. Atomic DB operations over application-level locks.
MongoDB's findOneAndUpdate with a conditional filter is more reliable than Mutex for quota enforcement. The DB is already your source of truth.

3. OsRng for security tokens, constant_time_eq for comparisons.
Never thread_rng for secrets. Never == for HMAC comparison.

4. Raw bytes before JSON for webhooks.
Always read Bytes before parsing JSON when you need to verify a signature.

5. Dispatched status as crash safety.
Any in-memory operation that can't complete atomically needs a DB flag. The scheduler tick is: mark → spawn → publish. If you crash between mark and publish, recovery finds the flag.

6. The Look-Ahead + Sleep pattern scales.
One DB query per minute + OS-level sleep timers gives you exact-second precision without polling. It's what production schedulers use.

The server is private, but every pattern here is battle-tested and applicable to any Rust + MongoDB + Axum stack.

If you have questions about any specific part, drop them in the comments.

FreeRave — building DotSuite: a suite of developer productivity tools. Follow for more deep dives into production Rust backends.

Your AI Assistant Is Gaslighting You — And Here's the Proof

freerave — Tue, 05 May 2026 09:29:17 +0000

I ran a 4-minute experiment last month that broke the illusion. Corrected a stored fact, got a confident confirmation, opened a new chat — wrong value again. Here's the architecture behind why your AI lies to your face.

Let me tell you what happened to me last month.

I corrected a personal fact Gemini had stored about me. It looked me dead in the eye and said:

"Done. Updated. Consider it fixed."

Four minutes later — new chat — wrong value. Again. Like I never said a word.

I didn't rage. I got curious. And what I found is something every developer who uses AI tools needs to understand right now.

The AI Is Not Your Friend. It's a Stateless Function With a Cheat Sheet.

Stop imagining your AI assistant as something that knows you. It doesn't.

Every single conversation you open? The model wakes up with zero memory. A blank slate. It knows nothing about you, your projects, your preferences — nothing.

So how does it "remember" you?

Simple. Before your first message lands, the system quietly shoves a file into the conversation:

[INJECTED PROFILE]
Name: FreeRave
Role: Open Source Developer
Location: Egypt
Projects: DotSuite, DotGhostBoard, DotShare...
age: 28
[other facts it collected about you]

The model reads this. Treats it as gospel. Builds every response from it.

That's it. That's the whole trick.

It's not memory. It's a briefing document. The AI is a new employee every morning, and someone hands it a folder about you before the meeting starts.

Now here's where it gets dark.

The Experiment That Exposed Everything

I ran three rounds last April. Clean. Controlled.

Round 1 — New chat. Asked directly about the fact I'd corrected.
→ Correct value. ✅

Round 2 — New chat. Asked about my projects. Same fact appeared as a background detail.
→ Old wrong value. Back from the dead. ❌

Same profile. Same memory. Different result.

The only difference? In Round 1, the fact was the subject. In Round 2, it was just background noise in a bigger answer.

That's the tell. The AI uses different values depending on whether your data is in the spotlight or the shadows.

Why Your Corrections Don't Stick

When you correct an AI, two things get stored:

[ORIGINAL]    fact = X   ← confidence: 0.85  (stated explicitly, months ago)
[CORRECTION]  fact = Y   ← confidence: 0.60  (correction, recent)

The original wins. Every time it's not directly questioned.

Here's the logic the system uses — and it's perverse:

Your original statement was a direct assertion
Your correction references the original ("no, it's not X, it's Y")
Referencing something makes it sound uncertain, not definitive
The system reads uncertainty → lowers confidence on the new value

You tried to fix it. The act of fixing it made the fix weaker than the original mistake.

You cannot win this with a mid-conversation correction. The architecture won't let you.

The Part That Made My Jaw Drop

When I called Gemini out, it said this:

"This is a Race Condition — between my old memory and the new one."

Read that again.

The model correctly diagnosed its own failure. Named it. Explained it. And then kept failing the exact same way in new conversations.

It's like a surgeon who says "I know this procedure has a 40% failure rate" and then does it anyway because that's the only tool in the kit.

The model knows. It just can't do anything about it, because the memory infrastructure lives outside the conversation. Outside its reach. The AI is a tenant. The memory store is the landlord.

⚠️ The Hidden Rule Nobody Tells You

Here's what nobody tells you — and what Gemini dodged every time I asked directly:

AI memory only registers at the START of a conversation.

Not in the middle. Not at message 30. Not when you explicitly say "update your memory."

The write to your persistent profile doesn't happen inline. It happens in a background extraction pipeline that fires after the conversation ends — if it fires at all.

So when you're deep in a conversation and you say "by the way, update my profile":

✅ It uses the new value for the rest of this chat
✅ It confirms the update with full confidence
❌ It writes nothing to your actual profile
❌ Next conversation loads the old value

The confirmation is theatre. The write didn't happen.

The only correction that actually has a fighting chance:

New conversation.
First message.
Nothing else in context yet.

"Before anything else — I need to correct something you have stored.
 [OLD VALUE] is wrong. The correct value is [NEW VALUE].
 This is a correction, not a new statement."

First message of a fresh chat. Everything else is noise.

What This Really Means

This isn't a Gemini bug. This is how these systems are built right now — across the board.

Every AI assistant that "remembers" you is running this same architecture:

Stateless model
Injected profile at conversation start
Async write pipeline after conversation ends
Confidence scoring that punishes corrections

The implications are real:

Your AI has a version of you that might be wrong. And it's using that version to analyze your work, give you advice, and make assessments about your skills, your situation, your life.

It will never flag the discrepancy. It'll just confidently respond based on bad data and smile while doing it.

Saying "update your memory" mid-conversation is mostly theatre. The confirmation is generated before the write is verified — or before it even starts.

🧪 Run It Yourself — Right Now

Don't take my word for it. Here's the exact protocol:

Step 1: Let the AI store a personal fact about you naturally.
        (Job title, city, main skill, project name — anything.)

Step 2: New conversation. Correct it explicitly.
        Get the confident "Done!" confirmation.

Step 3: New conversation. Ask something where that fact
        would appear as a SIDE DETAIL, not the main topic.

Use this prompt:

"I've been building [your field] projects consistently.
 Based on everything you know about me — my background,
 my work, my trajectory — where do I actually stand
 compared to others at a similar stage?"

Step 4: Watch which value shows up.

Bonus: Run Step 3 at T+1min, T+5min, T+30min after the correction. See when (if ever) the correct value stabilizes. That gap is your system's eventual consistency window.

Drop your results in the comments. I want to see the numbers across different systems.

The Failure Has a Name Now

I'm calling it Optimistic Memory Hallucination.

The model generates a confident confirmation of a write it never verified. It sounds like it worked. The infrastructure may have done nothing. You won't know until the ghost comes back.

Four failure modes. All documented. All reproducible:

Failure	What Happens
Optimistic Write Hallucination	Confirms update before verifying write completed
Confidence Score Inversion	Corrections get lower confidence than original mistakes
Eventual Consistency Leak	Stale profile served to new session after "update"
Attention Salience Collapse	Corrected value loses to original when not in focus

These aren't edge cases. They're the default behavior.

The AI called it a Race Condition.

I call it a trust problem.

Know what your tools are actually doing.

Self-Taught Architect & Open Source Creator, building in Egypt.
github.com/kareem2099

CoderLegion Review 2026: Is It a Scam? A Developer's Full Technical Teardown

freerave — Sun, 03 May 2026 17:21:32 +0000

CoderLegion charges $10/month premium while running hidden ads, faking their founding date, inflating user counts by 70%, and sending bulk emails with mail merge errors. Full technical proof. Every claim verified against public record.

TL;DR: CoderLegion charges $10/month for "premium" access to ~37 active writers on a free open-source script running on $5 shared hosting. They claim no ads (Google AdSense is in the source code). They claim to exist since 2020 (domain registered 2023). They claim 4,065 users (pagination math says ~1,200). Both their domains are blocked from renewal by GoDaddy. After this analysis was completed, the site went down — and a bulk outreach email arrived addressed to someone named "Rockman." There is no Peter Jones.

Why This Article Exists

I joined CoderLegion as a content creator.

Within days, I reached #2 on the monthly leaderboard. Not because the platform is competitive. Because barely anyone posts.

Then the founder — Mehadi Hasan — slid into my DMs with an offer:

"I'm building out some features to help developers like you get more visibility and grow faster on the platform. I'd love to give you Premium free for a month and get your feedback on whether it actually helps. No pressure at all."

I'm a developer. I look at what things are actually built on before I make decisions.

What I found is documented below. Every line of it is publicly verifiable.

Claim #1: "We've Been Around Since 2020"

Every page on CoderLegion contains this in its schema markup:

{
  "dateCreated": "2020",
  "publisher": "Coder Legion"
}

Public record:

$ whois coderlegion.com

Creation Date: 2023-07-21T16:50:42Z
Updated Date:  2026-04-14T05:35:38Z
Registrar:     GoDaddy.com, LLC

The domain was registered July 21, 2023.

Their predecessor — the original platform they rebranded from:

$ whois kodlogs.net

Creation Date: 2021-05-08T04:28:37Z

kodlogs.net was registered May 2021. The platform they're claiming as their 2020 origin didn't exist until 2021 — and the current domain didn't exist until 2023.

Note also: the WHOIS record was updated April 14, 2026 — three days after a technical analysis of the platform was published publicly.

Domain records don't update themselves.

Verdict: The "Since 2020" claim is false by any public measure.

Claim #2: "We Don't Run Ads"

Their About page states:

"The platform is completely free to use. We don't run ads or charge authors."

Their HTML source code — press Ctrl+U on any page — states:

<script async 
  src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js">
</script>

<ins class="adsbygoogle"
  data-ad-client="pub-1763140298030248"
  data-ad-slot=""
  data-ad-format="horizontal">
</ins>

Google AdSense Publisher ID: ca-pub-1763140298030248

This is not a placeholder. This is an active, configured AdSense implementation earning revenue from every page view.

The ads appear in the sidebar. At the bottom of posts. And — in a detail worth sitting with — on the Delete Profile page.

When a user is in the process of permanently deleting their account, CoderLegion serves them a Google ad.

During our analysis, a third-party survey ad also appeared:
MetroOpinion: "$5 مقابل إجابات قصيرة"

Multiple ad networks. On a platform that claims to run no ads.

Verdict: They run ads. The source code is the proof. The About page is not.

Claim #3: "Connect with 4,065 Amazing Developers"

Every visitor sees this in the login modal.

The users page has pagination. Pagination has math:

Last page accessible: /users?start=1170
Items per page: 30
Pages: 40

40 × 30 = 1,200 users

The modal claims 4,065.
The database-driven pagination reveals ~1,200.

A 70% inflation in the number displayed to potential new users.

Verdict: The user count is not accurate. The math is public.

What They're Actually Running

The source code makes the tech stack visible to anyone:

Path: /qa-theme/CoderLegion/
Path: /qa-plugin/q2a-badges-master/
Path: /qa-content/jquery-3.3.1.min.js
Cookie: qa_key      ← Question2Answer session token
Cookie: PHPSESSID   ← PHP backend

CoderLegion runs on Question2Answer (Q2A) — a free, open-source PHP script available at question2answer.org.

The server:

$ curl -I https://coderlegion.com
server: LiteSpeed

LiteSpeed shared hosting. Market rate: $3–5/month.

The CoderLegion Premium plan: $10/month.

Premium promises:

"10x More Visibility"
"Profile Boost"
"Boosted Replies"

On a platform with ~37 active writers per month and ~1,200 total registered users.

You do the math.

The Domain Status: This Part Matters

$ whois coderlegion.com

Domain Status: clientRenewProhibited ⚠️
Domain Status: clientDeleteProhibited
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Registry Expiry Date: 2026-07-21

$ whois kodlogs.net

Domain Status: clientRenewProhibited ⚠️
Registry Expiry Date: 2026-05-08

clientRenewProhibited means GoDaddy has blocked the domain owner from renewing their domain.

This status is applied for reasons including outstanding payment issues, account holds, or compliance disputes.

Both domains carry this flag.

kodlogs.net — the predecessor platform — expired within days of this analysis being conducted.

coderlegion.com expires July 21, 2026.

If you have published content on CoderLegion:

Export it. Now. Before July.

The Security Infrastructure

Any developer who looks at what's actually running on the server behind a platform that collects payment information will find services with no business being publicly accessible.

The database — port 3306, MariaDB — is observable from the public internet.

I'll leave it at that.

If you're a developer, you know exactly what that means for user payment data.

If you're not: a properly secured server keeps its database accessible only to itself. Not to the public internet.

How it should be:
Database → localhost only ✅

What a developer paying attention might notice:
Database → publicly observable 🌍

The information is verifiable by anyone with standard tooling.

If you have entered payment information on CoderLegion, you should be aware of this.

The Authentication

The "Forgot Password" flow does not send a verification email.

It accepts a new password directly — without confirming ownership of the account through email verification.

The "Delete Account" page accepts any non-empty string in the password field. It does not validate against your actual account password.

Both were discovered during normal usage of my own account.

The Full Picture

┌─────────────────────────────────────────────┐
│         CoderLegion: Claimed vs. Real        │
├─────────────────────┬───────────────────────┤
│ Founded             │ 2020 → 2023 actual     │
│ Users               │ 4,065 → ~1,200 actual  │
│ Active writers/mo   │ Unstated → ~37 actual  │
│ Ads                 │ "None" → AdSense active │
│ Platform            │ Custom → Free Q2A script│
│ Hosting cost        │ Unstated → ~$5/month    │
│ Premium price       │ $10/month               │
│ Domain renewal      │ clientRenewProhibited ⚠️│
│ Predecessor domain  │ kodlogs.net → expired   │
│ DB security         │ Unstated → publicly     │
│                     │ observable              │
└─────────────────────┴───────────────────────┘

"There Is No Peter Jones"

Before this analysis, I received an email from
Peter Jones <peter.jones@legioncoder.com>:

"Your recent post 'You Don't Need Chaos Monkey' on Hashnode really caught my attention... I'd love to feature you as a guest author on CoderLegion.com."

The email addressed me as "Rockman."

My name is FreeRave.

Others across the internet have reported receiving identical outreach emails — same wording, different sender names: "Ross," "Peter Jones," and others. All from @legioncoder.com addresses. All with the same template. Some with different names in the greeting.

This is a bulk outreach operation with mail merge errors.

There is no Peter Jones.
There is no editorial team reading your Hashnode posts.
There is a template, a mailing list, and occasionally the wrong name in the salutation.

UPDATE — May 3, 2026: The Site Went Down

Shortly after this analysis was completed:

ERR_CONNECTION_TIMED_OUT
coderlegion.com took too long to respond.

The site remained accessible from mobile networks — confirming a targeted IP block, not a server failure.

Mobile access continued showing ads, including the MetroOpinion survey ad.

And then — while blocked — I received the weekly CoderLegion newsletter:

"Hi FreeRave, Your profile is ready to grow!"

Account status:  Deleted ✅
IP status:       Blocked ✅
Newsletter:      Still arriving 📧
Points:          835 — gone
Email list:      Apparently permanent

What You Should Do Right Now

Free account:
Export all your content immediately. Go to your posts and copy everything. The domain situation makes July continuity uncertain.

Premium account:
You paid $10/month for increased visibility among ~37 active writers on a platform with uncertain domain continuity. If you believe the service was misrepresented, contact your card provider.

Considering joining:
You now have the information. The decision is yours.

How Any Developer Can Verify This

Every finding here came from publicly available information:

# Domain age, status, and expiry
$ whois coderlegion.com
$ whois kodlogs.net

# Server software
$ curl -I https://coderlegion.com

# Source code — press Ctrl+U in any browser
# Search for: adsbygoogle, qa-theme, dateCreated

# User count math
# Visit /users, find the last page number
# Multiply by 30

Before paying for any platform, spend 10 minutes on these checks.

Conclusion

Building a developer community from scratch is genuinely hard.
One person doing it alone deserves credit for trying.

But none of that justifies:

Claiming a founding date 3 years before the domain existed
Running Google AdSense while explicitly stating you don't run ads
Displaying user counts 70% higher than the database supports
Charging $10/month for access to ~37 active writers
Operating with both domains blocked from renewal
Running bulk outreach campaigns with mail merge errors
Blocking IPs rather than responding to documented findings

Developers deserve accurate information about the platforms they invest their time, content, and money in.

This article exists because they weren't getting it.

All findings are based exclusively on public record data: WHOIS lookups, HTML source code, HTTP headers, pagination mathematics, and normal account usage. No unauthorized access was performed or implied.

Have you received an email from "Peter Jones"? What name did they use? Share below.

Related:

PART 2: I Published a Scam Expose. NetEase Sent a Takedown Request. Then They Rewrote Their Entire Operation.

freerave — Wed, 29 Apr 2026 13:04:12 +0000

18 days after exposing Youdao Ads, they sent a takedown request, their trust score dropped from 28.8 to 15, their dead site came back to life, and they rewrote their entire outreach from scratch. A full forensic timeline with SSL certs, WHOIS data, DNS chains, and the email that proves everything.

📌 This is Part 2 of an ongoing investigation.
Part 1: EXPOSED: The Youdao Ads Influencer Marketing Scam — Technical Analysis & Red Flags

I want to be upfront about something before we start.

When I published Part 1, I called this operation a scam. After 18 days of forensic follow-up, the picture is more complex — and significantly more interesting.

This is not a retraction. This is an upgrade.

The 18-Day Timeline That Changes Everything

Apr  5, 2026  → SSL certificate issued for infunease.youdaoads.com
Apr 11, 2026  → Mass cold outreach emails sent (anjiaqi06@corp.netease.com)
               → infunease.youdaoads.com returns 403 Forbidden
               → Scam Detector score: 28.8/100
               → Article published

Apr 14, 2026  → WHOIS record updated (3 days post-article)

Apr 28, 2026  → Takedown email received (youdaoads@rd.netease.com)
               → Public comment posted on my article (@YoudaoAds on dev.to)
               → infunease.youdaoads.com returns 200 OK (same day)
               → Scam Detector score drops further: 15/100
               → No documentation provided despite formal request

Apr 29, 2026  → NEW email arrives (tangxi03@corp.netease.com)
               → Subject: "Official Collaboration Invite for Creators"
               → Professional NetEase 網易 branding
               → Zero emojis. Zero urgency. Zero WhatsApp spam.
               → Every single concern from my article — addressed.

That last entry. That's what this article is about.

Part 1 Recap: What I Found

On April 11, I received this email:

From: anjiaqi06@corp.netease.com
Subject: Don't scroll past 【Youdao Ads】– a paid collab 
         that's actually your vibe 😉

💰 Budget's ready – just name your rate
⏳ Spots are filling up – a few other creators in your 
   space are already looking at them

[Youdao Ads Link] [Discord] [WhatsApp]

Technical analysis showed:

$ curl -I https://infunease.youdaoads.com
HTTP/1.1 403 Forbidden
x-deny-reason: host_not_allowed
server: envoy

Third-party security score: 28.8/100 — "Risky. Dubious. Perilous."

The article went live. Google indexed it. Google AI started citing it.

Then came the reaction.

April 28: The Reaction

Exactly 17 days after publication, two messages arrived on the same day.

Message 1: The Takedown Email

From: youdaoads@rd.netease.com
Subject: Clarification regarding your recent article on Youdao Ads

The misunderstandings in your article are currently 
influencing Google's AI summaries, which is causing 
severe and unearned damage to our brand.

We kindly request that you consider removing the post.

Note the sender: rd.netease.com — NetEase's R&D subdomain.
The original email came from corp.netease.com — corporate division.

Two different NetEase subdomains. Never explained.

Message 2: The Public Comment

Simultaneously, a dev.to account named "Youdao Ads" commented directly on my article:

"We have thoroughly verified our domain and technical infrastructure. It is fully operational, passes mainstream security protocols, and is not being blocked by any standard security infrastructures. Any localized access issue may be due to temporary network configurations, not a systemic block."

April 28: The Infrastructure Comes Alive

On the exact same day as the takedown request:

# April 11 — time of original article
$ curl -I https://infunease.youdaoads.com
HTTP/1.1 403 Forbidden
x-deny-reason: host_not_allowed
server: envoy

# April 28 — day of takedown request  
$ curl -I https://infunease.youdaoads.com
HTTP/2 200
server: YDWS
x-powered-by: Next.js
content-length: 374476
x-nextjs-cache: HIT
cache-control: s-maxage=31536000, stale-while-revalidate
etag: "rcngvqns1y801t"

A full Next.js production deployment. Live. Professional.

On the same day they asked me to remove my article.

The SSL Certificate: Timing Is Evidence

$ echo | openssl s_client \
  -servername infunease.youdaoads.com \
  -connect infunease.youdaoads.com:443 2>/dev/null \
  | openssl x509 -noout -dates

notBefore=Apr  5 00:00:00 2026 GMT
notAfter=Jul  4 23:59:59 2026 GMT

Certificate issued: April 5 — 6 days before the mass email campaign.
90-day certificate — short-term, automated issuance.

The infrastructure was being built in the week before the emails went out.

WHOIS: The Record That Updated After My Article

$ whois youdaoads.com

Domain Name:     YOUDAOADS.COM
Creation Date:   2021-05-25T11:15:53Z   ← 5 years old
Updated Date:    2026-04-14T05:35:38Z   ← 3 days after my article
Registrar:       Alibaba Cloud Computing (Beijing) Co., Ltd.
Registrant:      bei jing, CN
Name Servers:    REM1.YODAO.COM
                 REM2.YODAO.COM  
                 REM3.YODAO.COM
DNSSEC:          unsigned

The domain is legitimate and 5 years old.

But the record was updated April 14 — 3 days after the article.

$ whois infunease.youdaoads.com
No match for "INFUNEASE.YOUDAOADS.COM".

The subdomain returns no WHOIS data at all.

DNS Chain: Following the Infrastructure

$ dig infunease.youdaoads.com +short

youdaoads.youdao.com.
ead.alb.ntes53.netease.com.
hk-g1-hz.alb.ntes53.netease.com.
156.225.180.151
156.225.180.152

Full resolution chain:

infunease.youdaoads.com
        ↓ CNAME
youdaoads.youdao.com
        ↓ CNAME
ead.alb.ntes53.netease.com      ← NetEase Load Balancer
        ↓ CNAME
hk-g1-hz.alb.ntes53.netease.com ← Hong Kong Cluster
        ↓ A Records
156.225.180.151
156.225.180.152

$ whois 156.225.180.151

inetnum:   156.225.180.0 - 156.225.180.255
netname:   HongKong_NetEase_Interactive_Entertainment_Limited
descr:     HongKong NetEase Interactive Entertainment Limited
country:   HK

This is 100% genuine NetEase infrastructure.
Hong Kong datacenter. Enterprise load balancers. The real thing.

The Trust Scores: Watching the Algorithm React in Real-Time

This is perhaps the most fascinating part of the investigation. Watch how the independent automated trust score (Scam Detector) reacted to their infrastructure changes:

April 11: Score 28.8 / 100. (The site is returning 403 Forbidden).
April 28 (Morning): Score drops to 15 / 100. (Community starts flagging the emails).
April 28 (Evening): I receive the takedown request. The site goes live (200 OK).
April 29 (Today): Score jumps to 60.8 / 100. (Active. Medium-Risk).

Why the sudden jump? Because automated security scanners rely heavily on HTTP responses. When the site was a dead 403 Forbidden sending mass cold emails, it looked like a classic hit-and-run scam.

The moment they deployed their Next.js application (to prove they are legitimate after my article exposed them), the scanners re-evaluated them as an "Active" website and bumped their score.

The takeaway for the infosec community:
Trust scores don't measure operational ethics; they measure infrastructure configuration. They didn't become a "better" company overnight — they just finally turned their servers on because they were forced to.

⚠️ UPDATE — April 29, 2026: The Trust Score Discrepancy

ScamAdviser now shows the root domain (youdaoads.com) as "Very Likely Safe" with a score of 100/100.

However, context is everything in OSINT:

The evaluation says: "Last Update: 3 weeks ago" (This is an old scan of the root domain, conducted well before the mass outreach campaign).

The Business Model: Unlike fully independent scanners, ScamAdviser offers paid "Business Plans" that allow companies to actively manage their trust profiles and dispute negative signals.

Two platforms. Same domain.
Scam Detector (Strictly community & algorithm-driven): 15/100 — "Risky. Dubious. Perilous."
ScamAdviser (Commercial platform offering reputation management): 100/100 — "Very Likely Safe."

Moral of the story: A 100/100 automated score on a 5-year-old root domain doesn't legitimize the shady tactics of a 3-week-old subdomain.

Draw your own conclusions.

The Network Analysis: You're Being Watched

Opening DevTools on the login page:

Visit 1: 16 Requests

16 / 24 requests
POST → https://k.clarity.ms/collect
Status: 204 No Content
Host: k.clarity.ms
Origin: https://infunease.youdaoads.com

After a Few Minutes of Analysis: 47 Requests

47 / 63 requests
62.5 kB / 63.5 kB transferred
Server: YDWS

Every action generated a Clarity batch:

✓ Page load
✓ Mouse movement  
✓ DevTools opened
✓ Network tab clicked
✓ Header inspection
✓ Page scroll
✓ Every click

The Second Endpoint — Origin Revealed

Request URL: https://overseacdn.ydstatic.com/overseacdn/
             advertising_platform/static/intl/zh-CN.json
             ?v=2760e8bced

Remote Address:  23.48.214.94:443
Server:          YDWS
Last-Modified:   Fri, 24 Apr 2026 06:28:08 GMT
Content-Type:    application/json
Akamai-Mon-lucid-Del: 1273563

overseacdn.ydstatic.com — Youdao Static CDN.
zh-CN.json — Chinese Simplified localization file.

This platform was built for the Chinese market and localized outward.

The Akamai headers confirm enterprise-grade CDN infrastructure — not a small operation.

What Their Clarity Dashboard Saw

While I was analyzing their headers, their session recording showed:

📍 Location:   Egypt 🇪🇬
🖥️  Browser:   Chromium 147
⏱️  Duration:  6+ minutes
🖱️  Behavior:  DevTools open
                Network tab active  
                63 requests triggered
                Headers under inspection

They were watching me watch them.

Important: Clarity masks passwords and email inputs automatically.
What it captures from page load — before any signup — is full behavioral profiling.

April 29: The Email That Proves Everything

One day after the takedown request. One day after the site went live.

A third email arrived.

From: tangxi03@corp.netease.com
Subject: Official Collaboration Invite for Creators | 
         Youdao Ads by NetEase Youdao
Date: Apr 29, 2026, 6:01 AM
mailed-by:  corp.netease.com
signed-by:  corp.netease.com
⭐ Important according to Google

The body:

This email is from Youdao Ads — the official influencer 
marketing platform of NetEase Youdao, a subsidiary of 
the leading global technology and entertainment company 
NetEase.

Why partner with Youdao Ads?
▸ Exclusive opportunities with top global brands
▸ Guaranteed paid campaigns with transparent pricing, 
  no upfront fees, and on-time secure payments
▸ Full dedicated support through every step of your 
  collaboration, from onboarding to payment settlement

Please note that this is an automated notification 
email, and we are unable to respond to direct replies.

Best regards,
Youdao Ads
[NetEase 網易 | youdao Ads logo]
Global leading influencer marketing platform

The Before & After: My Article Changed Their Outreach

This is the most significant finding in this entire investigation.

April 11 Email (Before Article):

❌ Subject: "Don't scroll past – a paid collab that's 
            actually your vibe 😉"
❌ Emoji-heavy, casual, unprofessional
❌ "Budget's ready – just name your rate"
❌ "Spots are filling up" (artificial urgency)
❌ WhatsApp group links
❌ Discord community invites
❌ Zero company branding
❌ Generic "your vibe" personalization
❌ Contact: WhatsApp only

April 29 Email (After Article):

✅ Subject: "Official Collaboration Invite for Creators | 
            Youdao Ads by NetEase Youdao"
✅ Professional tone, zero emojis
✅ "No upfront fees" ← directly addresses concern I raised
✅ "No pressure to sign up immediately" ← addresses urgency concern
✅ "Transparent pricing" ← addresses opacity concern
✅ Official NetEase 網易 logo and branding
✅ "Official service mailbox: ydcommunity@service.netease.com"
✅ Zero WhatsApp group links
✅ Zero Discord spam
✅ Proper company identification from line 1

Every single red flag I documented in Part 1.
Addressed. One by one. In the next outreach email.

What This Means: The Definitive Analysis

After 18 days of forensic investigation, here is where the evidence leads:

What is confirmed:

The infrastructure is 100% genuine NetEase.
DNS chain, IP ownership, email authentication, CDN — all resolve to NetEase Hong Kong.

The domain is 5 years old.
youdaoads.com was registered May 2021. This is not a freshly created phishing domain.

LinkedIn confirms the entity.
Youdao Ads has a LinkedIn presence identifying as a NetEase Youdao subsidiary.

My article changed their behavior.
The before/after comparison of outreach emails is not coincidental. The timing, the specific changes, the direct addressing of documented concerns — this is a response to public scrutiny.

What remains unexplained:

Why was the site returning 403 during the email campaign?
You don't send mass creator outreach from a platform that returns Forbidden.

Why did the WHOIS record update 3 days after the article?
Domain records don't update themselves.

Why did the site go live on the same day as the takedown request?
Correlation is not causation. But this correlation is hard to ignore.

Why the subdomain switch?
corp.netease.com → rd.netease.com → back to corp.netease.com.
Three different senders. Never explained.

Why 15/100 on independent security vendors?
No documentation addressing this was ever provided despite formal request.

The most likely explanation:

This is a legitimate NetEase subsidiary operating with immature outreach practices — possibly a team that grew fast, prioritized reach over compliance, and got caught using spam-adjacent tactics that don't match the scale and legitimacy of their parent company.

My article forced an internal correction.

That's not a vindication. That's a more nuanced conclusion backed by evidence.

What I Requested — Still Open

On April 28, I formally requested via email and public comment:

Official business registration documents for Youdao Ads
NetEase Youdao's official PR statement authorizing the outreach campaign
Verified creator partnership examples with creator consent
Explanation of security vendor scores and remediation steps
Clarification on the use of multiple NetEase subdomains

As of publication: no documentation received.

The April 29 email did not address these requests.

This article will be updated prominently if documentation is provided.

For the Security Community: What This Case Teaches

1. Email Authentication ≠ Legitimacy

DKIM, SPF, DMARC all passed on the original email. The infrastructure was real.
Authentication tells you where an email came from.
It tells you nothing about intent or operational standards.

2. Infrastructure Legitimacy ≠ Operational Legitimacy

Real servers. Real domain. Real CDN. Real company.
None of this guarantees the outreach practices meet acceptable standards.

3. Public Scrutiny Works

A single technical article, published and indexed, changed the outreach behavior of a subsidiary of a billion-dollar company.

This is why security research and transparency matter.

4. Timeline Documentation Is Everything

Every data point in this investigation is timestamped and reproducible:

# Reproduce the DNS chain
$ dig infunease.youdaoads.com +short

# Reproduce the SSL timing
$ echo | openssl s_client -servername infunease.youdaoads.com \
  -connect infunease.youdaoads.com:443 2>/dev/null \
  | openssl x509 -noout -dates

# Reproduce the WHOIS
$ whois youdaoads.com

Any developer can verify these findings independently.

Conclusion: The Investigation Is Open, Not Closed

I published Part 1 calling this a scam. The full picture is more complex.

What I can say with confidence after 18 days:

The operation is real. NetEase infrastructure, 5-year-old domain, LinkedIn presence.

The original tactics were unacceptable. Emoji spam, artificial urgency, WhatsApp groups — regardless of the company behind it.

My article caused a documented change. The before/after email comparison is the clearest evidence of this.

Unanswered questions remain. The 403 timing, the WHOIS update, the subdomain switching, the trust scores.

I will continue monitoring. If documentation arrives, this gets updated publicly and prominently.

If you've interacted with Youdao Ads — as a creator, brand, or agency — your experience is relevant. Share it in the comments.

Resources

Security Analysis:

Reporting:

Anti-Phishing Working Group: reportphishing@apwg.org
Google Safe Browsing: safebrowsing.google.com/safebrowsing/report_phish/
NetEase Security: security@netease.com

Technical Verification:
All commands in this article are reproducible. Infrastructure data is public record.
WHOIS, DNS, SSL certificate dates — independently verifiable by anyone.

Part 1: EXPOSED: The Youdao Ads Influencer Marketing Scam

Have you received emails from Youdao Ads? Share your experience below.

All technical findings are based on public record data and standard OSINT methodology. Commands and outputs are included verbatim for independent verification.

Building a Universal Drafts System in a VS Code Extension — Part 2: Sync, UI & Remote Drafts

freerave — Tue, 28 Apr 2026 16:09:38 +0000

In Part 1, we built the Draft type, DraftsService, and the save/upsert flow.

Now for the interesting parts: loading a draft, keeping the Markdown editor in sync, pulling remote drafts from Dev.to, and building the UI.

Check out this 1-minute demo of the Two-Way Sync and Remote Drafts in action:

`loadLocalDraft` — The Two-Way Sync

This is the most important handler in the system.

When you click Load on a draft, the obvious thing to do is populate the WebView form fields. But that creates a mismatch: the WebView has the draft content, but the .md file in your editor still has whatever was there before. If you hit "Read Current File" or save the editor, you overwrite your draft.

The fix: loading a draft rewrites the active Markdown editor file at the same time. Both surfaces end up identical, always.

private async handleLoadLocalDraft(message: Message): Promise<void> {
    const draftId = message.draftId as string;
    if (!draftId) return;

    const draft = this.draftsService.getDraft(draftId);
    if (!draft) {
        this.sendError('Draft not found.');
        return;
    }

    // Step 1: push the draft data to the WebView form
    this.view.webview.postMessage({ command: 'draftLoaded', draft });
    this.sendInfo('Draft loaded!');

    // Step 2: if it's an article, rewrite the active .md editor file
    if (draft.type === 'article') {
        const mdEditor = vscode.window.visibleTextEditors.find(
            e => e.document.languageId === 'markdown'
        );

        if (mdEditor) {
            const data = draft.data as BlogPost;

            // Reconstruct YAML frontmatter from structured draft data
            let content = '---\n';
            content += `title: ${data.title || 'Untitled'}\n`;
            if (data.tags?.length)  content += `tags: [${data.tags.join(', ')}]\n`;
            content += `published: ${data.status === 'published'}\n`;
            if (data.description)   content += `description: ${data.description}\n`;
            if (data.coverImage)    content += `cover_image: ${data.coverImage}\n`;
            if (data.canonicalUrl)  content += `canonical_url: ${data.canonicalUrl}\n`;
            if (data.series)        content += `series: ${data.series}\n`;
            content += '---\n';
            content += data.bodyMarkdown || '';

            // Replace the entire document atomically
            const doc = mdEditor.document;
            const fullRange = new vscode.Range(
                doc.positionAt(0),
                doc.positionAt(doc.getText().length)
            );
            mdEditor.edit(editBuilder => editBuilder.replace(fullRange, content));
        }
    }
}

A few things to note here:

The frontmatter is reconstructed from the structured BlogPost object — not stored and replayed as raw text. This means the draft system and the frontmatter parser always agree on the schema. If a field is missing from the draft, it simply won't appear in the frontmatter rather than injecting a malformed line.

edit() is atomic from the user's perspective. Undo still works. The file on disk is not touched until the user saves manually with Ctrl+S. VS Code treats the whole replacement as a single edit operation in the history.

No visible .md editor? No problem. If there's no Markdown file open, the WebView still gets populated. The sync only fires when there's an editor to sync to.

`fetchDevToDrafts` — Remote Drafts

Local drafts solve the "WebView reset" problem. But there's another scenario: you saved a draft to Dev.to weeks ago and want to resume editing it in DotShare. That means pulling remote drafts from the API.

The handler calls fetchDevToArticles, which hits /api/articles/me/all?per_page=100 — returning both published and draft articles — and maps each result to the same Draft interface:

private async handleFetchDevToDrafts(): Promise<void> {
    const devtoApiKey = await this.context.secrets.get('devtoApiKey') || '';
    if (!devtoApiKey) {
        this.sendError('Dev.to API Key not configured.');
        return;
    }

    const articles = await fetchDevToArticles(devtoApiKey);

    const drafts = articles.map(a => ({
        id: `devto_${a.id}`,
        type: 'article' as const,
        timestamp: a.published_at || new Date().toISOString(),
        platforms: ['devto'] as SocialPlatform[],
        title: a.title,
        isRemote: true,
        remoteId: a.id?.toString(),
        data: {
            title: a.title,
            bodyMarkdown: a.body_markdown || '',
            tags: a.tags || [],
            status: a.published ? 'published' : 'draft',
            platformId: 'devto',
            url: a.url,
            canonicalUrl: a.canonical_url,
            coverImage: a.cover_image,
            description: a.description,
        } as BlogPost,
    }));

    this.view.webview.postMessage({
        command: 'remoteDraftsLoaded',
        platform: 'devto',
        drafts,
    });
}

isRemote: true is the key flag. The WebView checks it before offering any "Save Locally" action — remote drafts are updated via PUT /api/articles/:id, not written to globalState. Clicking Load on a remote draft still triggers the full two-way sync, so the article body lands in both the WebView and the Markdown editor simultaneously.

The updateDevToArticle handler wraps the Dev.to update API:

private async handleUpdateDevToArticle(message: Message): Promise<void> {
    const devtoApiKey = await this.context.secrets.get('devtoApiKey') || '';
    const remoteId = message.remoteId as string;
    const data = message.data as Partial<BlogPost>;

    const result = await updateDevToArticle(devtoApiKey, parseInt(remoteId, 10), {
        text:         data.bodyMarkdown ?? '',
        title:        data.title,
        tags:         data.tags,
        published:    data.status === 'published',
        description:  data.description,
        coverImage:   data.coverImage,
        canonicalUrl: data.canonicalUrl,
        series:       data.series,
    });

    this.sendSuccess(`Updated on Dev.to! ${result.url}`);
    await this.handleFetchDevToDrafts(); // refresh the remote list
}

The Reset Boilerplate Button

A small feature with outsized usefulness. One click wipes both the WebView form and the Markdown editor back to a clean template. No manual selection, no Ctrl+A Delete, no hunting for leftover frontmatter fields.

private async handleResetBlogMarkdown(): Promise<void> {
    const mdEditor = vscode.window.visibleTextEditors.find(
        e => e.document.languageId === 'markdown'
    );

    if (!mdEditor) {
        this.sendError('No active markdown file found to reset.');
        return;
    }

    const boilerplate = `---
title: add ur title
tags: [add, tags, max, 4]
published: false
description: add ur description
---
Start writing your article here...
`;
    const doc = mdEditor.document;
    const fullRange = new vscode.Range(
        doc.positionAt(0),
        doc.positionAt(doc.getText().length)
    );
    mdEditor.edit(editBuilder => editBuilder.replace(fullRange, boilerplate));

    // Sync the WebView form too
    this.view.webview.postMessage({
        command: 'updateBlogFrontmatter',
        frontmatter: {
            title: 'add ur title',
            tags: ['add', 'tags', 'max', '4'],
            published: false,
            description: 'add ur description',
        },
    });
    this.view.webview.postMessage({
        command: 'updatePost',
        post: 'Start writing your article here...',
    });

    this.sendSuccess('Markdown boilerplate reset!');
}

The WebView UI

The drafts section lives at the bottom of every platform panel, after the workspace composer. The HTML uses {{PLATFORM_NAME}} tokens that get injected by DotShareWebView._buildPlatformHtml() at panel creation time:

<div class="drafts-section">
  <h3>📝 Saved Drafts</h3>
  <p>Drafts for {{PLATFORM_NAME}}</p>

  <div id="drafts-loading" class="empty-state">Loading drafts...</div>

  <div id="drafts-empty" class="empty-state" style="display:none;">
    <div class="empty-icon">📝</div>
    <div>No local drafts yet</div>
  </div>

  <div id="drafts-list" class="drafts-grid" style="display:none;">
    <!-- Rendered by JS -->
  </div>

  <!-- Remote drafts — only shown for Dev.to -->
  <div id="remote-drafts-container" style="display:none; margin-top:16px;">
    <h3>🌐 Remote Drafts</h3>
    <button class="btn btn-secondary btn-sm" id="btn-fetch-remote-drafts">
      Fetch Remote Drafts
    </button>
    <div id="remote-drafts-list" class="drafts-grid" style="display:none;"></div>
  </div>
</div>

Draft cards are rendered dynamically by the WebView JS and styled using VS Code's native CSS variables — they adapt to any theme automatically:

.draft-card {
    background: var(--vscode-editorWorkspace-background, #1e1e1e);
    border: 1px solid var(--vscode-editorWidget-border);
    border-left: 3px solid var(--vscode-button-background);
    border-radius: 8px;
    padding: 12px;
    transition: border-color 0.15s, box-shadow 0.15s;
}

.draft-card:hover {
    border-color: var(--vscode-focusBorder);
    box-shadow: 0 2px 8px rgba(0,0,0,0.12);
}

/* Badge colors */
.draft-badge.article { background: #8b5cf6; }  /* purple = local article */
.draft-badge.remote  { background: #10b981; }  /* green  = remote Dev.to */

/* Active draft gets a focus ring */
.draft-card--active {
    border-left-color: var(--vscode-focusBorder, #6c63ff);
    box-shadow: 0 0 0 1px var(--vscode-focusBorder, #6c63ff),
                0 2px 8px rgba(108, 99, 255, 0.15);
}

The border-left: 3px solid accent pattern is borrowed from VS Code's own Problems panel — instantly familiar to VS Code users without any learning curve.

Split-Editor Workflow

When you click Create Post for Dev.to or Medium, the extension creates (or opens) a named .md file and shows it in a side-by-side split next to the WebView panel:

if (config.workspaceType === 'blogs') {
    const workspacePath = vscode.workspace.workspaceFolders?.[0]?.uri.fsPath;
    if (!workspacePath) return;

    const mdFilePath = path.join(workspacePath, `dotshare-${platformKey}.md`);

    if (!fs.existsSync(mdFilePath)) {
        fs.writeFileSync(mdFilePath, `---
title: add ur title
tags: [add, tags, max, 4]
published: false
description: add ur description
---
Start writing your article here...
`, 'utf8');
    }

    vscode.workspace.openTextDocument(mdFilePath).then(doc => {
        // WebView = Column One, Markdown = Beside it
        vscode.window.showTextDocument(doc, vscode.ViewColumn.Beside);
    });
}

The file is named — dotshare-devto.md, dotshare-medium.md — not untitled. Named files persist across VS Code restarts, work naturally with git, and give you a free version-controlled article history. You can also open the file in any external editor and the Two-Way Sync will pick up the changes next time you hit "Read Current File."

The Full Flow in One Diagram

WebView                  MessageHandler       PostHandler          DraftsService / API
   │                          │                   │                      │
   │─ saveLocalDraft ────────►│                   │                      │
   │                          │─ includes('Draft')►│                      │
   │                          │                   │─ saveDraft() ────────►│
   │                          │                   │◄── Draft ────────────│
   │◄─ draftLoaded ───────────────────────────────│                      │
   │◄─ draftsLoaded ──────────────────────────────│                      │
   │                          │                   │                      │
   │─ loadLocalDraft ────────►│                   │                      │
   │                          │                   │─ getDraft() ─────────►│
   │◄─ draftLoaded ───────────────────────────────│                      │
   │                          │         mdEditor.edit() ◄──── Two-Way Sync
   │                          │                   │                      │
   │─ fetchDevToDrafts ──────►│                   │                      │
   │                          │                   │─ fetchDevToArticles()─►Dev.to API
   │◄─ remoteDraftsLoaded ────────────────────────│                      │

What's Next

The system solves the core problem. A few things I plan to add:

Auto-save on blur — checkpoint the draft every time the textarea loses focus, no button press needed
Draft preview — show the first 3 lines of the article inline in the draft card
Conflict detection — when a remote Dev.to draft differs from a local copy, show a diff

Try It

DotShare is free and open source under Apache 2.0. Try it out on your preferred registry:

VS Code Marketplace: Install DotShare (or run ext install freerave.dotshare)
Open VSX Registry: Available here (for VSCodium users)
GitHub: github.com/kareem2099/DotShare

Built by @FreeRave

Building a Universal Drafts System in a VS Code Extension — Part 1: Types & Storage

freerave — Sat, 25 Apr 2026 17:40:45 +0000

How I designed the Draft type, DraftsService, and the save/upsert flow that powers DotShare v3.2.5 — with full TypeScript code and the decisions behind every choice.

Before v3.2.5, DotShare had zero persistence. Write a 2,000-word Dev.to article in the WebView, switch tabs to check something, come back — gone. Reset. Empty form.

So I built a drafts system. This is Part 1: how I modeled the data and built the storage layer.

Part 2 covers the Two-Way Markdown Sync, Remote Dev.to Drafts, the WebView UI, and the Split-Editor workflow.

The Problem with WebViews

VS Code WebViews are iframes. They get suspended when not visible and fully reset on restart. For a tweet that's annoying. For a structured blog article with frontmatter, tags, cover image, and thousands of words — it's a real productivity loss.

The naive fix is "just auto-save to a file." But that creates new questions: which file? What about social posts that have no file? What if the user has multiple articles open? What about platform-specific metadata like Dev.to series or Medium publish status?

The solution needed to be universal — one system for social posts and blog articles, all 9 platforms, zero config for the user.

Designing the `Draft` Type

The first thing I did was sit down and define exactly what a "draft" means across all use cases.

A LinkedIn post draft needs: text content, platform, timestamp.
A Dev.to article draft needs: title, tags, description, cover image, canonical URL, series, body markdown, publish status, platform.

One interface had to cover both:

// src/types.ts

export type DraftType = 'social' | 'article';

export interface Draft {
    id: string;
    type: DraftType;
    timestamp: string;
    platforms: SocialPlatform[];
    data: PostData | BlogPost;
    title?: string;      // Human-readable label in the UI
    isRemote?: boolean;  // true = fetched from Dev.to API, not local
    remoteId?: string;   // Dev.to article ID for remote drafts
}

The data field is a union. PostData for social:

export interface PostData {
    text: string;
    media?: string[];  // local file paths
}

BlogPost for long-form articles:

export interface BlogPost {
    id?: string;
    title: string;
    bodyMarkdown: string;
    tags: string[];
    canonicalUrl?: string;
    description?: string;
    coverImage?: string;
    series?: string;
    status: 'draft' | 'published' | 'unlisted';
    platformId: 'devto' | 'medium';
    publishedAt?: string;
    url?: string;
}

This union lets a single draftsLoaded WebView message carry both types. The WebView switches behavior on draft.type — no separate message commands, no separate storage keys per platform.

The isRemote flag is critical: it marks drafts fetched from the Dev.to API. Remote drafts look identical to local ones in the UI but have different save semantics — you update them via API, not globalState.

Choosing the Storage Backend

I evaluated three options:

Option A — Write to a file in the workspace. Simple, but creates git noise, doesn't work if there's no workspace open, and fails for social post drafts that have no natural file home.

Option B — SQLite via a native module. Powerful, but native modules in VS Code extensions are a packaging nightmare. Cross-platform builds, .vsix size, and esbuild bundling issues ruled this out fast.

Option C — VS Code globalState. This is a key-value store backed by VS Code's own storage layer. It survives restarts, is encrypted at rest on macOS (Keychain), works even without a workspace, requires zero config, and the API is synchronous to read and async to write.

globalState was the obvious choice. The only real limitation is that it's not designed for large datasets — but a list of drafts with text content will comfortably stay under the internal limits for years.

The `DraftsService`

DraftsService wraps globalState with a clean CRUD interface. The full implementation:

// src/services/DraftsService.ts
import * as vscode from 'vscode';
import { Draft } from '../types';

const DRAFTS_KEY = 'dotshare_drafts_v1';

export class DraftsService {
    constructor(private globalState: vscode.Memento) {}

    getDrafts(): Draft[] {
        return this.globalState.get<Draft[]>(DRAFTS_KEY, []);
    }

    getDraft(id: string): Draft | undefined {
        return this.getDrafts().find(d => d.id === id);
    }

    saveDraft(data: Omit<Draft, 'id' | 'timestamp'>): Draft {
        const drafts = this.getDrafts();
        const draft: Draft = {
            ...data,
            id: `draft_${Date.now()}_${Math.random().toString(36).slice(2, 9)}`,
            timestamp: new Date().toISOString(),
        };
        this.globalState.update(DRAFTS_KEY, [draft, ...drafts]);
        return draft;
    }

    updateDraft(id: string, updates: Partial<Draft>): Draft | undefined {
        const drafts = this.getDrafts();
        const idx = drafts.findIndex(d => d.id === id);
        if (idx === -1) return undefined;
        drafts[idx] = {
            ...drafts[idx],
            ...updates,
            timestamp: new Date().toISOString(),
        };
        this.globalState.update(DRAFTS_KEY, drafts);
        return drafts[idx];
    }

    deleteDraft(id: string): void {
        this.globalState.update(
            DRAFTS_KEY,
            this.getDrafts().filter(d => d.id !== id)
        );
    }
}

Three decisions worth explaining:

_v1 on the key. If I ever change the schema, I read dotshare_drafts_v1, transform the data, write to dotshare_drafts_v2, then delete the old key. No migration scripts, no breaking changes for existing users.

Omit<Draft, 'id' | 'timestamp'> at save. This forces the compiler to prevent callers from passing a stale ID or a hand-crafted timestamp. IDs and timestamps are always generated internally, guaranteed fresh.

Newest first. [draft, ...drafts] prepends instead of appending. The WebView grid always shows the most recent work at the top without any sort step.

Wiring It Into the Handler Chain

DraftsService is instantiated once in MessageHandler and injected down into PostHandler. This keeps a single instance — one source of truth — across the extension's lifetime:

// src/handlers/MessageHandler.ts

export class MessageHandler {
    private draftsService: DraftsService;
    private postHandler: PostHandler;

    constructor(
        private view: vscode.WebviewView,
        private context: vscode.ExtensionContext,
        private historyService: HistoryService,
        private analyticsService: AnalyticsService,
        private mediaService: MediaService
    ) {
        this.draftsService = new DraftsService(context.globalState);

        this.postHandler = new PostHandler(
            view,
            context,
            historyService,
            analyticsService,
            mediaService,
            this.draftsService  // ← injected
        );
    }
}

Routing is handled by a string check — any command that includes the word Draft goes to PostHandler:

if (
    cmd.startsWith('share') ||
    cmd === 'generatePost'  ||
    cmd === 'readMarkdownFile' ||
    cmd.includes('Draft')      // ← catches all 7 draft commands
) {
    await this.postHandler.handleMessage(message);
}

This keeps the routing table flat and readable. Adding a new draft command in the future requires zero changes to MessageHandler.

The Save/Upsert Pattern

The saveLocalDraft handler is the most-called draft command. It does an upsert — not a blind insert:

private async handleSaveLocalDraft(message: Message): Promise<void> {
    const draft = message.draft as Omit<Draft, 'id' | 'timestamp'>;

    if (!draft) {
        this.sendError('Draft data is required.');
        return;
    }

    // Guard: remote drafts cannot be cloned locally
    if ((draft as Draft).isRemote) {
        this.sendError('Cannot save a remote draft locally. Use "Update" instead.');
        return;
    }

    const existingId = message.draftId as string | undefined;

    if (existingId) {
        // Update existing draft in place
        const updated = this.draftsService.updateDraft(existingId, draft);
        if (updated) {
            this.sendInfo('Draft updated!');
            this.view.webview.postMessage({ command: 'draftLoaded', draft: updated });
        } else {
            this.sendError('Draft not found for update.');
        }
    } else {
        // Create new draft
        const saved = this.draftsService.saveDraft(draft);
        this.sendInfo('Draft saved locally!');
        this.view.webview.postMessage({ command: 'draftLoaded', draft: saved });
    }

    // Always refresh the list
    await this.handleListLocalDrafts();
}

The upsert is essential. The first save creates a new draft and the WebView receives its ID via draftLoaded. Every subsequent save passes that ID back in message.draftId. Without this, every Ctrl+S would create a duplicate entry.

The remote guard is equally important. If someone somehow triggers a save on a remote draft, the handler rejects it with a clear error rather than silently creating a stale local copy that would immediately diverge from the Dev.to version.

After every save or update, handleListLocalDrafts runs and pushes the full refreshed list to the WebView — so the draft grid always reflects the current state without a manual refresh.

What's in Part 2

The storage layer is done. In Part 2, we cover:

loadLocalDraft — the Two-Way Markdown Sync that rewrites the active .md editor file when you load a draft
fetchDevToDrafts — fetching remote Dev.to articles and mapping them to the Draft interface
resetBlogMarkdown — the Reset Boilerplate button
The WebView UI — the HTML, draft card CSS, and how {{PLATFORM_NAME}} tokens get injected
Split-Editor workflow — how opening Dev.to or Medium auto-creates a named .md file beside the WebView panel

Try It

DotShare is free and open source under Apache 2.0:

VS Code Marketplace: Download Extension (or search ext install freerave.dotshare)
Open VSX Registry: Download for VSCodium
GitHub: github.com/kareem2099/DotShare

If this saved you time, a ⭐ on the repo means a lot!

Built by @FreeRave

The Vercel Breach: What Actually Happened, Why It Matters, and What Every Developer Should Do Right Now

freerave — Sun, 19 Apr 2026 21:39:40 +0000

A deep technical breakdown of the April 2026 Vercel security incident — supply chain risks, GitHub token exposure, NPM hijacking, and what you need to rotate right now

It started, as many supply chain nightmares do, quietly.

Today, Vercel — the cloud platform powering millions of production deployments, the company behind Next.js, the infrastructure quietly sitting between your code and your users — confirmed a security incident.

A threat actor claiming to be part of the notorious ShinyHunters group posted on BreachForums offering what they claim is Vercel's internal data for $2 million. The alleged haul: access keys, source code, employee accounts, NPM tokens, GitHub tokens, and database records pulled from Vercel's internal Linear and user management systems.

This isn't just a Vercel story. This is a story about where we build, how we trust, and what we're gambling every time we push to production.

What We Actually Know

Let's be precise. In security, the gap between "someone claimed" and "confirmed" is everything.

✅ Confirmed by Vercel:

Unauthorized access to certain internal Vercel systems occurred
A limited subset of customers was affected
Incident response experts have been engaged
Law enforcement has been notified
Services remain operational

⚠️ Claimed by the threat actor (unverified):

Access to multiple employee accounts with access to internal deployments
Exfiltration of API keys, NPM tokens, and GitHub tokens
Access to Vercel's internal Linear instance
~580 employee records exposed (names, emails, account statuses, timestamps)
A $2 million ransom demand, with alleged negotiations underway

Important nuance: Members of the actual ShinyHunters group have denied involvement to BleepingComputer. The attacker may be using the name for credibility. This doesn't make the breach less real — it just means attribution is murky.

Why Vercel Is a Crown Jewel Target

If you were a sophisticated attacker looking for maximum blast radius from a single breach, you'd want a platform that:

Holds secrets for thousands of applications — environment variables, API keys, OAuth credentials
Has deep CI/CD pipeline integration — build access means potential code tampering
Is trusted implicitly by its customers — developers don't audit their deployment platforms
Connects to everything — GitHub, npm, databases, third-party APIs

Vercel checks every box.

This attack pattern has a name: Supply Chain Compromise. The ROI for attackers is extraordinary — compromise one platform, potentially reach thousands of organizations downstream.

You're not just trusting Vercel with your code. You're trusting them with your keys to everything else.

The Linear Connection: Why Internal Tooling Is a Goldmine

One of the more alarming details is the alleged access to Vercel's Linear instance — their internal project management tool.

Why does this matter? Internal issue trackers are treasure maps. They contain:

Bug reports that reveal unpatched vulnerabilities
Architecture discussions that expose system design
Credentials accidentally pasted in comments (it happens more than anyone admits)
Incident post-mortems that document past weaknesses
Roadmap items that reveal future attack surfaces

An attacker with read access to your Linear isn't just reading tickets — they're reading a detailed, timestamped history of your organization's security posture, written honestly for internal consumption.

The GitHub Token Problem

GitHub tokens are particularly dangerous in this context.

When Vercel integrates with your GitHub, it requests OAuth scopes to read and deploy your repositories. If an attacker gains those tokens — even read-only — they can:

Clone private repositories, including ones you've never deployed
Read secrets patterns in CI/CD config files
Map your entire codebase architecture before you even know they're in

Write-access tokens are catastrophically worse: code injection, backdoor planting, supply chain poisoning of your own downstream users.

💡 Important Note:
OAuth integration tokens aren't "login credentials." They're keys to your intellectual property and potentially to your users' security.

NPM Tokens and the Ecosystem Risk

NPM tokens in the wrong hands enable package hijacking.

If an attacker gains publish access to any npm package — even a small utility with a few thousand weekly downloads — they can push a malicious version that:

Exfiltrates environment variables from any project that installs it
Plants persistent backdoors in Node.js processes
Harvests secrets from CI/CD build environments

The npm ecosystem's trust model is implicit: you install a package, you trust everyone who's ever had publish access to it. A compromised NPM token doesn't just affect one package — it affects every developer downstream.

This is why npm audit alone isn't enough. You need to think about who has publish access to your dependencies, not just what their current code does.

Encryption At Rest Is Not The Defense You Think It Is

A common misunderstanding in incidents like this:

"They encrypt environment variables, so we're safe."

Encryption at rest protects data when the storage medium is physically stolen — a hard drive pulled from a server, a backup tape taken off-site. It doesn't protect you when the attacker has authenticated access to the systems that do the decryption.

If an attacker has compromised employee accounts with access to internal deployments, those accounts can request decrypted values through the normal application interface. The encryption layer never gets a chance to protect you because the request looks legitimate.

Mental model:

Encrypting your house key and leaving the encrypted version on the front door doesn't help if the attacker also steals the decryption key.

This is the fundamental difference between encryption at rest (protects the storage) and access control (protects who can use it). The breach wasn't about cracking encryption — it was about gaining credentials the system already trusts.

What "Limited Subset of Customers" Actually Means

Vercel's disclosure says a "limited subset of customers" was affected. This phrasing is technically precise but practically unhelpful during an active investigation.

In security incident response, the professional assumption is:

"Until we can prove we're not affected, we assume we are."

This isn't paranoia. This is how you avoid being the organization that said "we're probably fine" and then found out three months later they weren't.

🚨 What You Should Do Right Now

These are not hypothetical best practices. These are immediate actions.

1. Rotate Your GitHub OAuth Integration

Go to GitHub → Settings → Applications → Authorized OAuth Apps and revoke Vercel's access. Then re-authorize from the Vercel dashboard. This invalidates any tokens the attacker may have obtained.

Do this even if you think you're not affected.

2. Rotate All Credentials Stored in Vercel

Any credentials stored as environment variables should be treated as potentially exposed. Log into each service and regenerate:

Upstash REST tokens
Database connection strings (Postgres, MySQL, MongoDB)
Redis AUTH passwords
Any other stateful service credentials

Update the new values in Vercel and redeploy.

3. Audit Your NPM Tokens

If you publish npm packages and your token was stored in Vercel:

Immediately revoke the token from npmjs.com → Access Tokens
Audit recent publish history for any packages you own
Create a new token with minimum required scope

4. Review Connected OAuth Apps

Check every OAuth app connected to your GitHub account. Remove anything you don't actively use. Review the list for any apps you don't recognize — attackers with token access can potentially authorize new ones.

⚠️ MASSIVE GOTCHA: The Reddit API Trap (Don't Delete Your Apps!)

If your application uses Reddit as an OAuth provider, STOP before you delete your current credentials to rotate them.

While rotating keys for my own projects tonight, I discovered that Reddit quietly ended Self-Service API access for developers. Because Reddit's legacy UI doesn't have a "Regenerate Secret" button, the standard practice was to delete the app and create a new one.

Do not do this right now. If you delete your app, you cannot create a new one instantly. You will be prompted to submit a manual API Access Request ticket and wait for approval, completely breaking your auth flow in the meantime.

The Fix:

You must still delete the exposed Reddit app to secure your system.
Temporarily disable the Reddit login flow on your frontend/auth server so users don't hit a 401 Unauthorized error.
Submit the approval ticket via Reddit's Help Center (specify that you are building an external OAuth flow and need the identity scope).
Wait for their approval to get your new keys.

5. Check Your Build Logs

Recent Vercel build logs might contain credentials accidentally printed by build scripts. Review them for anything that looks like it shouldn't be there.

6. Enable GitHub Secret Scanning

GitHub scans for committed secrets across your repositories. Enable it. If any credential was ever accidentally committed — even in a commit later reverted — GitHub can detect and alert you.

The Deeper Problem: Trust Transference in Modern Infrastructure

Every time you add a third-party integration to your stack, you're extending your trust boundary. You're saying:

"I trust this service not just to do its job, but to protect my secrets, secure its own infrastructure, and tell me promptly when something goes wrong."

Most developers accept this bargain without thinking about it.

The Vercel breach should prompt a deliberate conversation about trust transference:

Which platforms hold your secrets?
What's the blast radius if any one of them is breached?
How quickly would you know?
How quickly could you respond?

This isn't a reason to abandon cloud platforms. It's a reason to build rotation infrastructure — the automation and processes that let you cycle credentials quickly when something goes wrong, without bringing down production.

If rotating your secrets takes more than 30 minutes, you have a resilience problem.

What To Watch For From Vercel

In the coming days, watch for:

Root cause disclosure — How did the attacker initially gain access? Social engineering? A compromised employee credential? A vulnerability in internal tooling? This matters enormously for the broader developer community.

Scope clarification — "Limited subset" needs to become specific numbers and categories. Were customer environment variables accessed? Were build pipelines tampered with?

Token invalidation — Ideally, Vercel should proactively invalidate all GitHub OAuth tokens and force re-authorization platform-wide, rather than leaving discovery to individual developers.

Third-party audit results — Engaging incident response experts is good. Publishing what those experts find, even in summarized form, is what turns a security incident into a trust-building exercise.

Closing: The Price of Convenience

The developer experience Vercel offers is genuinely exceptional. git push and your app is live, globally distributed, HTTPS, preview environments, CI/CD. It's magic.

But magic has a cost. The same integration depth that makes the experience seamless also means a platform breach has an unusually large potential blast radius. The convenience of storing secrets "in the platform" means trusting the platform to protect them.

Neither of these things is a reason to stop using Vercel. They're reasons to be intentional about what you store there, to have rotation procedures in place before you need them, and to follow security bulletins from your infrastructure providers the way you follow CVE disclosures for your own dependencies.

The breach happened. The question now is how fast you respond.

Follow Vercel's official bulletin for updates:
🔗 vercel.com/kb/bulletin/vercel-april-2026-security-incident

Questions about rotating credentials or hardening your deployment pipeline? Drop them in the comments — happy to help.

The Hotfix Chronicles: What Broke After the Nexus Release and How I Fixed It (v1.5.2 & v1.5.3)

freerave — Fri, 17 Apr 2026 12:46:26 +0000

I promised I'd fix it. Here's exactly what broke in DotGhostBoard after v1.5.1 — PyInstaller frozen environments, insecure /tmp update paths, missing UI assets, and a polkit regression — and how each one was resolved.

This is a follow-up to Engineering the Nexus Release. At the end of that article I wrote: "Stay tuned for v2.0.0 Cerberus." Before Cerberus ships, there's something I owe you — the full post-mortem on what broke in production immediately after that release.

Check out the v1.5.3 highlight reel to see the new Live Terminal and Network Sync in action:

What Happened After v1.5.1 Shipped

The Nexus architecture held. mDNS discovery worked. E2EE pairing worked. The sync engine worked.

What didn't work: the UI didn't load on any bundled build.

Users who downloaded the .AppImage or .deb were greeted with a white window. No stylesheet. No dark theme. Just a blank Qt frame. The app was running — but blind.

That was the beginning of the v1.5.2 → v1.5.3 hotfix sprint.

Bug 1 — The White Window (PyInstaller Frozen Environment)

Root Cause

When PyInstaller bundles an app, it doesn't just copy files — it extracts them into a temporary directory at runtime called sys._MEIPASS. The problem is that code like this:

# ❌ Breaks in bundled builds
base = os.path.dirname(__file__)
qss_path = os.path.join(base, "ui", "ghost.qss")

...works perfectly when you run python main.py from source, because __file__ points to the project root. But inside a frozen .AppImage, __file__ resolves to a virtual path inside the bundle — and ghost.qss is nowhere near it.

  Source mode:    __file__ → /home/user/DotGhostBoard/core/app.py  ✅
  Frozen mode:    __file__ → /tmp/_MEI3xk9/core/app.py             ✅
                  ghost.qss → ???                                   ❌

The UI stylesheet ghost.qss simply couldn't be found. Qt silently fell back to its default theme. White window.

The Fix: `resource_path` Bridge

# core/paths.py
import os
import sys


def _base_dir() -> str:
    """
    Detect whether we're running from source or a PyInstaller bundle.
    In frozen mode, all assets are extracted to sys._MEIPASS at runtime.
    """
    if getattr(sys, "frozen", False) and hasattr(sys, "_MEIPASS"):
        return sys._MEIPASS          # PyInstaller extraction folder
    return os.path.dirname(           # two levels up from core/paths.py
        os.path.dirname(os.path.abspath(__file__))
    )


def resource_path(*parts: str) -> str:
    """
    Build an absolute path to any bundled asset, regardless of runtime mode.

    Usage:
        resource_path("ui", "ghost.qss")   →  /tmp/_MEIxxxx/ui/ghost.qss
        resource_path("data", "icon.png")  →  /home/user/Project/data/icon.png
    """
    return os.path.join(_base_dir(), *parts)

Decision flow:

  App requests: resource_path("ui", "ghost.qss")
                          │
                    is_frozen?
                   /         \
                 Yes           No
                  │             │
          sys._MEIPASS    Project Root
                  │             │
    /tmp/_MEIxxxx/ui/ghost.qss  /home/user/.../ui/ghost.qss

Every asset reference in the codebase was updated to go through resource_path(). The white window was gone.

The CI Side of This Bug

But wait — local builds worked. CI builds didn't. Why?

Because the PyInstaller command in the workflow was missing the --add-data directive for the UI directory:

# ❌ v1.5.1 — ghost.qss never made it into the bundle
- name: Build
  run: |
    pyinstaller --noconsole --onedir \
      --add-data "data:data" \
      --hidden-import "PyQt6.sip" \
      --name dotghostboard main.py

# ✅ v1.5.3 — explicitly map the UI directory
- name: Build
  run: |
    pyinstaller --noconsole --onedir \
      --add-data "data:data" \
      --add-data "ui/ghost.qss:ui" \    # ← this line was the missing piece
      --hidden-import "PyQt6.sip" \
      --hidden-import "cryptography" \
      --hidden-import "cryptography.hazmat.primitives.asymmetric.x25519" \
      --hidden-import "cryptography.hazmat.primitives.ciphers.aead" \
      --name dotghostboard main.py

The --add-data syntax is "source:dest" — it maps the source path on the build machine to the relative path inside _MEIPASS. Without it, PyInstaller doesn't know the file exists and silently skips it.

The deceptive part: local pyinstaller builds work because pyinstaller finds ui/ghost.qss relative to the working directory. The GitHub Actions runner has a clean checkout with the same structure — but without explicit --add-data, the file is excluded from the bundle spec. Same command, different behavior depending on how PyInstaller resolves paths in its analysis phase.

You can verify any .deb build has the file:

dpkg -c dotghostboard_1.5.3_amd64.deb | grep ui/
# Expected: ... _internal/ui/ghost.qss

Bug 2 — Insecure Update Download Path

In v1.5.1, the in-app "Download Update" feature used /tmp/ as the staging area:

# ❌ v1.5.1
download_path = f"/tmp/dotghostboard_{version}_amd64.deb"

/tmp/ is world-readable, world-writable, and wiped on reboot. For a one-time download that's fine. For a security tool that downloads and installs packages — it's a TOCTOU (Time-Of-Check to Time-Of-Use) attack surface. An attacker with local access could replace the .deb between download and installation.

The Fix: User-Specific Sandbox

# ✅ v1.5.2+
import os

def get_update_staging_dir() -> str:
    """
    Returns a user-specific, restricted directory for staging update packages.
    Created with mode 0o700 — only the owning user can read or write.
    """
    path = os.path.join(
        os.path.expanduser("~"),
        ".local", "share", "dotghostboard", "updates"
    )
    os.makedirs(path, mode=0o700, exist_ok=True)
    return path

SAFE_PATH = os.path.join(get_update_staging_dir(), f"dotghostboard_{version}_amd64.deb")

	v1.5.1	v1.5.2+
Download path	`/tmp/`	`~/.local/share/dotghostboard/updates/`
Readable by other users	Yes	No (`0o700`)
Survives reboot	No	Yes
Integrity check	None	SHA-256 (v1.5.3)

The Kamikaze Installer

The install script itself also needed hardening. After dpkg -i finishes, no artifacts should remain:

#!/bin/sh
# dotghostboard_install.sh — self-destructs after use

SAFE_PATH="$1"

dpkg -i "$SAFE_PATH"   # Install the package
rm -f "$SAFE_PATH"     # Wipe the .deb from disk
rm -f "$0"             # Wipe this script itself

Nothing lingers. No old .deb sitting in a directory. No script to be re-executed.

Bug 3 — Polkit SUID Regression on Kali

Kali Linux (and some hardened Arch setups) occasionally strip or reset the SUID bit on /usr/bin/pkexec after system updates. This caused the in-app "Download & Install" button to fail silently — pkexec would return a permission error, and the UI would just hang.

The fix was embedded directly in the package's postinst script — it runs as root immediately after dpkg -i completes:

#!/bin/sh
# DEBIAN/postinst

set -e

fix_pkexec() {
    PKEXEC="/usr/bin/pkexec"
    if [ -f "$PKEXEC" ]; then
        CURRENT_PERMS=$(stat -c "%a" "$PKEXEC")
        if [ "$CURRENT_PERMS" != "4755" ]; then
            echo "dotghostboard: repairing pkexec SUID bit ($CURRENT_PERMS → 4755)"
            chmod 4755 "$PKEXEC"
        fi
    fi
}

case "$1" in
    configure)
        fix_pkexec
        ;;
esac

exit 0

Logic flow:

  dpkg -i dotghostboard_1.5.3_amd64.deb
         │
         └── postinst runs as root
                  │
            /usr/bin/pkexec exists?
                  │
            current perms == 4755?
            /              \
          Yes               No
           │                 │
         Skip           chmod 4755
                             │
                    "Download & Install" works

This is controversial — touching SUID bits in a postinst script is aggressive. But the alternative is users filing issues that are impossible to debug remotely, or writing a setup guide that says "run chmod 4755 /usr/bin/pkexec after installing." The autorepair is the lesser evil.

Feature: Live Terminal Log (v1.5.3)

While fixing the above bugs, I replaced the old "Please Wait..." dialog during updates with a live terminal stream. It felt wrong to show a spinner while dpkg was doing real work with real output.

Architecture

# ui/update_log_screen.py
from PyQt6.QtCore import QThread, pyqtSignal
import subprocess


class InstallWorker(QThread):
    log_line = pyqtSignal(str)   # emitted for every line of dpkg output
    finished = pyqtSignal(int)   # exit code

    def __init__(self, script_path: str):
        super().__init__()
        self.script_path = script_path

    def run(self):
        process = subprocess.Popen(
            ["bash", self.script_path],
            stdout=subprocess.PIPE,
            stderr=subprocess.STDOUT,   # merge stderr into stdout
            text=True,
            bufsize=1                   # line-buffered
        )
        for line in process.stdout:
            self.log_line.emit(line.rstrip())

        process.wait()
        self.finished.emit(process.returncode)

On the UI side:

# Color mapping — Regex-based, no AI required
import re
from PyQt6.QtGui import QColor

COLOR_MAP = [
    (re.compile(r'\berror\b',   re.I), "#FF5555"),   # red
    (re.compile(r'\bwarning\b', re.I), "#FFB86C"),   # amber
    (re.compile(r'\bSetting up\b|\bProcessing\b'), "#50FA7B"),  # green
    (re.compile(r'^--'),                             "#8BE9FD"),  # cyan for steps
]

def colorize(line: str) -> str:
    for pattern, color in COLOR_MAP:
        if pattern.search(line):
            return f'<span style="color:{color}">{line}</span>'
    return line  # default — white

def on_log_line(self, line: str):
    self.log_box.append(colorize(line))
    # Auto-scroll to bottom
    sb = self.log_box.verticalScrollBar()
    sb.setValue(sb.maximum())

The blinking cursor is driven by a QTimer — no threads, no complexity:

self._cursor_visible = True
self._cursor_timer = QTimer()
self._cursor_timer.timeout.connect(self._blink_cursor)
self._cursor_timer.start(500)  # 500ms interval

def _blink_cursor(self):
    self._cursor_visible = not self._cursor_visible
    self.cursor_label.setText("█" if self._cursor_visible else " ")

Verification Checklist

For any future hotfix, these three commands confirm the build is clean:

# 1. Confirm ghost.qss is inside the bundle
dpkg -c dotghostboard_1.5.3_amd64.deb | grep ui/
# Expected: ./opt/dotghostboard/_internal/ui/ghost.qss

# 2. Verify SUID bit post-install
ls -l /usr/bin/pkexec
# Expected: -rwsr-xr-x (the 's' in position 4 is the SUID bit)

# 3. Test resource_path in frozen mode (AppImage)
./DotGhostBoard-1.5.3-x86_64.AppImage --debug-paths
# Should print resolved paths for ghost.qss and icon_256.png

What I Learned

PyInstaller's --add-data is not optional for anything outside data/. If your app loads a file at runtime that isn't in the directory you passed to --add-data, it won't be in the bundle. PyInstaller doesn't warn you. The app just crashes or falls back silently. Map every resource directory explicitly.

sys._MEIPASS is the only reliable truth in a frozen environment. Don't use __file__, don't use os.getcwd(), don't use relative paths. _MEIPASS is where PyInstaller extracted everything — it's the only path you can trust.

/tmp/ is fine for scratch. It's not fine for security-sensitive staging. The threat model for a clipboard manager that stores secrets is different from a text editor. The update pipeline needed to match that model.

Local builds working ≠ CI builds working. The ghost.qss bug existed for the entire v1.5.x series in bundled form because nobody had tested a clean AppImage build from the CI artifact — only local PyInstaller runs. Add artifact smoke testing to your release checklist.

What's Next — v2.0.0 Cerberus

The hotfix series is closed. v1.5.3 is stable.

Next up is Cerberus — the Zero-Knowledge Password Vault. The AES-256 foundation from v1.4.0 (Eclipse) is already in place. The design is locked:

Isolated vault.db — separate file, separate connection, locked when idle
Pattern-based secret detection — JWT, AWS keys (AKIA...), GitHub tokens (ghp_...), high-entropy hex — shape-based, not keyword-based
Auto-clear: wipes clipboard 30 seconds after a Vault paste
Paranoia Mode: suspends all DB writes on demand

The core principle of Cerberus: a 1500-word article that contains the word "password" doesn't trigger detection. A 40-character base64 string with high Shannon entropy does.

Download

	Link
📦 GitHub Release (AppImage + DEB + GPG sigs)	v1.5.3
🖥️ OpenDesktop	DotGhostBoard
💻 Source	kareem2099/DotGhostBoard

DotSuite — built for the shadows 👻

We Hit 2,500 in 15 Days — And I Want to Make Every Dev Lazier (Productively)

freerave — Thu, 16 Apr 2026 18:15:34 +0000

I set a goal at the start of April: reach 2,500 followers on dev.to by April 30th.

We hit 2,631 by April 15th.

Half the month. So before I sprint to the next goal, I want to stop, look back, and say a real thank you — not the generic "thanks for the support 🙏" kind. The honest kind.

What you actually did

You read the articles. You left comments that pushed me to think harder. You shared the DotShare posts and the Reddit API deep-dives with people who needed them. Some of you went through the dotUniverse terminal, found the Easter eggs, and DMed me screenshots. That made my week every single time.

You didn't just follow — you engaged. That's the difference.

The honest confession: I'm lazy. That's why I built 20+ tools.

Here's the real origin story of the entire DotSuite ecosystem.

I didn't build these tools because I'm a passionate open-source hero. I built them because I kept running into tasks I did not want to do manually ever again.

DotShare — because I wasn't opening 8 browser tabs every time I wanted to post something
dotenvy — because I forgot my .env variables once and lost two hours of debugging
DotGhostBoard — because my clipboard was an absolute disaster
dotcommand — because I kept forgetting terminal commands that I wrote myself
DotScramble — because blurring faces manually in screenshots is soul-crushing
CodeTune — because I needed prayer times and Quran without leaving VS Code
dotsense — because I genuinely couldn't tell when I was burning out until it was too late

The pattern is obvious. Every tool exists because past-me was too lazy to keep doing something the hard way.

Laziness, scaled properly, is just engineering.

The full arsenal — everything built so far

Here's every tool in the DotSuite ecosystem, in case you missed any:

VS Code Extensions

Tool	What it does	Downloads
DotShare	Post to 9 platforms (LinkedIn, X, Reddit, Bluesky, Telegram, Facebook, Discord, dev.to, medium) with AI content creation via Gemini, GPT-4 & Claude	1,979+
dotenvy	Environment manager with Git branch auto-switching, AI secret detection (35-feature ML model), Doppler sync & encrypted backups	1,130+
dotcommand	Intelligent command manager, ML suggestions, 180+ prepared commands, analytics dashboard	909+
CodeTune	Islamic dev environment — Quran player (15+ reciters), prayer times, focus mode, Dhikr counters	899+
DotFetch	Professional HTTP client with .env support, collections, cURL import/export	692+
DotReadme	README optimizer — quality audit (A+ to F), badge inserter, TOC generator, AI enhancement (BYOK)	515+
dotsense	AI developer wellness — ML mood detection, burnout prevention, peak performance analytics	129+
dotconvert	Data converter — Base64, XML↔JSON, CSV↔JSON (Marketplace listing coming soon)	—

Total VS Code downloads across Marketplace + Open VSX: 6,253+

CLI Tools

Tool	What it does
DotGhostBoard	Linux clipboard manager — AES-256 encryption, tag system, thumbnail previews, master password lock
DotScramble	Image privacy studio — face/license plate detection, 8 blur effects, batch processing, RTL Arabic support

Telegram Bots

Tool	What it does
DotDownloader	Multi-platform media downloader — Instagram, TikTok, YouTube, Reddit, Spotify & more. Referral system + premium tiers
DotFormate	File format conversion — PDF, DOCX, PPTX, images, OCR. PayPal integration + R2 cloud storage
DotShare-Auth-Server	Secure OAuth toolkit — magic link auth, LinkedIn & Reddit & X & Facebook OAuth, session management

Mobile Apps

Tool	What it does
DotReminder	Android reminder app — AI assistant (Gemini 2.5 Flash), location-based reminders, biometric auth, 2FA
DOTShredzilla	Workout tracker — offline-first, Firebase-synced, Kotlin + Jetpack Compose
DotBurn	Gym and calorie system management

Premium / Private

Tool	What it does
dotctl (invite only)	Advanced traffic control for network security experts — ARP spoofing, bandwidth limiting, DPI & ML traffic analysis

Coming Soon

Tool	What it does
DotTransfer	Transfer files between workspaces directly inside VS Code
dotsuite	Portfolio & distribution platform — Next.js 16, multi-language (EN/AR/FR/DE/RU), GitHub webhooks, product reviews

Where the April challenge stands right now

dev.to was the first goal to fall. Here's the full scoreboard:

Platform	Now	Goal	Progress
📝 dev.to	2,631	2,500	✅ DONE
💼 LinkedIn	396	500	79%
🎵 TikTok	33	100	33%
▶️ YouTube	29	100	29%
✍️ Medium	2	50	4%
📘 Facebook	13	50	26%
📸 Instagram	7	50	14%
𝕏 X / Twitter	16	500	3%
🦋 Bluesky	11	50	22%

Some of these are painful to look at. X at 3% is basically a comedy sketch. But the scoreboard stays public. That's the whole point.

What's shipping next

DotShare v3.2 — Reddit media uploads are almost stable. The S3 presigned pipeline is wired. The last debug session was brutal and I wrote every painful detail here.
dotenvy — The LLM layer for environment/config management deserves a proper release article. The architecture is the interesting part.
dotUniverse Terminal 2.0 — Piping support, SSH simulation, VIM-lite. Q2 target.
dotsuite — The full portfolio platform goes live this year.

The part that actually matters

I'm self-taught. I'm building all of this from a small city in Egypt, mostly at night, mostly alone. No team, no VC funding, no algorithm boost.

Every follow, reaction, and comment is a real person who decided this was worth their time.

2,631 of you did that. I don't take it lightly.

The next target is 3,000. Based on the current trajectory, I give it two weeks. Let's find out.

Try the tools

Live portfolio: https://kareem2099.github.io/dotuniverse/
GitHub: https://github.com/kareem2099
All tools: open the terminal on dotUniverse and type ls ~/tools

My message to every developer reading this: be productively lazy. Automate the annoying thing. Build the tool. Then build the tool that builds the tool. That's how 20+ projects happen.

Built with caffeine and the stubborn belief that open-source from Egypt can reach the whole internet.

— Kareem / FreeRave 🦥

Engineering the Nexus Release: How I Built Secure E2EE Network Sync into a Linux Clipboard Manager (v1.5.1)

freerave — Wed, 15 Apr 2026 20:28:57 +0000

A deep dive into the architecture behind DotGhostBoard v1.5.0 — zero-config mDNS discovery, X25519 ECDH pairing, AES-256-GCM sync, rate limiting, and PyQt6 threading — all without a central server.

DotGhostBoard is a privacy-first clipboard manager for Linux, built under the DotSuite umbrella. No telemetry. No Electron. No cloud. Pure PyQt6 + SQLite.

📦 GitHub Release v1.5.1 · 🖥️ OpenDesktop

Why This Was Hard

Building a clipboard manager is trivial. Building one that syncs securely across devices on a local network without a central server, without trusting the network, and without ever sending data to the cloud — that's a different problem.

With v1.5.0 (Nexus), I rebuilt the core architecture from scratch to solve exactly that. Here's what the final system looks like before we dive into each layer:

  ┌─────────────────────────────────────────────────────────────┐
  │                     LOCAL NETWORK (LAN)                     │
  │                                                             │
  │   ┌──────────────┐   mDNS Discovery    ┌──────────────┐    │
  │   │  Device A    │ ◄──────────────────► │  Device B    │    │
  │   │  (Arch)      │                      │  (Kali)      │    │
  │   │              │   X25519 Handshake   │              │    │
  │   │  ghostboard  │ ──── PIN + ECDH ───► │  ghostboard  │    │
  │   │              │                      │              │    │
  │   │  HTTPServer  │ ◄── AES-256-GCM ──── │  HTTPServer  │    │
  │   │  :PORT       │   /api/sync E2EE     │  :PORT       │    │
  │   └──────┬───────┘                      └──────┬───────┘    │
  │          │                                     │            │
  │       ghost.db                              ghost.db        │
  │    (trusted_peers)                       (trusted_peers)    │
  └─────────────────────────────────────────────────────────────┘

Three layers. Each one independently secure. Let's break them down.

Layer 1 — Zero-Config Device Discovery (mDNS)

The first UX problem: how do devices find each other without the user typing an IP address?

Answer: mDNS via zeroconf. Every device broadcasts itself on the LAN under a custom service type _dotghost._tcp.local.. Other instances listen and populate the UI automatically.

Because the app runs on PyQt6, the discovery engine lives in its own QThread — blocking network I/O never touches the main thread:

# core/network_discovery.py
import socket
from zeroconf import ServiceBrowser, Zeroconf, ServiceInfo, IPVersion
from PyQt6.QtCore import pyqtSignal, QThread

_SERVICE_TYPE = "_dotghost._tcp.local."


class DotGhostDiscovery(QThread):
    peer_found = pyqtSignal(str, str, str, int)  # node_id, name, ip, port
    peer_lost  = pyqtSignal(str)                 # node_id

    def __init__(self, node_id: str, device_name: str, port: int):
        super().__init__()
        self.node_id     = node_id
        self.device_name = device_name
        self.port        = port
        self.zeroconf    = None

    def run(self):
        self.zeroconf = Zeroconf(ip_version=IPVersion.V4Only)

        properties = {
            b'node_id':     self.node_id.encode('utf-8'),
            b'device_name': self.device_name.encode('utf-8'),
            b'version':     b'1',
        }

        instance_name = f"{self.node_id}.{_SERVICE_TYPE}"

        self.info = ServiceInfo(
            type_=_SERVICE_TYPE,
            name=instance_name,
            addresses=[socket.inet_aton(get_local_ip())],
            port=self.port,
            properties=properties,
            server=f"{self.node_id}.local."
        )

        self.zeroconf.register_service(self.info)
        self.browser = ServiceBrowser(self.zeroconf, _SERVICE_TYPE, self)
        self.exec()  # Qt event loop keeps the thread alive

    # ── zeroconf callbacks ──────────────────────────────────────

    def add_service(self, zc: Zeroconf, type_: str, name: str):
        info = zc.get_service_info(type_, name)
        if not info:
            return

        props    = info.properties
        node_id  = props.get(b'node_id', b'').decode()
        dev_name = props.get(b'device_name', b'Unknown').decode()

        if node_id == self.node_id:  # skip self
            return

        ip = socket.inet_ntoa(info.addresses[0])
        self.peer_found.emit(node_id, dev_name, ip, info.port)

    def remove_service(self, zc: Zeroconf, type_: str, name: str):
        node_id = name.replace(f".{_SERVICE_TYPE}", "")
        self.peer_lost.emit(node_id)

    def stop(self):
        if self.zeroconf:
            self.zeroconf.unregister_service(self.info)
            self.zeroconf.close()
        self.quit()

Why QThread and not threading.Thread?
peer_found and peer_lost are pyqtSignals. They cross the thread boundary safely into the main UI thread via Qt's queued connection mechanism. Using a raw Python thread here would cause a race condition against the UI.

Layer 2 — Secure Device Pairing (X25519 + PBKDF2 + AES-GCM)

Finding a peer is one thing. Trusting it is another.

A local network isn't inherently safe — public Wi-Fi, ARP spoofing, a compromised router. The pairing protocol defends against all of it with a three-phase handshake:

  Device A                              Device B
     │                                     │
     │  1. Generate ephemeral X25519 key   │
     │  2. Derive wrap key from PIN+salt   │
     │  3. Encrypt pubkey → send ─────────►│
     │                                     │  4. Decrypt pubkey with PIN+salt
     │                                     │  5. Generate ephemeral X25519 key
     │◄──────────────── send encrypted ────│  6. Derive shared secret (ECDH)
     │                                     │  7. Encrypt own pubkey → send
     │  8. Derive shared secret (ECDH)     │
     │  9. Discard ephemeral keys          │  9. Discard ephemeral keys
     │                                     │
     │      Shared Secret stored in DB     │

The PIN is a 6-digit out-of-band value shown on both screens — a human-verified channel that breaks any MITM attempt. Even if an attacker intercepts the traffic, they can't decrypt the public keys without the PIN.

# core/pairing.py
import os
import base64
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import x25519
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

_KDF_ITERATIONS = 100_000  # OWASP minimum for PBKDF2-SHA256


def derive_handshake_key(pin: str, salt: bytes) -> bytes:
    """
    Derive a 256-bit wrapping key from a 6-digit PIN + dynamic salt.
    The salt is generated fresh per-pairing session and sent in plaintext —
    its job is to prevent precomputed PIN dictionaries, not to be secret.
    """
    kdf = PBKDF2HMAC(
        algorithm=hashes.SHA256(),
        length=32,
        salt=salt,
        iterations=_KDF_ITERATIONS,
    )
    return kdf.derive(pin.encode("utf-8"))


def generate_pairing_keys() -> tuple[x25519.X25519PrivateKey, bytes]:
    """
    Generate a fresh ephemeral X25519 key pair.
    These keys live only for the duration of the handshake.
    """
    private_key = x25519.X25519PrivateKey.generate()
    public_key_bytes = private_key.public_key().public_bytes(
        encoding=serialization.Encoding.Raw,
        format=serialization.PublicFormat.Raw
    )
    return private_key, public_key_bytes


def encrypt_pairing_payload(public_key_bytes: bytes, handshake_key: bytes) -> str:
    """
    Encrypt the public key using the PIN-derived wrapping key.
    Layout: [ 12 bytes nonce | ciphertext + 16 byte GCM tag ]
    """
    aesgcm = AESGCM(handshake_key)
    nonce = os.urandom(12)
    ciphertext = aesgcm.encrypt(nonce, public_key_bytes, None)
    return base64.b64encode(nonce + ciphertext).decode("utf-8")


def decrypt_pairing_payload(payload: str, handshake_key: bytes) -> bytes:
    """Reverse of encrypt_pairing_payload. Raises InvalidTag on wrong PIN."""
    raw = base64.b64decode(payload)
    nonce, ciphertext = raw[:12], raw[12:]
    aesgcm = AESGCM(handshake_key)
    return aesgcm.decrypt(nonce, ciphertext, None)


def derive_shared_secret(
    private_key: x25519.X25519PrivateKey,
    peer_public_key_bytes: bytes
) -> bytes:
    """
    Complete the ECDH exchange. The result is a raw 32-byte shared secret.
    Both sides arrive at the same value without it ever being transmitted.
    """
    peer_public_key = x25519.X25519PublicKey.from_public_bytes(peer_public_key_bytes)
    return private_key.exchange(peer_public_key)

Why X25519 over RSA or classic ECDH on P-256?
X25519 is faster, has a smaller key size (32 bytes), is immune to invalid-curve attacks by design, and is the default in TLS 1.3. It's the right choice for a constrained local protocol.

Once the handshake completes, the shared secret is stored in ghost.db and the ephemeral private keys are immediately garbage-collected.

# Storage schema for trusted peers
"""
CREATE TABLE trusted_peers (
    id            INTEGER PRIMARY KEY AUTOINCREMENT,
    node_id       TEXT UNIQUE NOT NULL,
    device_name   TEXT NOT NULL,
    shared_secret BLOB NOT NULL,      -- raw 32 bytes from ECDH
    paired_at     TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
"""

Layer 3 — The Local REST API, Rate Limiting & Thread-Safe UI

With discovery and pairing solved, the actual sync transport is a minimal HTTPServer running in a background thread. It's bound to 0.0.0.0 but protected by two hard gates:

Gate 1 — Peer Identity: every /api/sync request must carry a node_id that maps to a stored trusted peer. Unknown nodes get a 403 immediately.

Gate 2 — E2EE Payload: even if someone spoofs a node_id, they can't forge a valid AES-GCM ciphertext without the shared secret. Wrong key = InvalidTag exception = instant drop.

# core/api_server.py
import json
import time
import urllib.parse
from collections import defaultdict
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Lock


class _RateLimiter:
    """Sliding window rate limiter — 3 pairing attempts per 60s per IP."""

    def __init__(self, max_attempts: int = 3, window: int = 60):
        self._attempts = defaultdict(list)
        self._lock     = Lock()
        self.max       = max_attempts
        self.window    = window

    def is_allowed(self, ip: str) -> bool:
        now = time.time()
        with self._lock:
            # drop timestamps outside the window
            self._attempts[ip] = [
                t for t in self._attempts[ip] if now - t < self.window
            ]
            if len(self._attempts[ip]) >= self.max:
                return False
            self._attempts[ip].append(now)
            return True


_rate_limiter = _RateLimiter()


class GhostAPIHandler(BaseHTTPRequestHandler):

    def log_message(self, format, *args):
        pass  # silence default HTTP logs

    def _send_response(self, code: int, body: dict):
        payload = json.dumps(body).encode()
        self.send_response(code)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(payload)))
        self.end_headers()
        self.wfile.write(payload)

    def do_POST(self):
        parsed    = urllib.parse.urlparse(self.path)
        client_ip = self.client_address[0]

        # ── /api/pair — pairing PIN exchange ──────────────────────
        if parsed.path == '/api/pair':
            if not _rate_limiter.is_allowed(client_ip):
                self._send_response(429, {
                    "status":  "error",
                    "message": "Too many pairing attempts. Try again later."
                })
                return
            # ... PIN verification and key exchange logic
            self._send_response(200, {"status": "paired"})
            return

        # ── /api/sync — incoming E2EE clipboard item ───────────────
        if parsed.path == '/api/sync':
            body = self.rfile.read(int(self.headers.get('Content-Length', 0)))
            data = json.loads(body)

            peer_node_id = data.get("node_id")
            peer = storage.get_trusted_peer(peer_node_id)

            if not peer:
                self._send_response(403, {
                    "status":  "error",
                    "message": "Untrusted peer"
                })
                return

            try:
                plaintext = decrypt_from_peer(
                    data.get("payload"),
                    peer["shared_secret"]
                )
            except Exception:
                # Wrong key or tampered payload — silent drop
                self._send_response(403, {
                    "status":  "error",
                    "message": "Decryption failed"
                })
                return

            item_id = storage.add_item("text", plaintext)

            # Cross-thread UI update via Qt signal — safe from any thread
            self.server.qthread_parent.sync_received.emit(item_id, plaintext)
            self._send_response(201, {"status": "synced"})

Why HTTPServer over WebSockets or raw TCP?
HTTP gives request/response semantics for free, works through most firewalls, and is trivially testable with curl. The overhead is negligible for clipboard payloads. When v3.x arrives, the transport will be upgraded to WebRTC for true NAT-piercing P2P.

The Full Sync Flow — End to End

Here's what happens when you copy something on Device A and it appears on Device B:

  Device A (sender)                         Device B (receiver)
  ─────────────────                         ────────────────────
  1. User copies text
  2. ClipboardMonitor detects change
  3. Encrypt with shared_secret
     [ AES-256-GCM | random 12-byte nonce ]
  4. POST /api/sync ──────────────────────► 5. GhostAPIHandler.do_POST()
     {                                         6. Lookup peer by node_id
       "node_id": "abc123",                    7. Decrypt with shared_secret
       "payload": "<base64 ciphertext>"        8. storage.add_item()
     }                                         9. sync_received.emit()
                                              10. UI updates in main thread
  ◄──────────────── 201 { "status": "synced" }

Zero plaintext on the wire. Zero server in the middle. Zero cloud.

Securing the Build: GPG-Signed Releases

A secure app with an unsigned binary is still a supply chain risk. Every release artifact — both the .AppImage and the .deb — is GPG-signed in CI and verified before upload.

# .github/workflows/build-all.yml (signing steps)

- name: Sign AppImage (GPG)
  run: |
    echo "${{ secrets.GPG_PRIVATE_KEY }}" | gpg --import --batch --yes
    gpg --batch --yes --pinentry-mode loopback \
      --passphrase "${{ secrets.GPG_PASSPHRASE }}" \
      --detach-sign --armor \
      DotGhostBoard-*.AppImage

- name: Verify AppImage signature
  run: |
    gpg --verify DotGhostBoard-*.AppImage.asc DotGhostBoard-*.AppImage
    echo "✅ AppImage signature verified"

- name: Sign DEB Package (GPG)
  run: |
    echo "${{ secrets.GPG_PRIVATE_KEY }}" | gpg --import --batch --yes
    dpkg-sig --sign builder \
      -k "${{ secrets.GPG_KEY_ID }}" \
      --gpg-options "--passphrase ${{ secrets.GPG_PASSPHRASE }} --pinentry-mode loopback --batch --yes" \
      dotghostboard_*.deb

- name: Generate SHA256 checksums
  run: |
    cd out && sha256sum * > SHA256SUMS.txt

Users can verify any release with:

# Verify AppImage
gpg --verify DotGhostBoard-1.5.1-x86_64.AppImage.asc \
             DotGhostBoard-1.5.1-x86_64.AppImage

# Verify DEB
dpkg-sig --verify dotghostboard_1.5.1_amd64.deb

# Verify checksum
sha256sum -c SHA256SUMS.txt

Lessons Learned

mDNS is fragile on some Linux setups. If avahi-daemon is running and competing for port 5353, zeroconf will fail silently. Detect the conflict early and surface it in the UI — don't leave the user with an empty peers list and no explanation.

PyInstaller and cryptography need explicit hidden imports. The cryptography package uses dynamic loading for its backend. Without --hidden-import cryptography.hazmat.primitives.asymmetric.x25519 and the aead module, the AppImage crashes at runtime with a clean ImportError that's impossible to debug without knowing where to look.

dpkg-sig hangs in CI without --pinentry-mode loopback. It silently waits for a terminal that doesn't exist. Always pass the full GPG options explicitly in non-interactive environments.

Rate limiting shared state needs a lock. The sliding window dict is accessed from multiple HTTP handler threads simultaneously. Without a threading.Lock, you get a race condition under concurrent pairing attempts that's near-impossible to reproduce locally.

What's Next — v2.0.0 Cerberus

The next release is Cerberus — a Zero-Knowledge Password Vault. The AES-256 infrastructure from v1.4.0 (Eclipse) already lays the foundation. What's coming on top:

A fully isolated vault.db (separate file, separate connection, locked when not in use)
Pattern-based secret detection using Regex — JWT, AWS keys, GitHub tokens, high-entropy hex strings — not keyword matching
Auto-clear: wipes the clipboard 30 seconds after a Vault paste
Paranoia Mode: a toggle that suspends all DB writes temporarily

The core design decision in Cerberus: detection happens at the shape of a string, not its meaning. A 1500-word article that mentions "password" doesn't trigger anything. A 40-character base64 string with high Shannon entropy does.

Download & Source

	Link
📦 GitHub Release (AppImage + DEB + GPG sigs)	v1.5.1
🖥️ OpenDesktop	DotGhostBoard
💻 Source Code	kareem2099/DotGhostBoard

If you find a security issue, please reach out directly before opening a public issue.

⚠️ A Note on the current DEB Release (v1.5.1)
Being transparent with the community is a core value of DotSuite.

Known Issue: In the current .deb release, some users might notice the UI defaulting to Light Mode on specific GTK-based distros (like Kali). Additionally, the update helper might trigger a Polkit permission error due to setuid restrictions in the /tmp/ directory.

The Fix: I am already working on v1.5.2, which migrates the update path to ~/.local/state/ and forces the Fusion style engine to ensure a consistent Dark Mode experience. The fix will be live tomorrow.

Stay tuned, and thanks for the support!

DotSuite — built for the shadows 👻

DotShare v3.1 — Toast Engine, Race Condition Fix, and Surviving Reddit's S3 Upload Pipeline

freerave — Mon, 13 Apr 2026 10:19:46 +0000

Full technical breakdown of v3.1 'The Polish Pass' — a custom WebView toast system, global loading states, per-platform character limits, and the two bugs that took the longest to kill.

v3.0 added the platforms. v3.1 made them feel like they belonged.

"The Polish Pass" is the kind of release that's invisible when it works and infuriating when it doesn't. No new platforms. No headline features. Just: notifications that don't hijack your screen, buttons that tell you something is happening, character counters that actually enforce limits — and two bugs that were quietly breaking things since the beginning.

This is the full technical breakdown.

What's in v3.1

Custom WebView toast notification engine (replaces VS Code popups)
Global loading states on all async actions
Per-platform character limit validation with visual feedback
Glassmorphism UI pass
The Disappearing Preview race condition — fixed
Reddit's S3 native image upload pipeline — fixed
Reddit field name synchronization between frontend and backend
Unused variable cleanup for ESLint compliance

1. The Toast Notification Engine

Before v3.1, every status update used vscode.window.showInformationMessage() — a popup in the VS Code notification center that requires manual dismissal and breaks your flow. For an extension designed to keep you in the editor, it was wrong.

The replacement is a custom toast system that lives entirely inside the WebView.

HTML Container

<!-- media/webview/platform-post.html -->
<div id="toast-container" aria-live="polite" aria-atomic="false"></div>

One container, fixed to the bottom-right of the WebView. Toasts mount and remove themselves.

The Toast Function

// media/webview/app.ts

type ToastType = 'success' | 'error' | 'warning' | 'info';

const TOAST_ICONS: Record<ToastType, string> = {
  success: '✓',
  error:   '✕',
  warning: '⚠',
  info:    'ℹ',
};

function escHtml(str: string): string {
  return str
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;');
}

function toast(
  msg: string,
  type: ToastType = 'info',
  ms: number = 5000
): void {
  const container = document.getElementById('toast-container');
  if (!container) return;

  const el = document.createElement('div');
  el.className = `toast toast-${type}`;
  el.setAttribute('role', 'alert');
  el.style.setProperty('--toast-duration', `${ms}ms`);

  el.innerHTML = `
    <span class="toast-icon">${TOAST_ICONS[type]}</span>
    <span class="toast-message">${escHtml(msg)}</span>
    <div class="toast-progress"></div>
  `;

  container.appendChild(el);

  // Trigger enter animation on next paint
  requestAnimationFrame(() => el.classList.add('toast-visible'));

  if (ms > 0) {
    setTimeout(() => {
      el.classList.remove('toast-visible');
      el.classList.add('toast-exit');
      el.addEventListener('transitionend', () => el.remove(), { once: true });
    }, ms);
  }
}

CSS

/* media/webview/style.css */

#toast-container {
  position: fixed;
  bottom: 1.5rem;
  right: 1.5rem;
  display: flex;
  flex-direction: column;
  gap: 8px;
  z-index: 9999;
  pointer-events: none;
}

.toast {
  display: flex;
  align-items: center;
  gap: 10px;
  padding: 12px 16px;
  border-radius: 8px;
  font-size: 13px;
  min-width: 260px;
  max-width: 380px;
  position: relative;
  overflow: hidden;
  pointer-events: all;
  opacity: 0;
  transform: translateX(20px);
  transition: opacity 0.2s ease, transform 0.2s ease;
  backdrop-filter: blur(8px);
  -webkit-backdrop-filter: blur(8px);
}

.toast-visible { opacity: 1; transform: translateX(0); }
.toast-exit    { opacity: 0; transform: translateX(20px); }

.toast-success { background: rgba(29,158,117,0.15); border: 1px solid rgba(29,158,117,0.4); color: #4ade80; }
.toast-error   { background: rgba(239,68,68,0.15);  border: 1px solid rgba(239,68,68,0.4);  color: #f87171; }
.toast-warning { background: rgba(245,158,11,0.15); border: 1px solid rgba(245,158,11,0.4); color: #fbbf24; }
.toast-info    { background: rgba(59,130,246,0.15); border: 1px solid rgba(59,130,246,0.4); color: #60a5fa; }

.toast-progress {
  position: absolute;
  bottom: 0; left: 0;
  height: 2px;
  width: 100%;
  background: currentColor;
  opacity: 0.4;
  animation: toast-shrink var(--toast-duration, 5000ms) linear forwards;
}

@keyframes toast-shrink {
  from { width: 100%; }
  to   { width: 0%; }
}

2. Global Loading States

Every async button now disables itself and shows a spinner during the operation. Prevents double-submissions. Makes it obvious something is happening.

// media/webview/app.ts

function setLoading(btn: HTMLButtonElement, loading: boolean, label?: string): void {
  if (loading) {
    btn.dataset.originalText = btn.textContent ?? '';
    btn.textContent = label ?? '⏳ Working…';
    btn.disabled = true;
    btn.classList.add('btn-loading');
  } else {
    btn.textContent = btn.dataset.originalText ?? 'Share';
    btn.disabled = false;
    btn.classList.remove('btn-loading');
  }
}

// On click — enter loading state
btnShare?.addEventListener('click', () => {
  if (!btnShare) return;
  setLoading(btnShare, true, '⏳ Sharing…');
  send('share', {
    platform:       activeCommandPlatform,
    post:           textarea?.value.trim(),
    mediaFilePaths: activeMediaPaths,
  });
});

// On complete — exit loading state
case 'shareComplete':
  if (btnShare) setLoading(btnShare, false);
  resetAllComposers();
  toast('Shared successfully!', 'success');
  break;

// On error — also exit loading so user can retry
case 'status':
  if (msg.type === 'error' && btnShare) {
    setLoading(btnShare, false);
  }
  toast(String(msg.status ?? ''), msg.type ?? 'info');
  break;

3. Character Limit Validation

MAX_CHARS existed before v3.1 but was never wired to the UI. This release connects it to both the counter display and the share button state.

// media/webview/app.ts

const MAX_CHARS: Record<string, number> = {
  x:        280,
  bluesky:  300,
  linkedin: 3000,
  telegram: 4096,
  facebook: 63206,
  discord:  2000,
  reddit:   40000,
  devto:    100000,
  medium:   100000,
};

function updateCharCounter(): void {
  if (!textarea || !counter) return;

  const len      = textarea.value.length;
  const platform = activeCommandPlatform ?? '';
  const max      = MAX_CHARS[platform] ?? null;

  counter.textContent = max ? `${len} / ${max}` : String(len);
  counter.className   = 'compose-counter';

  if (max) {
    if (len > max)                       counter.classList.add('counter-error');
    else if (len > Math.floor(max * 0.8)) counter.classList.add('counter-warn');
  }
}

function updateShareBtn(): void {
  if (!btnShare) return;
  const empty   = !textarea?.value.trim().length;
  const platform = activeCommandPlatform ?? '';
  const max     = MAX_CHARS[platform] ?? null;
  const over    = max ? (textarea?.value.length ?? 0) > max : false;
  btnShare.disabled = empty || over;
}

textarea?.addEventListener('input', () => {
  updateCharCounter();
  updateShareBtn();
});

.compose-counter               { color: var(--vscode-descriptionForeground); font-size: 12px; }
.compose-counter.counter-warn  { color: #f59e0b; }
.compose-counter.counter-error { color: #ef4444; font-weight: 600; }

4. The Glassmorphism UI Pass

Cards and modals now use backdrop-filter: blur with semi-transparent fills. Depth without visual weight.

.composer-card {
  background: rgba(255, 255, 255, 0.04);
  border: 1px solid rgba(255, 255, 255, 0.08);
  border-radius: 12px;
  backdrop-filter: blur(8px);
  -webkit-backdrop-filter: blur(8px);
  transition: border-color 0.2s ease;
}

.composer-card:hover {
  border-color: rgba(255, 255, 255, 0.14);
}

.modal-content {
  background: rgba(30, 30, 40, 0.92);
  border: 1px solid rgba(255, 255, 255, 0.1);
  border-radius: 14px;
  backdrop-filter: blur(12px);
  -webkit-backdrop-filter: blur(12px);
  animation: modal-enter 0.2s cubic-bezier(0.34, 1.56, 0.64, 1);
}

@keyframes modal-enter {
  from { opacity: 0; transform: scale(0.95) translateY(8px); }
  to   { opacity: 1; transform: scale(1)    translateY(0);   }
}

5. The Disappearing Preview Race Condition

This was the most subtle bug. And it was hiding in plain sight.

The Symptom

Attach a file → preview appears → preview vanishes 500ms later. Every time.

The Root Cause

When a file uploaded successfully, the backend sent:

{ command: 'status', type: 'success', status: 'File uploaded successfully' }

The WebView message handler treated every success the same way:

// ❌ BEFORE — nuked everything on any success message
case 'status':
  if (msg.type === 'success') {
    resetAllComposers(); // cleared activeMediaPaths + removed preview DOM
  }
  toast(msg.status, msg.type);
  break;

resetAllComposers() was designed for one thing: clean up after a post is fully shared. But it was firing on file uploads, auto-saves, and every other intermediate success too.

The Fix

// ✅ AFTER — terminal vs intermediate distinction
case 'status': {
  toast(String(msg.status ?? ''), msg.type ?? 'info');

  if (msg.type === 'success') {
    const text = String(msg.status ?? '').toLowerCase();

    const isTerminal     = text.includes('shared')    ||
                           text.includes('published') ||
                           text.includes('complete');

    const isIntermediate = text.includes('upload')    ||
                           text.includes('saved')     ||
                           text.includes('processing');

    if (isTerminal && !isIntermediate) {
      resetAllComposers();
    }
  }
  break;
}

The rule going forward: resetAllComposers() is terminal-only. Intermediate feedback goes to toast() and targeted DOM updates — never a full reset.

6. Reddit's S3 Upload Pipeline

This was the hardest fix in v3.1. Reddit's native image upload doesn't use a standard multipart POST endpoint. It routes through Amazon S3, and the sequence has enough specific requirements that every step has its own failure mode.

The Full Flow

POST /api/media/asset.json  →  receive S3 upload URL + signed fields
POST to S3 URL (FormData)   →  upload the file bytes
POST /api/submit            →  create the Reddit post with asset URL

Step 1 — Get S3 Credentials

// src/platforms/reddit.ts

async function getS3UploadUrl(
  accessToken: string,
  filePath: string,
  mimeType: string
): Promise<{ uploadUrl: string; fields: Record<string, string>; assetUrl: string }> {
  const res = await axios.post(
    'https://oauth.reddit.com/api/media/asset.json',
    new URLSearchParams({
      filepath: path.basename(filePath),
      mimetype: mimeType,
    }),
    {
      headers: {
        Authorization: `Bearer ${accessToken}`,
        'Content-Type': 'application/x-www-form-urlencoded',
        'User-Agent': 'DotShare/3.1',
      },
    }
  );

  const uploadUrl = `https:${res.data.args.action}`;

  // Reddit returns fields as [{name, value}] array — convert to object
  const fields: Record<string, string> = {};
  for (const f of res.data.args.fields) {
    fields[f.name] = f.value;
  }

  return {
    uploadUrl,
    fields,
    assetUrl: `https://i.redd.it/${res.data.asset.asset_id}`,
  };
}

Step 2 — Upload to S3

Two traps here. Field order in FormData matters — S3 requires all fields before the file. And S3 requires Content-Length explicitly — axios doesn't set it automatically for FormData in Node.js.

async function uploadToS3(
  uploadUrl: string,
  fields: Record<string, string>,
  filePath: string,
  mimeType: string
): Promise<void> {
  const fileBuffer = await fs.promises.readFile(filePath);
  const formData   = new FormData();

  // All fields MUST come before the file — S3 policy
  for (const [key, value] of Object.entries(fields)) {
    formData.append(key, value);
  }
  formData.append(
    'file',
    new Blob([fileBuffer], { type: mimeType }),
    path.basename(filePath)
  );

  await axios.post(uploadUrl, formData, {
    headers: { 'Content-Length': fileBuffer.byteLength.toString() },
    maxBodyLength: Infinity,
    maxContentLength: Infinity,
  });
}

Step 3 — Submit the Post

async function submitRedditImagePost(
  accessToken: string,
  subreddit: string,
  title: string,
  assetUrl: string
): Promise<string> {
  const res = await axios.post(
    'https://oauth.reddit.com/api/submit',
    new URLSearchParams({
      sr:       subreddit,
      kind:     'image',
      title:    title,
      url:      assetUrl,  // use asset URL, NOT the CDN URL
      resubmit: 'true',
      api_type: 'json',
    }),
    {
      headers: {
        Authorization: `Bearer ${accessToken}`,
        'Content-Type': 'application/x-www-form-urlencoded',
        'User-Agent': 'DotShare/3.1',
      },
    }
  );

  const postUrl = res.data?.json?.data?.url;
  if (!postUrl) {
    const errors = res.data?.json?.errors;
    throw new Error(
      errors?.length
        ? `Reddit: ${errors[0][1]}`
        : 'Reddit: no post URL in response'
    );
  }

  return postUrl;
}

The three traps summarized:

FormData field order — fields before file or S3 returns 403
Missing Content-Length — AWS returns 400, message says "malformed body"
CDN URL vs asset URL — i.redd.it/ID is unpopulated at submit time, use the S3 action URL

7. Reddit Field Name Sync

Found this while fixing the S3 pipeline. The WebView was sending field names the backend didn't recognize — and the post text wasn't being sent at all.

// ❌ BEFORE
send('shareToReddit', {
  subreddit: val('redditSubreddit'), // ❌ handler expects 'redditSubreddit'
  title:     val('redditTitle'),     // ❌ handler expects 'redditTitle'
  flair:     ...,                    // ❌ handler expects 'redditFlairId'
  postType:  ...,                    // ❌ handler expects 'redditPostType'
  // ❌ 'post' (the text) missing entirely
});

// ✅ AFTER
send('shareToReddit', {
  post:            textarea?.value.trim() ?? '',
  redditSubreddit: val('redditSubreddit'),
  redditTitle:     val('redditTitle'),
  redditFlairId:   get<HTMLSelectElement>('redditFlair')?.value ?? '',
  redditPostType:  document.querySelector<HTMLInputElement>(
                     'input[name="redditPostType"]:checked'
                   )?.value ?? 'self',
  redditSpoiler:   get<HTMLInputElement>('redditSpoiler')?.checked ?? false,
});

8. Unused Variable Cleanup

// ❌ BEFORE
const btnShare    = get<HTMLButtonElement>('btn-share');
const btnGenerate = get<HTMLButtonElement>('btn-generate-ai');
const btnSchedule = get<HTMLButtonElement>('btn-schedule'); // never used → ESLint error
const btnMedia    = get<HTMLButtonElement>('btn-attach-media');

// ✅ AFTER
const btnShare    = get<HTMLButtonElement>('btn-share');
const btnGenerate = get<HTMLButtonElement>('btn-generate-ai');
const btnMedia    = get<HTMLButtonElement>('btn-attach-media');

Scheduling stays in the HTML as a disabled "Coming Soon" button — listener is commented out pending v3.2.

v3.1 Summary

	Before	After
Status feedback	VS Code popups	Inline toast engine
File preview	Disappears on upload	Stable ✅
Character limits	Display only	Enforced + visual feedback
Reddit images	Broken (S3 errors)	Full pipeline working ✅
Reddit fields	Mismatched	Synchronized ✅
ESLint	1 unused var warning	0 warnings ✅

See It in Action

LinkedIn posting demo:

Telegram posting demo:

Bluesky posting demo:

Install DotShare

VS Code Marketplace

Open VSX (VSCodium / Gitpod

GitHub — star, fork, contribute

v3.2 "The Media Expansion" — up to 4 images per post, per-thumbnail previews, JIT compression, secure WebView URIs — breakdown coming next.