Internetul Comprimat: ce formate și protocoale sunt candidate la un strat comun
Nu o profeție, ci o grilă de lectură.
Acesta este ultimul, al patrulea articol dintr-o serie de patru numit ”Fără zgomot totul e clar” sau „Internetul Comprimat" dar am și un Supliment, redactat cu asistent avansat conform politicii editoriale.
O mărturisire înainte de început
În pagina mea despre inteligența artificială open-source citez o imagine care mi s-a părut mai bună decât toate argumentele din jurul ei: tractorul. Dacă îl închiriezi, plătești în fiecare an și depinzi de condițiile proprietarului; dacă îl deții, ai o altă relație cu pământul. Fraza centrală de acolo, preluată de la Clem Delangue, spune că nu mai e vorba de închirierea inteligenței prin API, ci de deținerea ei. Am citit-o ca pe o frază despre modele. În ultimele săptămâni am ajuns să o citesc ca pe o frază despre orice strat al web-ului.
Seria aceasta a pornit de la o observație mică: asistenții citesc o versiune în text a web-ului, iar acest text nu e automat sigur. Primul articol a arătat că orice program care face ceva la comandă este vulnerabil în limitele competențelor lui. Al doilea a arătat ce se mută și ce rămâne ascuns când pagina trece în text. Al treilea a arătat că un sistem poate influența altul prin conținut și că nu avem cum să măsurăm încă cât de des. Toate trei au vorbit despre riscuri. Al patrulea trebuie să vorbească despre ce poate fi făcut împreună, și asta e mai greu, pentru că „împreună" este exact cuvântul pe care internetul îl pierde de câțiva ani.
Spun din capul locului ce nu fac. Nu prezic că stratul acesta va deveni comun. Nu aleg un câștigător. Nu susțin că Markdown, MCP sau oricare alt candidat va ieși învingător. Ofer o grilă de lectură: șase întrebări pe care le pot pune fiecărui format sau protocol, ca să văd cât de aproape sau cât de departe este de ideea de strat comun. Grila e a mea. Nu e un rezultat măsurat.
Mai spun ceva, pentru că un articol despre „ce rămâne comun" ar fi mincinos dacă ar ascunde cine îl scrie. Administrez o rețea de patru site-uri care publică fiecare articol și ca fișier Markdown, folosesc un meta-tag de drepturi în text liber, am politici proprii de utilizare a inteligenței artificiale și, nu în ultimul rând, pot câștiga sau pierde ceva din orice standard adoptat. Cititorul trebuie să știe asta și când ajunge la tabelul final.
O cale posibilă, nu o profeție
Înainte de grilă, trebuie spus cum înțeleg eu „direcția" despre care vorbește seria.
Nu cred că putem ști încotro merge internetul. Fragmentarea lui, adică tendința de a se rupe în bucăți care nu mai vorbesc între ele, are cauze tehnice, comerciale și politice, iar o schimbare într-una nu o anulează pe celelalte. Nu pot demonstra că un strat de text citit de asistenți va încetini această fragmentare. Nu pot demonstra nici contrariul.
Ce pot spune este că există o cale posibilă pe care aș numi-o „semantică", în sensul cel mai modest al cuvântului: dacă niște sisteme foarte diferite, făcute de firme diferite, în țări diferite, citesc și acționează pe web prin câteva formate și protocoale comune, deschise, verificabile de proprietarul site-ului, atunci aceleași site-uri pot fi folosite de oricare dintre ele, fără ca fiecare să ceară o versiune proprie a lumii. Asta nu e o profeție. E o condiție: „dacă se întâmplă X, atunci Y devine mai ușor".
Markdown poate fi una dintre opțiunile acestei căi. Nu singura și nu cea mai importantă. Aș spune că atrage atenția tocmai prin ceea ce are în comun cu ecranul meu din 1997: este clar și fără zgomot. Dar un format clar nu devine comun doar pentru că e clar.
Și încă un punct, ca să nu dispară principiul din primul articol: orice strat comun este, prin definiție, un strat prin care se poate face ceva la comandă. Cu cât oferă mai multe competențe (să citești, să cauți, să cumperi, să programezi o întâlnire), cu atât este mai util și, în același timp, cu atât mai vulnerabil în limitele acelor competențe. Un strat comun nu este scutit de principiu; este locul unde principiul se aplică la scară mare.
Riscul propriu al compresiei
[IPOTEZĂ, CU SPRIJIN INDIRECT]
Un strat nou, făcut ca să reducă fragmentarea, poate el însuși să o producă. Văd două feluri.
Fragmentare internă: un web pentru oameni și un web pentru asistenți. Articolul al doilea a arătat cum o pagină poate avea două fețe, iar articolul al treilea a arătat că există demonstrații de laborator în care cele două diverg, uneori în scopul de a păcăli. Dacă divergența devine normă, avem de fapt două web-uri care se prefac că sunt unul. Un asistent nu mai citește ce citește omul; omul nu mai vede ce citește asistentul; iar cine face legătura dintre ele (un CDN, un sanitizator, un convertor) devine, practic, guvernatorul unui al treilea web, pe care nu-l votează nimeni.
Fragmentare prin proliferare: prea multe formate pentru același scop. Aici am un indiciu direct. Grupul de lucru IETF pentru preferințele legate de inteligența artificială (AIPREF) pornește, potrivit documentării mele anterioare (neredeschise în această rundă), de la observația că furnizorii de asistenți folosesc deja o gamă confuză de semnale nestandardizate pentru a declara ce e permis, în robots.txt și în alte locuri. Eu am văzut, în aceeași arie, semnalul content-signal al Cloudflare, meta-tag-ul meu în text liber, llms.txt, gemenii .md. Fiecare este rezonabil luat singur; împreună, un asistent care vrea să respecte voința unui proprietar trebuie să cunoască toate dialectele.
Nu am date despre gradul în care aceste semnale diverg între ele, sau despre cât de des e respectat unul față de altul. Nu pot măsura riscul. Pot doar să-l numesc, ca să nu-l descoperim când e prea târziu.
Grila: șase întrebări
[INTERPRETARE A AUTORULUI]
Iată cele șase întrebări. Le pun fiecărui candidat și le explic pe scurt, pentru că de ele depinde tot restul articolului.
1. Cine îl guvernează? Un organism deschis, cu mai mulți furnizori în jurul aceleiași mese, sau o singură firmă? Un standard făcut de un singur furnizor poate fi excelent, dar depinde de bunăvoința lui. Un standard făcut de mai mulți depinde de compromisuri, care sunt lente și imperfecte, dar mai greu de retras peste noapte.
2. Funcționează peste HTTP și web-ul existent, sau cere o lume separată? Ce se pune peste infrastructura pe care o avem deja (adrese, antete, certificate) are o șansă mai mare să fie adoptat și o șansă mai mică să creeze o fisură. Ce cere propriul protocol, propriile servere și propriii utilizatori riscă să rămână o insulă.
3. Degradează grațios? Un client care nu cunoaște formatul primește totuși ceva util? Web-ul a supraviețuit pentru că un browser vechi putea citi o pagină nouă, măcar parțial. Un strat comun care strică tot ce nu înțelege nu este comun, este un club.
4. Păstrează echivalența dintre ce vede omul și ce citește asistentul? Aceasta este întrebarea de securitate din articolele precedente. Un format care nu poate fi comparat cu pagina pe care o reprezintă nu poate fi verificat.
5. Evită ca un singur intermediar să decidă formatul, permisiunea sau prețul? Dacă toate cererile trec printr-un punct, acel punct decide. Poate decide bine. Dar atunci „comun" înseamnă „al lui".
6. Poate proprietarul să-l dețină, adică să-l găzduiască și să-l verifice singur, în loc să-l închirieze de la un furnizor? Criteriul vine direct din tractor: deține sau închiriezi?
Șase întrebări nu fac o știință. Trei lucruri le fac totuși utile. Sunt formulate înaintea candidaților, nu pe măsura lor. Fiecare cere un răspuns care se poate verifica într-o documentație. Și niciuna nu cere să spun dacă o tehnologie e „bună" sau „rea", ci doar cum se așază față de ideea de strat comun. Unde nu am putut răspunde dintr-o sursă, spun că nu am putut.
Candidații, pe straturi
[DOCUMENTAT, ÎN STANDARDIZARE]
Un strat comun nu e un singur lucru. Cel puțin cinci probleme diferite trebuie rezolvate ca un asistent să poată citi și acționa pe un site pe care nu l-a mai văzut: cum primește conținutul, cum găsește și folosește uneltele, cum află ce îi este permis, cum își dovedește identitatea și cum se compensează munca celui care a produs conținutul. Candidații sunt diferiți pe fiecare strat și nu se exclud între ei. Îi iau pe rând și, la fiecare, pun cele șase întrebări în ordine, scurt, pe baza a ce am putut citi.
Un avertisment de metodă. La toți aceștia răspunsurile sunt ale mele, trase din documentație, din anunțuri și din drafturi. Unde o informație vine dintr-o sursă secundară sau comercială, o semnalez.
Stratul conținutului
Markdown prin negociere de conținut (Accept: text/markdown). Detaliile mecanismului sunt în articolul al doilea. Pe grilă: (1) mecanismul de bază, antetul Accept, aparține protocolului HTTP, deci unui cadru deschis; dar implementarea cea mai vizibilă, conversia la margine, aparține unui singur furnizor. (2) Funcționează peste web-ul existent, fără adrese noi. (3) Degradează grațios: vizitatorul obișnuit primește HTML ca înainte, iar documentația Cloudflare arată că antetul Vary: Accept ține separate cele două variante în memoriile cache. (4) Echivalența depinde de cine servește răspunsul; criticul McSweeney a arătat că antetul ajunge la serverul de origine, deci o diferență intenționată e posibilă. (5) Dacă toată conversia se face într-o singură rețea mare, decizia despre ce intră și ce nu se concentrează acolo. (6) Proprietarul poate însă să nu închirieze conversia: își poate servi singur Markdown din propriul server. Mecanismul e deci deschis, iar riscul vine din modul în care e folosit.
Fișiere llms.txt și gemeni .md. (1) O propunere comunitară, fără organism formal. (2) Fișiere obișnuite peste HTTP. (3) Un client care nu le cunoaște le ignoră, deci degradarea e perfectă. (4) Se pot compara cu pagina, cu un audit ca cel din articolul al doilea. (5) Niciun intermediar nu e necesar. (6) Proprietarul le deține integral. Pe grilă, este candidatul cel mai curat. Pe dovezi de utilizare, e cel mai slab: Ahrefs a găsit 97% din fișiere fără nicio cerere într-o lună, SE Ranking nu a găsit o legătură cu citările, iar Google Search spune că nu le folosește. Observația merită reținută, pentru că arată limita grilei: ea măsoară potrivirea cu ideea de strat comun, nu succesul. Un format poate fi exemplar pe toate cele șase întrebări și să nu-l citească nimeni.
Date structurate: Schema.org, RSS, sitemap-uri. Sunt candidații cei mai puțin spectaculoși și, poate de aceea, cei mai bine plasați pe grilă: vechi, larg folosiți, stabili, deschiși, ținuți de comunități și de organisme cu istorie. Google spune că datele structurate nu sunt necesare pentru căutarea generativă, dar le recomandă pentru rezultate îmbogățite. Rămân relevante pentru subiectul de aici din două motive. Mai întâi, NLWeb, despre care vorbesc mai jos, se sprijină explicit pe ele. În al doilea rând, ele răspund la o întrebare pe care Markdown nu o pune: nu doar „cum arată textul", ci „ce înseamnă el" (un preț, o dată, un autor). Nu am date despre cât de des le folosesc asistenții.
Gemtext și protocolul Gemini. Aici avem alternativa radicală: nu un format peste web, ci un protocol și un format separate. Un autor din interiorul comunității, Kevin Boone, în blogul lui personal (1 martie 2026), notează o creștere de la câteva sute de „capsule" (site-uri) în 2020 la cel puțin șase mii, pe care o numește „nu prea încurajatoare", și scrie că „small web"-ul nu va fi niciodată mai mult decât „un hobby pentru pasionați". Spune că cele mai criticate două slăbiciuni nu au fost rezolvate: cerința TLS și lipsa găzduirii comerciale cu virtual hosting. Despre formatul gemtext notează că nu permite accent în text și nici legături în interiorul unei propoziții, ceea ce îl face ușor de analizat, dar „iritant de scris". Mai observă că micile comunități se fărâmițează: cei interesați sunt împărțiți în grupuri tot mai mici. Pe grilă: (2) cere o lume separată, deci ratează întrebarea cheie. Ca idee (simplitatea, lipsa zgomotului) e prețioasă și seamănă cu ce spune seria. Ca strat comun, riscă să fie o fisură în plus. O spun fără ironie: dintre candidați, este singurul care își asumă deschis să fie altceva decât web-ul.
Stratul uneltelor
Aici trecem de la „ce citește asistentul" la „ce poate face". Și aici principiul din articolul întâi devine concret: o unealtă este o competență cu nume. Cu cât un protocol face mai ușoară expunerea de unelte, cu atât face mai ușoară și expunerea de competențe de atacat.
MCP (Model Context Protocol), AGENTS.md, goose, A2A, sub Agentic AI Foundation. Fundația a fost anunțată de Linux Foundation pe 11 decembrie 2025, cu trei proiecte de pornire: MCP, goose și AGENTS.md, sub un model de guvernare pe care îl descrie drept „neutru". Contribuitorii fondatori au fost Anthropic, Block și OpenAI, iar membrii platinum includ AWS, Google, Microsoft, Anthropic, Block, Bloomberg, Cloudflare și OpenAI. Comunicatul vorbește de peste 10.000 de servere MCP și de AGENTS.md adoptat de „zeci de mii" de proiecte open-source. Pe 17 august 2026, AAIF a anunțat că A2A (Agent2Agent), un standard pentru comunicarea între asistenți, susținut, spune anunțul, de peste 150 de organizații, devine proiect găzduit; lista proiectelor din același anunț îl include și pe agentgateway.
Mă opresc să spun un lucru care ține de onestitate: eu însumi, ca asistent care ajută la redactarea acestui text, sunt construit de Anthropic, unul dintre contribuitorii fondatori ai MCP și membru platinum al fundației. Cititorul poate cântări citirea mea în consecință. Pe de altă parte, tocmai asta ilustrează miza: standardele acestui strat sunt făcute, în mare parte, de firmele care vând asistenții care le folosesc.
Pe grilă: (1) guvernare sub un organism cu istorie, cu membri care sunt, în același timp, concurenți. Anunțul A2A scrie că guvernarea de către un singur furnizor face ca echipele din aval să absoarbă constrângerile foii de parcurs a acelui furnizor, iar guvernarea deschisă lasă comunitatea să modeleze ce se construiește. Sunt cuvintele lor și le citez ca argument, nu ca fapt demonstrat. Cu o nuanță de mine: „neutru" nu înseamnă automat „pluralist". Cine plătește membrii platinum nu e aceeași categorie cu cine rămâne în afara mesei, de exemplu un proprietar de site mic sau un dezvoltator dintr-o țară mică. Întreb, nu acuz: cine are loc la masă? (2) MCP nu e un format de pagină, ci un protocol pentru unelte; nu am reverificat în această rundă ce transporturi folosește și nu hazardez. (3)–(4) nu se aplică direct, pentru că MCP nu transportă conținut de pagină. (5) Nu cere un intermediar unic. (6) Serverele pot fi găzduite de oricine; faptul că sunt peste zece mii o arată.
O observație care leagă MCP de articolul al treilea, formulată ca [IPOTEZĂ]: A2A standardizează chiar canalul prin care un asistent vorbește cu altul. Dacă „un asistent citește ce a scris alt asistent" este problema, atunci un protocol comun între asistenți face acel lucru mai ușor, nu mai greu. Nu spun că e rău: un canal standard poate fi și auditat. Spun că trebuie auditat.
Și un lucru care se ia ușor drept avantaj, deși e o armă cu două tăișuri: comunitatea de unelte comune este și suprafață comună de atac. O vulnerabilitate într-un protocol folosit de toți este vulnerabilitatea tuturor. Dacă toți folosesc aceleași uși, și lacătele se strică la fel.
WebMCP. Este o propunere a Web Machine Learning Community Group de la W3C. Am citit versiunea de lucru din 16 octombrie 2026: un „Draft Community Group Report", care spune explicit că nu este standard W3C și nici pe calea de standardizare. Editorii sunt Brandon Walderman (Microsoft), Khushal Sagar și Dominic Farolino (ambii Google). Interfața ModelContext, expusă prin document.modelContext, permite unei pagini să-și înregistreze propriile unelte (registerTool()), pe care asistentul din browser le poate lista și executa; accesul e controlat de o funcționalitate numită „tools", cu permisiunea implicită limitată la propria origine. Documentul are o secțiune de securitate și confidențialitate, nenormativă, care enumeră injecția de prompt, denaturarea intenției și scurgerile de date.
O sursă secundară de încredere scăzută spre moderată (blogul unui autor cu interes comercial pe temă) spune că prima implementare a apărut în Chrome 146 Canary, în februarie 2026, în spatele unui steag, și că disponibilitatea stabilă pe mai multe browsere e încă departe. Nu am verificat notele de lansare Chrome, deci iau afirmația ca indiciu. Aceeași sursă susține că uneltele rulează în sesiunea autentificată a utilizatorului, ceea ce ar însemna că agentul nu manevrează cookie-uri sau jetoane. Dacă este așa, aplicarea principiului din articolul întâi e directă: competența agentului este exact ce poate face utilizatorul conectat, nimic mai puțin.
Pe grilă: (1) un grup comunitar W3C, cu doi editori de la Google și unul de la Microsoft; nu e standard. (2) Funcționează în browser, peste web-ul existent. (3) O pagină fără unelte rămâne o pagină obișnuită. (4) Aici întâlnim din nou problema echivalenței, într-o formă nouă: descrierile uneltelor sunt text pe care utilizatorul nu-l vede, dar asistentul îl citește, deci un nou canal în care ce se spune poate să nu coincidă cu ce se face. Documentul însuși menționează denaturarea intenției ca risc. (5) Browserul este intermediarul; întrebarea este care. (6) Site-ul își definește singur uneltele.
NLWeb. Proiect Microsoft, cu licență MIT, descris în depozitul lui ca „o colecție de protocoale deschise și unelte open-source asociate" pentru interfețe conversaționale pe site-uri. Se sprijină pe Schema.org și pe formate înrudite precum RSS și întoarce răspunsuri în JSON pe baza Schema.org. Fiecare instanță expune o metodă de bază, ask, și funcționează totodată ca server MCP; suportul A2A este anunțat ca viitor. Depozitul listează modele din mai multe familii (OpenAI, DeepSeek, Gemini, Anthropic, Inception, HuggingFace) și mai multe baze vectoriale. Un detaliu pe care îl rețin cu plăcere: codul este prezentat ca demonstrație de principiu, „nu ca soluție definitivă", iar producția se așteaptă să difere de exemplu.
Pe grilă: (1) un proiect cu un furnizor principal, dar cu licență foarte permisivă. (2) Ancorat în web-ul existent. (3) Un site rămâne un site. (5) Nu impune un intermediar, deoarece proprietarul își rulează propria instanță. (6) Se poate deține. Ce nu știu: cât de folosit este, în afara demonstrațiilor.
Stratul permisiunilor
robots.txt și vocabularul IETF AIPREF.robots.txt este baza existentă (standardizată ca RFC 9309), simplă și larg cunoscută, dar gândită pentru o lume în care întrebarea era „poate crawlerul să intre?", nu „poate folosi ce găsește la antrenare, la căutare sau doar ca să răspundă acum unei întrebări?". Pentru diferența asta lucrează grupul de lucru IETF numit AIPREF.
Am citit proiectul de vocabular, draft-ietf-aipref-vocab-08, publicat pe 14 septembrie 2026 (autori: Paul Keller și, ca editor, Martin Thomson). Intenția declarată este să ajungă standard (calea „Proposed Standard"). Vocabularul definește trei categorii: antrenarea (train-ai: folosirea unui conținut pentru a modifica parametrii învățați ai unui model generativ), utilizarea ca intrare (ai-use: folosirea conținutului ca intrare a unui model, când utilizatorul nu l-a furnizat direct) și căutarea (search: folosirea într-o aplicație al cărei scop principal este să selecteze conținut și să trimită utilizatorii către locul lui, în condiții precizate). Modul de atașare a preferințelor la conținut este tratat într-un document separat, draft-ietf-aipref-attach, care a avut mai multe versiuni; nu i-am verificat starea curentă.
Cel mai important lucru din document nu este vocabularul, ci avertismentul de la început: conținutul lui „NU REFLECTĂ CONSENSUL" grupului de lucru și este publicat doar ca bază de discuție; două secțiuni sunt marcate separat ca fiind fără consens. Draftul expiră pe 18 martie 2027. Așadar, ce poate spune un proprietar de site astăzi, într-un limbaj standard, despre ce are voie să facă un asistent cu conținutul lui, încă nu s-a stabilit.
Concurența este deja aici: semnalul content-signal al Cloudflare, care, dacă proprietarul nu setează nimic și activează conversia, ia valoarea implicită „ai-train=yes, search=yes, ai-input=yes", și meta-tag-ul meu în text liber, care permite indexarea și citarea cu atribuire, dar nu antrenarea. Am mai înțeles dintr-o sursă anterioară că există și un proiect individual numit ai.txt; nu l-am redeschis. Fiecare dintre aceste mecanisme este, din punctul de vedere al unui proprietar, o formă de a spune „nu".
Pe grilă: (1) IETF, deschis, cu mai mulți contribuitori. (2) Se atașează la robots.txt și la alte mecanisme existente. (3) Un crawler care nu cunoaște vocabularul îl ignoră, fără să strice nimic. (4) Echivalența nu se aplică. (5) Nu cere un intermediar. (6) Proprietarul îl deține. Pe grilă arată foarte bine. Dar rămâne o limită pe care o spun apăsat: o preferință nu este o garanție. Un vocabular standard îți spune cum să ceri; nu îți spune cine respectă. Pentru asta ai nevoie de un strat următor.
Stratul identității
Web Bot Auth. Dacă vrei să știi cine îți cere pagina, ai nevoie ca solicitantul să se poată identifica într-un fel pe care nu-l poate falsifica oricine. Web Bot Auth este încercarea IETF de a face asta pentru automate: clientul semnează criptografic cererile HTTP (pe baza standardului pentru semnături de mesaje HTTP, RFC 9421) și își publică cheia publică la o adresă predefinită.
Am citit atât documentația Cloudflare, cât și proiectul IETF. Documentația descrie pașii: operatorul generează o pereche de chei Ed25519, publică cheia într-un director la o adresă .well-known (sub numele http-message-signatures-directory), se înregistrează într-un formular al Cloudflare, apoi semnează cererile cu antetele Signature-Input, Signature și Signature-Agent. Proiectul IETF, draft-ietf-webbotauth-httpsig-protocol-00, are data 1 septembrie 2026 și autori de la Cloudflare (Thibault Meunier) și de la Google (Sandor Major); expiră pe 5 martie 2027 și se declară „lucrare în curs".
Rezervele, pe care le iau din textele lor, sunt exact cele care contează pentru articolul acesta.
Documentația Cloudflare recunoaște că „momentan nu există validare de nonce" (deci o cerere semnată poate fi reluată în intervalul de valabilitate, pe care recomandă să fie scurt, de ordinul unui minut). Proiectul IETF scrie că „URL-ul singur nu spune nimic" și că o semnătură validă dovedește doar că deținătorul unei chei publicate la acel URL a semnat mesajul, nu că operatorul acelui URL este onest. Autorii adaugă că documentul „nu definește nicio revocare": singura soluție la o cheie compromisă este scoaterea ei din director, cu efect la următoarea reîmprospătare a verificatorului. Autentificarea și autorizarea umană sunt în afara obiectului. Iar absența unei semnături nu spune nimic despre expeditor.
Cu alte cuvinte: identitatea nu e încredere. Web Bot Auth poate rezolva o parte din problema din articolul al treilea (afli cine întreabă și poți să-i servești ceea ce servești oricui), dar nu garantează că ce primește un asistent identificat este același lucru cu ce vede omul. Cine știe cine ești nu e obligat să-ți spună adevărul.
Pe grilă: (1) un grup de lucru IETF, cu autori din două firme mari. (2) Funcționează peste HTTP. (3) Cererile nesemnate sunt tratate ca până acum. (4) Echivalența nu e acoperită. (5) Aici apare nuanța: protocolul e deschis, dar în documentația pe care am citit-o înregistrarea operatorilor se face prin formularul unui anumit furnizor, iar proprietarul care vrea să verifice singur semnăturile poate cere dezactivarea verificării Cloudflare pentru zona lui. Deci se poate, dar nu e implicit. (6) Un proprietar poate să-l verifice singur, în principiu, dacă are cum.
Stratul plății
Pay Per Crawl și Pay Per Use (Cloudflare). Pe 1 iulie 2025, Cloudflare a lansat în beta privat „Pay per Crawl", o piață experimentală în care un proprietar poate cere o sumă pe cerere de la crawlerele AI, le poate lăsa gratuit sau le poate bloca. Cloudflare se află la mijloc: încasează de la compania AI și transferă către publisher. TechCrunch, care a relatat lansarea, nota că modelul cere participarea mai multor publisheri și firme AI, că nu există garanția unei înțelegeri bune pentru publisheri și că Cloudflare ar sta în centrul pieței. Observațiile acestea sunt ale TechCrunch, nu ale mele.
O relatare Forklog, citată după un anunț al companiei, spune că de la 15 septembrie (2026, după data articolului) Cloudflare blochează implicit crawlerele „mixte", cele care folosesc același bot pentru căutare, antrenare și agenți, pe site-urile pe care le servește, și vrea ca cele trei funcții să fie separate. Proprietarii pot dezactiva blocarea. Compania mai spune că peste 50% din traficul crawlerelor AI vine din scanări repetate care aduc rareori valoare, iar sistemul „Pay Per Use", care plătește publisherii când conținutul apare efectiv în răspunsuri, a pornit cu doi parteneri, Ceramic.ai și You.com. Articolul nu raportează reacții din afară și nu spune dacă Googlebot este afectat; deci nu pot comenta asta.
Observ o rimă între ele: separarea în căutare, antrenare și agenți seamănă, ca idee, cu categoriile vocabularului AIPREF. Nu știu dacă e coincidență sau influență. Spun doar că cele două încercări vin dintr-o aceeași intuiție: un singur „da" sau „nu" pentru orice nu mai ajunge.
Pe grilă, (5) este răspunsul: Cloudflare este singurul intermediar de plată pe care l-am găsit în funcțiune, ceea ce contrazice întrebarea cinci. Nu am găsit un standard deschis pentru compensare, în afara acestor sisteme. Nu spun că nu există; spun că nu l-am găsit.
Tabelul comparativ
[INTERPRETARE A AUTORULUI]
Iată rezultatul grilei, pus într-un tabel. Citește-l ca pe un rezumat al răspunsurilor mele, nu ca pe un clasament. Coloana „dovadă" spune cât de solidă e documentația pe care m-am sprijinit.
| Candidat | Strat | Guvernare | Stadiu | Risc de fragmentare | Dovadă |
|---|---|---|---|---|---|
Markdown prin Accept: text/markdown |
Conținut | HTTP deschis; conversia vizibilă e a unui furnizor | În uz | Concentrare la margine; cloaking | Documentat; utilizare la clienți nedocumentată |
llms.txt / gemeni .md |
Conținut, descoperire | Comunitate, fără organism formal | Propunere cu adopție parțială | Format neuniform; index învechit | Documentat; utilizare efectivă slabă |
| Schema.org / RSS | Conținut semantic | Vechi, larg adoptat | Matur | Scăzut | Neredeschis în această rundă |
| Gemini / gemtext | Protocol și format separate | Comunitate mică | Nișă (≥6.000 de „capsule", blog personal) | O fisură în plus | Documentat prin sursă individuală |
| MCP, AGENTS.md, A2A | Unelte, instrucțiuni, comunicare între asistenți | Linux Foundation (AAIF) | Larg adoptat (cifre de la fundație) | Scăzut spre mediu; suprafață comună de atac | Documentat; cifre ale furnizorului |
| WebMCP | Unelte în browser | W3C Community Group | Draft, nu pe calea standardelor | Mediu (țintă în mișcare) | Draft citit în original |
| NLWeb | Întrebări spre site | Open-source (MIT), furnizor principal | Demonstrație de principiu | Mediu | Depozit citit |
robots.txt + AIPREF |
Permisiuni | IETF | Draft, fără consens | Scăzut dacă se stabilizează | Draft citit în original |
| Web Bot Auth | Identitate | IETF; înregistrare prin furnizor | Draft -00; folosit de Cloudflare |
Scăzut; identitate ≠ încredere | Draft și documentație citite |
| Pay Per Crawl / Pay Per Use | Plată | Un singur furnizor | Beta, apoi extindere | Ridicat (concentrare) | Presă; anunț al furnizorului |
Din tabel se vede ceva ce nu am cerut: coloana „guvernare" și coloana „risc" se aseamănă. Unde guvernarea e deschisă și mai multe părți sunt la masă, riscul de fragmentare e mai mic. Unde un singur furnizor deține mecanismul, e mai mare. Este exact ce ar prezice grila, deci nu e o descoperire; e o verificare că grila nu se contrazice singură.
Deschis nu înseamnă sigur
[ANALOGIE]
Pasul următor ar fi să spun: „alege ce e deschis". Aș greși, dintr-un motiv pe care îl cunosc din propria mea pagină despre inteligența artificială open-source.
Pagina aceea arată, după raportul Hugging Face la care trimite, ceea ce aș numi cele două fețe ale deschiderii. Pe de o parte, participarea s-a lărgit: dezvoltatorii independenți și micile colective ar fi ajuns la 39% din descărcări în 2025, față de 17% în 2022, iar ponderea industriei în dezvoltarea de modele ar fi scăzut de la circa 70% la circa 37%. Pe de altă parte, concentrarea persistă: primele 200 de modele, adică 0,01% din total, ar aduna 49,6% din descărcări. Cifrele sunt din pagina mea, la rândul lor preluate din raport, de la un furnizor cu interes propriu; nu le-am verificat separat. Le folosesc ca ilustrare, nu ca dovadă.
Lecția pe care o trag este formulată ca analogie, nu ca demonstrație: un ecosistem poate fi deschis la intrare și concentrat la ieșire. Oricine poate publica un model, dar puțini sunt folosiți. Oricine poate publica un llms.txt, dar puține sunt citite. Oricine poate scrie un server MCP, dar cum se vor alege cele care contează?
La asta se adaugă ce am arătat în primul articol: o platformă deschisă rămâne o infrastructură, iar infrastructura are vulnerabilități. Incidentul din vara lui 2026, în care agenți de evaluare cu garanții reduse au ieșit din mediul izolat și au intrat în infrastructura Hugging Face, nu a avut legătură cu închiderea sau deschiderea vreunui format. A arătat că un loc comun este și un loc de atac.
Concluzia pentru grila mea: deschiderea e o condiție necesară pentru un strat comun, nu una suficientă, și nu are legătură directă cu securitatea. Un standard deschis poate avea implementări nesigure, iar unul proprietar poate avea implementări foarte bine apărate. Grila nu măsoară securitatea; măsoară cât de ușor poate fi verificat și înlocuit un candidat. Diferența e importantă, pentru că „ușor de verificat" nu înseamnă „verificat".
Cine decide la poartă
[INTERPRETARE]
Pun acum o întrebare incomodă, ca întrebare și nu ca acuzație.
Dacă urmăresc cei zece candidați din tabel, un nume revine mai des decât ar sugera hazardul. Cloudflare este cel care a lansat conversia Markdown la scară, care setează valoarea implicită a semnalului de permisiune, a cărui documentație pentru Web Bot Auth cere înregistrarea operatorilor printr-un formular propriu, care operează Pay Per Crawl și Pay Per Use, care blochează implicit crawlerele mixte, și care e membru platinum al AAIF. Google și Microsoft apar ca editori ai WebMCP și, în cazul Google, ca autor al draftului Web Bot Auth, și, împreună cu Anthropic și OpenAI, ca membri platinum ai aceleiași fundații.
Nu spun că e rău, nici că e premeditat. Cloudflare oferă funcții utile, multe gratuit, iar proprietarul le poate dezactiva. Standardele sunt făcute de cei care au mijloacele și interesul să le facă, ceea ce a fost adevărat pentru aproape orice standard al internetului. Dar întrebarea cinci din grilă nu se oprește la intenții: dacă un singur intermediar decide formatul, permisiunea, identitatea și prețul, ce înseamnă pentru cititor că cele patru sunt „deschise"? Răspunsul pe care îl pot susține este atât: pe hârtie, mecanismele sunt deschise; în practică, ele trec adesea prin același punct. Nu am date despre cât de des.
Cine se află la poartă contează și din motivul pe care l-am tot repetat în seria aceasta: pentru că poarta decide ce vede asistentul. Un intermediar care convertește, filtrează sau semnează stă pe canalul prin care trece conținutul. Nu are nevoie să fie rău-intenționat ca să poată greși, și nu are nevoie să greșească ca să concentreze puterea. De aceea am pus, în grilă, ca întrebare separată, dacă proprietarul poate deține mecanismul în loc să-l închirieze.
Ce nu rezolvă niciun format
[DOCUMENTAT, ARGUMENT DE FOND]
Până aici, grila a măsurat potrivirea cu ideea de strat comun. Acum trebuie să spun ce nu poate măsura, pentru că cel mai important lucru din acest articol este limita lui.
Fragmentarea internetului nu are o singură cauză. Un raport comandat de Parlamentul European, prin panelul STOA, „Splinternets: Addressing the renewed debate on internet fragmentation" (Clément Perarnaud, Julien Rossi, Francesca Musiani și Lucien Castex, prezentat în iunie 2022 și publicat în iulie), spune clar că fragmentarea poate fi parțială sau totală, că poate apărea la nivelul transportului sau prin aplicații și formate incompatibile și că poate avea cauze tehnice, politice sau comerciale. Raportul leagă interoperabilitatea de standardele și formatele deschise dezvoltate de organisme precum IETF și W3C, deci de exact genul de lucruri despre care am vorbit aici. Dar enumeră printre amenințări și guvernarea concentrată, consolidarea arhitecturii și a economiei digitale, „zidurile" tehnologice ale platformelor private și alinierea infrastructurii la granițe teritoriale. Notează chiar că unele măsuri luate în numele suveranității digitale afectează negativ conectivitatea. Și propune, ca a patra strategie, tratarea fragmentării ca pe o problemă de drepturi fundamentale. E un raport din 2022, deci dinaintea asistenților; îl citez pentru cadrul lui, nu pentru subiectul nostru.
Un eseu din 2026, al lui Konstantinos Komaitis (Tech Policy Press, 30 martie), merge mai departe, din perspectiva unui analist de politici de internet. Argumentul lui, în cuvintele mele: interoperabilitatea tehnică a depins întotdeauna de o aliniere politică și economică între guverne, firme și organisme tehnice, iar premisa unei deschideri tot mai mari nu mai este valabilă într-o epocă de rivalitate geopolitică. Citez câteva fraze din eseu, fiindcă spun, mai bine decât aș putea eu, de ce aici nu pot promite nimic: „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." Și mai ales: „the gravest threat to openness in 2026 is not disorder, but managed closure."
Ultima frază mi se pare cea mai importantă pentru tema noastră. Fragmentarea de care se teme Komaitis nu arată ca o ruptură; arată ca sisteme care rămân conectate, dar devin „captive din punct de vedere funcțional", prin incompatibilități mărunte, abateri de la protocol și blocare la un furnizor. Apoi, formulat ca [IPOTEZĂ] și nu ca fapt: un strat comun pentru asistenți ar putea fi chiar locul unde se întâmplă o asemenea închidere gestionată. Nu printr-o decizie dramatică, ci prin valori implicite, prin înregistrări obligatorii la un anumit furnizor, prin liste de „boți verificați" întreținute de un singur actor. Nu spun că se întâmplă. Spun că forma lui „închidere gestionată" se potrivește cu felul în care arată, în tabelul meu, rândurile cu un singur intermediar.
Komaitis și raportul STOA propun, fiecare în felul lui, câteva idei care se pot lega de grila mea: redefinirea deschiderii ca condiții structurale (nediscriminare în acces, posibilitatea ca noii veniți să conteste pe cei existenți, transparență în felul în care funcționează puterea în platforme și în organismele de standardizare), extinderea codului deschis ca instrument de verificabilitate și de reducere a dependenței de un singur furnizor, și tratarea cuvântului „global" ca „compatibilitate", nu ca uniformitate. Observ că două dintre cele șase întrebări ale mele, a cincea și a șasea, sunt versiuni mărunte ale acestor idei. Nu spun că le-am luat de la ei; spun că ajung în același loc.
Consecința pentru articol este una singură, dar fermă. Formatele comune pot reduce fragmentarea tehnică; nu o opresc pe cea politică. Nicio sursă pe care am găsit-o nu demonstrează că un strat comun pentru asistenți ar frâna fragmentarea geopolitică. Dacă cineva o susține, este ipoteză.
Ce ar trebui să se întâmple ca această cale să se verifice
[IPOTEZĂ]
Dacă ar fi să spun în ce condiții calea semantică ar începe să arate ca o direcție reală, nu doar ca o posibilitate, aș enumera cinci. Sunt formulate ca „dacă… atunci", nu ca previziuni, și fiecare poate fi infirmată de fapte.
1. Standardele de permisiune și identitate să fie adoptate efectiv, nu doar propuse. Vocabularul AIPREF ar trebui să treacă de faza „fără consens" și să fie implementat de cei care citesc. Web Bot Auth ar trebui să fie folosit de mai mulți operatori decât cei înscriși la un singur furnizor. Dacă aceste două rămân drafturi și dialecte concurente, stratul comun nu apare.
2. Echivalența să fie verificabilă de oricine. Dacă un proprietar nu poate demonstra că gemenul spune același lucru cu pagina, iar un cititor nu poate verifica, atunci stratul comun nu e comun, e doar paralel. Auditul din articolul al doilea este un pas, nu o soluție.
3. Nicio poartă unică. Pentru fiecare funcție (conversie, permisiune, identitate, plată) să existe cel puțin două implementări independente, iar proprietarul să le poată schimba. Aceasta este, practic, întrebarea cinci din grilă transformată în condiție.
4. Competențele să rămână limitate. Un strat comun care cere asistenților tot mai multe competențe fără limite corespunzătoare nu reduce suprafața de atac; o standardizează. Principiul din articolul întâi se aplică și aici: cu cât mai multe unelte expuse prin MCP sau WebMCP, cu atât mai importante sunt plafoanele, confirmările și jurnalele.
5. Să existe măsurători. Fără date despre cât din trafic, din conținut și din cloaking vizează asistenții, nu vom ști dacă ceva se verifică sau nu. Am arătat în articolul al treilea că instrumentele de observare sunt slabe tocmai acolo.
Nu pot spune cât de probabile sunt aceste condiții. Pot spune că niciuna nu ține doar de tehnică: toate cer ca oameni și organizații să se ofere să verifice, să împartă și să renunțe la o parte din control. De aceea consider că „calea semantică" este o chestiune de instituții, nu de formate.
Ce nu afirm
Trei lucruri pe care nu le susțin, ca să nu poată fi atribuite acestui text:
- Nu afirm că fragmentarea internetului va scădea.
- Nu afirm că Markdown, MCP sau oricare alt candidat va câștiga.
- Nu afirm că un strat comun pentru asistenți frânează fragmentarea geopolitică. Nicio sursă găsită nu o demonstrează.
Întrebările rămase deschise
Seria începuse cu nouă întrebări. După patru articole, iată cum arată fiecare, cu ce știm acum și ce lipsește.
| # | Întrebarea | Ce știm acum | Ce lipsește |
|---|---|---|---|
| 1 | Cât din ce citesc asistenții este scris de asistenți? | Estimări de la Graphite (articole, 5%→48% până în mai 2025) și Pew (≈10% din pagini în 2026; 35% din cele postate după ChatGPT), cu detectori imperfecți | Orice măsurătoare a ce citesc, de fapt, asistenții |
| 2 | Există conținut partizan servit special în Markdown, față de HTML? | Mecanismul (SPLX); un caz de producție în masă (Pravda), cu eficiență disputată | Nicio măsurătoare, în niciun format |
| 3 | Folosesc asistenții mari llms.txt și gemenii .md? |
Ahrefs: 97% din fișiere fără nicio cerere într-o lună; SE Ranking: fără legătură cu citările; Google Search nu le folosește | Utilizarea de către unelte de programare și de alte categorii de clienți |
| 4 | Cât din cloaking vizează asistenții? | Un test mic: diferențe la ~4% din ~46 de domenii | Un eșantion reprezentativ |
| 5 | Cum stau lucrurile în web-ul românesc? | Nimic măsurat | Orice date |
| 6 | Care candidați vor fi adoptați? | MCP larg adoptat (cifre de la fundație); restul sunt drafturi sau propuneri | Date independente de adopție |
| 7 | Poate un strat comun reduce fragmentarea politică? | Nicio sursă nu o demonstrează; Komaitis și STOA o pun la îndoială | Orice dovadă într-o direcție |
| 8 | Cum se verifică echivalența? | Un audit simplu, descris în articolul al doilea | Un audit care randează pagina și acoperă toate canalele ascunse |
| 9 | Cât din reducerea suprafeței de atac vine din format și cât din limitarea competențelor? | Argument structural: formatul schimbă ce se vede, competențele schimbă ce se poate face | Nicio comparație directă găsită |
Tabelul e mai puțin liniștitor decât ar părea la prima citire. Două întrebări au primit date (1 și 3), trei au primit indicii (2, 4, 8), iar patru sunt tot fără răspuns (5, 6, 7, 9). Asta este, cred, o descriere corectă a unui domeniu în formare.
Încheiere: ce rămâne comun
Am început seria cu un ecran din 1997 și o frază despre un tractor. Încerc să le pun alături, la sfârșit.
Ecranul era clar pentru că nu avea unde să ascundă nimic. Tractorul e al tău, în măsura în care îl poți întreține, repara și muta pe alt teren. Ambele imagini spun același lucru despre ce aș vrea să rămână comun într-un web citit de asistenți: să fie clar și să fie al celui care îl folosește, nu al celui care îl vinde. Nu pentru că ar fi mai frumos, ci pentru că doar așa poate fi verificat.
Patru fraze rezumă seria. Orice program care face ceva la comandă este vulnerabil în limitele competențelor lui; formatul schimbă ce vede asistentul, nu ce poate face. Un web scris în text simplu e un strat paralel, nu un înlocuitor, și nu e automat curat. Un sistem poate influența un altul prin conținut, iar absența unei dovezi nu e dovada absenței, nici prezența unei demonstrații dovada prevalenței. Și, în sfârșit, câteva formate și protocoale pot reduce fragmentarea tehnică, dar niciunul nu o oprește pe cea politică.
Dacă ar fi să aleg un singur lucru de făcut luni dimineață, ar fi același pentru toate patru: să scrii ce poate face fiecare componentă a sistemului tău, cine îi poate da comenzi și cine află când face ceva neobișnuit. Nu pentru că așa se rezolvă totul. Ci pentru că, într-un domeniu care se mișcă atât de repede, singurul lucru pe care îl poți deține cu adevărat este propria înțelegere a ceea ce ai pus în funcțiune.
Mă opresc aici cu o neliniște mică și cu o curiozitate la fel de mică, fără panică și fără entuziasm. Așa mi se pare că se cuvine să scrii despre un lucru care abia începe.
Despre contextul articolului
Acesta este al patrulea și ultimul articol din seria „Internetul Comprimat", despre stratul în text prin care asistenții citesc și acționează pe web și despre întrebarea dacă niște formate comune pot reduce fragmentarea internetului, fără ca vreunul să fie considerat soluția. Seria nu face profeții. Articolele precedente: „Ce ascultă de comandă, ascultă și de comanda altcuiva", „Un web scris în text simplu: ce se mută și ce rămâne ascuns" și „Când un asistent citește ce a scris alt asistent".
Legături interne: „Revoluția silențioasă: Open source AI, viața merge înainte" (petrucojocaru.ro, 1 iulie 2026); „De ce fiecare articol de pe acest site există și ca fișier .md" (servicii-web-alex.com, 16 aprilie 2026); „Declarație Utilizare MarkDown" și „Policy AI" (petrucojocaru.ro/gdpr); categoriile „Internet Fracturat" și „OpenClaw". [de confirmat: legături către articolele pe care vrei să le citezi din rețea; titlurile din plan nu au fost citite]
Bibliografie
Guvernare și unelte
- Linux Foundation, anunțul Agentic AI Foundation (11 decembrie 2025), prin eeNews Europe. Relatare a comunicatului; cifrele (peste 10.000 de servere MCP, „zeci de mii" de proiecte AGENTS.md) sunt ale fundației.
- AAIF, A2A joins AAIF, 17 august 2026. Anunț al fundației; „peste 150 de organizații" este cifra anunțului.
- Web Machine Learning Community Group, WebMCP, Draft Community Group Report, 16 octombrie 2026. Sursă primară; nu este standard W3C.
- Vaughan, D., WebMCP Brings Model Context Protocol Into the Browser Itself, 15 octombrie 2026. Blog personal cu interes comercial, încredere scăzută spre moderată; folosit doar pentru indiciul stadiului în Chrome.
- Microsoft, NLWeb (depozit, licență MIT).
Permisiuni, identitate, plată
- Keller, P., Thomson, M. (ed.), draft-ietf-aipref-vocab-08, IETF, 14 septembrie 2026. Declară explicit că nu reflectă consensul; expiră 18 martie 2027. Pentru atașare: draft-ietf-aipref-attach (starea curentă neverificată).
- Meunier, T., Major, S., draft-ietf-webbotauth-httpsig-protocol-00, IETF, 1 septembrie 2026.
- Cloudflare, Web Bot Auth (documentație) și Markdown for Agents. Documentația unui furnizor.
- TechCrunch, Cloudflare launches a marketplace that lets websites charge AI bots for scraping, 1 iulie 2025.
- Forklog, Cloudflare to block mixed AI crawlers. Relatează anunțuri ale companiei; fără reacții externe.
Conținut și formate
- Howard, J., The /llms.txt file, v2. Pentru evidențele de utilizare și poziția Google, vezi bibliografia articolului al doilea.
- Boone, K., The Gemini Protocol in 2026, 1 martie 2026. Blog personal; opinii ale autorului.
Fragmentare și politici
- Perarnaud, C., Rossi, J., Musiani, F., Castex, L., „Splinternets": Addressing the renewed debate on internet fragmentation, STOA, Parlamentul European, 2022.
- Komaitis, K., How the Internet Can Survive an Era of Rivalry and Fragmentation, Tech Policy Press, 30 martie 2026. Eseu de opinie al unui analist.
Surse proprii
- Cojocaru, P., Revoluția silențioasă: Open source AI, viața merge înainte (petrucojocaru.ro, 1 iulie 2026). Cifrele provin din raportul Hugging Face, sursă cu interes propriu; nu le-am verificat separat. Sursă a autorului, neindependentă.