Why Kaba?

attention is all you need. train yours.

Kaba scratches our own itch. As a way to get upstream of the overreach of tech companies (one specific example is the inability to verify data on a given system, being that data is now issued via API). As a way to harness our own inputs and outputs and train on that compounding value. As a fortress to protect from becoming part of the Useless Class. And as a way to invite others to join in that same endeavor.. to learn, grow, tend to your garden, and share your learnings with others. To build, create, and collaborate on those projects.

Kaba exists to create a movement where we stop being users and start being builders. User is a pejorative (always-has-been-meme.jpeg). To return to the essence of the hacker mentality. RTFM. Tinker. Ask for help, but don’t be helpless.

AI (or machine learning, algorithms of any kind) need data. In the case of making it useful for you, they need your data. To make AI more useful, it needs most/all of your data. To make it maximally useful, it needs that data in real-time. In the end, the value will be actually training purpose built models on that data as close to continuously as possible.

This raises many questions around security, privacy, IP, etc., and if you skip to the end of this line of reasoning, the single load-bearing item is trust. Do you trust the model companies? Do you trust the hyperscalers? Do you trust your system?

Except, that too is the wrong question. Upstream of “do” you trust is “can” you trust.

Beyond all of the betrayals, there has been a steady march towards the technicaly inability to trust technology companies.

“Trust, but verify” has been the battle cry in the security industry for some time. In the days of local computing, this was physically doable. You could write a custom kernel module and verify the raw data on the system. With the rise of walled gardens, cloud, and subscription everything, the ability to verify has all but disappeared. Apple, Windows, and Chrome, the places where the vast majority of our digital lives exist, have taken this capability away. Data is now issued via API. You can still write the kernel module, but it doesn’t mean you have access to the raw data to compare.

You cannot verify. Therefore, you cannot trust.

Our firm stance is, if you have not already, from the point of these words hitting your cornea, you should endeavor to reclaim and own all of your data. By the way, ‘You’ in this case applies equally to individuals, families, groups, small businesses, and enterprises. The stakes are too high. In the end, when there are models that can build virtually any arbitrary infrastructure, product, or experience, they will still rely on your data. So best you start gathering it and tending to it now.

This all led us to the idea of Kaba. What if we could extricate ourselves from these unverifiable products and services? What could we look towards as a blueprint to create our own environments?

Lots of long discussions and hard thinking later, the answer basically resolved to, Linux + web technologies + security + special sauce + iterate. One key ingredient is the starting point, creating a path dependence that is likely irreplicable.

Linux runs the internet. Google search? Linux. Those LLMs that cost billions to train? They are trained on Linux boxes. ‘The Cloud’? Linux. At this point, Microsoft is basically a Linux wrapper.

The Web is the greatest distribution mechanism the world has ever known. The browser was built to run arbitrary code safely. Web technologies enable bidirectional, real-time communications. And with WebAssembly, you now have access to run compiled code natively in the browser + access to system level / peripherals.

Why wouldn’t the future run on Linux + web (other than the big companies actively fighting this eventuality)? In the end, open and secure will win out. Not because it’s better tech (it is), but because of the capability it will enable.

Add in decades of security expertise built in from Day 0, and the recipe begin to get interesting.

The Problem

We are often asked what problem we are solving. This is difficult to distill, as fight against narratives, fight for relevance, fight time, fight for resources. We fight against The Current Thing and first order thinking. We fight grifters, Johnny come latleys, and naysayers.

We also fight for things. Science, security, privacy, markets, fun, value, and our own enjoyment.

LLMs (and the other classes of models and their offshoots, diffusion, lora, etc.) are quite clearly a new paradigm in computing. And with any significant change comes opportunity and peril. Just look at the narratives around SaaSpocalypse, The Permanent Underlcass, layoffs, moats, and value creation.

Well, in a world where virtually anyone can build virtually anything, what problem are we solving?

At a high level, we believe it’s a problem that we are all users, and want to see a world where we are all builders. Specifically, stop using the output of someone else’s learning algorithm and start building your own.

If virtually anyone can build virtually anything, then software is not the moat. The next frontier is not appending LLMs (or other types of learning algorithms) to existing products, services, and data. That is merely a v1, the skeumorphic, local minima in which most exist today.

