jratkevic

Hi HN,

We’re the team at MyDecisive.ai, and today we’re giving developers a peek at Octant — point-and-click control and visibility for your OpenTelemetry.

You've likely felt the pain of the "observability tax," especially if you manage K8S clusters. The modern standard is to instrument everything with OpenTelemetry, but piping all those rich OTLP logs, metrics, and traces straight to a SaaS vendor (Datadog, Splunk, Honeycomb) gets expensive fast. You end up paying massive ingestion and storage costs for noisy, low-value data just so it's searchable when something breaks. With Octant you get up and running on OTel in minutes.

We built Octant to flip this model. Instead of blindly shipping all telemetry off-cluster, Octant configures and helps to manage OTEL clusters. It gives you a visual interface for managing K8s objects, but importantly, it acts as an OTLP gateway that filters data at the source before it leaves your VPC.

Because it natively speaks OpenTelemetry, you can point your existing OTel SDKs or collectors right at it without touching your application code. Here is what it does under the hood:

- OTel-Native Trace & Log Sampling: It makes it easy to ingest OTLP traffic and inspects logs and traces on the wire. By waiting for the full context of a trace before determining what to keep, it delivers on the promise of braiding, retaining 100% of the actionable signals around (like errors and high-latency spans) but droppings the junk before it hits your SaaS bill.

- In-Flight Stateful Alerting: Instead of waiting for data to be batched, shipped, and indexed by an external provider to trigger an alert, Octant can process the telemetry streams in-flight. This shrinks the detection gap and reduces the need for SaaS vendors in the first place. - On-the-Wire PII Redaction: It can detect and strip sensitive information from your logs and traces in real-time before they are transmitted over the internet, removing "post-ingestion" clean-up costs and compliance risks.

- K8s Context Injection: Because it's deeply integrated with your cluster, it maps your OTel streams directly to your K8s resources (Deployments, Pods, CRDs) in a unified UI.

The API is built in Go ([github.com/mydecisive/octant] and the whole stack can be deployed directly into your cluster via our Helm charts.

We’d love for you to spin it up on a dev cluster and tear it apart. We just recently merged a PR from our very first community contributor, which was a huge milestone for us! We want to keep that momentum going. If you're interested in hacking on K8s observability and autonomy, OpenTelemetry pipelines, or Go/React, we’ve tagged a few 'good first issues' and would be thrilled to welcome you to the project.

GitHub: https://github.com/MyDecisive/octant

Website: https://www.mydecisive.ai/

I'll be hanging out in the thread today and am happy to answer any questions or dig into the architecture!

Oberon makes it possible for a service provider to issue capability tokens to clients in such a way that the service provider never sees the value of the capability token. This prevents the service provider from being able to impersonate the client. Oberon relies upon zero-knowledge proof presentation of the capability token so that the token is never transmitted norrevealed. Instead of the client sending the token to the service—as is done with API tokens today—the client sends a zero-knowledge proof proving that they have a valid capability token issued by the service provider; this is called proof-of-knowledge.

GitHub: https://github.com/cryptidtech/oberoncryptid

Get cryptid: https://www.cryptid.tech]