web-gib - agent-driven ibGib web apps

:under_construction: _I'm currently in the process of pulling this out as a framework from @ibgib/blank-gib._

This library enables ibgib apps with...

* initializing the ibgib environment
* bootstrapping the metaspace
* utilizing and interacting with IndexedDB
* IndexedDB-based ibgib space implementation
* IndexedDB helper functions
* building with the ibgib component framework

src notes

$3

All ibgib code is TypeScript + ES Modules.

* .ext for chrome extension-only (not the app)
* .web.mts - web (not node)
* .app.mts - blank-gib app (not the web extension)

UI Architecture: Custom @ibgib component framework

tl;dr: _Web Component-based components react to ibgib's unique Merkle DAG DLT time-centric data model._

The front end that this library enables is not built with a conventional
framework like React or Vue. Instead, it uses a custom architecture built on top
of standard Web Components and the ibgib protocol. This creates a reactive
framework against an infinite space built on ibgib's unique DLT
content-addressing system.

In particular, components are linked to a backing ibgib timeline, using the
ibgib's tjp address (specifically the gib part, i.e., the tjpGib) as the
pointer to the genesis of the timeline. This acts as a unique, content-addressed
timeline/stream identifier. And components subscribe to the metaspace's local
pubsub, specifically listening to timeline updates, reacting accordingly.

$3

All current approaches to data are disconnected. So the best you can do with a
front-end component framework is a Redux-like approach where you usually have a
local data store and you provide pathing into that store. Slightly better is you
can have a store provider layer. Then your local-only components react to
updates via the lambdas/reducers.

The lone exception - and the reason for its ENORMOUS success - is git itself.
Think of git's coarse branches as the paths and remotes as the components. Now
think of a DLT-based approach to timeline dynamics (like version control
systems), that wasn't built with source code as its only use case, rather _with
each piece of data as its own timeline_. Now you have a universally-sized
distributed computation addressing system that enables _distributed_ component
architecture.

$3

The component framework itself consists of three main parts:

1. The Component Service (IbGibComponentService): A singleton service that acts as a central registry and router for all components in the application. When the application needs to display a new view, it asks the service to find and create the appropriate component for the given data (ibGibAddr).

2. The Component Meta (IbGibDynamicComponentMeta): This is a "blueprint" or factory object for a component. It doesn't render any UI itself; instead, it defines the component's custom HTML tag name (e.g., ibgib-sidepanel), its routing rules (how it matches a URL or path), and contains the factory method (createInstance) to stamp out new instances.

3. The Component Instance (IbGibDynamicComponentInstance): This is the component itself - an actual HTMLElement web component that gets rendered in the DOM. It contains the UI logic, event handling, and maintains a live link to its corresponding ibgib data. It uses a LiveProxyIbGib to automatically update the UI when the underlying data changes.

This architecture allows for a highly dynamic and modular UI where components can be loaded, unloaded, and updated in response to changes in the ibgib knowledge graph. For a more detailed technical breakdown, see the README.md in the apps/blank-gib/src/extension directory.