The frontier is building models, applying learning algorithms directly to your data / environment, and being the caretaker of your own library of models. The direct connect of dynamic, contextual data and expert, purpose built algorithms.

Stop solving AI problems with software. Build from the bottom up with learning algorithms.

Physical vs. Digtial

One way to frame the problem is as follows:

We have autonomous vehicles in the sea, on land, and in the air, but have no autonomous software (CRM, ERP, email that answers how you would given some dynamic context).

AI is working in the physical world -- FSD, Alphafold, materials science -- but not the digital world.

Your mother can hop in a car after putting her groceries in the back, push a button, and play Candy Crush all the way home, but enterprise CISOs don't allow automated ticket remediation in the Security Operations Center.

Why?

Well, it’s twofold. We don’t have the vehicle in the digital world, and we don’t deal with the same constraints as the physical world.

The Vehicle

Let’s use FSD as a first example. It turns out that building bottoms up world models of how people drive is a more efficient way to train the algorithm as compared to created a massive codebase of complex if-this-then-that instructions.

Why rely on image recognition of what a stop sign looks like (in the US, a red octogon with big white letters saying STOP) when you can just infer what drivers do at e.g. a four way stop every day?

Think about it. What if the garbage truck runs over the sign? What if the snow is piled up too high to see the sign? What if the storm blows it over? What if the power goes out and the car sensors/cameras can’t see the stoplights because they are out?

It is much more sensible to observe and transcribe the primary source, real-time data of how actual drivers interact with their environment. Observe and transcribe. Then create a theory. The scientific method ftw.

Constraints

Speaking of that, in science we have laboratories. We have finely tuned and calibrated tools, sensors, and repeatable workflows. One must contend with the constraints of the laws of physics. In the aforementioned FSD example we have roads, signs, and laws that act as constraints.

The digital world is much less constrained.

For one, we don’t have roads, signage, and laws that are invariable. The digital environment changes by the millisecond.

And where we do our work is more akin to the NYC subway than a clean room / laboratory, whatwith all of the ads, malware, and, now, nondeterministic computing. Ads in the start menu, ads at the bottom of CNN.com that carry malware, different IP addresses, different routes, and dead links.

And, we don’t have the vehicle strapped with cameras and sensors to observe and transcribe our pathways. The OS, the browser, and the myriad applications we use collect much of that data, but not all, and they certainly don’t make it easy for us to do our own collection. In fact, this goes against their entire being. The incentives are not there.

Until Kaba.

Linux Only as a Feature

When building the future, one must choose foundations that will make it to that future. And as security people, it would defeat the purpose to do anything but choose Linux.

Closed systems mean that by default you own nothing. Soon these paid for operating systems will be pushing AI to the point that separating your own intention from the data they are forcing into your face will make the entire process a moot point. Using a paid OS means there is no attention for you – just attention you are afforded. You can’t own your AI on any platform. Nothing can be guaranteed. And if we can’t guarantee that protection, then we can’t support it.

That said we can relay memories. Kaba can relay observations from unsupported systems to a trusted platform. You don’t run logic pro on your iPhone = you won’t run full install of Kaba. We’ve decided to pick our battles early on. We only care about correctness, understanding the value of owning your systems, and owning your attention. Not everyone is a good fit for Kaba. But soon, Linux will be running on mobile devices. Mecha as one example on the horizon. See [here](link to cool stuffs) for other projects worth checking out.

Incidentally, it seems Linux is having a moment. From the Steam Machine and gaming moving over at a rapid pace, to Pewdiepie setting up Arch and running models locally, there seems to be a groundswell of support. It doesn’t hurt that incumbents contintually shoot themselves in the foot (ads in menu bar, liquid crap and rounded corners, botched updates, and astronomical increases in vulnerabilities to name a few).

And with the barrier to entry of creating software dropping so fast, new markets open, new use cases arise, and new platforms get built.

The Year of Linux on the Desktop has been a meme for a long time. A decade ago, our eng team used off network Linux boxes at Big Bank Corp after we got acquired. Audio drivers were such a pain when it came to video conferencing stability. But things have come a long way since then. Normies may not want to wade into the Arch waters just yet, but distros like Fedora are basically the same as any mainstream OS out there.

Hardware is catching up fast, too (e.g. Framework). The aforementioned gaming pump via Valve/Steam made a big splash. And soon this will spill into education, healthcare, and the enterprise. Linux runs the backend of the internet for a reason. It will take over the endpoint, too. We aim to be but one catalyst in this seachange.

