FAQ - Frequently Asked Queries

As I've said elsewhere, git is the greatest monopoly ever, and arguably the greatest piece of software written to date. Like all GOAT questions, this can never be resolved, but it is at the very least "in the conversation".

It will also be obselete by 2030.

This does not mean it will no longer exist of course, rather, it will be recognized as relatively inefficient for the AI era. There is too much overhead for too many informational branches and "remotes" with the explosion of agents.

Also GitHub is the arguably the greatest SAAS to date, giving birth to gitops. And gitops is a nightmare of complexity, as is other out-of-band, non-versioned metadata and derivatives such as issues and discussions.

In ibgib, **EVERYTHING** uses the same semi-structure - something I call supersymmetry. It is kind of like adding version control at the file level (though it's even finer grained than this at the semantic level). As such, we can include things like commit messages, issue tracking, discussions, pull requests, etc. ALL IN THE SAME GRAPH projection as the code that it describes. This also applies to specs, packages, "and much much more™"! These are all things that in one way or another get shoehorned into git. And in programming, we have a term for this: "code smell". But for some unfathomable reason, normally extremely intelligent (i.e. the smartest humans on the planet) people have lost their noses.

Ibgib's protocol seeks to provide "granular" version control-like capabilities, but also granular compensation/financial support. This will address not only "open source" remuneration (a problem simply unsolvable with today's infrastructure), but service remuneration in general. This would place it in competition with the services like GoFundMe and Kickstarter, which similar to the case of git, ultimately will not be granular enough for the explosion we are about to experience.

Yes. But the question is at what cost? Most people think of "efficient" in terms of time. But there are also costs in terms of complexity. And not only that, complexity at what scale?

Ibgib has an upfront complexity cost of incorporating time with data. This makes it entirely unsuitable for small scales. But the long-term simplicity gains will outweigh that initial cost, whereas existing technologies explode in complexity and cannot meet the scale without an exponential growth of surface area. This means less interoperability, fewer features, and necessarily less security even possible.

For example, say you are building a web3 "dapp" (decentralized application). You will write src that goes in a repo. Already now, you have at least two separate Merkle-based buckets for data: 1) src data goes in git (a Merkle DAG), and 2) your dapp's infrastructure which hooks up to (most likely) a blockchain (a Merkle-linked list). You most likely also have intermediate artifacts like packages hosted on, e.g., npm (like ibgib does). While not strictly a Merkle DAG/blockchain, package managers still ad hoc do essentially the same thing: version control (tar) files via content addressing and provide integrity guarantees via a hashing mechanism to prevent tampering. Now not only do they have to maintain the security of their own infrastructure, but you have to maintain your credentials and infrastructure for connecting to their infrastructure. And this is only for package derivates. What about issue tracking, not only with the issues but with identity? Commit messages? Code conversations? And this explodes for each participant in the supply chain.