ideas VS apiclarity

State Encryption was one of those long requested features[0] (I had it on my ideas list for years[1]) that Hashicorp didn't have much incentive to build. I don't think it has to with distancing opentofu as such, but the opentofu team prioritizing the right things that customers actually need.

[0]: https://github.com/hashicorp/terraform/issues/9556

[1]: https://github.com/captn3m0/ideas#-mars-terraform-remote-htt...

What I would really like to see is “subscribeable OPML feeds”, so GitHub could provide a OPML feed for what shows up in your home page, and you any changes in your subscriptions (repos you watch etc) would change the OPML, which would then cause your feed reader to unsubscribe/subscribe to specific RAS feeds.

Unfortunately, this isn’t supported by the majority of RSS clients (tt-rss is the only one I know) which means in practice OPML feeds are merely import/export mechanisms.

Ref: https://github.com/captn3m0/ideas#opml-sync

I’ve been wanting to write a Mastodon/Twitter twine compiler that would take an existing Twine story and compile it to a list of posts.

https://github.com/captn3m0/ideas#twitter-adventure-maker

The primary difficulty is in flattening the state, which twine supports (apple=true, key=false in this story) but if it’s not too many variables might work out.

In my list of ideas is one for a Twine-compatible Twitter-Adventure Maker[0]. Remember those "choose your own adventure threads" that showed up on twitter and got viral a while back[1]. It would be great to be able to use Twine for authoring those.

[0]: https://github.com/captn3m0/ideas#twitter-adventure-maker

[1]: https://www.linkedin.com/pulse/media-trend-choose-your-own-a...

I wish OPML (the import/export RSS format) was also subscribe-able[1] in more clients. So my GitHub "news feed" would live at github.com/captn3m0/news.opml (which would just be a list of RSS URLs), and the client would update this list periodically.

Same thing works well for Twitter, or other sites.

[1]: https://github.com/captn3m0/ideas/#opml-sync

Almost exactly a fit against my idea[1] to generate OpenAPI from HAR files.

[1]: https://github.com/captn3m0/ideas#openapi-specification-gene...

Want to build the same, but using boardgame.io. Search for Gym here: https://github.com/captn3m0/ideas

I've been wanting something like this for an idea of mine[1]. Would love to have the ability to send arbitary responses (JPG/PNG)

[1]: https://github.com/captn3m0/ideas#svg-to-png-on-the-edge

We'll install APIClarity into a Kubernetes cluster to test our API documentation. We're using a Kind cluster for demonstration purposes. Of course, if you have another Kubernetes cluster up and running elsewhere, all steps also work there.

If you go to APIClarity, the first thing you’ll see is the source code (Figure 1), followed by some documentation at the bottom.

This feature is available in the open-source tool APIClarity, as part of the OpenClarity initiative.

Hi, I would also like to add another tool I'm contributing to at work (cisco) called APIClarity [1]. It aims at reconstructing swagger specifications of REST microservices running in K8S, but can also be run locally.

This is a challenging task and we don't support OpenAPI v3 specs yet (we are working on it).

Feel free to have a look, and get ideas from it :)

We'll also be presenting it at next Kubecon 2022.

[1]: https://github.com/openclarity/apiclarity

For example, APIClarity is a tool that observes all of the API traffic within your Kubernetes environment. Based on traffic observation, APIClarity infers an OpenAPI description for those APIs. This is especially helpful if the API creator never defined or provided such a description. It also surfaces potential problems with existing APIs, such as requests made to undocumented, shadow APIs or continued use of deprecated, zombie APIs. If you’re getting started on the path toward OAS compliance, then tools like APIClarity can be a great source of insight and observability.

The fundamental first step to solving this problem is to create an API spec and use it to audit and document the APIs your apps use. Ideally, we would create an API spec simply by observing API traffic in real-world applications. In the past, there was no simple, scalable, and open-source tooling capable of doing this. Now, we have APIClarity—an open-source API traffic visibility tool for Kubernetes (K8s) clusters. It’s purpose-built to address the gap and enable API reconstruction through observation.