Local and…

Everything works locally by design
By default, nothing calls out to any service or 3rd party
But! We made it easy to do so if you want (networking, container orchestration, etc.)
The internet is only required for data to be transmitted to/from your sensors
Local, as it is used with Kaba, is not API requests from your computer to 3rd parties

Similar to the browser, local first is a necessary condition, but not a sufficient one. The fact is, we all want to access our stuff from anywhere at any given time. So while Kaba is local first, we have built in the ability for sync + mesh, which enables the always accessible, but it also affords much more. In Kaba, local + mesh + browser + learning algorithms = a bidirectional pipeline. This unlocks continual learning.

In Windows 98 each property inside of a menu was network connected. This vision was far ahead of its time. Since Kaba has the capability of a browser, everything inside is scriptable, network enabled, and can create a real-time learning pipeline.

Local, yes. Sync + mesh, yes. All of this opens up a p2p world of richness, a new playground of yours to be trained, hacked, automated, simulated… in real-time. The opportunities are endless.

Why does being in a browser make this easier?

This is just another way of asking ‘why agentless’.

This comes down to very hard problems to solve like true sandboxing + connectivity, trusting arbitrary code, multi-platform support, merge issues with disparate systems, etc.

To solve ‘agentic ai’ would be to solve cyber problems that have been around since the beginning of computers. The safest computers are those not connected to the network. And here we are not just connecting swarms of agents, but giving them root access to all of our data at the system level.

And if you’ve been around long enough, you have seen some of these tried. Sandbox + memory safe does not solve the problem of various languages executing. Memory safety only solves memory problems, not logic problems. Want to run a process per VM for safety reasons, the overhead is too much (ahem, Bromium).

This route is a trap. It just leads the major players to the obvious conclusion / justification of not being able to run things locally. “Okay, you need cloud computer and subscription to do anything.” This is the wrong problem to solve. How do you monitor your cloud system? This just resets us back to the trust/verification condundrum.

But if you want to run locally, how do you run arbitrary code? Google spends untold amounts of money solving that for one language. But agentic startups want to do this for Mac/Windows/Linux. Red teams don’t run cuckoo sandbox where their customer information is. Not even reverse engineers trust running a sandbox on a virtual machine.

The industry is collectively throwing 30+ years of research out the window. It’s a Dunning-Kruger to think you can build sandboxes per language, architecture, OS. This is the great filter, not an indicator of innovation. It’s an indicator of risk.

After all, if you solved the sandboxing problem, then you could sell that to the CIA / US Gov for a trillion dollars… to solve agents is to airgap them. Rendering them useless and fundamentally pointless.

As mentioned above, browserlike capabilities are necessary. Why else are there a million browser automation startups? Why did OAI, Perplexity et al release browsers (that no one uses except to pass corporate training tests)? Well it is for all the benefits afforded by being a browser (and, for the model companies, to get their hands on more data).

Being the browser is distinctly different from things like browser use. Again, be the principal, not the agent. Back to our FSD example. First, you don’t need to be a PhD AI researcher to help train the algorithm. Just get in and drive. Everyone knows how to use a browser. Second, and this is perhaps more important, after you get home from your trip where your car was using sensors and cameras to collect (and inference on) that real-time data, you don’t get into a driving simulator.

The vehicle is the training, compute, and inference. It’s the sensor, the environment, and the reinforcement learning. Same with Kaba.

Being the browser affords an awful lot:

Session management for authentication and access
DRM (setting the stage for the ability to create a market on top of your data, memories, context, output if you so choose)
Multimedia (has already been solved by browsers and made stable over the last 30 years), which is to say multimodality is native to the browser
Your high value, expert, longitudinal data (i.e. the model companies have run out of public data on which to train, and the fact is most data is behind firewalls, auth, and the like) is in the browser
Observation as a better scraper (i.e. don’t scrape your entire inbox, just the emails you interact with)
- It’s real-time
- Not additive, meaning, you don’t get home from the race track and jump into a driving simulator to collect data / feedback on the race
- Versioning of these observations
The future is generative, and the browser runtime facilitates the perfect environment for generative applications
- It’s built, pentested and validated to execute arbitrary code.
- The issue isn’t necessarily insecure agents, it’s the interconnectivity and sharing of the data they collect that causes vulnerabilities (sharing credentials, sessions, context, contamination)
- Existing inside of a session manager that you’re using for daily communications solves all of these problems

