标签：#web

kreuzcrawl began as a Rust core with bindings for ten languages. v0.3.0 ships fourteen, adds a tiered WAF-aware dispatch engine, cuts peak streaming memory from ~2.5 GB to ~20 MB, and enables SSRF defense across every outbound call path by default. It is the first release we consider API-stable. This post covers what changed, why each decision was made, and what the harder engineering problems looked like from the inside. At a glance Area v0.2.0 v0.3.0 Language bindings 10 14 (+Dart, Kotlin/Android, Swift, Zig) Peak streaming memory ~2.5 GB ~20 MB SSRF protection opt-in on by default Dispatch model static HTTP / bypass / browser tiered, signal-driven escalation WAF fingerprints — 35 across 8 vendors Fingerprint hot-reload — lock-free ( ArcSwap ), 500 ms debounce MCP tools partial 1:1 with CLI, safety-annotated CLI subcommands scrape, crawl + batch-scrape, batch-crawl, download, citations Robots / sitemap parsers engine-internal public modules API stability preview stable Four new language bindings v0.2.0 shipped Rust, Python, Node.js, Ruby, Go, Java, C#, PHP, Elixir, and WebAssembly. v0.3.0 adds Dart , Kotlin/Android , Swift , and Zig — bringing the total to fourteen. None of the per-language glue is written by hand. Every binding is generated from the Rust core by alef , our polyglot binding generator. The Dart and Kotlin/Android packages bind through the C FFI layer ( kreuzcrawl-ffi ) via dart:ffi and JNI respectively. Swift binds through clang. Zig uses @cImport against the same C header. The generation pipeline also hardened in this release: the Docker publish matrix now builds each architecture natively rather than via QEMU emulation, the Dart build no longer requires the Flutter SDK for pub.dev publishes, Swift artifactbundle checksums are injected automatically, and the Elixir/PHP/Ruby releases preserve their lock files through the source-publish step. === "Python" ```sh pip install kreuzcrawl ``` === "Node.js" ```sh npm install @xberg/kreuzcrawl ``` === "Rus

Last year I was doing a code review for a startup. Everything looked fine on the surface, clean code, good structure, tests passing. Then I noticed this: const query = `SELECT * FROM users WHERE email = ' ${ req . body . email } '` That's it. That's the bug. SQL injection, sitting right there in a startup that had been in production for 8 months. Nobody caught it. Not the developer, not the reviewer, not the CTO. Here's the thing, it's not that developers are careless. It's that this kind of bug is invisible until it isn't. The code works perfectly. Tests pass. Users are happy. Until someone types ' OR '1'='1 in the email field and walks straight into your database. The bugs I see most often 1. Raw SQL with user input // 🚨 This is everywhere const query = `SELECT * FROM users WHERE email = ' ${ email } '` // ✅ Use parameterized queries const query = ' SELECT * FROM users WHERE email = $1 ' db . query ( query , [ email ]) 2. Secrets in environment variables... committed to git # .env DATABASE_URL = postgres://user:actualpassword@prod-db.company.com/mydb STRIPE_SECRET = sk_live_... Then .env ends up in the repo because someone forgot to add it to .gitignore . I've seen this more times than I want to admit. GitHub's secret scanning catches some of these, but not always before someone has already cloned the repo. 3. JWT tokens that are never actually verified // 🚨 Decoding is not the same as verifying const user = jwt . decode ( token ) // ✅ Always verify const user = jwt . verify ( token , process . env . JWT_SECRET ) jwt.decode just reads the token. Anyone can forge it. jwt.verify actually checks the signature. The names are confusingly similar and the wrong one silently works in development. 4. No rate limiting on auth endpoints // 🚨 Anyone can try a million passwords app . post ( ' /login ' , async ( req , res ) => { const user = await db . findUser ( req . body . email ) // ... }) // ✅ Add rate limiting const authLimiter = rateLimit ({ windowMs : 15 * 60 * 1000 , m

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Most people lose hours pretending to work or study. I was one of them. I kept setting Pomodoro timers and ending up scrolling Twitter during breaks. That's not rest. That's just a different kind of distraction. So I built Mognota — a free wellness companion for screen workers. The Problem You don't have a discipline problem. You have a system problem. Your brain has a hard biological limit. Sustained attention peaks at 20-45 minutes before quality drops sharply. Long unfocused hours are not work — they are the feeling of work. The solution isn't more willpower. It's intentional recovery. What I Built Mognota pairs a Pomodoro timer with 50+ guided wellness activities: 👁️ 20-20-20 eye break reminders 🫁 Guided breathing & 7 pranayama techniques 🧘 Desk yoga, HIIT, Tai Chi, stretches 🎵 Binaural beats & ambient soundscapes 🧠 Meditation & NSDR protocols 📓 Gratitude journal, mood tracker, brain dump 🎮 Sudoku, sliding puzzle, fractal explorer The Technical Part This is what dev.to might find interesting: Pure HTML, CSS, vanilla JS — zero frameworks Everything in a single HTML file All 8 notification sounds synthesized with Web Audio API localStorage only — nothing leaves your device Works offline once loaded 109+ languages supported No npm. No build step. No dependencies. Just open and use. Try It 👉 https://mognota.com/ Completely free. No account. No ads. Forever. Would love brutal honest feedback from this community.

