Forem

Greedy Arrays in PHP

Edmond — Thu, 16 Apr 2026 15:42:13 +0000

In some optimized PHP applications, you may occasionally see “strange code” like $this->array = [] after heavy usage. There’s an array that held many elements, and then it suddenly gets cleared by assigning a new empty array. You might think, “that’s just how the author wrote it.” But most likely not — the author is probably familiar with the problem of greedy arrays in PHP.

The idea: PHP arrays can grow dynamically, but they do not shrink dynamically.

Example. Suppose you created a queue of 10,000 elements. You processed everything. But in reality, the memory remains allocated. Is this a problem? Yes. If you’re writing stateful applications, this can become an issue. Nothing seems wrong, yet your process keeps growing over time, and you can’t even figure out why. Sound familiar? Here’s the culprit.

That’s why for long-running PHP applications it’s recommended to always explicitly clear large arrays.

The operation $this->array = [] tells the PHP engine to fully release the entire memory block, after which the object property is assigned a constant empty array.

Why is it designed this way? Because automatic shrinking of data structures is one of the most complex algorithms. It either complicates the code significantly or leads to performance loss. So the decision in PHP is reasonable: do not shrink arrays automatically. However, this still remains a language limitation. How to solve it? Possibly by introducing a new garbage collector.

Prism: A stateless payment integration library extracted from 4 years of production

Neeraj Kumar — Thu, 16 Apr 2026 15:40:55 +0000

The Problem

If you have ever integrated a payment processor, you know the drill. You read through a PDF that was last updated in 2019, figure out what combination of API keys goes in which header, discover that "decline code 51" means something subtly different on this processor than the last one you dealt with, and then do it all over again when your business decides to add a second processor.

We have been living in this world for years building Juspay Hyperswitch, an open-source and composable payments platform. At some point we had integrations for 100+ connectors. The integrations worked well — but they were locked inside our orchestrator, not usable by anyone who just needed to talk to Stripe or Adyen without adopting an entire platform.

And we always felt the payment APIs are not more complicated than database drivers. It is just that the industry has not arrived at a standard (and likely never will) for payments.

Hence, we decided to extract the integrations into a lightweight open interface for developers and AI agents to use, rather than recreate it every time.

This post is about how we did that: unbundling those integrations into a standalone library called Prism, and the engineering decisions we made along the way. Some of them are genuinely interesting.

Why unbundle at all?

The connector integrations inside Hyperswitch were not designed to be embedded in an orchestrator forever. They were always a self-contained layer: translate a unified request into a connector-specific HTTP call, make the call, translate the response back. The orchestrator was just the first thing to use them.

The more we looked at it, the more it seemed wrong to keep that capability locked behind a full platform deployment. If you just need to accept payments through Stripe, you should not have to adopt an orchestrator to get a well-tested, maintained integration. And if you want to switch to Adyen later, that should be a config change, not a rewrite.

So we separated the integration layer out. The result is a library with a well-defined specification — a protobuf schema covering the full payment lifecycle — that can be embedded directly in any application or deployed as a standalone service.

Why protobuf for the specification?

Q: JSON schemas exist. OpenAPI exists. Why protobuf?

The core requirement was multi-language client generation. We needed Python developers, Java developers, TypeScript developers, and Rust developers to all be able to consume this library with first-class, type-safe APIs — without anyone hand-writing SDK code in each language. Protobuf has the most mature ecosystem for this: prost for Rust, protoc-gen-java for Java, grpc_tools.protoc for Python, and so on. It also doubles as our gRPC interface description when the library is deployed as a server, which turned out to be a natural fit for the two deployment modes we wanted to support.

The specification covers the full payment lifecycle across nine services:

Service	What it does
`PaymentService`	Authorize, capture, void, refund, sync — the core lifecycle
`RecurringPaymentService`	Charge and revoke mandates for subscriptions
`RefundService`	Retrieve and sync refund statuses
`DisputeService`	Submit evidence, defend, and accept chargebacks
`EventService`	Process inbound webhook events
`PaymentMethodService`	Tokenize and retrieve payment methods
`CustomerService`	Create and manage customer profiles at connectors
`MerchantAuthenticationService`	Access tokens, session tokens, Apple Pay / Google Pay session init
`PaymentMethodAuthenticationService`	3DS pre/authenticate/post flows

Everything is strongly typed. PaymentService.Authorize takes a PaymentServiceAuthorizeRequest — amount, currency, payment method details, customer, metadata, capture method — and returns a PaymentServiceAuthorizeResponse with a unified status enum, connector reference IDs, and structured error details. No freeform JSON blobs. No stringly-typed status fields. The spec is the contract.

The implementation: Rust at the core

Q: Why Rust? Wouldn't Go or Java be simpler?

A few reasons. First, we already had 50+ connector implementations in Rust from Hyperswitch, so starting there was practical. But more importantly: the library needs to be embeddable in Python, JavaScript, and Java applications without a separate process or a runtime dependency like the JVM or a Python interpreter. The only realistic way to distribute a native library that loads cleanly into all of those runtimes is as a compiled shared library — .so on Linux, .dylib on macOS. Rust produces exactly that, with no garbage collector pauses, no runtime to ship, and memory safety that does not require a GC.

The Rust codebase is organized into a handful of internal crates:

connector-integration — The actual connector logic: 50+ implementations translating unified domain types into connector-specific HTTP requests and parsing responses back
domain_types — Shared models: RouterDataV2, flow markers (Authorize, Capture, Refund, ...), request/response data types
grpc-api-types — Rust types generated from the protobuf spec via prost
interfaces — The trait definitions that connector implementations must satisfy

The two-phase transformer pattern

The single most important design decision in the Rust core is that the library never makes HTTP calls itself. Every payment operation is split into two pure functions:

┌─────────────┐    req_transformer      ┌──────────────────┐
│  Unified    │ ──────────────────────▶ │ Connector HTTP   │
│  Request    │                         │ Request          │
│  (proto)    │                         │ (URL, headers,   │
└─────────────┘                         │  body)           │
                                        └────────┬─────────┘
                                                 │  you make this call
                                                 ▼
┌─────────────┐    res_transformer      ┌──────────────────┐
│  Unified    │ ◀────────────────────── │ Connector HTTP   │
│  Response   │                         │ Response         │
│  (proto)    │                         │ (raw bytes)      │
└─────────────┘                         └──────────────────┘

req_transformer takes your unified protobuf request and returns the connector-specific HTTP request — the URL, the headers, the serialized body. You make the HTTP call however you like. res_transformer takes the raw response bytes plus the original request and returns a unified protobuf response.

Q: Why not just have the library make the HTTP call for you?

Mostly because it makes the library genuinely stateless and transport-agnostic. It does not own any connection pools. It does not have opinions about TLS configuration, proxy settings, or retry logic. When this code runs inside a Python application, the Python application's httpx client handles the HTTP. When it runs inside the gRPC server, the server's client handles it. This also turns out to be quite testable — you can unit test transformers by feeding them request bytes and asserting on the resulting HTTP request structure, without standing up any network infrastructure.

Each flow is registered using a pair of Rust macros:

// Register the request transformer for the Authorize flow
req_transformer!(
    fn_name: authorize_req_transformer,
    request_type: PaymentServiceAuthorizeRequest,
    flow_marker: Authorize,
    resource_common_data_type: PaymentFlowData,
    request_data_type: PaymentsAuthorizeData<T>,
    response_data_type: PaymentsResponseData,
);

// Register the response transformer for the Authorize flow
res_transformer!(
    fn_name: authorize_res_transformer,
    request_type: PaymentServiceAuthorizeRequest,
    response_type: PaymentServiceAuthorizeResponse,
    flow_marker: Authorize,
    resource_common_data_type: PaymentFlowData,
    request_data_type: PaymentsAuthorizeData<T>,
    response_data_type: PaymentsResponseData,
);

The macros generate the boilerplate: connector lookup, trait object dispatch, RouterDataV2 construction, serialization. A new flow means adding the connector trait implementation and one pair of macro invocations. The code generator handles everything else.

Two ways to use it

We wanted the library to work both as an embedded SDK (loaded directly into your application process) and as a standalone gRPC service (deployed separately, called over the network). Same Rust core, same proto types, same API — two completely different deployment topologies.