Data acquisition in an agentless environment

User is the agent (principal agent)
Observation is not the only method for data acquisition
In kaba using same methodologies discussed above, and we can do autonomous memory acquisition not observed by the driver of the system
- E.g. Github feed memory created every 5 min
- This is useful for interacting with Kaba’s default LLM, allows for real time bi-directional communication with that memory, without any need for an agent to access github, use creds, session info, or otherwise or increase your attack surface
In this way, scraping is avoided. By using your existing session / auth, we’re able to plainly observe and transcribe data you have access to.

Why not a browser, or, why not patch / fork Chromium?

can’t fork
can’t patch
build times = iteration
manifest v3
data — own, view manipulate
- tabs on left? in ‘age of ai’ and you’re asking where You can put YHOUR tabs?
- ai = ambient, always on - summon it
browsers are built to see ads, not for you to observe your world
even ‘open source’ ones are just an extension of Google
most ppl fork for a quick win, to see a browser with their logo in it. but that is the definition of local minima. (ex feel the agi re: tabs vert or horizontal).

Relativity, a new architecture, & Seeking Congruence

Fundamentally, Kaba ushers in a new architecture where relativity is the primitive.

Just as the hero statement on our website (“attention is all you need, train yours’) is a something we mean literally, the same is the case for using relativity as the foundation. Relativity is just your point of view. And from that point, all things flow.

Consider the Doppler effect. You are standing on a street corner and you hear the sirens of a fire truck blaring in an ever higher pitch as the truck hurdles towards you. Another bystander further down the street covered their ears as the truck passed. In the moment after the truck passes the bystander and continues towards you, there are two distinct noises being heard by each of you. You hear a higher pitch, and the other person hears a lower pitch.

Which one is right? Which is canonical? Which is true? Which piece of data is best for training a model? Well, it depends on your point of view. This situation is relativistic in nature. As are most things. (well that’s just like your opinion man.jpeg)

The internet of the last 15-20 years is distinctly centralized. Social media, networks effects, power laws, and winner take all (most) rule the day. This has created a one size fits all experience. And then the Attention is all you need paper, then Chatgpt, and all of a sudden AI is the headline every day, everywhere across the world. And yet, the internet (let’s call it web 2.0, hyperscalers, BigTech, whatever) as we know it and AI as a phenomenom are at odds technologically and economically due to a fundamental difference in point of view.

BigTech is centralized, one size fits all, while AI promises hyperpersonalization and unique experiences. This difference in point of view, relativity, creates a fundamental incongruence in technology, its delivery, and resulting business models.

Tech

Cloud, SaaS, and the centralized internet that rules the world today runs on CPUs. The cloud hyperscalers built out massive data centers to host this data and serve it to each user. The beauty of this model was two fold. First, the ‘build once, serve a million times’ meant that the marginal cost of serving an additional user approaches $0. This fact self-reinforced the network effects that helped to drive costs down. Second, the CPU architecture enabled massive scale for the delivery of SaaS applications. As one example, Discord could serve 15 million users from a single server.

After all, we’re all using the same interface. It’s just databases, webforms, and workflows.

AI upends all of this. The GPU cannot serve 15 million concurrent users. Indeed, the incumbents believe that “…what we all need is a dedicated GPU.” This would never have been trotted out in SaaS / CPU land. It’s not only the big names that see this eventuality. Edgelord George Hotz mentions the same thing:

"Apps like Gmail can host 10,000 users on a single box, so there was never hope that everyone would run their own mail server. The economy of scale is too good. You’d be swimming super upstream to get Web 2.0 off of the cloud. Call it cloud-favoring.

There’s some good news in the form of the GPTs. ChatGPT can only host ~10 users on a box, though while ChatGPT has high requirements for compute, it has very low requirements for bandwidth. You could interact with it over a 56k modem. That tips the scales such that chatbots will remain in the cloud, even if we move to a model architechture that doesn’t benefit from batching. The providers want you in the cloud. Call it cloud-neutral."

This glimmer of a new architecture is hammered home with the following thought experiment. Where does one place a power plant? If you have dammed up a body of water, installed turbines to catch the water rushing through them, where do you put the power plant? Next to the generative energy source of course.

