querysub 0.2.0

package/.dependency-cruiser.js

@@ -0,0 +1,304 @@
+/** @type {import('dependency-cruiser').IConfiguration} */
+module.exports = {
+  forbidden: [
+    /* rules from the 'recommended' preset: */
+    // {
+    //   name: 'circular',
+    //   severity: 'warn',
+    //   comment:
+    //     'This dependency is part of a circular relationship. You might want to revise ' +
+    //     'your solution (i.e. use dependency inversion, make sure the modules have a single responsibility) ',
+    //   from: {},
+    //   to: {
+    //     circular: true
+    //   }
+    // },
+    {
+      name: 'no-orphans',
+      comment:
+        "This is an orphan module - it's likely not used (anymore?). Either use it or " +
+        "remove it. If it's logical this module is an orphan (i.e. it's a config file), " +
+        "add an exception for it in your dependency-cruiser configuration. By default " +
+        "this rule does not scrutinize dot-files (e.g. .eslintrc.js), TypeScript declaration " +
+        "files (.d.ts), tsconfig.json and some of the babel and webpack configs.",
+      severity: 'warn',
+      from: {
+        orphan: true,
+        pathNot: [
+          '(^|/)\\.[^/]+\\.(js|cjs|mjs|ts|json)$', // dot files
+          '\\.d\\.ts$',                            // TypeScript declaration files
+          '(^|/)tsconfig\\.json$',                 // TypeScript config
+          '(^|/)(babel|webpack)\\.config\\.(js|cjs|mjs|ts|json)$' // other configs
+        ]
+      },
+      to: {},
+    },
+  ],
+  options: {
+
+    /* conditions specifying which files not to follow further when encountered:
+       - path: a regular expression to match
+       - dependencyTypes: see https://github.com/sverweij/dependency-cruiser/blob/master/doc/rules-reference.md#dependencytypes-and-dependencytypesnot
+       for a complete list
+    */
+    doNotFollow: {
+      path: 'node_modules'
+    },
+
+    /* conditions specifying which dependencies to exclude
+       - path: a regular expression to match
+       - dynamic: a boolean indicating whether to ignore dynamic (true) or static (false) dependencies.
+          leave out if you want to exclude neither (recommended!)
+    */
+    exclude: {
+      path: ["src/[^/]+.ts", "benchmarkTests", "tests", "benchmarks", "diagnostics", "Main"],
+      dynamic: true
+    },
+
+    /* pattern specifying which files to include (regular expression)
+       dependency-cruiser will skip everything not matching this pattern
+    */
+    // includeOnly : '',
+
+    /* dependency-cruiser will include modules matching against the focus
+       regular expression in its output, as well as their neighbours (direct
+       dependencies and dependents)
+    */
+    // focus : '',
+
+    /* list of module systems to cruise */
+    // moduleSystems: ['amd', 'cjs', 'es6', 'tsd'],
+
+    /* prefix for links in html and svg output (e.g. 'https://github.com/you/yourrepo/blob/develop/'
+       to open it on your online repo or `vscode://file/${process.cwd()}/` to 
+       open it in visual studio code),
+     */
+    // prefix: '',
+
+    /* false (the default): ignore dependencies that only exist before typescript-to-javascript compilation
+       true: also detect dependencies that only exist before typescript-to-javascript compilation
+       "specify": for each dependency identify whether it only exists before compilation or also after
+     */
+    tsPreCompilationDeps: true,
+
+    /* 
+       list of extensions to scan that aren't javascript or compile-to-javascript. 
+       Empty by default. Only put extensions in here that you want to take into
+       account that are _not_ parsable. 
+    */
+    // extraExtensionsToScan: [".json", ".jpg", ".png", ".svg", ".webp"],
+
+    /* if true combines the package.jsons found from the module up to the base
+       folder the cruise is initiated from. Useful for how (some) mono-repos
+       manage dependencies & dependency definitions.
+     */
+    // combinedDependencies: false,
+
+    /* if true leave symlinks untouched, otherwise use the realpath */
+    // preserveSymlinks: false,
+
+    /* TypeScript project file ('tsconfig.json') to use for
+       (1) compilation and
+       (2) resolution (e.g. with the paths property)
+
+       The (optional) fileName attribute specifies which file to take (relative to
+       dependency-cruiser's current working directory). When not provided
+       defaults to './tsconfig.json'.
+     */
+    tsConfig: {
+      fileName: 'tsconfig.json'
+    },
+
+    /* Webpack configuration to use to get resolve options from.
+
+       The (optional) fileName attribute specifies which file to take (relative
+       to dependency-cruiser's current working directory. When not provided defaults
+       to './webpack.conf.js'.
+
+       The (optional) `env` and `args` attributes contain the parameters to be passed if
+       your webpack config is a function and takes them (see webpack documentation
+       for details)
+     */
+    // webpackConfig: {
+    //  fileName: './webpack.config.js',
+    //  env: {},
+    //  args: {},
+    // },
+
+    /* Babel config ('.babelrc', '.babelrc.json', '.babelrc.json5', ...) to use
+      for compilation (and whatever other naughty things babel plugins do to
+      source code). This feature is well tested and usable, but might change
+      behavior a bit over time (e.g. more precise results for used module 
+      systems) without dependency-cruiser getting a major version bump.
+     */
+    // babelConfig: {
+    //   fileName: './.babelrc'
+    // },
+
+    /* List of strings you have in use in addition to cjs/ es6 requires
+       & imports to declare module dependencies. Use this e.g. if you've
+       re-declared require, use a require-wrapper or use window.require as
+       a hack.
+    */
+    // exoticRequireStrings: [],
+    /* options to pass on to enhanced-resolve, the package dependency-cruiser
+       uses to resolve module references to disk. You can set most of these
+       options in a webpack.conf.js - this section is here for those
+       projects that don't have a separate webpack config file.
+
+       Note: settings in webpack.conf.js override the ones specified here.
+     */
+    enhancedResolveOptions: {
+      /* List of strings to consider as 'exports' fields in package.json. Use
+         ['exports'] when you use packages that use such a field and your environment
+         supports it (e.g. node ^12.19 || >=14.7 or recent versions of webpack).
+
+         If you have an `exportsFields` attribute in your webpack config, that one
+         will have precedence over the one specified here.
+      */
+      exportsFields: ["exports"],
+      /* List of conditions to check for in the exports field. e.g. use ['imports']
+         if you're only interested in exposed es6 modules, ['require'] for commonjs,
+         or all conditions at once `(['import', 'require', 'node', 'default']`)
+         if anything goes for you. Only works when the 'exportsFields' array is
+         non-empty.
+
+        If you have a 'conditionNames' attribute in your webpack config, that one will
+        have precedence over the one specified here.
+      */
+      conditionNames: ["import", "require", "node", "default"],
+      /*
+         The extensions, by default are the same as the ones dependency-cruiser
+         can access (run `npx depcruise --info` to see which ones that are in
+         _your_ environment. If that list is larger than what you need (e.g. 
+         it contains .js, .jsx, .ts, .tsx, .cts, .mts - but you don't use 
+         TypeScript you can pass just the extensions you actually use (e.g. 
+         [".js", ".jsx"]). This can speed up the most expensive step in 
+         dependency cruising (module resolution) quite a bit.
+       */
+      // extensions: [".js", ".jsx", ".ts", ".tsx", ".d.ts"],
+      /* 
+         If your TypeScript project makes use of types specified in 'types'
+         fields in package.jsons of external dependencies, specify "types"
+         in addition to "main" in here, so enhanced-resolve (the resolver
+         dependency-cruiser uses) knows to also look there. You can also do
+         this if you're not sure, but still use TypeScript. In a future version
+         of dependency-cruiser this will likely become the default.
+       */
+      mainFields: ["main", "types"],
+    },
+    reporterOptions: {
+      dot: {
+        /* pattern of modules that can be consolidated in the detailed
+           graphical dependency graph. The default pattern in this configuration
+           collapses everything in node_modules to one folder deep so you see
+           the external modules, but not the innards your app depends upon.
+         */
+        collapsePattern: 'node_modules/(@[^/]+/[^/]+|[^/]+)',
+
+        /* Options to tweak the appearance of your graph.See
+           https://github.com/sverweij/dependency-cruiser/blob/master/doc/options-reference.md#reporteroptions
+           for details and some examples. If you don't specify a theme
+           don't worry - dependency-cruiser will fall back to the default one.
+        */
+        theme: {
+          graph: {
+            /* use splines: "ortho" for straight lines. Be aware though
+              graphviz might take a long time calculating ortho(gonal)
+              routings.
+           */
+            splines: "splines"
+            //splines: "ortho"
+          },
+          modules: [
+            {
+              criteria: { matchesFocus: true },
+              attributes: {
+                fillcolor: "lime",
+                penwidth: 2,
+              },
+            },
+            {
+              criteria: { matchesFocus: false },
+              attributes: {
+                fillcolor: "lightgrey",
+              },
+            },
+            {
+              criteria: { matchesReaches: true },
+              attributes: {
+                fillcolor: "lime",
+                penwidth: 2,
+              },
+            },
+            {
+              criteria: { matchesReaches: false },
+              attributes: {
+                fillcolor: "lightgrey",
+              },
+            },
+          ],
+          dependencies: [
+            {
+              criteria: { "rules[0].severity": "error" },
+              attributes: { fontcolor: "red", color: "red" }
+            },
+            {
+              criteria: { "rules[0].severity": "warn" },
+              attributes: { fontcolor: "orange", color: "orange" }
+            },
+            {
+              criteria: { "rules[0].severity": "info" },
+              attributes: { fontcolor: "blue", color: "blue" }
+            },
+            {
+              criteria: { resolved: "4-querysub" },
+              attributes: { color: "#0000ff77" }
+            },
+            {
+              criteria: { resolved: "3-path-functions" },
+              attributes: { color: "#00770077" }
+            },
+            {
+              criteria: { resolved: "2-proxy" },
+              attributes: { color: "#77007777" }
+            },
+            {
+              criteria: { resolved: "1-path-client" },
+              attributes: { color: "#77000077" }
+            },
+            {
+              criteria: { resolved: "a-auth" },
+              attributes: { color: "#77770077" }
+            },
+            {
+              criteria: { resolved: "b-tree-core" },
+              attributes: { color: "#00777777" }
+            },
+          ]
+        }
+      },
+      archi: {
+        /* pattern of modules that can be consolidated in the high level
+          graphical dependency graph. If you use the high level graphical
+          dependency graph reporter (`archi`) you probably want to tweak
+          this collapsePattern to your situation.
+        */
+        collapsePattern: '^(packages|src|lib|app|bin|test(s?)|spec(s?))/[^/]+|node_modules/(@[^/]+/[^/]+|[^/]+)',
+
+        /* Options to tweak the appearance of your graph.See
+           https://github.com/sverweij/dependency-cruiser/blob/master/doc/options-reference.md#reporteroptions
+           for details and some examples. If you don't specify a theme
+           for 'archi' dependency-cruiser will use the one specified in the
+           dot section (see above), if any, and otherwise use the default one.
+         */
+        // theme: {
+        // },
+      },
+      "text": {
+        "highlightFocused": true
+      },
+    }
+  }
+};
+// generated: dependency-cruiser@12.11.0 on 2023-03-20T01:54:07.550Z

