@ibgib/ts-gib 0.4.9

package/README.md

@@ -0,0 +1,502 @@
+# ibgib
+
+This is the core part of the ibgib engine, written in TypeScript.
+This is responsible for creating quantum ibgib frames based on
+existing ibgib quanta.
+
+## data structure: `ib`, `gib`, `data`, `rel8ns`
+
+Each ibgib can be thought of both as individual nodes in a Merkle DAG, and as
+streams through time with those individual nodes as reified discrete quanta.
+
+Each quantum node has up to four fields, and each field in one word:
+
+* `ib` - metadata
+* `gib` - checksum
+* `data` - internals
+* `rel8ns` - externals
+
+This is extremely terse and naive of course. Here are slight more fleshed out
+descriptions of each field.
+
+* `ib`
+  * data and metadata
+  * contains simple, core data you want to see _without loading the entire datum into memory_.
+    * Especially important when viewing only a linked relationship ib^gib address.
+* `gib`
+  * metadata
+  * for complex data, this is the hash of the datum's other three fields
+    * so for
+
+    ```json
+    {
+        "ib": "bob",
+        "data": {
+          "bday": "1/1/1"
+        },
+        "rel8ns": {
+          "past": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY"]
+        }
+    }
+    ```
+
+    , the gib could be the hash of the concatenated hashes of the `ib`, `data` and `rel8ns`, e.g. `hash(hash(ib)+hash(data)+hash(rel8ns))
+  * for primitives (e.g. '7' or '"some string"'), implied 'gib' value
+    * so if you see 'test^gib', this implies { ib: test, gib: falsy or 'gib', data: falsy, rel8ns: falsy }
+* `data`
+  * intrinsic 'simple' primitive data.
+    * e.g. `data: { name: "arthur", age: 42 }`
+  * You can nest primitive-ish data objects, depending on your use case.
+* `rel8ns`
+  * extrinsic 'complex' data
+  * named lists of merkle pointers to other content addressable ibgibs via their `ib^gib` addresses.
+    * e.g. `"rel8ns": { "past": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY"] }`
+  * depending on type of rel8ns you're using, this can be ...
+    * a single pointer like a linked list or blockchain style.
+    * multiple pointers like a hash table.
+  * these pointers are cryptographic merkle links to immutable frames
+    but in practice often point to a timeline of a mutable ibgib entity.
+
+Here is more detailed information about these fields.
+
+### `ib`
+
+The `ib` is for data and/or metadata that you want to be included in pointers
+to the ibgib record. The entirety of this field will be used, in combination with
+the `gib`, to uniquely identify an ibgib at a particular moment in "time". (Time
+meaning the ibgib's own recorded mutations form a timeline, not necessarily wall time.)
+
+In these examples, I'll give the `ib` and a corresponding possible `ib^gib` address
+using gib placeholders like 'ABC123' which correspond to cryptographic hashes.
+
+* simple
+  * '[name]' or '[title]' or '[filename]'
+    * 'bob' > 'bob^ABC123'
+    * 'Life, The Universe, Everything' > 'Life, The Universe, Everything^DEF456'
+    * 'foo.txt' > 'foo.txt^GHI789'
+* more complex
+  * '[name] [date]' or '[filename] [username]'
+    * 'bob 1/1/2001' > 'bob 1/1/2001^XYZ321'
+    * 'foo.txt bob' > 'foo.txt bob^DDD444'
+* real world complex
+  * 'tx [id] [token] [flag] [mask] [attempts]'
+    * 'tx 123 JWThErE12x.y.z_no_spaces T 0110 1^AAA111'
+    * 'tx 345 JWThErE12x.y.z_no_spaces T 0110 999^BBB284'
+  * 'rx|[id]|[token]|[flag]|[mask]|[retries-left]'
+    * 'rx|321|JWT_we can have spaces now in the token..|0|0101|3'
+
+**NOTHING IS HARD CODED IN THE BASE GRAPH LIB REGARDING SCHEMAS.**
+
+With the ibgib protocol, you can have your version control specs on-chain.
+One of these specs can be a canon/template/schema for the `ib` field, or you can keep the
+structure of the ib off-chain (but lose the usefulness of on-chain-ness).
+This includes how the ib is delimited. For example, I often space-delimit the ib's
+various pieces, which themselves are underscore or hyphen delimited. Since
+the ib is much like a filename, it is often convenient to consider which
+characters are allowed in which OSes you will want to interop with.
+
+### `gib`
+
+For starters, you can simply think of this as the hash of the other three fields.
+It provides integrity of the record by default, and helps in building out
+ibgib's version of a Merkle DAG.
+
+### `rel8ns`
+
+The `rel8ns` is a mapping of relationships among ibgibs, in a very similar
+manner to edges/links in a graph. It's not quite the same, because the
+graph is NOT just a DAG (directed acyclic graph), but we'll get to that.
+
+#### a note on `ib^gib` addresses
+
+Ibgib has a content addressable design. This means that we create an
+address that is directly (and deterministically) related to the content
+of the data.
+
+In many other content addressing systems, only the hash is used, with some
+using hard-coded metadata tacked on post-hoc and hard-coded in source code.
+Ibgibs however use the `ib` field plus a delimiter (`^` by default) and the
+`gib`, often referred to just as its `ib^gib`.
+
+_This allows for on-chain, use-case driven decisions for exactly what metadata to include with the addresses!_
+
+I've found over the years of programming with this approach that this is
+ludicrously useful for making decisions in functions, algorithms and workflows
+without requiring the resources to fully load a datum.
+
+#### `rel8ns` structure V1
+
+So the `rel8ns` themselves have the structure of rel8n names to arrays of
+`ib^gib` addresses.
+
+```json
+"rel8ns": {
+  "[rel8nName]": ["ib^gib address", "ib^gib2", "ib^1ac45ff5631f4a98a2148e24abc534d3"], // <<< general form
+  "past": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY"],
+  "ancestor": ["bob^gib"],
+  "tjp": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY"],
+  "friend": ["alice^34a807c927d84068af2e8b1cd24b4cb8", "charlie^0b54e0760c54441285374125563ef672", ],
+}
+```
+
+There are a couple special rel8n names here: `past`, `ancestor` and `tjp`.
+
+#### `past` rel8n
+
+Ibgib is largely an append-only system very much like other version control systems.
+_(I often conceive it as a semantic version control system, not hyperoptimized for text)_
+Whenever you add/remove/edit an ibgib's property (`ib`, `data` or `rel8ns`), you are
+mutating that ibgib across "time". That timeline is defined in the ibgib's terms
+as its past. This is like what some other systems call an audit log, or like the previous links
+of a blockchain. But it isn't - not in ibgib's terms. It is much more appropriate to think of
+the ibgib as an entity progressing through time, and the record is like an echo/metric/projection
+of that entity in our data space(s).
+
+_The data is never the ibgib though!_
+
+So when we notice a change of the ibgib either intrinsically (its `data` field)
+or extrinsically (via its `rel8ns` to other ibgibs), we record a new ibgib datum/frame/quantum
+with those changed intrinsic/extrinsic attributes and link the record to the previous one
+via the `past` rel8n, either by appending the previous to the current frame's `past`
+rel8n (which costs more in terms of storage resources), or by replacing the
+`past` array with the single `ib^gib` address of the previous incarnation.
+If the former, then we are growing the record each time, which will cost us
+more resources in terms of storage but will provide quicker access to previous
+frames. If the latter, which is more a blockchain linked-list style, then we
+inevitably use less storage because it's always just one address, but it will
+cost more to traverse the linked list both in terms of memory and processing costs.
+
+This tradeoff between rel8n style is not just with the `past` rel8n but can be
+with any rel8n you desire per use case.
+
+Append style (default):
+```json
+{
+  "past": [""],
+}
+// mut8 or rel8 transform
+{
+  "past": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY"],
+}
+// mut8 or rel8 transform
+{
+  "past": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY", "bob^070e3fc9aab34f4ba1090f9519d9676a"],
+}
+// mut8 or rel8 transform
+{
+  "past": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY", "bob^070e3fc9aab34f4ba1090f9519d9676a", "bob^e556d72ace93428a98d222c960135e29"],
+}
+```
+
+See how it keeps growing? That will cost us in the long run in storage if we expect a lot of records.
+
+Linked style (via `linkedRel8ns` parameter):
+
+```json
+{
+  "past": [""],
+}
+// mut8 or rel8 transform
+{
+  "past": ["bob^OLDHASH123456HOOGLEDYBOOGLEDY"],
+}
+// mut8 or rel8 transform
+{
+  "past": ["bob^070e3fc9aab34f4ba1090f9519d9676a"],
+}
+// mut8 or rel8 transform
+{
+  "past": ["bob^e556d72ace93428a98d222c960135e29"],
+}
+```
+
+In this case, we simply have a single rel8n to only the previous frame of the ibgib's existence,
+much like a linked list or a blockchain. This will save in terms of storage, but we
+will need to load each previous record in order to get the prior one. To combat this,
+and for many other reasons, the `tjp` rel8n is required which is a pointer to the
+very first unique address of the ibgib. But first, the `ancestor` rel8n.
+
+#### `ancestor` rel8n
+
+Creating "new" ibgibs is actually a process of `fork`-ing existing ones, with
+theoretically something "brand new" being a fork of the root ibgib
+(with the actual address of `ib^gib`). When we perform this `fork` transform
+(we'll get to that), we will clear out the `past` rel8n and add the source
+ibgib to the `ancestor` rel8n.
+
+_NOTE: If we're forking from the root, we'll leave `ancestor` empty just to save space, but whenever you see an empty array, it's always populated with at least `ib^gib`!_
+
+So while an ibgib mutating intrinsically (via `mut8` transform) or extrinsically (via `rel8` transform) will append to its
+`past` rel8n, a `fork` transform will clear the `past` and append to the `ancestor` rel8n. (This ain't your
+grandpa's blockchain!)
+
+#### `tjp` rel8n
+
+Have you ever seen Back to the Future II? Do you remember the scene where Biff steals the Delorean
+and goes back to 1955 - **the same point in time Marty went back to in Back to the Future I!!!**
+
+Doc Brown calls that the Temporal Junction Point (or maybe it's just a coincidence). So that's what
+I've called it. But that is extremely long to write, and it's so important that the terse `tjp` is
+acceptable (I usually vehemently eschew variable names so short, if you don't mind a few $5 words).
+
+So it turns out that this is **extremely** important. When you want to refer to an instance in time
+for an ibgib, then you can refer to its `ib^gib` address. But when you want to refer to the _timeline_
+of an ibgib, then you refer to its temporal junction point (`tjp`). This is used, for example,
+in tracking the latest version of an ibgib. Also for subscribing to changes to an ibgib.
+
+#### `dna` rel8n
+
+If you choose, you can capture not only the ibgib frames in the ibgib timeline, but also the
+"code" that was used to create each proceeding frame.
+
+See the following section on transforms for more info.
+
+### `data`
+
+This is where you "link" to intrinsic, usually primitive data. For example, say you had
+
+```json
+"data": {
+  "name": "Bob",
+  "favoriteNumber": 42,
+}
+```
+
+You could think of both "Bob" and 42 as being "Bob"^gib and 42^gib, so these indeed are
+"rel8ns" to these primitives similar to the `rel8ns` property.
+
+But for the most part, it's easiest to just think of the `data` as containing the
+"actual" reified, simple data payloads.
+
+## transforms
+
+The three primary low-level transforms are: `fork`, `mut8` and `rel8`.
+
+Each is encapsulated in an ibgib record of its own, and if you choose to track the
+transform, its transform `ib^gib` address will be related to the newly created ibgib
+via the special `dna` rel8n name.
+
+For those familiar with event sourcing, this is quite similar to memo-izing both
+the events and the aggregate values. The primary proximal benefit of this design however,
+beyond those we get from the ibgib architecture in general, is that unlike with
+event sourcing, we can apply this dna not only to rehydrate to produce the same
+output, but to reapply to a different ibGib (or the same ibgib in a different space)
+specifically to produce _different_ output.
+
+Think applying diffs to different branches during merges...but instead of only
+working in the text level, we're working at the semantic level!
+
+_(We can optimize for storage through other methods such as compression of less used ibgibs...it's relatively easy to index them since we're using content addressing to begin with.)_
+
+### `fork` transform
+
+When we `fork` an ibgib A, we create a "new" ibgib B. This clears out `B.rel8ns.past`
+and appends A's address to `B.rel8ns.ancestor` (remember all hashes are just made up here):
+
+```
+// source A that we will `fork`
+{
+  "ib": "A",
+  "gib": "ed4ce4c485b84bdb95c59affbefc138e",
+  "rel8ns": {
+    "past": ["A^fbb1369596684e61ad093f33486ed615, A^7464b055d8524b638818aabab078e146, A^a96e9afc41c04245ad02036f7c1f7b53],
+    "ancestor": [], // implied "ib^gib", but not too important :-0
+    "dna": []
+  },
+  "data": {
+    "foo": "bar",
+    "bar": "bazzz"
+  }
+}
+
+// transform T
+{
+  "ib": "fork",
+  "gib": "bebbe34768434d909fc1ca3ab47c0b9f",
+  "data": {
+    "type": "fork",
+    "srcAddr": "A^ed4ce4c485b84bdb95c59affbefc138e",
+    "destIb": "B",
+    "dna": true,
+    ...
+  },
+  "rel8ns": {
+    "ancestor": ["fork^gib"] // ancestry often acts as a "type" hierarchy
+    ...
+  }
+}
+
+// output B produced by the `fork`
+{
+  "ib": "B", // new ib
+  "gib": "f94448aa676d4d398241b80575c8e31e",
+  "rel8ns": {
+    "past": [], // cleared
+    "ancestor": ["a^ed4ce4c485b84bdb95c59affbefc138e"], // added source address
+    "dna": ["fork^bebbe34768434d909fc1ca3ab47c0b9f"]
+  },
+  "data": { // same data
+    "foo": "bar",
+    "bar": "bazzz"
+  }
+}
+// output B
+```
+
+In this example, we `fork` with source A (A^ed4ce4c485b84bdb95c59affbefc138e), with
+`fork` transform T (fork^bebbe34768434d909fc1ca3ab47c0b9f), specifying a new ib "B" (`T.data.destIb`),
+and it produced the "new" B with a cleared `B.rel8ns.past`. We didn't _have_ to give it a new
+ib, that's just to point out that these are two distinct timelines.
+
+_The hierarchy via `ancestor` is also its own kind of "timeline", but that's for another time._
+
+### `mut8` transform
+
+### `rel8` transform
+
+## so what
+
+### v bitcoin
+
+nothing.
+
+But if that's not exciting enough for you, ibgib was developed for distributed
+computation apart from the bitcoin world. Here are just some of the design decision
+differences:
+
+* consensus is off-chain (or rather on-chain in git which itself is another Merkle DAG)
+* PoW is hard-coded
+  * thus PoW is naive (in the computation sense), since it requires huge effort to recode/move to some other proof.
+* the source code is not part of the blockchain
+  * so it's open src, and it's open data, but the src and data live in silos.
+* centralized in the source code.
+  * you're at the mercy of their coders to write the one chain to rule them all.
+* these lead to consequences that make things like data projection & replication
+  extremely non-trivial, let alone MANY other opportunity costs with technical debt.
+
+What's good about bitcoin? Well it's awesome and still in wide use across the globe.
+PoW was extremely novel and cool.
+
+### v permissioned blockchains/DLTs
+
+Basically, people are taking the blockchain/distributed ledger paradigm and trying
+to apply it to other forms of distributed computing. without exception, each of these
+starts by writing source code that is stored in a separate distributed ledger (called
+git or [insert vcs here]) with no plan on dogfooding the source code back into the
+process. Now you have to write and maintain code for (at least) both your source code
+and your data, whereas you should be able to reuse code analysis/replication/identity
+tools in a streamlined fashion.
+
+For example, if I write a view that presents data in a certain way, I might now use
+that same view to look at other data (possibly the code for the view itself) with
+little-to-no modification. And if I am a learner
+
+...anyway, lotsa writing. I invariably seem to write these kinds of things to get
+the brain going, but I digress...
+
+## contributing
+
+### to add unit tests (specs)
+
+Add a file in the same folder as the one you want to test.
+Copy the filename and add .spec just before the extension,
+e.g. src/folder/file-here.ts -> src/folder/file-here.spec.ts
+
+## questions
+
+### what is an ibgib?
+
+what isn't?
+
+### no really...
+
+Semi-structured (JSON) data structure which creates a DLT graph with directed,
+non-directed, cyclic and acyclic qualities. Very much like a semantic version
+control system on a graph substrate to "track" "things".
+
+### attention and devil's advocate
+
+Think of the dynamic between our brain's process of "attention" and
+the possibility of "playing devil's advocate". Essentially, you can
+either point your attention at some "thing" where you think of
+extending that same thing over time, or you can think of "splitting"
+that thing and considering the result to be some "new" thing.
+
+But each of these actions (and other permutations and actions not listed)
+itself can be one of those "things". So you can devolve and never extend
+anything, where everything is essentially meaningless. Or you can
+go the other way and say how everything is still the same (one) thing.
+
+But we experience time as a combination of these two options, always with
+the ability to use our own attention to increase the sameness or
+different-ness of any thing.
+
+### semantic version control system
+
+Computer people usually think of version control systems like
+git, OpenCVS, subversion, etc. These usually borrow jargon from
+the evolution of a river or a plant through time, e.g. branching,
+forking, root. But these were developed with source control specifically
+in mind, and they have been hyper-optimized for dealing with text.
+Git has added on non-textual functionality, but it was an afterthought.
+
+ibgib has been made as a self-referencing, bootstrapping semantic
+version control system, and more fundamentally, the protocol that
+underlies this system. By this, all configuration, source code,
+issue tracking, etc., can be stored _inside_ the ibgib data
+structures and using ibgib nodal exchanges.
+
+You can think of the data structure as a Directed Acyclic Graph (DAG),
+but this is only at the physical level **and does not capture
+the cyclic nature of the ability for ibgibs over time to be
+self-referencing** _(and self-negating and other self-thingies)_.
+
+Two of the big focus points are:
+1) Each datum is from some perspective, i.e. it's a belief held by an identity.
+2) Each datum has context where it is "true" and where it is "false", which actually
+defines what these terms mean.
+
+Truth/falseness is determined by the attention on a thing, i.e. wherever
+the ibgibs that continue to evolve and persist, those are said to be
+"true within that context". Each context itself can be an ibgib, and
+this framework provides an addressing scheme/space for this process of attention
+that streamlines interaction between microservices/systems, ais, humans,
+multi-human organizations, etc. It also does a lot of other stuff.
+
+Ibgibs are also mobile, and can move among contexts proactively,
+in addition to the contexts themselves changing over time.
+
+### goedelian numbers counting to infinity
+
+For the even more abstract out there (can't imagine many here on Earth): Each ibgib
+datum is a goedelian number. The `ib^gib` (content) address ends up being this number,
+and what we are actually doing is counting through time to infinity. But things
+"at" infinity act differently than in the finite world.
+
+When you "add" a number, the number was already there from some other context. This
+stems from the existence of one infinity not only implies but requires _all infinities_
+"to exist". But we experience this process over time. So it also requires that
+_all infinities_ "do NOT exist".
+
+Remember the aforementioned attention? This is where we resolve the issue of seemingly
+self-negating statements, e.g., "This statement is false." If you think of this naively
+with the dead concept of true/false, then you run into a problem. Most scientists and
+mathematicians dislike this, just as they dislike most quantum outcomes - a feeling
+which manifests itself as these effects being "weird". But back to the attention.
+
+"Both" pathways through a self-negating statement are "true" in some context,
+and as such when you are also in "that" context, you will attend to that pathway.
+You will provide more time to it _within you yourself as a context_.
+
+Just as you have competing thoughts and emotions (terms which are much more
+easily understood with the concept of ibgib) within yourself which can seem to be
+diametrically opposed, so any statement can be. This can lead to understanding the
+difficulties with current friction between, e.g., pure and applied mathematicians.
+Context for "proofs" is absolutely paramount: Under this condition X,Y,Z using these
+axioms, etc. But neither axioms, nor their corollaries or proofs, are "true"
+absolutely. If you agree with this, then it is true within your context. On down
+the road of your life, when you disagree with this, it is false within your context.
+Etc...
+
+Enough typing for now, back to coding. Feel free (future and past beings), jump in with
+your isomorphic ibgib engines in the chat, or email me at bill.mybiz@gmail.com .

package/dist/V1/constants.d.mts

@@ -0,0 +1,22 @@
+import { IbGib_V1 } from './types.mjs';
+export declare const IB = "ib";
+export declare const GIB = "gib";
+export declare const ROOT: IbGib_V1;
+export declare const IBGIB_DELIMITER = "^";
+/**
+ * Gib is often just a single hash for a single ib^gib record.
+ * But if the ibgib has a tjp, which implies a timeline ("stream"
+ * in some senses), then we will include the tjp gib hash alongside the
+ * individual punctilear ibgib frame.
+ *
+ * ATOW this has the default schema of
+ *
+ * @example "comment abc^TJPHASH123", "comment abc^TJPHASH123.THISRECORDHASH456"
+ */
+export declare const GIB_DELIMITER = ".";
+export declare const ROOT_ADDR = "ib^gib";
+/**
+ * Some rel8ns should not be able to be renamed or removed.
+ */
+export declare const FORBIDDEN_ADD_RENAME_REMOVE_REL8N_NAMES: string[];
+//# sourceMappingURL=constants.d.mts.map

package/dist/V1/constants.d.mts.map

@@ -0,0 +1 @@
+{"version":3,"file":"constants.d.mts","sourceRoot":"","sources":["../../src/V1/constants.mts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,MAAM,aAAa,CAAC;AAEvC,eAAO,MAAM,EAAE,OAAO,CAAC;AACvB,eAAO,MAAM,GAAG,QAAQ,CAAC;AACzB,eAAO,MAAM,IAAI,EAAE,QAAgC,CAAA;AACnD,eAAO,MAAM,eAAe,MAAM,CAAC;AACnC;;;;;;;;;GASG;AACH,eAAO,MAAM,aAAa,MAAM,CAAC;AACjC,eAAO,MAAM,SAAS,WAAW,CAAC;AAElC;;GAEG;AACH,eAAO,MAAM,uCAAuC,UAAqC,CAAC"}

package/dist/V1/constants.mjs

@@ -0,0 +1,21 @@
+export const IB = 'ib';
+export const GIB = 'gib';
+export const ROOT = { ib: IB, gib: GIB, };
+export const IBGIB_DELIMITER = '^';
+/**
+ * Gib is often just a single hash for a single ib^gib record.
+ * But if the ibgib has a tjp, which implies a timeline ("stream"
+ * in some senses), then we will include the tjp gib hash alongside the
+ * individual punctilear ibgib frame.
+ *
+ * ATOW this has the default schema of
+ *
+ * @example "comment abc^TJPHASH123", "comment abc^TJPHASH123.THISRECORDHASH456"
+ */
+export const GIB_DELIMITER = '.';
+export const ROOT_ADDR = 'ib^gib'; // `${IB}${IBGIB_DELIMITER}${GIB}`;
+/**
+ * Some rel8ns should not be able to be renamed or removed.
+ */
+export const FORBIDDEN_ADD_RENAME_REMOVE_REL8N_NAMES = ['past', 'ancestor', 'dna', 'tjp'];
+//# sourceMappingURL=constants.mjs.map

package/dist/V1/constants.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"constants.mjs","sourceRoot":"","sources":["../../src/V1/constants.mts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,EAAE,GAAG,IAAI,CAAC;AACvB,MAAM,CAAC,MAAM,GAAG,GAAG,KAAK,CAAC;AACzB,MAAM,CAAC,MAAM,IAAI,GAAa,EAAE,EAAE,EAAE,EAAE,EAAE,GAAG,EAAE,GAAG,GAAG,CAAA;AACnD,MAAM,CAAC,MAAM,eAAe,GAAG,GAAG,CAAC;AACnC;;;;;;;;;GASG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG,GAAG,CAAC;AACjC,MAAM,CAAC,MAAM,SAAS,GAAG,QAAQ,CAAC,CAAC,mCAAmC;AAEtE;;GAEG;AACH,MAAM,CAAC,MAAM,uCAAuC,GAAG,CAAC,MAAM,EAAE,UAAU,EAAE,KAAK,EAAE,KAAK,CAAC,CAAC"}

package/dist/V1/factory.d.mts

@@ -0,0 +1,23 @@
+import { Ib, IbGib, IbGibRel8ns, TransformResult, TemporalJunctionPointOptions } from '../types.mjs';
+import { IbGib_V1 } from './types.mjs';
+export declare class Factory_V1 {
+    static root(): IbGib_V1<import("./types.mjs").IbGibData_V1, import("./types.mjs").IbGibRel8ns_V1>;
+    static primitive({ ib }: {
+        ib: Ib;
+    }): IbGib_V1;
+    static primitives({ ibs }: {
+        ibs: Ib[];
+    }): IbGib_V1<import("./types.mjs").IbGibData_V1, import("./types.mjs").IbGibRel8ns_V1>[];
+    static firstGen<TData = any>({ ib, parentIbGib, data, rel8ns, dna, tjp, linkedRel8ns, noTimestamp, nCounter, }: {
+        ib: Ib;
+        parentIbGib: IbGib;
+        data?: TData;
+        rel8ns?: IbGibRel8ns;
+        dna?: boolean;
+        tjp?: TemporalJunctionPointOptions;
+        linkedRel8ns?: string[];
+        noTimestamp?: boolean;
+        nCounter?: boolean;
+    }): Promise<TransformResult<IbGib_V1<import("./types.mjs").IbGibData_V1, import("./types.mjs").IbGibRel8ns_V1>>>;
+}
+//# sourceMappingURL=factory.d.mts.map

package/dist/V1/factory.d.mts.map

@@ -0,0 +1 @@
+{"version":3,"file":"factory.d.mts","sourceRoot":"","sources":["../../src/V1/factory.mts"],"names":[],"mappings":"AAGA,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,WAAW,EAAE,eAAe,EAAE,4BAA4B,EAAE,MAAM,cAAc,CAAC;AACrG,OAAO,EAAE,QAAQ,EAAE,MAAM,aAAa,CAAC;AAGvC,qBAAa,UAAU;IACnB,MAAM,CAAC,IAAI;IAGX,MAAM,CAAC,SAAS,CAAC,EACb,EAAE,EACL,EAAE;QACC,EAAE,EAAE,EAAE,CAAA;KACT,GAAG,QAAQ;IAIZ,MAAM,CAAC,UAAU,CAAC,EACd,GAAG,EACN,EAAE;QACC,GAAG,EAAE,EAAE,EAAE,CAAA;KACZ;WAIY,QAAQ,CAAC,KAAK,GAAG,GAAG,EAAE,EAC/B,EAAO,EACP,WAA+B,EAC/B,IAAI,EACJ,MAAM,EACN,GAAG,EACH,GAAG,EACH,YAAY,EACZ,WAAW,EACX,QAAQ,GACX,EAAE;QACC,EAAE,EAAE,EAAE,CAAC;QACP,WAAW,EAAE,KAAK,CAAC;QACnB,IAAI,CAAC,EAAE,KAAK,CAAC;QACb,MAAM,CAAC,EAAE,WAAW,CAAC;QACrB,GAAG,CAAC,EAAE,OAAO,CAAC;QACd,GAAG,CAAC,EAAE,4BAA4B,CAAC;QACnC,YAAY,CAAC,EAAE,MAAM,EAAE,CAAC;QACxB,WAAW,CAAC,EAAE,OAAO,CAAC;QACtB,QAAQ,CAAC,EAAE,OAAO,CAAC;KACtB;CA8DJ"}

package/dist/V1/factory.mjs

@@ -0,0 +1,78 @@
+import { fork } from './transforms/fork.mjs';
+import { mut8 } from './transforms/mut8.mjs';
+import { rel8 } from './transforms/rel8.mjs';
+import { IB, GIB, ROOT } from './constants.mjs';
+export class Factory_V1 {
+    static root() {
+        return Factory_V1.primitive({ ib: IB });
+    }
+    static primitive({ ib }) {
+        return { ib, gib: GIB };
+    }
+    static primitives({ ibs }) {
+        return ibs.map(ib => Factory_V1.primitive({ ib }));
+    }
+    static async firstGen({ ib = IB, parentIbGib = Factory_V1.root(), data, rel8ns, dna, tjp, linkedRel8ns, noTimestamp, nCounter, }) {
+        const lc = `[firstGen]`;
+        /** * Multiple transform steps will create multiple results. */
+        const interimResults = [];
+        let src = parentIbGib || ROOT;
+        let resFork = await fork({
+            src,
+            destIb: ib,
+            tjp,
+            dna,
+            linkedRel8ns,
+            noTimestamp,
+            nCounter,
+        });
+        interimResults.push(resFork);
+        src = resFork.newIbGib;
+        if (data) {
+            let resMut8 = await mut8({
+                src,
+                dataToAddOrPatch: data,
+                dna,
+                linkedRel8ns,
+                noTimestamp,
+                nCounter,
+            });
+            interimResults.push(resMut8);
+            src = resMut8.newIbGib;
+        }
+        ;
+        if (rel8ns) {
+            let resRel8 = await rel8({
+                src,
+                rel8nsToAddByAddr: rel8ns,
+                dna,
+                linkedRel8ns,
+                noTimestamp,
+                nCounter,
+            });
+            interimResults.push(resRel8);
+            // src = resRel8.newIbGib; // not needed because not used (this is the last step)
+        }
+        if (interimResults.length > 1) {
+            const newIbGib = interimResults.slice(interimResults.length - 1)[0].newIbGib;
+            const result = {
+                newIbGib,
+                intermediateIbGibs: interimResults.slice(0, interimResults.length - 1).map(x => x.newIbGib),
+            };
+            if (dna) {
+                let dnas = [];
+                interimResults.forEach(res => { dnas = dnas.concat(res.dnas); });
+                result.dnas = dnas;
+            }
+            return result;
+        }
+        else if (interimResults.length === 1) {
+            // for some reason the caller just used this as a fork.
+            return interimResults[0];
+        }
+        else {
+            throw new Error(`${lc} hmm, I'm not sure...`);
+        }
+    }
+}
+//# sourceMappingURL=factory.mjs.map

package/dist/V1/factory.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"factory.mjs","sourceRoot":"","sources":["../../src/V1/factory.mts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,uBAAuB,CAAC;AAC7C,OAAO,EAAE,IAAI,EAAE,MAAM,uBAAuB,CAAC;AAC7C,OAAO,EAAE,IAAI,EAAE,MAAM,uBAAuB,CAAC;AAG7C,OAAO,EAAE,EAAE,EAAE,GAAG,EAAE,IAAI,EAAE,MAAM,iBAAiB,CAAC;AAEhD,MAAM,OAAO,UAAU;IACnB,MAAM,CAAC,IAAI;QACP,OAAO,UAAU,CAAC,SAAS,CAAC,EAAE,EAAE,EAAE,EAAE,EAAE,CAAC,CAAC;IAC5C,CAAC;IACD,MAAM,CAAC,SAAS,CAAC,EACb,EAAE,EAGL;QACG,OAAO,EAAE,EAAE,EAAE,GAAG,EAAE,GAAG,EAAE,CAAC;IAC5B,CAAC;IAED,MAAM,CAAC,UAAU,CAAC,EACd,GAAG,EAGN;QACG,OAAO,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC,UAAU,CAAC,SAAS,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC,CAAC;IACvD,CAAC;IAED,MAAM,CAAC,KAAK,CAAC,QAAQ,CAAc,EAC/B,EAAE,GAAG,EAAE,EACP,WAAW,GAAG,UAAU,CAAC,IAAI,EAAE,EAC/B,IAAI,EACJ,MAAM,EACN,GAAG,EACH,GAAG,EACH,YAAY,EACZ,WAAW,EACX,QAAQ,GAWX;QACG,MAAM,EAAE,GAAG,YAAY,CAAC;QACxB,+DAA+D;QAC/D,MAAM,cAAc,GAAgC,EAAE,CAAC;QACvD,IAAI,GAAG,GAAa,WAAW,IAAI,IAAI,CAAC;QACxC,IAAI,OAAO,GAAG,MAAM,IAAI,CAAC;YACrB,GAAG;YACH,MAAM,EAAE,EAAE;YACV,GAAG;YACH,GAAG;YACH,YAAY;YACZ,WAAW;YACX,QAAQ;SACX,CAAC,CAAC;QACH,cAAc,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QAC7B,GAAG,GAAG,OAAO,CAAC,QAAQ,CAAC;QAEvB,IAAI,IAAI,EAAE;YACN,IAAI,OAAO,GAAG,MAAM,IAAI,CAAC;gBACrB,GAAG;gBACH,gBAAgB,EAAE,IAAI;gBACtB,GAAG;gBACH,YAAY;gBACZ,WAAW;gBACX,QAAQ;aACX,CAAC,CAAC;YACH,cAAc,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;YAC7B,GAAG,GAAG,OAAO,CAAC,QAAQ,CAAC;SAC1B;QAAA,CAAC;QAEF,IAAI,MAAM,EAAE;YACR,IAAI,OAAO,GAAG,MAAM,IAAI,CAAC;gBACrB,GAAG;gBACH,iBAAiB,EAAE,MAAM;gBACzB,GAAG;gBACH,YAAY;gBACZ,WAAW;gBACX,QAAQ;aACX,CAAC,CAAC;YACH,cAAc,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;YAC7B,iFAAiF;SACpF;QAED,IAAI,cAAc,CAAC,MAAM,GAAG,CAAC,EAAE;YAC3B,MAAM,QAAQ,GAAG,cAAc,CAAC,KAAK,CAAC,cAAc,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC;YAC7E,MAAM,MAAM,GAAG;gBACX,QAAQ;gBACR,kBAAkB,EAAE,cAAc,CAAC,KAAK,CAAC,CAAC,EAAE,cAAc,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC;aACjE,CAAC;YAC/B,IAAI,GAAG,EAAE;gBACL,IAAI,IAAI,GAAe,EAAE,CAAC;gBAC1B,cAAc,CAAC,OAAO,CAAC,GAAG,CAAC,EAAE,GAAG,IAAI,GAAG,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,IAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;gBAClE,MAAM,CAAC,IAAI,GAAG,IAAI,CAAC;aACtB;YACD,OAAO,MAAM,CAAC;SACjB;aAAM,IAAI,cAAc,CAAC,MAAM,KAAK,CAAC,EAAE;YACpC,uDAAuD;YACvD,OAAO,cAAc,CAAC,CAAC,CAAC,CAAC;SAC5B;aAAM;YACH,MAAM,IAAI,KAAK,CAAC,GAAG,EAAE,uBAAuB,CAAC,CAAC;SACjD;IACL,CAAC;CACJ"}

package/dist/V1/index.d.mts

@@ -0,0 +1,6 @@
+export * from './sha256v1.mjs';
+export * from './factory.mjs';
+export * from './types.mjs';
+export * from './constants.mjs';
+export * from './transforms/index.mjs';
+//# sourceMappingURL=index.d.mts.map

package/dist/V1/index.d.mts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.mts","sourceRoot":"","sources":["../../src/V1/index.mts"],"names":[],"mappings":"AAAA,cAAc,gBAAgB,CAAC;AAC/B,cAAc,eAAe,CAAC;AAC9B,cAAc,aAAa,CAAC;AAC5B,cAAc,iBAAiB,CAAC;AAChC,cAAc,wBAAwB,CAAC"}