service: sw: src: change: notify: Service to facilitate poly repo pull model dev tooling

[johnandersen777]

• dataflow configurable sending and receiving
• git hooks

Related:

• docs: arch: 2nd and 3rd party plugins #1061 (comment)
• https://intel.github.io/dffml/main/examples/webhook/index.html
• https://bovine.readthedocs.io/en/latest/tutorial_server.html
  • activitypub-webhook-relay
• https://github.com/LemmyNet/lemmy/blob/main/docker/Dockerfile
  • https://join-lemmy.org/docs/administration/configuration.html
  • https://join-lemmy.org/docs/contributors/04-api.html#curl-examples
    • https://github.com/LemmyNet/lemmy-js-client/blob/main/src/types/CreatePost.ts

[johnandersen777]

ability to publish commit history across projects with email lists or chat notifcations to send on a per repo (or custom function) basis.

The goal here is that you're able to figure out what people are working on more quickly and collaborate on problems faster. Breaks down silos caused by pre-pr work. If everyones changes show up as code somewhere. You can quickly understand who is working on what at all times in your org. This allows you to map pre-pr dev branches in docs, infra as code (or gitops), code, etc. anything you have an API for you put it as code. Now all the sudden you have complete visibility into what everyone in your org is working on every time they save their work. This could be extended to provide daemon functionality which watches the filesystem in a repo (fanotify, inotify, nodemon, etc.) and sends out diffs for dirty repos (http://git-scm.com/docs/gitglossary#def_dirty). You can then map branches to OKRs. You can also map them to ANYTHING, via DID's and personal datastores. We then implement DID and personal datastore support as df.*Network objects. Then your code can dynamically just add whatever it wants where ever it wants and a dataflow anywhere else can pick it up (propagates through the blockchain). So you map the branches to the OKRs, issues (requirements, bugs, etc.), etc. Map OKRs and requirements then follow the links in the chain to see who is working on what objectives. Then follow the chain of DIDs to see if anyone is working on the same thing technically. Do this by comparing feature sets of projects as identified by metric collection (similar dependencies, similar API calls, walks like http server, quacks like http server, probably is http server, usage of aiohttp, http.server, common libs for language, check if in depenendnency tree, then move to source analysis). This model is useful for human developers working on projects but will also be useful when we start to get into the cross between automl auto feature engineering used here to come up with modificaitions to dataflows in order to create a distributed system for attempting to build new programs or refactor or patch security vulns (understanding of threat model via architecture of entrie solution as dataflow required to understand context around usage, intent). Need to rememeber to add the ability for any part of a dataflow run to output metrics which can be used to train a model to optimize for any high level goal as defined by the direction to automl that we'd like to move this metric this way. That metric can be as abitrary as "security" via model stacking, development time is then equivilant to time consumed on the distributed compute, or developer hours, whoever is faster. There are several important metrics in our final system.

