# :under_construction: wip. ain't working atow...

i am working towards creating the fundamental es module package structure before
pulling out behavior from the ionic-gib project into this lib. so this is just a
shell right now.

# forward

I have created a working MVP for ibgib that shows some of the potential for the
architecture:

* try it out
  * https://ibgib.space
* pre-refactored MVP codebase on GitHub
  * `ionic-gib`: https://github.com/wraiford/ibgib/tree/v0.2.729/ionic-gib
  * "pre-refactored" = doesn't use this core-gib lib, but rather is the
    springboard/"carcass" for it.
* base ibgib protocol graphing substrate lib on GitLab
  * `ts-gib`: https://gitlab.com/ibgib/ts-gib/-/tree/master

# core-gib

`core-gib` is the intermediate ibgib substrate that provides functionality for basic ibgib interactions.

This includes plumbing for the following primary areas:

* witnesses
* spaces
* apps
* robbots

_note: many of these could technically be its own library, but at the very least for now these will stay within this core library until it seems they should be broken out._

This sits on top of the lowest level `ts-gib` library, which provides the very basic
primitives used in the mechanics of ibgib graphing.

## witnesses

An ibgib "witness" is the lowest level of ibgib in code that provides behavior
that is associated with its ibgib data. It is so called because it's meant to
convey to us that an ibgib is not some impartial, absolute function but rather
_always has a POV_. It is like if you take a function and abstract away
specifics of how it gets its information (be it on a stack, heap, at a local RAM
location address, etc.)

So in short, a witness is a distributed computation metaversal function, but
personified in order to remind each of us of anything's fallibility (including
computer functions).

### witness in code

With this in mind, let's look at the witness interface definitions in
TypeScript, with generic types and comments removed for clarity.

```typescript
export interface IbGib {
    ib: Ib;    // string
    gib?: Gib; // string
}

export interface IbGibWithDataAndRel8ns<...> extends IbGib {
    data?: TData;     // object/map of string->any
    rel8ns?: TRel8ns; // map of string->string[]
}

export interface Witness<...> extends IbGibWithDataAndRel8ns<...> {
    witness(arg: TIbGibIn): Promise<TIbGibOut | undefined>;
}
```

This last `Witness` interface has a single member: the `witness` function. This
accepts a single ibgib arg and returns a single ibgib arg. Since each ibgib is
content addressed (*1), this allows for a function addressing scheme that
effectively works in an infinite addressing space.

Considering this, the ibgib + witness design can be thought of as a superset of
all programming languages with `witness` ibgib acting similar to how we think of
functions. So inter-witness communications are at the extreme of functional
programming. Or said another way it can describe any programming language. But
when it comes to execution, adding the isomorphic transformation into the ibgib
description space would necessarily add overhead and most likely create
unfeasible execution times (until computation power vastly improves relative to
our current POV in time). Or in short, it would be NECESSARILY SLOWER, to the
point of local impracticality.

Still, it's important to think each witness as a universally addressed function,
and each space as a special case witness whose job is colocation.

[*1] primitives and other ibgibs without a gib hash, like "6^gib" or "hello^gib", are still "content addressed", it's simply the value is the address itself.

## spaces

So a "witness" is an ibgib with behavior, i.e. doesn't just have data. A "space"
is one kind of witness. Its primary job is to collocate ibgib.

_nuance: The implementation of "collocation" is not concrete and can be decided by - and vary wildly by - the implementing class._

### types of spaces

Ideally all spaces are to be considered equally, with the idea being that you
"simply" treat them as buckets of data. As such, we can think of them like a
bucket or a repo with just a couple capabilities: `get`, `put`, etc.

But when dealing with the process of living, temporal data dynamics, we must
consider one key aspect of data: **perspective**, i.e. POV. As such, there are
necessarily(?) three "types" of space with respect to POV:

1. local space
2. outer space
3. inner space

These are currently implemented in the ionic-gib MVP as follows:

1. local space
  * implemented with [`IonicSpace_V1`](https://github.com/wraiford/ibgib/blob/ed2d09c411dfdbc916e7841f1a0ccb6b559c303a/ionic-gib/src/app/common/witnesses/spaces/ionic-space-v1.ts)
  * uses [capacitor filesystem api (v4)](https://capacitorjs.com/docs/apis/filesystem)
    as indexeddb substrate
2. outer space
  * implemented with [`AWSDynamoSpace_V1`](https://github.com/wraiford/ibgib/blob/ed2d09c411dfdbc916e7841f1a0ccb6b559c303a/ionic-gib/src/app/common/witnesses/spaces/aws-dynamo-space-v1.ts#L854)
  * this is implemented as a "merge" space, in that when ibgibs are "put" into
    the space, timelines are dynamically merged using a CRDT-like merging
    algorithm that applies unapplied DNA transforms
  * uses DynamoDB for most ibgib data stored as four string fields ([max string size of 400 KB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html))
  * uses S3 for larger ibgibs with DynamoDB entries that indicate S3 storage
3. inner space
  * the [InnerSpace_V1](https://github.com/wraiford/ibgib/blob/ed2d09c411dfdbc916e7841f1a0ccb6b559c303a/ionic-gib/src/app/common/witnesses/spaces/inner-space-v1.ts) is not used or tested
  * it is only sketched
  * better composeability will be required for inner spaces to be utilized

## witnesses, and thus spaces, as universally addressed functions

If you think of a function in a programming language, it has a couple of characteristics:

* has an address
* has at least one parameter, which ultimately has an an address (either in the stack/heap or a pointer to memory)
* returns 0-1+ data structures


## spaces related to witnesses

## testing

### importmaps - `npm run test:browser` fails

as a workaround for bleeding edge ES module consumption (let alone testing
frameworks for them), I have kluged a workaround by editing
`/node_modules/jasmine-browser-runner/run.html.ejs` to include an import map
section. So atow paste the following code before any other `script` tags in the
`head` section.  (the versions may need to change):

_note: atow I am copy/pasting this text whenever I reinstall node_modules folder_

```html
  <script type="importmap">
    {
      "imports": {
        "ts-gib": "https://unpkg.com/ts-gib@0.4.8/dist/index.mjs",
        "ts-gib/": "https://unpkg.com/ts-gib@0.4.8/"
      }
    }
  </script>
```