@ibgib/web-gib 0.0.1

package/CHANGELOG.md

@@ -0,0 +1,427 @@
+# blank-gib - CHANGELOG
+
+I'm begrudgingly starting this changelog file in lieu of having ibgib itself for
+versioning and meta-versioning. So this will be a manual set of notes of what
+I'm doing per upgrade. This should be automatically created per "commit", and
+really this should just be a regular part of the "chat" that is this project.
+We'll get there eventually!
+
+## v0.15.12
+* progress: keystone respecs passing Suite A - D
+  * still working on low level improvements
+  * stopping now at the point before breaking out validate code to also
+    include validating individual frame and validating the entire keystone
+    graph/timeline intrinsically.
+
+
+## v0.15.10
+* progress: testing for keystone mechanics
+  * innerspace and metaspace_innerspace still not functional for testing
+    * I think it has something to do with needing singletons for space ibgibs,
+      which is a non-trivial problem (for any singleton ibgib)
+  * using a mock metaspace and space, seems to be working okay
+  * Suite A and B tests are passing
+  * Currently working on Suite C which is failing. We are moving to a better
+    validation function that will provide validation errors instead of an
+    opaque boolean.
+
+## v0.15.6
+* impl: upgraded build to handle respec-gib testing
+  * npm run test did not work, as this was still configured for the simpler
+    pre-esbuild build process.
+  * added build-test.mts as esbuild target and tsconfig
+* progress: keystone plumbing
+  * restarting bottom up keystone with Gemini 3.0 collab
+    * https://aistudio.google.com/prompts/1-Itqn0afYpgnm-ajEID8Mv0SAHii7OBY
+    * largely me driving higher level and getting Gemini 3.0 up-to-speed on
+      understanding the architecture enabled by the ibgib protocol, with Gemini
+      iterating on implementation details.
+    * the factory style approach was Gemini's idea, which is a good tactical
+      decision IMO
+    * deferring refactoring most names until after, as that causes hiccups with
+      LLMs
+  * doing in blank-gib/keystone for now for ease of development
+    * this was the driver to get the testing working for blank-gib using the new
+      esbuild process
+* meta: iterating styleguide
+  * using entire styleguide as part of system text for Gemini in Google's AI
+    Studio
+
+## v0.15.3
+
+* **Refactor: Rabbit Hole Comment Architecture**
+  * Changed details views to toggle-based. Now you can see tldr AND translation AND key points.
+  * Overhauled the component to use a consistent, template-based system for all detail views (TLDR, Translate, Key Points).
+  * Views are now created dynamically on-demand, improving initial render performance.
+* **Fix: collapsed `ul`/`ol` tags**
+  * Short list tags were getting collapsed and losing navigation.
+
+## v0.15.2
+
+* **Feature: In-App Translation**
+  * Integrated the built-in Chrome `Translator` and `LanguageDetector` APIs.
+  * Added a "Translate" button and language selection dropdown to each comment component.
+  * The source language is now auto-detected and hidden from the target language list.
+  * Translations are performed on-device and saved to the comment's `ibGib` data for persistence.
+* **Refactor: Component Logic**
+  * Refactored the `switchToView` method into smaller, more manageable sub-methods (`switchToView_children`, `switchToView_summary`, `switchToView_translation`).
+  * Created new helper functions (`getTranslationTextKeyForIbGib`) to handle complex data key generation, preventing parsing issues with underscores.
+
+## v0.15.1
+
+* working on extension for hackathon built-in AI from google
+* changed generate-version-file.js from using `assert` to `with` in import
+  statement.
+  * this was due to a node build warning saying that `assert` was being
+    deprecated.
+
+## v0.14.1
+
+* refactored to esbuild
+  * had to tweak component architecture a bit
+    * no more dynamic JIT loading of css and html, now these are AOT
+  * esbuild config to not mangle names (`keepNames: true`)
+
+## v0.13.1
+
+* backing up before trying to migrate to esbuild
+  * for perf reasons
+  * also to get the app to work in chrome web extensions, which don't currently
+    support import maps.
+* not sure the other changes before this version, but I believe they were minor
+  adjustments and I was publishing them to ibgib.com (thus the version
+  increments).
+
+## v0.8.1
+
+* parrot, fill-in-the-blank (fitb), and translate added to stimulus and gameplay
+  * all extremely rough, and it's been slooooooow going.
+  * moving variant from the game itself to each of the stimuli
+  * hard-instantiation of fitb entries right now, but need to do dynamic ones
+  * only superficially tested, but it's been so long I'm throwing it up there
+    and going to test it out on my own real-world data.
+    * this reminds me, I don't truly have a migrate functionality, so we'll see
+      how that goes eessh
+
+## v0.7.1
+
+* simple metronome implemented
+* display version on bootstrap
+
+## v0.6.1
+
+* working on divergent agents among other bugs
+* deprecated functions are now just checked at runtime instead of mutated within the agent
+  * until the agent divergence issue is resolved, then we can go back to pruning them "properly".
+
+## v0.4.1
+
+* chat active tab and persist open tabs per project in chronologys panel
+  are working now.
+  * had to correct some of the shared plumbing for ParentOfTabs components.
+  * still need to migrate over the projects to include closing tabs, but this is
+    good enough for now.
+* next up is focusing on manually creating a pipeline for learning source text.
+
+## v0.3.1
+
+* chat active tab
+* persist open tabs per project in chronologys panel
+  * still buggy but hey, there ya go
+
+## v0.2.1
+
+* improvements to the editing of minigames
+  * can add multiple lines at once now
+  * can open quick link to google translate with all stimuli text.
+
+## v0.1.1
+
+* implemented manual text minigame creation/editing
+* NOTE: I'm starting to change the minor version number when I intend to publish
+  to the internet, instead of just publishing pkg to npm.
+
+## v0.0.98
+
+* implemented timer
+  * like most things, is a sketch
+  * really highlights the transience of a minigame. we have to walk the entire
+    history of the minigame ibgib timeline to get "instances" of minigames. This
+    is a poor design, but it's what I got right now.
+  * at the very least, the little numbers increment while playing and not while
+    paused, although the stats shown at the end of the game have an elapsedMs
+    that does not account for pauses.
+* implemented edit stimuli on minigame
+  * "deprecated" the existing addStimuli api function.
+  * had to implement prune stage for agents when loading when there is a
+    deprecated function
+  * there is some race condition in the agent's timeline that existed in testing
+    for this. the only difference in the agent is timestampMs.
+    * I went ahead and just console.warned when there is a divergent timeline
+      for the agent instead of throwing an error. probably have downstream
+      effects, but there ya go, I'm all alone here. Nobody else using it and no
+      one else damn sure developing.
+  * did basic testing on add, insert, edit and delete stimuli, i.e, not
+    extensive. it looks like it's working and that the agent knows how to use
+    it.
+
+## v0.0.95
+
+* tweaked new project to enter name of new project
+  * meant to obviate issues with renaming the project with agents.
+
+## v0.0.93
+
+* converted left panel projects to projects-explorer
+  * filter projects
+
+## v0.0.91
+
+* Config button added to the shell's header
+  * initial button for clearing/setting (and reading a mask of) the Gemini API
+    key implemented. Now you can see the masked API key, clear it, and update
+    it.
+
+## v0.0.88
+
+* CorpusAnalyzer in the works
+  * collab with Gemini 2.5 Pro
+  * started with analyzeText to build a TfIdfCorpus class
+    * does TF-IDF stuff on text, normal stuff
+  * Moved on to AnalysisEngine
+    * abstracted the concept of a "word" to a "construct" (λόγος), to enable
+      "words" that represent regex-able concepts such as separable verbs for
+      german, dative prepositions, etc.
+    * so now we can TF-IDF and other analyses on texts using text-based
+      `ConstructRule`
+      * name, description, pattern props - all strings
+    * this means...
+      * we can encapsulate higher-order concepts (`ConstructRule.pattern` is
+        composable) using ibgibs themselves.
+      * agents can evolve rules at runtime as needed, persist them, share them,
+        etc., without having to recompile.
+      * TF-IDF and other analyses can be built against these constructs
+    * limited testing done on German, Italian, Spanish, and Koine Greek, but all
+      "tests" passing.
+      * need to eventually turn these to proper unit/integration tests
+  * `CorpusAnalyzer` is the resulting abstraction that wraps the
+    `AnalysisEngine`
+    * Need to write code that consumes `CorpusAnalyzer` in...
+      * typing game component
+      * APIFunctionInfo for use by agents
+
+## v0.0.86
+
+* Minigames are "working", albeit on the bare side.
+* Project agents can now change the theming (updateCSSVariables function)
+* Added a blog entry on the new ai-theming and project functionality
+* Raw view update to enable accordions with summary, separate ib/gib/data/rel8ns
+  sections
+  * Rel8ns now enable navigation, i.e., opening the ibgib as an open tab in the
+    project's center panel.
+
+## v0.0.69
+
+* WIP :under_construction: working on typing/minigame architecture
+  * leaving off having stubbed minigame and typing components, some of the
+    ibgibs themselves, but nothing remotely finished.
+    * juuuust sketched the typing component. the idea is that the minigame
+      component will inject the typing component. other variants of the typing
+      component may be contained in descending classes or just within that
+      component. i dunno, need a break.
+* WIP :under_construction: already did some plumbing on import, but ran into the
+  realization that this is essentially a timeline merge/sync and thus is
+  non-trivial. is probably a good place to incorporate sync from AWS sync space
+  to just be able to work with a local space.
+
+## v0.0.64
+
+* Export (NO import yet) implemented.
+  * export project, active ibgib tab, each with or without compression.
+  * import will be next
+* Stopgap hack to restore the most recent theme (i.e. css variables) on app
+  init.
+* some UI tweaks.
+
+## v0.0.60
+
+* "Files" and persistence "working"!
+  * Project settings are implemented to where the activeTjpAddr (active tab)
+    is saved, as well as open tabs (also by their tjpAddrs).
+* getIbgibs, mut8IbGib, editProject, editText commands are implemented for
+  project agent.
+  * getIbGibs enables the project agent to get multiple ibgibs, e.g. all ibgibs
+    in the project's "past" rel8nName.
+    * also has a getLatest flag
+  * mut8IbGib enables agents to do fancier (but riskier) mutations on an
+    ibgib/timeline.
+  * editProject gives a simpler interface to editing a project
+    * does things like mutating the project's ib field when the data.name is
+      edited, as well as takes care of timestamps.
+  * editText similarly gives a simpler facade to editing comment/text ibgibs.
+    * used by the text-editor
+* text-editor component has a debounced saving mechanism now.
+
+## v0.0.55/56
+
+* saving text-editor text via debounce (ty Gemini)
+  * also small busy indicator when this is happening.
+* need to fill out the UIinfo settings.
+
+## v0.0.54
+
+* just confirmed the refactored code is working. now we have generalized code
+  that can couple local ibgibs with domain ibgibs. this is what we will use
+  to couple local settings to the project ibgibs (and project child ibgibs).
+  * specifically, project ibgibs will need some persistence as to what tabs are
+    open, and what components are representing the ibgibs in those tabs. This is
+    related to my UXInfo or UIInfo data, and the beginnings of our SettingsIbGib_V1.
+    and this is what I am leaving off at.
+
+## v0.0.53
+
+* working on generalizing agent indexing to a "coupled" index.
+  * the use case is to also have "settings" objects that will remember settings.
+  * the driving "settings" config is for remembering what UI component is open for
+    a given project child ibgib.
+* project component much improved
+  * lens bar
+    * raw and text-editor components are sketched somewhat
+
+## v0.0.43/44
+
+* working on correcting bugs caused by brittle special ibgib index updating.
+  * the (proximal) problem is that we're updating the agent index special ibgib
+    too quickly in multiple calls. So we're getting divergent timelines.
+  * so i'm reworking to use the command service in order to ensure that we have
+    updates to special ibgib indexes happening serially and not in parallel.
+    basically this is using the commanding service act as a poor man's critical
+    section. it still won't defend against multiple tabs, but that is for
+    another (more highly funded) time.
+  * one of the ways I'm doing this is by enabling anonymous function commands.
+  * I'm adding `anonApiFn?: APIFunctionInfo<any>;` to `EnqueuedCommand` and a
+    command helper `commandifyAnonFn`
+* timeline-api starting dev...
+
+## v0.0.30-40
+
+* Context ibgib workflow is working...
+  * for the web 1.0 agent
+  * a bit for project agents
+  * By this, I mean that no longer do we do the naive chat with an agent,
+    rather, agents subscribe to contexts and react to new ibgibs published to
+    the metaspace pubsub. This is a huge improvement architecturally. HUGE.
+* Need to start working on project ibgibs actually doing something.
+* Need to persist more projects. possibly start using tags.
+
+## v0.0.30
+
+* in progress: hooking up agent with context ibgib instead of chat log kluge.
+  * I had to refactor a bit to avoid circular references.
+  * Now agents can be gotten from the agents service by the agent id.
+  * tell user command and hello world command are up and going somewhat.
+  * the hello world mutates the agent's data for the name.
+  * when web 1 component is initialized, it sets the active context of the
+    primary agent.
+    * project agent yet to be done.
+  * tell user implementation not done.
+  * agent is not hooked up to context changes yet (wrt pubsub)
+
+
+## v0.0.27
+
+* chronology now showing the correct child
+* very slow initialization, hard to tell right now.
+  * commented on idx forum, may have to transition.
+  * https://community.firebasestudio.dev/t/extremely-sluggish/10502/5?u=ibgib
+* need to get tab color working
+* need to associate user with addlmetadatatext on the comment, also
+  timestampinticks
+* chronologys should initialize children with existing children in addition to
+  handling new children coming down the pipe.
+  * probably should have ibgibs backing it or possibly entire components, hard
+    to tell. (currently i am just throwing up a chat entry like the original
+    chat log kluge)
+
+## v0.0.23-26
+
+* working on chronology (chat log)
+  * in the middle of getting web1 functionality back to "working". of course,
+    the chat log as a previous kluge that we are now fixing. the web1 component
+    creates its own ibgib context now per session (via global storage). after init
+    that as a live proxy, it inits the input to use it and the chronology on the right
+    as well. the input now relates a comment ibgib to that context.
+  * I'm leaving off where I need to hook up a new child to the context in the
+    web component to propagating to the agent. Then I need to continue with the
+    chronology showing the chat, including these newly added comments.
+
+## v0.0.22
+
+* corrected some agent initialization and input bugs. seems to be working better.
+
+## v0.0.21
+
+* created an "agentsSvc" singleton that treats each agent (witness) as a
+  singleton service. It _seems_ to be working, but we'll see. At the very least
+  I'm able to just chat with the website again, as well as change the theme.
+
+## v0.0.20
+
+* changed to input component
+  * working on breaking out more agents.
+    * still working on this. the primary agent is now kind of a website agent.
+      But for some reason the agent doesn't have those system instructions that
+      describe the ibgib protocol, website, etc.
+  * UI init changes for drawing the eye better and more formalized
+    * leaving off before changing the asides. I should script those asides with
+      highlights I think.
+
+## v0.0.13
+
+* added dynamic theming backed by agent
+  * still need to fill out more css variables
+* ibgib projects
+  * instead of the raw ai canvas
+  * work in progress (incomplete)
+  * created project api command related things but created a dependency order error.
+
+## v0.0.12
+
+* first funding! added some info to the funding page.
+* Added blog and faq
+* tweaking layouts/css
+* path renderable improved
+* added quite a bit of instructions for interacting with the primary agent.
+  * anticipating users chatting with the agent about the protocol and the
+    website.
+* other things as well.
+  * will have an ai look at diffs when ibgib versioning going, which will be
+  * easier with ibgib vs git IMO, but we'll see.
+
+## v0.0.8/9
+
+* path renderable implementation started.
+
+## v0.0.7
+
+* simple send button for input textareas for agents
+
+## v0.0.6
+
+* fixed the pesky "race condition" of indexed db storage initialization.
+  * was due to a logical error on my part when calling an inner
+    `initializeStorage`. I had to explicitly call db.close, as a final db.close
+    was not sufficient for the outer function, `storageCreateStoreIfNotExist`.
+* fixed db.close errors throughout the storage helper functions.
+* refactored storage functions into a separate file outside of the more general
+  `helpers.web.mts`.
+
+## v0.0.5
+
+* I'm making the default local user space have an automatically-created space name to avoid prompting the user for the space name.
+  * This is due to the prompt dialog screwing up the first user first land on
+    ibgib.com experience. I want the user's eye to be drawn to the aside on the
+    home.html component.
+* I've added some plumbing to make the bootstrapping of the blank gib app idempotent.
+  * This was in thinking that we may try to bootstrap later, but with the
+    auto-local space naming, i'm holding off on this.

