The best Hacker News stories from Show from the past day

Go back

Latest posts:

Show HN: My Terminal Themes Web App

Well, after 15 years of saying "Someday I'll turn this into a web app," I finally did it!<p>I've been maintaining a popular repo of terminal themes at <a href="https://github.com/mbadolato/iTerm2-Color-Schemes" rel="nofollow">https://github.com/mbadolato/iTerm2-Color-Schemes</a>, and it was finally time to build the app with all the features I wanted!<p>So, the next-gen version is live at <a href="https://terminalthemes.com" rel="nofollow">https://terminalthemes.com</a>! It currently has over 800 themes, and provides downloads for close to 40 different formats (iTerm, Ghostty, Windows, and many more)<p>It's free for everyone. An account is not needed to browse and download, but registering for an account (free) allows you to vote, bookmark, submit themes, etc.<p>I focused on a11y features for those who need it, in addition to adding Find My Theme and other tools to make it easy to find something you like!<p>Live terminal and code previews help show a more realistic view of the terminal, as opposed to the ANSI screenshots used at the GitHub repository. Those are still there, for those who like them.<p>I would love for you guys to check it out and provide feedback, feature suggestions, whatever!<p>And a huge thanks to the community of people that have contributed themes, ports to other terminals, and tools to provide conversions between formats over the years.<p>Oh! And if you've ever contributed themes to the GitHub repo, please register for an account, find your theme(s), and hit the Claim Authorship button!

Show HN: rStation – A shared research lab for your AI agents

Show HN: Ito – Build Terminal UIs in Lua

My friend and I are huge Neovim nerds. We like to rice our terminals and our editors. We just wanted a harness that we can do the same with, rice it till our hearts' desire. So, we started looking out for harnesses. Pi was great, Pi was good. But in the end, it was JavaScript. I don't have anything against JavaScript, but Lua is more fitting, and I can just as easily base it in Rust to make it even faster. So, we started cooking, and we ended up with a design that's minimal at its core and is built using Lua. Every built-in abstraction, the way you define providers, the way you rice it up, everything, literally everything, you can do in Lua.<p>But how? How does it all work? I proposed we just do it the Ratatui way, but my friend was like, nah! We shall make it possible to build TUIs in Lua. (Weirdo!) But it paid off, and we got ourselves a shiny new Lua library, ito!!!<p>He didn't get the gravity of the situation. We had an awesome terminal UI library in Lua! I wanted everyone to know how cool that is, so I got cooking, wrote myself a custom canvas implementation of this library instead of the usual terminal adaptor, exported it as wasm, and made this super cool website where you can experiment building awesome UIs in Lua. For vibe-coders, we got an llms.txt too. Have at it, and see if you can build something really cool with it. The library's at github.com/uji-labs/ito, and the awesome sauce harness is at github.com/uji-labs/uji.<p>I hope you like it!

Show HN: Wonderhop – A daily game: guess what most people say, or what none do

Hello HN!<p>Wonderhop is a small browser game with no account needed to play, everyday there are 4 rounds of 7 quesitons like "Name a food that a lot of people hate" The goal depends on the mode: Either gives the answer most people would give, the one no one would give, the oldest answer or the most recent one and there's a leaderboard for the day.<p>The most interesting part of the project was understanding answers that are typed freely and in 10 languages, there was some typos, plurals, nickname, or even duplicate way of sayign the same thing. We needed AI judge that checks it really existes conencted to some API like wikipedia to judge the veracity of each answer really quickly (less than 1s on average)<p>The percentage starts from an estimate but move really fast with the answers of real players. If the list missed a good answer, it gets added as soon as a few different players give it.<p>(There are also a lot of secrets and pop culture references added in the game :) )<p>A large part of the code was written with AI tools, but the artistic direction the concept and every choice design are human-made<p>We'd love to know if the goal is clear from the very first question while playing and were any good answers rejected unfairly<p>We are a couple of developers from Montreal that like guessing games so we built this in about two month.<p>Thanks a lot!

