标签：#EV

Last month, an AI coding agent handed me a beautiful fix. Five lines. Elegant. It reused an existing helper, matched the codebase style, compiled on the first try. Exactly the kind of diff we've all learned to praise since "make the agent write less code" became the standard advice. It was also completely untested, and it sat on a password-recovery path. That diff taught me something I now consider the central problem of AI-assisted coding in 2026: we've spent a year teaching agents to write less code, and almost no time teaching them to prove the code they kept actually holds. The two failure modes Every AI coding agent fails in one of two directions. Failure mode #1: the over-build. You ask for a date comparison; you get a new dependency, a ValidationService class, and a config layer. This one is well known — it's why minimal-code prompts and skills became popular, and they genuinely work on it. Failure mode #2: the confidently small diff. Minimal, clean, written after reading half the flow, verified never — dropped onto a path that handles money, auth, or user data. It compiles. It demos. It detonates in week three. Here's the uncomfortable part: fixing #1 aggressively makes #2 more likely. When the objective function is "shortest diff," the first things to quietly disappear are edge-case handling, failure-path tests, and the guard clause that looked optional. The diff gets smaller. The blast radius doesn't. A five-line change to a payment path is more dangerous than a four-hundred-line internal script that runs once. Code size is not risk. Blast radius is risk. Yet almost every skill and prompt in this category optimizes for size alone. What a guard does differently This is why I built Guardsman 💂 — an open-source skill that behaves less like a minimalist and more like the royal guard in front of the palace: nothing passes the post unchallenged, and the level of challenge depends on what's behind the gate. Three duties, on every task: 1. Read the standing orders

This is a submission for Weekend Challenge: Passion Edition What I Built Passion Roast is an AI "Passion Judge" that looks at a photo of your fan setup, collection, or hobby corner — plus the name of whatever you're obsessed with — and roasts you for it, scores your devotion out of 100, and hands you a mock diploma for your dedication. The goal was simple: capture the universal feeling of being a little too into something you love, and let an AI genuinely react to real, specific details in your photo instead of giving generic responses. Demo 🔗 Live app: https://passion-roast-production.up.railway.app 🎥 Demo video / GIF: <link here> Try it with a photo of anything you're passionate about — a jersey collection, a gaming setup, houseplants, vinyl records, whatever. Each roast is generated fresh from what's actually in the picture. Code https://github.com/NOVA-X-Code/passion-roast How I Built It Backend: Node.js + Express, with Multer handling in-memory image uploads (no files ever touch disk). Google AI (Gemini API): the entire app is built around a single multimodal call — the uploaded photo (as inlineData ) and the declared passion are sent together to Gemini with a system prompt defining "The Passion Judge" persona. Gemini is instructed to return strict JSON (passion score, mock diploma title, roast, verdict), which the backend parses and validates before sending it to the frontend. Frontend: vanilla HTML/CSS/JS with drag-and-drop upload and a shareable-style result card — no frameworks, no build step. I deliberately kept the stack to a single external API. Rather than chaining multiple services, I focused on getting real value out of Gemini's multimodal reasoning: the roast has to reference actual details Gemini sees in the image, not just repeat the passion name back with generic flattery/insults. Prize Categories Best Use of Google AI weekendchallenge

Interactive Rive mascots can react, think, talk, and connect to real AI, SaaS, web, and mobile products. Your SaaS Mascot Should Do More Than Just Sit There 👀 A lot of products have mascots. They look great on landing pages. Maybe they wave. Maybe they blink. Maybe there is a small looping animation. And that's it. But I think a product mascot can do much more. What if your mascot actually knew what was happening inside your product? That's the idea I've been exploring with Mascot Engine . I don't just want to animate characters. I want to build interactive mascot systems that connect to real products . From a mascot animation to a product system Imagine you're building an AI app. A user opens the app. The mascot is idle . The user sends a message. The mascot starts thinking . The AI begins responding. The mascot switches to talking . The task completes. The mascot celebrates . Something goes wrong? The mascot reacts to the error . The flow could look like this: User Action ↓ Product State ↓ Runtime Input ↓ Rive State Machine ↓ Mascot Reaction This isn't a video. It isn't a GIF. It isn't a pre-rendered animation playing randomly. The product controls the mascot at runtime. That's where things become interesting. A mascot can understand product states Well... not literally understand them 😄 The application still owns the logic. But we can expose a small runtime contract from the Rive file. For example: emotion = 2 isTalking = true lookX = 40 lookY = -10 celebrate = trigger error = false The developer controls these values from the application. The Rive State Machine handles the character behavior. The application controls what happened . The mascot system controls how the character reacts . I really like this separation. Why I use Rive for interactive mascots Traditional animation tools are great for videos and motion design. But product animation has different requirements. The character needs to react to application events. The animation may need runtime values. De