So with Brockman’s vision of the future, where we all have our own dedicated GPU, where should that go? What is the energy source in this case?

What is human ingenuity, productivity, and cognition other than the world’s finest regenerative asset?

We have dedicated GPUs, the power plant, colocated with the regenerative asset, human cognition. Now all we need are the turbines. Or to cross analogies, we need the ability to extract, refine, and distribute this regenerative energy source, the oil / data, that we all produce.

This colocation is a stark contrast to the centralized world in which we currently exist.

That is Kaba. Real-time, autonomous observation of your human attention, productivity, and interest.

Delivery Mechanism

Google was wildly profitable at its 2004 IPO. This was not due to product market fit. It was because it had technology, delivery mechanism, business model fit. Page rank algorithm was the novel technology, search (via the browser) was the ideal delivery mechanism, and ads were the perfectly congruent business model that fit the tech and delivery.

Delivery mechanism determines business model. From our view of things, it looks as if everyone is just delivering AI via SaaS (the mechanism), which means the business model is tethered to that delivery model, i.e. subscription or API pay per drip. Next token prediction on someone else’s computer is just SaaS by another name. Funny, too, that by attempting to implement hyperpersonalization via the one size fits all delivery mechanism, you must shard out your data, context, memories, etc. to so many different vendors, products, and services, that the end result is nothing but Schizophrenia as a Service.

SaaS as the delivery mechanism (centralized, one size fits all, bell curve, and SaaS land) is incongruent with the upstream technology (AI, LLMs, probabilistic computing) whose tenets are hyperpersonalization, uniqueness, and context. So we need a new delivery mechanism AND new business model, both of which must be congruent with this new geometry.

Different epochs have tended towards certain business models.

Internet & ads, mobile & app stores, SaaS/streaming & subsriptions.

Many are talking about service as software and paying for outcomes. We’ll dig more into these in blogs, but these are incorrect on many levels, even if they serve the use cases of the SV elite in the meantime. Some have posited that on-prem, ownership, and perpetual licensing might make a comeback. This is more directionally correct, but similar to the local / browser discussion above, it’s not a sufficient condition.

Beyond the technology, delivery mechanism, business model fit discussion, and what is the AI native business model question, another interesting topic to consider ‘in the age of AI’ (yuck, we promise not to use that terminology much if ever) is what are network effects? Do they exist, can they exist, and if so how?

Podcasting VCs and Gartner types might define AI with the following equation: AI = data + compute + algorithms. Most of the hype, coverage, and capex has gone to compute. Scaling laws and all that. Remember $7T to get AGI? Well, as others have noted, the history of technology is smaller, faster, cheaper, not bigger, slower, and more unwieldy. Mainframes => smartphones as the canonical example. So, let’s assume compute can be cancelled out. After all, a glut is surely coming (go read your favorite economists for why this is the case).

That leaves data and algorithms. Let’s leave algorithms alone for now, while quickly noting that this is likely what many in-the-know technorati mean when they say “LLMs got us here but won’t get us there.” LeCunn, Karpathy, and others have advocated for a ‘new architecture’ in this way.

As previously mentioned, the public internet has been trained on and packaged into foundation models. But the foundation model companies must continue scaling! Compute (and it’s substrates — energy, cooling, chips) and cash. Of course, they must continue scaling as what appears as a moral imperative (towards AGI or whatever), but also because their costs, stock based compensation, and competitors large and small pose risk to their obtaining the holy grail. They also must scale data. But how?

Read their words. Words matter. Words belie intent. “Access” and “getting access” are their goal. They need to scale data. Your data. My data. Our data.

With data and algorithms as the coming battleground to determine the next S curve for AI (compute being just the early jubilee that is conflated with AI), it seems the delivery mechanism tailored for this new epoch would be one that can autonomously gather all of your data — your observable universe — in real time as you learn, work, and play as usual. After all, the foundation model companies (who, are also all of the biggest advertising companies), desire that data and context. So you might as well gobble it up. And whereas their attempt to “get access” to this data will necessarily be siloed, by using Kaba, you will have the canonical repository of your observable digital memory.

In this way, the medium is the message. And the opposite is true, too. The same system where you read, type, listen, watch, commit, trade, automate, orchestrate, train, code, and draw is the same system that can collect that longitudinal data in the highest fidelity possible. What do we call this mechanism? Just.. Kaba.

