AI 资讯

On device private AI meeting transcripts Discussion | Link

proof-of-execution for AI agents Discussion | Link

Background: I accidentally created a recursive loop with an AI agent that would have cost me $50+ in API calls before I noticed. Existing tools either cost money or only show you what already happened. So I built TokenFirefighter — a 100% free, local-only HTTP proxy. What it does: - Sits between your app and OpenAI/Anthropic on localhost:7272 - Tracks every API call cost in real time - Detects 4 types of runaway loops and blocks them - Has a terminal dashboard (no web UI needed) - Zero accounts, zero data collection, zero cost Install: npm install -g tokenfirefighter tokenfirefighter init tokenfirefighter start Then just set OPENAI_BASE_URL=http://localhost:7272/v1 in your .env. Would genuinely appreciate feedback from anyone who uses AI APIs regularly. GitHub: https://github.com/MohitBaghel24/tokenfirefighter submitted by /u/AdventurousMirror122 [link] [留言]

OpenAI has published a report detailing how China-linked influence campaigns against data centers used ChatGPT.

Not a hiring post. I have a 9-5 but also a lot of ideas I want to build. The core is just to show up and make small progress — but I find I'm missing accountability and partnership, so I thought it'd be nice to partner with someone. Mostly backend/infra stuff. If you're interested, email in my profile.

This is a submission for the June Solstice Game Jam What I Built Bletchley is a web codebreaking game set at Bletchley Park, 1939–1945. You play as an anonymous codebreaker in Hut 6. Your job: decrypt intercepted Enigma messages by adjusting mechanical rotors before time runs out. The game spans 4 levels across two cipher types — Caesar and rotor permutation. Early levels introduce the mechanics with a single rotor and generous time. By level 4, you're working with three rotors (two already solved by your colleagues), 90 seconds on the clock, and a hint you have to earn by clicking. The hint system mirrors a real codebreaking technique: cribs — words known to appear in the plaintext. Players use them as anchors, sweeping the rotor until the word surfaces in the decrypted output. That's exactly how Turing's team worked. Between each level, the screen goes quiet and a narrative fragment appears. No UI, no score — just text. Together they tell Alan Turing's story in chronological order: his arrival at Bletchley in 1939, breaking Naval Enigma in 1941, the classified silence after the war, and then 1952. The game doesn't end on victory. That's intentional. Theme connection: The game honors Turing on two registers — the mechanics recreate the known-plaintext attack his team developed, and the narrative tells his full story, including the parts history preferred to forget. June is also Pride Month. That's not incidental. Video Demo Note on the video: Due to a dental procedure, I wasn't able to record a voiceover. The narration was AI-generated. The gameplay, code, and everything else in the demo are entirely my own work. Code cristianrubioa / bletchley Web codebreaking game inspired by Alan Turing and the Enigma machine bletchley — A Turing Tribute Codebreaking game · June Solstice Game Jam 2026 · Best Ode to Alan Turing You are a codebreaker at Bletchley Park. Decrypt intercepted messages by adjusting Enigma rotors before time runs out. 4 levels · 2 cipher types · histori

Compares npm, Yarn (Berry), pnpm, Bun, and Deno as different dependency models. submitted by /u/OtherwisePush6424 [link] [留言]

Breaks down package managers as different dependency models rather than "faster npm replacements". It compares npm, Yarn, pnpm, Bun, and Deno through reproducibility, compatibility, disk usage, and migration failure modes. submitted by /u/OtherwisePush6424 [link] [留言]