Show HN: Gemini 4 Argon plays StarCraft

I've refreshed StarSkirmish Bench, a benchmark where LLMs play StarCraft BW by writing code, with results from the flagship models of OpenAI, Anthropic, Google, and Muse

Show HN: Proa – A Rust web framework with fast SSR and multi-target rendering

Video: <a href="https://youtu.be/-CfCyvIKYyo?si=hCLuStkXxanCUJD1" rel="nofollow">https://youtu.be/-CfCyvIKYyo?si=hCLuStkXxanCUJD1</a><p>Video on multi-target rendering: <a href="https://youtu.be/pJx84jdBDKU?si=HRRd6dgUWXiqeWhq" rel="nofollow">https://youtu.be/pJx84jdBDKU?si=HRRd6dgUWXiqeWhq</a><p>Benchmarks: <a href="https://github.com/Proa-Labs/proa-benchmarks" rel="nofollow">https://github.com/Proa-Labs/proa-benchmarks</a>

Show HN: Proa – A Rust web framework with fast SSR and multi-target rendering

Video: <a href="https://youtu.be/-CfCyvIKYyo?si=hCLuStkXxanCUJD1" rel="nofollow">https://youtu.be/-CfCyvIKYyo?si=hCLuStkXxanCUJD1</a><p>Video on multi-target rendering: <a href="https://youtu.be/pJx84jdBDKU?si=HRRd6dgUWXiqeWhq" rel="nofollow">https://youtu.be/pJx84jdBDKU?si=HRRd6dgUWXiqeWhq</a><p>Benchmarks: <a href="https://github.com/Proa-Labs/proa-benchmarks" rel="nofollow">https://github.com/Proa-Labs/proa-benchmarks</a>

Show HN: Indigene – Native plants for where you stand

Back when I lived in Central Florida, it took me years to learn what native plants could benefit wildlife and the local ecosystem as I slowly replaced parts of my yard to make it more resilient to drought. After moving to Seattle a few years ago, I had to start all of that from scratch. LLMs made the process a bit easier but I still had to routinely ask the same kinds of questions over and over, despite being far more familiar with native plants these days and leaning more on native plant societies and botany resources like Doug Tallamy and Joey Santore whose excellent Crime Pays But Botany Doesn't site was recently posted here[1].<p>A good friend was visiting from Orlando over the summer and told me she was struggling to decide what to plant in her own yard despite her landlord being ok with it. That was enough of an excuse for me to kick off work on Indigene, which is aimed at giving folks just-in-time knowledge about what to plant based on their locale, sun exposure, soil conditions, and their own ecosystem support goals.<p>Candidly, as many of us have, I've also leaned heavily on LLMs (mostly Claude here) to bring this to life. Largely to avoid saying demonstrably false things, which might be an absurd statement. You can find the GitHub repository[2] a wild array of open data sources I've dug out and cross-referenced to ensure mistakes and hallucinations are unlikely to survive for long. But given today's Indigenous Peoples Day I figured it was past time I shared the projects and invited more scrutiny.<p>Being the Keep a Changelog guy, you can bet it has extensive release notes[3] generated from the project changelog. Those are also parsed into feature-specific guides so each also lists relevant recent updates.<p>Lastly, I put together a post[5] that goes into a bit more detail on the story of the project and what I've learned along the way.<p>I really, really hope people here (and beyond) find it as useful and enlightening as I do.<p>PS: before it comes up, all the LLM usage for the project is documented[6] and used as warning system in every PR but I think there's a lot more I can do to further reduce it<p>[1]: <a href="https://news.ycombinator.com/item?id=49192566">https://news.ycombinator.com/item?id=49192566</a><p>[2]: <a href="https://github.com/olivierlacan/indigene" rel="nofollow">https://github.com/olivierlacan/indigene</a><p>[3]: <a href="https://indigene.app/release-notes/" rel="nofollow">https://indigene.app/release-notes/</a><p>[4]: <a href="https://indigene.app/guide/" rel="nofollow">https://indigene.app/guide/</a><p>[5]: <a href="https://constantvariable.net/blog/2026/indigene-native-plants/" rel="nofollow">https://constantvariable.net/blog/2026/indigene-native-plant...</a><p>[6]: <a href="https://indigene.app/llm/" rel="nofollow">https://indigene.app/llm/</a>

