On Fri, Jul 4, 2025 at 1:31 PM Christian Huitema <huitema@xxxxxxxxxxx> wrote:
On 7/4/2025 9:56 AM, Phillip Hallam-Baker wrote:
> On Fri, Jul 4, 2025 at 9:30 AM Theodore Ts'o <tytso@xxxxxxx> wrote:
>
> ...
>
> As a result, I tend to be very skeptical over solutions which require
> radical rearchitecture. By the time it is implemented, and deployed,
> it may be that it has been overtaken by events. Sure, this can happen
> with incremental changes, but at least the time and cost to implement
> can be much less, which mitigates this risk.
>
>
> This is not a 'radical rearchitecture'. It is merely recognizing that
> we took a wrong turn 30 years ago because we failed to understand what
> the DNS is.
>
> The DNS is the naming system of the Internet.
>
> That means the DNS should be the naming system for ALL the Internet.
>
> Which means it should be the naming system used by people to identify
> themselves, same as for hosts and services.
...
I agree with Ted on this one. I don't want to comment on the merit of
Phil's proposed solution, but mostly on the relation between business
models and deployment plans. Any new solution or new feature that we
propose has to be deployed, and deployment almost never start with
changes in the infrastructure.
There are no 'infrastructure' changes, everything I propose can be done incrementally. Don't judge the complexity of the transition by the capabilities of the result. All I am proposing is some very slight adjustments in a few key places and a different way of looking at the infrastructure that already exists.
* Minor extension to JSContact + prefixed DNS TXT record + JOSE + EARL scheme enables direct exchange of credentials to enable end to end secure communication in any protocol.
* ACME relay plus DNS Update plus JSDevice description analogous to JSContact enables onboarding devices as true IoT devices with DNS names and WebPKI certificates.
* Minor changes to the Blue Sky DNS Handle based OAUTH profile turns it into a global Internet identity provider with the user in full control of their identity handle if they choose.
* Use the JSContact scheme to specify the endpoint of a MOQ presence service and MOQ becomes an Open Service synchronous messaging, voice and video communications system.
None of these would be called 'infrastructure' if done individually. The only change here is recognizing that real users are going to need someone to provide those services. But that isn't really a change either. The only change is that instead of every service trying to 'own' the customer by locking them in with a serf@xxxxxxxxxxxxx, we use full DNS names that give the user the option of exit.
Instead, we see new applications or
devices deployed on the Internet we have, not the Internet that we wish
we had.
Which is exactly what I am proposing.
I also agree with the point about business models, and of the risks of
the device-cloud-app architecture. Some providers will inevitably go
bankrupt, or simply decide to not support the cloud part anymore, at
which point the app will just stop working. I don't believe that the
solutions here are technical.
Technical choices constrain the solution space. The decision to make people second class citizens on the Internet with account@domain was a technical decision.
I could think of non technical solutions,
such as laws compelling the manufacturers who stop supporting a product
to open source its communication protocols or allow the consumers to
reflash their devices. But the moment we say "laws", we step outside of
the the domain of the IETF.
I don't think we need laws, we just need to find a set of IoT manufacturers that are willing to make products the customers want instead of the products the VC backers want.
And I have a strategy. The US manufacturers are all looking for recurring revenue from services, but certain other manufacturers want to avoid services at any cost because they don't have the capability to offer them. And there is a tried and tested way of getting them to produce something - you put the product out as a kickstarter and a dozen companies will be copying it before you get your deliveries.
So what my little startup will do is to offer the other manufacturers a coupon costing a few dimes per device they sell which will allow purchasers who don't already have a HSP account to set one up. They get rid of a customer service cost, customers don't have to pay $8/mo to rent the use of the device they already bought.
Unless of course, other people were to look at my business plan and get in there first, well, I might have to think of another business model if that happened.