package/.eslintrc.js

@@ -0,0 +1,51 @@
+module.exports = {
+    "root": true,
+    "env": {
+        "browser": true,
+        "es6": true,
+        "node": true
+    },
+    "extends": [],
+    "globals": {
+        "Atomics": "readonly",
+        "SharedArrayBuffer": "readonly"
+    },
+    "overrides": [
+        {
+            "files": [
+                "**/*.ts",
+                "**/*.tsx"
+            ]
+        }
+    ],
+    "parser": "@typescript-eslint/parser",
+    "parserOptions": {
+        "ecmaVersion": 2018,
+        "sourceType": "module",
+        "project": "./tsconfig.json",
+        "tsconfigRootDir": __dirname,
+    },
+    "plugins": [
+        "@typescript-eslint"
+    ],
+    "rules": {
+        "@typescript-eslint/unbound-method": [
+            "error",
+            {
+                "ignoreStatic": true
+            }
+        ],
+        "@typescript-eslint/no-floating-promises": [
+            "error"
+        ],
+        "quotes": [
+            "error",
+            "double",
+            {
+                "allowTemplateLiterals": true
+            }
+        ],
+        "eqeqeq": "error",
+        "semi": "error"
+    }
+};

package/.github/copilot-instructions.md

@@ -0,0 +1 @@
+For error messages, always use templates strings and include variables which explain specifically what the error is.

