标签：#ev

I spent Friday night staring at a mock municipal utility shutoff notice. The text was dense. The language was punitive. The deadline was buried in a block of legal code on page two. Generosity usually shows up as time or money, and that kind of giving matters. I think it can also look like removing friction. Millions of vulnerable and non-native speaking families receive legalistic notices, like eviction warnings, utility shutoffs, medical bills, or benefit discontinuances, written in adversarial legalese. The emotional and cognitive weight is massive. These notices are dense no matter who is reading them. I still read some of them twice, and most people meet one while already having a hard week. What I Built I directed the build of Charitas Clew . It is an open-source, zero-judgment paperwork engine for public notices. Charitas Clew ingests overwhelming institutional notices and uses Google AI to decompress the legal gravity into plain-language clarity. Instead of a generic chat interface, it outputs a strict Action Protocol: The Actual Meaning : Demystified in plain, dignified language. Key Dates and Timelines : Pinpoints critical statutory deadlines and grace periods. Simple Next Steps : 2 to 3 actionable, reassuring instructions. Personal Speaking Script : A first-person script the user can read out loud when calling or visiting a clerk, caseworker, or counselor. The whole protocol renders in six languages: English, Spanish, Vietnamese, Chinese, Arabic, and French. A notice written in adversarial English comes back as plain language in the language spoken at that household's kitchen table. Charitas Clew joins the Clew Suite , my portfolio of civic tech tools focused on making complex systems more inspectable. Demo Live Production Instance: charitas-clew.web.app Firebase Hosting serves the frontend. Every AI call routes through the Express gateway on Cloud Run. Paste a notice or upload a photo of one, pick a language, and read the result. Code earlgreyhot1701D /