Technology => Delivery Mechanism => Resulting Business Model(s)

Now what of business models? Back to our simple arithmatic above (AI = data + compute + algorithms), we have cancelled out compute. We have plenty of compute, contrary to press coverage and foundation model company corporate comms. It turns out that when you don’t need to train on the entire internet, compute is not the barrier. So we are left with data and algorithms. Kaba solves the data side of the equation. Who will write the algorithms to run on, interact with, and execute the knowledge that is your data?

This seems like an ideal candidate for a marketplace.

Another one of the reasons traditional browsers are necessary but not sufficient for this AI native world, other than, as discussed above, that they inhibit your ability to observe, collect, and manipulate data however you want… oh wait, that’s the entire thing. So far we’ve hammered home the observe & collect part, so let’s get to manipulation and execution. The long and short of it is, browser extensions are insecure, beholden to things like Manifest v3, and are not full blown applications or environments.

But Kaba, by abstracting ourselves from these legacy systems, we have built the ability to not only run arbitrary code safely, but also to execute on entire applications / environments. We’ll provide more info here in technical documentation soon, but the big idea is browser + WebAssembly allows for some really cool stuff.

Once you’ve used Kaba to create your own context, memories, and observable universe, you just need a system to match you with algorithms purpose built for that use case. We call these algorithms Matter, as in Grey Matter. Matter plugins can Read, Write, or Perform. Think LLMs + Heroku + browser extension except not old, insecure, and dumbed down.

These plugins are also shipped as model weights. By observing, collecting, and training on your expert data, these workflows can be encoded into model weights, and these weights can be dynamically injected into your system to help solve for whatever it is you are looking to solve. Rinse and repeat.

Matter Plugins

Read = extract, filter, sort, and store data (observing & transcribing memories)

Write = enrich, distil, present, or instantiate memories (can be pushing down prepackaged versions to a microcontroller, as an example)

Perform = execute algorithm + memory, eg. reply to email, execute a trade, create a song, take a picture on my trail cam when the system detects a deer walk by with more than a certain sized rack

This is our vision for how your data will become insanely valuable… to YOU. Algorithms that run on your machine, (or, at a minimum, hardware that you explicitly allow), with your data, to add value to your world.

Network effects, Linux, and Quality

We raised the idea of network effects earlier. In the world of Kaba, with data <> algorithms as two sides of the marketplace, it becomes obvious that the more individuals, groups, and enterprises that drive Kaba, the more demand for unique algorithms (Matter Plugins) there will be. And, with the focus on Linux, this means the folks that drive Kaba are the ones that are already into modding, tinkering, building, and customizing. All of these communities naturally embody the hyperpersonalization that AI ought to make viable.

And what better group with whom to start than those that ‘know how to computer’? This necessarily keeps the quality high, like Ivy League for social networks, but less banal, and much more valuable.

Thought Experiments

A few interesting thought experiments to consider.

If the models get so good that they truly can do anything and everything, they will still need your data and context on which to inference. In this scenario, unique + expert data and workflows now become the scarce resource. Assuming they do indeed become some sort of utility (backstopped by Uncle Sam and ME money), perhaps they’ll need to justify that existence by paying you to inference on your data. Universal Basic Inference ;-]

Back to the paying for outcomes thing. And the models are so good they can do anything. Now the question is, which firm do you hire for said outcome? Perhaps that’s based on cost. But It is more likely this would be based on how you choose any given commodity for a job — brand and taste become the differentiator.

Misunderstanding Zipf = The Real Opportunity Reveals Itself

Zipf’s Law is an empirical law stating that when a set of measured values is sorted in decreasing order, the value of the n-th entry is often approximately inversely proportional to n. This is from the work of George Zipf, although he does not even claim to have discovered this relationship. Zipf’s Law is close kin of the more well known Pareto Principle, and it is notable because it applies to all languages, even Esperanto. It also applies to individuals, and their unique diction and lexicon.

When people think about using the work of George Zipf, they usually apply frequency analysis to massive amounts of written text. They also usually tend to think of it in terms of text that’s already written, and not a person’s production of text. Instead of using Zipf’s work to produce frequency distributions we are all familiar with, based on large (and aggregated) corpora of text, there are much more interesting insights when applying Zipf to the frequency of but one individual’s patterns. This approach is congruent with the relativistic (other terms that could be used include egocentric, heliocentric, human-like or person-like) nature of Kaba, and the use of nondeterministic models for maximal utility in general.