Adding an AI feature looks deceptively easy. You sign up for an API key, paste in a prompt, and within an hour you've got a working demo that makes the whole team lean over your shoulder. Then you ship it, traffic arrives, and two things happen at once: your latency graph develops a long, ugly tail, and your monthly bill arrives with a number that makes finance schedule a meeting. The gap between "impressive demo" and "production feature" is almost entirely about cost and latency engineering. The model is the easy part. Here's how to cross that gap. First, understand what you're actually paying for Most LLM APIs bill by tokens — roughly ¾ of a word each — and they bill both directions: the tokens you send (input) and the tokens the model generates (output). Output tokens are usually several times more expensive than input tokens, which has a non-obvious consequence: a verbose prompt is cheaper than a verbose answer. This reframes optimization. People obsess over trimming their prompts while letting the model ramble for 800 tokens when 80 would do. If you want to cut cost, the highest-leverage move is almost always constraining the output : ask for JSON, ask for a single sentence, set a max_tokens ceiling, and tell the model explicitly to be terse. Latency follows the same logic. Generation is sequential — the model produces one token at a time — so output length is the single biggest driver of how long a request takes. A 50-token answer is fast almost regardless of model. A 2,000-token answer is slow even on the fastest infrastructure. Lever 1: Don't call the model when you don't have to The cheapest, fastest LLM call is the one you never make. Two techniques eliminate a startling share of traffic. Caching identical and near-identical requests. Many real-world prompts repeat — the same FAQ-style question, the same document summarized twice, the same classification of similar inputs. A cache keyed on the normalized prompt turns a repeat request into a sub-millisecond