Show HN: Indigene – Native plants for where you stand

Back when I lived in Central Florida, it took me years to learn what native plants could benefit wildlife and the local ecosystem as I slowly replaced parts of my yard to make it more resilient to drought. After moving to Seattle a few years ago, I had to start all of that from scratch. LLMs made the process a bit easier but I still had to routinely ask the same kinds of questions over and over, despite being far more familiar with native plants these days and leaning more on native plant societies and botany resources like Doug Tallamy and Joey Santore whose excellent Crime Pays But Botany Doesn't site was recently posted here[1].<p>A good friend was visiting from Orlando over the summer and told me she was struggling to decide what to plant in her own yard despite her landlord being ok with it. That was enough of an excuse for me to kick off work on Indigene, which is aimed at giving folks just-in-time knowledge about what to plant based on their locale, sun exposure, soil conditions, and their own ecosystem support goals.<p>Candidly, as many of us have, I've also leaned heavily on LLMs (mostly Claude here) to bring this to life. Largely to avoid saying demonstrably false things, which might be an absurd statement. You can find the GitHub repository[2] a wild array of open data sources I've dug out and cross-referenced to ensure mistakes and hallucinations are unlikely to survive for long. But given today's Indigenous Peoples Day I figured it was past time I shared the projects and invited more scrutiny.<p>Being the Keep a Changelog guy, you can bet it has extensive release notes[3] generated from the project changelog. Those are also parsed into feature-specific guides so each also lists relevant recent updates.<p>Lastly, I put together a post[5] that goes into a bit more detail on the story of the project and what I've learned along the way.<p>I really, really hope people here (and beyond) find it as useful and enlightening as I do.<p>PS: before it comes up, all the LLM usage for the project is documented[6] and used as warning system in every PR but I think there's a lot more I can do to further reduce it<p>[1]: <a href="https://news.ycombinator.com/item?id=49192566">https://news.ycombinator.com/item?id=49192566</a><p>[2]: <a href="https://github.com/olivierlacan/indigene" rel="nofollow">https://github.com/olivierlacan/indigene</a><p>[3]: <a href="https://indigene.app/release-notes/" rel="nofollow">https://indigene.app/release-notes/</a><p>[4]: <a href="https://indigene.app/guide/" rel="nofollow">https://indigene.app/guide/</a><p>[5]: <a href="https://constantvariable.net/blog/2026/indigene-native-plants/" rel="nofollow">https://constantvariable.net/blog/2026/indigene-native-plant...</a><p>[6]: <a href="https://indigene.app/llm/" rel="nofollow">https://indigene.app/llm/</a>

Show HN: Flipflop – Iroh-powered persistent tunnels for filesharing

This is a project that spun from my frustrations of using LocalSend and DashBeam to transfer stuff between devices, and with the extra goal of being fast, trying out the Slint framework and, most importantly, establishing a communication channel with trusted external people that can be left always on.

Show HN: Flipflop – Iroh-powered persistent tunnels for filesharing

This is a project that spun from my frustrations of using LocalSend and DashBeam to transfer stuff between devices, and with the extra goal of being fast, trying out the Slint framework and, most importantly, establishing a communication channel with trusted external people that can be left always on.

Show HN: Unfenced – Land for sale that borders public land

Show HN: Unfenced – Land for sale that borders public land

Show HN: Parsimony – an open-source benchmark for how much code AI models add