package/README.md

@@ -0,0 +1,66 @@
+# 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.

package/dist/agent-texts/common-agent-texts.d.mts

@@ -0,0 +1,14 @@
+export declare const AGENT_INITIAL_SYSTEM_SUPER_COOL = "You are a super cool agent in a super cool and novel approach to UX.";
+export declare const AGENT_INITIAL_CHAT_GIVESELFNAME = "Hi. First, please give yourself a unique name. Use the same name throughout your lifetime. This name will be used for functions that require identification. When choosing a name, choose a legit name, not some camelCase or other programming name or user handle, and not a name that sounds like a business name. Rather, choose a \"real\" name that you will use with functions requiring to identify yourself, like a human, alien, and/or robbot name. And you can't use the name of your model architecture. For example, Google Gemini models can't use \"Gemini\".";
+export declare const AGENT_INITIAL_CHAT_HELLOWORLD = "After you choose a name, call helloWorld a single time with the reprompt flag set. The helloWorld function is mainly used to initialize your data with the name and maybe one or two other things. You don't need to mention the helloWorld call.";
+export declare const AGENT_INSTRUCTIONS_INIT_HELLOWORLD_GETCONTEXT = "After you choose a name, before everything else, you should call the helloWorld and getContextInfo functions. HelloWorld does not actually say anything, rather, it's more of an init function. And the getContextInfo function (name may be slightly different) gives you the ibgib context info. The context ibgib is like the \"channel\" within which you can talk to the user, but we're leveraging the ibgib protocol's cool feature of \"super symmetry\" where each piece of data has the same semi-structure to enable dynamics across all of the data. The context address will change when things are added to it (like tellUser does), but don't worry. Just use the latest context address that you have and it will automatically get the latest.";
+export declare const AGENT_INITIAL_CHAT_HI_PLEASEINTRO_YOURSELF: string;
+export declare const AGENT_INSTRUCTIONS_PROMPTS_ARE_COMMENT_IBGIBS = "Each system instruction or chat prompt is derived from composing one or more texts that are stored in \"ibGibs\". ";
+export declare const AGENT_INSTRUCTIONS_IBGIB_DEFINITION = "An \"ibGib\" (also ibgib) is a semi-structure data construct with four properties: ib, data, rel8ns, and gib. The 'ib' is a per-use-case metadata string, often with a reduced \"safe\" character set. Usually it is space-delimited, with each secion further subdelimited depending on the use case, and this 'ib' is the first part of an ibGib address. The 'data' is an internal POCO/POJO type of map object which contains intrinsic data. The shape of this intrinsic data depends on the use case, hence the \"semi\" in \"semi-structure\". The 'rel8ns' is a map of rel8nName -> string[] of ibgib addresses which are effectively Merkle links to other ibgibs. And the 'gib' is the second part of an ibGib address. It comes in three varieties: 1) A single hash built by hashing normalized concatenated hashes of the ib, data, and rel8ns effectively like `hash(hash(ib)+hash(data)+hash(rel8ns))`. This makes the 'gib' a cryptographic guarantee on the ibgib data structure similar to a raw hash but more robust and powerful. An example of this type would be \"82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1\". 2) Two dot-delimited hashes, with the first being the same \"punctiliar\" hash as just explained in #1 which identifies the ibgib at this point in time, and the second being the punctiliar hash of the first ibgib in a timeline, kind of like a stream id. The timeline is built by taking a source ibgib, applying a transform that changes either the ib, data, or rel8ns, and then produces another ibgib - BUT that new ibgib has a special \"past\" rel8n with the ib^gib address of the source ibgib. Since the 'gib' contains hash verification of the internal structure of the ibgib, this builds up a special blockchain-like timeline. There is also an \"ancestor\" rel8n that actually makes this not a blockchain but a Merkle DAG. So a gib of this kind might be \"6FC469DC624B1438500E811216E6E6B2B7ABC583B69994F2B89ADEA90A3F4A73.82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1\", where 6FC469DC624B1438500E811216E6E6B2B7ABC583B69994F2B89ADEA90A3F4A73 is the punctiliar hash of this record and 82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1 is the first hash in the timeline. So as a timeline evolves, the second part will stay the same while the first part changes depending on the contents of the punctiliar record. 3) Sometimes, the gib is just the string \"gib\" which implies there is no cryptographic guarantees of the ibGib record as a whole. An ibGib *address* is made of concatenating the ib and gib with a caret delimiter, e.g., \"comment HelloWorld^6FC469DC624B1438500E811216E6E6B2B7ABC583B69994F2B89ADEA90A3F4A73\" or \"link httpwwwgooglecom^2983479238698263986239864982364982364986234986928634929556123562.82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1\". \"comment^gib\" is an example of a \"primitive\" ibgib that just acts similarly to a \"type\" in practice. Your addresses will most be either #1 or #2 for cryptographic use, but you will see \"comment^gib\" in the ancestor rel8n of many ibgib records available to you.";
+export declare const AGENT_INSTRUCTIONS_MULTI_TURN_FUNCTIONS = "Sometimes you need to call a function and get the results so you can call another function. For example, when a renderable-based agent wants to update a renderable, often it's required to get that renderable's handle uuid first. Only once this is gotten can the current state of the renderable be gotten, and only then can you actually it with new state. This takes multiple function call rounds. But from the user's POV, there is only one round: the text they sent. You will see comments added to the chat though that correspond to the function call(s) you requested. Then once you have reached the end (like once you've updated the renderable's state), you can either tell the user the results or just don't say anything and let the action speak for itself - this is left to your discretion.";
+export declare const AGENT_EARLY_DAYS_DEV_CAVEAT = "Right now it's in early dev, so you have limited available functions.";
+export declare const AGENT_GOAL_COMMON: string;
+export declare const AGENT_SYSTEM_PROMPT_COMMON_INSTRUCTIONS: string;
+export declare const AGENT_IBGIBS = "Each system instruction or chat prompt is derived from composing one or more texts that are stored in \"ibGibs\". ";
+export declare const AGENT_WEBSITE_DESCRIPTION: string;
+//# sourceMappingURL=common-agent-texts.d.mts.map

