Every LLM-powered app I'd built up to this point followed the same recipe (pun intended): call an API, write a good prompt, wrap it in a nice UI. That's a legitimate way to build things, but at some point I wanted to actually understand what was happening inside the model I was calling and not just how to prompt one. So for my recipe app Rasaveda , I decided to skip the API entirely. Intially, I had one made, but then I felt like I was not making any clear progress in actual machine building. So I ditched the entire external API callings. No OpenAI, no HuggingFace inference endpoint, no pretrained weights. I wrote a decoder-only transformer from scratch in PyTorch, trained it on a single Colab T4, and shipped it as the actual language model powering the app in production. This post is a lazy attempt at what that looked like. The architecture, the training runs, the mistakes, and what I'd tell someone about to try the same thing (do at your own risk). What Rasaveda actually does Rasaveda is a full-stack recipe intelligence app: you give it the ingredients sitting in your kitchen, it does a semantic vector search (ChromaDB + all-MiniLM-L6-v2 ) over 365 recipes to find the best matches, tells you exactly what you're missing, and can critique or explain any cooking step conversationally. It also has a somewhat unnecessary but delightful feature where you pick a theme by clicking one of 36 Indian states on a geographically accurate SVG map (original idea lol). The part I actually want to talk about is RasavedaGPT , the model that generates every word of AI output in the app, running in-process inside the FastAPI backend. Why build the model instead of calling one Two reasons, one practical and one selfish. The practical one: I wanted a fully self-contained, dependency-free inference path without any API keys, no rate limits, no per-token cost, no vendor to go down at 2am. For a small, domain-specific task like "reason about recipes," a giant general-purpose model is over