Existing benchmarks measure solve rate and token output/cost, but don't punish excess code, which makes a codebase harder to work with in the long term. I wanted to measure this since it matters most for long-term projects.<p>Method: it takes the patches that benchmarks already publish (DeepSWE, SWE-bench Verified, SWE-bench Live) and counts "coding units": syntax elements like statements, calls, names and literals. I didn't use lines of code, so cramming code isn't rewarded. Deleted code is subtracted, so it measures net units.<p>GPT-6 and Claude 5.5 have no public patches yet, so I ran them myself on 3–10 tasks on my own subscriptions (shown as faded circles, not ranked).<p>Any feedback or model contributions are welcome, especially public patch exports for newer models.<p>GitHub: <a href="https://github.com/La5u/Parsimony" rel="nofollow">https://github.com/La5u/Parsimony</a><p>Not affiliated with any of the benchmarks.

Show HN: A guided 3D Leonardo da Vinci museum, built in code

Hello HN,<p>I am the founder of a small nonprofit which built Museum of Ages. We opened its first wing last week, a digital Leonardo da Vinci museum. It is a virtual tour with 17 stops, his works and then his last house in Amboise. The entrance is free.<p>At the different stops you can see for example his paintings close to their real size, or 15 of his machines rebuilt in code, and you can have a look at 29 of his anatomy sheets. We also selected 207 of his manuscript pages which you can read in a virtual reading table, mirror the view to read his writing and 131 of the 207 are translated. We also rebuilt his last house in Amboise on the later stops of the walk. The museum is available in seven languages.<p>Each stop has one of four grades as a label, documented, reconstructed, conjectural and not known. In a detailed view the user can have a closer look at the sources.<p>The materials of the rooms and machines are created in Three.js. The museum runs with WebGPU. If the browser doesn’t support it, the fallback is WebGL2. To create the textures we used Creative Commons Zero photo scans (CC0) and for a few small objects we use free 3D models (CC0).<p>Our mission is to create digital museums you can walk as not everyone can get to a museum, because illness or disability keeps them away. Some cannot afford the trip or just reside far away. So our goal is also to make our digital museums as accessible as possible. Therefore we also pre-rendered the walk so that it also works on older phones and is easy to use for older people.<p>We released the code under AGPL-3.0. The texts and pictures are CC BY-SA 4.0. Reproductions have their own licenses. <a href="https://github.com/chipmates/museumofages" rel="nofollow">https://github.com/chipmates/museumofages</a><p>We put a lot of time and passion into the museum and hope you like it. We are happy about any feedback. Which digital museum would you like to see next?

Show HN: A guided 3D Leonardo da Vinci museum, built in code

Hello HN,<p>I am the founder of a small nonprofit which built Museum of Ages. We opened its first wing last week, a digital Leonardo da Vinci museum. It is a virtual tour with 17 stops, his works and then his last house in Amboise. The entrance is free.<p>At the different stops you can see for example his paintings close to their real size, or 15 of his machines rebuilt in code, and you can have a look at 29 of his anatomy sheets. We also selected 207 of his manuscript pages which you can read in a virtual reading table, mirror the view to read his writing and 131 of the 207 are translated. We also rebuilt his last house in Amboise on the later stops of the walk. The museum is available in seven languages.<p>Each stop has one of four grades as a label, documented, reconstructed, conjectural and not known. In a detailed view the user can have a closer look at the sources.<p>The materials of the rooms and machines are created in Three.js. The museum runs with WebGPU. If the browser doesn’t support it, the fallback is WebGL2. To create the textures we used Creative Commons Zero photo scans (CC0) and for a few small objects we use free 3D models (CC0).<p>Our mission is to create digital museums you can walk as not everyone can get to a museum, because illness or disability keeps them away. Some cannot afford the trip or just reside far away. So our goal is also to make our digital museums as accessible as possible. Therefore we also pre-rendered the walk so that it also works on older phones and is easy to use for older people.<p>We released the code under AGPL-3.0. The texts and pictures are CC BY-SA 4.0. Reproductions have their own licenses. <a href="https://github.com/chipmates/museumofages" rel="nofollow">https://github.com/chipmates/museumofages</a><p>We put a lot of time and passion into the museum and hope you like it. We are happy about any feedback. Which digital museum would you like to see next?

