The full technical report (PDF, 128 pages): Objwire-OWP-Technical-Report-v0.1.pdf
I've spent the last while on something that has nothing to do with breaking into anything, which is a sentence I don't get to write very often.
It started as an argument with myself about a question that sounds trivial until you try to answer it precisely: how does a machine know anything about the Internet?
Not "how does it search" — that part is solved, and the answer is that a few large companies will sell you a ranked list. The question is what happens after the machine has found a page. How does it know that page belongs to the company it mentions? How does it know the certificate it just saw was issued to that company? How does it know whether "domain X is operated by company Y" is something company Y said, something somebody measured, or something a model guessed?
Right now it doesn't. It reads a page, extracts some text, and then writes a confident summary. If you ask it where a particular sentence came from, the best case is "a page I fetched earlier." The worst case is that it can't tell you at all, because it's already forgotten.
That's the whole problem in one line: the Internet publishes a huge amount of information about itself, but almost none of it arrives in a form a machine can check.
The library with no catalogue
Here's the analogy I keep coming back to.
Imagine a library where every book writes its own cover. The cover can say anything — author, publisher, subject, edition. There's no catalogue, no spine label, no librarian. If you want to know whether a book was published by Penguin, you have to open it and read a claim, then decide whether to believe it. Something that looks like a Penguin book might be a Penguin book. It might also be a very good forgery, or a fan project, or a page someone threw together last week.
That's the Internet from a machine's point of view. Every website is a book whose cover is a claim. We've built an entire industry — search engines, reputation systems, trust scores, browser warnings — to work around the fact that the covers can't be trusted.
People manage. We have context, memory, and a lifetime of practice reading the web. Machines have none of that, and we're now asking them to make decisions on our behalf at a rate no human can supervise.
Three sentences that all look the same
The thing that actually kept me up at night isn't that the information is unreliable. It's that three very different kinds of statement arrive in exactly the same shape:
| What was said | Where it really came from | How much you should trust it |
|---|---|---|
| "This domain resolves to 203.0.113.10" | Somebody did a DNS lookup and watched what came back | High — it's a measurement you can repeat |
| "We own this domain" | The domain owner, describing itself | Depends entirely on who's asking, and whether they can prove it |
| "This domain is probably operated by that company" | A model, reasoning from a certificate and a footer | It's a guess. A good guess, maybe, but a guess |
Once those three get flattened into the same JSON blob, the difference is gone. And the difference is the only thing that matters when something goes wrong — when a payment is made to the wrong vendor, when an incident gets attributed to the wrong party, when a journalist publishes a claim that turns out to be a model's confident invention.
So the design goal stopped being "collect more information" and became something much narrower and, I think, much more useful: keep those three apart, and make the difference machine-readable.
What I'm actually building
The idea is called Objwire (the protocol is OWP — the name is new, more on that below). It's an open convention, not a product, and it rests on four plain ideas.
One: things describe themselves, at a predictable address on their own domain. If a company wants machines to know about it, it publishes a small JSON file at a standard location on its own website:
The /.well-known/ part is an old, boring web standard — it's the same mechanism that already tells the world where a site's security contact or ACME challenge lives. Nothing exotic. If you can post a file on the web, you can participate.
Two: descriptions are signed. A record carries a cryptographic signature from the domain's key. That doesn't make the claim true — a company can sign a lie just as easily as a truth. What it does is make the claim attributable: this came from whoever controls that domain, at this time, and here's the proof. That's not the same as trust, but it's the thing trust has to be built on.
Three: no central catalogue is required. You don't look up a company in my database, because there is no "my database." You take the identifier, see whose domain it lives under, and fetch it from there. If every index and search engine in the world went offline tomorrow, the description would still be fetchable and the signature would still check out. That property — resolution that doesn't depend on a middleman — is the entire reason I think this design has legs.
Four: measurements sit outside the thing being measured. If nobody from a company ever publishes anything, that doesn't mean the Internet goes dark about it. A registry, a certificate log, or a security company can publish what it observed, clearly labelled as an observation by that party. The company's own claims and everyone else's observations are stored separately, with separate authors, on purpose.
Here's roughly what a record looks like — shortened, but not simplified:
That epistemic_class field — asserted, observed, or inferred — is the heart of the whole thing. Everything else in the specification exists to make that field meaningful and hard to cheat.
What it deliberately doesn't do
I want to be careful here, because the temptation with a project like this is to promise a global brain.
It is not a search engine. It will not answer "find me every cybersecurity company in Canada." Search is a genuinely hard problem that several enormous companies have already solved, and every attempt to federate it has quietly collapsed back into a central index. I left search out of the core specification on purpose.
It is not a truth machine. A signature proves who said something, not whether it's correct. Nothing in this design stops a company from publishing nonsense about itself.
It is not a crawler, and it doesn't want to be one. Anybody can already crawl; the missing piece was never coverage, it was verifiability.
And it can't promise that every object on the Internet has one true name, because that's mathematically impossible without handing naming authority to a central body — which is the thing I'm trying to avoid. So identifiers come in three honest flavours: self-published (the owner's name for itself), content-derived (a hash of the actual bytes), and observer-scoped (somebody else's name for something they don't control, clearly labelled as such).
The most useful thing a system like this can do is say "I don't know, and here is exactly what I do and don't cover." Almost nothing on the Internet says that today.
Why I think this matters in the long term
I'm not going to pretend this is a business plan. It's infrastructure, and infrastructure is judged over a decade. Here's what I think it's actually for.
Agents get to show their work. Right now, an AI agent summarising a company is a black box with a plausible voice. Because every record carries its author, its timestamp and its evidence, an agent using this can produce an answer where each claim can be traced: this bit came from the company, this bit from a certificate log, this bit is my own inference, and this bit I couldn't find. That's the difference between a tool you can put in front of an auditor and one you can't.
Verification gets cheaper. A lot of professional work — due diligence, incident response, vendor onboarding, supply-chain review, journalism — is the same activity repeated: figure out who owns what, and how confident you should be. Right now it's manual, and everyone redoes it. If the underlying claims are published once in a verifiable shape, the expensive part (collecting) gets shared and the valuable part (judging) stays with the person doing the judging.
Records outlive companies. Every API eventually dies, and the data behind it usually dies with it. A signed file sitting on a domain has a much longer shelf life than an integration into somebody's product — and because the signature is verifiable offline, an archived record from 2026 will still be checkable in 2046.
It stays a commons. The specification is royalty-free, the reference tooling is open source, and there's no company you have to pay to be compliant. That's a deliberate bet: if this works, it should work because it's boring and freely implementable, not because someone owns it. The commercial opportunity, if any, is in the hard parts — hosted indexes, connectors, analysis — not in gatekeeping the format.
History becomes possible. Most systems only know the present tense. This one keeps track of when things were true: a certificate that existed for ninety days in 2026, a company that owned a domain until last spring, an address that changed. That sounds dull until you need to answer "was this true at the time?" — which is the question in nearly every investigation.
Small players get legible. Today, being found and understood by machines is mostly a game of SEO and Wikipedia notability. A plumbing company with four employees can't win that game against a marketing department. But a plumbing company can publish a signed file that says precisely who it is, what it operates, and who to contact. If a machine reads that shape, being small stops being the same thing as being invisible.
None of this requires anyone to trust me, which is the point. It requires a whole lot of small parties to publish a small amount of checkable information.
Where it actually is right now
Honest status, because I'd rather undersell this: nothing is deployed. There is no network yet. There's a specification, machine-checked schemas, a validator with 35 test fixtures (including the ones that are supposed to fail — forged signatures, conclusions dressed up as facts, silent truncation), a CLI that signs and verifies records in two commands, and a 128-page report that includes the parts I got wrong the first time.
One detail from that process that I enjoyed: the project had a different name when I started. It turned out the name was already a registered standard identifier in an adjacent area of the identity world, which would have made the acronym collide with a resolver-level method string. So I renamed it. The renaming itself was an afternoon's work — and it would have been a year of explanations if I'd discovered it after publishing. Cheaper to check first.
There's also a long section in the report about what the design deliberately doesn't do, and about the parts that are still unsolved — reputation, spam, the economics of somebody running a public node for years. I kept those in rather than quietly hoping nobody would notice, because a standard whose author won't name its weak points isn't worth implementing.
What happens next
The next step is deliberately small, and it takes two to three weeks: one real domain, publishing one signed object, from a static host. No server, no database, no software to install. If that works — and I can hand you a URL and you can verify it with curl in five minutes — then everything else becomes a scheduling problem instead of a conceptual one.
After that: a reference node, a conformance test suite, and connectors into registries that already publish this kind of information openly — certificate logs, package registries, registration data.
The thing I actually need is not money, or at least not yet. It's a second implementation. Right now one person's code passes one person's tests, which proves almost nothing. The moment somebody writes a compatible implementation from the specification alone — in another language, without copying mine — the design either stands up or it doesn't, and I find out which.
If that sounds like a good use of a weekend, or if you run something that would benefit from being verifiable to machines, I'd like to hear from you. And if you think the whole idea is wrong, I'd like to hear that even more — the report has a section listing exactly the observations that would prove it wrong.
The web was built so people could read it. This is the small, boring piece of work that would let machines check it.
You can reach me at admin@dtrh.net.