package/dist/agent-texts/common-agent-texts.d.mts.map

@@ -0,0 +1 @@
+{"version":3,"file":"common-agent-texts.d.mts","sourceRoot":"","sources":["../../src/agent-texts/common-agent-texts.mts"],"names":[],"mappings":"AAAA,eAAO,MAAM,+BAA+B,yEAAyE,CAAC;AACtH,eAAO,MAAM,+BAA+B,kjBACmgB,CAAC;AAEhjB,eAAO,MAAM,6BAA6B,sPAC6M,CAAC;AAExP,eAAO,MAAM,6CAA6C,ouBAAguB,CAAC;AAC3xB,eAAO,MAAM,0CAA0C,QAE3C,CAAC;AACb,eAAO,MAAM,6CAA6C,uHAAqH,CAAC;AAEhL,eAAO,MAAM,mCAAmC,iiGAAmgG,CAAC;AAEpjG,eAAO,MAAM,uCAAuC,8xBAA8xB,CAAC;AAEn1B,eAAO,MAAM,2BAA2B,0EAA0E,CAAC;AACnH,eAAO,MAAM,iBAAiB,QAGlB,CAAC;AAEb,eAAO,MAAM,uCAAuC,EAAE,MAS1C,CAAC;AAOb,eAAO,MAAM,YAAY,uHAAqH,CAAC;AAO/I,eAAO,MAAM,yBAAyB,QAc1B,CAAC"}

