Ezt az eseményösszefoglalót Claude készítette, Tim O’Reilly szerkesztésével, a beszélgetés átírt jegyzete alapján. 2026. október 20-án Tim O’Reilly egyórás beszélgetést vezetett Alex Komoroskéval, a Common Fabric vezérigazgatójával és társalapítójával, aki több mint egy évtizedet töltött a Google-nél termékmenedzserként és a Chrome, Google Maps és Google Earth termékekhez kapcsolódó termékmenedzsment igazgatójaként, majd a Stripe-nál foglalkozott vállalati stratégiával. Alex a Resonant Computing Manifesto társszerzője; Tim korábban aláírta a kiáltványt, és a beszélgetés során a Common Fabric alapelveiről és műszaki megoldásáról beszéltek. A Common Fabric fogyasztói terméke még nem nyilvános, de Alex a beszélgetés előtt bemutatta azt Timnek.
A Resonant Computing Manifesto fő pontjai
A Resonant Computing Manifesto öt alapelvet foglal össze a „rezonáns” technológiához: private (a saját adatok feletti gondnokság), dedicated (érdekkonfliktus nélküli), plural (nincs központosított, fölösleges hatalom), adaptable (alkalmazkodó, a készítők konkrétan nem feltétlenül előre definiált feladatokat is képes ellátni) és prosocial (közösségi értelemalkotást segíti). Alex megkülönbözteti a „hollow” és a „resonant” élményeket: az előbbi használat után megbánást hagy, míg az utóbbi táplál és tartós értéket ad. Szerinte a jelenlegi ipar hatékonyan gyárt üres, de addiktív élményt, és az AI-átmenet lehetőséget ad a normák és architektúrák alapvető újratervezésére.
Adatvédelem, bitek és a bizalom „fizikája”
Tim O’Reilly rákérdezett Alex privátságról alkotott elképzelésére. Alex nem a HIPAA-szerű „elzárt” adatkezelésre gondolt, ahol az adatokhoz még a tulajdonos sem fér hozzá; helyette azt javasolja, hogy az adat akkor lesz hasznosabb, ha az irányítás a felhasználónál van. Válaszát három részre bontotta:
- Contextual integrity: Helen Nissenbaum elméletét idézte, amely szerint az adatot a felhasználó szándékainak és elvárásainak megfelelően kell használni, kerülve a káros és váratlan felhasználásokat.
- Atoms vs bits: a fizikai világban a viselkedés látható és társadalmi következményekkel jár; a bitek világában a láthatatlanság miatt cégek könnyebben „belenéznek az ablakba”, és a kombinált adathasználat nagyobb pénzügyi ösztönzőt ad a visszaélésre.
- Az adatok vírusossága: a digitális adatok másolhatók és terjeszthetők teljes pontossággal és szinte költség nélkül, ezért egyszer kikerülve a felhasználó irányítása alól, gyakorlatilag elvesznek.
Alex szerint az iparág eddig három, elégtelen mechanizmust alkalmazott: a senki által elolvasatlan felhasználói feltételeket, a jogosultság-kéréseket (amelyeket ő „felelősségmosó dialógusoknak” nevezett), és az adat-silokat, ahol minden alkalmazás csak egy szeletet lát a felhasználóról.
A Common Fabric megközelítése: az adat saját szabályokat hordoz
A Common Fabric alapötlete, hogy az adathoz mindig tartozik egy metaadat „sidecar”, amely két dolgot visz magával: kriptográfiai eredetet (ki végezte az utolsó számítást, mely szoftver ujjlenyomata, bemenetek követhetősége) és egy politikát, amely meghatározza, mikor és hogyan hozható nyilvánosságra vagy használható az adat. A matematikai megközelítés hasonló a blokkláncokéhoz, de a Common Fabric nem igényel globálisan konzisztens, pénzeszköz-vezérelt főkönyvet.
Ezen politikákat egy nyílt forráskódú futtatókörnyezet (Alex kifejezése szerint a „core reaction chamber”) ellenőrzi és érvényesíti. A runtime egy javasolt számítási gráfot kap, amely nem megbízható kódot hajtana végre bizonyos adatokon és politikákon; ha a számítás szabályos, lefut, frissül a provenance lánc és minden érintett értesítést kap; ha nem, a runtime leáll és leíró hibát ad (például hálózati kérések, amelyek titkos adatból származó információt szivárogtatnának). A felhasználó futtathatja a runtime-ot saját gépén, de a legtöbben felhőszolgáltatóktól, ún. AI service providerektől veszik igénybe, ahol a runtimeot Trusted Execution Environmentsben (TEE) futtatják — hardverileg elszigetelt környezetekben, ahol a szolgáltató nem lát be, és kriptográfiailag bizonyítható, hogy a runtime nem módosult.
Mintaalapú szoftver (patterns)
A Common Fabric szoftvere „pattern”-ekből áll: kis, nem-megbízhatónak kezelt kódblokkokból, amelyeket TypeScriptben írnak és React-szerű felépítéssel. Alex hangsúlyozta, hogy „untrusted” itt biztonsági értelemben szerepel: nem kell megbízni bennük, mert az adatok politikája határozza meg, mit tehetnek. Egy pattern hat képességgel bír:
- Tetszőleges számítást végezhet.
- Származtatott adatot hozhat létre, amely perzisztál és más pattern-ek számára elérhető.
- Különböző kontextusokra UI-t generálhat (például sötét mód vagy előnézeti chip), csak akkor számítva, amikor használják.
- Hálózati kérést tehet, ha a politika megengedi (LLM-hívások ilyen kérések).
- Almintákat hozhat létre vagy induló mintákat tölthet le az internetről, illetve LLM által menet közben generált almintákat hozhat létre.
- „Kívánhat” több adatot — azaz expresszálhat adatigényt, amelyet más patternek vagy LLM-ek teljesíthetnek.
Alex bemutatott egy példát: egy ételtervező pattern kívánhatná a felhasználó kedvenc ételeit; ez a kívánság megvalósulhat egyszerű szövegdoboz felajánlásával, korábbi receptek elemzésével vagy a felhasználó Gmailjének LLM-mel történő feldolgozásával; ha az e-mailek bizalmasak, a leszármaztatott eredmény is bizalmas marad.
Taint, szabályok és a típusellenőrzés analógiái
A Common Fabric információáramlás-ellenőrzési modelljében az adat „tainted” lesz, ha egy titkos forrással érintkezett, és örökli annak korlátozásait. A cél az, hogy minél kevesebb adat legyen megfertőzött, hogy a hálózati kérések később biztonságosan végrehajthatók legyenek. A compiler feloldja a pattern-ek adatfolyamait: ha a kód csak továbbad egy tokent, a rendszer kezelőt ad neki a token helyett, így a kód maga megmarad nem-megfertőzöttnek. Alex párhuzamot vont Rust borrow checkerével: a taint-checker „nyaggat”, de az LLM-ek nem türelmetlenek; képesek a szükséges változtatásokat automatikusan elvégezni. Ha a szoftor fordul, strukturálisan biztonságos — használhatóságát persze külön értékelni kell.
A rossz és a veszélyes minták kezelése
Alex elismerte, hogy lesznek gyenge vagy „szar” pattern-ek — a közösségi válogatás az, ami a jókat kiemeli. Sokkal inkább aggódik a veszélyes pattern-ekért, amelyek visszaélhetnek adatokkal. Példaként hozta a chat-alkalmazások piszkozat-mezőjét: ma semmi nem garantálja struktúrálisan, hogy a vázlat tényleg csak a felhasználó számára maradjon látható, mielőtt megnyomja a Send gombot. A Common Fabricben egy alapértelmezett politika megteheti, hogy a vázlat bizalmas marad, amíg a felhasználó kifejezetten nem deklasszálja.
Alex elismerte, hogy a rendszer kifutása után rengeteg sarokesetet fognak találni; ezért a nyílt mintakészletnek és a politikáknak együtt kell fejlődnie, és a delegált bizalmat (trust delegation) fontos szerepet játszik abban, hogy ki melyik alapértelmezéseket fogadja el.
Hogyan jönnek létre és hogyan vándorolnak az adatok — visszaszerzés, exportálás
Tim és Alex beszéltek arról, hogy miért ragasztják magukhoz a felhasználókat a nagy szolgáltatók: a szolgáltatások felhalmozott adatai miatt. Alex szerint a helyes keret a „data reclamation” — a felhasználó által betett biteknek vissza kell jönniük. Példaként említette a msgvault nyílt forráskódú projektet, amely helyi Gmail-archívumot tart, így ügynökségek és agentek lokális másolaton dolgozhatnak a korlátozott API-hívások helyett.
Az üzleti és költségoldal
A műveletek számítása és tárolása költséges. Alex rámutatott: ha nem te fizeted a számítást, akkor az a számítás valaki másnak dolgozik. A Common Fabric modellt úgy képzeli el, hogy a felhasználók vagy saját gépeiken futtatják a runtime-ot, vagy AI service providerektől vesznek szolgáltatást, amelyek TEE-ket használnak és díjat számolnak fel tokenekért, compute-ért és tárolásért. Ha a felhasználók váltani tudnak szolgáltatók között, akkor a haszonkulcsok alacsonyak maradhatnak. Alex elismerte, hogy a fogyasztók ellenállnak a szoftverért való fizetésnek, de az LLM-tokenek nemtriviális marginja nyitást ad a fizetős modellre.
Nyílt forráskód alul, termék felül
Alex elmondta, hogy az alap runtime és a pattern-rendszer nyílt forráskódú; önmagukban demonstrációnak tűnnek, ezért a Common Fabric egy fogyasztói terméket épít tetejükre. A termék még fejlesztés alatt áll, de Alex hálózati hatásokat vár, amikor több felhasználó és minta csatlakozik az ökoszisztémához. A minták egy részét nem feltétlenül emberek írják majd: Alex és társalapítója, Berni Seefeld, azt jósolták évtizedek óta, hogy az AI szoftvert fog írni, és így agentek fogják előállítani a szükséges mintákat.
Vállalati forma és hosszú távú ösztönzők
Common Fabric közhasznú (public benefit) vállalatként szerveződik; Alex elmondta, hogy Eric Ries tanácsát használta az örök hosszútávú gondolkodás beágyazására, és rámutatott, hogy a hosszú távú szervezetek hajlamosabbak figyelemmel lenni külső hatásaikra.
Hol tartunk és miért számít
Tim O’Reilly szerint az AI lehetőség a „reset”-re: új üzleti és technikai modellek jöhetnek létre, amelyek nem a megfigyelési kapitalizmus mechanizmusaira épülnek. A Common Fabric műszaki és jogi-üzleti megközelítése — adatokhoz kötött politika, provenance, nyílt runtime, TEE-alapú futtatás és pattern-ek — egy lehetséges út ennek elérésére. Alex óvatosan nem ígért tökéletes biztonságot, de azt állítja, hogy ugyanazon biztonsági költségvetésből a felhasználók többet érhetnek el, ha az adat a felhasználó kontrolja alatt van és a rendszerek strukturálisan betartatják a szabályokat.
Záró gondolatok
A Common Fabric egy olyan kísérlet, amely egyszerre technikai és normatív választ ad arra a problémára, hogy a jelenlegi internetes és AI-ökoszisztéma sokszor a felhasználók rovására skálázódott. A projekt ötlet- és implementációs elemei — rezonancia-elv, metadata sidecar, provenance lánc, politikával ékesített adat, nyílt runtime és pattern-ek — egyaránt arra törekszenek, hogy az AI-vel bővített szoftverek inkább táplálják, semmint kizsákmányolják a felhasználókat. Alex és Tim szerint a következő években az lesz a kérdés, hogy az ökoszisztéma és az üzleti modellek követik-e ezt az alternatívát.
