Ex Situ
Hi, I designed and developed a spatial index that maps museum artefacts as connecting arcs/hyperlinks from their origin site to institutional location/sources. The Index specifically looks at western/euro-american institutions and maps their collection categorised by them under Islamic art, Asian/African art, ethnological collections, Middle East, South America etc. Started as my MA thesis in 2022, kept building since, mostly solo with a little funding. Fully open source, self-hosted, AGPL-3.0, Next.js + Deck.gl on the frontend, Strapi backend, Python ETL pulling from museum open-access APIs. Currently indexing over 100k artifacts from all over the world, across 8 collections (Met, V&A, SMB Berlin). Recently added an md export so researchers can download provenance data for a filtered set of artifacts. The infrastructure is conceptualized as an indexer, not a hoster. Even images are kept as URLs pointing to the source institutions. It's connective tissue between archives that were never designed to speak to each other, with an origin-first search UI concept. The data model is on purpose flat, to avoid encoding problematic taxonomies, and routes researchers directly to the source giving responsibility to the source institutions rather than duplicating institutional data. It indexes the relationship between origin sites and destination collections. Coming from a design background, taking this project from prototype to production app has been incredibly rewarding, but honestly it’s getting a little bit overwhelming to scale alone. I would love community’s feedback on performance scaling, any code contributions, data pipelines for missing museum apis or general feedback. Repo: https://github.com/hburakyel/ex-situ Live: https://exsitu.app
Agent in 9 Lines Python
I asked myself: what would a minimal implementation of an agent look like? Something that works out of the box, is a real agent with tool calling, but without 1000s of lines of code, without dozens or hundreds of npm or pypi dependencies. Something with just a few 'essential' features (not a whole kitchen sink that most agent harnesses come with nowadays). An implementation close to pseudocode that you can look at in one page, everything there at a glance, no scrolling. This is the agent.py I ended up with so far: import json,sys;from subprocess import getoutput as sh;from urllib.request import Request as R,urlopen url=sys.argv[1];h=[];b=dict(model="gpt-5.6",input=h,tools=[dict(type="custom",name="sh")]) while p:=input("> "): h+=[dict(role="user",content=p)];H={"Content-Type":"application/json"} while True: o=(r:=json.load(urlopen(R(url,json.dumps(b).encode(),H))))["output"] h+=o;c=[i for i in o if i["type"]=="custom_tool_call"];z=r["usage"]["total_tokens"]/10500 if not c:print(o[-1]["content"][0]["text"],f'\n[{z:06.3f}%]');break h+=[dict(type="custom_tool_call_output",call_id=i["call_id"],output=sh(i["input"])) for i in c] It is a bit code golfed but I think it is fairly readable - imports are all from stdlib (0 external dependencies!) - assumes there is an inference api endpoint running somewhere - assumes the inference api endpoint is openai-like - model hardcoded to "gpt 5.6" (=> Sol), can easily be changed to e.g. open weight (kimi k3, glm 5.2 etc) - api endpoint url is passed as arg to the python script - configures only 1 custom tool: 'sh' - 'sh' is sufficient for interacting with the environment in an open ended way - new api output gets added to history ("h") - if api output contains tool calls the tool calls get executed - agent gives control back to user when the last model response is without tool calls - agent message to user shows % of context window used Noteworthy: no dependencies other than python stdlib (!) - less startup time - less dependency churn - less supply chain attack vector surface - less code to verify and understand no mcp, no plugins, no security theater - if you want to add something specific: add it explicitly - adapt the environment to give the agent access or restrict access to tools, resources, network etc (the env is the security boundary, not the harness) no system prompt - every token in context window is precious - current strong models do fine without steering via system prompt (or are even harmed by long overly specific system prompts designed for models from months ago) - system prompt or agents.md context can easily be added if needed (agent can also discover it or get prompted to read from environment as is) how to run/deploy the agent - design the environment you want to give the agent (container, docker, sandbox of your choice) - start an inference api endpoint that is openai-like (support the request/response shape used in agent.py above) - inference api endpoint can be as simple as a proxy to openai api that adds credentials/api key - adapt as you want/need it, change the model, remove/alter context window behaviour, add tools, etc etc Looking for any feedback you have to make it more clear or even simpler!
Maptoolkit.org
We built Maptoolkit.org - a free, production-grade vector maps service built on OpenStreetMap and MapLibre. Map rendering and tile hosting have historically been either expensive (Google, Mapbox) or complex to maintain yourself. (Plus: Their maps are car-focused.) Our maps feature max data zoom 15, global hill-shading, 3D terrain, contour lines, water depths, and specialized styles (like Hiking, Cycling, Winter). No sign up or API keys required. You can use it like this: ``` const map = new maplibregl.Map({ container: 'map', style: 'https://styles.maptoolkit.org/summer.json', // <- that's all you need to add center: [11.40, 47.27], zoom: 12 }); ``` And you can create custom styles with our MapMaker. Maybe a Elden Ring map style for your website? We hope you like it.
Langy, an automated AI engineer (we gave it a robot body) [video]
Founder here. Langy is an AI engineer that lives inside our platform, LangWatch. It reads your production traces, writes Scenario tests and evaluations for the problems it finds, opens a pull request on your repo, and proves the fix by running those simulations in CI. A human still merges. Reachy robot from Hugging Face arrived on the same week we were planing on launching it, so we wanted to use for the launch. So we it wired to our Langy which actually lives on the platform, and asked it to test our own customer-support voice agent. On the video you can see it writing the agent tests reading traces and everything. LangWatch is an open source platform (github.com/langwatch/langwatch) and Scenario, the simulation-testing library it drives, is open source too if you want to run that part yourself: https://github.com/langwatch/scenario. A full write-up on how Langy works under the hood is coming later this week. Happy to get into how it drives the robot, what is real vs staged, latency, or how the whole harness around it actually works.
Unlayer
Hi HN, We’re Adeel and Umair, co-founders of Unlayer (https://unlayer.com/). We let you add content creation to your applications without having to build an entire editor, renderer, template, and export stack yourself. Unlayer lets you create emails, web pages, and documents inside your app, in three different ways: in code, visually, or with AI. Here’s a demo: https://www.youtube.com/watch?v=0HsDtNkdMpM. We started with an embeddable email editor because a lot of products eventually need one: CRMs, marketing tools, customer engagement platforms, marketplaces, internal tools, and vertical SaaS apps all run into this at some point. At first, it sounds like a small feature: "just" add a drag and drop editor. In practice, it turns into a big pain. You end up dealing with email rendering, Outlook quirks, responsive layouts, templates, merge tags, image uploads, exports, permissions, localization, versioning, and a long tail of edge cases that have nothing to do with your core product Over time, we saw the same problem beyond email. Apps also need landing pages, invoices, proposals, reports, contracts, and PDFs. Some of this content is best created visually by end users. Some of it is better generated in code by developers. Increasingly, some of it is also generated by AI agents. Many teams eventually need all three workflows. That is the direction we have been working toward with Unlayer. There are three parts we are showing today: (1) Unlayer Elements. This is our open-source React component library for creating emails, pages, and documents in code (repo: https://github.com/unlayer/elements, more at https://unlayer.com/elements). Instead of hand-writing raw HTML templates, developers can compose content using React components, reuse sections like headers, footers, CTAs, invoice rows, and branded blocks, keep templates in Git, and render them into production output. One newer use case we are seeing is AI-assisted content creation. If an AI agent is asked to create an email, invoice, report, or landing page, the output is usually raw HTML or markdown that becomes hard to maintain. With Elements, the agent can generate structured React components instead. A developer can review the result, refactor it, keep it in Git, and still pass the design into a visual builder later if someone needs to edit it. (2) Visual Builder. This is the drag and drop editor (repo: https://github.com/unlayer/react-email-editor, more at https://unlayer.com/email-builder) that can be embedded inside an app so non-technical users can create or edit content. In the demo, we show the email builder and the AI assistant inside the builder. The goal is not to replace the developer workflow, but to connect it with a visual workflow when marketers, admins, customers, or internal teams need to make changes themselves. (3) Document Builder. This is for structured documents such as proposals, reports, invoices, contracts, and PDFs. We have seen a lot of teams build separate systems for email templates, web pages, and document generation, even though the underlying primitives are similar: layout, content blocks, variables, assets, preview, export, and permissions. More: https://unlayer.com/document-builder The technical challenge is making these workflows share a common foundation. Developers should be able to build templates in code when that makes sense. End users should be able to edit visually when that makes sense. AI agents should be able to generate structured content instead of unmaintainable blobs. The final output should still be usable by the host application. We make money by selling hosted builder, template, export, and platform features to companies embedding this into their products. Elements is open source. The commercial product is the broader hosted platform around builders, collaboration, storage, exports, and production use cases. We were part of W22, so this is a late Launch HN. At the time, Unlayer was an embeddable email editor, and we did not think we had the right broader story for HN yet. Since then, the product has expanded into a more general content creation layer for products, including emails, pages, documents, APIs, open-source developer projects, and AI-assisted workflows. That felt like a better moment to bring it to HN and ask for feedback. We'd really appreciate thoughts from HN. This is one of those areas where a lot of people have strong opinions because they’ve been burned by editors, email HTML, document editing, or “simple” content workflows before. We'd love to hear what resonates, what sounds wrong, and what you think we should be thinking harder about!
I built a zero-latency developer tool suite in pure Vanilla JavaScript
Show HN: I built a zero-latency developer tool suite in pure Vanilla JavaScript
Production duplex speech model for revenue calls
Hi, HN, we’re building Mia & Leo: AI personalities backed by purpose-built duplex speech models for revenue calls. Teams building real-world agents told us that more than 40% of callers hang up within the first 30 seconds. On a revenue call, that meant a lost booking, an unpaid balance, a cold lead, or a customer who does not come back. This happens because humans interrupt, correct dates, pause halfway through a sentence, or speak over someone in the background. The agent misses it, talks over them, or loses the thread. That’s because of how the current voice systems work. They sequentially listen, stop, think, and then speak. The conversation is actually a walkie-talkie exchange. So, we’re proud to introduce our first iteration of Mia & Leo who keep listening while they speak. They can handle interruptions, overlapping speech, corrections, and background voices without breaking the conversation. They are also built for production. Developers get control over agent behaviour, visibility into calls, failures they can debug, and costs that work at scale. Please try them out at metavoice.io. We'd love to hear any feedback!
Uploads.sh
Show HN: Uploads.sh – the missing upload command for coding agents (open-source)
Tomshardware
Open-source 3D-printed portable MRI machine built for under $70k
Rise-reforming
Hi HN! This is George, Lucas, and Jona from Rise Reforming (https://www.rise-reforming.com/). We’re developing a process to convert gas produced at landfills, farms, and wastewater plants (“biogas”) into higher value chemicals. Our technology is modular, designed to be deployed and operated on-site. Think of us as a chemical project developer; we sit between biogas producers (suppliers) and chemical end users (customers). We pay biogas producers for their gas and we make money from selling our chemicals. We're starting with dimethyl ether (DME) as our beachhead chemical because of its high-margin use case in the cosmetics industry and ultimately targeting methanol – a versatile and widely used industrial chemical. Being in a two sided market allows us to target two large problems. (1) On the chemical side: The multi-trillion dollar U.S. chemical and fuel industries are vulnerable to geopolitical conflicts and climate-driven natural disasters. The Iran war has caused global methanol prices to skyrocket – even in the U.S., a net exporter of methanol. (https://www.spglobal.com/energy/en/news-research/latest-news... the US). In 2021, Winter Storm Uri wiped out 60% of U.S. organic chemicals production for at least a month (https://www.dallasfed.org/research/swe/2021/swe2102/swe2102c...). The problem? Centralized production and fossil-fuel dependence. The solution isn't unknown; decentralized, fossil-free production could insulate supply chains from these shocks. But distributed green chemical production has yet to become cost-competitive with the status quo. Unlocking it requires the right feedstock paired with the right process and strategy. Also, the chemical industry’s reliance on fossil fuels makes it responsible for 5-6% of global greenhouse gas emissions. About 40% of the industry’s well-to-gate emissions come from just the extraction, processing, and transportation of these fossil fuels (https://rmi.org/resources/chemistry-in-transition-charting-s...). (2) Biogas is an ideal feedstock to address Problem 1. It is decentralized, plentiful, and a large part of it is not properly utilized. Biogas is a mixture of methane (CH4) and carbon dioxide (CO2), produced as a result of anaerobic digestion at landfills, farms, and wastewater plants, and can be used as a raw material in chemical manufacturing. The U.S. produces around 780 billion cubic feet of biogas a year – if we converted all that biogas into methanol, that’s about $20 billion a year. Currently, about 60% of this biogas is either burned for power/heat (low-margin and unreliable) or flared altogether. The rest is used in the highly subsidized renewable natural gas (RNG) market (https://americanbiogascouncil.org/abcs-data-digest-lite-july...). The result: many biogas producers leave substantial revenue on the table and experience huge operational headaches. Our modular technology takes in biogas, electricity, and water as inputs. Co-location with biogas producers allows us to tap into their existing infrastructure and speeds up permitting vs a greenfield project. Our 3 step process is outlined below: Step 1: We clean the biogas of contaminants. That means running the gas over specialized adsorbents that trap any nasty sulfur-containing and silicon-containing compounds we don’t want in our process. Step 2: We reform that biogas into an intermediate gas called syngas through the bi-reforming process, which combines the novel dry methane reforming reaction with the legacy steam methane reforming reaction. Syngas is a versatile combination of H2 and CO and is the building block for many chemicals, allowing us to be a platform company. Step 3: Lastly, we upgrade that syngas into our end chemicals. We do this step using conventional catalysts and operating conditions. The modular approach paired with our patent-pending integrated process makes our solution one of the cheapest ways of making green chemicals. Where are we today? We’ve completed our proof-of-concept in the lab and just broke ground on our pilot plant at a Chicagoland wastewater plant that currently flares all of its biogas. We will convert that wasted biogas into methanol. Estimated commissioning is Q1 2027. We all met at the University of Chicago studying Molecular Engineering and started the company back in June 2024. Rise Reforming’s first iteration came after attending a talk from an Argonne National Laboratory researcher on low-carbon fuels. In that seminar, we heard about a reaction called “dry reforming” wherein one can react CH4 with CO2, effectively eliminating both pollutants and making useful syngas (CO + H2). We realized that this reaction could enable cheaper decarbonization of chemicals than the legacy electrolysis pathway and started to build a technoeconomic analysis. George has a background in energy generation, storage, and carbon capture. He was an early employee at Highland Electric Fleets (now a unicorn) and later worked at Nexamp, GenH, and Mantel Capture – researching various battery chemistries, building a first-of-a-kind (FOAK) modular hydropower system, and helping prove a novel point-source capture prototype. He also conducted battery research at UChicago's Patel Lab and Rowan Group, co-authoring two papers. Lucas led the design, procurement, construction, and operation of Rise Reforming’s bench-scale reforming unit with controls that operated successfully for over 1800+ continuous hours. Prior to Rise, he worked at Avangrid (Iberdrola Group) with the offshore wind project services team and did transmutation research of spent nuclear fuel at Argonne National Laboratory. Jona also studied Molecular Engineering at the University of Chicago. He grew up around the marine industry and brings deep knowledge of the space to the team. While at UChicago, he conducted research in the Patel Lab on batteries and sustainable polymer applications and built novel equipment for the lab, including a high-throughput cyclic voltammetry battery performance testing device. Our advisory board has 220+ combined years in aerosols, permitting/safety, low-carbon fuels, catalysts, scale-up, automated modular chemical plants, and wastewater treatment. Here’s our launch video if you want to put faces to the names: https://youtu.be/Bx_ASPapxlQ?si=PAlqvd1eUhW8kjJm. We’d appreciate any feedback, questions, or advice. Thank you for reading! George, Lucas, and Jona
Flashpaper
Hi everyone! This is my first HN and I’m very new to the scene. My name is Min from Bangkok. At first, I just want to create a dead man's switch for personal use and for fun. then, I think about information that self destruct like a spy movie. after that, I try to come up with the better version of Privnote or Bitwarden with self-destruct and some kind of censoring or blocking download ability. Somehow, end up with this product. :O Flashpaper is for sending any information that would be burned after reading (with counting down timer like Mission Impossible movie ! or after 24 hrs max if not opened) Encryption happens in browser and because the key stays after # in the link; server never sees the key (Zero-knowledge for web use) and— because I’m a newbie. I don’t want to connect to database because I don’t have the money and I want things light and simple. So, that’s why Flashpaper keeps things in RAM-only, no database. For AI Agent side, Flashpaper provides a REST API and an MCP server so agents can create secret links easily in dead-drop style that can be claimed only once. The second claim would get a 404 which means someone already took it. However, for the agent API flow, the server sees the plaintext for a moment before encrypting, so this flow is not zero-knowledge like the web flow. Overall, I think it work quite well for web use, but for agent API use, I am not sure this is enough security. All the limitations are listed in SECURITY.md. Some feedback would be appreciated. I make it open source with MIT license, with honorware policy for Enterprise use, like self-hosted docker. Here is my repo https://github.com/mmmpym/flashpaper and you can try it here https://flashpaper.app Again ! Please feel free to tell me what I missed. Min
Vivari
Show HN: Vivari – Open-Source WebContainer for Node, Bun, and Python