@ibgib/core-gib 0.1.13 → 0.1.15

package/tmp.md

@@ -1,11 +1,129 @@
-OK, ty. The space-wide sync approach is not tenable. That is like trying to sync Alice's entire logical drive with Bob's entire logical drive instead of a particular folder on the drive. Your thinking that a single Domain IbGib does not contain many timelines is faulty. A dependency graph of a "single" domain may contain multiple, or even many/a great many, timelines. Think of this like in set theory and we are creating an isomorphic projection of nodes. I say isomorphic and not homomorphic, because we may have to do merges for timelines, so it really is a "one-way" projection. Though obviously, with "sync" being bi-directional, we are ultimately converging on both endpoints having "equivalent" timelines (there may be orphans on one and/or the other after merges, with either endpoint effectively doing a "rebase"). So our sync process has to start with getting a "live" dependency graph of a single domain ibgib. We can actually do multiple domain ibgibs, and then unify the entire dependency graph in the sync transmission ibgib, but I think it's best to just build for the single ibgib scenario. You can look at@beautifulMention, but I would really recommend looking at the entire @beautifulMentionfile. This is a non-trivial recursive function, but you should be able to fully grok it by looking at both the jsdocs/comments in that file and the code itself. Always look at the code itself of course!
+OK great! We're making progress for sure. Here are some issues and questions that I've come across. 
 
-That dependency graph comes in the form a @beautifulMention as defined by this:
+---
+
+around line 154
+
+```
+// 5. MERGE RESULT (Optimistic Commit)
+                // we need to refactor this to a `finalizeSaga` method that...
+                //  * moves all ibgibs stored in temp space to target space in
+                //    one go (commit phase 1)
+                //  * registers each timeline AFTER commit space via
+                //    metaspace.registerNewIbGib (commit phase 2)
+                //    * need to add a skipBroadcast flag so we can register
+                //      without broadcasting until the very tip of each timeline
+                //  * deletes the temp space
+```
+
+I want to keep this in because we will need to do the `registerNewIbGib`
+somewhere when we do the commit transaction process.
+
+---
+
+around line 283:
+
+```
+            if (!remoteFrameAddr) {
+                // warnings are mostly to be avoided. i use warnings primarily for temporary code reminders to remember to do something before prod.
+                // console.warn(`${lc} Peer response has no sagaFrame. Ending loop.`);
+                // currentFrame = null;
+                // break;
+
+                // question: are we prepared to error out the saga when an exception arrives?
+                throw new Error(`Peer response has no sagaFrame. Ending loop. (E: 0224e84a83e1c7ee288aaed6bdc40826)`);
+```
+
+---
+
+around line 421:
+
+Why does "Commit" run on either sender/receiver?
+
+---
+
+around line 512:
+
+Added todo to change to use `getLatestAddrs({tjpAddrs: remoteTjps})`
+
+---
+
+around line 626:
+
+I reverted to my corrected, more explicit separate error conditional checks.
+
+---
+
+around line 639:
+
+readded todo:
+
+// todo: change this to batch getFromSpace. Also, do not get addrs that are primitive.
+
+---
+
+in sync-saga-context-helpers.mts, shouldn't sagaFrame be required in createSyncSagaContext?
+This would change the CreateSyncSagaContextOptions also, and would throw if this was falsy.
+
+---
+
+In just sync-saga-coordinator.mts alone, there are 68 uses of the word "payload"
+(case-insensitive).
+
+But the term `payload` is defined in multiple places differently. In some
+places, this is defined as `IbGib_V1[]`, others it is `any`, and still others
+it is `string[]`.  
+
+For example, in CreateSyncSagaContextOptions, this is defined as:
 
 ```
 /**
- * Map of addr -> ibGib
+ * Payload addresses (strings) for bulk data.
  */
-export type FlatIbGibGraph = { [addr: string]: IbGib_V1 };
+payload?: string[];
 ```
 
+But `getStageAndPayloadFromFrame` has in its return type `payload: any`.
+
+And in `executeSagaLoop`: `let nextPayload: IbGib_V1[] = [];`
+
+This is being used in different contexts and is causing confusion
+as to how it is being used. We need to create different, explicitly named
+variable and property names that are specific to the immediate use case. And we
+should have zero `any` types being used, except in extremely rare difficult
+compilation contexts (like when we have to cast to any before casting to some
+other type). The only reason I allow `any` at all is mainly for backwards compat
+(would be too much work to do the whole codebase).
+
+In my prototype, I also came across a similar problem. My solution was to always
+be explicit with [x]IbGib's vs. [x]Addrs. Sometimes it seemed like overkill, but
+it was a way to reduce difficulty in reading and following code.
+
+So, we need to change these to `payloadIbGibs` and `payloadAddrs` in ALL
+locations, so we can be explicit.
+
+---
+
+analyzeTimelines returns this:
+
+```
+{
+    srcStones: IbGib_V1[],
+    srcTimelinesMap: { [tjp: string]: IbGib_V1[] },
+    srcSortedTjps: string[],
+    srcGraph: { [addr: string]: IbGib_V1 },
+}
+```
+
+But the calling code is
+
+```
+const { srcTimelinesMap, srcGraph } = await this.analyzeTimelines({ domainIbGibs, space: localSpace });
+```
+
+Where are we synchronizing the src stones? I understand when we create our initial knowledgeVector, we usually want just our timelines. But we still need to synchronize stones as well. What if one of our `domainIbGibs` is itself a stone? All of the dna for the timelines will be in srcStones. I could just be missing something of your algorithm, but to me, we need to include the stone addrs in the knowledge vector. Perhaps we can skip the dna for the timelines initially, but ultimately we will need to send those as well. 
+
+
+---
+
+So that is just some of the issues. I haven't gone through the entire file yet. Please let's talk about these, and do NOT make any changes to the file. We are in full discussion mode right now!!