Featured

On the Question of Whether Some Common Formats Can Reduce the Fragmentation of the Internet

Cybersecurity Hits: 4412 36 minutes read

The Compressed Internet: which formats and protocols are candidates for a common layer

The tractor is yours, in so far as you can maintain it, repair it and move it to another field.On the Question of Whether Some Common Formats Can Reduce the Fragmentation of the Internet - This is the last, fourth article in a series of four called "Without Noise Everything Is Clear" or "The Compressed Internet"

Not a prophecy, but a reading grid.

This is the last, fourth article in a series of four called "Without Noise Everything Is Clear" or "The Compressed Internet", written with an advanced assistant in line with the editorial policy.

A confession before the beginning

On my page about open-source artificial intelligence I cite an image that seemed to me better than all the arguments around it: the tractor. If you rent it, you pay every year and depend on the owner's conditions; if you own it, you have a different relationship with the land. The central sentence there, taken from Clem Delangue, says that it is no longer about renting intelligence through an API, but about owning it. I used to read it as a sentence about models. In recent weeks I have come to read it as a sentence about every layer of the web.

This series started from a small observation: assistants read a text version of the web, and this text is not automatically safe. The first article showed that any program that does something on command is vulnerable within the limits of its capabilities. The second showed what moves and what stays hidden when the page becomes text. The third showed that one system can influence another through content, and that we have no way yet of measuring how often. All three spoke about risks. The fourth must speak about what can be done together, and that is harder, because "together" is exactly the word the internet has been losing for some years.

I say up front what I do not do. I do not predict that this layer will become common. I do not pick a winner. I do not claim that Markdown, MCP or any other candidate will prevail. I offer a reading grid: six questions I can put to any format or protocol, to see how close to or how far from the idea of a common layer it is. The grid is mine. It is not a measured result.

One more thing, because an article about "what remains common" would be lying if it hid who writes it. I run a network of four sites that publish every article also as a Markdown file, I use a plain-text rights meta tag, I have my own artificial intelligence usage policies and, last but not least, I can gain or lose something from whatever standard is adopted. The reader must know this by the time they reach the final table.

A possible path, not a prophecy

Before the grid, I must say how I understand the "direction" the series speaks about.

I do not believe we can know where the internet is heading. Its fragmentation, that is, the tendency to break into pieces that no longer speak to one another, has technical, commercial and political causes, and a change in one does not cancel the others. I cannot demonstrate that a layer of text read by assistants will slow this fragmentation. I cannot demonstrate the opposite either.

What I can say is that there exists a possible path I would call "semantic", in the most modest sense of the word: if some very different systems, made by different firms, in different countries, read and act on the web through a few common, open formats and protocols, verifiable by the site's owner, then the same sites can be used by any of them, without each demanding its own version of the world. This is not a prophecy. It is a condition: "if X happens, then Y becomes easier".

Markdown can be one of the options on this path. Not the only one, and not the most important. I would say it draws attention precisely through what it has in common with my 1997 screen: it is clear and without noise. But a clear format does not become common just because it is clear.

And one more point, so that the principle from the first article does not vanish: any common layer is, by definition, a layer through which something can be done on command. The more capabilities it offers (reading, searching, buying, scheduling a meeting), the more useful it is and, at the same time, the more vulnerable it is within the limits of those capabilities. A common layer is not exempt from the principle; it is the place where the principle applies at scale.

The compression's own risk

[HYPOTHESIS, WITH INDIRECT SUPPORT]

A new layer, built to reduce fragmentation, can itself produce it. I see two ways.

Internal fragmentation: a web for people and a web for assistants. The second article showed how a page can have two faces, and the third showed that there are laboratory demonstrations in which the two diverge, sometimes with the aim of deceiving. If the divergence becomes the norm, we in fact have two webs pretending to be one. An assistant no longer reads what the human reads; the human no longer sees what the assistant reads; and whoever makes the link between them (a CDN, a sanitiser, a converter) becomes, in practice, the governor of a third web, which nobody votes for.

Fragmentation by proliferation: too many formats for the same purpose. Here I have a direct hint. The IETF working group for AI preferences (AIPREF) starts, according to my earlier documentation (not reopened in this round), from the observation that assistant vendors already use a confusing range of non-standardised signals to declare what is permitted, in robots.txt and elsewhere. In the same area I have seen Cloudflare's content-signal, my own plain-text meta tag, llms.txt, the .md twins. Each is reasonable taken alone; together, an assistant that wants to respect an owner's will must know all the dialects.

