Apologies…missed that. Yeah this is what we are currently working on - part of the next release actually :)

you dont have ti provide anything, the weight of the proof is with the non believer :)

but okay lets go:

beyond all the obvious evidence:

the biggest evidence is around how difficult it would have been to stage it. how many people need to be bribed for eternal silence - this includes suppliers, ex workers, employees, crews, etc…why hasnt anyone admitted the lie in their deathbed?

what I am saying is that it is more difficult to stage this (successfully) than actually do the freakin thing.

I actually agree with most of your premise.

Voiden is not coming from “people are too scared of the terminal, let’s save them with buttons.” It comes from almost the opposite direction. A lot of us are terminal people too. The problem is not that curl, hurl, scripts, OpenAPI, or plain code are bad. The problem is that API work tends to get fragmented across too many places once it becomes real.

You have raw requests in one place, auth logic in another, docs somewhere else, examples in Slack, test cases somewhere else again, and then different teams consuming different versions of what is supposedly the same API. That’s the mess we care about.

So the goal with Voiden is not to replace power-user workflows but to give them a better structure, while also making that same source of truth usable by the rest of the team, including people who are not living in the terminal all day, or simply have different preferences.

That is also why composability matters so much to us. Reusable headers, auth, query params, payload fragments, shared blocks, documentation alongside execution , not because curl cannot do requests, but mainly because nobody wants to maintain the same slightly different request 100 times across scripts, docs, and collections.

And on the “UI tools become dead ends” point: yes, that is the trap we are trying to avoid. We do not want a bespoke black-box UI where if there is no button, you are stuck. The idea is to have one source of truth that can still work for power users, can be versioned in Git, can be shared, can be documented properly, and can evolve into automation/CLI/agent workflows as well.

So from my side it is not “UI versus terminal.” That debate is honestly a bit too small. What if we reframe this to: “Can we have one composable, reviewable, reusable representation of API work that serves both the terminal-native people and the wider team without duplicating everything across five tools?”

That is basically the whole bet.

So yeah, I get the skepticism. I have it too. The world does not need another glossy “API client” that turns into a toy the moment you step outside the happy path.

The point of Voiden is precisely to avoid that fate. I am sure you will see how radically different Voiden’s take is, if you just give it a spin for a few mins. In a world full of postman clones - we want Voiden to really stand out with a different approach to api tooling. :)

this is the fundamental meditation.

yes :) welcome to try

what if I tell you this was not intentional? I just realized this. But I can pretend this was done on purpose as a joke.

welcome to try and share your feedback here or here: https://github.com/VoidenHQ/voiden :)

awesome

hey, nikolas here (part of the team of Voiden)- I am keen to understand more if you dont mind. Which of the preferences you mentioned discounts this project? the version control and lightweight?

I guess you are you referring to the tool being on Electron (Since the version control is handled through the native git integration)?

We used electron cause allows to deliver the same experience across Windows, macOS, and Linux, and makes it easier to iterate quickly in these early stages.

a few points:

• Some apps do feel heavy because of how they are structured : monolithic cores, always-on cloud layers, or unnecessary background services. Voiden is (intentionally) built with a lightweight core: offline-first, Git-native, and without extra baggage.

• Voiden uses a plugin architecture. This means that we have a small core and all the extra functionality is optional (users can enable or disable plugins) so the base app stays small while the ecosystem can grow. Community contributions or advanced features don’t inflate the core, they live in plugins that users opt into.

At the same time, there is no special tie to Electron :) We evaluated other options as well but we felt they didn’t offer the same support for all the features we wanted to deliver.

But we intentionally designed the plugin SDK to be framework-agnostic, leaving the door open to switch the core to a different framework in the future if it makes sense.The goal is a tool that stays lean, extensible, and adaptable as it evolves.

apologies for the long answer - hope it makes sense?

yap, I think the plain text all the way from design, tests and docs is powerful. Looking forward to any thoughts you might have when you try.

yes, I heard and read about his racist and sexist stories as well. agree.