second-brain
Turn your archive into a pay-per-query AI agent.
About
The problem it solves For creators, researchers, and experts, the current monetization landscape for written knowledge is deeply flawed. If you have a massive archive of valuable text (newsletters, research notes, documentation, or books), your options are currently limited to blunt, all-or-nothing paywalls (like Substack) or relying on ad revenue. Furthermore, if you want to let users "chat" with your data, you have to upload it to a centralized platform like OpenAI, which captures all the value and offers you nothing in return. Second Brain solves this by turning any static text archive into a sovereign, pay-per-query AI agent that you can embed anywhere. Instead of locking knowledge behind a $10/month subscription, Second Brain uses the x402 protocol (HTTP 402 Payment Required) combined with the ultra-low fees of MegaETH to create true micro-monetization. What people can use it for: * Independent Creators: Upload your entire back-catalog of essays. Drop the iframe onto your personal site, allowing readers to ask your "AI clone" specific questions for a few cents per answer. * Open Source & Dev Tools: Monetize premium technical support. Train a brain on your project's advanced documentation and charge micro-transactions for instant, highly-accurate technical debugging. * Researchers & Analysts: Sell access to proprietary market research. Users don't have to buy a $500 report; they can pay $0.50 to ask exactly what they need to know. How it makes things better: * Frictionless UX: It utilizes an embeddable iframe. The reader connects their wallet directly in the chat widget, signs the escrow transaction, and gets their answer instantly. * Creator-Owned: The creator holds the keys. Revenue accumulates in an on-chain escrow contract, ready to be pulled directly to their wallet at any time. * Context-Strict (RAG): Because it uses Venice AI and a localized vector store, the agent only answers using the provided archive, drastically reducing hallucinations and preserving the creator's true voice.
How it's made
Challenges we ran into Building a decentralized, pay-per-query agent required bridging the gap between synchronous Web2 APIs and asynchronous Web3 infrastructure. Here are the main hurdles and how I overcame them: 1. The RPC Race Condition (Transaction Propagation Delay) The biggest hurdle was a classic blockchain race condition during the payment handshake. When a user paid for a query in the frontend iframe, their injected wallet (e.g., MetaMask) instantly confirmed the transaction and told the React app to hit the backend /query endpoint with the new transaction hash. However, the Express backend validates payments using a public MegaETH RPC node. Because the node takes a few seconds to index the newest blocks, it was returning null for the transaction, causing the API to reject valid payments with a "Transaction not found" error. * How I fixed it: I implemented a localized polling loop inside the backend's x402 middleware. Now, when the backend receives a payment hash, instead of failing immediately, it gracefully retries fetching the receipt up to 5 times (spaced 1 second apart). This gives the RPC node the buffer it needs to sync the network state, resulting in a flawless UX for the reader. 2. Serverless Environments vs. Stateful AI Vectors Initially, I wanted to deploy the entire stack to Vercel. However, the architecture relies on an in-memory database to store API keys and uses Xenova to generate localized vector embeddings on the fly. Serverless functions (like Vercel's) spin down constantly, which meant the vector store and API keys were being wiped from memory every few minutes, causing "Invalid API Key" errors. * How I fixed it: I split the architecture into a hybrid deployment. I deployed the React frontend as a Static Site to Vercel for fast global CDN delivery, but migrated the Express/Ethers backend to a dedicated Google Compute Engine (GCE) Virtual Machine running persistently via systemd. To bypass browser CORS and Mixed Content (HTTPS -> HTTP) blockers, I configured vercel.json to act as a reverse proxy, silently routing all frontend /api/* requests to the VM.