If you've wired Swiss Ephemeris into a Node astrology app, you know the ritual. You npm install sweph , and now every machine needs Python plus a C/C++ toolchain, because the package compiles Swiss's C code via node-gyp at install time (make/gcc on Linux, Xcode on macOS, Visual C++ Build Tools on Windows). It works on your laptop. Then it explodes: Apple Silicon: node-gyp can't find full Xcode behind Command Line Tools. Slim Docker / CI images: no Python, no build-essential , so the install dies. Serverless: the .node binary you built locally won't load on Amazon Linux (wrong arch or glibc). Then there's the data. Neither sweph nor swisseph bundles the .se1 ephemeris files; you download them yourself and point the library at a path. The modern set is 2 MB, the full GitHub set is 100 MB. And since 2.10.1 , sweph is AGPL-3.0 (LGPL only under a professional license), a real obligation to weigh for a closed-source SaaS backend. The pure-Rust alternative XALEN Ephemeris is an analytical engine written entirely in Rust and licensed Apache-2.0. Three things make it interesting for JS/TS devs: No node-gyp. The Node addon is napi-rs, which ships prebuilt per-platform binaries via npm. No Python, no C compiler, no compile step. A real WASM build via wasm-bindgen, so you compute charts client-side in the browser: no server round-trip, no backend copyleft. Zero data files. The core math (VSOP87A, ELP2000-82, IAU precession/nutation, an 8,870-star catalog) is analytical and compiled into the binary. No .se1 to host. import init , * as xalen from " xalen-ephemeris " ; // WASM build, runs in the browser await init (); // load the .wasm module const chart = xalen . computeChart ({ datetime : " 1990-04-12T08:30:00Z " , lat : 28.6 , lon : 77.2 }); console . log ( chart ); // planet longitudes, house cusps, etc. Swiss via Node XALEN (pure Rust) Build deps node-gyp + Python + C compiler none: prebuilt binary / .wasm Runtime data .se1 files (2 to 100 MB) none, compiled in Browser / WASM

Why developer tools deserve a design language of their own - and how I built one for my own corner of the web Somewhere along the line, we collectively agreed that "functional" had to mean "boring." Open almost any developer tool, internal dashboard, or technical log and you'll find the same thing: a sterile corporate wiki. Grey on white. The same SaaS design system everyone copied from the same three component libraries. Rounded cards, a sans-serif font, a faint drop shadow. It works. It's also completely forgettable. But here's the thing nobody says out loud: when you're building for engineers - or building your own space on the web - you are under no obligation to follow the standard playbook. The intersection of system design and visual identity is one of the most under-explored areas in frontend architecture. We obsess over latency, bundle size, and runtime dependencies, then slap a default theme on top and call it done. The backend gets all the craft. The interface gets a template. I wanted to do the opposite. Building VOID_PROTOCOL When I put together my own developer log - https://blog.naveenr.in - I deliberately stepped away from the standard minimalist tech blog. Instead, I built out a full design system I call the VOID_PROTOCOL × Manga Editorial Design System: dark-only, type-driven, built on Astro 6, Tailwind 4 (CSS-first @theme tokens), and React 19 islands. The name isn't decoration. VOID_PROTOCOL started on my https://naveenr.in portfolio, which runs in two modes. There's a minimal version, and there's an immersive one - and in immersive mode the background is a real-time 3D simulation of a sentinel entity. It's not a looping video; it actually responds to your movement, clicks, and scroll. When you leave it alone long enough, it sleeps. And when it sleeps, it dreams - it dreams my initials. (Yes, really. It started as a joke and I kept it.) That entity is the soul of the whole identity: black, empty, void-like space and a cool blue palette, a deep-sp