Show HN: I wrote an email app that accepts only one sender per inbox

Infinite inboxes, including prefixes where you don't have to create inboxes before you use them -- they self create when you add a suffix.<p>Three types of inboxes: - One sender. Locks to the first domain to send email (except gmail, outlook, etc where it locks to an email account for obivous reasons. It bounces everyone else. - Temporary. Lasts for a while (24h, 7days, etc) then bounces. Received messages stay or go as per your choice. - Prefix. The most powerful. Declare a prefix like "service" and then invent any suffix, like "service-netflix" or "service$bank" and it creates a new one-sender inbox locked to whoever wrote first.<p>Bring you own domain. Bring your own AI (MCP server ready). Forwarding.<p>Please help me test it.

Show HN: I wrote an email app that accepts only one sender per inbox

Infinite inboxes, including prefixes where you don't have to create inboxes before you use them -- they self create when you add a suffix.<p>Three types of inboxes: - One sender. Locks to the first domain to send email (except gmail, outlook, etc where it locks to an email account for obivous reasons. It bounces everyone else. - Temporary. Lasts for a while (24h, 7days, etc) then bounces. Received messages stay or go as per your choice. - Prefix. The most powerful. Declare a prefix like "service" and then invent any suffix, like "service-netflix" or "service$bank" and it creates a new one-sender inbox locked to whoever wrote first.<p>Bring you own domain. Bring your own AI (MCP server ready). Forwarding.<p>Please help me test it.

Show HN: Petal, open-source CoScreen/ScreenHero finally free