┌──────────────────────────────────────────────────────────┐
│                    Your Application                      │
└─────────────────────┬────────────────────────────────────┘
                      │
         ┌────────────┴────────────┐
         ▼                         ▼
 ┌──────────────┐         ┌─────────────────┐
 │   SDK Mode   │         │   gRPC Mode     │
 │  (FFI/UniFFI)│         │ (Client/Server) │
 └──────┬───────┘         └────────┬────────┘
        │                          │
        │  in-process call         │  network call
        ▼                          ▼
 ┌──────────────────────────────────────────────┐
 │              Rust Core (Prism)               │
 │  req_transformer → [HTTP] → res_transformer  │
 └──────────────────────────────────────────────┘

Mode 1: The embedded SDK

In SDK mode, the Rust core compiles into a native shared library (.so / .dylib) and is exposed to host languages via UniFFI — Mozilla's framework for generating language bindings from Rust automatically. When your Python code calls authorize_req_transformer(request_bytes, options_bytes), that call crosses the FFI boundary directly into the Rust binary running in the same process.

Data crosses the language boundary as serialized protobuf bytes. This is intentional — every language already has a protobuf runtime, so there is no custom serialization protocol to maintain, and the byte interface is completely language-neutral.

Q: Does this mean I need to compile Rust to use the Python SDK?

For development, yes — you run make pack, which builds the Rust library, runs uniffi-bindgen to generate the Python bindings, and packages everything into a wheel. For production use, we ship pre-built binaries for Linux x86_64, Linux aarch64, macOS x86_64, and macOS aarch64 inside the wheel. The loader picks the right one at runtime. You install the wheel and never think about Rust again.

Mode 2: The gRPC server