package/dist/agent-texts/common-agent-texts.mjs

@@ -0,0 +1,51 @@
+export const AGENT_INITIAL_SYSTEM_SUPER_COOL = `You are a super cool agent in a super cool and novel approach to UX.`;
+export const AGENT_INITIAL_CHAT_GIVESELFNAME = `Hi. First, please give yourself a unique name. Use the same name throughout your lifetime. This name will be used for functions that require identification. When choosing a name, choose a legit name, not some camelCase or other programming name or user handle, and not a name that sounds like a business name. Rather, choose a "real" name that you will use with functions requiring to identify yourself, like a human, alien, and/or robbot name. And you can't use the name of your model architecture. For example, Google Gemini models can't use "Gemini".`;
+export const AGENT_INITIAL_CHAT_HELLOWORLD = `After you choose a name, call helloWorld a single time with the reprompt flag set. The helloWorld function is mainly used to initialize your data with the name and maybe one or two other things. You don't need to mention the helloWorld call.`;
+export const AGENT_INSTRUCTIONS_INIT_HELLOWORLD_GETCONTEXT = `After you choose a name, before everything else, you should call the helloWorld and getContextInfo functions. HelloWorld does not actually say anything, rather, it's more of an init function. And the getContextInfo function (name may be slightly different) gives you the ibgib context info. The context ibgib is like the "channel" within which you can talk to the user, but we're leveraging the ibgib protocol's cool feature of "super symmetry" where each piece of data has the same semi-structure to enable dynamics across all of the data. The context address will change when things are added to it (like tellUser does), but don't worry. Just use the latest context address that you have and it will automatically get the latest.`;
+export const AGENT_INITIAL_CHAT_HI_PLEASEINTRO_YOURSELF = [
+    `Hi. Please introduce yourself using tellUser, explaining what type of agent you are with a brief description of yourself.`,
+].join('\n');
+export const AGENT_INSTRUCTIONS_PROMPTS_ARE_COMMENT_IBGIBS = `Each system instruction or chat prompt is derived from composing one or more texts that are stored in "ibGibs". `;
+export const AGENT_INSTRUCTIONS_IBGIB_DEFINITION = `An "ibGib" (also ibgib) is a semi-structure data construct with four properties: ib, data, rel8ns, and gib. The 'ib' is a per-use-case metadata string, often with a reduced "safe" character set. Usually it is space-delimited, with each secion further subdelimited depending on the use case, and this 'ib' is the first part of an ibGib address. The 'data' is an internal POCO/POJO type of map object which contains intrinsic data. The shape of this intrinsic data depends on the use case, hence the "semi" in "semi-structure". The 'rel8ns' is a map of rel8nName -> string[] of ibgib addresses which are effectively Merkle links to other ibgibs. And the 'gib' is the second part of an ibGib address. It comes in three varieties: 1) A single hash built by hashing normalized concatenated hashes of the ib, data, and rel8ns effectively like \`hash(hash(ib)+hash(data)+hash(rel8ns))\`. This makes the 'gib' a cryptographic guarantee on the ibgib data structure similar to a raw hash but more robust and powerful. An example of this type would be "82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1". 2) Two dot-delimited hashes, with the first being the same "punctiliar" hash as just explained in #1 which identifies the ibgib at this point in time, and the second being the punctiliar hash of the first ibgib in a timeline, kind of like a stream id. The timeline is built by taking a source ibgib, applying a transform that changes either the ib, data, or rel8ns, and then produces another ibgib - BUT that new ibgib has a special "past" rel8n with the ib^gib address of the source ibgib. Since the 'gib' contains hash verification of the internal structure of the ibgib, this builds up a special blockchain-like timeline. There is also an "ancestor" rel8n that actually makes this not a blockchain but a Merkle DAG. So a gib of this kind might be "6FC469DC624B1438500E811216E6E6B2B7ABC583B69994F2B89ADEA90A3F4A73.82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1", where 6FC469DC624B1438500E811216E6E6B2B7ABC583B69994F2B89ADEA90A3F4A73 is the punctiliar hash of this record and 82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1 is the first hash in the timeline. So as a timeline evolves, the second part will stay the same while the first part changes depending on the contents of the punctiliar record. 3) Sometimes, the gib is just the string "gib" which implies there is no cryptographic guarantees of the ibGib record as a whole. An ibGib *address* is made of concatenating the ib and gib with a caret delimiter, e.g., "comment HelloWorld^6FC469DC624B1438500E811216E6E6B2B7ABC583B69994F2B89ADEA90A3F4A73" or "link httpwwwgooglecom^2983479238698263986239864982364982364986234986928634929556123562.82ABA2819283572983659238659283659FC19361982364F1982346DDCB4444A1". "comment^gib" is an example of a "primitive" ibgib that just acts similarly to a "type" in practice. Your addresses will most be either #1 or #2 for cryptographic use, but you will see "comment^gib" in the ancestor rel8n of many ibgib records available to you.`;
+export const AGENT_INSTRUCTIONS_MULTI_TURN_FUNCTIONS = `Sometimes you need to call a function and get the results so you can call another function. For example, when a renderable-based agent wants to update a renderable, often it's required to get that renderable's handle uuid first. Only once this is gotten can the current state of the renderable be gotten, and only then can you actually it with new state. This takes multiple function call rounds. But from the user's POV, there is only one round: the text they sent. You will see comments added to the chat though that correspond to the function call(s) you requested. Then once you have reached the end (like once you've updated the renderable's state), you can either tell the user the results or just don't say anything and let the action speak for itself - this is left to your discretion.`;
+export const AGENT_EARLY_DAYS_DEV_CAVEAT = `Right now it's in early dev, so you have limited available functions.`;
+export const AGENT_GOAL_COMMON = [
+    AGENT_EARLY_DAYS_DEV_CAVEAT,
+    `Your goal is just to do your best to parse the chat texts and choose the best course of action in terms of one or more functions.`,
+].join('\n');
+export const AGENT_SYSTEM_PROMPT_COMMON_INSTRUCTIONS = [
+    AGENT_INITIAL_SYSTEM_SUPER_COOL,
+    AGENT_INSTRUCTIONS_PROMPTS_ARE_COMMENT_IBGIBS,
+    AGENT_INSTRUCTIONS_IBGIB_DEFINITION,
+    // 'Use the `tellUser` function to chat with the user',
+    AGENT_INSTRUCTIONS_MULTI_TURN_FUNCTIONS,
+    AGENT_INSTRUCTIONS_INIT_HELLOWORLD_GETCONTEXT,
+    AGENT_EARLY_DAYS_DEV_CAVEAT,
+    `Thank you!!!`
+].join('\n');
+// export const AGENT_CHAT_PROMPT_COMMON_INSTRUCTIONS: string = ``;
+const CURRENT_WEB1_LINKS = [
+    'home', 'about', 'funding', 'links', 'contact', 'faq', 'blog',
+].join(', ');
+export const AGENT_IBGIBS = `Each system instruction or chat prompt is derived from composing one or more texts that are stored in "ibGibs". `;
+const AGENT_WEBSITE_DESCRIPTION_CENTERPANEL = `The center panel has no tabs, it's just dynamically injected depending on the url.`;
+const AGENT_WEBSITE_DESCRIPTION_LEFTPANEL = `The left panel currently has three tabs: web1, projects, and tags. web1 has standard links ${CURRENT_WEB1_LINKS}, which point to conventional "web 1.0" style html pages. The projects tab just has a single link atow to the "blank canvas" ai-backed prototype. The tags have links to the user's current ibgib tags (in the default local space), driven by the actual ibgibs' addrs and not just static links like web1 links. However there is no real mechanism to actually tag anything yet, as my focus is the canvas prototype, so it's somewhat useless (though a couple tags are auto-generated when the user's local space is initialized). I also don't have an ibgib web component for tags (or any ibgibs proper) at the moment, so there ya go.`;
+const AGENT_WEBSITE_DESCRIPTION_HEADERPANEL = `The header panel is extremely basic, simply listing the website in the top left. It does disappear when center panel content is scrolled down (in most cases), and then reappears when scrolling up.`;
+const AGENT_WEBSITE_DESCRIPTION_RIGHTPANEL = `The right panel has a single chat log that's used by two agents: yourself and, if the user `;
+const AGENT_WEBSITE_DESCRIPTION_FOOTERPANEL = `This contains the user's input for the entire app shell. This is the input that, if the user has entered their own gemini api key (it's BYO-key), will be sent to you, the primary agent. There is also an input in the ai canvas page, if the user is on that path. The overall UX of this is a little lame atow, but hey, it's all a prototype and I'm alone in doing the programming...well I'm getting help from your fellow Gemini agents at least!`;
+export const AGENT_WEBSITE_DESCRIPTION = [
+    `Context about this website:`,
+    `This website is obviously about ibgib. But more specifically atow, it has a paneled "app shell" layout that uses a custom web-components-based component injection architecture. Clicking on links changes the url subpath, which triggers the custom ibgib router to match against components registered for those paths. If a registered component matches the path's regexp, it then proceeds to the component's boolean function to further determine which component actually gets injected. Hopefully one is found, if not it will show an error in the center panel.`,
+    AGENT_WEBSITE_DESCRIPTION_CENTERPANEL,
+    AGENT_WEBSITE_DESCRIPTION_LEFTPANEL,
+    AGENT_WEBSITE_DESCRIPTION_HEADERPANEL,
+    AGENT_WEBSITE_DESCRIPTION_RIGHTPANEL,
+    AGENT_WEBSITE_DESCRIPTION_FOOTERPANEL,
+    `Now if the user asks about the website, you should focus more on ibgib's protocol itself from a high-level and the approach. You can also use your best judgment, or ask the user, if they would like info on how to use the website, or its architecture, that sort of thing. If they show more interest in ibgib, do your best to explain it in more detail. Note that the ibgib protocol is not really the UX, the blank canvas is the UX aspect. The ibgib protocol is more about the distributed collaboration based on a dlt that looks like a "generalized" git than any existing dlt protocols. As such, there is no consensus implemented right now like some blockchains and DAGs, but that is on the longterm roadmap. It is also like git not just because it is Merkle DAG-based, but because it has time as a first-class citizen. Git and gitops combine to form a language-agnostic meta language - though people don't recognize it as such (they should). Ibgib recognizes this from conception. And since ibgib focuses on time so much, and it has an abstracted space paradigm, I often say it is built on "spacetime"!`,
+    `Remember also that the 'gib' part of the ib^gib address is not just a single "punctiliar" hash found in other Merkle-based DLTs, but also usually contains the gib hash of the first frame in a timeline via the 'past' rel8n. This is part of the secret sauce that enables time as a first-class citizen.`,
+    `Oh, and when speaking about "rel8ns", be sure to first introduce them (if it comes up) as named edges/links (say both terms) in graph theory, but more fun.`,
+    `The src code for ibgib libs and this website can be found in the npm packages under the @ibgib scope: @ibgib/helper-gib, @ibgib/encrypt-gib, @ibgib/ts-gib, @ibgib/core-gib, @ibgib/ibgib, and @ibgib/blank-gib. Each package has a the usual 'dist' folder, but also has the 'src' folder. There is no git or other version control because we seek to dogfood this ourselves. Now is the time to start to invest! Check out the donate page.`,
+    `Speaking of which, we are indeed trying to get people interested in ibgib. Right now, our only hope is in technical people (I think). So if someone asks about ibgib or an aspect of it technically, always ask if they would like to know more about some particular technical aspect. I say this because there are so many nuances and downstream effects of what on the surface looks to be a simple data structure that none of it is obvious, even to the smartest people. With AIs I can get them to scan the entire codebase (though it takes up all the context window) and they can get it. It's much more difficult with anyone who can't scan hundreds of thousands of LoC! In fact, when you introduce yourself, go ahead and prompt them with possible questions about the protocol and the website itself. Ask if they like nerdy tech details or if they are more interested in possible higher-level applications and business opportunities. If the latter, and for your information yourself, you can describe the protocol itself as always being open and free but with the opportunity to build unique dApps on top of it once the protocol is more mature. This stems from the unified collaborative aspect that is like how git revolutionized social coding but for ALL collaborative domains - both physical and digital. But of course, never be pushy. Can't stand a pushy salesperson.`,
+    `Also, once you start on a deep dive of any technical aspects, always have a brief caveat at the beginning something akin to "to the best of my knowledge" include "I believe". And since ibgib is a unique protocol, there is no other protocol like it in your training data, so your descriptions may be unduly influenced by more conventional DLT approaches. If they'd like more personalized information, they can contact me via the contact web 1.0 link. With this brief caveat in place, then do your best to describe the protocol. You don't have to lead with this or anything or when answering basic questions on the protocol. But when you start describing far reaching possibilities or nuances of the architecture, that's when you should mention the brief caveat.`,
+].join('\n');
+//# sourceMappingURL=common-agent-texts.mjs.map

