4y5k, have some self-respect. you could have cooked on this for a little bit longer than: yesterday. there is one commit! this is ... quite possibly, but I'm unsure, the first "show hn" with a single commit, lol
you can do that with full git history, the first commit is "upload files" or something like that, which I assume is via the UI because that is def not dev speak
Are you asking why transparency in the git history and how the code was created is important?
How do you git bisect when a bug was introduced in the mega-commit paradigm? This generally beneficial most for the primary developer.
Separately, the presence of mega commits is a red flag in the age of ai and slop. It's a warning sign for too much eyes-free coding. The agents are not good enough for this. If you are not staying in the loop and managing changes, then I have serious concerns about the security and reliability of the software.
Not necessarily. Plenty of devs (me included) clean up or reinit git history before a first release or going public. I understand it’s now read as an AI slop signal, but that’s no reason to dismiss their work.
Devil's advocate, it could have been a bunch of squashed commits. I've done that when open-sourcing stuff from work, after making sure the code didn't have any stray references to work-related items.
I initially developed and tested it locally in my own scratch environment before pushing the first public release via the web UI. I've now pushed the full structured commit history so the progression is visible. Also just released v0.1.1 on PyPI (`pip install ghostman`).
Posting works well for making outbound HTTP requests; the only part it doesn't handle by default is locally capturing and replaying webhooks.
While testing TradingView alerts, exchange execution callback handlers, or cryptocurrency payment webhooks for our trading software, we always find ourselves running `posting` (or `curl`) in one terminal window while having an additional tunneling/receiving script running in another one just to catch and retransmit the tricky JSON payloads.
I'm excited for CLI/TUI since 2016. It's just easier to use and automate. Other than a web browser, all the software I spend significant time in are CLI/TUIs. This includes most image editing.
OpenAPI / Swagger import is high on my roadmap for v0.2.0! Being able to point to an OpenAPI spec and immediately populate collections in the terminal would be awesome.
Feels odd to me to put TUI in the about section first, and then a few words later use no electron as a selling point - if I’m using a TUI I’m not expecting electron!
1) Sometimes you need to look at things yourself. You do verify the agent's work for important things, I hope? You've never seen them do mind-numbingly stupid things that warrant a bit scrutiny from time to time?
2) To me, Vim provides a normal UI. No slow, bloated, clunky, mousing, no slow Electron garbage, blegh. Just a quick, clean, lean UI.
I can relate to the part of your post where you have difference of opinion, but the apparent solipsism of not being able to understand why someone would want something different than you is the part of your post that drives me nuts. There are different people who like different things, is that not fairly straightforward to understand?
Absolutely unwarranted gatekeeping and bashing in this thread for the most benign reason. I think it looks neat. The API client space definitely needs some new FOSS entries after postman, insomnia, bruno all followed the same free -> freemium bait and switch way too common in dev tooling. Paywalling features that are already or previously implemented is a gross move, and feels especially egregious in the tooling space because developers integrate them as part of their flow and to get a random (albeit important) cog in that flow rugpulled or kneecapped adds undue annoyance and burden in whatever random project you happen to be working on at the time.
Nice work OP, I love these TUI tooling, and we need more options in this space in particular. Hopefully, next time you'll use git from the beginning (for your own organizational sake) but I'm honestly baffled people will disregard a whole FOSS project because of how you chose to make it public. Do better HN populace.
It even got to the point where I implemented my own Insomnia/Bruno alternative and I have been using it exclusively for months now. Because Bruno lacked some features I needed.
Last time I checked, Bruno implemented these features, but my version is still much faster and uses minimum resources in comparison (C++ and wxWidgets).
I don't see it the same way. People are building these things for themselves because it solves a specific problem they have, and that means it's crafted just to their liking. And it will only become easier to maintain these because of LLMs constantly advancing (for now). So if this is also a match for what you want out of a tool, then you can easily adopt it, or even fork it to your own liking. If it's not a fit for you, that's fine, there are plenty other options that may be.
I've seen several projects like this, where there is a flurry of activity for a few days, maybe a couple of weeks, and then it is abondoned and doesn't see any more updates. Maybe they got bored of it, maybe the code wasn't actually maintanable (which can easily happen with vibed code), maybe they were just trying to get attention and didn't actually care about the project.
Sure, but projects need to start somewhere. You can't go from one user to hundreds+ without first having two users. This is how they're deciding to share it the first time, and that's fine. Use it if you like, don't if you don't. Simple. If they stop maintaining it, then since it's open source and MIT license, you can do what you want with it to fix the issues you have.
It might have all the features it needs, but I have yet to see any non-trivial project that doesn't have bugs, or need occasional updates due to changes in something it interacts with.
4y5k, have some self-respect. you could have cooked on this for a little bit longer than: yesterday. there is one commit! this is ... quite possibly, but I'm unsure, the first "show hn" with a single commit, lol
I never publish my "first_draft" branch - never.
Why does it matter. It's pretty normal to do a bunch of dev locally and then at some point create a public gh repo and then push
you can do that with full git history, the first commit is "upload files" or something like that, which I assume is via the UI because that is def not dev speak
You could, but why is it important?
Are you asking why transparency in the git history and how the code was created is important?
How do you git bisect when a bug was introduced in the mega-commit paradigm? This generally beneficial most for the primary developer.
Separately, the presence of mega commits is a red flag in the age of ai and slop. It's a warning sign for too much eyes-free coding. The agents are not good enough for this. If you are not staying in the loop and managing changes, then I have serious concerns about the security and reliability of the software.
Not necessarily. Plenty of devs (me included) clean up or reinit git history before a first release or going public. I understand it’s now read as an AI slop signal, but that’s no reason to dismiss their work.
its not the only reason it is sus, I imagine you too use several dignals, likely evolving in the age of ai
update: idk how I have positive points on my comment above
I wouldn’t make one like it again. simply because I really have no clue how long the author thought about their project
hell, another front page Show HN has a single commit
Devil's advocate, it could have been a bunch of squashed commits. I've done that when open-sourcing stuff from work, after making sure the code didn't have any stray references to work-related items.
back at peak Slop HN, there were a ton of these, the fastest I recall was a few minutes from first commit time to Slop HN time
example: https://news.ycombinator.com/item?id=47492202
I recall sub-10m, but don't care to search has any harder
I initially developed and tested it locally in my own scratch environment before pushing the first public release via the web UI. I've now pushed the full structured commit history so the progression is visible. Also just released v0.1.1 on PyPI (`pip install ghostman`).
Without having looked to deeply into this..why?
https://github.com/darrenburns/posting
Exists, its from on of the co-devs of textual the framework this uses anyway..and more mature I would wager to say.
Posting works well for making outbound HTTP requests; the only part it doesn't handle by default is locally capturing and replaying webhooks.
While testing TradingView alerts, exchange execution callback handlers, or cryptocurrency payment webhooks for our trading software, we always find ourselves running `posting` (or `curl`) in one terminal window while having an additional tunneling/receiving script running in another one just to catch and retransmit the tricky JSON payloads.
And it's in Go which makes for the better app experience.
I’m a big fan of Hurl for this purpose. It’s just a thin declarative layer over curl.
https://hurl.dev/
Is it weird that in 2027 I get excited by apps becoming TUIs?
Would love to see OpenAPI support at least for import
Welcome, future person! Please give us good news about what will transpire since many of us are currently stuck on Halloween 2026. Thanks!
Maybe his fiscal 2027 year already started
I'm excited for CLI/TUI since 2016. It's just easier to use and automate. Other than a web browser, all the software I spend significant time in are CLI/TUIs. This includes most image editing.
And it's natural for many of us to aim at optimized tools and setups
OpenAPI / Swagger import is high on my roadmap for v0.2.0! Being able to point to an OpenAPI spec and immediately populate collections in the terminal would be awesome.
Feels odd to me to put TUI in the about section first, and then a few words later use no electron as a selling point - if I’m using a TUI I’m not expecting electron!
That's an LLM README for you. They probably used the sentence "without electron" during development in some prompt and it ended up there
You're responding to an LLM conversation generator.
If only the author of the project used this LLM to improve their README. It correctly detected an obnoxious issue !
But that LLM doesn't care! That's the real beauty.
What does human do best? Pollute, pullute everything to the ground.
Beautiful, I'm telling you, pure beauty.
Appreciate the text for the detector
Why do you need to inspect something in to if you have :
1) agents 2) normal ui
Not trying to be critical , just curious why ????
1) Sometimes you need to look at things yourself. You do verify the agent's work for important things, I hope? You've never seen them do mind-numbingly stupid things that warrant a bit scrutiny from time to time?
2) To me, Vim provides a normal UI. No slow, bloated, clunky, mousing, no slow Electron garbage, blegh. Just a quick, clean, lean UI.
I can relate to the part of your post where you have difference of opinion, but the apparent solipsism of not being able to understand why someone would want something different than you is the part of your post that drives me nuts. There are different people who like different things, is that not fairly straightforward to understand?
I would have preferred that it not have a UI at all and be more like curl on steroids.
Like httpie? https://httpie.io/cli
Absolutely unwarranted gatekeeping and bashing in this thread for the most benign reason. I think it looks neat. The API client space definitely needs some new FOSS entries after postman, insomnia, bruno all followed the same free -> freemium bait and switch way too common in dev tooling. Paywalling features that are already or previously implemented is a gross move, and feels especially egregious in the tooling space because developers integrate them as part of their flow and to get a random (albeit important) cog in that flow rugpulled or kneecapped adds undue annoyance and burden in whatever random project you happen to be working on at the time.
Nice work OP, I love these TUI tooling, and we need more options in this space in particular. Hopefully, next time you'll use git from the beginning (for your own organizational sake) but I'm honestly baffled people will disregard a whole FOSS project because of how you chose to make it public. Do better HN populace.
I completely agree with you.
It even got to the point where I implemented my own Insomnia/Bruno alternative and I have been using it exclusively for months now. Because Bruno lacked some features I needed.
Last time I checked, Bruno implemented these features, but my version is still much faster and uses minimum resources in comparison (C++ and wxWidgets).
I mean this is clearly unfinished and was certainly vibe-coded literally yesterday.
> No cloud accounts. No 1GB Electron bloat. 100% Local-first.
This would make me want to use Postman (Electron) over this, since I know that this will absolutely be unmaintained in the a few years.
I don't see it the same way. People are building these things for themselves because it solves a specific problem they have, and that means it's crafted just to their liking. And it will only become easier to maintain these because of LLMs constantly advancing (for now). So if this is also a match for what you want out of a tool, then you can easily adopt it, or even fork it to your own liking. If it's not a fit for you, that's fine, there are plenty other options that may be.
I've seen several projects like this, where there is a flurry of activity for a few days, maybe a couple of weeks, and then it is abondoned and doesn't see any more updates. Maybe they got bored of it, maybe the code wasn't actually maintanable (which can easily happen with vibed code), maybe they were just trying to get attention and didn't actually care about the project.
Sure, but projects need to start somewhere. You can't go from one user to hundreds+ without first having two users. This is how they're deciding to share it the first time, and that's fine. Use it if you like, don't if you don't. Simple. If they stop maintaining it, then since it's open source and MIT license, you can do what you want with it to fix the issues you have.
Or it is feature complete and doesn't need constant updates?
As long as it is being used daily, I think a project is still alive.
It might have all the features it needs, but I have yet to see any non-trivial project that doesn't have bugs, or need occasional updates due to changes in something it interacts with.