Hi HN!<p>I’m Jason Thomas, one of the founders of CoScreen.<p>As some of you may know, Datadog sunset the CoScreen service on July 31st.<p>Four of us from the original CoScreen team have spent the last couple months building a free and open source pair programming tool inspired by those that came before us: It’s called Petal (<a href="https://github.com/kiruna-labs/petal" rel="nofollow">https://github.com/kiruna-labs/petal</a>)<p>Some history first, because when we started CoScreen we had hoped to break the sad and established pattern of this industry.<p>Screenhero was an exceptional tool that a lot of us loved for pairing. Multiple cursors, low latency, you could click your partner’s editor, and just start typing. It felt like magic while we had it. Then Slack bought it in 2015, and shut down the standalone app in December 2017.<p>When Till, Max, and I started CoScreen, we were aware of this history, and wanted to build an even more magical collaboration and screen sharing experience: the entire concept was “throw a window from your laptop up on someone else’s screen, and start collaborating with zero friction.”<p>Datadog acquired us in 2022, and thus began the great adventure of adapting our real-time technology into Datadog products, while also continue developing CoScreen as a standalone tool from the Datadog ecosystem. Datadog invested in the product for years and we’re thankful for that. But CoScreen itself proved, like so many other screen sharing tool acquisitions, to be too tangential from the customer base and core mission. We instead built other communication features in Datadog, the integrations with other video platforms, and also its wildly successful MCP server. We weren't the only ones. Around was bought by Miro and shut down in March 2025. Multi (formerly Remotion) was acqui-hired by OpenAI in 2024 and shut down about a month later. It's nearly always the same story: a small team builds something hard that people love, a platform buys it for the team or the feature, and the standalone product doesn't survive the integration. So we decided firmly to do things differently this time. Petal is completely free and open source and we aren't monetizing it. If we lose interest or get hit by a bus, you can self-host it or fork it, and nobody can sunset it on you. Honestly it's a love letter to everyone in this community that supported us, believed in us, and to liberate collaborative screen sharing from this vicious cycle.<p>We hope through this we can help foster a large and vibrant community around innovating in this product sector. What Petal does: shared windows show up as real windows on your desktop, movable and resizable, not tiles in a grid. Several people can share at once, everyone gets a labeled cursor, and you can click into any shared window to type and scroll. Rooms are persistent, so you click once to join "eng-sync" instead of passing links around. It runs on macOS and Windows (Linux is next, this time for real and you can help us!), plus a web app. Media goes over LiveKit. You can use our hosted instance with zero config, or point the app at your own LiveKit server with one docker-compose if you want the traffic to stay on your network or even use an entirely different video backend if you want to. The part that still feels strange to us: CoScreen took almost six years to build. The first version of Petal took under eight weeks, from scratch, with frontier models like Fable and Astra doing a lot of the work. Real-time video and window capture is some of the most unforgiving code we have ever written, so we didn't expect that. We will do a proper writeup on what worked and what didn't, and are happy to answer questions about it here. Till, Darren, Max and I will be in the thread.

Show HN: Petal, open-source CoScreen/ScreenHero finally free

Hi HN!<p>I’m Jason Thomas, one of the founders of CoScreen.<p>As some of you may know, Datadog sunset the CoScreen service on July 31st.<p>Four of us from the original CoScreen team have spent the last couple months building a free and open source pair programming tool inspired by those that came before us: It’s called Petal (<a href="https://github.com/kiruna-labs/petal" rel="nofollow">https://github.com/kiruna-labs/petal</a>)<p>Some history first, because when we started CoScreen we had hoped to break the sad and established pattern of this industry.<p>Screenhero was an exceptional tool that a lot of us loved for pairing. Multiple cursors, low latency, you could click your partner’s editor, and just start typing. It felt like magic while we had it. Then Slack bought it in 2015, and shut down the standalone app in December 2017.<p>When Till, Max, and I started CoScreen, we were aware of this history, and wanted to build an even more magical collaboration and screen sharing experience: the entire concept was “throw a window from your laptop up on someone else’s screen, and start collaborating with zero friction.”<p>Datadog acquired us in 2022, and thus began the great adventure of adapting our real-time technology into Datadog products, while also continue developing CoScreen as a standalone tool from the Datadog ecosystem. Datadog invested in the product for years and we’re thankful for that. But CoScreen itself proved, like so many other screen sharing tool acquisitions, to be too tangential from the customer base and core mission. We instead built other communication features in Datadog, the integrations with other video platforms, and also its wildly successful MCP server. We weren't the only ones. Around was bought by Miro and shut down in March 2025. Multi (formerly Remotion) was acqui-hired by OpenAI in 2024 and shut down about a month later. It's nearly always the same story: a small team builds something hard that people love, a platform buys it for the team or the feature, and the standalone product doesn't survive the integration. So we decided firmly to do things differently this time. Petal is completely free and open source and we aren't monetizing it. If we lose interest or get hit by a bus, you can self-host it or fork it, and nobody can sunset it on you. Honestly it's a love letter to everyone in this community that supported us, believed in us, and to liberate collaborative screen sharing from this vicious cycle.<p>We hope through this we can help foster a large and vibrant community around innovating in this product sector. What Petal does: shared windows show up as real windows on your desktop, movable and resizable, not tiles in a grid. Several people can share at once, everyone gets a labeled cursor, and you can click into any shared window to type and scroll. Rooms are persistent, so you click once to join "eng-sync" instead of passing links around. It runs on macOS and Windows (Linux is next, this time for real and you can help us!), plus a web app. Media goes over LiveKit. You can use our hosted instance with zero config, or point the app at your own LiveKit server with one docker-compose if you want the traffic to stay on your network or even use an entirely different video backend if you want to. The part that still feels strange to us: CoScreen took almost six years to build. The first version of Petal took under eight weeks, from scratch, with frontier models like Fable and Astra doing a lot of the work. Real-time video and window capture is some of the most unforgiving code we have ever written, so we didn't expect that. We will do a proper writeup on what worked and what didn't, and are happy to answer questions about it here. Till, Darren, Max and I will be in the thread.

1 2 3 ... 1057 1058 1059 >