This is a submission for Weekend Challenge: Passion Edition What I Built HahaNotes is an interactive web application designed to help developers, office workers, and students vent their daily stress by transforming real-world struggles (legacy code at 3 AM, unpaid overtime, sếp hãm, or exam stress) into hilarious, sarcastic AI-voiced banters, complete podcasts, and ready-to-share short videos. The application features a dynamic dialogue between two contrasting AI hosts: Rookie (The Naive Optimist): A starry-eyed beginner who sees the world through rose-colored glasses and speaks in trendy buzzwords. Cynic (The Sarcastic Senior): A battle-hardened veteran who gently (or not so gently) pops Rookie's bubble with witty, dry, and highly relatable tech sarcasm. Users can input their struggles, choose their favorite voices for the hosts, generate structured comedy scripts, chat continuously with the hosts to extend the banter, listen to fully produced podcasts with ambient lo-fi background music/laugh tracks, and export 9:16 vertical short videos with synchronized karaoke captions and visual memes. Demo Video Demo: Website Demo: https://hahanotes.vercel.app/ Code omlttg / hahanotes 🎙️ HahaNotes Banishing Developer Burnout with AI Banter Podcasts & Short Videos Live Demo: hahanotes.vercel.app Weekend Challenge: Submitted for Weekend Challenge: Passion Edition 🌟 Introduction HahaNotes is an interactive web application designed to help developers, office workers, and students vent their daily stress by transforming real-world struggles (e.g. legacy bugs at 3 AM, unpaid overtime, or exam anxiety) into hilarious, sarcastic AI-voiced banters, complete podcasts, and ready-to-share short videos. The application features a dialogue between two contrasting AI hosts: Rookie (The Naive Optimist): A starry-eyed beginner who sees the world through rose-colored glasses, uses corporate buzzwords, and believes completely in hustle culture. Cynic (The Sarcastic Senior): A battle-hardened ve

This is a submission for Weekend Challenge: Passion Edition What I Built I built Origin —...

Python is an excellent language for automating cloud infrastructure, but the official Kubernetes Python client leaves developers with an important architectural decision: Where should Kubernetes manifests live? Should they be constructed directly with Python objects? Embedded as multiline strings? Or stored as external files and rendered at runtime? Each approach works, but they have very different implications for readability, maintainability, and long-term operational cost. The key is recognizing that deployment logic and platform configuration evolve on different lifecycles. Your deployment code, the part that authenticates to Kubernetes, renders templates, and applies resources, may remain unchanged for months. Your manifests, however, often change weekly as applications evolve, resource limits are tuned, cloud-provider annotations are added, or networking requirements change. When those two concerns are tightly coupled, even a configuration, only change forces you to modify, test, and redeploy the delivery or application code itself. Over time, this increases maintenance costs, slows platform changes, and makes configuration drift and production mistakes more likely. This is a familiar software engineering principle: separate concerns that evolve independently. The same thinking that keeps application configuration separate from executable code also applies to Kubernetes manifests. Treating manifests as first-class configuration artifacts allows them to evolve independently from the Python code that delivers them. In this article we'll compare three ways of deploying Kubernetes resources with the official kubernetes-python-client , ranging from tightly coupled implementations to a design that cleanly separates deployment logic from platform configuration. The Landscape at a Glance The comparison below assumes a common application deployment scenario, where the desired state is largely known ahead of time. Controllers and Operators have fundamentally different r