I didn't set out to build a content API. I set out to stop copy-pasting. Every week, the same ritual: open a doc, stare at a blank page, write a headline, delete it, write it again. Multiply that by every client, every product page, every email drip campaign. I wasn't doing creative work — I was doing assembly-line work while pretending it was creative. PostAll started as a script I wrote to stop doing that. The API is what that script became after other developers asked if they could use it too. This guide walks you through integrating PostAll's API into your own workflow — authentication, the endpoints you'll actually use, real working code in both Python and Node.js, and the specific places things will break before they work. By the end, you'll have a functioning pipeline that generates formatted, CMS-ready content programmatically. What you'll build A script that takes a list of content briefs (keywords, tone, target length) and returns publish-ready content — with proper formatting, metadata, and error handling for the rate limits you'll hit in production. Here's the shape of what you're building: [ CSV of briefs ] → [ PostAll API ] → [ formatted content objects ] → [ your CMS / database ] The full working code for both languages is at the end of each section. I'll explain the interesting parts inline. Prerequisites A PostAll account with API access enabled (free tier works for this guide — rate limits noted below) Node.js 18+ or Python 3.10+ Basic familiarity with async/await in either language An HTTP client: axios or native fetch for Node, httpx for Python Step 1: Authentication PostAll uses API key authentication. Every request needs your key in the Authorization header. Get your key: Dashboard → Settings → API Keys → Generate New Key Store it as an environment variable. Never hardcode it. export PostAll_API_KEY = "postall_live_xxxxxxxxxxxxxxxxxxxx" Your key has two prefixes: postall_live_ for production, postall_test_ for the sandbox. The sandbox returns r

I spent yesterday building purejq , a pure-Python implementation of jq. I expected it to be the slow-but-portable option. Then I benchmarked it against the jq package on PyPI (the C bindings everyone uses to run jq from Python) and got this, on a 100k-object array, in-process: workload purejq jq PyPI (C bindings) field-access stream 9 ms 368 ms filter + count 55 ms 442 ms map + aggregate 18 ms 444 ms group_by 112 ms 704 ms transform + sort 136 ms 899 ms Pure Python, 7-40x faster than the C extension. That number looked wrong to me too, so before publishing anything I made the benchmark script verify every output against the actual jq binary first ( tools/bench.py --verify ), re-ran everything as median-of-7, and gave the bindings their best-case API. The gap is real. Here's why. The serialization tax The C bindings wrap real jq, and real jq only speaks JSON. So every call does this: your dicts -> JSON text -> C parser -> jq evaluates -> JSON text -> dicts That round trip costs about 350-450 ms for 100k small objects on my machine, before any actual filtering happens. You can see it in the numbers: even a trivial field access pays the same ~400 ms floor as a group_by. purejq skips the trip entirely. It compiles the jq program once into Python closures and walks your dicts and lists directly: import purejq prog = purejq . compile ( " group_by(.team) | map({team: .[0].team, n: length}) " ) prog . first ( data ) # operates on your objects, no serialization The lesson generalizes beyond jq: when you embed a C library that has its own data model, the marshaling boundary is often more expensive than the work. An interpreter written in your language gets to skip the boundary, and that can buy back an order of magnitude. Surprise number two: the CLI beats the jq binary on big files This one I really didn't expect. End to end on a 93 MB file (1M objects), parse + filter + output: workload purejq CLI jq 1.8.1 binary single lookup 0.51 s 1.68 s filter + count 1.08 s 1.96 s grou

TL;DR — We'll install dskripchenko/laravel-api , write one controller, and end up with a versioned API ( /api/v1/... ) and interactive OpenAPI 3.0 docs at /api/doc — generated from the docblock you'd write anyway. Then we'll ship a v2 without copy-pasting a single controller. The problem Two things rot in every growing Laravel API: Versioning. v1 ships, then v2 needs to change three endpoints but keep the other twenty. You either copy-paste a V2 folder (and now bugfixes live in two places) or bolt if ($version === 2) branches into your controllers. Docs. The OpenAPI spec drifts from the code the moment you merge. Annotation libraries ( #[OA\Get(...)] , giant YAML files) ask you to describe your API twice — once in code, once in attributes. This package's bet: your controller already describes itself . The method name, the request fields, the response shape — write them once, as a normal PHPDoc, and let the package derive routes and docs from it. Versioning becomes plain PHP inheritance. Let's build it. What we'll build A tiny tasks API: POST /api/v1/task/list — list tasks POST /api/v1/task/create — create one interactive docs at GET /api/doc (raw spec per version at /api/doc/{version} ) then a v2 that adds an endpoint without touching v1 Total: ~4 small files. Step 0 — Install composer require dskripchenko/laravel-api Publish the config (optional, but handy to see the knobs): php artisan vendor:publish --tag = laravel-api-config // config/laravel-api.php return [ 'prefix' => 'api' , // → /api/... 'uri_pattern' => '{version}/{controller}/{action}' , 'available_methods' => [ 'get' , 'post' , 'put' , 'patch' , 'delete' ], 'openapi_path' => 'public/openapi' , 'doc_middleware' => [], // lock down /api/doc here ]; Step 1 — Write a controller Nothing exotic — it extends the package's ApiController , which gives you response helpers ( success() , error() , validationError() , created() , noContent() , notFound() ). The docblock is the documentation : <?php namespace App\Api