package/.vscode/settings.json

@@ -0,0 +1,25 @@
+{
+    // "debug.node.autoAttach": "on",
+    "files.watcherExclude": {
+        "**/.git/objects/**": true,
+        "**/.git/subtree-cache/**": true,
+        "**/node_modules/*/**": true,
+        "**/.hg/store/**": true
+    },
+    "[typescript]": {
+        "editor.formatOnSave": true,
+    },
+    "[typescriptreact]": {
+        "editor.formatOnSave": true,
+    },
+    "[javascript]": {
+        "editor.formatOnSave": true,
+    },
+    "typescript.tsdk": "node_modules/typescript/lib",
+    "search.exclude": {
+        "**/node_modules": true,
+        "**/bower_components": true,
+        "**/*.code-search": true,
+        "**.cache": true
+    }
+}

package/bin/deploy.js

@@ -0,0 +1,4 @@
+#!/usr/bin/env node
+
+require("typenode");
+require("../src/3-path-functions/deployMain");

package/bin/function.js

@@ -0,0 +1,4 @@
+#!/usr/bin/env node
+
+require("typenode");
+require("../src/3-path-functions/PathFunctionRunnerMain");

package/bin/server.js

@@ -0,0 +1,4 @@
+#!/usr/bin/env node
+
+require("typenode");
+require("../src/server.ts");

