ibgib blog

AI-Theming and Ibgib Projects are LIVE (...in early alpha)

brief recap

For those of you not yet familiar with ibgib, it's a protocol for truly distributed computation. It resembles more git than blockchain under the hood, and it perfectly dovetails with the Agentic Era.

This innovative website in an early alpha stage, utilizing the ibgib protocol throughout its design. In short, everything is an ibgib. The agents are ibgibs, the "projects" which we'll get to, the parts of the projects, even the "chat" that you see on the right of the screen and even each message within the chat...each and every one of these is an ibgib.

And just as git revolutionized code collaboration, the ibgib protocol completely revolutionizes human-agentic collaboration.

ibgib.com Update #1: AI-Theming beyond Light/Dark Themes

First, the shiny: You can now theme the entire website with natural language via the website's primary agent. This isn't just a chatbot and this isn't just a dark theme. We've hooked up the agent with the ability to change so many of the website's colors, and we're among the first to do so.

But that's just a fun thing that others can emulate. The new "projects" capability is our first step to ibgib awesomeness.

ibgib.com Update #2: Projects have officially begun

On the ibgib.com website, we can now create and interact with Agent-backed projects. Now, "project" is just a word - a word to help us understand what an ibgib is. Let me explain.

Every serious project is a complex endeavor that breaks down into sub-projects, with individual components that ultimately evolve independently. This trend is especially evident in decoupled hardware and software systems, which rely on intricate supply chain networks. So as project scale increases, so inevitably does this "sub-project" sprawl. Git's solution to this (and thus almost everyone's solution) is either a single monorepo or repo sprawl, each with their pros and cons.

🛈

git Monorepo

Pros:

  • Code sharing and reuse are simplified.
  • Dependency management is easier to handle.
  • Atomic changes across multiple components are possible.
  • Code is easier to discover and navigate.

Cons:

  • Can be slow for large projects due to the size of the repository.
  • Access control can be more complex to manage.
  • Build and test times increase.

git Repo Sprawl

Pros:

  • Faster build and test times due to smaller repository sizes.
  • Simpler access control.
  • Easier to understand the codebase for individual components.

Cons:

  • Code sharing and reuse are more difficult.
  • Dependency management is more complex.
  • Atomic changes across multiple components are not possible.
  • Code can be harder to discover and navigate.

Another Way?

What git does NOT allow for is sub-file granularity or cross-repo content-addressing. You can't version a function and you can't get a commit hash that points even to a file. So we get tons of small repos with a bunch of unnecessary overhead. This is because git's object database (the thing that has the commit hashes) does not include repo metadata. This is why you have a .git folder with things like refs, hooks, repo description and the config settings proper. None of these are in the object database, so none of these can leverage the git push/pull mechanism that makes the source code versioning so useful across remotes.

This is where ibgib and ibgib projects come in.

A "project" (and a "sub-project") is a friendly wrapper term for an "ibgib". And an ibgib is like a git repo but at the semantic level. What does this mean? Git works at the file level of granularity (a folder is just a collection of files). But a file is an OS construct and many OS files have tremendous semantic structure, i.e., there can be many "things" inside a single file. This is the level that ibgib tracks. Each "thing" has a timeline, that looks similar to an entire repo's timeline. Each and every piece of semantic data has its own "commit hash" so to speak. When you "change" an ibgib, you actually create a new frame on its timeline and link back to the previous address - just like a repo (and a blockchain).

This gives us what I call "supersymmetry". Each piece of data is individually addressed and thus can be "imported" into any arbitrary space. This includes metadata and derivative data. So as complexity grows, we still use the same timeline dynamics as our foundation. There is no separate code required for a package repository.

Don't get me wrong, there is still inherent complexity as the projects and subprojects grow. But we minimize this complexity with a uniform foundation upon which to build and version our software artifacts.

This approach unlocks an entirely new collaboration paradigm just in time for the explosion that is accompanying the AI-based agent revolution.

check out projects

You can explore the beginnings of our project ibgib implementation by navigating to the Projects Tab in the left panel and selecting 'New Project'. Then hit the plus sign and you'll be off and going. Introduce yourself to your project agent (every ibgib has its own backing agent), and see where it takes you.

First Funding!

A momentous day, with the first funding received from a generous individual: $100 !

This may or may not have been prompted by the Google workshop I participated in called Build with AI. It was a fun event with a lot of smart, smiling people.

Shows early on in the workshop with a slide on a projector and some of the other people in the room. Shows the view outside of the window, looking out over the river in Austin, TX. Shows the view outside of the window, looking down over the sail building adjacent to Google's building where the workshop was held in Austin, TX.