querysub 0.355.0 → 0.356.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "querysub",
-  "version": "0.355.0",
+  "version": "0.356.0",
   "main": "index.js",
   "license": "MIT",
   "note1": "note on node-forge fork, see https://github.com/digitalbazaar/forge/issues/744 for details",

package/src/diagnostics/logs/diskLogger.ts

@@ -183,7 +183,7 @@ export function logDisk(type: "log" | "warn" | "info" | "error", ...args: unknow
             }
         }
 
-        // We don't want developer errors clogging up the error logs. However, they can still notify errors, Because this will only notify nodes that are able to access us (It uses a reverse connection scheme, so instead of talking to nodes that we can access, we only talk to nodes that can access us), Which will mean it will only notify for local services, so the developer still gets error notifications, But our errors won't be spread to all developers. BUT, we will still watch global errors, because we can contact the global server, so developers will still get errors about production issues, even while developing!  
+        // We don't want developer errors clogging up the error logs. However, they can still notify errors, Because this will only notify nodes that are able to access us (It uses a reverse connection scheme, so instead of talking to nodes that we can access, we only talk to nodes that can access us). So we get only OUR local errors. We will still watch all global errors, because we can contact the global server!
         if (isPublic()) {
             let loggers = startupDone ? getLoggers() : undefined;
             if (!loggers) {

package/src/diagnostics/logs/lifeCycleAnalysis/lifeCycles.tsx

@@ -0,0 +1,16 @@
+//todonext
+// Welp... no logs are showing up. That's a problem..
+// Ah, okay, we don't store logs locally. Because... we only log to backblaze? Alright, fair enough...
+/*
+0) LIFECYCLES!
+    - To debug auditting (to some degree)
+    - To debug why servers are getting sent values from the wrong authority
+        - This would be VERY interesting
+    - Rewrite the spec for how to do this
+        - One big thing is value association. As in, we want logs to be able to associate a session with a user. Even dynamically, so we might log somewhere saying this is the current user, and then we might log after that saying this is the session. And both of the logs might contain something saying this is the thread. And so we could say, okay, for the thread, the current user is this. And then when it says what the session is, we say, okay, well, the current user, which was defined earlier, has this session. 
+            - The biggest issue with this is caching, as now everything becomes one big bucket
+        - We want to be able to cache the parsing of the logs with the different lifecycle specifications. That way, we can view even just specific life cycles, and it can be very fast to load it, even if we have billions of logs, which take hours to parse. 
+        - I think we do want the lifecycle parsing to be run in the background. We already have a lot of background scripts (although we haven't been running them for a long time).
+            - Our log parsing is already pretty fast, which is good. So, then this will be even faster. 
+            - We will be need to be able to dynamically parse it though. And I guess we'll want to be able to parse it in the browser. And then that becomes a whole complicated thing to manage, but I think it's worth it. 
+*/

package/src/diagnostics/managementPages.tsx

@@ -126,7 +126,7 @@ export async function registerManagementPages2(config: {
         getModule: () => import("./misc-pages/SnapshotViewer"),
     });
     inputPages.push({
-        title: "Local Watches",
+        title: "View Synced Paths",
         componentName: "LocalWatchViewer",
         getModule: () => import("./misc-pages/LocalWatchViewer"),
     });