package/costsBenefits.txt

@@ -0,0 +1,112 @@
+Concepts
+    Naming
+        PathValue is the database
+        FunctionRunner is a tool which makes remote function calling easy
+        Querysub is the interface which untrusted parts of apps use to sync data and commit calls
+            - Quadratic sieve: `The quadratic sieve algorithm (QS) is an integer factorization algorithm and, in practice, the second fastest method known (after the general number field sieve). It is still the fastest for integers under 100 decimal digits or so, and is considerably simpler than the number field sieve`
+            - Quorum sensing: `In biology, quorum sensing or quorum signalling (QS)[1] is the ability to detect and respond to cell population density by gene regulation.`
+            - Query subscriptions (https://www.apollographql.com/docs/react/data/subscriptions/): In graphQL you have to choose between them, with Querysub you get both. `Like queries, subscriptions enable you to fetch data. Unlike queries, subscriptions are long-lasting operations that can change their result over time. They can maintain an active connection to your GraphQL server (most commonly via WebSocket), enabling the server to push updates to the subscription's result.` and the BS justification for why graphQL doesn't support automatic subscriptions: `In the majority of cases, your client should not use subscriptions to stay up to date with your backend. Instead, you should poll intermittently with queries, or re-execute queries on demand when a user performs a relevant action (such as clicking a button).`, which is true, but automatic subscriptions should still be easy to enable with 100% accuracy, instead of being hacked kludge to fill the massive missing piece of graphQL.
+
+    NOTE: The whole idea is "fix later" locks, where we invalidate writes later on, if we realized our lock wasn't ACID.
+
+    NOTE: We don't need to hang onto lock chains forever, because we require servers to keep their data fresh by constantly receiving the latest values. This means if a piece of data is old enough, we know it can be relied upon, because no one can go back in time far enough to remove it.
+        - We still need locks, because have changed relatively recently, but... we don't need to follow it's locks back, or even remember that it is supposed to be valid!
+
+    NOTE: Functions don't exist explicitly, but due to identical readLocks you can tell what happened from the same function. This also ensures writes are atomic, as if they have the same readLocks, either they are all accepted, or all rejected.
+
+    NOTE: We don't actually lock things such as Object.keys(). In practice we will get pretty close, but our handling of it is simply not fully ACID.
+
+    NOTE: In regards to FunctionRunners. FunctionRunner rerun any calls which seem to not be run. The first one to run will get the value, with the others having their ReadLock on the result (from epoch to their LATER writeTime) invalidated.
+        - Although, in practice, the writeTimes will be close, as they are based on requested writeTimes, made unique by creatorId. So... if two FunctionRunners run the same call, one will consistently create the accepted value. So... just don't have two FunctionRunners run the same call!
+
+    NOTE: "Bad" predictions are possibly by if you know the path some change will write to (ie, the call result path). You can create a prediction that depends on that path being undefined (in some range that includes the eventual remote change, but not the prediction), simply watch that path, and when the change eventually happens your prediction will automatically be invalidated.
+        - This is not suitable for trusted nodes, as it means all of our dependent values on that prediction will be only acceptable to us (as our prediction won't really be able to be propagated, as the change might never happen, in which case our prediction has to go away, which is impossible to do if we propagate it), but... it is very useful for clients to quickly predict writes (trusted nodes can just write actual values, not trying to get some remote to make a change).
+        - AND, if you only depend on that path there is no jitter as you reject old values, as there is no cascading! This DOES allow values to drift out of sync with the server (if they are CONSTANTLY written to), but... that is another problem, for games, and just one of many issues games have to overcome.
+
+
+Summary of benefits/costs
+
+    Benefits
+        1) Decreased code size / decreased development time / decreased complexity
+            - Adding a new value doesn't require new endpoints
+            - Even for a non-syncing application the code size is about as small as it can get
+        2) Minimum possible clientside delay (so everything feels fast)
+            - If you just explicitly input predict values, and then clobber the predicted value when the call comes back, you run into a case where multiple predictions get clobber by an old callback. Which is bad.
+            - If you explicitly input predict values, and only clobber the latest, that works... until you have reasonably complex data.
+            - Explicit endpoints per data path is a non-starter, because when your user interfaces migrates it won't overlap, and then you will have to explicitly calling multiple endpoints after a mutate call, and it will become your entire job.
+            - The only way to do input prediction at a framework level is to track all accesses, and have a serverside which exposes path bases values, AND to have the same mutate functions clientside as you use serverside (otherwise you have to rewrite all mutate functions twice).
+                - AND THEN... if other users mutate data, you NEED the server to tell you when it changes. If you don't, 
+                - In theory you can download data every time you need it... but this can't scale to reasonably large applications. AND, if you don't the user won't just see stale data, they will predict stale data, which will be really bad. So... the server needs to synchronize the paths as well
+        3) Excellent sharding / scaling via very lax sharding
+            - PathValue.locks are a simple locking mechanism, and very efficient (less efficient with high contention)
+            - Transactions can easily be done cross shard, and are still fully ACID, which most other databases have a hard time doing (unless they use virtually the same locking scheme)
+
+    Database flowchart
+        (NOTE: Large static assets should always be stored in some object storage database, like S3, even if you are using another system for other data.)
+        (NOTE: If you want an ultra responsive UI you can often use a write-then-reader wrapper for your database (which might require extra work to specify what should update, and what should be read). Or... just use query-sub)
+
+        - Do you want a very responsive user interface (via input prediction)
+            = Yes
+                - Is it easy to specify exactly what the writes are (with high accuracy) for most server write operations
+                    (As in, are you using complex writes that involve functions with many lines of code, or is pretty much just KVP writes.)
+                    = Yes
+                        - Will the user often experience write contention
+                            = YES
+                                - query-sub
+                            = NO
+                                - query-sub
+                                - OR Run again without a very responsive user interface, and then slap a write-then-reread wrapper onto your database, and then tell it what values it should predict.
+                    = No
+                        - query-sub
+            = NO
+                - Is % chance contention * impact of contention low (contention free)?
+                = Yes
+                    Is the data static enough where stale data can be shown? (ex, search results, non-user part of youtube, twitter?)
+                    = Yes
+                        - Any NoSQL implementation (S3 for large data, MongoDB for complex data, otherwise BigTable, or even ElasticSearch?)
+                    = No
+                        - Do you want clientside data syncing
+                        = Yes
+                            - firebase
+                        = No
+                            - A fast writing NoSQL implementation (probably MongoDB)
+                = No
+                    - Do you want clientside data syncing
+                    = Yes
+                        - firebase + firebase cloud functions
+                    = No
+                        - Are writes simple and only affect a single collection
+                        = Yes
+                            - MongoDB
+                        = No
+                            - MongoDB / SQL (likely with high transaction isolation levels)
+
+        Conclusion
+            - Realistically, you want a responsive user interface (who wouldn't?)
+
+    NOTE: For applications with very static data (so not just mostly reads, but the data actually changes so infrequently that users can be shown stale data and they won't even notice), using MongoDB is just as good (unless you need really complex transactions).
+        - You will still run into issues at huge scales with other databases though, as eventually the amount of transactions you want will exceed what one server can handle, and then you need to shard, and if you don't or can't shard well, everything will get slow.
+
+    Timestamped writes / clientside reproducible writes
+        BENEFIT: Allows clients to compare against incoming writes and know if they write is newer, or older, allowing predictions to never get out of sync.
+            ALTERNATIVE: Reading state after each write also allows this. HOWEVER, if the write is a function mutation, the impetus for the write might be small, but the data mutated could be large. For example, a paint application, where a write mutates the canvas, which is large, so we don't want to download the entire canvas after each write.
+                - AND, even if the values are small, this requires increased network usage
+        COST: Is slower. Is only useful with with KVP writes (if you can't map from clientside write to read paths this can't be used to predict values).
+        ADDITIONAL BENEFITS: Makes debugging easier, via keeping track of a history of operations
+    
+    Watching/syncing
+        BENEFIT: Greatly reduces read count needed to keep data up to date
+        COST: Writes have more overhead, requiring everything to be notified
+
+    Lock tracking / valid tracking / contention invalidation / eventually consistent transactions
+        BENEFIT: ACID safety that is fast even with large collections.
+            - Also allows ACID safety even for servers that are off the main network, allowing anyone to add transactions without worrying about inserting an inconsistent write (worst case the write will be rejected).
+            - Also, ACID safety is a lot easier to implement with this technique
+            ALTERNATIVE: Use a single server, or a single server per collection and don't provide ACID cross collection.
+            ALTERNATIVE: Collection locking, which if you have enough servers using the same collection degenerates to single server performance.
+            ALTERNATIVE: Smart evenly sub-collection sharding. This can be very efficient, HOWEVER, it is extremely difficult to anticipate the access patterns. Accurately predicting all access patterns would be akin to a universal storage system that can run any search query in optimal time (either O(1), or O(logN)).
+            ALTERNATIVE: No ACID safety. This is pretty much only viable if the write interface is purely KVP based. Otherwise it is easy to create functions which depend on ACID safety, and give unpredictable results when it is not kept (ex, contention causes really bad breaking of things). This makes it impossible to implement things such as financial transactions, most games, etc.
+                - And, of course, we can have lock tracking support, but just commit writes with no readLocks, which will produce much faster writes, making the database based degenerate to a NoSQL database, with theoretically the same speed.
+        COST: Slower to compute writes, and writes become MUCH larger.
+            - Lock/eventually consistency transactions ONLY work if the client readers are syncing. If they aren't, they will get the wrong data and KEEP the wrong data, which would break pretty much any application.
+        ADDITIONAL BENEFITS: Makes debugging easier, via making it possible to trace the read source used to generate any write (so to track data through the system).

package/deploy.ts

@@ -0,0 +1,3 @@
+import "./src/diagnostics/satSchema";
+import "./src/test/test";
+import "./src/4-dom/qreactTest";

package/inject.ts

@@ -0,0 +1 @@
+import "./src/inject";

package/package.json

@@ -0,0 +1,60 @@
+{
+    "name": "querysub",
+    "version": "0.2.0",
+    "main": "index.js",
+    "license": "MIT",
+    "note1": "note on node-forge fork, see https://github.com/digitalbazaar/forge/issues/744 for details",
+    "repository": {
+        "type": "git",
+        "url": "https://github.com/sliftist/shard.git"
+    },
+    "dependencies": {
+        "@sendgrid/mail": "^7.7.0",
+        "@types/fs-ext": "^2.0.3",
+        "@types/node-forge": "^1.3.1",
+        "@types/pako": "^2.0.3",
+        "@types/yargs": "^15.0.5",
+        "acme-client": "^5.0.0",
+        "cbor-x": "^1.5.6",
+        "chalk": "^5.2.0",
+        "diskusage": "^1.2.0",
+        "fs-ext": "^2.0.0",
+        "js-sha256": "https://github.com/sliftist/js-sha256",
+        "js-sha512": "^0.9.0",
+        "node-forge": "https://github.com/sliftist/forge#e618181b469b07bdc70b968b0391beb8ef5fecd6",
+        "pako": "^2.1.0",
+        "preact": "^10.11.3",
+        "socket-function": "^0.31.0",
+        "terser": "^5.31.0",
+        "typesafecss": "^0.6.3",
+        "yaml": "^2.5.0",
+        "yargs": "^15.3.1"
+    },
+    "optionalDependencies": {
+        "rdtsc-now": "^0.4.2"
+    },
+    "scripts": {
+        "server": "yarn typenode ./src/server.ts",
+        "serversharded": "yarn server --authority ./pathremain.json & yarn server --authority ./patha.json & yarn server --authority ./pathb.json & yarn server --authority ./pathc.json & yarn server --authority ./pathd.json",
+        "function": "yarn typenode ./src/3-path-functions/PathFunctionRunnerMain.ts --function --local D:/repos/shard/",
+        "deploy": "yarn typenode ./src/3-path-functions/deployMain.ts --domain querysub.com --local D:/repos/shard/",
+        "type": "yarn tsc --noEmit",
+        "depend": "yarn --silent depcruise src --include-only \"^src\" --config --output-type dot | dot -T svg > dependency-graph.svg",
+        "dbmerge": "yarn typenode ./src/dbmerge.ts",
+        "test": "yarn typenode ./src/test/test.tsx --local D:/repos/shard/",
+        "test2": "yarn typenode ./src/4-dom/qreactTest.tsx --local D:/repos/shard/"
+    },
+    "bin": {
+        "shard-deploy": "./bin/deploy.js",
+        "shard-server": "./bin/server.js",
+        "shard-function": "./bin/function.js"
+    },
+    "devDependencies": {
+        "dependency-cruiser": "^12.11.0",
+        "open": "^8.4.0",
+        "typedev": "^0.3.0"
+    },
+    "resolutions": {
+        "node-forge": "https://github.com/sliftist/forge#e618181b469b07bdc70b968b0391beb8ef5fecd6"
+    }
+}

package/prompts.txt

@@ -0,0 +1,54 @@
+/*
+Style
+    Steampunk City, night scene, street level, Dark Muted Colors, Shadows
+    Cinematic lighting
+    realistic
+    photo realism
+    ultra detailed
+    film grain
+    octane render
+    dark colored photo
+    photo by Justin James Muir, Peter Lindbergh
+    Peaker blinders
+    LA Noire
+    1920s
+    1930s
+
+    lights from blinds
+    painting
+    dim volumetric lighting
+    a detailed matte painting
+    new objectivity
+
+    <kitchen|bathroom|entertainment room|cellar>
+
+    <bedroom|living room|kitchen|bathroom|hallway|closet|basement|dining room|studio|hallway|balcony|elevator|study|utility room|basement|garage|cellar|apartment hallway>
+    <table|chairs|couch|bed|stool|cabinet|sofa|television|plants>
+
+    Angles
+        - https://youtu.be/ko3GKu4POXE?t=8
+        high angle shot, drone shot, birds eye view, low angle shot, close up shot, wide shot, medium shot, long shot, extreme close
+        fisheye lens, establishing shot, wide angle lens, wide field of view,
+        low angle shot, looking up
+        mid shot, fullbody shot, standing
+        macro photography, close up, extreme close up, shallow depth of field
+
+    Lighting
+        shadows
+            - Really sharpens everything, making it seem ultra modern (and often black and white)
+        soft shadows
+            - shadows, but softer
+        misty
+            - Pretty good way to add mood
+        foggy
+            - Seems to also add graffiti?
+
+    Negative prompts for people
+        - bad anatomy, bad proportions, blurry, cloned face, cropped, deformed, dehydrated, disfigured, duplicate, error, extra arms, extra fingers, extra legs, extra limbs, fused fingers, gross proportions, jpeg artifacts, long neck, low quality, lowres, malformed limbs, missing arms, missing legs, morbid, mutated hands, mutation, mutilated, out of frame, poorly drawn face, poorly drawn hands, signature, text, too many fingers, ugly, username, watermark, worst quality
+        - bad anatomy, bad proportions, blurry, cloned face, cropped, deformed, disfigured, duplicate, extra arms, extra fingers, extra legs, extra limbs, fused fingers, gross proportions, long neck, low quality, malformed limbs, missing arms, missing legs, mutated hands, poorly drawn face, poorly drawn hands, too many fingers, ugly
+
+    Emotions
+        {optimistic|pained|tired|worried|happy|disgust|confused|joyful|lonely|proud|nervous|embarrassed|amused|serious|laughing|sneering|smiling with teeth|}
+
+        
+*/