• speed of thought: running average time to correctly find a valid new dataflow representing a program execution
• speed of trial: running average time to check if a dataflow we thought of can run without triggering any failure conditions
  • Will probably need to think more about failure conditions. Initial set of things that could be checked and used to determine if a faliure occurred. Anything that makes up the system context (system state, ping: docs: dataflows: Improve docs #1279 (comment))
    • All metrics which can be reported during the running of a flow
    • All outputs
    • All inputs
    • Config
    • Output of a model trained on all of the above data
    • Generic dataflow to determine failure of other dataflow.
      • Maybe we should extend this to dataflows themselves, allow a flow similar to seed to set a dataflow which runs as a subflow (so within the same input network context)
• speed of error: running average number of failed runs as a percentage of total runs. Lower numbers here mean we are thinking in the right direction.
• usefulness of thoughts: Are our thoughts generating dataflows which are improving our metrics in the right directions to meet our overall goal, our example from earlier was increase "security".
  • Need to find a way to measure how much closer we are getting to our end goal, which appropriately reflects when a conceptual leap has been made (we made a lot of progress towards our goal, last set of values we were trying to move was at X now were at 10X, or X^10, is logarithmic scale important here?)
• chaos: diversity of authorship applied to clustering model run on all thoughts (dataflows) where each dataflow maps to line changed and the cluster classification is the author.
• rate of epiphany: Eureka moments within a set of trains of thought. Some kind of moving average of state of the art movement towards strategic principles over time?
• happiness: Context local measurement determined by each entity/agent

Probably want to make the collection of these metrics done by flows. Look into doing this by just running a dataflow at any point within the execution of the dataflow to hit output stage operations, theres a method for this. We can then just trigger the metric collection flow periodically, maybe via running in a subflow with same contexts triggered by the running of an operation within the parent flow, or just triggered by caller whenever if running with #919 async for style.

• Org repo modified -> email org members working on those projects

[johnandersen777]

Question around what to do client side when you receive a change notification from a peer.

• If it's known working do you change your local copy of the flow?
• Do you have a lists which say accept these changes from these peers for these operations or flows automatically?
  • Ran alternate form of this example by kernel Andy, multiple devs with multiple feature branches in different repos

Modes:

• Developing
  • Use dev pull model for custom dynamic BKD, always run with the latest working code as viewed across all peers
• Debugging
  • Ensure running on the upstream BKD, stash dev pull model changes

Example: Two devs: CR0/4

For example, devs Alice and Bob are working on a dataflow which has a SUT being used to run CR0/4 patchest validation (KSPP Issue 19).

They both have their own SUT which they are using actively for development. Alice is working in kexec-tools and Bob is working in QEMU. Recall that there were multiple failure conditions when this patch was first introduced which could be pursued in parallel with enough developers.

Start with the desired end state of the the system. The state the system (defined as end state after executing flow) would be given by a pass result from the test cases: https://github.com/pdxjohnny/protecting_cr4_host_setup/blob/master/test.sh

• Hibernation / Suspend to RAM
• kexec
• SMM
• L2

If either Alice or Bob make a change which results in one of those test cases passing, it is promoted to the best known data flow (BKD). The data flow defining the test run is of course also stored upstream, which is the BKD. However, what's new about this pull model approach is that Alice and Bob can now define what their BKD should be based on, dynamically. Bob can say if Alice finds any changes that advance the upstream flow, auto apply them to my local copy. To advance the BKD one must provide essentially a more useful thought than the current most useful thought. Where a thought here is a dataflow, and in the way that we are pulling in from other devs it's likely an overlay, or a diff between dataflows.

Let's go back in time before any of the work had been done. Alice and Bob both have dffml service sw change notify daemon repo running in each git repository.

• We start at thought zero, no work has been done

graph TD

  subgraph tought_0[Thought 0]

    subgraph Alice
      alice_kexec_tools
      alice_linux
      alice_qemu
    end

    subgraph Bob
      bob_kexec_tools
      bob_linux
      bob_qemu
    end

  end

Loading

[johnandersen777]

Dataflows as a web3 adapter via input network

[johnandersen777]

Source: https://www.linkedin.com/posts/manisha-s-b72713200_data-datascience-datavisualization-ugcPost-6908783417899806720-IiA5

Example for chaos metric visualization:

[johnandersen777]

• study each thought or train of thoughts (dataflow within dataflows with full system context) to learn what activities a dev is trying
• train a model to classify trains of thoughts (the chaos metric stuff above)
• hook into dev workflows to identify active trains of thought
  • notify devs when they start to work on the same thing
  • notify devs when they start to work in a direction that another dev already worked in an yielded no results
  • notify devs when overall priorities change (change in train of thought in strategic direction, new priorities, changes to system context aka inputs in planning dataflow, or mabye that has to do with the metircs dataflow)

---

• Could write docs on why we tired a certain approach by providing background on conceptual backing behind trains of thought
  • Could write an operation that knows how to search the python standard library
  • It could read the descriptions and sphinx object file and learn what the functions do
  • You could then take high level direction towards a goal, such as
• Maybe we could give a seed thought
  • The most high level description of what we want done

graph TD

    subgraph client
      http_request
      print
    end

    subgraph http_server
      json_to_dict
      listen_for_http_requests
      get_form_value
      get_mapping
      format_message
      respond_to_http_request
    end

    http_request --> listen_for_http_requests
    listen_for_http_requests --> get_form_value
    get_form_value --> get_mapping
    json_to_dict --> get_mapping
    get_form_value --> format_message
    get_mapping --> format_message
    format_message --> respond_to_http_request

    http_request --> print

Loading

[johnandersen777]

Cross ref to #1406 (comment)

• https://github.com/nsmith5/rekor-sidekick
  • Rekor transparency log monitoring and alerting

[johnandersen777]

Cross ref to #1406 (reply in thread)

💊

[johnandersen777]

Policy on policy on downstream triggers to support sort of cached rebuild, minimal resource usage to complete full validation.

[johnandersen777]

Source: https://github.com/ietf-scitt/use-cases/blob/main/scitt-components/scitt-rbac.md#promotion-across-rbac-instances
PR: ietf-scitt/use-cases#21
LICENSE: https://github.com/ietf-scitt/use-cases/blob/main/LICENSE
Related: #1400

SCITT Role Based Access Control Enabling Decentralized Development

• References
  • https://github.com/intel/dffml/blob/alice/docs/arch/0007-A-GitHub-Public-Bey-and-TPM-Based-Supply-Chain-Security-Mitigation-Option.rst

TODO:

• Why we need limited access to information submitted to SCITT
• Will SCITT support partitioned access within a SCITT instance, or will a SCITT instance be limited and only approved content is promoted to another SCITT instance that has broader access?

Promotion Across RBAC Instances

Whether a SCITT instance supports RBAC partitioning or not, users will configure multiple SCITT instances to support their dev through production workflows, or their internal systems being maintained separate from their public services. Users can promote the content from internal, secured SCITT instances, to SCITT instances with different permissions, or public access.

Design Options

RBAC at the SCITT Instance

Any access to a SCITT instances means access to all content

Pros

Simpler to implement

Cons

• Teams that need to limit access within a SCITT instance will need to run multiple SCITT instances
• This may not work well when associating a SCITT instance with a registry/datastore that supports partitioned RBAC

RBAC Partitioning a SCITT Instance

Pros

• Maps to existing registries/storage services that support partitioning

Cons

• Harder to implement