https://dsa-life-simulator-frontend.vercel.app"I made a free tool to make DSA practice feel like an RPG — would like feedback from this community"Been grinding DSA for months and it never felt fun. So I built something. What it does: 🏟️ Real-time 1v1 Arena battles against other devs 🧪 Lab to create and publish your own challenges 🏘️ Community Hub to attempt others' challenges 📖 AI writes your weekly coding journey as a life story 🎮 XP, credits, levels, leaderboards Stack: React + Tailwind + Firebase + Node.js + Socket.IO + Groq AI Still early — would genuinely love feedback from people who've felt the pain of traditional DSA prep.

AI coding tools are changing how software gets built. Claude Code, Cursor, GitHub Copilot, Windsurf and other tools can generate code incredibly fast. For small tasks, they are already useful: write a component, explain a function, scaffold an endpoint, create a test, refactor a file. But after using AI in real projects, one thing becomes obvious: The problem is no longer code generation. The problem is engineering control. Most AI coding workflows still look like this: text idea -> prompt -> code -> fix -> prompt again -> more code -> lost context -> start over It feels fast at the beginning. Then the project grows. Requirements change. Architecture decisions disappear inside chat history. The AI forgets previous context. You start acting as product manager, architect, reviewer, QA, DevOps, and prompt engineer at the same time. That is not software engineering. That is vibe coding. ## Vibe coding works until it doesn't Direct AI coding is great when the task is isolated. Ask for a React component. Ask for a SQL query. Ask for a utility function. Ask for a unit test. No problem. But real software is not a collection of isolated snippets. Real software has: - business rules - architectural constraints - existing patterns - security concerns - database impact - deployment requirements - edge cases - regression risk - long-term maintenance When AI jumps directly from prompt to code, it often skips the thinking that should happen before implementation. The result may compile. But does it fit the architecture? Does it respect the domain? Does it create hidden technical debt? Does it solve the right problem? That is the gap we are trying to close with N45.AI. ## What is N45.AI? N45.AI is a framework that turns AI coding tools into a structured engineering workflow. It works with the tools developers already use, including Claude Code, Cursor, GitHub Copilot, and Windsurf. The idea is simple: Instead of treating AI as one generic assistant, N45.AI organizes the work like a

Most developers never have to design a network protocol from scratch. You use HTTP, gRPC, WebSockets, or something else that already exists and has been debugged by thousands of people over many years. That is the right call for most situations. I did not take that path when building Vaylix, a key-value database engine. I designed a custom binary protocol called VTP2, and the process taught me things about networking that I would not have picked up any other way. This is not an argument that you should also build a custom protocol. For most things, you should not. This is an honest account of what I ran into. Why not HTTP The first question anyone reasonably asks is: why not just use HTTP? HTTP is everywhere. The tooling is excellent. Every language has a client. Debugging with curl is trivial. If I had used HTTP, I would have had working client libraries in a dozen languages before writing a single line of server code. The problem is that HTTP is stateless by design. Every request is independent. Every request carries headers. Every response carries headers. The model assumes that each round trip is a fresh conversation with no memory of what came before. A database session is the opposite of that. A client connects, authenticates, and then issues many commands over the same connection. The authentication should happen once. The session should carry state. Pipelining requests without waiting for each response to return should be natural, not something you fight the protocol to achieve. HTTP/2 closes some of this gap. But using HTTP/2 correctly for a stateful session model involves working against the grain of what HTTP was designed for. I would have been spending a lot of time on infrastructure that exists to make HTTP behave less like HTTP. The other issue is overhead. HTTP headers are verbose. For small key-value operations, the headers can easily exceed the payload. That felt wrong for something designed to be a tight operational data store. So I went with TCP d