Picking colors is the fun part. Wiring them into a codebase that stays maintainable is where most palettes fall apart. Here's the approach I use. 1. Name colors by role, not value Don't scatter hex codes everywhere: css .button { background: #6366f1; } .link { color: #6366f1; } Define them once as custom properties, referenced by role: :root { --color-bg: #f7f7f8; --color-surface: #ffffff; --color-text: #1f2937; --color-muted: #9ca3af; --color-accent: #6366f1; } .button { background: var(--color-accent); } .link { color: var(--color-accent); } Now re-theming the whole app is a few edits in one place. 2. Skip pure black and pure white #000 on #fff feels harsh on screens. Pull both back: --color-text: #1f2937; /* near-black */ --color-bg: #f7f7f8; /* off-white */ Most layouts instantly look more intentional. 3. Dark mode is almost free Because the colors are role-based variables, you just override the values: @media (prefers-color-scheme: dark) { :root { --color-bg: #0f1115; --color-surface: #1a1d24; --color-text: #e5e7eb; } } Every component using var(--color-bg) adapts automatically. A shortcut I got tired of hand-converting palettes into this, so I built a free tool, PaletteCSS, that copies any palette straight out as CSS variables, Tailwind or SCSS — and has a color palette generator if you need a starting point. But honestly, the three rules above matter more than any tool. What conventions do you use to keep a color system maintainable? PaletteCSS — a free tool to discover, create and share color palettes and CSS gradients. Copy any palette as hex, CSS variables, Tailwind or SCSS. No signup. https://palettecss.com**

Over the past few months, I've been building a gaming website focused on Elden Ring guides, calculators, and tools. While the project started as a simple hobby, it quickly became an interesting experiment in SEO, content strategy, and web development. Here are some lessons I learned along the way. Building the Site Was Easier Than Getting Traffic Launching a website with Next.js was straightforward. Getting visitors was much harder. Many developers underestimate how competitive search traffic can be, especially in gaming niches where large sites already dominate search results. Publishing a website is only the first step. Why I Chose Next.js The project uses: Next.js TypeScript React Tailwind CSS The biggest advantage was SEO. Server-side rendering and static generation helped ensure that search engines could easily crawl and index pages. Performance was also excellent compared to many traditional CMS solutions. Tools Attract Different Users Than Articles One interesting discovery was that calculators and interactive tools behave differently from standard content pages. For example: Guides answer questions. Tools solve problems. A player may read a guide once, but they might return to a calculator dozens of times while planning different character builds. This makes tools valuable long-term traffic assets. Internal Linking Matters More Than Expected When new content was published, internal links helped search engines discover and understand related pages. For example: Build guides linked to calculators. Calculator pages linked to stat guides. Stat guides linked to weapon builds. This created a stronger topical structure around the Elden Ring ecosystem. Search Traffic Takes Time One of the biggest lessons was patience. Many pages received: Zero impressions Zero clicks No rankings for days or even weeks. Then suddenly search impressions started increasing as Google tested pages across different queries. Traffic growth was rarely linear. Content Clusters Work Well Inst

I build Voxis, an open-source Windows app that translates whatever your system is playing — a video, a game, the other side of a call — and plays the translation back as spoken voice, a few seconds behind the speaker. No subtitles, no virtual audio cable, no bot joining your meeting. The "no virtual cable" part is the bit worth writing about. Almost every system-audio tool on Windows tells you to install VB-CABLE or VoiceMeeter, or to drop a bot into your call. Voxis doesn't, for incoming audio. This post is how that capture engine works, and the sharp edges I hit building it in Python. I'll be specific about what's hard and honest about what's not mine to fix. The goal Read the exact audio the user is hearing — the post-mix system output — at 16 kHz mono, and do it without installing anything. Then stream it to a translation model and play the result back, all while the original keeps playing underneath. Three constraints fall out of that: Driverless. If it needs a reboot and a driver, it's not zero-setup. No self-feedback. The app plays translated audio into the same system mix it's capturing . Naively, it would capture its own voice and translate the translation. That has to be impossible by construction, not patched with an echo gate. Realtime-safe. Capture can't stall. If the downstream VAD or garbage collector hiccups, the WASAPI ring buffer must not overflow. WASAPI process-loopback: capturing the mix, minus yourself Windows 10 version 2004 added the ApplicationLoopback API — a way to activate an IAudioClient in loopback mode scoped to a process tree, either including only that tree or excluding it. Excluding our own process tree is exactly what constraint #2 needs: the captured mix is everything the user hears, with Voxis's own output removed. You don't get this client from the normal IMMDeviceEnumerator path. You activate it by name through ActivateAudioInterfaceAsync , passing the loopback parameters in a PROPVARIANT carrying a BLOB : params = AUDIOCLIENT_

Live demo: https://safestate.vercel.app , code: https://github.com/usv240/safestate A product recall today is basically a notice. It lives on a webpage, or a PDF, or an email that somebody is supposed to read. Say the problem out loud and it gets uncomfortable fast. A recalled crib can be listed and sold to another family, and nobody in that sale ever sees the recall. Reselling recalled goods is actually illegal, and recalled infant products have killed kids. I spent this hackathon building something to close that gap. I called it SafeState, and the idea is small: make the recall do something. When a second-hand item is listed or sold, the marketplace checks SafeState first, and recalled units get blocked right at checkout. It is precise down to the serial number, so safe units still sell. It runs on the stack this hackathon is about. A Next.js front end on Vercel, with Amazon Aurora DSQL behind it. Why DSQL is the whole point here The promise SafeState has to keep is this: the moment a recall lands in any region, no marketplace anywhere should ever read that product as "safe" again. That is a strong consistency problem, not a nice-to-have. If there is any window where a recalled product still looks safe, that is exactly when it gets sold. An eventually consistent store or a nightly sync leaves that window open. DSQL's active-active, multi-region setup with strong consistency is what closes it. I set up a real peered cluster across us-east-1 and us-east-2, with us-west-2 as the witness. Write a recall through one region's endpoint and you can read it back from the other region right away. There is a page in the app that lets you run that yourself. The one trick that makes it work DSQL runs on snapshot isolation (PostgreSQL REPEATABLE READ) with optimistic concurrency. It catches write-write conflicts at commit time. Snapshot isolation will not protect you from write skew, so I had to design around that. To guarantee that a recall and a sale of the same product actua

You added a useLayoutEffect to measure a tooltip, shipped it, and the next time your Next.js (or Remix, or Gatsby) dev server rendered a page on the server, the console lit up: Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, useLayoutEffect should only be used in components that render exclusively on the client. The warning is correct, the suggested fix ("only use it on the client") is unhelpful, and the obvious workaround — just switch to useEffect — quietly reintroduces the visual bug you used useLayoutEffect to kill in the first place. useIsomorphicLayoutEffect is the small hook that resolves the standoff. This post explains exactly why the warning happens, why the two naive fixes are both wrong, and what the one-line hook actually does. Why useLayoutEffect Exists At All React gives you two effect hooks that look nearly identical: useEffect runs after the browser has painted. Its callback is queued and fires asynchronously once the frame is on screen. useLayoutEffect runs before the browser paints, synchronously, right after React has mutated the DOM but before the user sees anything. That timing difference is the whole point. If you need to read layout — getBoundingClientRect , scrollHeight , the measured width of a node — and then write a style based on it, you have to do it before paint. Otherwise the user sees one frame of the wrong layout, then a flicker as your useEffect corrects it. The canonical example is a tooltip that has to position itself relative to its own measured size: function Tooltip ({ targetRect , children }) { const ref = useRef < HTMLDivElement > ( null ); const [ pos , setPos ] = useState ({ top : 0 , left : 0 }); useLayoutEffect (() => { const { height , width } = ref . current ! . getBoundingClientRect (); // place the tooltip above the target, centered s

Why I Still Believe in Zero-Cost BFF Layers After 6 Months (And What Broke) Honestly, I didn't expect to be writing this article. Six months ago, I built capa-bff — a zero-cost BFF framework that won a hackathon gold medal — and I thought I had it all figured out. "This is perfect," I told myself. "Zero configuration, works with any Spring Boot app, solves all the frontend aggregation problems." Spoiler alert: It didn't. Don't get me wrong — it's still great for what it is. But here's the thing about building developer tools: the real world has a way of humbling you. Let me walk you through what I learned, what works, what doesn't, and who should actually use this thing. What Even Is a BFF Anyway? If you're new to the term, BFF stands for Backend For Frontend . It's that intermediate layer between your frontend clients (web, mobile, mini-programs) and your backend services. The idea is simple: instead of making the frontend stitch together data from multiple backend APIs, you have this middle layer that does it for you. ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Frontend │ -> │ BFF │ -> │ Backend │ │ (Web/Mobile)│ │ Aggregation │ │ Services │ └─────────────┘ └─────────────┘ └─────────────┘ The benefits are clear: Fewer network calls from the client Customized responses for each client type Better caching opportunities One place to handle auth/transformations But here's the catch most articles don't tell you: adding a BFF layer means another service to maintain , another deployment , another thing that can break . For small teams and startups, that cost can feel too high. That's exactly why I built capa-bff: I wanted a zero-cost BFF layer that you can just drop into your existing Spring Boot app. No new service, no extra deployment — just add the dependency and start aggregating APIs. How It Actually Works (Code Example) Let me show you the basics. With capa-bff, you define your aggregation in a simple annotation: @BffRoute ( path = "/user-dashboard" ) public

Every few months, I see another post declaring: "Prompt engineering is dead." Usually, the argument goes something like this: AI models are getting smarter. They understand natural language better. You no longer need carefully crafted prompts. On the surface, that sounds reasonable. But after building AI workflows and experimenting with modern frameworks, I think the opposite is happening. Prompt engineering isn't disappearing. It's evolving. And if you're building AI applications, not just chatting with AI, you'll probably rely on it more than ever. Prompt Engineering Was Never About Fancy Prompts One of the biggest misconceptions is that prompt engineering is about writing magical sentences that somehow unlock hidden AI capabilities. It isn't. Good prompt engineering is about giving an AI system exactly what it needs to complete a task reliably. Consider these two examples. Poor prompt: Write Python code. Better prompt: Write a Python FastAPI endpoint that accepts a CSV upload. Requirements: Use Python 3.12 Validate file type Handle exceptions Return JSON responses Include comments explaining each step The second prompt isn't "clever." It's simply clearer. And clarity scales. AI Models Are Better, But They Still Need Context Modern LLMs have become incredibly capable. They can: Generate code Explain algorithms Debug applications Write tests Refactor functions But they still don't know: Your architecture Your coding standards Your API contracts Your deployment strategy Your business requirements That information comes from you. And the way you provide it matters. Prompt engineering is fundamentally the practice of supplying useful context. Every AI Framework Depends on Good Prompts Take a look at the most popular AI frameworks. Whether you're using: LangChain LangGraph CrewAI LlamaIndex Every one of them eventually sends prompts to an LLM. Even sophisticated agent systems are built from sequences of prompts. Agents don't eliminate prompt engineering. They multiply

Introduction In the early 2000s, email spam was rampant, cluttering inboxes with unsolicited messages promising quick riches or promoting dubious products. Fast forward to today, and a similar phenomenon is occurring in the world of open-source software: Pull Request (PR) spam. Much like its email predecessor, PR spam is becoming a major nuisance for developers and maintainers, disrupting workflows and compromising the integrity of collaborative software projects. This blog post explores the parallels between early 2000s email spam and contemporary PR spam, examines the motivations behind this new wave of digital clutter, and discusses potential solutions to mitigate its impact. The Rise of PR Spam The Allure of Contribution Metrics One of the primary drivers behind PR spam is the increasing emphasis on contribution metrics in the open-source community. Platforms like GitHub have made contributing to projects more accessible, and many developers are eager to showcase their activity through public repositories. However, this focus on quantity over quality can lead to an influx of low-effort or irrelevant PRs. An example of this is Hacktoberfest, an annual event encouraging contributions to open-source projects. While well-intentioned, it has, in some instances, resulted in a deluge of superficial PRs. Contributors seeking to meet participation thresholds often submit changes that are trivial or unnecessary, much like the spam emails of old that inundated our inboxes with irrelevant or nonsensical content. Automated PR Generators Another factor contributing to the rise of PR spam is the use of automated tools that generate pull requests. These tools can be beneficial for routine tasks such as dependency updates or code formatting. However, when misused, they can lead to a flood of PRs that lack genuine human oversight or consideration, akin to the automated email spam generators that once plagued communication networks. For instance, a tool might automatically submit

Hey Dev Community, If you are running enterprise-scale web scrapers, pricing monitors, or data ingestion pipelines for LLMs, you’ve probably spent sleepless nights dealing with network latency and sudden 403 blocks. When choosing an infrastructure partner, every provider pitches the same script: "99.9% uptime guarantees, millions of residential IPs, and lightning-fast response times." But in the trenches of real-world data collection, we all know that marketing numbers rarely match production reality. Last quarter, my team ran an exhaustive infrastructure audit to compare proxy providers pricing performance and infrastructure stability. If you want to dive straight into our live dataset, telemetry scripts, and interactive monitoring utilities, you can check out the full workbench at ProxyVero . Here is a technical breakdown of how we built our benchmarking matrix, and the architectural gaps we discovered across mainstream enterprise proxy services. 📊 1. The Core Metrics: Uptime vs. Success Rates The biggest lie in the networking industry is confusing Server Uptime with Request Success Rate . A proxy gateway server can maintain a 99.9% uptime while the underlying residential peer network is failing 20% of your data collection requests due to strict target WAFs or high peer churn. When conducting our proxy providers uptime guarantees performance benchmarks , we evaluated three core parameters: TCP Handshake Latency : The time it takes to establish a connection with the proxy endpoint. TTFB (Time to First Byte) : Critical for parsing dynamic JavaScript targets. HTTP Status Code Reliability : Tracking the exact ratio of 200 OK vs. 403 Forbidden / 429 Too Many Requests . ⚖️ 2. The Big Three: Oxylabs vs Bright Data vs SmartProxy Comparison To provide an objective proxy network performance benchmarks comparison , we deployed standard headless browser worker instances (Playwright/Puppeteer) routed through different enterprise gateways. Below is a high-level summary of our a

Thariq Shihipar, engineering lead for the Claude Code team, recently published a blog post (Using Claude Code: The Unreasonable Effectiveness of HTML) arguing that HTML, with its richer visualizations, color, and interactivity, improves the productivity of human-agent communication in many settings, especially when compared to default Markdown outputs. By Bruno Couriol

got annoyed that pastebin and similar sites log everything and keep your text forever, so i built one where the server literally cant read what you paste. heres how the encryption actually works and what i learned building it the problem most paste sites work like this: you type something, it goes to their server as plain text, and it sits in their database. they can read it. their employees can read it. anyone who breaches them can read it. and a lot of them keep it forever even after you think its gone. i didnt want to just promise not to look at your stuff. i wanted it so that i cant look even if i wanted to. the idea: encrypt before it leaves the browser the trick is that all the encryption happens on your side, in the browser, before anything gets sent. the server only ever sees scrambled bytes. the key never touches the server at all, it lives in the part of the url after the # , which browsers dont send in requests. so the flow is basically: you paste text browser generates a random key text gets encrypted with that key only the encrypted blob goes to the server the key gets stuck in the link after a # whoever opens the link decrypts it locally the actual code modern browsers have the Web Crypto API built in, so you dont need any library for this. heres the encrypt part, stripped down: \ `js async function encrypt(text) { const key = await crypto.subtle.generateKey( { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"] ); const iv = crypto.getRandomValues(new Uint8Array(12)); const encoded = new TextEncoder().encode(text); const ciphertext = await crypto.subtle.encrypt( { name: "AES-GCM", iv }, key, encoded ); // export the key so we can put it in the url const rawKey = await crypto.subtle.exportKey("raw", key); return { ciphertext, iv, rawKey }; } ` \ the ciphertext and iv go to the server. the rawKey gets base64'd and dropped into the link after the # . decrypting is just the same thing in reverse with crypto.subtle.decrypt . the thing that tripped

If you're building AI agents that work with browser screenshots, you already know the pain. You take a full 1920×1080 screenshot, pass it to GPT-4o or Claude, and watch your token bill climb — while the model downscales the image anyway and blurs the exact text you needed it to read. There's a better way. The problem Vision LLMs are expensive for two reasons when you feed them full screenshots: Token cost — a full screenshot can cost 10–20x more tokens than a small crop Accuracy loss — models internally downscale large images, blurring fine text, labels, and UI elements But your agent already knows where to look. Browser automation tools like Playwright and Puppeteer give you getBoundingClientRect() — the exact pixel coordinates of any element on screen. So why are you sending the whole screenshot? The solution I built a stateless pay-per-use API that takes a screenshot and pixel coordinates, and returns just the cropped element as a lossless PNG — ready to pass directly to your vision LLM. POST /crop { "image" : "<base64 screenshot>" , "x" : 120 , "y" : 45 , "width" : 640 , "height" : 80 } Returns: { "success" : true , "data" : { "base64" : "iVBORw0KGgo..." , "mime" : "image/png" , "width" : 640 , "height" : 80 , "bytes" : 4821 } } A 4KB crop instead of a 2MB screenshot. Same information. 95% fewer tokens. How payment works Here's where it gets interesting. The API uses the x402 payment protocol — HTTP's long-dormant 402 Payment Required status code, finally put to use. There are no API keys. No accounts. No subscriptions. The agent pays $0.0005 USDC per crop on Base L2 automatically. The flow: 1. Agent POSTs to /crop (no payment header) ← 402 with payment instructions in headers 2. Agent transfers 0.0005 USDC to recipient wallet on Base (near-zero gas, ~2 second settlement) 3. Agent POSTs again with x-payment-tx-hash header ← 200 with cropped PNG The entire exchange happens inside the HTTP request cycle. No human intervention. No billing dashboard. The money lands

Introduction With the World Cup 2026 group stage reaching its climax, football fans worldwide are speculating about who will make it to the finals. To make this experience interactive, I built a fully dynamic World Cup 2026 Bracket Simulator. Instead of just letting users click and choose winners, this app dynamically calculates ELO win probabilities and probabilistically generates realistic match scores (including extra time and penalties) based on team ratings. It also syncs with live match data in real-time. Live URL: https://worldcup-predict2026.github.io/champion/ Tech Stack: Vanilla JS, CSS3 (3D parallax), GitHub Actions, Python, football-data.org API Core Features & Technical Implementation ELO-Based Win Probability & Score Simulation Each team in the database is assigned an ELO-based strength rating. When a user runs the AI auto-prediction, the script calculates win probability and generates a realistic scoreline. Here is the goal roll algorithm (Poisson-like simulation) implemented in Vanilla JS: javascript function generateMatchScore(team1, team2, winner) { if (team1 === "TBD" || team2 === "TBD" || !winner) return null; const s1 = teamStrengths[team1] || 70; const s2 = teamStrengths[team2] || 70; const winnerIsTeam1 = (winner === team1); const strengthDiff = Math.abs(s1 - s2); const baseGoalExpected = 1.1; const bonusGoal = Math.min(1.8, strengthDiff / 12.0); // Goal weight based on ELO difference const rollGoals = (lambda) => { let L = Math.exp(-lambda); let k = 0; let p = 1.0; do { k++; p *= Math.random(); } while (p > L && k < 10); return k - 1; }; let gWin = 0; let gLose = 0; const r = Math.random(); if (r < 0.75) { // Regular time win (90 mins) gLose = rollGoals(baseGoalExpected); gWin = gLose + 1 + rollGoals(0.7 + bonusGoal); return winnerIsTeam1 ? ${gWin} - ${gLose} : ${gLose} - ${gWin} ; } else if (r < 0.92) { // Extra time win (AET) const normalGoals = rollGoals(baseGoalExpected); gLose = normalGoals; gWin = normalGoals + 1; return winnerIsTeam1 ?