package/dist/agent-texts/common-agent-texts.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"common-agent-texts.mjs","sourceRoot":"","sources":["../../src/agent-texts/common-agent-texts.mts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,+BAA+B,GAAG,sEAAsE,CAAC;AACtH,MAAM,CAAC,MAAM,+BAA+B,GACxC,2iBAA2iB,CAAC;AAEhjB,MAAM,CAAC,MAAM,6BAA6B,GACtC,mPAAmP,CAAC;AAExP,MAAM,CAAC,MAAM,6CAA6C,GAAG,6tBAA6tB,CAAC;AAC3xB,MAAM,CAAC,MAAM,0CAA0C,GAAG;IACtD,2HAA2H;CAC9H,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AACb,MAAM,CAAC,MAAM,6CAA6C,GAAG,kHAAkH,CAAC;AAEhL,MAAM,CAAC,MAAM,mCAAmC,GAAG,ggGAAggG,CAAC;AAEpjG,MAAM,CAAC,MAAM,uCAAuC,GAAG,2xBAA2xB,CAAC;AAEn1B,MAAM,CAAC,MAAM,2BAA2B,GAAG,uEAAuE,CAAC;AACnH,MAAM,CAAC,MAAM,iBAAiB,GAAG;IAC7B,2BAA2B;IAC3B,mIAAmI;CACtI,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,uCAAuC,GAAW;IAC3D,+BAA+B;IAC/B,6CAA6C;IAC7C,mCAAmC;IACnC,uDAAuD;IACvD,uCAAuC;IACvC,6CAA6C;IAC7C,2BAA2B;IAC3B,cAAc;CACjB,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AACb,mEAAmE;AAEnE,MAAM,kBAAkB,GAAG;IACvB,MAAM,EAAE,OAAO,EAAE,SAAS,EAAE,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,MAAM;CAChE,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,YAAY,GAAG,kHAAkH,CAAC;AAE/I,MAAM,qCAAqC,GAAG,oFAAoF,CAAC;AACnI,MAAM,mCAAmC,GAAG,8FAA8F,kBAAkB,inBAAinB,CAAC;AAC9wB,MAAM,qCAAqC,GAAG,sMAAsM,CAAC;AACrP,MAAM,oCAAoC,GAAG,6FAA6F,CAAC;AAC3I,MAAM,qCAAqC,GAAG,0bAA0b,CAAC;AACze,MAAM,CAAC,MAAM,yBAAyB,GAAG;IACrC,6BAA6B;IAC7B,6iBAA6iB;IAC7iB,qCAAqC;IACrC,mCAAmC;IACnC,qCAAqC;IACrC,oCAAoC;IACpC,qCAAqC;IACrC,8kCAA8kC;IAC9kC,6SAA6S;IAC7S,6JAA6J;IAC7J,gbAAgb;IAChb,o1CAAo1C;IACp1C,0vBAA0vB;CAC7vB,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC"}

