U.S. House committee approves blueprint for Big Tech crackdown

I’m just fine with saying this thing is an appliance that does what it does, including only accepting paired cartridges (gate-kept apps).

Consumers buy toasters instead of open grills for valid reasons, same for mobile devices. Forcing the toaster maker to support open grilling is over-regulation, the opposite of letting markets decide. If consumers don’t want a no muss no fuss appliance, they can buy something else.

You say this but then go on to pull in far more detail from today than I have...

> My lone assumption is a business that provides user-facing software. That's it. With that assumption, I'm arguing for the principle that when a business provides customers a human-targeted "UI", they need to provide a corresponding machine-usable "API" that bypasses the accidental complexity of human interaction. We know there must be a machine-friendly format before the user-friendly format, because the software is itself operating on a machine.

False. Actual machine friendly formats are not the same as the data structures that power UIs.

>> the business has chosen the architecture, and the law would mandate accessibility. > Well this isn’t what you said before. >This is what I said before. Having some type of public API is not "architecture". It's mandating open access to the same thing any front end needs to access anyway.

As already stated, the front end is not the same thing as an api suitable for clients. Maintaining a stable API is quite different from building a front-end site.

> Authentication and sign up: It's a public API, so this is irrelevant for read access.

Is it? Front ends often require sign up for read access. Why wouldn’t an API?

> For ordering, the same exact account system as using the web/app UI.

Wait - I thought your idea was architecture neutral. Why are you talking about the web ui?

> You keep ignoring existing implementations, pretending like what I'm saying would require some huge ground-up design rather than tweaks to what already exists.

Ahh, so this is just about how things are built today with minor tweaks.

> Data formats: The company. If a company is big enough to dictate formats, then they're big enough for developers to pay attention to.

Ok, so your law requires people to dictate formats?

> After the custom of using aggregators for shopping becomes commonplace, it becomes in their own interest to stick with common formats rather than get left behind.

Aggregators owned by whom? Google, Facebook, Amazon?

> Bugs: The company, while leaving the old "buggy" version in place for some period of time.

Seems like you have just introduced an architectural requirement to be able to run old versions in parallel with new ones. Who determines the person of time?

> you're imagining that any such law would be useless since a company could just deliberately create an unusable API. But courts see right through those type of "bad faith" approaches.

You are the only one talking about bad faith. I’m simply pointing out that supporting API clients requires architecture that is different from only supporting UI visitors.

If you are iterating on the UI frequently, and changing the structures that supports that UI, the by definition you don’t have a stable API unless you engineer one separately. No bad faith needed.

I'm referencing details that today's businesses are already operating with. I'm not proposing them to be part of the law, but analyzing how a generally abstract law would be applied to today's implementations.

> Actual machine friendly formats are not the same as the data structures that power UIs.

You're right. I tried to simplify by leaving off the network, and that was a mistake. It is true, a business offering in-person user-facing software would have to design a protocol to get the data out of memory (ie a security boundary). But when a business offers the software over a communications network, such serialization formats are already a requirement. So I do have a second assumption of a communications network.

> Front ends often require sign up for read access

I have yet to see a popular consumer store that requires a signin to browse products.

> Wait - I thought your idea was architecture neutral. Why are you talking about the web ui?

Because we're still talking about businesses who have chosen to make their software available over the web. That is complexity that they've chosen.

> Aggregators owned by whom? Google, Facebook, Amazon?

Whomever, at your own individual choice, as they're not bound by network effects of selling products as well. I'd personally choose a local client from the apt repository or nixpkgs.

> If you are iterating on the UI frequently, and changing the structures that supports that UI, the by definition you don’t have a stable API

So you're telling me that the back end engineers at Amazon just make whatever changes they feel like, remove the old version, and the front end engineers just deal? Or when the front end engineers want some additional data, they simply edit the backend code and deploy it directly?

In reality, there is versioning and change control going on internal to any large company. But once again you're blindfolding yourself to the common structure and customs that already exist, only to throw your hands up.

I really don't see how we can productively continue this conversation, as you keep superficially dragging in orthogonal complexity and then point outing how complex it is, rather than focusing on my proposal as stated.

FWIW, look at the EU's mandate for a common charging connector that both avoided locking in one implementation forever, while leveraging modern industry consensus to provide a massive market benefit.

So you agree that they already have to maintain stable APIs for each other? Meaning the mandate would be just adding a requirement for external visibility into the existing internal process, not anything significantly different from what they're already doing.

> If I was interviewing someone for a technical role and they told me that APIs were like charging connectors, I would say ‘no hire’, and complain to the recruiter.

So are you closed minded to analogies in general, don't appreciate that the physical layer has its own complexity, or what? The same type of arguments you're making were also levied at micro USB, by companies trying to keep their bespoke proprietary connectors so they could charge $50 for a spare phone charger. In the end they lost and the market benefited.

> Your argument seems to be that supporting external API clients in addition to an in-house UI imposes no burden

I agree there's a "burden". It's a small burden. One easy bound on this burden is that it is much less effort than developing a mobile app or another whole website specifically for mobile users. And most companies have eagerly done both.

> If you could accept that there are architectural constraints imposed by your demand

You keep using this word architecture. The current de facto deliverable includes XML or JSON documents. The deliverable for the mandate would be differently-formatted XML or JSON documents. Calling a second formatting an "architectural constraint" is a stretch.