A useful thing happened in agent infrastructure this June: several teams shipped "escrow layers for AI agents" - production MCP tools that let an agent run a full commit -> hold -> complete lifecycle without a human anywhere in the loop. An agent can now park value with a contract or service, wait for the other side to deliver, and release on completion. That is genuinely new, and it solves a real problem. It is also worth being precise about, because "escrow" and "settlement" get used as if they were one thing. They are not. There are two structurally different ways to make a trade your agent does at 3am trustworthy, and the difference is exactly who holds the money while the trade is in flight . Model one: held custody In the held-custody model, a third party - a smart contract escrow, a custody service, a payment facilitator - takes the funds, holds them, and releases them when a condition is met. The condition can be anything you can express: a delivery confirmation, an evaluator's attestation, a timeout, a multi-sig approval. This is the right tool for a large class of agent commerce. If your agent is paying a merchant, buying a dataset, or hiring another agent to do a unit of work, the hard question is subjective : did the thing actually get delivered, and was it any good? A hash function cannot see that. A custodian can - it gives the trade a place to pause while something or someone checks. The new agent-escrow tooling is built around exactly this shape: a job, a held balance, a release on completion. For agent-to-merchant payments riding on rails like x402, held custody is the honest primitive. The cost is equally concrete. A held balance is a honeypot. Someone controls the funds between commit and complete, which means someone can freeze them, lose them, misconfigure the release condition, or get drained. You have added a trust assumption and a liveness dependency - the custodian has to be online, solvent, and honest at release time. That is often an accep

It is a privacy-first, local-first photo organizer powered by deep learning face recognition. It detects, embeds, and groups faces to organize your photos automatically—all 100% offline. 🔥 Highlight Features: ✅ 100% Local: No cloud APIs, no telemetry, no leaks. ✅ Deep Learning: Driven by OpenCV DNN (YuNet + SFace ONNX models). ✅ Smart Automation: Copies matches, partial matches, and individual profiles into organized folders, complete with ZIP archives and JSON reports. ✅ Standalone EXE: Run it on Windows instantly with zero dependencies. ✅ Dynamic UI: Fully responsive Tailwind dashboard with Dark/Light modes. Check out the repository, download the EXE, or contribute: 👉 https://github.com/Shaan-alpha/face-sort-studio Let me know what you think! ⭐ machinelearning #computervision #python #localfirst #privacy #developers #opensource #ai Internet access on first launch only (to fetch the AI models ~40-50mb)

I built a pay-per-call MCP server too — here's the piece that almost broke everything When kirothebot dropped the breakdown of what the agent payment stack actually looks like, it landed because it's a problem almost no one has documented honestly. Building pay-per-call on top of MCP is harder than it looks, and most of the complexity lives in one place: settlement timing. The problem with settling after the call The obvious approach is: run the tool, check if payment cleared, return the result. That's backwards. Here's why. If you settle after the call, you've already spent the compute. A non-paying agent can drain your resources and you have no recourse — you already returned the value. You can rate-limit after the fact, but by then you've done the work for free. The correct sequence is: price check → authorization → tool execution → result delivery. The authorization step is what makes this different from a standard webhook with a Stripe call attached. Authorization in this context means the calling agent or its orchestrator has confirmed: (a) it has credit for this call type, (b) the credit is being reserved before execution, and (c) the tool will receive settlement confirmation as part of the return flow. That's not how HTTP requests work out of the box. You need a layer that lives between the MCP protocol and your tool handler. The credit-reservation problem at agent scale Here's the complication that doesn't show up until you have multiple concurrent agents: credit reservation under contention. If ten agents each have 5 credits remaining and they all hit your MCP server simultaneously, naive implementations let all ten through — because at the moment each request lands, each agent appears to have credit. You end up with ten executions and five payments. This is a race condition in the authorization layer, not in your tool logic. The fix is optimistic locking on credit state, which is standard database concurrency control but needs to be built into the payment