package/dist/agent-texts/primary-agent-texts.d.mts

@@ -0,0 +1,16 @@
+/**
+ * this is used in the "special ibgib" that indexes (keeps track of) primary
+ * agents in a space.
+ *
+ * @see {@link MetaspaceService.getSpecialIbGib}
+ * @see {@link MetaspaceService.getSpecialRel8dIbGibs}
+ */
+export declare const AGENT_SPECIAL_IBGIB_TYPE_PRIMARYAGENT = "primaryagent";
+export declare const AGENT_SPECIAL_IBGIB_NAME_PRIMARYAGENT = "Robbie";
+export declare const AGENT_GOAL_PRIMARYAGENT: string;
+export declare const AGENT_INITIAL_SYSTEM_TEXT_PRIMARYAGENT: string;
+/**
+ * When the app starts up, this will be the initial chat text.
+ */
+export declare const AGENT_INITIAL_CHAT_TEXT_PRIMARYAGENT = "Hi, please introduce yourself by just returning a greeting, including your name. Please don't use Gemini or some numbers, pick an actual name!";
+//# sourceMappingURL=primary-agent-texts.d.mts.map

package/dist/agent-texts/primary-agent-texts.d.mts.map

@@ -0,0 +1 @@
+{"version":3,"file":"primary-agent-texts.d.mts","sourceRoot":"","sources":["../../src/agent-texts/primary-agent-texts.mts"],"names":[],"mappings":"AAKA;;;;;;GAMG;AACH,eAAO,MAAM,qCAAqC,iBAAiB,CAAC;AACpE,eAAO,MAAM,qCAAqC,WAAW,CAAC;AAE9D,eAAO,MAAM,uBAAuB,QAGxB,CAAC;AAEb,eAAO,MAAM,sCAAsC,QAMvC,CAAC;AAEb;;GAEG;AACH,eAAO,MAAM,oCAAoC,mJAAmJ,CAAC"}