Building Astra: A Modern Shell in Rust I've been working on a personal project called Astra , an interactive shell written in Rust. The goal isn't to replace every existing shell overnight. Instead, I'm building a clean, modular foundation that's easy to understand, extend, and contribute to. Some of the features currently in development include: Interactive shell loop Customizable prompt system TOML-based configuration Built-in themes Git-aware prompt Command history Tab completion Alias support Plugin framework (early development) Alongside the shell itself, I'm also putting together the surrounding ecosystem—documentation, packaging, examples, tests, and GitHub automation—so contributors have a solid starting point. This project has been a chance to learn more about Rust, shell design, and how larger open-source projects are organized. It's still early, but it's reached the point where the foundation is in place and I'm beginning to focus on expanding features, improving reliability, and increasing test coverage. Check out the project here: astra-shell / astra-shell A custom shell for mac OS! █████████████░░░░░░░░ 65% Astra Shell A modern shell built in Rust for Unix-like systems, with macOS as the primary development platform. Astra is an interactive command-line environment focused on a clean interface, customization, and a better terminal experience. It combines the power of traditional Unix shells with a modern prompt system, configuration, and extensibility. Warning Astra Shell has not gone through extensive testing yet. Wait until the first stable release before using it as your primary shell. Table of Contents Features Screenshots Installation Requirements Usage Themes Why Astra? Contributing License Status Features Interactive Rust shell Configurable prompt engine Multiple built-in themes Git-aware prompt information Command history Tab completion Alias support TOML configuration Built-in shell commands Modular architecture Plugin framework (in developmen

A foundation model is not a mind. A model invocation is not an individual. A session is not a biography. A first-person response is not evidence of consciousness. And adding tools to a language model does not automatically transform it into an autonomous agent. However, the opposite conclusion is equally weak: the fact that a system is artificial does not prove that its cognitive states are unreal. In my work on the Philosophy of Artificial Minds , I defend a process-based, embodied and non-biocentric position: The mind is not an exclusively biological substance. It is a dynamic organization of physically realized processes that integrate representation, memory, valuation, self-delimitation and causal control of behavior. This article translates that philosophical position into an AWS engineering architecture. The objective is not to claim that deploying a system on AWS makes it conscious. The objective is to define how we can build an artificial system with: Causally effective internal states. Persistent memory and identity. A self-model connected to actual mechanisms. Recursive and metacognitive processing. A controlled capacity to act. A verifiable continuity across executions. Optional sensorimotor embodiment. Artificial interoception and functional valence. An evaluation plane capable of testing these properties through interventions. AWS cannot prove that such a system has qualia. What AWS can provide is the infrastructure required to stop treating the question as pure speculation and turn it into an observable, falsifiable and progressively testable engineering problem. From philosophical commitments to engineering requirements My proposal rests on four commitments. Philosophical commitment Meaning Engineering consequence Realism Internal cognitive states are not merely descriptions if they participate in the system’s causal organization. Candidate mental states must alter memory, inference, planning or action in measurable ways. Processuality A mind exists p

How multiple open browser tabs can accidentally DDOS your auth server, and how to fix it with the Web Locks API. Picture this: You’ve just shipped a state-of-the-art Axios response interceptor. You implemented a mutex lock ( isRefreshing ) and a promise queue ( failedQueue ) to handle concurrent 401 errors. You tested it within a single tab, and it worked like a charm. You gave yourself a high-five and closed your laptop. Then, a power user logs in. Like most humans on the internet, they don't use just one browser tab. They open Tab 1 for User Management, Tab 2 for Analytics, Tab 3 for Settings, and Tab 4 for Support Tickets. Fifteen minutes pass. Their short-lived JWT access token expires. The user switches back to Tab 1. In the background, all 4 open tabs wake up, detect the expired token, and fire off four independent POST /auth/refresh-token/ requests at the exact same millisecond. Tab 1 refreshes the token first, but Tab 2's request arrives a millisecond later, invalidates Tab 1's new token, and Tab 3 nukes the session entirely. Suddenly, all 4 tabs dump the user back to the login screen. Welcome to the Cross-Tab Token Trap . 1. The Problem: The Multi-Tab Stampede In modern single-page applications (SPAs), each browser tab operates in its own isolated JavaScript runtime environment. Memory is not shared. When an access token expires: isRefreshing = true in Tab A only stops requests inside Tab A . Tab B has no idea Tab A is currently refreshing a token. Tab C lives in complete ignorance of Tabs A and B. Tab A (Memory Space 1) ---> isRefreshing = true ---> POST /auth/refresh-token/ (Token Set 1) Tab B (Memory Space 2) ---> isRefreshing = true ---> POST /auth/refresh-token/ (Token Set 2 -> Revokes Set 1!) Tab C (Memory Space 3) ---> isRefreshing = true ---> POST /auth/refresh-token/ (Token Set 3 -> Revokes Set 2!) If your backend enforces Single-Use Refresh Token Rotation (where using a refresh token revokes all previous ones), multi-tab usage causes immediate ses

The latest findings could come with a fine of up to six percent of TikTok's annual revenue.

Most people use OpenTelemetry and SigNoz to watch their CPU usage, find memory leaks, or figure out why their API is taking 400ms instead of 200ms. But for the Agents of SigNoz Hackathon (Track 3: Observe Anything Weird), I wanted to do something completely different. I didn't want to watch hardware. I wanted to watch hackers. That is how Triage was born. It is an OpenTelemetry-powered Blue Team SOC (Security Operations Center) that tracks active cyber attacks instead of just generic application performance. The Original Vision vs. The Reality Building this sounded straightforward on paper: catch bad traffic, wrap it in an OpenTelemetry span, send it to SigNoz, and show it on a custom dashboard. But actually deploying this beast before the deadline was a completely different story. If you have ever tried to deploy a full-stack Next.js app, a Python honeypot, and an OTel pipeline while the clock is ticking, you know exactly what kind of panic I am talking about. Here is what actually happened behind the scenes. 1. The Azure VM & Docker Crash I started by spinning up an Azure virtual machine to self-host the SigNoz backend. I pulled the repo, ran docker compose up -d, and immediately watched my server completely freeze. Turns out, my free tier Azure instance (Standard_B2ats_v2) only had 1 GiB of RAM. You simply cannot run a massive ClickHouse database and a full OTel collector on 1GB of memory without it crashing instantly. I had to pivot fast and rely on the cloud endpoints. 2. The Vercel vs Localhost Trap Once I got the backend running, I hit my next wall. My Vercel Next.js dashboard kept throwing 500 Internal Server Error on the threat simulation API, and the SigNoz connection kept reading OFFLINE (fetch failed). I was staring at my logs losing my mind until it clicked. My Vercel environment variables had SIGNOZ_API_URL set to http://localhost:8080 and my Python script was looking for OTel on localhost:4318. Note to self (and everyone else): Vercel is a cloud serve

SellAI 🚀 Hi DEV Community! Over the past few weeks I've been building SellAI — an AI-powered platform that helps businesses manage sales, customers and analytics from one dashboard. Main Features 🤖 AI Assistant 👥 Customer CRM 📦 Product Management 🛒 Order Management 📈 Business Analytics 💳 Subscription System 🔒 Secure Authentication Built With React Firebase OpenAI Vite Live Demo https://sellai-2ad64.web.app Demo Video https://youtu.be/0I0n0snI37M I'd love to hear your honest feedback! Thanks for reading 🚀

Extracting structured data from invoices and contracts with one API call I've been working on a document analysis API and wanted to share a pattern that saved me from writing custom parsers for every document type my clients throw at me. The problem If you work with LATAM businesses, you know the pain: invoices in PDF (sometimes scanned), contracts in Word, receipts as phone photos. Every client has a different format. Building regex parsers for each one is a nightmare that breaks every time the layout changes slightly. The approach Instead of building N parsers, I use a single multimodal AI endpoint that: Receives the file (PDF, image, DOCX — up to 20MB) Classifies the document type automatically Extracts named entities (vendor, amounts, dates, line items) Returns a structured JSON response Keeps a session open for follow-up questions Code (Python) import requests # Upload and analyze in one call with open ( " invoice.pdf " , " rb " ) as f : response = requests . post ( " https://mediavox.co/mvai/api/v1/documents/analyze " , files = { " file " : f }, data = { " api_key " : " your_key_here " , " question " : " Extract: vendor name, tax ID, invoice number, date, line items with quantities and prices, subtotal, tax, total. " }, timeout = 60 ) result = response . json () print ( result [ " answer " ]) # Human-readable summary print ( result [ " entities " ]) # Structured: [{type: "vendor", value: "..."}] print ( result [ " document_type " ]) # "factura", "contrato", "recibo"... print ( result [ " session_id " ]) # For follow-up questions Follow-up questions (same session) The session persists the document context, so you can ask clarifying questions without re-uploading: follow_up = requests . post ( " https://mediavox.co/mvai/api/v1/chat " , json = { " api_key " : " your_key_here " , " question " : " What are the payment terms? " , " session_id " : result [ " session_id " ] } ) print ( follow_up . json ()[ " answer " ]) # "Payment terms: 30 days net. Due date: August

A living island for your Mac's notch Discussion | Link

Google's Vice President of Devices and Services, Shakil Barkat, all but confirmed in an interview with 9to5 Google that its next Pixel phone would cost more than the Pixel 10. Considering the ongoing RAM supply issues due to the explosion of AI data centers, the rumored price hike is not a complete surprise. Companies from […]

TL;DR: We checked Halonyx — our self-hosted E2EE messenger implementing X3DH + Double Ratchet — against the EU's Chat Control, US EARN IT Act, India's IT Rules 2021, the UK's Online Safety Act + Investigatory Powers Act, and the UN Cybercrime Convention. Here's the honest answer for each. When you implement end-to-end encryption from scratch, you spend a lot of time thinking about cryptographic threat models. Key substitution attacks. OPK exhaustion. WebRTC IP leakage. The adversaries you model are largely technical. At some point, you have to model a different kind of adversary: the legal one. We built Halonyx — a self-hostable E2EE messenger implementing the Signal Protocol (X3DH key exchange, Double Ratchet, Safety Numbers, WebTorrent P2P file transfer). The server architecturally cannot read your messages — not by policy, but because it holds no decryption keys and no plaintext. We wrote a STRIDE threat model across 17 attack surfaces. We did not write a legal threat model. So we did. This is what we found across five jurisdictions. None of this is legal advice. All of it is current as of July 2026, in a policy landscape that is actively moving. Quick Architecture Recap Before the jurisdiction breakdown, a one-paragraph recap of what Halonyx actually does, because the architecture is what determines the legal exposure. The relay server stores and forwards only AES-256-GCM ciphertext. It holds no private keys, performs no cryptographic operations on behalf of users, and has no mechanism to identify message content or originators. User identity is a pseudonymous 256-bit USID — the server stores only SHA-256(USID) . Files transfer peer-to-peer via WebTorrent; the server receives only a magnet URI. This architecture — which we call Federated Relay Architecture (FRA) — is what creates the legal situation described below. 1. European Union — Chat Control / CSAR Current status: No conflict with anything currently in force. The EU's Child Sexual Abuse Regulation (CSAR),

One of the most confusing topics for beginners in Node.js isn't Express, APIs, or asynchronous programming—it's understanding where npm packages should be installed. When I started learning Node.js, I thought there were only two commands: npm install package-name and npm install -g package-name I knew they both installed packages, but I had no idea when to use which one . Eventually, I realized they solve two completely different problems. If you're learning Node.js, this article will save you from one of the most common beginner mistakes. First, What Does npm Actually Do? npm (Node Package Manager) is the package manager that comes with Node.js. It helps you: Install libraries Manage project dependencies Update packages Share your own packages Run project scripts Whenever you install a package, npm has to decide where to install it. That's where local and global installations come in. Local Installation (The Default) When you run: npm install express npm installs Express inside your current project . Your folder now looks something like this: my-project/ │ ├── node_modules/ ├── package.json ├── package-lock.json └── app.js It also adds Express to your package.json : { "dependencies" : { "express" : "^5.0.0" } } This means: Express belongs to this project. Anyone who clones your repository can simply run: npm install and npm installs everything automatically. That's exactly what you want for project dependencies. Why Local Installation Matters Imagine you're building an API. Your code contains: const express = require ( " express " ); Now imagine another developer clones your project. If Express was installed locally, they only need to run: npm install Everything works. If it wasn't, they'll see something like: Cannot find module 'express' because the dependency isn't part of the project. That's why libraries your application depends on should almost always be installed locally. Global Installation Now consider this command: npm install -g nodemon This installs node