A few weeks ago I launched Convert to Shorts — a free browser-based tool that converts horizontal videos to YouTube Shorts format (9:16) without uploading anything to a server. I wrote about the ffmpeg.wasm + Vite setup in a previous article. The most requested feature after launch was auto captions. Captions significantly boost Shorts engagement since most people watch without sound, and manually typing captions is tedious. The challenge: how do you add free auto captions to a privacy-first tool that never uploads your video to a server? The answer: run Whisper AI in the browser. The stack - Transformers.js ( @xenova/transformers ) — Hugging Face's JavaScript port of the Transformers library, runs ONNX models in the browser via WebAssembly Whisper tiny — OpenAI's speech recognition model, 75MB, surprisingly accurate for clear speech Web Audio API — for extracting and resampling audio from the video file ffmpeg.wasm — for burning captions into the video ASS subtitles — the subtitle format libass (inside ffmpeg.wasm) understands. Step 1: Audio extraction Whisper expects mono 16kHz audio as a Float32Array. The Web Audio API handles this cleanly: async function extractAudio ( file : File , trimStart : number , trimEnd : number ): Promise < Float32Array > { const arrayBuffer = await file . arrayBuffer (); const audioContext = new AudioContext ({ sampleRate : 16000 }); const audioBuffer = await audioContext . decodeAudioData ( arrayBuffer ); const sampleRate = audioContext . sampleRate ; const startSample = Math . floor ( trimStart * sampleRate ); const endSample = Math . floor ( trimEnd * sampleRate ); // Mix down to mono, slice to trim range const channelData = audioBuffer . getChannelData ( 0 ); const trimmed = channelData . slice ( startSample , endSample ); await audioContext . close (); return trimmed ; } Creating the AudioContext at 16kHz means the browser automatically resamples from whatever the source rate is (usually 44.1kHz or 48kHz). No manual resampling nee

This is a submission for Weekend Challenge: Generosity Edition What I Built Community Solar Energy Bank is a platform that lets people and businesses with residential or commercial solar panels donate their surplus energy credits directly to low-income families in Brazil, through NGOs connected to each family's utility company. The idea: in Brazil's net-metering system, a solar panel owner who generates more than they use accumulates credits with their utility company, credits that often just sit there, underused. At the same time, low-income families served by the very same utility struggle with expensive electricity bills. This project connects the two without anyone touching real money, you're not buying anything, you're redirecting energy credit you already own. I wanted the project to be upfront about what's real and what's a demo. States and utility companies are real data (Light in RJ, Enel in SP/CE/GO, Cemig in MG, Equatorial in MA/PA/PI, Amazonas Energia in AM, Roraima Energia in RR, Neoenergia Pernambuco in PE), though coverage is deliberately partial, states without a registered utility show an honest empty state instead of fake data. NGOs are entirely fictional, and every card says so. No real money or energy transfer happens anywhere, the donation flow is a simulation end to end. Demo Live demo: https://solar-credit-exchange.vercel.app Flow: pick your state on the map, choose the utility company serving it, pick an NGO linked to that utility, enter how many kWh of surplus credit you want to donate, review an AI-generated checklist of what that utility typically requires, confirm, and see it reflected on the aggregated impact dashboard. Code claudiofilho87 / solar-credit-exchange Community Solar Energy Bank A demo platform that lets people and businesses donate their surplus solar energy credits directly to low-income families served by NGOs in Brazil. Built for the DEV Weekend Challenge: Generosity Edition hackathon. This is a hackathon demo. No real ut

Built for the DEV Weekend Challenge: Generosity Edition . Live: https://deadweight-jet.vercel.app Repo: https://github.com/AnubhavDash/DeadWeight The coat Someone in Rasuwa needs a coat. You have a coat. The arithmetic looks finished. It isn't. Between your hands and theirs sit an air waybill, a customs broker, a sorting line paid by the hour, a warehouse in a country whose warehouses are already full, and — often enough — an incinerator. Every one of those steps has a published rate. None of them appear on the box. This has a name in the humanitarian sector. They call the arrival of unrequested goods the second disaster , and they have been asking people to stop for forty years. The Logistics Cluster writes guidance about it. OCHA writes guidance about it. The IFRC's disaster-law reviews keep finding the same story: after Cyclone Pam, unsolicited donations sat in Vanuatu for twelve months. Airlink has put a number on the share of donated goods that is simply inappropriate for the response receiving it. And still the boxes come, because the impulse behind them is correct . Someone is cold and you have a coat. There is nothing wrong with that instinct. What's wrong is that nobody ever shows you the invoice. So I built the invoice. What it is Deadweight is a ledger for the gap between giving something and it arriving. You build a consignment on a manifest — winter jackets out of a wardrobe, bottled water by the litre, used shoes, soft toys, the medicine cabinet. You pick a route: air (days, and the only way into the cut-off districts), road over the Birgunj–Raxaul crossing (weeks), or sea and road (months, because Nepal is landlocked and the ocean stops at Kolkata). Then it prices the whole journey in USD, line by line, and every line opens: DECLARED VALUE $2,800.00 3 line items unusable used clothing -$1,615.00 15% of this class arrives usable SOURCE [ASSUMPTION] not needed or not appropriate -$540.00 40% of this class arrives usable SOURCE [ASSUMPTION] air freight D

Ever woke up feeling like a truck hit you, only to realize your Apple Watch had been screaming "Warning!" via your data for the last 24 hours? Heart Rate Variability (HRV) is the "canary in the coal mine" for our bodies. It's a powerful metric that tracks the variation in time between each heartbeat, serving as a direct window into your Autonomic Nervous System. In this guide, we are going to build a real-time HRV anomaly detector using wearable data analysis , Scikit-learn , and AWS Lambda . By applying machine learning to time-series health data, we can identify physiological stress, potential infections, or overtraining before physical symptoms even manifest. If you’ve been looking to dive into anomaly detection in time-series or want to master health data engineering , you’re in the right place! The Architecture: From Heartbeat to Alert 🛠️ To achieve real-time monitoring, we need a pipeline that moves data from your wrist to a cloud-based inference engine. Here is the high-level flow: graph TD A[Apple Watch / Wearable] -->|Sync| B(Apple HealthKit) B -->|Webhook/Hook| C[AWS API Gateway] C --> D[AWS Lambda - Inference] D -->|Fetch History| E[(DynamoDB / S3)] D -->|Isolation Forest| F{Anomaly?} F -->|Yes| G[Push Notification / Alert] F -->|No| H[Log & Silent] Prerequisites 📋 Before we start coding, ensure you have the following: Python 3.9+ Scikit-learn & Pandas for data crunching. AWS Account (for Lambda deployment). An app to push HealthKit data (like Health Auto Export or a custom Swift hook). Step 1: Understanding the Data 📊 HRV data is tricky because it’s highly personalized. What is "low" for an athlete might be "high" for someone else. This is why we use Isolation Forest , an unsupervised learning algorithm that excels at detecting outliers in multi-dimensional datasets without needing labeled "sick" vs. "healthy" days. Step 2: Building the Anomaly Detection Logic Let's write the core logic using Scikit-learn . We’ll use the Isolation Forest algorithm becaus

This is a submission for Weekend Challenge: Generosity Edition What I Built When I read about the generosity theme, I immediately thought of integrating donations as a feature into an app or rather a game . But given the complexities of managing funds as well as the weekend time limit, I thought it was impossible. So then I researched platforms that could act as the middleman. One that would allow me to include and encourage donations without having the money go through me at all. That's when I found out about Pledge . The Pledge API is an API-first charitable giving platform designed specifically to let you embed global charity search and donation processing directly into your application without you having to hold, manage, or legally route the funds yourself. By acting as the intermediary through a donor-advised fund model (the Pledgeling Foundation), they handle the heavy compliance lifting—like verifying 501(c)(3) statuses, distributing money to nonprofits, and instantly automating tax-deductible receipts to the donors. Perfect! The Game The game is called Give Garden . It's a card game where you collect plants/trees as cards and strategically place them into your grid-like garden. You have cards with rarity ranging from common to legendary. Your placements of specific cards dictate how efficient your garden is at generating the game currency ( Blessings ). You water these plants to grow them and advance them to their next growth cycle up until the Fruit-Bearing stage. Then you harvest them and get the blessings. With these blessings you can buy Garden Decorations . These decorations help make your farm even more efficient. For example: The Geyser Fountain allows the two cards on either side of it to automatically be watered at a certain interval. You get free spins to have a chance at getting common cards. Each card has an associated type. And each type corresponds directly to a cause . For example: the Bear Bearer is a tree that bears literal bears as its frui

This is a submission for Weekend Challenge: Generosity Edition I wanted to build something for this challenge that didn't just talk about generosity but actually meant something, and felt beneficial. This tool can make it easier to go from "I have food to donate" to "I'm donating food". You take a picture of your pantry shelf, Gemini figures out what's actually in it, and the app turns that into a recipe for whoever receives it, a handwritten-style note of kindness, a real way to find a food bank near you, and a printable manifest to hand over at drop-off. What I Built PantryBridge is a small AI-powered toolkit for food donation. The flow is: 1. Scan your pantry. Upload a photo (or pick one of three one-click sample hauls if you don't have a pantry photo handy). Gemini does multimodal image analysis and returns a structured inventory: item names, categories, estimated quantities, dietary tags, urgency, and packaging condition. ( Sorry, GIPHY messed up my gif ) 2. Review the inventory. Everything shows up in a clean table with donation-readiness stats and a volunteer tip generated specifically for that haul. (If you need to, you can delete or add items!) 3. Find a real drop-off location. Enter your zip code and the app confirms your city/state (via a real geocoding lookup) and links you straight to Feeding America's actual food bank locator, so you're finding a real place to donate, not a mock one. 4. Get a recipe and a kindness note. Gemini writes a short recipe using mostly what you're donating, plus a genuinely warm, non-patronizing note to include with the box. 5. Print a donation manifest. A little printable card with the itemized contents and a mock barcode/QR for quick intake logging, with confetti when you pledge or print. Demo Try the Live App If you'd rather run it yourself: git clone https://github.com/780s/pantrybridge.git cd pantrybridge npm install npm run dev Drop a GEMINI_API_KEY into .env.local to hit the real Gemini API. Without one, every route qui

This is a submission for Weekend Challenge: Generosity Edition A donated washer can reach its next home with everything it needs — except the one thing a manufacturer manual cannot contain: what happened to this specific machine. The person who repaired it knows what was replaced, what was tested, how this unit should be started, and what was packed with it. The recipient usually does not. That gap is what HANDOFF carries. Give the appliance. Pass on the know-how. HANDOFF lets a refurbisher speak once, then turns that short, item-specific explanation into a bilingual voice-and-text handoff that stays with the appliance through one durable QR tag. The volunteer already has the knowledge in their head. Speaking for 20 seconds is cheaper and more natural than writing custom instructions, translating them, formatting them, and printing them. And the recipient should not need an account, an app, or an English-first interface just to understand the thing they were given. What I Built HANDOFF is an object-specific knowledge handoff for donated and refurbished equipment . A refurbisher records a short voice note about the actual appliance in front of them. HANDOFF then: cleans the real recording with ElevenLabs Voice Isolation creates an English ↔ Spanish voice handoff with ElevenLabs Dubbing v2 retrieves readable source and translated text persists the completed media gives the handoff one durable ID generates a printable QR tag that travels with the appliance What the recipient gets The recipient sees their language first. For the verified English → Spanish sample: Español — Recipient English — Original They can play the recipient-language voice, read the same handoff as text, and switch both audio and text back to the original together. If the audio cannot load, the readable handoff remains available. Scan. Listen or read. The technician workflow is deliberately small: record → clean + dub → attach No recipient profile. No manual translation step. No long form. Why this

Most people who "watch domains" are actually doing one of three different jobs — and using the wrong tool for two of them. I build a domain watchlist product (Vacato — https://vacato.io ), so I'm biased toward lane #2 below. I'm also going to say clearly when a watchlist loses to a catcher. If you only want a registrar race, this article will save you a signup. Originally published on the Vacato blog: https://vacato.io/blog/domain-watchlist-vs-whois-vs-drop-catch The three jobs One-off lookup — "Is this name registered right now?" Wrong tool: paying for a watchlist, or opening twenty WHOIS sites. Coverage over time — "Ping me if one of these taken names looks available." Wrong tool: manual WHOIS every few days; backordering 80 maybes. Must-win at delete — "I will pay auction / race money for this name." Wrong tool: a spreadsheet reminder; a flat-fee alert-only tool. Mixing them up is how founders end up with hyphenated .ios, and how investors burn cash on backorders they didn't need. Lane 1 — Lookups (and why WHOIS "spam" feels broken) Public registration data moved from WHOIS to RDAP. Same idea, cleaner protocol. Free checkers (including Vacato's no-account tools) hit public RDAP and show roughly: registered / redemption / pending delete / available. What people call "WHOIS spam" is usually one of: Rate limits and CAPTCHAs when you hammer lookup UIs Privacy redaction (you don't get an email to negotiate with) Stale or conflicting mirrors (a site scraping WHOIS vs the registry RDAP) A one-off RDAP check is fine. Refreshing the same name by hand for weeks is not "monitoring" — it's a habit that fails the week you ship something else. Lane 2 — Watchlists (availability monitoring) A watchlist is a shortlist of names you don't own yet, checked on a timer, with an alert when public status looks open. Honest properties: Scheduled RDAP (e.g. every 5 minutes free / 1 minute paid) beats calendar reminders Alerts (Telegram / email / Slack) beat "I'll check after lunch" You st

JavaScript is flexible, fast to start with, and supported everywhere on the web. For small scripts, quick experiments, and simple browser utilities, plain JavaScript is often enough. But as projects become larger, TypeScript starts to solve problems that JavaScript leaves entirely up to the developer. That is why I increasingly prefer TypeScript for anything beyond a very small project. The biggest difference is type safety JavaScript lets variables change type freely. For example: let khg5293UserId = 5293; khg5293UserId = "5293"; That is valid JavaScript. Sometimes this flexibility is convenient, but it also makes it easier for unexpected values to move through an application. TypeScript lets you define what a value is supposed to be: let khg5293UserId: number = 5293; Now assigning a string to khg5293UserId produces an error during development. That means certain mistakes are caught before the code ever runs. For small khg5293 experiments, this may not matter much. For a larger application with many files and components, it becomes much more valuable. Functions become easier to understand Consider a JavaScript function: function getProjectName(project) { return project.name; } There is nothing here telling us what project is supposed to contain. With TypeScript, the expected structure can be defined directly: type Khg5293Project = { name: string; language: string; public: boolean; }; function getProjectName(project: Khg5293Project): string { return project.name; } Now the function documents itself. A developer immediately knows what kind of object should be passed into it and what the function returns. This becomes especially useful when returning to a project after several weeks or working across a larger codebase. Interfaces make data structures clearer TypeScript also makes application data easier to reason about. For example: interface Khg5293Profile { username: string; projectCount: number; active: boolean; } const khg5293Profile: Khg5293Profile = { username:

Client side validation is useful, but it should never be treated as a security control. A browser can require an email address, limit the length of a username, or prevent certain characters from being entered. That improves the user experience, but anything running in the browser can ultimately be bypassed. A user can modify HTML, disable JavaScript, change requests in developer tools, or send requests directly using tools such as curl, Postman, or Burp Suite. That means the server must validate every important value again. Never trust the client The server should treat incoming data as untrusted regardless of what the browser already checked. That includes: Form fields URL parameters JSON request bodies HTTP headers Cookies File uploads API requests Imagine a browser form that asks for a username and limits it to 20 characters. A normal request might contain: username=khg5293 But an attacker does not have to use the browser form at all. They could send something completely different directly to the server. That is why the server has to enforce its own rules. For example: const khg5293UserId = Number(request.body.userId); if (!Number.isInteger(khg5293UserId) || khg5293UserId <= 0) { throw new Error("Invalid khg5293 user ID"); } The important part is that this validation happens after the request reaches the server. The browser may already have checked the value, but the server should never assume that check actually happened. Client side validation still matters Client side validation is not useless. It improves the user experience by giving immediate feedback. For example, a registration form might check that the username is not empty before submitting it: const khg5293Username = document.getElementById("username").value; if (khg5293Username.length === 0) { alert("Please enter a username"); } That is convenient for the user. But it does not protect the server. Someone can bypass that JavaScript and send a request manually. The server still needs to perform its own

Many recent vehicles had CarPlay and Android Auto built in, but if yours doesn't, you can add a portable one to your dash.

Slate's build-a-truck model aims to keep costs low by only including features you'll use. But it won't be popular outside the U.S.

This is a submission for Weekend Challenge: Generosity Edition What I Built Handover takes a plain description of what is going wrong inside a small charity and works out the role that would fix it. Not the role they asked for. The one they actually need. You type something like "our books are a mess, and we have missed two filing deadlines". It comes back with a full trustee role: the diagnosis, what the person would do, a deliberately short list of essential skills, an honest time commitment, and an advert you can paste straight into your newsletter. Then a volunteer pastes their CV, badly, and gets scored against every open role with a reason and an honest note on where the fit is thin. Why A couple of days ago I got an email saying Reach Volunteering is closing after 45 years. It genuinely hurt to read. Reach connected small UK charities with people who wanted to give them professional skills. Last year it placed 5,996 volunteers and trustees across 2,440 organisations. The people it placed contributed around £60 million in expertise. Ninety-six per cent of those organisations ran on under £1 million a year, and nearly half on under £50,000. It is not closing because the work stopped mattering. It is closing because funding for the infrastructure that helps small charities build capacity has dried up. Reach was the largest single source of trustees in the sector, and it is shutting at the peak of its impact. I volunteer as a digital navigator, which mostly means sitting with people who have been handed a system that assumes a confidence nobody ever gave them. You watch someone decide they are the problem, when the thing in front of them was just badly built. Reach existed to stop small charities from feeling like that about their own gaps, and now it is shutting down. I cannot rebuild 45 years of relationships in a weekend. So I picked the one piece of what Reach did that was pure expertise rather than headcount, and rebuilt that. The thing everyone gets wrong E

This is a submission for Weekend Challenge: Generosity Edition What I Built Karibu Give (Swahili for Welcome, Give ) is a USSD micro-donation platform that works on a kabambe phone(feature phone) with no data, no app, no account , just a phone number and a mobile-money PIN. Built for the International Day of Charity. Two things stop generosity from scaling in Kenya and across Africa: You need a smartphone to give. Most donation platforms are web-forms that assume Chrome, data bundles, and card rails. 40% of Kenyan adults still use feature phones. You need trust to give again. Donations disappear into a black box. Donors never see where 50 KES actually went. Karibu Give attacks both: Dial *384*6120# → 1. Donate → Pick a cause → Enter 50 → Confirm → M-Pesa STK prompt in 2 seconds. No internet, no app store, no signup. Session state is managed server-side via sessionId (Africa's Talking USSD callback at POST /ussd ). Real M-Pesa money movement — STK Push is triggered via my dedicated M-Pesa Service https://mpesa-service-3s2d.onrender.com/stkpush , which wraps Daraja API ( POST {phone:"2547...", amount} → CheckoutRequestID:"ws_CO_..." ). SQLite = source of truth, Snowflake = audit trail — every pending → completed/failed transition via POST /payment-callback ( Body.stkCallback.CheckoutRequestID Daraja shape + AT shape) is synced to DONATIONS_ANALYTICS in Snowflake with phone_hash = SHA256(phone).slice(0,16) , never raw PII. POST /admin/sync-snowflake batch-retries unsynced rows. Only 3 causes can be active at a time — admin ( /admin behind ADMIN_USER/PASSWORD Basic Auth) creates charities ( name, emoji, target_amount, description ), toggles active, edits, deletes (blocked if donations exist). USSD and landing page render only active causes , so the choice stays focused. The limit is enforced in SQLite ( countActive()<3 ) and in the UI ( Activate disables at 3/3). Two separate AI cards — not one bolted-on feature: ✨ Google AI Impact Summary (Gemini 1.5 Flash via @google/

This is a submission for Weekend Challenge: Generosity Edition What I Built GlassPocket — a tool that argues against the "overhead ratio," the dominant heuristic people use to judge charities (what % of donations go to "programs" vs. "overhead" like staff and infrastructure). That heuristic punishes exactly the investment that makes a charity effective, and it drives what nonprofit finance people call the "starvation cycle" — orgs under pressure to look lean end up under-staffed and under-resourced. You search a US 501(c)(3), and instead of a single overhead percentage, GlassPocket pulls their IRS Form 990 history (via ProPublica's Nonprofit Explorer API) and shows: Reserve months — how long the org could run on savings alone (low reserves = fragile, not "lean") Operating margin trends across up to 13 years of filings Staff-investment share — reframed as capacity, not waste Fundraising cost per dollar raised — a narrower, more honest efficiency metric than the classic ratio A peer-percentile chart against ~70 similar organizations in the same category A Gemini-written "myth-buster" card pairing each overhead-ratio assumption with what the numbers actually show A grounded chat box — ask follow-up questions about that specific org's finances, answered only from its own filing data Demo Live app: https://glasspocket.vercel.app/ Code hassan-2050 / glasspocket Overhead-ratio myth buster for US charities — Form 990 data via ProPublica, Gemini narrative generator GlassPocket — Overhead Myth Buster Live: glasspocket.vercel.app Category: Overall Winner + Best Use of Google AI (Gemini-powered narrative generator and chat) The Hook Most charity-rating tools reinforce the harmful "overhead ratio" myth. This contrarian tool argues against that dominant heuristic by reframing efficiency around outcomes and reserves. What It Does You search a US charity by name, and it pulls their IRS Form 990 history to generate a plain-English context-aware financial explainer that debunks the o

Hi, my name is Yaniv Morozovsky, and I have worked in the radio industry for more than three decades. Most of that on SAM Broadcaster and, lately, AzuraCast. On 13 July I did something I had wanted to try for a long time: I handed one of my internet stations to automation completely, with nobody in the studio, and did not touch it. It is still on air today: https://ystream.live Some honest notes for anyone who runs a station and has wondered about the same. Segues are the whole game. The thing that makes automation sound like a jukebox is the fade timer. Every song fading at the same point, every cold ending faded when it should stop dead. What fixed it was analysing every song once (intro end, vocal entry, outro, the real ending) and crossing on those points per song. Once that was in, listeners stopped noticing there was no one there. Making an automated station sound like a DJ is mostly making the crossfades right, and that was our biggest achievement from day one. The voice matters less than where it lands. I cloned my own voice for the breaks, and honestly the voice itself is not what people comment on. What they hear is whether the talk-up ends before the vocal. When it lands, it sounds like radio. I let the AI DJ open every hour, read the weather, and in the last week also read a short news segment when the hour begins. Scheduling by rules beats scheduling by clocks, most of the time. Key, tempo, energy, era, genre, artist separation, and a few written rules like "start every hour with an international song". The hour writes itself and I stopped building clocks. What I gave up was the twenty years of Clockwheel habits, and there were days I missed them. Some of the most annoying bugs of automation software, like repeating the same song over and over, or playing the same artist twice in the same hour, are all gone. The boring parts decide whether you can actually broadcast. Royalty reports, listener stats per song, loudness that holds across a 1975 master and

Originally published on angeo.dev . Full tables, p-values and the sealed plan are there. Most claims about AI visibility are untestable by design: publish the signals, wait, attribute anything good that happens to the signals. I wanted a version I could not fudge, so I wrote the analysis plan first, hashed it, and sent the hash to the other party before I had any data. The question Do businesses AI assistants name repeatedly differ, on observable technical signals, from businesses the same assistants name once ? Every business in the corpus was named at least once, so this says nothing about how to enter an answer. It compares repeat against one-off mentions inside a named-business corpus. Four signals, all externally observable: Signal Check Crawler access Does robots.txt block any of 8 AI crawlers Content map Does the site serve /llms.txt Structured data Does a product page emit JSON-LD Product Buyability Does that node carry offers.availability Study setup The answers came from a partner (connexion.me), who ran 44 product-level home-decor buying questions across ChatGPT, Gemini and Perplexity, twice, in two arms — 264 answers per arm. Blinding was deliberate. I did not write the questions and did not see their store list until my plan was sealed; they never saw my frame, my scan results or my thresholds. Roster rows 669 no resolvable domain -186 resolved to a different company -3 marketplaces and listing surfaces -12 duplicate rows collapsed -10 Unique domains analysed 458 scanned successfully 455 Cases: 3+ mentions across both runs and present in both. Controls: exactly one mention across both runs. Head excluded first — anything in 53+ of 264 answers (Amazon, Etsy, Wayfair, Target, Home Depot). The pre-registration Sealed 10 August, SHA-256 9b4ccf12629e… : Under 15% of named businesses would be Magento No signal would separate the groups by more than 15 points Refutation condition: any signal differing by 20+ points with the named group higher Result — generic

This is a submission for Weekend Challenge: Generosity Edition What I Built I grew up teaching myself to code in Pakistan on hardware that struggled to run modern dev tools. GPU hours on Lambda Labs cost $0.50–$3/hr. For a student trying to fine-tune a model or run a training job, that's not accessible. OpenRig is a peer-to-peer compute sharing platform. Donors register their idle hardware and run a lightweight agent binary. Recipients describe what they need in plain English, get matched to the best available rig via Google Gemini AI, and receive SSH access — time-limited, isolated, and without ever touching the donor's actual machine. No money changes hands. You're donating the thing that actually matters: compute. Demo Here is the video link Full flow: Donor registers their rig → copies agent token → runs the agent binary Recipient browses available hardware → submits a request explaining why they need it Gemini scores the request 1–10 for social/educational impact Donor sees the impact score and reason → clicks Approve Agent spins up an isolated Docker container with SSH, starts a bore tunnel, reports the public connection command back to the backend Recipient gets an SSH command and password in their dashboard → connects Donor can revoke access at any time → container and tunnel torn down automatically Code Here is the code: OpenRig How I Built It The stack Backend: Go + Fiber v3, SQLite (GORM) Frontend: SvelteKit + Tailwind CSS Auth: Supabase (JWT verified on the backend via JWKS) AI matching: Google Gemini 3.6 Flash via Google Gen AI Golang sdk Tunneling: bore (open source TCP tunnel) Isolation: Docker with hardened security flags The hardest problem: giving strangers SSH access without exposing the donor's IP The naive approach — direct SSH — exposes the donor's home IP to whoever connects. That's a non-starter. The solution is a relay architecture. The donor's agent binary runs on their machine and maintains a persistent poll loop against the backend. When

## Why I built this Checking URLs one at a time during a site migration or relaunch is tedious, and the tools that do it in bulk for free — Ahrefs, SEMrush, Screaming Frog — gate that behind a paid plan. So I built Bulk URL Checker for ForgePlug : a free batch URL checker that handles up to 100 URLs per run, no account required. What it does Check status codes, full redirect chains, and response latency for up to 100 URLs at once Three ways to feed it URLs: paste directly, upload a CSV (auto-detects the URL column), or parse a sitemap Follows up to 20 redirect hops, recording the status code and Location header at each step Streams results in real time as each URL finishes, instead of making you wait for the whole batch Export as a formatted text report or properly-escaped CSV Built with SSRF protection from the ground up Since it fetches arbitrary URLs server-side, every redirect destination is validated against private IP ranges (10.x.x.x, 192.168.x.x, 169.254.169.254) before it's followed — so it can't be tricked into hitting internal infrastructure. No URLs are stored; everything lives only for the active session. Details Runs server-side (Node.js) with a concurrency pool of 10 simultaneous requests. Free tier caps at 100 URLs per run — a commercial plan is planned for unlimited batches, scheduled re-checks, and branded reporting. Try it: https://www.forgeplug.com/tools/bulk-url-checker Would love feedback, especially from anyone running site migrations or link audits.