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

*.ext.mts, *.web.mts, *.app.mts

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.

Big Idea

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.

Framework Parts

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.