If you need real-time BTC conversion (USD and BRL), polling an API every few seconds is usually not enough. A better approach is streaming quotes with WebSockets and calculating conversions as events arrive. Why WebSockets for BTC conversion? With WebSockets, your app keeps one open connection and receives new prices instantly. Benefits: Lower latency than polling Fewer HTTP requests Better user experience for real-time values Trade-offs: You must handle reconnects Need heartbeat/health checks Must validate and normalize incoming messages Real-time conversion model For BTC conversion, a common model is: Stream BTC/USD Stream USD/BRL Calculate BTC/BRL = BTC/USD × USD/BRL This avoids waiting for a separate BTC/BRL endpoint and keeps conversion logic transparent What is a “tick”? A tick is one market update event. Example: BTCUSD changed to 64210.50 at timestamp t . In this article, each tick has: pair : market identifier ( BTCUSD , USDBRL ) price : latest value for that pair ts : event timestamp Why this matters: conversion state should always be derived from the latest ticks . Minimal WebSocket client (TypeScript) This client only transports responsibilities: Connect Receive messages Parse and normalize into a consistent shape Notify listeners Reconnect on disconnect type MarketTick = { pair : string ; // e.g. "BTCUSD" or "USDBRL" price : number ; ts : number ; }; class WsFeedClient { private ws ?: WebSocket ; private listeners : Array < ( tick : MarketTick ) => void > = []; constructor ( private readonly url : string ) {} connect () { this . ws = new WebSocket ( this . url ); this . ws . onopen = () => console . log ( " [ws] connected " ); this . ws . onmessage = ( event ) => { try { const data = JSON . parse ( String ( event . data )); // Normalize external payload into internal contract const tick : MarketTick = { pair : String ( data . pair ), price : Number ( data . price ), ts : Number ( data . ts ), }; // Basic guard if ( ! tick . pair || Number . isNaN ( tick

Hi guys, I've been working on Regdrift, my first open-source project. It's a CLI and GitHub Action that compares two CMSIS-SVD files to check whether there are any register-map changes that could affect firmware functionality. It catches changes such as moved registers, interrupt renumbering, access changes, and altered read/write behavior. It then classifies those changes as BREAKING , WARNING , or SAFE so the tool can act as a CI gate. I'm looking for feedback from people who maintain SVDs, HALs, PACs, SDKs, or firmware repositories. If possible, I'd like to test it against real old/new SVD pairs and learn where the classifications produce false positives, miss important changes, or are unclear. For people who work frequently with CMSIS-SVD files: which types of register-map changes are most detrimental to firmware or cause the most difficult code-related problems? Resources GitHub: https://github.com/Pranav-s79/regdrift Install pip install regdrift Usage regdrift check old.svd new.svd

This is a submission for [Weekend Challenge: Passion Edition] What I Built Over the years, I watched my mom do the same work over and over, often spending 2 to 4 hours preparing a single telecom SLA report. She works in network field maintenance for a telecom company in Nigeria, and every reporting cycle she has to manually read fault descriptions from field engineers, usually pasted directly from WhatsApp, classify each fault into the company's standardized taxonomy, and format everything into an Excel compliance report. At one point, I learned the process myself so I could truly understand what she was going through. After doing it firsthand, I realized how mentally and physically exhausting it was. Sitting for hours on a repetitive task that required constant attention wasn't just inefficient, it was draining. That experience made me ask one simple question: What could I build to make this easier for her? That question became this project. The Telecom RCA Automation System reduces a task that used to take 2 to 4 hours to about 5 minutes, cutting the workload by more than 95% while improving consistency and reducing manual errors. This project wasn't built over a single weekend. It started months ago as a side project that I'd return to whenever I had free time. It never quite felt ready to share. When the Weekend Challenge: Passion Edition was announced, it gave me the motivation to go back, refine the classification engine, fix long-standing bugs, improve the user experience, and finally build something I was proud to release. More than anything else, this project is about giving someone I love a few hours of her evening back. Demo https://telecom-rca-automation-system.vercel.app * 🎥 Demo Walkthrough * https://youtu.be/EIdFDKtcIZw The video demonstrates the complete workflow, from uploading the telecom availability report to generating the final SLA report, and highlights how Google Gemini AI assists with ambiguous fault classification. Code https://github.com/t

Here is a design decision we made early, wrote into the architecture as an invariant, and have refused to revisit since: our agent accepts no commands. Not "we don't currently use that feature" — the hub has no way to tell an installed agent to do anything at all. No remote execution, no self-update, no "collect this for us right now". It sends data outward, and that is the entire surface. This is not a limitation we are working around. It is the product. And it costs us features that customers ask for, which is exactly why it is worth explaining. The uncomfortable arithmetic of remote control Any tool that can update a plugin across fifty client sites is, by construction, a tool that can execute code on fifty client sites. Any dashboard that can restart a service on your server holds, somewhere, a credential that lets it in. This is not a flaw in those products — it is what they are for. You cannot automate a repair without the power to perform it. But that power has an owner, and the owner has a login, and the login has a support team, and somewhere in that chain there is a version of the software with a bug in it. When the tool is compromised, the blast radius is not the tool. It is every machine the tool could reach. The industry has already run this experiment at scale. In July 2021, attackers exploited a vulnerability in a widely used remote monitoring and management platform. They did not break into a single company — they broke into the thing that had access to the companies. Roughly sixty managed service providers were hit, and through them, an estimated 800 to 1,500 downstream businesses were encrypted in a single weekend, with a $70 million ransom demand attached. Read that shape again, because it is the whole argument: the victims did nothing wrong. They had bought a well-known product from a serious vendor and installed it exactly as instructed. Their compromise arrived through the door they had deliberately, sensibly, contractually left open — the one

Concept design for a building is slow and expensive. A homeowner planning an extension, or a contractor trying to win a job, is stuck between two bad options: pay a drafter $500–2,000 for a concept package, or fight SketchUp's learning curve for a week. Meanwhile the actual idea — "a 4-bed duplex with a garage and a palm out front" — fits in one sentence. So I built Forge3D Spaces : you type that sentence, and a few seconds later you're walking through a furnished 3D house in your browser — with measured floor plans, DXF for AutoCAD, and a cost estimate that come out of the same model. No install. Here's how it works under the hood. The pipeline: sentence → structured plan → building The naive approach — "ask an LLM to emit a 3D scene" — falls apart fast. Models are bad at spatial consistency; walls don't meet, rooms overlap, doors float. So the LLM never touches geometry directly. It emits a structured program , and a deterministic solver turns that into a watertight building. The prompt becomes a spec. A strict JSON-schema call (OpenRouter, json_schema response format with every field required) turns "4-bed duplex with a garage" into a room program: room types, target areas, adjacencies, storeys. A slicing-tree solver lays it out. This is the old floorplanning trick from chip design — recursively split a rectangle with horizontal/vertical cuts until every room has its area. A squarify pass keeps rooms from collapsing into corridors. The output is exact rectangles with real dimensions, guaranteed non-overlapping and gap-free. Walls, openings, roof, furniture get generated from the solved plan. Every door and window is placed by rule, not by vibes. Because the plan is a real data structure, the 2D floor plan, the 3D model, the elevations, and the bill of quantities are all views of the same thing . Drag a wall and they all move together. Nothing drifts out of sync, because there's nothing to sync — it's one model. The rendering: WebGPU, and the fallback you actually

Matmos are an incredibly accomplished duo between their own solo records like the masterpiece A Chance to Cut Is a Chance to Cure and production classic Bjork records like Vespertine. But Drew Daniel, one half of Matmos, is fiendishly prolific. When he's not literally dreaming up new viral music genres, he's also putting out records […]

Most WooCommerce product pages still show the same thing stores have shown for 20 years: a handful of flat photos. I spent the last few months building Noorifa, a plugin that replaces that with an interactive Three.js viewer — customers rotate the model, zoom in, and switch colors/materials on specific meshes in real time, synced to the store's actual WooCommerce variations. The 3D rendering part was the easy 20%. The other 80% was a series of small, specific problems that don't show up in a Three.js tutorial. Here are four of them. 1. A directional light rig can't light a face it can't see Early on, customers rotating a table model would find the underside of the tabletop rendering near-black — no matter how far I pushed the light intensity. The rig at the time was a single key light plus a hemisphere ambient: scene . add ( new THREE . HemisphereLight ( 0xffffff , 0x444444 , 1.2 ) ); const keyLight = new THREE . DirectionalLight ( 0xffffff , 1.2 ); keyLight . position . set ( 3 , 5 , 4 ); scene . add ( keyLight ); The bug was geometric, not a brightness problem: keyLight sits above the model, so its light direction only reaches surfaces whose normal faces back toward it. A downward-facing surface — the underside of an overhanging tabletop — can't receive any direct contribution from a light positioned above it, at any intensity. Cranking the brightness slider was scaling a number that was multiplying against zero. The fix was closer to actual three-point studio lighting: key, fill, and rim from above for shape and separation, plus a dedicated light from below, and a brighter hemisphere ground color to approximate bounced light: scene.add( new THREE.HemisphereLight( 0xffffff, 0x888888, 1.1 * brightness ) ); const keyLight = new THREE.DirectionalLight( 0xffffff, 1.1 * brightness ); keyLight.position.set( 3, 5, 4 ); const fillLight = new THREE.DirectionalLight( 0xffffff, 0.5 * brightness ); fillLight.position.set( -4, 2, 3 ); const rimLight = new THREE.DirectionalLigh

This is a submission for Weekend Challenge: Passion Edition TL;DR SQL can count a commit trail. It can't always find the story it tells. Name a public GitHub repo. Snowflake fetches its commit history, decides which story is actually in there, and asks Cortex to narrate that one thread. You get a card you can drop into a README. 6 storyline detectors, 15 SQL views, and 0 AI calls in any of them—the story is chosen by plain SQL. Then 1 Cortex call, on 20–140 commit lines: 25% of the repo's, clamped. The warehouse is the editor. Cloud Run paints a PNG and computes nothing. Live at commitchronicles.anchildress1.dev , code at v1.0.0 , and I'm going for Best Use of Snowflake . What I Built Commit Chronicles reads one public GitHub repo and gives it back to you as a story. Snowflake fetches the repository, decides which story exists, gathers the evidence, asks Cortex to narrate exactly that thread, validates the result, and returns structured JSON. Cloud Run just turns it into a 1200×630 PNG—the size a README embed and a social preview both want. This is one of my repos and every dot, timestamp, and quoted commit on it is real. The color isn't just decoration—Cortex picks the accent hex as a reading of the arc, so a repo that died and one that came back and shipped don't look the same. The scope is deliberately one repository , not a whole profile. A year-in-review across a profile turns to mush. A repo has a clean arc: commits start, cluster, pause, restart, or stop. Two rules hold it together: Cortex interprets the shape. It never invents the facts. Every timestamp, count, gap, and quoted message on the card is real. It reads the arc; it does not reach past it. Motivation isn't in the data, so the model is forbidden from claiming any. A repo with no real story says so. Sparse histories get an honest grey card— "no story here" —and Cortex never runs. Not every repo is an obsession, and a tool that admits that is the one you trust when it says otherwise. Why I built it 🪤

Throughout my career I have had to work with quite a few platform teams, and I was part of two for a couple of years. Some were bad, some were good and some should not have existed at all. I want to tell you my user experience, what I have seen work and what not and what you should definitely avoid doing. Be The Multiplier This is the main goal of a platform team. As a team, it needs to be a multiplier. If the platform team supports 10 teams, then each work it commits should multiply by 10. If the team member builds a new feature, it should be helpful for all the other teams. Otherwise, the platform team is an addition, and in most cases it is then better to split the platform team and add them to all other teams, instead of being a separate team. Because the amount of communication needed is in most cases quadratic in relation to the number of teams. Reducing Cognitive Load The platform should take away cognitive load for all the teams it supports. By doing so, they will have more time to implement business requirements. Let's say a platform team provides Gitlab runners or Azure Agents where people can run their CI/CD code on. They should not need to know how the runners are scaled, or how the agents are updated. This takes away the need for that skill set in all the teams. Build a Community A platform team has a unique position. It is building something that all other developers probably can build as well. Some could do it even better than the platform team itself. For some platform teams, their ego sometimes comes in to play or just straight up refuses their help because they are not the team. But it is not the job of the platform team to build a product, but a platform where everyone can thrive and/or build on. So onboard the community on the platform! The Law of Diffusion applies to almost all companies. You will have the innovators that want to build it themselves and the early adopters that will voice their opinion, but will not build it themselves. Those two

No hacking — a passive scan only looks at what your browser already downloads when it opens a page. Here's what I found: 6 of 15 load their Supabase database directly client-side. The public API key sits in the page source. That's fine if Row-Level Security is configured right — but it's one wrong setting away from "anyone can read the whole table." 14 of 15 ship no Content-Security-Policy — a simple, high-value hardening against script injection, almost always missing. Is this theoretical? No. Two apps I audited with the owner's permission: A social app: the profiles table — user names, cities, and a password hash — readable by a logged-out stranger. Closed in an afternoon. A paid learning app: 155 paid study sheets and 4,872 answers were readable by anyone, with no account and no subscription — its entire paid catalogue, a single API call away. The paywall lived only in the front-end; the database served everything to everyone. Loading Supabase in the browser isn't the mistake. Not enforcing access in the database (RLS) is. And the tools you build with won't tell you — they'll happily ship it. If you built something on Lovable / Bolt / Replit with real users (or paying ones), it's worth 60 seconds to check what a stranger can already see. I made a free tool that runs the surface check (passive, no signup): sealdy.dev Happy to answer questions on how RLS leaks happen and how to lock them down.

The Developer's Guide to Picking the Right Coding LLM at Scale Six months ago, I was staring at our monthly AI bill — $14,000 and climbing fast. We were using the "premium" model for everything, including trivial code completions. That night, I built a small internal benchmark to figure out which models actually earn their cost. What I learned reshaped how we think about AI tooling, vendor lock-in, and what "production-ready" really means. Here's the raw truth from my testing rig, what we shipped, and how we cut costs by 70% without touching output quality. Why I Stopped Trusting Default Recommendations Every vendor says their model is the best. Every benchmark site ranks things differently. Most "best of" lists are either sponsored or built on vibes. I needed numbers that matched my actual workflow: generating Python services, debugging JavaScript race conditions, implementing TypeScript algorithms, and reviewing Go for security. So I took ten models, threw identical prompts at them, and scored them myself. No vendor PR. No cherry-picked examples. Just the same five tasks, run the same way, scored on the same rubric. Here are the ten models I tested, with their output pricing per million tokens — because at scale, that's the metric that decides whether your AI strategy is viable or a margin killer. Model Provider Output $/M DeepSeek V4 Flash DeepSeek $0.25 DeepSeek Coder DeepSeek $0.25 Qwen3-Coder-30B Qwen $0.35 DeepSeek V4 Pro DeepSeek $0.78 DeepSeek-R1 DeepSeek $2.50 Kimi K2.5 Moonshot $3.00 GLM-5 Zhipu $1.92 Qwen3-32B Qwen $0.28 Hunyuan-Turbo Tencent $0.57 Ga-Standard GA Routing $0.20 Before you ask: yes, I tested against the originals. I also tested against Global API's unified routing layer, which lets you hit any of these through one endpoint. More on that later — it became the architectural decision that actually saved us. My Benchmark Methodology (No Marketing Fluff) I built five tasks that mirror what my engineers actually do every week. Not synthetic acad

We Taught a Snowflake Warehouse to Judge World Cup Conviction and Write the Verdict Back to Solana Soumyadeep Dey Soumyadeep Dey Soumyadeep Dey Follow Jul 12 We Taught a Snowflake Warehouse to Judge World Cup Conviction and Write the Verdict Back to Solana # devchallenge # weekendchallenge # snowflake 5 reactions 1 comment 16 min read

Every operating system has security gaps. Most never publish them. I am publishing mine. IONA OS is a sovereign operating system written from scratch in Rust. It has a kernel, a GUI, a blockchain protocol, a programming language, and a 140,000‑line AI running in Ring 0. It is designed to be secure by default. But secure is a journey, not a destination. Here is the hard list — the security issues I found in IONA OS, and what I am doing about them. 1. The filesystem is not encrypted at rest IONAFS reads and writes sectors in plain text directly to the disk. I already have a real ChaCha20‑Poly1305 engine with per‑file key derivation ( fs/encrypted_storage.rs ), but it is only used for backup/distribution — not for everyday local reading and writing ( fs/ionafs/mod.rs ). Why this matters: For a journalist or a civil servant, this is the central threat scenario: a lost device, confiscation at a border, or seizure. What I'm doing about it: Integrating encrypted_storage.rs into the normal IONAFS read/write path. Every write will be encrypted automatically. The key will be derived from a PIN or TPM. 2. Deleting a file does not destroy it delete_file() removes only the index entry. The data sectors remain on the disk, recoverable with standard forensic tools. Why this matters: For users with high security requirements — journalists, activists, government officials — this is a critical gap. What I'm doing about it: Adding a shred() function that overwrites the data sectors with random patterns before releasing them, with a configurable number of passes. 3. The keystore uses XOR, not real encryption security/keystore.rs pretends to use AES/ChaCha in its comments, but the actual implementation is a simple XOR stream — trivial to break once an attacker has access to the disk. Why this matters: This is a critical vulnerability. XOR is not encryption. If an attacker has access to the disk, they can recover the keys. What I'm doing about it: Replacing the XOR stream with real ChaCh

I wanted to build something different from the usual fan project. Instead of recreating gameplay, I asked a different question: How well do players actually remember the worlds of Super Mario Odyssey? The result is OdysseyGuessr, a browser game inspired by GeoGuessr. Players receive a screenshot from one of the game's Kingdoms and must place a marker on the correct location. Every meter counts. The project includes: Browser-based gameplay Single-player with customizable rounds Real-time multiplayer with a 5,000 HP battle system Community-submitted locations Admin moderation tools One of the biggest challenges wasn't the gameplay—it was collecting interesting locations that were difficult but still fair. Watching players confidently choose the wrong cliff or rooftop has been surprisingly entertaining. If you're interested in browser games or Nintendo fan projects, I'd love to hear your feedback. Play here: https://odyssey-guessr.lovable.app OdysseyGuessr is an unofficial fan project and is not affiliated with Nintendo.