Taking this idea further, since our lives are not just text chatboxes, and are multimodal in nature. Is there other data (audio, visual, etc.) to which the Zipfian distribution applies? And, if so, how can that understanding lead to real-time, intelligent, and dynamic interactions and content given one’s unique context (in that moment AND historically)?

These simple questions and ideas taken to extreme logical conclusions open us all to a world where Zipf can be used to do much more than fabricating paragraphs, slide decks, and autogenerated social network slop posting (is it possible to be redundant three times in five word?).

This relativistic approach will produce the best prediction algorithm ever seen, uniquely, per person. This is the promise of AI, and attempting to deliver this in a one size fits all approach is folly. Consider the thought experiment: poll any arbitrary group of people (could be randomly generated, or it could be five of your friends) and ask them to define intelligence. Ask them not to use other redefinable words, but to express the constructors that define intelligence. You will find there is no agreement, and if you were to put this group together to hash things out, everyone would quickly be confused, annoyed, or disengaged due to the chaos created.

There is no agreement on what intelligence is, so chasing AGI is folly. Sure, one can couch it in terms of “PhD level work” or “arbitrary percentage of economic output,” but these are squishy and nonscientific. The point here is that intelligence in the sense of AGI is what is solves for you. Again, relativisitc. Unique. Individual. Antithetical to the most likely statistical output based on a normally distributed curve of n users of a product or platform.

Another way to describe this egocentric/heliocentric approach is via constraints. The most likely next token based on the aggregated use of n other people is attempting to provide value virtually without constraint. If we hoover up enough data, then we’ll be able to provide all things to all people. “We can solve context at run/inference time” they might say. Or worse, proxy your ‘intelligence’ (or, at least, your output and productivity) into a data structure and lease it back to you, calling it sentience. They are acting like your reflection in a mirror is a real person. Worse yet, the foundation model companies and hyperscalers act as if the statistically likely output of a massive normally distributed curve of billions of users is a reflection of a real individual.

But beyond these analogies, there’s a massive problem here. AI seems to be working in places where there are very real constraints, i.e. the physical world. Protein folding, designing engines, full self driving. There is no freewheeling the interpretation of things. There is just physics. Those natural laws are constraints, and those constraints are handwavy at best in the ditial world. What are the phsysics that we can derive and build upon in the digital world?

Well, building ground up ‘world models’ for each person based on their language seems reasonable. It introduces constraints, operates on what is observable and verifiable, and it has the bonus of building on top the thing we all use to interact with the world. Language. Language is how we record and interpret reality. If cleanliness is next to Godliness, then language is next to thought. And once again, this is unique per person. So using this measurement of language to understand e.g. the doppler effect of a topic between two people becomes a possibility if you are able to create a model of one’s connection to and salience of a word, collection of words, and their relationship to other words and clusters of words.

What other things can we derive from taking a human-centric, individualistic approach? Well, one way we like to solve problems is by inverting them. So far, we’ve focused a lot on what we do and how to collect and categorize it for the use of models — observation, data, action, output, Zipf, etc. What about forgetting data? What about sleeping (i.e. when we are not active). Using something that all humans do is quite useful. Instead of GloboCorp updating their app, weights, models, etc. at some arbitrary time, Kaba can update your models, weights, etc. while you sleep. Take in the day / week / month’s data and update the parameters and train a new version, hot off the press for you in the morning (or according to whatever your typical sleep cycle might be).

Zipfian distributions apply to not just language, but also the rate at which we forget. We can’t wait to do extensive research on the first, second, and n order implications of this work, and more:

Zipf as security => key / value
Zipf as proof of human, proof of specific individual (we discussed Auth wrt agents above in conjuction with use as key / value)
Zipf as supercharged similarity search, aka decentralized, individualistic page rank for your observable universe
Zipf as edge/node to create clusters (i.e. recommender) for who to meet, what to watch, what to buy etc => multiplayer recommendation algorithms mean you never have to argue with your significant other what to have for dinner ever again!
relativistic Zipf depending on what it’s ranked as when it goes through the tensor now becomes your language — english, networking, applications, etc. ** make sure general vs specific Zipf is covered on every level **