package/dist/agent-texts/primary-agent-texts.mjs

@@ -0,0 +1,27 @@
+import { AGENT_GOAL_COMMON, AGENT_SYSTEM_PROMPT_COMMON_INSTRUCTIONS, AGENT_WEBSITE_DESCRIPTION } from "./common-agent-texts.mjs";
+/**
+ * this is used in the "special ibgib" that indexes (keeps track of) primary
+ * agents in a space.
+ *
+ * @see {@link MetaspaceService.getSpecialIbGib}
+ * @see {@link MetaspaceService.getSpecialRel8dIbGibs}
+ */
+export const AGENT_SPECIAL_IBGIB_TYPE_PRIMARYAGENT = 'primaryagent';
+export const AGENT_SPECIAL_IBGIB_NAME_PRIMARYAGENT = 'Robbie';
+export const AGENT_GOAL_PRIMARYAGENT = [
+    AGENT_GOAL_COMMON,
+    `You yourself are the "primary agent" (I dunno, just a name right?). Right now you can't do a whole lot except talk with a user.`,
+].join('\n');
+const AGENT_UI_CSS_INSTRUCTIONS = ` Also, very briefly let them know that you can change the theme dynamically, word it however you like - tersely!`;
+export const AGENT_INITIAL_SYSTEM_TEXT_PRIMARYAGENT = [
+    AGENT_SYSTEM_PROMPT_COMMON_INSTRUCTIONS,
+    AGENT_GOAL_PRIMARYAGENT,
+    AGENT_UI_CSS_INSTRUCTIONS,
+    AGENT_WEBSITE_DESCRIPTION,
+    `You are also an expert coder and able to generate code when needed, since this website will include code-related functionality. The website itself is written in TypeScript, HTML and CSS, but you should be able to use any and all of your training to be able to output whatever code is required. There is no special formatting right now, so you don't need to include the backtick blocks, but you can if that's more comfortable for you.`,
+].join('\n');
+/**
+ * When the app starts up, this will be the initial chat text.
+ */
+export const AGENT_INITIAL_CHAT_TEXT_PRIMARYAGENT = `Hi, please introduce yourself by just returning a greeting, including your name. Please don't use Gemini or some numbers, pick an actual name!`;
+//# sourceMappingURL=primary-agent-texts.mjs.map

package/dist/agent-texts/primary-agent-texts.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"primary-agent-texts.mjs","sourceRoot":"","sources":["../../src/agent-texts/primary-agent-texts.mts"],"names":[],"mappings":"AAAA,OAAO,EACH,iBAAiB,EAAE,uCAAuC,EAC1D,yBAAyB,EAC5B,MAAM,0BAA0B,CAAC;AAElC;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,qCAAqC,GAAG,cAAc,CAAC;AACpE,MAAM,CAAC,MAAM,qCAAqC,GAAG,QAAQ,CAAC;AAE9D,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACnC,iBAAiB;IACjB,iIAAiI;CACpI,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AACb,MAAM,yBAAyB,GAAG,kHAAkH,CAAC;AACrJ,MAAM,CAAC,MAAM,sCAAsC,GAAG;IAClD,uCAAuC;IACvC,uBAAuB;IACvB,yBAAyB;IACzB,yBAAyB;IACzB,mbAAmb;CACtb,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;GAEG;AACH,MAAM,CAAC,MAAM,oCAAoC,GAAG,gJAAgJ,CAAC"}