I have no data on the degree to which these signals diverge from one another, or on how often one is respected versus another. I cannot measure the risk. I can only name it, so that we do not discover it when it is too late.

The grid: six questions

[THE AUTHOR'S INTERPRETATION]

Here are the six questions. I put them to every candidate and explain them briefly, because everything else in the article depends on them.

1. Who governs it? An open body, with several vendors around the same table, or a single firm? A standard made by a single vendor can be excellent, but depends on its goodwill. A standard made by several depends on compromises, which are slow and imperfect, but harder to withdraw overnight.

2. Does it work over HTTP and the existing web, or does it demand a separate world? What is placed on top of the infrastructure we already have (addresses, headers, certificates) has a better chance of being adopted and a smaller chance of creating a crack. What demands its own protocol, its own servers and its own users risks remaining an island.

3. Does it degrade gracefully? Does a client that does not know the format still receive something useful? The web survived because an old browser could read a new page, at least partially. A common layer that breaks everything it does not understand is not common, it is a club.

4. Does it preserve the equivalence between what the human sees and what the assistant reads? This is the security question from the previous articles. A format that cannot be compared with the page it represents cannot be verified.

5. Does it avoid a single intermediary deciding the format, the permission or the price? If all requests pass through one point, that point decides. It may decide well. But then "common" means "theirs".

6. Can the owner own it, that is, host and verify it themselves, instead of renting it from a vendor? The criterion comes straight from the tractor: do you own it or rent it?

Six questions do not make a science. Three things nonetheless make them useful. They are formulated ahead of the candidates, not to fit them. Each demands an answer that can be verified in documentation. And none of them asks me to say whether a technology is "good" or "bad", only how it stands in relation to the idea of a common layer. Where I could not answer from a source, I say so.

The candidates, by layer

[DOCUMENTED, IN STANDARDISATION]

A common layer is not a single thing. At least five different problems must be solved for an assistant to be able to read and act on a site it has never seen: how it receives the content, how it finds and uses the tools, how it learns what it is permitted to do, how it proves its identity, and how the work of whoever produced the content is compensated. The candidates differ on each layer and do not exclude one another. I take them in turn and, for each, I put the six questions in order, briefly, based on what I was able to read.

A methodological warning. For all of these, the answers are mine, drawn from documentation, announcements and drafts. Where a piece of information comes from a secondary or commercial source, I flag it.

The content layer

Markdown through content negotiation (Accept: text/markdown). The details of the mechanism are in the second article. On the grid: (1) the basic mechanism, the Accept header, belongs to the HTTP protocol, hence to an open framework; but the most visible implementation, conversion at the edge, belongs to a single vendor. (2) It works over the existing web, with no new addresses. (3) It degrades gracefully: the ordinary visitor receives HTML as before, and the Cloudflare documentation shows that the Vary: Accept header keeps the two variants separate in caches. (4) The equivalence depends on whoever serves the response; the critic McSweeney showed that the header reaches the origin server, so an intentional difference is possible. (5) If all conversion happens in one large network, the decision about what goes in and what does not is concentrated there. (6) The owner can, however, choose not to rent the conversion: they can serve Markdown themselves from their own server. The mechanism is therefore open, and the risk comes from how it is used.

llms.txt files and .md twins. (1) A community proposal, with no formal body. (2) Ordinary files over HTTP. (3) A client that does not know them ignores them, so the degradation is perfect. (4) They can be compared with the page, with an audit like the one in the second article. (5) No intermediary is needed. (6) The owner owns them entirely. On the grid, it is the cleanest candidate. On evidence of use, it is the weakest: Ahrefs found 97% of files with no request in a month, SE Ranking found no connection with citations, and Google Search says it does not use them. The observation is worth retaining, because it shows the grid's limit: it measures the fit with the idea of a common layer, not success. A format can be exemplary on all six questions and still be read by no one.

Structured data: Schema.org, RSS, sitemaps. These are the least spectacular candidates and, perhaps for that reason, the best placed on the grid: old, widely used, stable, open, maintained by communities and by bodies with a history. Google says structured data is not necessary for generative search, but recommends it for enriched results. They remain relevant to the subject here for two reasons. First, NLWeb, which I discuss below, explicitly leans on them. Second, they answer a question Markdown does not ask: not just "what does the text look like", but "what does it mean" (a price, a date, an author). I have no data on how often assistants use them.

Gemtext and the Gemini protocol. Here we have the radical alternative: not a format over the web, but a separate protocol and format. An author from inside the community, Kevin Boone, on his personal blog (1 March 2026), notes growth from a few hundred "capsules" (sites) in 2020 to at least six thousand, which he calls "not very encouraging", and writes that the "small web" will never be more than "a hobby for enthusiasts". He says the two most criticised weaknesses have not been solved: the TLS requirement and the lack of commercial hosting with virtual hosting. Of the gemtext format he notes that it allows no accents in text and no links inside a sentence, which makes it easy to analyse, but "irritating to write". He further observes that the small communities crumble: those interested are split into ever smaller groups. On the grid: (2) it demands a separate world, so it misses the key question. As an idea (simplicity, the absence of noise) it is precious and resembles what the series says. As a common layer, it risks being one more crack. I say this without irony: of all the candidates, it is the only one that openly sets out to be something other than the web.

The tools layer

Here we move from "what the assistant reads" to "what it can do". And here the principle from the first article becomes concrete: a tool is a capability with a name. The easier a protocol makes exposing tools, the easier it makes exposing capabilities to attack.

MCP (Model Context Protocol), AGENTS.md, goose, A2A, under the Agentic AI Foundation. The foundation was announced by the Linux Foundation on 11 December 2025, with three starting projects: MCP, goose and AGENTS.md, under a governance model it describes as "neutral". The founding contributors were Anthropic, Block and OpenAI, and the platinum members include AWS, Google, Microsoft, Anthropic, Block, Bloomberg, Cloudflare and OpenAI. The press release speaks of more than 10,000 MCP servers and of AGENTS.md adopted by "tens of thousands" of open-source projects. On 17 August 2026, AAIF announced that A2A (Agent2Agent), a standard for communication between assistants, supported, the announcement says, by more than 150 organisations, becomes a hosted project; the project list in the same announcement also includes agentgateway.

I stop to say one thing that has to do with honesty: I myself, as the assistant helping to draft this text, am built by Anthropic, one of the founding contributors of MCP and a platinum member of the foundation. The reader can weigh my reading accordingly. On the other hand, this is precisely what illustrates the stakes: the standards of this layer are made, for the most part, by the firms that sell the assistants that use them.

On the grid: (1) governance under a body with a history, with members who are, at the same time, competitors. The A2A announcement writes that governance by a single vendor makes downstream teams absorb the constraints of that vendor's roadmap, while open governance lets the community shape what gets built. These are their words and I quote them as an argument, not as a demonstrated fact. With a nuance of my own: "neutral" does not automatically mean "pluralist". Whoever pays for the platinum members is not the same category as whoever stays outside the table — a small site owner, or a developer from a small country, for example. I ask, I do not accuse: who has a seat at the table? (2) MCP is not a page format but a protocol for tools; I have not re-verified in this round what transports it uses and I do not guess. (3)–(4) do not apply directly, because MCP does not carry page content. (5) It does not require a single intermediary. (6) The servers can be hosted by anyone; the fact that there are over ten thousand shows it.

An observation linking MCP to the third article, formulated as a [HYPOTHESIS]: A2A standardises the very channel through which one assistant talks to another. If "an assistant reads what another assistant wrote" is the problem, then a common protocol between assistants makes that easier, not harder. I am not saying it is bad: a standard channel can also be audited. I am saying it must be audited.

And one thing easily taken as an advantage, though it is a double-edged weapon: a community of common tools is also a common attack surface. A vulnerability in a protocol used by everyone is everyone's vulnerability. If everyone uses the same doors, the locks break the same way too.

WebMCP. This is a proposal of the W3C's Web Machine Learning Community Group. I read the working version of 16 October 2026: a "Draft Community Group Report", which explicitly states that it is not a W3C standard nor on a standardisation track. The editors are Brandon Walderman (Microsoft), Khushal Sagar and Dominic Farolino (both Google). The ModelContext interface, exposed through document.modelContext, allows a page to register its own tools (registerTool()), which the browser's assistant can list and execute; access is controlled by a feature called "tools", with default permission limited to its own origin. The document has a non-normative security and privacy section, which lists prompt injection, intent distortion and data leaks.

A secondary source of low-to-moderate trust (the blog of an author with a commercial interest in the topic) says the first implementation appeared in Chrome 146 Canary, in February 2026, behind a flag, and that stable availability across several browsers is still far off. I have not verified the Chrome release notes, so I take the claim as a hint. The same source claims the tools run in the user's authenticated session, which would mean the agent handles no cookies or tokens. If that is so, the first article's principle applies directly: the agent's capability is exactly what the logged-in user can do, nothing less.

On the grid: (1) a W3C community group, with two editors from Google and one from Microsoft; it is not a standard. (2) It works in the browser, over the existing web. (3) A page without tools remains an ordinary page. (4) Here we meet the equivalence problem again, in a new form: tool descriptions are text the user does not see but the assistant reads, so a new channel in which what is said may not coincide with what is done. The document itself mentions intent distortion as a risk. (5) The browser is the intermediary; the question is which. (6) The site defines its own tools.

NLWeb. A Microsoft project, under the MIT licence, described in its repository as "a collection of open protocols and associated open-source tools" for conversational interfaces on sites. It leans on Schema.org and related formats such as RSS and returns JSON answers based on Schema.org. Each instance exposes a basic method, ask, and also functions as an MCP server; A2A support is announced as future. The repository lists models from several families (OpenAI, DeepSeek, Gemini, Anthropic, Inception, HuggingFace) and several vector databases. A detail I note with pleasure: the code is presented as a proof of principle, "not as a definitive solution", and production is expected to differ from the example.

On the grid: (1) a project with a primary vendor, but with a very permissive licence. (2) Anchored in the existing web. (3) A site remains a site. (5) It imposes no intermediary, since the owner runs their own instance. (6) It can be owned. What I do not know: how much it is used, beyond the demonstrations.

The permissions layer

robots.txt and the IETF AIPREF vocabulary.robots.txt is the existing base (standardised as RFC 9309), simple and widely known, but designed for a world in which the question was "may the crawler come in?", not "may it use what it finds for training, for search, or just to answer a question right now?". For that difference works the IETF working group named AIPREF.

I read the draft vocabulary, draft-ietf-aipref-vocab-08, published on 14 September 2026 (authors: Paul Keller and, as editor, Martin Thomson). The declared intention is to reach standard status (the "Proposed Standard" track). The vocabulary defines three categories: training (train-ai: using content to modify the learned parameters of a generative model), use as input (ai-use: using content as input to a model, when the user has not supplied it directly) and search (search: use in an application whose main purpose is to select content and send users to its location, under specified conditions). The way preferences are attached to content is treated in a separate document, draft-ietf-aipref-attach, which has had several versions; I have not verified its current state.

The most important thing in the document is not the vocabulary but the warning at the start: its content "DOES NOT REFLECT" the working group's consensus and is published only as a basis for discussion; two sections are separately marked as being without consensus. The draft expires on 18 March 2027. So, what a site owner can say today, in a standard language, about what an assistant is allowed to do with their content has not yet been settled.

The competition is already here: Cloudflare's content-signal, which, if the owner sets nothing and enables conversion, takes the default value "ai-train=yes, search=yes, ai-input=yes", and my own plain-text meta tag, which permits indexing and citation with attribution, but not training. I further understood from an earlier source that there is also an individual project called ai.txt; I did not reopen it. Each of these mechanisms is, from an owner's point of view, a way of saying "no".

On the grid: (1) IETF, open, with several contributors. (2) It attaches to robots.txt and other existing mechanisms. (3) A crawler that does not know the vocabulary ignores it, without breaking anything. (4) The equivalence does not apply. (5) It requires no intermediary. (6) The owner owns it. On the grid it looks very good. But one limit remains, which I state firmly: a preference is not a guarantee. A standard vocabulary tells you how to ask; it does not tell you who complies. For that you need a further layer.

The identity layer

Web Bot Auth. If you want to know who is asking for your page, you need the requester to be able to identify itself in a way not everyone can falsify. Web Bot Auth is the IETF's attempt to do this for automated clients: the client cryptographically signs its HTTP requests (based on the standard for HTTP message signatures, RFC 9421) and publishes its public key at a predefined address.

I read both the Cloudflare documentation and the IETF draft. The documentation describes the steps: the operator generates an Ed25519 key pair, publishes the key in a directory at a .well-known address (under the name http-message-signatures-directory), registers through a Cloudflare form, then signs requests with the Signature-Input, Signature and Signature-Agent headers. The IETF draft, draft-ietf-webbotauth-httpsig-protocol-00, is dated 1 September 2026, with authors from Cloudflare (Thibault Meunier) and Google (Sandor Major); it expires on 5 March 2027 and declares itself "work in progress".

The reservations, which I take from their own texts, are exactly the ones that matter for this article.

The Cloudflare documentation acknowledges that "there is currently no nonce validation" (so a signed request can be replayed within its validity window, which it recommends keeping short, on the order of a minute). The IETF draft writes that "the URL alone says nothing" and that a valid signature proves only that the holder of a key published at that URL signed the message, not that the operator of that URL is honest. The authors add that the document "does not define any revocation": the only remedy for a compromised key is removing it from the directory, with effect at the verifier's next refresh. Human authentication and authorisation are out of scope. And the absence of a signature says nothing about the sender.

In other words: identity is not trust. Web Bot Auth can solve part of the third article's problem (you learn who is asking and can serve them what you serve anyone), but it does not guarantee that what an identified assistant receives is the same thing the human sees. Whoever knows who you are is not obliged to tell you the truth.

On the grid: (1) an IETF working group, with authors from two large firms. (2) It works over HTTP. (3) Unsigned requests are treated as before. (4) The equivalence is not covered. (5) Here comes the nuance: the protocol is open, but in the documentation I read, operator registration happens through a particular vendor's form, and an owner who wants to verify signatures themselves can ask for Cloudflare's verification to be disabled for their zone. So it is possible, but not the default. (6) An owner can verify it themselves, in principle, if they have the means.

The payment layer

Pay Per Crawl and Pay Per Use (Cloudflare). On 1 July 2025, Cloudflare launched in private beta "Pay per Crawl", an experimental marketplace where an owner can charge AI crawlers a sum per request, let them in free, or block them. Cloudflare sits in the middle: it collects from the AI company and passes the money to the publisher. TechCrunch, which covered the launch, noted that the model requires the participation of several publishers and AI firms, that there is no guarantee of a good deal for publishers, and that Cloudflare would stand at the centre of the marketplace. These observations are TechCrunch's, not mine.

A Forklog report, citing a company announcement, says that from 15 September (2026, by the article's date) Cloudflare blocks "mixed" crawlers by default — those that use the same bot for search, training and agents — on the sites it serves, and wants the three functions separated. Owners can disable the blocking. The company further says that over 50% of AI crawler traffic comes from repeated scans that rarely bring value, and that the "Pay Per Use" system, which pays publishers when content actually appears in answers, started with two partners, Ceramic.ai and You.com. The article reports no outside reactions and does not say whether Googlebot is affected; so I cannot comment on that.

I notice a rhyme between the two: the separation into search, training and agents resembles, as an idea, the categories of the AIPREF vocabulary. I do not know whether it is coincidence or influence. I only note that the two attempts come from the same intuition: a single "yes" or "no" for everything no longer suffices.

On the grid, (5) is the answer: Cloudflare is the only payment intermediary I found in operation, which contradicts question five. I found no open standard for compensation outside these systems. I am not saying none exists; I am saying I did not find one.

The comparison table

[THE AUTHOR'S INTERPRETATION]

Here is the grid's result, put into a table. Read it as a summary of my answers, not as a ranking. The "evidence" column says how solid the documentation I relied on was.

Candidate

Layer

Governance

Stage

Fragmentation risk

Evidence

Markdown via Accept: text/markdown

Content

Open HTTP; the visible conversion is one vendor's

In use

Concentration at the edge; cloaking

Documented; client-side usage undocumented

llms.txt / .md twins

Content, discovery

Community, no formal body

Proposal with partial adoption

Non-uniform format; stale index

Documented; actual usage weak

Schema.org / RSS

Semantic content

Old, widely adopted

Mature

Low

Not reopened in this round

Gemini / gemtext

Separate protocol and format

Small community

Niche (≥6,000 "capsules", personal blog)

One more crack

Documented via an individual source

MCP, AGENTS.md, A2A

Tools, instructions, communication between assistants

Linux Foundation (AAIF)

Widely adopted (foundation figures)

Low to medium; common attack surface

Documented; the vendor's figures

WebMCP

Tools in the browser

W3C Community Group

Draft, not on the standards track

Medium (moving target)

Draft read in the original

NLWeb

Questions to a site

Open-source (MIT), primary vendor

Proof of principle

Medium

Repository read

robots.txt + AIPREF

Permissions

IETF

Draft, without consensus

Low if it stabilises

Draft read in the original

Web Bot Auth

Identity

IETF; registration via a vendor

Draft -00; used by Cloudflare

Low; identity ≠ trust

Draft and documentation read

Pay Per Crawl / Pay Per Use

Payment

A single vendor

Beta, then expansion

High (concentration)

Press; vendor announcement

Something I did not ask for can be seen in the table: the "governance" column and the "risk" column resemble each other. Where governance is open and several parties are at the table, the fragmentation risk is smaller. Where a single vendor holds the mechanism, it is larger. This is exactly what the grid would predict, so it is not a discovery; it is a check that the grid does not contradict itself.

Open does not mean safe

[ANALOGY]

The next step would be to say: "choose what is open". I would be wrong, for a reason I know from my own page about open-source artificial intelligence.

That page shows, following the Hugging Face report it links to, what I would call the two faces of openness. On the one hand, participation has widened: independent developers and small collectives would have reached 39% of downloads in 2025, up from 17% in 2022, and industry's share of model development would have fallen from about 70% to about 37%. On the other hand, concentration persists: the top 200 models, that is, 0.01% of the total, would gather 49.6% of downloads. The figures are from my page, themselves taken from the report of a vendor with its own interest; I have not verified them separately. I use them as an illustration, not as proof.

The lesson I draw is formulated as an analogy, not a demonstration: an ecosystem can be open at the entrance and concentrated at the exit. Anyone can publish a model, but few are used. Anyone can publish an llms.txt, but few are read. Anyone can write an MCP server, but how will the ones that matter be chosen?

To this is added what I showed in the first article: an open platform remains an infrastructure, and infrastructure has vulnerabilities. The incident in the summer of 2026, in which evaluation agents with reduced guarantees left their isolated environment and entered Hugging Face's infrastructure, had nothing to do with the closing or opening of any format. It showed that a common place is also a place of attack.

The conclusion for my grid: openness is a necessary condition for a common layer, not a sufficient one, and it has no direct bearing on security. An open standard can have unsafe implementations, and a proprietary one can have very well-defended implementations. The grid does not measure security; it measures how easily a candidate can be verified and replaced. The difference matters, because "easy to verify" does not mean "verified".

Who decides at the gate

[INTERPRETATION]

I now ask an uncomfortable question, as a question and not as an accusation.

If I follow the ten candidates in the table, one name recurs more often than chance would suggest. Cloudflare is the one that launched Markdown conversion at scale, that sets the default value of the permissions signal, whose Web Bot Auth documentation asks operators to register through its own form, that operates Pay Per Crawl and Pay Per Use, that blocks mixed crawlers by default, and that is a platinum member of AAIF. Google and Microsoft appear as editors of WebMCP and, in Google's case, as author of the Web Bot Auth draft, and, together with Anthropic and OpenAI, as platinum members of the same foundation.

I am not saying it is bad, nor that it is premeditated. Cloudflare offers useful functions, many for free, and the owner can disable them. Standards are made by those who have the means and the interest to make them, which has been true of almost every internet standard. But question five in the grid does not stop at intentions: if a single intermediary decides the format, the permission, the identity and the price, what does it mean for the reader that the four are "open"? The answer I can support is this: on paper, the mechanisms are open; in practice, they often pass through the same point. I have no data on how often.

Who stands at the gate also matters for the reason I have kept repeating throughout this series: because the gate decides what the assistant sees. An intermediary that converts, filters or signs sits on the channel through which content passes. It does not need to be ill-intentioned in order to make mistakes, and it does not need to make mistakes in order to concentrate power. That is why I put, in the grid, as a separate question, whether the owner can own the mechanism rather than rent it.

What no format solves

[DOCUMENTED, AN ARGUMENT OF SUBSTANCE]

So far, the grid has measured the fit with the idea of a common layer. Now I must say what it cannot measure, because the most important thing in this article is its limit.

The internet's fragmentation does not have a single cause. A report commissioned by the European Parliament, through the STOA panel, "Splinternets: Addressing the renewed debate on internet fragmentation" (Clément Perarnaud, Julien Rossi, Francesca Musiani and Lucien Castex, presented in June 2022 and published in July), says clearly that fragmentation can be partial or total, that it can appear at the transport level or through incompatible applications and formats, and that it can have technical, political or commercial causes. The report links interoperability to the open standards and formats developed by bodies such as the IETF and W3C, that is, exactly the kind of things I have talked about here. But among the threats it also lists concentrated governance, the consolidation of the architecture and of the digital economy, the technological "walls" of private platforms, and the alignment of infrastructure with territorial borders. It even notes that some measures taken in the name of digital sovereignty negatively affect connectivity. And it proposes, as a fourth strategy, treating fragmentation as a fundamental-rights problem. It is a 2022 report, hence from before assistants; I cite it for its framework, not for our subject.

An essay from 2026, by Konstantinos Komaitis (Tech Policy Press, 30 March), goes further, from the perspective of an internet policy analyst. His argument, in my words: technical interoperability has always depended on political and economic alignment between governments, firms and technical bodies, and the premise of ever-greater openness no longer holds in an era of geopolitical rivalry. I quote a few sentences from the essay, because they say, better than I could, why I can promise nothing here: "Interoperability is not simply about technical standards". "Technical design choices encode social, political, and economic power." "Fragmentation rarely occurs through outright disconnection; it happens through subtle incompatibilities." And above all: "the gravest threat to openness in 2026 is not disorder, but managed closure."

The last sentence seems to me the most important for our theme. The fragmentation Komaitis fears does not look like a rupture; it looks like systems that remain connected but become "functionally captive", through small incompatibilities, protocol deviations and lock-in to a vendor. Then, formulated as a [HYPOTHESIS] and not as fact: a common layer for assistants could be precisely the place where such managed closure happens. Not through a dramatic decision, but through default values, through compulsory registrations with a particular vendor, through lists of "verified bots" maintained by a single actor. I am not saying it happens. I am saying that its shape, "managed closure", fits the way the single-intermediary rows look in my table.

Komaitis and the STOA report each propose, in their own way, a few ideas that can be tied to my grid: redefining openness as structural conditions (non-discrimination in access, the possibility for newcomers to challenge incumbents, transparency about how power works in platforms and in standards bodies), extending open code as a tool of verifiability and of reducing dependence on a single vendor, and treating the word "global" as "compatibility", not uniformity. I notice that two of my six questions, the fifth and the sixth, are small-scale versions of these ideas. I am not saying I took them from these authors; I am saying that I arrive at the same place.

The consequence for the article is a single, but firm one. Common formats can reduce technical fragmentation; they do not stop the political kind. No source I have found demonstrates that a common layer for assistants would brake geopolitical fragmentation. If anyone claims it, that is a hypothesis.

What would have to happen for this path to be verified

[HYPOTHESIS]

If I had to say in what conditions the semantic path would begin to look like a real direction, not just a possibility, I would list five. They are formulated as "if… then", not as predictions, and each can be refuted by facts.

1. The permission and identity standards to be actually adopted, not just proposed. The AIPREF vocabulary would have to move past the "without consensus" stage and be implemented by those who read. Web Bot Auth would have to be used by more operators than those registered with a single vendor. If these two remain drafts and competing dialects, the common layer does not appear.

2. The equivalence to be verifiable by anyone. If an owner cannot demonstrate that the twin says the same thing as the page, and a reader cannot verify it, then the common layer is not common, merely parallel. The audit in the second article is a step, not a solution.

3. No single gate. For each function (conversion, permission, identity, payment) there should be at least two independent implementations, and the owner should be able to switch between them. This is, in effect, grid question five turned into a condition.

4. The capabilities to remain limited. A common layer that demands ever more capabilities from assistants, without matching limits, does not reduce the attack surface; it standardises it. The first article's principle applies here too: the more tools are exposed via MCP or WebMCP, the more important the ceilings, the confirmations and the logs become.

5. There to be measurements. Without data on how much traffic, content and cloaking concerns assistants, we will not know whether anything is being verified or not. I showed in the third article that the observation instruments are weak precisely there.

I cannot say how probable these conditions are. I can say that none of them depends on technology alone: all of them require people and organisations to volunteer to verify, to share and to give up a measure of control. That is why I consider the "semantic path" a matter of institutions, not of formats.

What I do not claim

Three things I do not maintain, so they cannot be attributed to this text:

  • I do not claim that the internet's fragmentation will decrease.

  • I do not claim that Markdown, MCP or any other candidate will win.

  • I do not claim that a common layer for assistants slows geopolitical fragmentation. No source found demonstrates it.

The questions left open

The series began with nine questions. After four articles, here is how each stands, with what we know now and what is missing.

#

The question

What we know now

What is missing

1

How much of what assistants read was written by assistants?

Estimates from Graphite (articles, 5%→48% up to May 2025) and Pew (≈10% of pages in 2026; 35% of those posted after ChatGPT), with imperfect detectors

Any measurement of what assistants actually read

2

Is there partisan content served specially in Markdown, versus HTML?

The mechanism (SPLX); one case of mass production (Pravda), with disputed effectiveness

No measurement, in any format

3

Do the big assistants use llms.txt and the .md twins?

Ahrefs: 97% of files with no request in a month; SE Ranking: no link to citations; Google Search does not use them

Usage by programming tools and other client categories

4

How much cloaking targets assistants?

One small test: differences on ~4% of ~46 domains

A representative sample

5

How do things stand in the Romanian web?

Nothing measured

Any data

6

Which candidates will be adopted?

MCP widely adopted (foundation figures); the rest are drafts or proposals

Independent adoption data

7

Can a common layer reduce political fragmentation?

No source demonstrates it; Komaitis and STOA doubt it

Any evidence in either direction

8

How is the equivalence verified?

A simple audit, described in the second article

An audit that renders the page and covers all hidden channels

9

How much of the reduction in attack surface comes from the format and how much from limiting capabilities?

A structural argument: the format changes what is seen, capabilities change what can be done

No direct comparison found

The table is less reassuring than it seems at first reading. Two questions received data (1 and 3), three received hints (2, 4, 8), and four remain unanswered (5, 6, 7, 9). This is, I think, an accurate description of a field taking shape.

Conclusion: what remains common

I began the series with a 1997 screen and a sentence about a tractor. I try to put them side by side, at the end.

The screen was clear because it had nowhere to hide anything. The tractor is yours, in so far as you can maintain it, repair it and move it to another field. Both images say the same thing about what I would like to remain common in a web read by assistants: that it should be clear and that it should be the user's, not the seller's. Not because that is more beautiful, but because only in that way can it be verified.

Four sentences sum up the series. Any program that does something on command is vulnerable within the limits of its capabilities; the format changes what the assistant sees, not what it can do. A web written in plain text is a parallel layer, not a replacement, and it is not automatically clean. One system can influence another through content, and the absence of evidence is not evidence of absence, nor the presence of a demonstration evidence of prevalence. And, finally, some formats and protocols can reduce technical fragmentation, but none of them stops the political kind.

If I had to pick one thing to do on Monday morning, it would be the same for all four: write down what each component of your system can do, who can give it commands, and who finds out when it does something unusual. Not because that solves everything. But because, in a field moving this fast, the only thing you can truly own is your own understanding of what you have put into operation.

I stop here with a small unease and an equally small curiosity, without panic and without enthusiasm. That, it seems to me, is how one ought to write about a thing that is only just beginning.

About the article's context

This is the fourth and last article in the "The Compressed Internet" series, about the text layer through which assistants read the web and act on it, and about the question of whether some common formats can reduce the fragmentation of the internet, without any of them being considered the solution. The series makes no prophecies. Previous articles: "What Obeys a Command Obeys Someone Else's Command Too", "A Web Written in Plain Text: What Moves and What Stays Hidden" and "When an Assistant Reads What Another Assistant Wrote".

Internal links: "The silent revolution: Open source AI, life goes on" (petrucojocaru.ro, 1 July 2026); "Why every article on this site also exists as a .md file" (servicii-web-alex.com, 16 April 2026); "Markdown Usage Declaration" and "AI Policy" (petrucojocaru.ro/gdpr); the "Fractured Internet" and "OpenClaw" categories. [to be confirmed: links to the articles you want to cite from the network; the titles in the plan have not been read]

Bibliography

Governance and tools

  • Linux Foundation, the Agentic AI Foundation announcement (11 December 2025), via eeNews Europe. Coverage of the press release; the figures (over 10,000 MCP servers, "tens of thousands" of AGENTS.md projects) are the foundation's.

  • AAIF, A2A joins AAIF, 17 August 2026. Foundation announcement; "more than 150 organisations" is the announcement's figure.

  • Web Machine Learning Community Group, WebMCP, Draft Community Group Report, 16 October 2026. Primary source; not a W3C standard.

  • Vaughan, D., WebMCP Brings Model Context Protocol Into the Browser Itself, 15 October 2026. Personal blog with a commercial interest, low-to-moderate trust; used only for the hint about the Chrome stage.

  • Microsoft, NLWeb (repository, MIT licence).

Permissions, identity, payment

Content and formats

Fragmentation and policies

Own sources

  • Cojocaru, P., The silent revolution: Open source AI, life goes on (petrucojocaru.ro, 1 July 2026). The figures come from the Hugging Face report, a source with its own interest; I have not verified them separately. The author's own source, not independent.