kiselitza

Not sure how else to reply to this one, but it is the same thing as in its definition. Think less of client-server, think more of Postman, but without gazillion tabs and with docs at the same place with your API endpoint definition, headers, body, etc.

Deb and rpm should be ready any day now. I got nothing on flatpak or appimages tho.

To the best of my understanding, it is exactly what I wrote in the parent comment. It's the fact that the core lacks bits developed in the internal tool but not yet unglued from what will go in the plugins section.

It's not unheard of. For instance, I got another team and devtool I work with, non-related to the API niche, and they are going open source mid-next week. Some teams want to build the core their way, some want to see if it will catch traction before committing to support an entire community and contributions, some have got something else going on, some actually ARE shady and talk OSS for clout, etc.

Oh, 100%. And I'm all for FOSS and an adapter architecture approach (no lock-ins of any kind). Team is aware of it, CTO wants it, so opening the core is happening. I've got no reason not to believe them. Ofc, can't expect a stranger to believe me either. The fact that you can build your own plugins on top of the core, even before open-sourcing it, should be a sign that it's about giving you control, not locking you in on anything. But yeah, actually making it OSS will make that trust grow much easier.

Huhh, I think that may not be the worst idea. Feels like there’s room for a better shared language around this shift from everything-as-a-service towards owning your stack. Maybe even bringing back localhost is not the worst approach. Hmmm… just thinking out loud.

Hey, I know you! I used to use Insomnia before all the lock-in mess while I was still a dev. Thanks for the kind words, the team will appreciate it. I hope you keep doing what you like!

And we're happy to hear your feedback about it :)

Well, it's a standalone, non-hosted, offline application.

If you're designing your own API, you can do all the specs, docs, and if you get it up and running on localhost, you don't even need internet for testing it.

If you want to run a hosted API endpoint, or push your changes to git ofc you'll need the internet, but not because of the application, rather because you're trying to access something else that is not offline.

The easiest way I can think of is for you to join the Discord server. Top right corner of the website (I'm aware that's not the best icon for it - addressed it to the team).

Shouldn't take long until Linux is up there, tho. I know the team started managing the build process.

Hmm, I appreciate this, for real. We'll have some more discussions on how to optimize the landing page.

Curious, how do you feel about the tagline stuff? Happy to learn anything else you'd be willing to add here. We're all for making it crystal clear, no fluff, just making devs lives easier, which also means not wasting their time to understand whether they need it or not.

Yep, it's an Electron app. Looking to optimize it as well.

Much appreciated :) Let me know how it feels, the goods and the bads, every bit of feedback is very welcome.

That's correct. The intention IS to open source.

Voiden evolved from an internal tool where the team bundled a lot of features into the core product. Currently separating certain things into plugins. By the time that is done, and some community adoption/engagement is happening, the tool will be open-sourced.

As per the plugins, that's right. Some of the plugins can/will be monetized - but that's the discretion of the plugin developers. We won't be charging for any plugins that we build, unless they have an operational cost for us.

A repo, as in the project that contains the API specs and definitions, which you and your team are working on? Through terminal `git pull`

Or you're asking me something else?

Sweet, let us know how it feels. Happy to hear the feedback

Try https://voiden.md/

As per your needs it's: - Markdown (everything in markdown, including testing and specing APIs) - Let's you write your docs in markdown around the API you're designing/testing - Git-based (in-app terminal) - Code samples supported throug markdown

Plus offline, no login, no lock in, no telemetry.

It's early days so a tad rough around the edges still, but feels like the most natural way of handling APIs I ever used till date.

Just to congratulate you on going open source. I have nothing but high hopes and expectations for you folks.

Well, we are the ones telling devs not to reinvent the wheel, the least we could do is offer them the means to do it smoothly. :)

If you've ever dealt w authZ, you know the pain of listing challenge. Imagine having to check permissions for every single piece of content, for every single user, on every single homepage tap (or other action that pulls abnormal amount of content that has to be filtered out before shown) - the efficiency of such checks might get underwhelming really quickly.

This piece scratches the surface of a solution for such a challenge.

Intro to Cerbos exportVariables. By transitioning from the old approach of using local variables to the new method of importing exported variables, policy authors can streamline their policies, reduce duplication, and further improve overall readability, making their authZ config even smoother.