Along that line: I know that Lowe's, Home Depot, Chewy etc ship to me with speed matching or beating Amazon's (at least above a minimum purchase), so if what I'm buying is sold by those companies, Amazon does not get that sale.
Amazon is hugely anti-competitive, but their moat can be surprisingly shallow in some areas.
What Amazon has shown the rest of the industry is that shipping matters. Others are learning, at their own pace.
Yes, the uri spec must allow the host part to be empty. That's easily shown by remembering that file:/// URIs are commonly preceded by three slashes, so the spec must allow for that. Not sure where the brain was going with that.
> A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.
And it really is an empty host component, as RFC3986 section 3.2 specifically says:
> The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.
So yes, collapsing all those ////// into two really is illegal according to the spec -- but then again, the specs are mostly about network communication, so machine-to-machine. I consider a browser's url bar parsing to be more in the UX domain than in the technical domain.
So a shared-memory ringbuffer? Better make it clear that sender can perform TOCTOU attacks on the receiver. There seems to be a fuzz tester for the header, but the application logic would be the real target.
Exactly, the application logic is the target. Actually doing seccomp bpf base but for managed bindings (Java, Node, Go, ...) add a lot of complexity....
Perhaps it was more that risk taking and dying young from various illnesses was a thing that happened around you a lot, so you were more accustomed to it and didn't expect to live to 80.
None of the non-AWS copies of S3 implement exactly the S3 protocol. And even if they did, the next update -- coming at any arbitrary time -- would invalidate the full compatibility.
Fair correction. Wire-level copies don't even fully match, and upstream changes can invalidate whatever match exists. That's the weakness of wire-level duck typing. Contract-level compatibility doesn't fully solve the upstream changes problem (nothing does), but when you regenerate the OBI from an updated source spec, a compatibility check tells you structurally what changed. Wire-level clones find out by breaking.
The flip side is worth noting too. If you own the API and want to preserve contract compatibility, OBI lets you change your implementation (paths, payload shapes, even protocols) behind the same contract. Transforms bridge shape differences. Binding swaps change protocols. Consumers targeting the interface don't need to care.
Ad-hoc duck typing—“if it looks like a duck[…]”—is the only kind that exists! The point of the term “duck typing” is that it doesn’t require explicit declaration of the contract by implementers, it’s not synonymous with polymorphism or with interfaces in general. Haskell type classes are not duck typed, nor are Swift protocols; Go interfaces are.
OBI is a boilerplate generator for the adapter pattern for service communication; its contracts are just another set of their own paths, payload shapes, and protocols. The distinction between “protocol” and “contract” in this context is nonsense.
Pushing back on the terminology point. Duck typing is defined by how compatibility is determined, not by the absence of declaration. In Swift and Haskell, declaration is what makes a type conform. In Go, structure does, whether you add an optional assertion or not. OBI works the same way. Shapes determine compatibility. Roles and satisfies are optional declarations for explicitness, not a different mechanism.
Duck typing also requires being able to see a duck. Go has methods you can introspect. Raw REST doesn't. OpenAPI and gRPC reflection give you a structural surface, and OBI unifies those into one comparable form above the transport. What you're calling ad-hoc duck typing at the network boundary is humans reading docs and guessing whether the shapes match. That's a weaker version of the same idea, without the mechanical verification that makes duck typing useful. On "just another set of paths and protocols," OBI operation keys are transport-neutral. `tasks.create` has no route baked in. Bindings say how to reach it: REST at POST /tasks, gRPC at TaskService.Create, MCP as a tool. Same operation, multiple bindings, one identifier.
You’re still not getting it. Duck typing comes from the phrase “if it looks like a duck, and quacks like a duck, then it must be a duck”. The Wikipedia page contrasts it with nominative typing that requires a declaration, and calls out that duck typing does not need the adapter pattern. What you are calling duck typing is just “interfaces”.
Also “tasks.create” is morally a route. Eg grpc has web transports and autogenerated CLIs too; even without those, there’s no particular reason why the OBI “client layer” couldn’t just be, say, gRPC under the hood, with the OBI specs just being used to codegen adapters from the source protocol to gRPC. It would then immediately have a much more widely understood and supported client layer, with better performance, while remaining as simple to implement as the adapters to this new custom OBI runtime protocol.
You're right that what OBI does is structural typing or just interfaces, not duck typing. Transforms and bindings do use the adapter pattern. The critique lands and I can admit it. The duck typing framing was rhetorically appealing but imprecise.
On the gRPC-as-client-layer point, I want to make sure I understand. You're suggesting that between the OBI client SDK and the source service, there should be a gRPC layer, with generated gRPC adapters fronting each source? Or something else?
Worth noting either way: the spec doesn't dictate implementation. It defines operation contracts, binding sources, and the executor role. How an executor actually reaches a service is left open, so gRPC-based routing is a valid strategy within the spec regardless.
Thanks for sticking with this. This is exactly the kind of discussion I was hoping for. I really do appreciate it.
My gRPC point is that it already gives you a language for describing interfaces and support for generating client types from it, and already abstracts the connection management[1]. If OBI just generated a gRPC ClientConn implementation to map the Invoke calls to eg REST paths, it’d inherit the large existing gRPC client ecosystem. That ClientConn interface can already technically capture what OBI calls binding executors. People don’t do this though because it’s not worth it.
Thanks for the clarification. That's a valid implementation strategy for client consumers that want a gRPC feel. The spec doesn't require any particular client pattern (what's on the site is guidance, not normative), so an OBI-conformant toolchain could be built that way. I went with a less prescriptive approach, but that's a preference, not a mandate, and I think it's the right choice specifically for leaving the door open to alternative client implementation patterns like what you're proposing. I appreciate you sticking with this across the thread.
If you're open to it, I'd be interested in staying in touch as OBI evolves. I know you're not sold on the project, but critical voices willing to engage constructively for this long are rare and valuable regardless. If you ever want to poke at something or tell me where you think it's going wrong, I'm at https://x.com/clevengermatt, and there's the GitHub discussions.
> Stripe publishes an OBI, other payment providers declare a stripe.payments role, or a community defines a neutral payment-processor interface. No central registry, no governance bottleneck.
Except for the central registry of "stripe" and "payment-processor"?
Also, remember the code quality in the accidental Claude Code source publishing? Expect that for all their features. Thinking about having to debug automations hidden by their SaaS gives me the shudders.
Amazon is hugely anti-competitive, but their moat can be surprisingly shallow in some areas.
What Amazon has shown the rest of the industry is that shipping matters. Others are learning, at their own pace.
reply