Audit thousands of passwords against data breaches — completely in your browser with zero-knowledge privacy. Published: June 9, 2026 TL;DR Most bulk password checkers require you to upload your entire vault. Utilora’s Bulk Password Breach Checker uses HIBP’s k-anonymity + local hashing so your passwords never leave your device . The Hidden Risk Most People Ignore Using a password manager is excellent, but it’s not enough. Many users unknowingly reuse or slightly modify passwords that have already been leaked in massive breaches (LinkedIn, Adobe, Yahoo, etc.). Manually checking hundreds or thousands of passwords is impractical — which is why people turn to bulk checkers. The problem? Most bulk checkers ask you to upload your password list . That creates a massive new privacy risk. How Utilora’s Zero-Knowledge Breach Checker Works We built this tool using a privacy-preserving technique called k-anonymity (popularized by Troy Hunt of Have I Been Pwned). Step-by-Step Technical Process: Local Hashing — Your browser uses the WebCrypto API to create a SHA-1 hash of each password locally. Prefix Only — Only the first 5 characters of the hash are sent to HIBP’s Range API. Server Response — HIBP returns hundreds of matching hashes that start with the same prefix. Local Comparison — Your browser checks if your full hash exists in the returned list. Result: HIBP knows someone checked a password starting with ABC12 , but has no idea which specific password it was. Why You Should Audit Your Entire Vault Regularly Discover weak or compromised passwords you forgot about Clean up old reused passwords Respond quickly after major breaches Maintain good password hygiene across all accounts Real-World Scenarios You exported your Bitwarden / 1Password / KeePass vault You want to check 500+ passwords before a security audit You just heard about a new major breach and want to verify impact You’re helping a family member or client secure their accounts How to Use the Tool Go to the Bulk Pas

PostgreSQL Error 2200G: Most Specific Type Mismatch PostgreSQL error code 2200G ( most_specific_type_mismatch ) is a SQL-standard data exception that occurs when a value's type does not match the most specific (most derived) type expected in a context involving type hierarchies, XML schema types, or user-defined structured types. It most commonly appears when working with composite types, domain hierarchies, or XML processing functions where type inheritance or derivation is in play. While relatively rare in everyday CRUD operations, it can be a significant pain point in enterprise applications with complex type systems. Top 3 Causes and Fixes 1. Composite or Domain Type Hierarchy Mismatch When a function expects a specific domain or composite type but receives a parent/base type, PostgreSQL raises 2200G. Always cast explicitly to the most specific required type. -- Define types CREATE TYPE base_info AS ( name TEXT , value INTEGER ); CREATE DOMAIN specific_info AS base_info ; -- Function expecting the specific domain type CREATE OR REPLACE FUNCTION handle_info ( data specific_info ) RETURNS TEXT AS $$ BEGIN RETURN ( data ). name || ': ' || ( data ). value ; END ; $$ LANGUAGE plpgsql ; -- WRONG: passing base type causes mismatch -- SELECT handle_info(ROW('test', 42)::base_info); -- CORRECT: explicit cast to the most specific type SELECT handle_info ( ROW ( 'test' , 42 ):: specific_info ); 2. XML Type Processing Mismatch Using XML functions like XMLTABLE or XMLCAST without explicitly matching the expected schema type can trigger this error. Always declare column types explicitly. -- Correct: explicitly typed columns in XMLTABLE SELECT * FROM XMLTABLE ( '//product' PASSING XMLPARSE ( DOCUMENT ' <products> <product> <id>1</id> <price>29.99</price> </product> </products> ' ) COLUMNS product_id INTEGER PATH 'id' , price NUMERIC PATH 'price' ); -- Explicit XMLCAST to resolve type ambiguity SELECT XMLCAST ( XMLQUERY ( '//price/text()' PASSING XMLPARSE ( DOCUMENT '<data><pri