Posted by david927 11/9/2025
Ask HN: What Are You Working On? (Nov 2025)
I called it Wosp for word-oriented search and print. I released the first functional version a few days ago: https://github.com/atrettel/wosp
A multi-agent TUI that uses opencode and tmux to help me solve the frustrating LLM slot machine problem. I find that running 3 agents in parallel on even tough problems is enough to have one that builds what I want.
It’s also been a fun challenge to build a tool that can be used to improve itself
Live demo: https://play.tirreno.com/login (admin/tirreno)
website: https://murajah.pages.dev/
Play Store: https://play.google.com/store/apps/details?id=com.murajah.we...
Manual audio splitting tool for the above project: audio-splitter-6b3.pages.dev/
I've always been skeptical of AI-generated code. This is my first experiment with AI agents, where the full code base, implementation, debugging, and deployment are done using AI Agents MCPs.
Used VS Code all the way, i.e., all the source codes, including the code to generate the Google Play Store APK. I only reviewed the source code before committing and helped debug by suggesting ideas/algorithms.
Mostly used Claude Haiku 4.5 like 75% of the time, where it failed, switched to the sonnet 4.5 or GPT 5 codex. Interestingly, when debugging, sometimes one model struggled even after numerous iterations/feedback loops, but then the problem was solved instantly as soon as I switched to another model.
The source codes are available here:
https://github.com/wasi0013/Murajah
https://github.com/wasi0013/audio-splitter
Initially, I thought the audio splitting could be done automatically using some AI models from Hugging Face or Whisper. But the audio files have some complex repetitions; the output was miserable.
So, for now, this splitting is done manually using a Web UI (The audio splitting tool splits the large audio files into multiple small audio files, think of it like a long paragraph is split into multiple sentences.)
I will attempt again to automate this splitting task using AI, after drafting a game plan for tackling the challenges. I'm thinking of using energy drops and other similar factors to create segments.
If it works out, maybe this could be a way for me to replace the compromised Apple Music app with something that actually syncs to my music on my desktop.
https://play.google.com/store/apps/details?id=pipipie.game
It's currently only available on Android but I hope to bring it to other platforms soon.
I am a disabled developer who has limited mobility in his arms. I like treating games that are simple and accessible for people just to spend time.
Would love to hear any comments or suggestions!
A small OpenGL tutorial for Rust. Focus on understanding the OpenGL-API and interfacing with it directly, with a few as possible helper libraries.
Some of the chapters I'm currently working on can be found in the preview (https://preview.opengl.zgtm.eu/, ipv6 only).
People use Puter for an incredibly wide range of things, including cloud storage, web hosting, coding, AI, and gaming. Right now, we're mostly focused on improving performance and making sure that it's as fast as a regular desktop environment!
The protocol is fairly simple, encrypted by default, and works over lots of interesting transports.
Does the gossip flooding mean every single node needs to know about every other node in the entire mesh?
I have a project vaguely inspired by this and Meshtastic that tries to make use of existing internet tech, while falling back to local links, instead of trying to replace the Internet completely.
It's very much WIP, I'm planning to get rid of all of the automatic reliable retransmit stuff and replace it with per channel end to end acknowledgment. https://github.com/EternityForest/LazyMesh#
It works like your address is the hash of your pubkey, and you can announce that or not.
I assume every packet is probably at least 32 bytes, if 1000 people send one every ten minutes, that's going to be 700 bits per second or so, right?
It works great with lora, but each interface is it's own thing. It's not exactly like meshtastic/meshcore/etc (for better or worse) but also fulfills totally different roles. You can connect 1 interface to another, and only forward messages for particular addresses, if you want, or addresses that have announced on a specific interface, and you can control what you want to propagate/route.
You can set it up tons of different ways, so just imagine this is what you want:
- 20 ESP32 lora devices around my house, that respond with sensor-data or something - a pizero connected to the internet (via a huge TCP testnet) and lora (via a SPI device connected to some GPIO.) - These are not "secret" anyone can ask a sensor for it's data. the messages are encrypted, but they are intentionally public
If any of the 20 lora devices want to to be available to talk to someone on the internet, they can, and their announcements are forwarded, so people on the testnet know the address.
I can set it up so only messages directly to those 20 devices is forwarded, but otherwise announces are recorded (and replayed) on the pi.
Additionally, I can setup propagation for just my 20 devices, so even if they are out of range or turned off, they will get the message (from the pi) when they get back in range or turn on.
In this example, the structure of the network forms a kind of tree-like thing. Each tier of the network is scaled to the amount of traffic it can deal with: pi can deal with a ton, and is connected to internet, the ESP32s only need to deal with 1-to-1 traffic (announces don't really matter to them) and only compete with traffic from 20 devices (on the same lora network.)
These messages are pretty small (an announce is ~160 bytes, message proof is ~115 bytes.) For larger messages, you string them together over a link (a 1-to-1 encrypted tunnel.) I think a key thing though, is that not every tier of the network needs to send all the same packets. For example, not even 1000th of the "testnet firehose" gets sent over the local lora net of 20 devices, based on how it's setup here.
So, the usage-flow of this would like this:
- each sensor announces on lora, pi forwards that to internet ("hey my address/pubkey is X, and I have these cool capabilities as a sensor") - a user on internet sends a data-message to the address "hey give me your sensor data" - the pi routes that from internet to lora, and propagates (replays periodically if the lora is not around) - if the esp32 has not seen that peer, it can request an announce (and the pi will forward that both ways) - the esp32 responds "oh hey internet user with X address, my sensor data is X" - the message is sent over lora to the pi, which forwards on to internet
for very small data, if you don't care about P2P encryption, you could even put the sensor-data directly in the initial announce. "hey I have this address/pubkey and the current temperature is X" since announce "app data" is great for a very small amount of data.