The irony that I switched to Insomnia after Postman started demanding a login... and now I've been actively looking for alternatives (Bruno being on the list) now that Insomnia has done the same thing.
Especially once a VC gets into the fold.
1. Open source everything, including the parts of the code that are currently premium
2. Switch to a copyleft license like the GPL
3. Start accepting substantial contributions from the community without a CLA
Then they'd be legally unable to do that kind of rug pull.
Happy to see Bruno at the top of HN
We will never take VC funding. We received around 10 inbound reach outs from VCs till date and have denied funding from all of them.
We will remain independent and I have written about it in detail here https://www.usebruno.com/blog/bootstrapping
They haven't.
Like, that's kinda the whole point of offline-first, local-only tools, you can 100% use them in a an environment you control and take responsibility for. Once you take control of customer's data, there's a whole litany of due diligence that must considered, and often at considerable cost.
Your link makes sense, and I believe you. Have struggled with similar issues. But who knows what the future will bring? Google once said "don't be evil"; Oracle bought Sun. Is there any way you can guarantee your future actions? Contracts, articles of association/company constitution? Maybe setup a trust or charity? I don't think there is.
Though Insomnia doesn't work with streaming responses at all, which is a bit of a non-starter in the age of AI. Anyone know a good streaming HTTP UI?
https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88
If not, is there an example of "streaming HTTP" you could provide that illustrates the limitation
Of all the http-client applications I tested (Curl, Postman, Insomnia, Bruno), somewhat hilariously Curl has the best support. It will output all 'Transfer-Encoding: chunked' with line-by-line buffering, whereas Postman only supports responses precisely following the `Content-Type: text/event-stream` format (strictly less powerful than curl, as this format requires newlines in between events, and a bunch of overhead on top of that). The others buffer the entire response before displaying anything.
The `Content-Type: text/event-stream` format is fine enough, but I personally prefer to just plainly chunk the responses and let the client choose whether to buffer them into memory and operate on the entire value at once, or interpret them live as the chunks come in. With tools like gjp-4-gpt (Gradual JSON Parser 4 GPT's) you can even interpret partial JSON objects live as they come in and display complex/nested data structures in a generative manner.
https://cr.yp.to/proto/netstrings.txt
Personally I use a lame but effective simple 85.9 KiB static binary filter, a small C program, that removes the chunk sizes so the response is ready for use by other programs, e.g., in a pipe. Buffer is set at 8 KiB.
Is there a way to experiment with one of these streaming JSON GPT APIs non-interactively by just sending an HTTP request, without need for a third party program, an account, use of a Javascript engine, etc.
I don't know a public API that returns JSON slowly, but you could simulate it by just taking a JSON string, splitting it into 3-5 char chunks, and sending each of those in a `Transfer-Encoding: Chunked` response at ~100ms intervals.
Actually, now that I look at the underlying mechanism behind `Transfer-Encoding: Chunked`, it looks like it's already basically the same as the netstrings. What I'm referring to is the (variable length) contents of the netstring/chunk being sequential slices of a JSON object.
Only for the flexibility to use more programs. Otherwise every program I use to process HTTP responses needs to be able to accomodate chunked transfer encoding. Plus only a minority of sites send chunked responses. Instead, have one program that does one thing: remove chunked transfer encoding.
IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
> IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
I don't think so... I don't really want anything! Just a GUI that displays existing HTTP chunked responses as they come.
> GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
That's perhaps an exaggeration, but in general the speed and "smartness" of the model are inversely correlated.
Best of luck. Hope you can find the right program for viewing HTTP.