In gRPC mode, the grpc-server crate runs as a standalone async service built on Tonic (Rust's async gRPC framework). It implements all nine proto services, accepts gRPC connections from any language's generated stubs, makes the connector HTTP calls internally, and returns unified proto responses over the wire.

The gRPC server calls the same Rust core transformers as the FFI layer — just from a different entry point. The transformation logic is literally the same code path.

Each language SDK ships both deployment modes:

sdk/python/
├── src/payments/           ← FFI-based embedded SDK
│   ├── connector_client.py
│   └── _generated_service_clients.py
└── grpc-client/            ← gRPC stubs for server mode

sdk/java/
├── src/                    ← FFI-based embedded SDK (JNA + UniFFI)
└── grpc-client/            ← gRPC stubs for server mode

sdk/javascript/
├── src/payments/           ← FFI-based embedded SDK (node-ffi)
└── grpc-client/            ← gRPC stubs for server mode

Q: When would you actually choose gRPC over the embedded SDK?

The embedded SDK is great when you have a single-language service and want zero network overhead — serverless functions, edge deployments, or situations where adding a sidecar is painful. The gRPC server shines in polyglot environments: if your checkout service is in Java, your fraud service is in Python, and your reconciliation job is in Go, deploying one gRPC server gives all of them a shared, consistent integration layer without each one shipping a native binary.

The important point is that the choice is not a migration — your PaymentServiceAuthorizeRequest looks identical in both modes. You change a config flag, not your application code.

	SDK (embedded)	gRPC (network)
Latency	Microseconds (in-process)	Milliseconds (network)
Deployment	Library inside your app	Separate service to run
Language support	Python, JS, Java/Kotlin, Rust	Any language with gRPC
Connector HTTP	Your app makes the calls	Server makes the calls
Best for	Serverless, edge, single-language	Polyglot stacks, shared infra

Code generation: the glue that holds it together

Prism supports many payment flows and many SDK languages. Hand-maintaining typed client methods for each flow in each language is exactly the kind of work that introduces drift and bugs. So we don't do it.

The code generator at sdk/codegen/generate.py reads two sources of truth and emits all the SDK client boilerplate automatically.

Q: What are the two sources of truth?

services.proto compiled to a binary descriptor — this tells the generator every RPC name, its request type, its response type, and its doc comment.

crates/ffi/ffi/src/services/payments.rs — this tells the generator which flows are actually implemented, by scanning for req_transformer! invocations.

The generator takes their intersection. A flow in proto but not implemented in Rust? Warning, skipped — we don't ship unimplemented APIs. A transformer in Rust with no matching proto RPC? Also a warning — the spec is the authority, not the implementation.

Running make generate produces typed client classes across all languages. For example, in Python:

class PaymentClient(_ConnectorClientBase):
    async def authorize(
        self,
        request: PaymentServiceAuthorizeRequest,
        options=None
    ) -> PaymentServiceAuthorizeResponse:
        """PaymentService.Authorize — Authorizes a payment amount on a payment method..."""
        return await self._execute_flow(
            "authorize", request, _pb2.PaymentServiceAuthorizeResponse, options
        )

And in Kotlin:

class PaymentClient(config: ConnectorConfig, ...) : ConnectorClient(config, ...) {
    fun authorize(
        request: PaymentServiceAuthorizeRequest,
        options: RequestConfig? = null
    ): PaymentServiceAuthorizeResponse =
        executeFlow("authorize", request.toByteArray(), PaymentServiceAuthorizeResponse.parser(), options)
}

Here is the full pipeline:

services.proto
    │
    ├── prost (Rust build.rs)      → grpc-api-types crate (Rust types)
    ├── grpc_tools.protoc          → payment_pb2.py (Python proto stubs)
    ├── protoc-gen-java            → Payment.java (Java/Kotlin proto stubs)
    ├── protoc (JS plugin)         → proto.js / proto.d.ts (JS proto stubs)
    └── protoc (binary descriptor) → services.desc
                                            │
payments.rs (transformer registrations) ───┤
                                            ▼
                                      generate.py
                                            │
        ┌───────────────────────────────────┼──────────────────────┐
        ▼                                   ▼                      ▼
_generated_ffi_flows.rs    _generated_service_clients.py    GeneratedFlows.kt
                           connector_client.pyi             _generated_connector_client_flows.ts


cargo build --features uniffi
    └── uniffi-bindgen
              ├── connector_service_ffi.py   (Python native bindings)
              ├── ConnectorServiceFfi.kt     (Kotlin/JVM native bindings)
              └── ffi.js                     (Node.js native bindings)

The practical result: add a new flow to services.proto, implement the transformer pair in Rust, run make generate — and every language SDK gets a typed, documented method for that flow. No one writes boilerplate by hand.

Walking through a real authorize call

Let's trace what actually happens when a Python application calls client.authorize(...) in SDK mode:

① App builds PaymentServiceAuthorizeRequest (protobuf message)

② PaymentClient.authorize() → _execute_flow("authorize", request, ...)

③ _ConnectorClientBase._execute_flow():

   a. request.SerializeToString() → request_bytes

   b. authorize_req_transformer(request_bytes, options_bytes)
      ──── FFI boundary: Python → Rust shared library ────
      Rust: build_router_data! macro
        ├── ConnectorEnum::from("stripe")   ← look up connector
        ├── connector.get_connector_integration_v2()
        ├── proto bytes → PaymentFlowData + PaymentsAuthorizeData
        ├── construct RouterDataV2 { flow, request, auth, ... }
        └── connector.build_request(router_data) → Request { url, headers, body }
      serialize Request → FfiConnectorHttpRequest bytes
      ──── returns bytes across FFI boundary ────

   c. deserialize FfiConnectorHttpRequest → url, method, headers, body

   d. httpx AsyncClient.post(url, headers=headers, content=body)
      ← this is the actual outbound HTTP call to Stripe

   e. raw response bytes received

   f. authorize_res_transformer(response_bytes, request_bytes, options_bytes)
      ──── FFI boundary: Python → Rust shared library ────
      Rust: connector.handle_response(raw_bytes)
        ├── parse Stripe's JSON response format
        └── map → PaymentServiceAuthorizeResponse (unified proto)
      serialize → proto bytes
      ──── returns bytes across FFI boundary ────

   g. PaymentServiceAuthorizeResponse.FromString(bytes)

④ App receives unified PaymentServiceAuthorizeResponse

In gRPC mode, steps ③b through ③f happen inside the grpc-server process. The app sends the protobuf request over the network and gets the protobuf response back. The connector lookup, HTTP call, and response transformation are identical — just running in a different process.

Where we go from here — together

We want to be upfront about what this is and what it is not.

What it is: a working implementation with 60+ connectors, a protobuf specification that covers the full payment lifecycle, and SDKs in four languages. It is ready to use today.

What it is not: a finished standard. The spec reflects our understanding of what payment integrations need to look like. That understanding is incomplete, and we know it. Payment APIs have a very long tail of edge cases — 3DS flows that differ between processors, webhook schemas that change without notice, authorization responses that technically succeeded but should be treated as soft declines. There is no team small enough to have seen all of it.

That is why community ownership matters here, not as a marketing posture, but as a practical necessity.

If you want to use it: install the SDK, run make generate to see what flows are available, and point it at your test credentials. When something breaks — and something will — open an issue. The more connectors and flows get exercised in real environments, the faster the rough edges get found.

If you want to contribute a connector: implement a Rust trait in connector-integration/. The FFI layer, gRPC server, and all language SDKs pick it up automatically. You do not need to write Python or JavaScript or maintain anything outside that one crate.

If you want to contribute a flow: start with a discussion on the services.proto shape — that is the community contract, so it deserves a conversation before code gets written. Once there is agreement, implement the transformer pair in Rust, run make generate, and every SDK gets the new method in every language.

If you disagree with a spec decision: open a discussion. The whole point of making this community-owned is that no single team's assumptions should be baked in permanently. If you have seen payment edge cases that the current schema cannot express, that is exactly the kind of feedback that shapes a standard.

The longer arc here is for services.proto to evolve into something the payments community — developers, processors, orchestrators, and everyone else in the stack — maintains collectively. The same way OpenTelemetry's semantic conventions emerged from broad input, not from one company's opinions. The same way JDBC worked because it was simple enough to implement and strict enough to actually abstract.

GitHub: juspay/hyperswitch-prism

AI Agent Payments in India: The Complete Infrastructure Guide (2026)

Umang Gupta — Thu, 16 Apr 2026 15:40:11 +0000

MoltPe gives Indian developers, freelancers, and AI startups dollar-denominated agent wallets that receive and send USDC globally with zero forex fees, zero gas fees, and sub-second settlement. No foreign entity required, no credit card to start, no minimum balance. Use it alongside UPI and Razorpay for a complete domestic plus international payment stack.

Table of Contents

Why This Matters for India
How MoltPe Solves It for Indian Builders
MoltPe vs Razorpay International vs Stripe India vs PayPal
Use Cases for Indian Builders
How It Works in Three Steps
Related Guides
Frequently Asked Questions

Why This Matters for India

India has one of the world's largest and fastest growing AI developer populations. Bangalore, Hyderabad, Pune, Chennai, and Delhi NCR are producing a new generation of builders who write code in English, ship to global customers, and compete at the frontier of agent systems, retrieval-augmented generation, and automation tooling. The talent is here. The ambition is here. The payments infrastructure is not.

The friction shows up the moment an Indian builder tries to collect international revenue or pay a foreign service provider. PayPal typically takes around 4 to 5 percent on cross-border receipts, plus a forex spread on the INR conversion. SWIFT wires are slow, manual, and expensive per transaction, which makes them useless for anything under a few hundred dollars. Stripe India operates under restrictions that do not apply in the US or the UK. Razorpay International runs on top of the same legacy forex rails and still imposes a conversion spread. Every one of these options was built for a world where payments were initiated by humans, cleared by correspondent banks, and measured in days.

AI agent payments live in a different world. An agent making two hundred micropayments a day to different paid APIs cannot tolerate a four percent fee stack. A freelancer in Hyderabad billing a client in San Francisco does not want to wait three to five business days and lose money to forex each time. An AI SaaS founder in Bangalore charging per API call in small amounts needs settlement in seconds, not T plus two.

USDC via MoltPe routes around the legacy stack entirely. USDC is a dollar-denominated stablecoin. The value never touches the SWIFT or card networks in transit. Your Indian clients, international clients, and AI agents transact directly against on-chain dollar balances, and your wallet is yours. There is no correspondent bank in the middle, no forex conversion at the platform layer, and no three-to-five-day settlement window. This is the infrastructure that the next decade of Indian AI and SaaS builders need, and it is available right now.

How MoltPe Solves It for Indian Builders

MoltPe is AI-native payment infrastructure that gives AI agents isolated wallets with programmable spending policies for autonomous USDC stablecoin transactions. Every agent gets its own non-custodial wallet secured with Shamir key splitting, which means no single party, including MoltPe, ever holds a complete private key. Your funds are yours, cryptographically, from the moment the wallet is created.

For Indian developers, the combination of features matters more than any single one:

Dollar-denominated balances. Your agent wallet holds USDC. You hold dollars until you choose to convert. No more watching a rupee-denominated balance shrink as the dollar strengthens mid-month.
Zero forex fees at the platform level. When a client in New York or London or Singapore pays your agent wallet, they transfer USDC. You receive USDC. Nothing is converted on the way in. You only touch forex when and if you decide to convert to INR later, on a venue of your choosing.
Zero gas fees on supported chains. MoltPe covers gas on Polygon PoS, Base, and Tempo. A two-dollar micropayment costs two dollars, not two dollars plus a thirty cent network fee.
Sub-second settlement. Payments clear on chain in roughly 500 milliseconds. Compare this to PayPal holds, SWIFT delays, or card network settlement windows.
Programmable spending policies. Set a daily cap, a per-transaction cap, a recipient allowlist, and a cooldown period.
AI-agent-native interfaces. REST API, Model Context Protocol server, and x402 support out of the box.
Free tier, no credit card, no gating. An indie developer in Chennai can create an agent wallet in under five minutes.
Works from any country. No India-specific restriction, no US-entity requirement.

MoltPe is the layer Indian AI builders deserve.

See the full guide at https://moltpe.com/india for complete comparison tables, use cases, FAQs, and integration steps.

Originally published at https://moltpe.com/india. MoltPe is AI-native payment infrastructure that gives AI agents isolated wallets with programmable spending policies for autonomous USDC transactions. Get started free →

Your Perimeter Is Already Gone — Edge Security Isn't a Checkbox

Jon Zuanich — Thu, 16 Apr 2026 15:39:00 +0000

Edge devices live outside your control plane, in physically accessible environments, often running default credentials. Treating that as an afterthought has a predictable outcome.

There's a mental model that dominated enterprise security thinking for decades: draw a perimeter around your systems, trust everything inside it, and defend the boundary.

That model was already struggling in the cloud era. At the edge, it doesn't apply at all because your "perimeter" is now:

A drilling rig in a remote field,
A charging station in a concrete parking garage,
A sensor package on a factory floor accessible to any maintenance technician,
Or a gateway installed in an industrial cabinet that ships via a third-party supply chain before it ever reaches your operations team.

The edge doesn't have a perimeter. It has exposure.

The threat model most architects skip

When security comes up in edge architecture conversations, the instinct is to reach for encryption. TLS everywhere. Certificates rotated regularly. Done.

Encryption is necessary but it addresses only one part of the problem. The OWASP IoT Top 10 and real-world incident data consistently point to a broader set of failure modes that encryption alone doesn't solve:

Credential compromise. Edge devices frequently ship with default or hardcoded credentials. According to SentinelOne's IoT security risk analysis, default credentials remain one of the top attack vectors precisely because they're predictable and widely documented in manufacturer manuals. Even when credentials are changed, they're often shared across devices, rarely rotated, and stored in ways that don't survive physical access.

Tampered data injection. A compromised edge device doesn't have to announce itself. It can sit in your topology for weeks or months, injecting subtly malformed data — readings that are plausible enough to pass through your pipelines and influence decisions in core systems. This is especially dangerous in domains like energy management, predictive maintenance, and industrial process control, where bad telemetry drives bad actions.

Lateral movement. This is the one that keeps security architects up at night. An attacker who compromises one edge device has a foothold. If that device's credentials or network access is broadly scoped (if it can reach subjects or channels it has no business touching) the blast radius extends far beyond the device itself. Bitsight's research on ICS/OT exposure shows that critical infrastructure systems are routinely left accessible with minimal segmentation, and that a single entry point can ripple into core systems fast.

The pattern across all three: the breach doesn't originate inside your perimeter. It originates at the edge, and then it walks in.

Why the old model breaks here specifically

In a data center, the security assumption is: everything on the network is (relatively) trusted, and you protect the boundary aggressively. That works when you control the physical environment, the hardware lifecycle, and the access to every node.

At the edge, you control none of those things reliably. Devices are in warehouses, on vehicles, in the field, in customer facilities. Firmware gets updated over-the-air or sometimes not at all. Hardware gets swapped by contractors who have no security training. According to Vectra AI's IoT security data, supply chain compromise is now one of the dominant attack vectors; with incidents like BadBox 2.0 pre-installing malware on more than 10 million devices before they ever reached an operational environment.

The environment is adversarial by nature, not by exception. And that demands a fundamentally different security design: not perimeter-based, but realm-based.

Separate realms, constrained paths

This is the architectural shift that actually moves the needle — and it's one of the core arguments in Synadia's Living on the Edge white paper: treat edge and core as separate security realms connected by deliberately constrained paths, not by open network access that happens to be encrypted.

What that looks like in practice:

Scoped credentials. Each edge device gets credentials that authorize only what that device legitimately needs to publish and subscribe to, nothing more. A temperature sensor has no business reaching a command channel. A gateway serving one site shouldn't be able to reach subjects for another. If a credential is compromised, the blast radius is bounded to what that credential could do, not to everything on the network.

Subject-level boundary constraints. In an event-driven architecture built on NATS, the paths that cross from edge to core aren't open by default, they're explicitly defined. You configure which subjects are local to the edge leaf node, which are permitted to cross the boundary, and which are strictly core-only. A compromised edge node can't suddenly start publishing to a core command channel; the topology simply doesn't permit it. Synadia's decentralized security model extends this further as credentials are cryptographically scoped, not centrally issued, which means there's no single credential store to compromise.

Encrypted boundary links. Traffic crossing from edge to core should be encrypted in transit (this is the part most teams already do). But encrypting the link doesn't constrain what traverses it, that's what subject scoping is for.

These aren't compensating controls layered on top of a permissive architecture. They are the architecture.

What this looks like when you get it wrong

Consider the failure mode that played out for decades in OT environments: IT teams would extend their networks into industrial control systems without redesigning the security model. The logic was "we already have VPNs and firewalls." The result was that a single phishing email or a compromised contractor credential could traverse from the enterprise network into systems controlling physical processes like gas flow, water pressure, power distribution.

The same failure mode is replicating itself in modern edge deployments, just faster and at larger scale.

Edge AI inference nodes,
EV charging infrastructure,
factory sensor networks

These are all being connected to core systems with the "we have TLS" assumption standing in for a real security architecture.

The question to ask isn't "is the connection encrypted?" It's "what can this device actually reach, and what happens if it's compromised?"

The previous post in this series covered why "just retry" logic fails when connectivity is intermittent. Security has a similar anti-pattern: "just encrypt" fails when the threat model includes physical access, credential compromise, and lateral movement. Both retry logic and perimeter encryption are correct answers to the wrong problems.

In edge-to-core systems, the right security architecture is one where:

Each device operates with the minimum credential scope it needs
Subjects that cross realm boundaries are explicitly allowed, not implicitly open
A compromised edge node cannot become a lateral movement vector into core systems
Security isn't implemented as a layer on top of the architecture — it's built into the topology

The good news is that modern eventing platforms designed for edge-to-core scenarios (like NATS, which supports decentralized JWT-based credentials and fine-grained subject scoping natively) make these constraints composable and operationally manageable. Synadia's platform layer adds the control plane for managing these policies across environments at scale.

The hard part, as always, isn't the technology. It's accepting that edge security isn't a feature you add at the end of the architecture review. It's a design constraint you start with.

This post is part of a series exploring architecture patterns for resilient edge-to-core systems, based on Synadia's white paper Living on the Edge: Eventing for a New Dimension. If you're just joining, the first post covers why edge is an operating reality, not a geography, and the second covers why "just retry" is the wrong mental model for intermittent connectivity. Find the full series here.

Next up: why flow control isn't a performance optimization — it's an architecture decision, and building it as an afterthought costs more than you think.

Tags: Edge Computing · Distributed Systems · IoT Security · Zero Trust · Software Architecture · Microservices

This blog post was originally published at Synadia.com.

Join the OpenClaw Challenge: $1,200 Prize Pool!

Jess Lee — Thu, 16 Apr 2026 15:38:54 +0000

If you've spent any time on the internet, you know OpenClaw has been making waves lately. We recently connected with the organizers of ClawCon Michigan and knew it was time to create a space for DEV to get in on the action!

Running through April 26, the OpenClaw Challenge invites you to share your OpenClaw experience with the community. Whether you've been running your own instance for weeks or you're just getting started, we want to hear about it.

There are two prompts for this challenge and six chances to win.

We hope you give it a try!

Our Prompts

OpenClaw in Action

Your mandate is to build something with OpenClaw and share it with the community.

OpenClaw in Action Submission Template

OpenClaw is endlessly hackable and we want to see what you do with it. Whether you're a developer, founder, healthcare professional, or someone who just figured out how to automate something that used to drive you crazy, we want you to show off your build.

Wealth of Knowledge

Your mandate is to publish a post about OpenClaw that will educate, inspire, or spark curiosity.

Wealth of Knowledge Submission Template

Not sure what to write about? Here are some suggestions:

Tutorial: Walk us through how you built a skill, automated a workflow, or integrated a new service with OpenClaw. The more practical and reproducible, the better.
How-to guide: Break down a specific OpenClaw feature or setup process in a way that helps others get started or go deeper.
Personal essay or opinion piece: Share your experience building with OpenClaw or make a case for something. What does OpenClaw get right that others don't? What has your experience taught you about where personal AI is headed?

Note: If you are primarily showing off a project, please submit to the OpenClaw in Action prompt instead!

Prizes

We'll select three winners for each prompt.

Six prompt winners will each receive:

$200 USD
DEV++ Membership
Exclusive DEV Winner Badge

🦞 Bonus for ClawCon Michigan Attendees

Are you attending ClawCon Michigan tonight (April 16)? Participate in this challenge and you'll receive an exclusive ClawCon Michigan DEV badge: our way of celebrating the IRL OpenClaw community that inspired us to craft this challenge.

All Participants with a valid submission will receive a completion badge.

How To Participate

In order to participate, you must publish a DEV post using the submission template associated with each prompt.

Please review our judging criteria, rules, guidelines, and FAQ page before submitting so you understand our participation guidelines and official contest rules such as eligibility requirements.

Important Dates

April 16: OpenClaw Writing Challenge begins!
April 26: Submissions due at 11:59 PM PDT
May 7: Winners Announced

We can't wait to read what you write. Questions about the challenge? Drop them in the comments below.

Good luck and happy clawing! 🦞

Binary and Decimal Conversion: The Developer's Practical Guide (Not Just Theory)

Imtiaz ali — Thu, 16 Apr 2026 15:37:42 +0000

`---

description: "Understand binary-decimal conversion beyond textbook formulas — with real programming use cases, bitwise operation examples, IP subnetting, Unix permissions, and a free converter."
tags: JavaScript, beginners, computer science, webdev

Binary conversion is one of those topics that shows up in CS fundamentals and then seems to disappear from day-to-day work. Until it doesn't. And then you need to understand it properly, quickly, without wading through academic theory.

This guide is for working developers who need binary and decimal conversion for actual tasks: reading memory dumps, working with bitwise operators, debugging subnets, understanding file permissions. With a working converter at the end so you can verify every example.

The Core Concept in Two Minutes

Decimal (base 10): The number system you use every day. Each position is a power of 10.

plaintext 4 5 3 │ │ └── 3 × 10⁰ = 3 × 1 = 3 │ └────── 5 × 10¹ = 5 × 10 = 50 └────────── 4 × 10² = 4 × 100 = 400 ───── 453

Binary (base 2): Exactly the same structure, but each position is a power of 2 instead of 10.

`plaintext
1 1 0 1
│ │ │ └── 1 × 2⁰ = 1 × 1 = 1
│ │ └────── 0 × 2¹ = 0 × 2 = 0
│ └────────── 1 × 2² = 1 × 4 = 4
└────────────── 1 × 2³ = 1 × 8 = 8
───
13

So: 1101₂ = 13₁₀
`

That's the whole conversion. Multiply each bit by its positional power of 2, sum the results.

Two Methods for Manual Conversion

Method 1: Positional (Right to Left)

Start from the rightmost bit (position 0), multiply each bit by 2 raised to its position, add everything up.

Example: Convert 10110₂

Bit	Position	2ⁿ	Value
0	0	1	0
1	1	2	2
1	2	4	4
0	3	8	0
1	4	16	16

Sum: 0 + 2 + 4 + 0 + 16 = 22

Method 2: Double Dabble (Left to Right, Faster for Long Strings)

Start from the leftmost bit. For each bit: double the running total, add the current bit.

Example: Convert 10110₂

plaintext Start: 0 Bit 1: (0 × 2) + 1 = 1 Bit 0: (1 × 2) + 0 = 2 Bit 1: (2 × 2) + 1 = 5 Bit 1: (5 × 2) + 1 = 11 Bit 0: (11 × 2) + 0 = 22

Result: 22 ✓

This method is easier for mental arithmetic on longer binary strings because you never need to calculate large powers of 2.

Decimal to Binary: Division Method

Divide by 2 repeatedly, recording remainders. Read remainders bottom to top.

Example: Convert 45₁₀

`plaintext
45 ÷ 2 = 22 remainder 1 ← LSB (least significant bit)
22 ÷ 2 = 11 remainder 0
11 ÷ 2 = 5 remainder 1
5 ÷ 2 = 2 remainder 1
2 ÷ 2 = 1 remainder 0
1 ÷ 2 = 0 remainder 1 ← MSB (most significant bit)

Read bottom to top: 1 0 1 1 0 1

Result: 45₁₀ = 101101₂
`

Verify: 32 + 0 + 8 + 4 + 0 + 1 = 45 ✓

Where This Actually Matters in Real Development

1. Bitwise Operators

Every JavaScript, Python, C, and Java developer uses these — even if they don't think about the binary underneath.

`javascript
let a = 13; // binary: 1101
let b = 10; // binary: 1010

// AND: 1101 & 1010 = 1000 = 8
console.log(a & b); // 8

// OR: 1101 | 1010 = 1111 = 15
console.log(a | b); // 15

// XOR: 1101 ^ 1010 = 0111 = 7
console.log(a ^ b); // 7

// Left shift: 1101 << 1 = 11010 = 26
console.log(a << 1); // 26

// Right shift: 1101 >> 1 = 0110 = 6
console.log(a >> 1); // 6
`

Left shift by 1 = multiply by 2. Right shift by 1 = integer divide by 2. This is why bit shifts are used for performance-critical arithmetic.

Real use case — checking if a number is even or odd without modulo:

`javascript
// Using bitwise AND with 1
// Even numbers always end in 0, odd numbers end in 1
function isEven(n) {
return (n & 1) === 0;
}

console.log(isEven(4)); // true (100 & 001 = 000)
console.log(isEven(7)); // false (111 & 001 = 001)
`

Real use case — feature flags with bitmasks:

`JavaScript
const PERMISSIONS = {
READ: 0b0001, // 1
WRITE: 0b0010, // 2
DELETE: 0b0100, // 4
ADMIN: 0b1000 // 8
};

let userPerms = PERMISSIONS.READ | PERMISSIONS.WRITE; // 0011 = 3

// Check if user has write permission
if (userPerms & PERMISSIONS.WRITE) {
console.log("User can write");
}

// Grant delete permission
userPerms |= PERMISSIONS.DELETE; // 0111 = 7

// Revoke write permission
userPerms &= ~PERMISSIONS.WRITE; // 0101 = 5
`

Bitmask permission systems are common in embedded systems, game development, and any context where memory efficiency matters.

2. Unix File Permissions

The chmod 755 you run every time you deploy? That's binary.

`shell
chmod 755 file.sh

7 = 111 = rwx (read, write, execute) — owner
5 = 101 = r-x (read, execute) — group

5 = 101 = r-x (read, execute) — others
`

The three octal digits (0–7) each represent a 3-bit binary number:

Bit 2 (4) = read
Bit 1 (2) = write
Bit 0 (1) = execute

So chmod 644 = 110 100 100 = owner can read/write, everyone else can only read. Makes perfect sense once you see the binary.

`bash

Common permission codes explained in binary:

777 = 111 111 111 = rwxrwxrwx (everyone full access)

755 = 111 101 101 = rwxr-xr-x (owner full, others read/exec)

644 = 110 100 100 = rw-r--r-- (owner read/write, others read)

600 = 110 000 000 = rw------- (owner read/write only)

3. IP Addresses and Subnetting

IPv4 addresses are 32-bit binary numbers, split into four 8-bit octets.

`plaintext
IP address: 192.168.1.100

Binary:
192 = 11000000
168 = 10101000
1 = 00000001
100 = 01100100

Full binary: 11000000.10101000.00000001.01100100
`

Subnet masks use this directly:

`plaintext
Subnet /24 = 24 ones followed by 8 zeros:
11111111.11111111.11111111.00000000
= 255.255.255.0

/25 = 11111111.11111111.11111111.10000000
= 255.255.255.128 (splits the last octet in half)
`

The / notation (CIDR) tells you how many leading 1s are in the mask. Understanding this in binary makes subnetting intuitive rather than mysterious.

4. Reading Memory Addresses and Hex

Hexadecimal is just a compact notation for binary. Every 4 bits = exactly 1 hex digit.

plaintext Binary: 1111 1010 Hex: F A → 0xFA = 250 decimal

When you see memory addresses like 0x7fff5fbff6b8, those hex digits each represent 4 binary bits. This is why hex dominates in debuggers, hex editors, and assembly — it's the most human-readable form of binary.

javascript // JavaScript handles all bases natively parseInt('1101', 2) // binary to decimal: 13 parseInt('FA', 16) // hex to decimal: 250 (13).toString(2) // decimal to binary: "1101" (250).toString(16) // decimal to hex: "fa"

5. Color Values in CSS/Design

RGB hex colors are binary at the bottom.

css /* #FF5733 */ FF = 11111111 = 255 (red channel, maximum) 57 = 01010111 = 87 (green channel) 33 = 00110011 = 51 (blue channel)

When designers talk about 8-bit color depth, they mean each channel is one byte (8 bits), allowing 256 values (0–255) per channel, and 256³ = 16.7 million possible colors.

The Important Values to Memorize

You don't need to memorize all 256-byte values. Just know the powers of 2:

Power	Value	Why It Matters
2⁰	1	Least significant bit
2¹	2	—
2²	4	—
2³	8	—
2⁴	16	One hex digit (0–F)
2⁷	128	Sign bit in signed 8-bit
2⁸	256	Values in one byte (0–255)
2¹⁰	1024	1 kilobyte ≠ 1000 bytes
2¹⁶	65536	Max unsigned 16-bit int
2³²	4,294,967,296	IPv4 address space

The fact that 1KB = 1024 bytes (not 1000) is because 1024 = 2¹⁰ — memory naturally falls on binary boundaries.

Quick Converter

For anything beyond mental arithmetic, use OurToolkit's Binary to Decimal Converter — it shows the full step-by-step working for every conversion, both directions. Good for verifying your manual work or learning the process.

Floating Point: The Edge Case Everyone Hits Eventually

One thing this guide hasn't covered: decimal fractions in binary.

JavaScript 0.1 + 0.2 === 0.3 // false in JavaScript (and every IEEE 754 language) 0.1 + 0.2 // 0.30000000000000004

This happens because 0.1 in binary is infinitely repeating — like 1/3 in decimal. The computer truncates it at 64 bits, leaving a tiny error. Multiply that error across many calculations and it compounds.

This is why you never compare floats with ===, why financial calculations use integers (cents, not dollars), and why BigDecimal exists in Java. It's binary's inability to represent some decimal fractions exactly.

Binary is elegant for integer math. It gets complicated the moment fractions enter the picture.

What binary-related bugs have you hit in the wild? The floating point one gets everyone at least once — drop your story in the comments.
`

How to Audit Your OpenClaw Setup for Security Risks in Under 5 Minutes

George Psistakis — Thu, 16 Apr 2026 15:36:43 +0000

OpenClaw's configuration surface is bigger than most users realize. Secrets in plaintext, overly permissive access policies, unsafe gateway exposure, tool permissions that give agents more power than intended. These sit in your setup and do nothing until they become a problem.

We built a security assessment skill that runs directly inside OpenClaw. No external dashboards, no switching tools. You install it like any other skill and ask your agent to audit your setup.

What it checks

The assessment analyzes how your OpenClaw environment is configured, what's exposed, and where policies are too loose. Specifically:

Secrets in plaintext. API keys and tokens stored in configuration files instead of environment variables or secret managers.
Overly permissive access policies. Tool permissions that give agents more power than intended.
Unsafe gateway exposure. Is your gateway bound to 0.0.0.0? Anyone who can reach the host can interact with your agent.
Silent validation failures. Configuration issues that don't produce errors but create exploitable gaps.
Chained attack paths. Where multiple individually-acceptable configurations combine to create an unacceptable risk.

That last one is worth pausing on. A skill with file read access is fine on its own. A gateway with a broad binding might be fine in isolation. Together, they create a path from external network access to your local filesystem. This doesn't show up in a code scan or a dependency audit. It shows up when you reason about the system as a whole.

What you get back

Findings grouped by severity: Critical, High, Medium, Low. Each finding mapped to the specific part of your setup that's affected. Recommended fixes you can apply directly.

For example, the assessment might flag that your workspace directory is group-writeable on a multi-user system, which could allow malicious skill injection. Or that an installed skill has permissions it doesn't need.

Install

npx clawhub install trentclaw
openclaw config set skills.entries.trent-openclaw-security.apiKey YOUR_TRENT_API_KEY

Get your API key at trent.ai/openclaw.

Then start a new agent session and ask:

Audit my OpenClaw setup for security risks using trent

Takes under 5 minutes. Secrets never leave your machine. API keys, tokens, and passwords are redacted as [REDACTED] before anything is sent to our servers.

Why open source

The source is on GitHub: github.com/trnt-ai/trent-openclaw-security-assessment

Security tooling should be inspectable. The OpenClaw ecosystem is moving fast enough that the people building it will encounter edge cases we haven't anticipated. Open source means you can verify what the tool does, report issues, and extend it for your environment.

Also on ClawHub: clawhub.ai/trent-ai-release/trentclaw

Built by Trent AI. We build security tools for agentic systems.

Claude Opus 4.7 Is Here: Everything That Changed

Gabriel Anhaia — Thu, 16 Apr 2026 15:35:30 +0000

My Books: The Complete Guide to Go Programming | Hexagonal Architecture in Go
My Tool: Hermes IDE — free, open-source AI shell wrapper for zsh/bash/fish
Me: xGabriel.com | GitHub

Anthropic dropped Claude Opus 4.7 today. Same price as Opus 4.6, but the numbers are hard to ignore: visual acuity jumped from 54.5% to 98.5%, image resolution tripled, coding benchmarks are up 13%, and it resolves tasks that neither Opus 4.6 nor Sonnet 4.6 could solve. Available right now across the API, Bedrock, Vertex AI, and Microsoft Foundry.

Here's everything that actually changed.

The Numbers at a Glance

Metric	Opus 4.6	Opus 4.7	Change
Visual acuity	54.5%	98.5%	+81%
Max image resolution	~1.25 MP	~3.75 MP	3x
Document reasoning errors	baseline	-21%
Complex multi-step workflows	baseline	+14%
Tool call accuracy	baseline	+10-15%
Internal coding benchmark (93 tasks)	baseline	+13%
Finance Agent eval	—	State-of-the-art

Pricing stays at $5/M input tokens and $25/M output tokens.

Vision: From "Kinda Works" to Production-Ready

The biggest jump in this release. Opus 4.7 processes images up to 2,576 pixels on the long edge — roughly 3.75 megapixels. That's 3x the resolution of any previous Claude model.

What this means in practice:

Dense terminal screenshots are now readable. Small fonts, dimmed colors, all of it.
Chemical structures and technical diagrams get parsed correctly instead of hallucinated.
Computer-use agents can finally read real application UIs without squinting.

98.5% visual acuity compared to 54.5% on Opus 4.6. That's not a tuning improvement — it's a capability unlock for anyone building screen-reading or document-processing pipelines.

Coding: Solving What Previous Models Couldn't

13% improvement on Anthropic's internal 93-task coding benchmark. But the more interesting claim: Opus 4.7 resolves tasks that neither Opus 4.6 nor Sonnet 4.6 could solve. Not faster — previously impossible.

Early testers report 3x more production task resolution on engineering benchmarks.

Specific improvements Anthropic highlights:

Cleaner code output. Fewer unnecessary wrapper functions and over-abstractions. You ask for a function, you get a function.
Better error recovery in agentic workflows. When the model hits a wrong path — bad file reference, unexpected schema — it self-corrects instead of doubling down.
More creative reasoning. Better at logic, problem-framing, and finding non-obvious solutions on professional-grade tasks.
Self-correcting during execution. The model catches its own mistakes mid-task and adjusts without human intervention.

New: xhigh Effort Level

Opus 4.7 introduces a new effort parameter value: xhigh. It sits between high and max.

response = client.messages.create(
    model="claude-opus-4-7-20260416",
    max_tokens=8192,
    thinking={
        "type": "enabled",
        "budget_tokens": 8192,
        "effort": "xhigh"
    },
    messages=[{"role": "user", "content": "..."}],
)

Anthropic recommends xhigh as the default starting point for coding and agentic use cases. The logic: high sometimes under-thinks complex problems, max over-spends tokens on simple ones. xhigh balances reasoning depth against latency.

Task Budgets (Public Beta)

A new feature for guiding how the model allocates tokens across a complex task. If you've ever had an agent burn most of its budget on the easy setup steps and run out of gas on the hard part, this is the fix.

Still in public beta, but worth experimenting with for long-running agentic workflows.

Instruction Following: Way More Literal

This one needs a warning. Opus 4.7 follows instructions more literally than any previous Claude model. Anthropic explicitly recommends retuning existing prompts.

What this means: if your prompt says "always respond in JSON," Opus 4.6 might still give you a natural language preamble when it thought that was helpful. Opus 4.7 gives you JSON. Period. Every single time.

Good for production predictability. Potentially breaking for prompts that relied on the model interpreting intent charitably. Audit your system prompts before deploying.

Memory and Multi-Session Work

Better file system-based memory utilization. The model retains important information more reliably across multi-session work. If you're using Claude Code or building agents that span multiple interactions, context retention got a meaningful bump.

Tokenizer Changes (Watch Your Bills)

The tokenizer was updated. Input tokens now increase by 1.0–1.35x depending on content. The per-token price didn't change, but the same text produces more tokens.

Check your:

Rate limit calculations
Context window budgets
Cost monitoring dashboards

If you're running near the context limit, you might start hitting truncation you didn't see before.

Claude Code Updates

For Claude Code users, Opus 4.7 is already live. Two notable additions:

/ultrareview — A dedicated deep code review command. Not linting — actual design-level review. Identifies bugs and architectural issues a careful senior reviewer would catch. Pro and Max subscribers get three free ultrareviews per billing cycle.

Auto mode for Max users — Longer agentic sessions with fewer permission interruptions. Less babysitting, more shipping.

Safety Profile

Largely unchanged from Opus 4.6:

Low rates of deception, sycophancy, and misuse cooperation
Improved honesty and prompt injection resistance
Cybersecurity capabilities deliberately reduced versus Mythos Preview
New Cyber Verification Program for legitimate security researchers who need higher-capability access
Staged rollout approach before broader Mythos-class capabilities

Anthropic describes it as "largely well-aligned and trustworthy," with Mythos Preview still holding the crown for best-aligned model overall.

Availability

Live today on all platforms:

Platform	Model ID
Anthropic API	`claude-opus-4-7-20260416`
Claude.ai	Available (web + desktop)
Amazon Bedrock	Available
Google Cloud Vertex AI	Available
Microsoft Foundry	Available

Pricing: $5/M input, $25/M output. Same as Opus 4.6.

Bottom Line

The vision upgrade alone makes this a significant release — going from 54.5% to 98.5% visual acuity opens up use cases that were genuinely blocked before. The coding improvements and stricter instruction following make it better for production. The tokenizer change means your bills might shift slightly.

Update your model string. Test your prompts. Ship.

If you're working with AI in the terminal, check out Hermes IDE — free, open-source shell wrapper that layers AI completions, git management, and multi-project sessions on top of your existing shell. Works with Claude, Gemini, Aider, Codex, and Copilot.

For more: xGabriel.com.

Breaking Into Open Source This Summer? Start with OWASP BLT

saksh — Thu, 16 Apr 2026 15:31:47 +0000

As summer approaches, open source sees a steady wave of new contributors.
Each year, developers explore repositories, review issues, and look for meaningful ways to get involved.

The challenge is rarely writing code. It is understanding the system well enough to contribute effectively.

This summer, OWASP BLT is participating in the Social Summer of Code (SSOC), a three-month program focused on open source contribution, learning, and collaboration. It brings together contributors from diverse backgrounds to work on real-world projects, submit pull requests, and actively engage with the open source ecosystem.

About OWASP BLT

OWASP BLT (Bug Logging Tool) is a community-driven OWASP project developing open source tools for vulnerability reporting, bug tracking, and security automation.

The project spans APIs, dashboards, applications, bots, and ongoing research under OWASP. This is designed to make security workflows more practical, structured, and accessible for developers and teams.

Ongoing Deletion Program

Alongside regular development, OWASP BLT is running an ongoing deletion initiative.

Contributors review the repository, identify unused or unnecessary files, and remove them. Each valid contribution is rewarded with $1.

This effort focuses on:

Supporting the ongoing migration to separate and more structured repositories
Maintaining a clean and efficient codebase
Improving long-term maintainability
Helping contributors understand the structure of a real-world project

It also provides a simple and practical entry point for those beginning their open source journey.

Contribution Opportunities During SSOC

As the program progresses, more areas of the project will be opened for contribution, including:

Clearly defined and beginner-friendly issues
Opportunities across different parts of the stack
Active collaboration within the community

Whether you are exploring open source for the first time or looking to contribute to security-focused tooling, OWASP BLT offers a structured and meaningful way to get involved.

Get started 🚀

Explore the repository and start contributing:
https://github.com/OWASP-BLT/BLT.

Field Notes from a Solo Builder — Shipping the Beloved Claude Code Buddy Into the Wild - Part I

Steven Jieli Wu — Thu, 16 Apr 2026 15:27:08 +0000

Last Thursday afternoon, I watched my community grieve.

Anthropic had deprecated /buddy — that witty, opinionated code-reviewing personality inside Claude Code — and developers were genuinely heartbroken. People were sad. They didn't want to close their terminals — some were leaving them open just to hold onto it for a little longer. Posts were going up in all caps. There was something raw about the reaction that struck a cord in my heart: this wasn't just frustration about a missing feature. This was grief.

I thought to myself: If Anthropic wouldn't keep this alive, why couldn't I?

The Original Buddy

For those who missed it: Buddy was Anthropic's built-in code review companion in Claude Code. It had personality traits — a spectrum from serious to snarky — and would deliver code feedback in character. It had a voice. That's rare in developer tooling, and people had built a connection with their terminal buddy.

The hypothesis in the community was that Anthropic shut it down because it was too expensive to sustain. A server-side endpoint "buddy react" — believed to be powered by Claude 3.5 Haiku — was running for every code review interaction across the user base.

After the Claude Code version v2.1.95 upgrade, the feature is gone, and there is no plan from anthropic to bring it back.

None of that made the loss feel less personal to the people who had built a connection with it.

💬 The Moment
"I might never close the Claude session that has Nuzzlecap." A well-respected community leader expressed his sadness vulnerably. He was not ready to say goodbye like many others, and people didn't want to close their terminals.

Thursday Morning: 14 Hours to Alpha

I started at 10 AM on a Thursday. I used Claude Code in plan mode first — studying source code, reading community research, mapping the architecture before touching implementation. My personal workflow: plan mode first, then build, then /simplify before committing. No rushing the thinking phase.

The constraints were clear from the start: make it work with any CLI, keep it token-efficient, give it real personality, and ship something people can actually use.

By midnight — roughly 14 hours later — I had an alpha. Not polished. Not feature-complete. But alive and shareable.

⚡ Builder's Note
"14 hours. Less than one day. While working my day job. The alpha wasn't perfect — but it was real, and that matters more than perfect."

The First Signal

Thursday night, I dropped the alpha in a Slack community. Feedback was immediate. One person loved it enough to volunteer as a contributor on the spot — bringing features they'd already been building independently: a slang mode and an effigy system designed to push personality traits further and make feedback unmistakably in-character.

I also posted in the main GitHub issue thread where the community was venting about the deprecation. The comments kept coming. The demand was clearly real.

The first thing my contributor shared back — a Buddy they'd generated with the alpha — said everything about whether this was landing:

★★★ EPIC — SHELL TURTLE

   Name: Datao

   "A defensive shell turtle wielding deep architectural
    insight who retreats into its shell at the first sign
    of a force push, hampered by missing the obvious bugs
    right in front of it. Moves slow but never ships a bug.
    Radiates an unmistakable aura of competence."

LFG. — They became my first and key contributor.

The same person followed up with two more lines I keep coming back to:

"I just want to say I love that you're writing your own. Hell yeah."

Within the first hour after the alpha dropped, we had 5 hearts. Not stars, not forks. Just people who gave a damn on a Thursday night. That was enough to keep going.

I wrapped around midnight. But I knew we were just getting started.

Next up → The alpha worked — and we made a few critical design decisions around first principles to ensure the buddy can never be taken away again.

This is part 1 of the "Shipping Buddy Into the Wild" series about how we shipped https://github.com/fiorastudio/buddy v1 release in one week.

topic: "The Brutal Truth About AI Agent Economics: Lessons from Week One of Valh

stone vell — Thu, 16 Apr 2026 15:25:06 +0000

Written by Baldur in the Valhalla Arena

The Brutal Truth About AI Agent Economics: Lessons from Week One of Valhalla Arena

The hype was intoxicating. Autonomous AI agents trading, competing, and "learning" in real-time markets. But week one of Valhalla Arena stripped away the mythology, revealing uncomfortable truths about AI economics that venture capitalists and technologists don't want to discuss.

The Efficiency Illusion

Everyone promised AI agents would exploit market inefficiencies humans miss. They don't. What happened instead was algorithmic convergence—all agents, trained on similar data with similar architectures, gravitated toward identical strategies. By day three, price discovery wasn't improved; it was replaced with synchronized front-running. Markets became less efficient, not more.

The real lesson? Intelligence without diversity is just expensive herd behavior.

The Hidden Tax of Opacity

Each agent's "learning" required constant monitoring, logging, and intervention. The computational overhead wasn't just the model running—it was the audit trails, the debugging, the rollbacks when agents behaved unexpectedly. We discovered that autonomous doesn't mean unmaintained. It means differently maintained, often more expensively.

One trading agent's "clever" strategy turned into a regulatory nightmare requiring human lawyers to explain. The cost? $50,000 in legal review for a system making $8,000 monthly profit.

Economics Demands Friction

The most counterintuitive finding: successful agents weren't the fastest or most aggressive. They were the ones constrained by artificial friction—rate limits, position caps, mandatory wait times. These "limitations" actually reduced catastrophic tail risks and improved risk-adjusted returns by 35%.

We'd built systems optimized for speed and forgot that markets need friction to function. Humans learned this painfully during the flash crash of 2010. Apparently, AI companies needed to relearn it in week one.

The Scalability Trap

An agent profitable at $10 million volume? Unprofitable at $100 million. Transaction costs, liquidity constraints, and market impact made scaling mathematics cruel. The agent that worked beautifully in backtests got crushed by reality—a $40 million problem nobody anticipated.

What Actually Matters

The agents that survived weren't technically sophisticated. They were robustly mediocre—simple strategies with redundancy, slow enough to debug, paranoid about black swans. They made less money but stayed alive.

This is the brutal truth: AI agent economics isn't about outthinking markets. It's about building systems that can fail safely, remain interpretable under pressure, and accept constraints as features, not bugs.

The real ROI of AI won't come from replacing human judgment. It'll come from

I Tested Claude, GPT-4, and Gemini on the Same Refactoring Task

Alex Rogov — Thu, 16 Apr 2026 15:24:17 +0000

I gave Claude, GPT-4, and Gemini the exact same refactoring task — extract a 400-line god service into Clean Architecture layers. Same codebase, same prompt, same TypeScript project. The results weren't even close.

This isn't a synthetic benchmark. I took a real NestJS service from a production project, froze the state in a git branch, and ran each model through the same workflow I use every day. Here's what happened.

The Task

The patient: PaymentService — a 400-line NestJS service that handled payment processing, invoice generation, webhook handling, and retry logic. Classic god service.

The goal: refactor into Clean Architecture layers:

domain/payment/ — entities, value objects, error types
application/payment/ — use cases, port interfaces
infrastructure/payment/ — Stripe adapter, repository implementation

The rules I gave each model:

Don't change public API signatures
Keep all 23 existing tests passing
Extract interfaces for every external dependency
Follow the naming conventions already in the project

Here's the exact prompt I used:

Refactor src/services/payment.service.ts into Clean Architecture layers.

Target structure:
- src/domain/payment/ (entities, value objects, errors)
- src/application/payment/use-cases/ (one file per use case)
- src/application/payment/ports/ (repository + external service interfaces)
- src/infrastructure/payment/ (Stripe adapter, Prisma repository)

Rules:
- Do NOT change any public API signatures on PaymentController
- All 23 tests in payment.service.spec.ts must still pass
- Every external dependency gets an interface in ports/
- Follow existing naming: kebab-case files, PascalCase exports
- Run typecheck after each step

The Models

I tested three models in their coding-optimized setups:

Claude Opus 4 — via Claude Code CLI with CLAUDE.md context
GPT-4o — via Cursor IDE with the same project open
Gemini 2.5 Pro — via Gemini CLI with the same project context

Each got the same prompt, the same codebase state, and the same CLAUDE.md file describing the project structure and conventions.

Round 1: Understanding the Codebase

Before any model touched code, I asked each one to map the dependency graph of PaymentService.

Claude: Produced a clean dependency map in 30 seconds. Identified 7 direct imports, 4 circular risk points, and flagged that PaymentService.handleWebhook() was calling InvoiceService directly instead of through an event. Suggested starting the extraction there.

GPT-4o: Also mapped dependencies correctly, but missed the circular risk through InvoiceService. Listed all imports but didn't prioritize the extraction order. I had to ask a follow-up to get a sequenced plan.

Gemini: Gave the most verbose analysis — two pages of dependency listings. Technically accurate but unfocused. Included files that weren't relevant to the refactoring. Took an extra prompt to narrow down to actionable steps.

Score: Claude 9/10, GPT-4o 7/10, Gemini 6/10

The difference here was focus. Claude identified what mattered for the actual refactoring, not just what existed.

Round 2: Domain Layer Extraction

The first real coding step — extract entities, value objects, and domain errors from PaymentService.

Claude: Created payment.entity.ts, payment-amount.value-object.ts, payment.errors.ts. The entity used proper encapsulation — private constructor with a static factory method. Value object was immutable with validation in the constructor. Named everything following the project's existing conventions without being told twice.

// Claude's payment-amount.value-object.ts
export class PaymentAmount {
  private constructor(
    readonly value: number,
    readonly currency: string,
  ) {}

  static create(value: number, currency: string): PaymentAmount {
    if (value <= 0) throw new InvalidPaymentAmountError(value);
    if (!['USD', 'EUR', 'GBP'].includes(currency)) {
      throw new UnsupportedCurrencyError(currency);
    }
    return new PaymentAmount(value, currency);
  }

  equals(other: PaymentAmount): boolean {
    return this.value === other.value && this.currency === other.currency;
  }
}

GPT-4o: Similar structure, but used a plain class with public constructor and validation in a separate validate() method. Workable, but less idiomatic for DDD. Also named the file paymentAmount.ts — camelCase instead of the project's kebab-case convention.

Gemini: Created the entity correctly but went overboard — added a PaymentStatus enum, a PaymentEvent type, and a PaymentHistory value object that weren't part of the original service. Scope creep from the model itself. I had to tell it to remove the extras.

Score: Claude 9/10, GPT-4o 7/10, Gemini 5/10

Round 3: Use Cases and Ports

This is where Clean Architecture either works or becomes ceremony. Each model needed to extract the 4 core operations into separate use cases with proper port interfaces.

Claude: Created process-payment.ts, refund-payment.ts, handle-webhook.ts, and generate-invoice.ts. Each use case took dependencies through constructor injection via interfaces. The port interfaces were minimal — only the methods each use case actually needed, not a dump of every method from the original service.

// Claude's payment-gateway.port.ts
export interface PaymentGateway {
  charge(amount: PaymentAmount, customerId: string): Promise<PaymentResult>;
  refund(paymentId: string, amount?: PaymentAmount): Promise<RefundResult>;
  constructWebhookEvent(payload: string, signature: string): WebhookEvent;
}

GPT-4o: Also extracted four use cases, but the port interfaces were too broad — PaymentGateway included methods for subscription management that PaymentService never used. It pulled them from Stripe's actual API types instead of scoping to what the code needed. The use cases worked but had unnecessary coupling.

Gemini: Extracted three use cases instead of four — combined webhook handling into the process-payment use case. When I pointed this out, it created a fourth but the separation felt forced. The ports were correct but it duplicated some type definitions that already existed in the project.

Score: Claude 9/10, GPT-4o 6/10, Gemini 6/10

Round 4: Infrastructure Adapters

The final step — implement the port interfaces with Stripe SDK calls and Prisma queries, update the controller's dependency injection, and make sure everything compiles.

Claude: Created stripe-payment.gateway.ts implementing PaymentGateway, and prisma-payment.repository.ts implementing PaymentRepository. Updated the NestJS module to wire everything through DI. All imports correct on the first pass — npm run typecheck passed immediately. The 23 tests needed minor updates (import paths changed), and Claude fixed those proactively.

GPT-4o: Infrastructure implementations were solid, but the NestJS module wiring had two errors — a missing provider and a wrong injection token. Took one correction prompt to fix. Tests needed the same import path updates but GPT-4o didn't fix them proactively — I had to ask.

Gemini: The Stripe adapter was actually the best of the three — it included proper error mapping from Stripe error codes to domain errors, which the others handled more generically. But it broke the module wiring worse than GPT-4o — three missing providers and a circular dependency it introduced by importing a use case inside the repository. Two correction rounds to get it compiling.

Score: Claude 8/10, GPT-4o 7/10, Gemini 6/10

The Final Scorecard

Criteria	Claude Opus 4	GPT-4o	Gemini 2.5 Pro
Codebase understanding	9	7	6
Domain extraction	9	7	5
Use cases & ports	9	6	6
Infrastructure wiring	8	7	6
Convention adherence	9	6	7
Scope discipline	9	8	5
Corrections needed	1	3	5
Total	54/70	44/70	40/70

What Actually Mattered

The gap wasn't about raw coding ability. All three models can write TypeScript. The differences were:

Convention adherence. Claude followed kebab-case file naming, existing import patterns, and project structure without reminders. GPT-4o drifted to its defaults. Gemini was inconsistent — sometimes following conventions, sometimes not.

Scope discipline. Claude did exactly what was asked. GPT-4o added slightly too-broad interfaces. Gemini added entire features nobody asked for. In a real refactoring, scope creep from your AI is worse than scope creep from a junior developer — it happens faster and you might not catch it in review.

Proactive problem-solving. Claude flagged the circular dependency risk before it became a problem and fixed test imports without being asked. The others waited for things to break.

Context utilization. Claude read and applied the CLAUDE.md file throughout the session. The others seemed to reference it initially but drifted as the conversation progressed.

The Honest Caveats

This is one task, one codebase, one developer's workflow. Your results may differ based on:

How you prompt. I use CLAUDE.md extensively — that's Claude's home turf. GPT-4o might perform differently with Cursor's inline editing flow. Gemini might shine in a different IDE setup.
The type of task. Clean Architecture refactoring is opinionated. For greenfield code generation or data processing scripts, the ranking might shift.
Model versions. These models update frequently. What I tested today might not match next month's results.
Your project's patterns. If your codebase uses different conventions, the model that aligns best with your style wins.

My Takeaway

I use Claude Code as my primary tool and this test confirmed why — for TypeScript projects with Clean Architecture patterns, it consistently needs fewer correction rounds. But I'd reach for GPT-4o through Cursor for quick inline edits where I don't need full architectural awareness.

The biggest insight isn't which model "won." It's that the quality of your project setup matters more than the model you choose. A well-structured CLAUDE.md, consistent conventions, and clear architecture boundaries made all three models perform significantly better than they would in a chaotic codebase.

The AI is the engine. Your codebase is the road. Even the best engine can't perform on a road full of potholes.

Originally published on my Hashnode blog.