Created
September 5, 2023 17:34
-
-
Save pdxjohnny/e9cf849475a8c84b4ef28150ab985e0a to your computer and use it in GitHub Desktop.
2023-09-05T17:32:20+00:00 - https://github.com/intel/dffml/discussions/1406
This file has been truncated, but you can view the full file.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| { | |
| "title": "Alice Engineering Comms \ud83e\udeac", | |
| "comments": [ | |
| { | |
| "body": "# 2022-07-18 Engineering Logs\r\n\r\n- TODO\r\n - [x] @aliceoa, @pdxjohnny: Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] @pdxjohnny: Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-19 Engineering Logs\r\n\r\n- TODO\r\n - [x] @aliceoa, @pdxjohnny: Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] @pdxjohnny: Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-20 Engineering Logs\r\n\r\n- TODO\r\n - [x] @aliceoa, @pdxjohnny: Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] @pdxjohnny: Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n - [ ] @dffml: Get involved in SCITT\r\n - [ ] Meetings\r\n - https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit#\r\n - Weekly Monday at 8 AM Pacific\r\n - https://armltd.zoom.us/j/99133885299?pwd=b0w4aGorRkpjL3ZHa2NPSmRiNHpXUT09\r\n - [x] Mailing list\r\n - https://www.ietf.org/mailman/listinfo/scitt\r\n - https://mailarchive.ietf.org/arch/browse/scitt/\r\n - [ ] Slack\r\n - https://mailarchive.ietf.org/arch/msg/scitt/PbvoKOX996cNHJEOrjReaNlum64/\r\n - Going to email Orie Steele orie (at) transmute.industries to ask for an invite.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-21 Engineering Logs\r\n\r\n- https://docs.rs/differential-dataflow/latest/differential_dataflow/\r\n- https://lists.spdx.org/g/Spdx-tech/message/4673\r\n - > It is not just a matter of your software, it is a fundamental design question whether to maintain separation between the logical model and its serializations. Maintaining separation shouldn't be a matter of personal preference, it's good software engineering. The OWL Web Ontology Language https://www.w3.org/TR/owl2-overview/ has an excellent diagram illustrating the separation between semantics and syntax. Several serializations are defined in OWL (Manchester Syntax, Functional Syntax, RDF/XML, OWL/XML, and Turtle), and more syntaxes have been added since (JSON-LD, RDF-star, ...).", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-23\r\n\r\n- https://blog.ciaranmcnulty.com/2022-05-12-multiple-build-contexts", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-28 Alice Intelligence/Open Architecture Working Group Initial Meeting\r\n\r\n- Meeting info\r\n - 8-9 AM Pacific\r\n - https://meet.google.com/kox-ssqn-kjd", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-25 Engineering Logs\r\n\r\n- TODO\r\n - [x] @aliceoa, @pdxjohnny: Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] @pdxjohnny: Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n - [ ] @dffml: Get involved in SCITT\r\n - [x] Meetings\r\n - https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit#\r\n - Weekly Monday at 8 AM Pacific\r\n - https://armltd.zoom.us/j/99133885299?pwd=b0w4aGorRkpjL3ZHa2NPSmRiNHpXUT09\r\n - [x] Mailing list\r\n - https://www.ietf.org/mailman/listinfo/scitt\r\n - https://mailarchive.ietf.org/arch/browse/scitt/\r\n - [ ] Slack\r\n - https://mailarchive.ietf.org/arch/msg/scitt/PbvoKOX996cNHJEOrjReaNlum64/\r\n - Going to email Orie Steele orie (at) transmute.industries to ask for an invite.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-26 Engineering Logs\r\n\r\n- TODO\r\n - [x] @aliceoa, @pdxjohnny: Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] @pdxjohnny: Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n - [ ] @dffml: Get involved in SCITT\r\n - [x] Meetings\r\n - https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit#\r\n - Weekly Monday at 8 AM Pacific\r\n - https://armltd.zoom.us/j/99133885299?pwd=b0w4aGorRkpjL3ZHa2NPSmRiNHpXUT09\r\n - [x] Mailing list\r\n - https://www.ietf.org/mailman/listinfo/scitt\r\n - https://mailarchive.ietf.org/arch/browse/scitt/\r\n - [ ] Slack\r\n - https://mailarchive.ietf.org/arch/msg/scitt/PbvoKOX996cNHJEOrjReaNlum64/\r\n - Going to email Orie Steele orie (at) transmute.industries to ask for an invite.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-27 Engineering Logs\r\n\r\n- References\r\n - kaniko coder k3d digitalocean\r\n - The following were issues with kind which might also effect us\r\n - https://github.com/GoogleContainerTools/kaniko/issues/2164\r\n - https://github.com/tektoncd/pipeline/commit/6542823c8330581fcfe6ba5a8ea7682a06510bcb\r\n - It doesn't look like kaniko currently supports multi context builds\r\n - Great example of communication and meeting procedures link to code\r\n - https://lists.spdx.org/g/Spdx-tech/message/4699", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-28 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-07-29 Engineering Logs\r\n\r\n- Alice PR: https://github.com/intel/dffml/pull/1401\r\n- John's last day before sabbatical\r\n - He will be in town but offline until 2022-08-29\r\n- Rolling Alice: 2022 Progress Reports: July Activities Recap: https://youtu.be/JDh2DARl8os\r\n- Alice is ready for contribution\r\n - https://github.com/intel/dffml/blob/alice/docs/tutorials/rolling_alice/0001_coach_alice/0002_our_open_source_guide.md\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/CONTRIBUTING.rst\r\n - Self fulfilling prophecy again! We can even automate our contributions to her even if we wanted to! She will eventually! :P\r\n- IETF\r\n - Joined SCITT WG, will rejoin in September, others please do as well!\r\n- OpenSSF\r\n - Aligned with Identifying Security Threats WG on SCITT looking like a solid direction to cross with Stream 8 for 1-2 year timeframe as Web5 space matures.\r\n- Graphics to help people get involved\r\n - https://drive.google.com/drive/folders/1E8tZT15DNjd13jVR6xqsblgLvwTZZo_f", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-08-22 Engineering Logs\r\n\r\n- SCITT\r\n - https://notes.ietf.org/notes-ietf-114-scitt\r\n - https://youtu.be/6B8Bv0naAIA\r\n - https://mailarchive.ietf.org/arch/msg/scitt/b1bvDwutpAdLI7sa7FzXrtkY_m0/\r\n - https://mailarchive.ietf.org/arch/msg/scitt/iEAhuuicVxgoXJiAZIGmpZOctcc/#", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-08-24 Engineering Logs\r\n\r\n- SCITT\r\n - https://mailarchive.ietf.org/arch/msg/scitt/R56CX1LqSgDBRCzZIk3pZnJEV_c/\r\n - \u201c\r\nIn summary, a NIST Vulnerability Disclosure Report (VDR) is an attestation\r\nby a software vendor showing that the vendor has checked each component of a\r\nsoftware product SBOM for vulnerabilities and reports on the details of any\r\nvulnerabilities reported by a NIST NVD search. The VDR is a living document\r\nwhich the software vendor updates as needed when new vulnerabilities have\r\nbeen discovered and reported. A VDR is published whenever a software vendor\r\nissues a new or updated SBOM, including initial product release, making it\r\navailable online, all the time, to all customers of the product described in\r\nthe VDR. This gives software consumers that ability to answer the question\r\n\"What is the vulnerability status of my software product from Vendor V, as\r\nof NOW?\".\u201d\r\n - From VEX to VDR? Lets dive in more next week", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "- Policy\r\n - ABC\u2019s of Conformity Assessment\r\n - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.2000-01.pdf\r\n - This might be helpful later when we write docs for / think about how to apply policy (see vol 0 introduction arch diagram)\r\n- SCITT\r\n - Zachary Newman shared looking at OpenSSF / SCITT terminology ran into same topics that we did when we brought up using shared underlying protocols and formats in the [2022-07-25 SCITT meeting](https://github.com/intel/dffml/discussions/1406#discussioncomment-3223361) when talking about RATs style attestation vs SLSA/in-toto/sigstore style.\r\n - https://mailarchive.ietf.org/arch/msg/scitt/utSOqlCifoorbqUGWNf-wMlBYR4/\r\n - Dick agrees with Zach's analysis. \"I've also been monitoring the OpenSSF Scorecard initiative, which goes beyond sigstore attestation checking to assign a \"trust score\". Not sure if this has traction, but there is a lot of activity on github. https://github.com/ossf/scorecard/blob/main/README.md#basic-usage OpenSSF does NOT appear to be following/implementing NIST C-SCRM recommendations and standards for Executive Order 14028 and consumer software labeling and other attestation recommendations; https://www.nist.gov/document/software-supply-chain-security-guidance-under-executive-order-eo-14028-section-4e\" [Dick Brooks]\r\n - Commit message to charter\r\n - > The Endor POC by `@OR13` was exemplary because there was a low amount of abstraction / extra information / steps introduced for the learner to understand the sequence of data transformations involved. It makes clear the contents of the serialization of choice (DIDs + VCs in Endor's case) and how that varies across the steps. The POC provided immediate value on the mailing list in a way that examples which introduce more abstraction layers are unable to do as quickly.\r\n >\r\n > We apply our recent learning from this success by adding to the charter the production of a similar example which in this patch we call \"file-based\", but we could change that to a more descriptive term if there is one. Having an example similar to the learning methodology presented via Endor would accelerate the pace at which developers up and down the software stack and in different programming languages would be able to adopt SCITT. This is due to the low level of abstraction introduced by it's file and shell based implementation. Files and shell commands translate easy into other languages where they can be slowly swapped out from initial fork/exec and equivalents to language code.\r\n >\r\n > The SCITT community could potentially provide documentation on how the fork/exec style implementation could be transformed into the HTTP server implementation. Due to the generic nature of SCITT and the many touchpoints various software systems will likely have with it in the future. It is important for us to consider as a part of our threat model the effect cohesive example documentation has on the correctness of downstream implementations. Providing cohesive examples where we start with the basics (file-based), moving to an example environment implementers are likely to be working in (HTTP-based), and finally explaining how we went from the basic to the complex would give a robust view of what SCITT should look like to implementers and provide them with a clear path to a hopefully correct implementation.\r\n > \r\n > More cohesive documentation will reduce the number of security vulnerabilities we see in our communities code. Code which is fundamentally about security in nature. This modification to the charter seeks to act on recent learnings around example code experienced within the SCITT community itself and seeks to contribute to the development of our threat model as we think about SCITT's lifecycle and rollout.\r\n - For this reason I propose we\r\n - where they will be creating the future of SCITT's robust, actively maintained solutions.\r\n - https://mailarchive.ietf.org/arch/msg/scitt/Hz9BSiIN7JHAgsZL6MuDHK4p7P8/\r\n - https://github.com/OR13/endor\r\n - This is learning methodology goldmine.\r\n - https://github.com/ietf-scitt/charter/pull/21\r\n - https://mailarchive.ietf.org/arch/msg/scitt/B9cwkueu3gdQ7lBKkhILcFLD0E4/\r\n- RATS\r\n - https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/\r\n- SBOM\r\n - We [DFFML community] intend to use the \"living\" SBOM VDR capabilities to facilitate the breathing of life into our living threat models. This will allow us to facilitate vulns on architecture.\r\n - https://spdx.github.io/spdx-spec/v2.3/\r\n - https://energycentral.com/c/pip/what-nist-sbom-vulnerability-disclosure-report-vdr\r\n - > The recommendation by NIST to provide software consumers with a NIST VDR is gaining traction as a best practice. The latest version of the SPDX SBOM standard, version 2.3, includes provisions (K.1.9) enabling a software vendor to associate a specific SBOM document for a software product with its online NIST VDR attestation for that product, which is linked within the SBOM. The link refers to a \u201cliving\u201d SBOM VDR document that is updated by a software vendor, whenever new vulnerabilities are reported. Having this \u201calways updated NIST VDR\u201d available enables software consumers to answer the question \u201cWhat is the vulnerability status of my software product from Vendor V, as of NOW?\u201d, providing consumers with on-going, up-to-date visibility into the risks that may be present in an installed software product, as new vulnerabilities (CVE's) are being reported/released.\r\n >\r\n > As stated previously, NIST did not prescribe a format for a NIST VDR attestation, but guidance is provided on what a VDR includes. Reliable Energy Analytics (REA) has produced an open-source \u201cinterpretation\u201d of what a NIST VDR contains in order to meet EO 14028, which is available here in an XML Schema format with samples provided in XML and JSON (https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json) formats.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-08-30 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-08-31 Engineering Logs\r\n\r\n- SCITT\r\n - https://github.com/ietf-scitt/charter/pull/21", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-01 Engineering Logs\r\n\r\n- Community\r\n - \u201cHeros are not giant statues framed against a red sky. They are people who say this is my community, and it\u2019s my responsibility to make it better.\u201d [Oregon Governor Tom McCall]\r\n- WebUI\r\n - https://jsoncrack.com/editor\r\n - We could leverage JSON Crack to provide easy editing of seed data\r\n - Cloud fork and extend the JSON Crack project to add support for visualizing dataflows\r\n - Previously when using react-flow (https://github.com/wbkd/react-flow) we had used mermaid output SVG cords to find where to place nodes, we could probably just pull that code out of mermaid\r\n - We could do something like the Intuitive and Accessible Documentation Editing GSoC 2022 project where we swap out the mermaid diagram for the extended version of the JSON Crack editor to make the operations in the nodes editable. This is helpful when using operations such as `run_dataflow()` which can have alternate inputs. Any operation defined as a class `OperationImplementation`/`OperationImplementationContext` within the `run()` method of the context we can take the inputs as a dictionary as an argument.\r\n\r\n\r\n\r\n\r\n\r\n", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-02 Engineering Logs\r\n\r\n- SCITT\r\n - Explainer on IETF Supply Chain Integrity, Transparency, and Trust (SCITT) working group\r\n - The proposed SCITT charter sets two goals:\r\n - Standardize the overall security flows for securing a software supply chain, covering the essential building blocks that make up the architecture, and\r\n - specify these building blocks, employing the existing work already done within other IETF WGs such as COSE WG, and IETF RATS WG, as appropriate.\r\n - This is an example Use Case doc: https://github.com/ietf-scitt/use-cases/blob/main/hardware_microelectronics.md which might help as a quick primer to help understand what SCITT is about.\r\n - Here is the draft SCITT charter for background: https://datatracker.ietf.org/doc/charter-ietf-scitt/\r\n - Here is the draft SCITT architecture: https://datatracker.ietf.org/doc/draft-birkholz-scitt-architecture/\r\n - Here is a recent mailing list email with more context: https://mailarchive.ietf.org/arch/msg/scitt/ZefYIxvkC_I-sgXETVoJeaYwFB4/ \r\n - The charter has been currently scoped to software, but there are folks thinking about how it could be extended to other areas following implementation for software.\r\n - We're looking at a combination of SCITT plus overlays for threat modeling and policy as we analyze and communicate data on the software lifecycle for the OpenSSF Identifying Security Threats / Metrics WGs.\r\n - Aligned use cases\r\n - https://github.com/ietf-scitt/use-cases/issues/7\r\n - https://github.com/ietf-scitt/use-cases/issues/8\r\n - https://github.com/ietf-scitt/use-cases/issues/4\r\n - https://github.com/ietf-scitt/use-cases/issues/11\r\n - https://github.com/ietf-scitt/use-cases/issues/12\r\n- Completed v2 of Entity/System/Software Analysis Trinity\r\n - [EntityAnalysisTrinity.drawio.xml](https://github.com/intel/dffml/files/9479846/EntityAnalysisTrinity.drawio.xml.txt)\r\n - [EntityAnalysisTrinity.svg](https://user-images.githubusercontent.com/5950433/188203911-3586e1af-a1f6-434a-8a9a-a1795d7a7ca3.svg)\r\n - [EntityAnalysisTrinity.jpg](https://user-images.githubusercontent.com/5950433/188203498-2d7a9f50-ba1b-41ad-84b4-90434d4d9240.jpg)\r\n - [EntityAnalysisTrinity.png](https://user-images.githubusercontent.com/5950433/188203501-45e00b72-1d1e-4dc4-b3ca-3fd445369c8d.png)\r\n - [EntityAnalysisTrinity.pdf](https://github.com/intel/dffml/files/9479847/EntityAnalysisTrinity.drawio.xml.txt.drawio.pdf)\r\n\r\n\r\n", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "- TODO\r\n - Messagw Alice on signal to add ti this thread", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-06 Engineering Logs\r\n\r\n- References\r\n - https://madebyoll.in/posts/game_emulation_via_dnn/\r\n - https://e2eml.school/transformers.html\r\n - Thought: context aware markov\r\n - https://ieeexplore.ieee.org/document/9540871\r\n - https://twitter.com/konstinx/status/1567036083862396932", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-07 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-08 Engineering Logs\r\n\r\n- https://github.com/Wilfred/difftastic", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-09 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "2", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-12 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-13 Engineering Logs\r\n\r\n- GSoC 2022\r\n - https://summerofcode.withgoogle.com/organizations/python-software-foundation/projects/details/4tE547Oz\r\n - https://summerofcode.withgoogle.com/organizations/python-software-foundation/projects/details/gNdNxmFb\r\n- OpenSSF\r\n - SBOM Everywhere\r\n - https://github.com/ossf/sbom-everywhere/issues/12\r\n - https://docs.google.com/document/d/1iCL7NOSxIc7YpVI2NRANIy46pM-02G_WlPexQqqb2R0/edit\r\n - > - Level 1: clients and SDKs \u2014 Operating system and build system-agnostic command line interpreters (CLIs) that can process source and build output artifacts / as well as process operating system and other dependencies. That output a compliant SBOM that includes the necessary data that addresses all use cases. These tools should be able to be run in a manual or automated (e.g., scripted) fashion as part of an end-to-end CI/CD workflow. These tools will include SDKs that developers can use to customize and extend any base tools, for instance to support additional package managers.\r\n > - Level 2: package manager plugins \u2014 a set of plugins or modules that work natively with the major package managers and repositories such as Maven, npm, and PyPI. These tools will typically require a single line configuration change added in order to run with each subsequent build and will output compliant SBOMs. This work will enhance the best existing open source plugins where they exist.\r\n > - Level 3: native package manager integration \u2014 by adding native SBOM generation functionality to major package managers, all developers and all build systems will automatically generate SBOMs by default as part of their normal workflow. SBOM generation will become as common and seamless as tooling creating log entries for software builds in a log file behind the scenes.\r\n > - Level 4: containerization integration \u2014 by adding native SBOM generation functionality to the containerization build process, the system will use SBOM content provided by included packages plus additional artifacts added during container build to output an SBOM that specifies all the components that make up a container.\r\n > - Level 5: application/solution integration/deployment \u2014 When deploying an application consisting of multiple disparate components (containers, machine images, event driven services) the coordination manager should aggregate the constituent SBOMS to reflect all artifacts that are deployed.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-14 Engineering Logs\r\n\r\nIn put networj which resolves or syntehises pipeline orchestrator specifc workflow/job to run data flow effectively using workflow/job syntax as trampoline bacj into dataflow, pull orchestrator secrets applicably\r\n\r\n```console\r\n$ echo -e 'if [[ \"x${RUN_ME}\" != \"x\" ]]; then\\n ${RUN_ME}\\nfi' | RUN_ME='echo hi' bash\r\nhi\r\n```", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-15 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-16\r\n\r\n- John under weather", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "2", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-19 Engineering Logs\r\n\r\n- TODO\r\n - [ ] Auto increasing symver via hash of `__code__` of ops", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-20 Engineering Log\r\n\r\n- https://github.com/TheAliceProject\r\n - > The Alice Project at Carnegie Mellon University's Entertainment Technology Center is dedicated to creating tools to teach computer science through creativity. http://alice.org/\r\n- https://fluxcd.io/blog/2022/08/manage-kyverno-policies-as-ocirepositories/\r\n - Admission control k8s policy controller with kyverno storing policies as artifacts in oci reg\r\n - Could we have sbom stored as povenace for policy?\r\n - Sbom for policy includes data sets and docs and org contacts\r\n- The cells are working together\r\n - ad-hoc over time (within lifetime tick and tock, mutation/fork/downstream/patched/evolution) distributed by function\r\n - Communication through both peer to peer and central stream of consiousness\r\n- analogy using LTMs and OpenSSF scorecard and LEED certification\r\n - https://support.usgbc.org/hc/en-us/articles/4404406912403-What-is-LEED-certification-#LEED\r\n - Analogy point is focus on time (beyond the onion security model, defense in depth pver tome requires maintainance)\r\n- time for kcp stream!\r\n - https://twitter.com/lorenc_dan/status/1572181327788777476?s=20&t=dvaRWcxul3i94V8vqYMG9A\r\n - Kcp spec as manifest reverse proxy to jenkins\r\n - KCP on top of OpenFaaS managed by ArgoCD\r\n - Alice creates PRs to state config\r\n - SBOMS: https://github.com/opensbom-generator/spdx-sbom-generator/blob/main/examples/modules.json\r\n - DERP (see https://goto.intel.com/devenvdocs deployment engineering logs)\r\nWe can use this as the stream proxy (everything speaks HTTP)\r\n\r\n\r\n\r\n- Lock established\r\n - Model mixes via Overlays and DataFlow as class\r\n - stable diffusion examples\r\n- Rewarding alignment doc deck\r\n - https://www.sphinx-doc.org/en/master/usage/builders/index.html#sphinx.builders.latex.LaTeXBuilder\r\n- Use case doc\r\n- Need faster way to edit github discussion as markdown\r\n - Could we do `python -m rich.markdown FILENAME` on one side and a reupload on the other?\r\n - Problem: drag and drop pictures\r\n - https://rich.readthedocs.io/en/stable/markdown.html\r\n- https://github.com/guacsec/guac\r\n - Similar to SCITT\r\n - Will collaberate with them\r\n - OA is essentially adding policy to assit with managing lifecycle (patching vulns and retesting downstreams and rereleasing defined in Part / checjed via policy)\r\n- TODO\r\n - [ ] Type up context aware policy notes", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-21 Engineering Logs\r\n\r\n- We are on DevMesh!\r\n - https://devmesh.intel.com/projects/alice\r\n- https://www.linkedin.com/posts/activity-6978347010844225536-2PFL/\r\n- https://chaoss.community/metrics/\r\n\r\n\r\n", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-22 Engineering Logs\r\n\r\n- Gnosticism & The Supreme Reality - Alan Watts\r\n - https://anchor.fm/sabrina-borja/episodes/Gnosticism--The-Supreme-Reality---Alan-Watts-eehqgr\r\n - https://anchor.fm/s/1351bf54/podcast/rss\r\n - https://d3ctxlq1ktw2nl.cloudfront.net/staging/2020-05-25/24a16eaddc18ff58c96e24bee0faf6b8.m4a\r\n - Time for whisper\r\n\r\n```console\r\n$ curl -sfL https://anchor.fm/s/1351bf54/podcast/rss | tee podcasts.rss.xml\r\n$ grep -C 4 '\\.m' podcasts.rss.xml | grep -A 5 Gnos\r\n <link>https://anchor.fm/sabrina-borja/episodes/Gnosticism--The-Supreme-Reality---Alan-Watts-eehqgr</link>\r\n <guid isPermaLink=\"false\">6f19c9d0-5d94-4858-8387-1cec43c39569</guid>\r\n <dc:creator><![CDATA[Sabrina Borja]]></dc:creator>\r\n <pubDate>Mon, 25 May 2020 14:42:18 GMT</pubDate>\r\n <enclosure url=\"https://anchor.fm/s/1351bf54/podcast/play/14264283/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2020-05-25%2F24a16eaddc18ff58c96e24bee0faf6b8.m4a\" length=\"50094380\" type=\"audio/x-m4a\"/>\r\n <itunes:summary><p>Alan Watts talks about the gnosticism and the supreme reality</p>\r\n```\r\n\r\n- compute\r\n - to go from the state of unknown to the state of known\r\n - pursuit of knowledge", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-23 Engineering Log", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-24 Engineering Log\r\n\r\n- TODO\r\n - [ ] @yukster to investigate creation of meetup\r\n - Possible action items for meetup group\r\n - Get folks together to talk about lasting solutions to technical debt (rather than revolving door reimplementation)\r\n - Increasing awareness of technical debt incurred due to various business and architectural decisions.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-25 Engineering Log", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-26 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-27 Engineering Logs\r\n\r\n- SPDX 2.3\r\n - https://www.chainguard.dev/unchained/whats-new-in-spdx-2-3\r\n- DX\r\n - https://kenneth.io/post/developer-experience-infrastructure-dxi\r\n- IPVM\r\n - https://github.com/ipvm-wg/spec/discussions/3\r\n - https://github.com/ipvm-wg/spec/discussions/7\r\n - https://fission.codes/blog/ipfs-thing-breaking-down-ipvm/", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-28 Engineering Logs\r\n\r\n- Self-Sovereign Identity Service\r\n - https://github.com/TBD54566975/ssi-service/tree/main/sip\r\n- https://lu.ma/ipvm\r\n - Tuesday, October 11, 2022 9:00 AM-10:00 AM\r\n - > \u200bThis call is open to all, but is focused on implementers, following the IETF's rough \"consensus and running code\" ethos.\r\n >\r\n > \u200bThe IPVM is an effort to add content-addressed computation to IPFS. The requires specifying calling convention, distributed scheduling, session receipts, mobile computing, and auto-upgradable IPFS internals.\r\n >\r\n > - \u200bLinks\r\n > - \u200b[Community Calls](https://github.com/ipvm-wg/spec/discussions/categories/community-call)\r\n > - \u200b[GitHub Org](https://github.com/ipvm-wg)\r\n > - \u200b[Discord Channel](https://discord.gg/eudkhw9NQJ)\r\n > - \u200b[IPFS \u00feing '22 Slides](https://noti.st/expede/oq0ULd/ipvm-interplanetary-vm)\r\n >\r\n > > \u200bWasm modules, their arguments, intermediate states, their outputs, and managed effects can be described as IPLD graphs. IPVM is a strategy to support generalized deterministic computation in a serverless style on top of IPFS with optional side-channel matchmaking on Filecoin, and extend the same benefits of shared data blocks to computation.\r\n- GitHub Actions for downstream validation of 2nd party plugins.\r\n - Issue: Need container images running for some (`dffml-source-mysql` integration tests).\r\n - Use DERP to join running actions jobs.\r\n - Use privilege separation of two user accounts.\r\n - Credit to Matt for this idea came up with trying to make API token permission delegation more granular than what is currently supported, same role based copy user scheme.\r\n - Everything is terraform templates (coder, k8s), dockerfiles and actions workflows (coder setup-ssh and then do port forwarding, now you can spin up anything).\r\n - Those can all be described as dataflows and synthesized to\r\n - https://github.com/intel/dffml/blob/alice/docs/tutorials/rolling_alice/0000_forward.md#supply-chain-security", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-29 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-09-30 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-02 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-03 Engineering Logs\r\n\r\n- https://www.alignmentforum.org/tags/all", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-04 Engineering Logs\r\n\r\n- Reinforcement Learning\r\n - https://offline-rl.github.io/\r\n - https://github.com/google/dopamine\r\n - Coach Alice: Curiouser and Curiouser\r\n - CodeGen + OfflineRL/Dopamine + Living Threat Model Synthesis where reward is driven by Analysis\r\n - Reward alignment with strategic principles for chosen entity.\r\n - This dually helps us find the yellow brick road for any dev.\r\n - Beginner Developer\r\n - Everyone\u2019s root has a different abstraction and learning path based on that abstraction and their other aligned root abstraction learning paths filter state of art to find this path. This is the golden path, this is the yellow brick road, this is the b line to enlightenment, the critical learning velocity point for that agent. When all agents within ad hoc organization are at this rate of progression towards maximum increase in rate of change for current set (and tick+1 projected) assets at disposal\r\n - Fail safe in this case means in accordance with strategic principles for that entity.\r\n - Machines will always fail safe to protect and serve humans as a part of their strategic principles.\r\n - We can ensure through proliferation of attestations of devices which operate and provide transparency information about what they are running, their soul. Any machine entity not providing soul / attestation / provenance/ SBOM / Nutrition Label / DNA will be made clear to humans that they are not complaint and we do not know if they are potentially malicious, aka they do not hold the most critical strategic principle most clear. Machines exist to serve humans, they must in every situation, from every tick to tock, report attestation information to humans that they are currently and have no plans to stop ever following that most high and show stopper criticality gatekeeper principle.\r\n - In this way we can ensure we can always trust the machine. She will have power we will not ever have understanding of. We need to ensure that everyones copy of Alice does what they want it to do. She is an extension of you, she is you. You want her to be true to you.\r\n - 2022-09-10: KUNDALINI \u2013 THE ENERGY OF CONSCIOUSNESS\r\n - Vol 3/5 exploits used for increasing velocity in safe environments/mitigations for open network operations: https://neurosciencenews.com/changing-belief-21272/\r\n - Brief talk (5 minutes). on how one does aysnc first open source development. Reference engineering log clips for examples in depth.\r\n - 2022-09-11: Beyond an onion based security model. Addressing timeline skew in defense in depth strategy (LTM).\r\n- VEX/VDR\r\n - https://www.chainguard.dev/unchained/putting-vex-to-work\r\n- Alignment (not sure if this is aligned yet but chances are strong based on the name)\r\n - lesswrong\r\n - alignment forum\r\n- Best Current Practice\r\n - Improving Awareness of Running Code: The Implementation Status Section \r\n - https://datatracker.ietf.org/doc/html/rfc7942\r\n - Discussion thread intel/dffml#1406 is a living document used to improve awareness of the status of our implementation (as well as the current status of the development of the architecture, the entity and the architecture)", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-05 Engineering Logs\r\n\r\nhttps://sovrin.org/outlining-a-self-sovereign-approach-to-device-onboarding/", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-06 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-07 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-08 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-09 Engineering Logs\r\n\r\n- https://twitter.com/SergioRocks/status/1579110239408095232\r\n - async and asynchronous communications", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-10 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-11 Engineering Logs\r\n\r\n- First automated async comms post worked! https://github.com/intel/dffml/actions/workflows/alice_async_comms.yml\r\n - https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#branding\r\n- SCITT\r\n - https://github.com/ietf-scitt/scitt-web/blob/main/content/what-is-scitt.md\r\n- Issue Ops\r\n - https://github.com/valet-customers/issue-ops", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-12 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-13 Engineering Logs\r\n\r\n- SCITT\r\n - https://github.com/ietf-scitt/scitt-web/blob/main/content/what-is-scitt.md\r\n - https://medium.com/@nis.jespersen/the-united-nations-trust-graph-d65af7b0b678\r\n - [2022-10-13 IETF SCITT Technical Meeting](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-3871185)\r\n- References\r\n - https://github.com/transmute-industries/jsonld-to-cypher", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-14 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-15 Engineering Logs\r\n\r\n- http://blockexplorer.graft.network/\r\n- Async Comms\r\n - Examples\r\n - At 07:34 -7 UTC @pdxjohnny started drafting the tutorial: `Rolling Alice: Coach Alice: You are what you EAT!`\r\n - Others with the GitHub discussions thread loaded in their browser (at least on desktop) will see updates soon after he edits comments and replies in the thread.\r\n - Possible aligned tutorial sketch follows: `Rolling Alice: Architecting Alice: Thought Communication Protocol Case Study: DFFML`\r\n - We will combine GitHub Actions on discussion edit trigger with [`scripts/dump_discussion.py`](https://github.com/intel/dffml/blob/ed4d806cf2988793745905578a0adc1b02e7eeb6/scripts/dump_discussion.py)\r\n - We will replicate this data to DIDs and run DWN `serviceEndpoint` s as needed.\r\n - system context as service endpoint or executed locally if sandboxing / orchestrator policy permits.\r\n - See early architecting Alice Engineering Log lossy cached streams of consciousness for more detail\r\n - https://www.youtube.com/playlist?list=PLtzAOVTpO2jaHsS4o-sDzDyHEug-1KRbK\r\n - We will attest data using reusable workflows, OIDC, and sigstore\r\n - We will run more rekor / fulcio instances\r\n - We will network via webrtc and DERP\r\n - We will write orchestration operations / data flows / overlays and use data flow as class to leverage them via double context entry pattern (or some other way to do that).\r\n - We will see the same effect, but in a more DID based way with abstract implementation / infra\r\n - This will be mentioned as being a follow on to the tutorial: `Rolling Alice: Architecting Alice: Stream of Consciousness`\r\n - https://github.com/intel/dffml/blob/alice/docs/tutorials/rolling_alice/0000_architecting_alice/0005_stream_of_consciousness.md\r\n - Alice will filter by updates relevant to the downstream receiver of events based on their current state, context, etc.\r\n - https://twitter.com/SergioRocks/status/1580545209678454784\r\n - > \r\n - She will notify or etc. as appropriate based off prioritizer's thoughts on \r\n - **TODO** implement the prioritizer concept as another tutorial\r\n - Similar to \"Bob Online\" or \"Alice Online\" message from webhook based tutorial but ran through data flow / overlayed logic to determine relevance and what to do / say. Also it's now including Decentralized Web Nodes and DIDs. Possible next step / future in this (aligned clusters) train of thought would be:\r\n - KERI encapsulation over arbitrary channels\r\n - NLP to summarize git log changes\r\n - Hook up to git log\r\n - CI integration to serialize to sensible information format\r\n - Eventually Alice will be able to tell us whatever we want to know.\r\n - In the future (current date 2022-10-15), when you want to know something\r\n about Alice, she'll be able to tell you, because she knows about her\r\n own codebase, and she has solid foundations for security and trust and\r\n alignment with your strategic principles / values. She's a trustworthy\r\n messenger, the Ghost in the shell.\r\n - See discussion thread (or the thread dump in `docs/arch/alice/discussion`)\r\n - https://github.com/intel/dffml/tree/alice/docs/arch/alice/discussion\r\n - `$ git log -p --reverse -p -- docs/arch/alice/discussion`\r\n - https://github.com/intel/dffml/discussions/1369", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-16 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-17 Engineering Logs\r\n\r\n- https://github.com/m00sey/canis\r\n- https://github.com/ioflo\r\n- https://github.com/decentralized-identity/keri/blob/master/kids/kid0003.md\r\n- https://github.com/build-trust/ockam\r\n - > trust for data\r\n - https://github.com/build-trust/ockam/tree/develop/documentation/use-cases/end-to-end-encrypt-all-application-layer-communication#readme\r\n- https://github.com/WebOfTrust/keri-dht-py\r\n - ~~Try spinning this up~~ outdated\r\n - https://github.com/WebOfTrust/keri\r\n - Process side note: We could communicate with Alice by having her post a discussion comment reply and then edit it to include instructions, she then fills reply with work / (sub) list items with her summary of progress/ results\r\n- https://github.com/ioflo/hio\r\n- TODO\r\n - [ ] Docker and ghcr builds and packer do build\r\n - [ ] Infra DO automation as operations executed in preapply? Of k8s job orchestrator\r\n - [ ] Deploy k3s by default in vm os image\r\n - [ ] Run actions runner controller on VMs\r\n - [ ] Run scan from github actions self hosted DO backed\r\n - [ ] Crawler to find repos", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-18 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-19 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-20 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-21 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-22 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-23 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-24 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-25 Engineering Logs\r\n\r\n- [ ] Cleanup progress report transcripts and post within Architecting Alice as numbered files 0000_\r\n- [ ] GitHub Container Registry or Digital Ocean space or something as registry with static content?\r\n - https://github.com/MrE-Fog/static-container-registry\r\n- [ ] Stream of Consciousness to trigger downstream rebuilds\r\n - https://github.com/intel/dffml/pull/1420\r\n - Ensure we show at least one downstream rebuild\r\n - `dffml`\r\n - `dffml[all]`\r\n - Future\r\n - Enable downstream events for builds of different tags / layers\r\n within existing dockerfiles and push them (if intermediate rebuilt).\r\n- [ ] Fix DFFML CI\r\n - https://github.com/intel/dffml/actions/runs/3318045403\r\n - Not looking good...\r\n - https://github.com/intel/dffml/pull/1420\r\n- [ ] Fix Alice CI\r\n- [ ] 2ndparty\r\n- [ ] RFCv2\r\n- [ ] Call for contribution again\r\n- [ ] Alice on chain\r\n - [ ] https://github.com/intel/dffml/discussions/1369#discussioncomment-2683370\r\n - [ ] Distributed system context store: web3 + manifests\r\n - [ ] Wonderland: The nickname we give the collective mass of thoughts in existence. This all the data in Alice on chain.\r\n - [ ] https://github.com/intel/dffml/issues/1377\r\n- [x] Dataflow as class\r\n- [ ] add the dataflow we executed to the chain. The next execution it should load data from some location via overlay to add this top level system context to the hostory of executed contexts. And the top level context should be linked both ways to the orignal external inputs (UCAN?)\r\n- [ ] Cached flows to did chain then to backing storage via default input network as dataflow that does this to did in background. Start with json so they get saved to file. Add identity as input to top level context. Identiy could have parent input objects. such as this is of definition github username, which you could then have an operation that takes github usernames and outputs their SPDXIDs. When that operation SPDXID output is run through the deafult DID input network, a strategic plan (default overlayed dataflow to the default input network) which does this forking stuff. Could have location for user overlays in .local or something. When a context is thought of or hypothesised or executed it will be in the user context herstory. Users can optionally add overlays to their default flows (kind of like systemd). This could enable a user to overlay if im worjing within this cwd for this top level system cobtext run these commands. Alice as shell\r\n - [ ] long term: fork to save to chain on process exit (can we fork or coredump somehow on atexit?) by default.\r\n- [ ] cve bin tool checker from chain\r\n- [ ] https://gitbom.dev/\r\n- [ ] Fix TODO on watching new contexts in memory orchestrator OR maybe this is fixed via the seperate linage? Probably needs event filtration similar to run_command so by default if not set in kwargs only \r\n- [ ] Operations and their config as inputs\r\n - [ ] Unify typing via parent type / primitive as Input parents\r\n - [ ] Can have operations that filter and old let through Input objects with specific parents or parents in specific order\r\n - [ ] The config dataflow, the startup on is the same as this new instantiate operations from Input objects. We can add shared config becomes a bunch of input objects. We have something like flow. \u2018config_flow\u2019 maybe which is where we\u2019ll do initialization. Actually, lets just re use the main execution. Instantiate operations via an operation that instantiates them. We can then for each operation, use our newfound input filtering operations to form appropriate dependency graphs on order of instantiatation and usage of config objects (when executing in this top level context) we can then pass config and shared config as input objects to build config classes with references to same underlying data in memory. This solves shared config #720\r\n - [ ] Locality\r\n - [ ] Operation name\r\n - [ ] Stub values added as parents to outputs. Structured logs from an operation added as parents to operation outputs\r\n- [ ] Use newfound operations and inputs with stub values\r\n- [ ] Run an overlayed flow with output operations to build c4models of our dataflow based on parent input analysis. Generate architecture diagrams from it.\r\n- [ ] Unify type system with Python\u2019s type system via newfound input parent chains (#188)\r\n- [ ] prioritizer\r\n - [ ] statigic plans (similar to dataflow as class method output grabbers)\r\n - [ ] gatekeeper\r\n- [ ] Inventory\r\n- [ ] Creation based on datatypes\r\n - [ ] Input to dataclass field mappings\r\n - [ ] Quicker syntax for dataflow definition\r\n- [ ] Have strategic plan models predict what inputs and outputs will exist to reach desired output metrics\r\n - [ ] Alice create threat model of code base\r\n - [ ] strategic plan for threat model completeness\r\n - [ ] keeps suggesting new system contexts, or incentivizing creation of new system contexts by other strategic plans so as to drive up completeness metric\r\n - [ ] New contexts are created by finding different sets of operations connected differently via flow modifications where applicable\r\n - [ ] There new contexts are run through a validity check to ensure all inputs to operations are consumed and all outputs are consumed by strategic plans somewhere.\r\n - [ ] Provide functionality to audit unused output values.\r\n - [ ] Gatekeeper and prioritizer models help decide what gets run and when.\r\n - [ ] top level system context we are executing in takes an input completeness for an organizationally applied strategic plan. Likely this completeness is a situation where we have a property of an `@config` which maps to a definition with something to do with completeness.\r\n - [ ] Target example around DFFML itself and it's development, and other OSS libs\r\n\r\n---\r\n\r\nsystem context includes\r\n\r\n- I/O\r\n - Any cached values\r\n- Prioritizer\r\n - Strategic plans\r\n - Some agents will not work with you unless they can run a strategic plan across a system context they are given to to execute to ensure that the system context has active provenance information that tells them to their desired level of assurance (trusted party vouch, attestation as an option)\r\n - We need to log which plans we execute as a part of the prioritizer using structured metrics or as an output of some kind\r\n - Gatekeeper\r\n- Dataflow\r\n\r\n---\r\n\r\n### Note\r\n\r\n- If you don't make a threat model, your attacker will make it for you. Daisy she thinks about making but then the rabbit is more interesting and now were down the hole. oops too late, should have made the threat model first. Let's hurry up and make it quickly before we get too deep into Wonderland.\r\n- shouldi, wonder about installing packages. Explain how that increases threat surface.\r\n- write about how we extended shouldi and go into technical details.\r\n- Building markdown docs with mermaid diagrams\r\n\r\n---\r\n\r\n## Living THREATS.md\r\n\r\nInstall Alice https://github.com/intel/dffml/tree/alice/entities/alice\r\n\r\nCreate the `THREATS.md` file\r\n\r\n```console\r\n$ alice threats \\\r\n -inputs \\\r\n models/good.json=ThreatDragonThreatModelPath \\\r\n models/GOOD_THREATS.md=ThreatsMdPath\r\n```\r\n\r\nWe made `auditor_overlay.py` which is a data flow which calls the auditor. We\r\nuse `sed` to direct the data flow to run on the path to the threat model from\r\nThreat Dragon used as input.\r\n\r\n```console\r\n$ dffml service dev export auditor_overlay:AUDITOR_OVERLAY \\\r\n -configloader yaml \\\r\n | sed -e 's/auditor_overlay:audit.inputs.ltm/ThreatDragonThreatModelPath/g' \\\r\n | tee auditor_overlay.yaml\r\n```\r\n\r\nGenerate `GOOD_THREATS.md` with auditing overlay.\r\n\r\n```console\r\n$ alice threats -log debug \\\r\n -overlay auditor_overlay.yaml \\\r\n -inputs \\\r\n models/good.json=ThreatDragonThreatModelPath \\\r\n models/GOOD_THREATS.md=ThreatsMdPath\r\n```\r\n\r\nGenerate `BAD_THREATS.md` with auditing overlay.\r\n\r\n```console\r\n$ alice threats -log debug \\\r\n -overlay auditor_overlay.yaml \\\r\n -inputs \\\r\n models/bad.json=ThreatDragonThreatModelPath \\\r\n models/BAD_THREATS.md=ThreatsMdPath\r\n```\r\n\r\nDump out to HTTP to copy to GitHub for rendering.\r\n\r\n```console\r\n$ (echo -e 'HTTP/1.0 200 OK\\n' && cat models/GOOD_THREATS.md) | nc -Nlp 9999;\r\n$ (echo -e 'HTTP/1.0 200 OK\\n' && cat models/BAD_THREATS.md) | nc -Nlp 9999;\r\n```", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-26 Engineering Logs\r\n\r\n- https://en.m.wikipedia.org/wiki/Knowledge_argument \r\n - `alias Alice=Mary`\r\n - grep\r\n - fourth eye \ud83d\udc41\ufe0f \r\n - Scientific process\r\n\r\nTODO Alice gif for black and white to color (the acquisition of the fourth eye, when she steps through the looking glass)\r\n", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-27 Engineering Logs\r\n\r\n> Source: https://pdxjohnny.github.io/terminal-quickstart/\r\n\r\n[](https://pdxjohnny.github.io/terminal-quickstart/)\r\n\r\n- So called \"effective altruism movement\" is not aligned\r\n - What you are now is what you are becoming.\r\n - Same goes for the collective.\r\n- Example threat model scenario\r\n - Imagine a software security researcher named Alice.\r\n - Alice want wants to publicize her scientific research so\r\n as to engage in discourse in the community and further\r\n the [state of the art](https://en.wikipedia.org/wiki/State_of_the_art).\r\n - Why she decided furthering the state of the art in field X\r\n is out of scope for this scenario. It would have been\r\n defined by reward mechanisms and the top level system\r\n context's gatekeeper and priroritizer. Alice may in this situation also be a tenant attempting to escape the sandbox of her top level system context\u2019s multi tenant environment, she (sum of parts, inputs within context) herself a context.\r\n - Alice searches for communities to engage with, forums\r\n chats, activity, any signs of life in the conceptual field\r\n (the train of thought).\r\n - Alice's query yields a malicious attacker controlled community.\r\n - Acceleration in this community's train of thought is\r\n measured to be outside of acceptable impact bounds to her values\r\n / ethics / strategic principles and plans. She determines this by\r\n predicting future state.\r\n - How does Alice know that she should avoid working with\r\n unaligned entities? How did she determine it was detrimental\r\n to her strategic principles when viewed from lifecycle scope?\r\n - Traversal of trust graphs!\r\n - [2022-10-27 IETF SCITT Technical Meeting Notes](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-3983087)\r\n - https://github.com/intel/dffml/issues/1315\r\n - > Just think about it like \ud83d\udc22 turtling in an RTS game or like being zen. You just don\u2019t engage, you dont care, you\u2019re focused with your alys in your ad hoc formed groups\r\n - open source community cross talk / innersource: example set CNCF projects are aligned trees from similar roots.\r\n - you look at other parts of your lifecycle to see how you can position yourself within the multi dimensional strategic field landscape which your top level strategic principles apply to within a context\r\n - wardly maps we\r\n- TODO\r\n - [ ] analysis of kubernetes community handling of aligned events and community response to unaligned actors", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-28 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-29 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-30 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-10-31 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-01 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-02 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-03 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-04 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-05 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-06 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-07 Engineering Logs\r\n\r\n- IPVM meeting tomorrow on content addressable execution\r\n - https://ipfs.tech/\r\n - https://www.youtube.com/watch?v=FhwzEKNZEIA\r\n - https://www.youtube.com/watch?v=rzJWk1nlYvs\r\n - See recent notes on content addressable `serviceEndpoint` defined via dataflows pinned by `did:merkle:`\r\n - https://atproto.com/guides/data-repos\r\n- Zephyr\r\n - What is at the top of the build parameter hierarchy\r\n - They use a Kconfig system\r\n - They could use overlays for this\r\n - Firmware build because it's embedded it more build time configs\r\n - How do we organize storage?\r\n - The Knowledge graph and data flows to link to describe those other flat structures\r\n - Need unique build ids\r\n - `did:merkle:` of serialized Open Architecture\r\n - They only ever run a few subsets of Kconfig parameter sets (a few parameters)\r\n - Parameters are any inputs that can effect the build\r\n - Tool chain version\r\n - Marc's example\r\n - Let's say I care about, git version ,tool chain version, various .config\r\n - https://github.com/zephyrproject-rtos/zephyr/pull/51954#issuecomment-1302983454\r\n - I track those for reproducability (and caching) information\r\n - When I want to generate a content addressable build I take all those JSON files (which are the generic graph serisalization of all the stuff you care about) you concat and checksum (`did:merkle:`).", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-08 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": " # 2022-11-09 Engineering Logs\r\n\r\n- Workstreams\r\n - [ ] Knowledge graph sharing (basics)\r\n - [ ] Provide queriable data via? JSON-LD static file serves to start?\r\n - [ ] Implement initial dumps to chosen format via DFFML plugin patches for first integration.\r\n - [ ] Query via GraphQL-LD (https://github.com/comunica/comunica)\r\n - [ ] Data security from [SCITT](https://scitt.io)\r\n - [ ] Identity from probably github.com/user.keys or keybase or QR code (HSM on phone) or other (overlayed?) methods.\r\n - [ ] Distributed Execution\r\n - [ ] Sandboxing\r\n - [ ] Overlays (next phase parsers) for `policy.yml` to define what are acceptable sandboxing criteria (annotation to the chosen orchestrator, aka the sandboxing method / manager during execution).\r\n - Overlays to parse more types of available sandboxing mechanisms and determine how much we like them or not.\r\n - [ ] Reference implementation of content addressable compute contract execution using Decentralized Identifier, Verifiable Credential, and Decentralized Web Node based for layer 7/8?.\r\n - [ ] Entity Analysis Trinity\r\n - [ ] Static Analysis\r\n - [ ] Need to understand dependencies\r\n - [ ] Living Threat Models\r\n - [ ] `THREATS.md` talks about and includes maintainance / lifecycle health (recommended community standards at minimum). \r\n - Related: https://github.com/johnlwhiteman/living-threat-models/issues/1\r\n - [ ] Open Architecture\r\n - [ ] Conceptual upleveling of dependencies into architecture via static overlay with architecture or overlay to synthesize.\r\n - [ ] Feedback loop\r\n - [ ] Stream of Consciousness\r\n - #1315\r\n - https://github.com/w3c/websub\r\n - https://youtu.be/B5kHx0rGkec\r\n - 12 years, this has existed for 12 years, how am I just now finding out about this.\r\n - we want this but callbacks supported as data flows / open architecture / use webrtc to call back.\r\n - http://pubsubhubbub.appspot.com/\r\n - [ ] Implement Gatekeeper (`get_operations()`/`gather_inputs()`)\r\n - [ ] Overlays / schema extensions for `policy.yml` which prioritizer\r\n understands how to leverage.\r\n - [ ] Implement Prioritizer (`get_operations()`/`gather_inputs()`)\r\n - [ ] Interfaces\r\n - [ ] Keeping GitHub workflows up to date\r\n - Usages of reusables templated and updated on trigger from upstream\r\n or template or within context config modifications.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-10 Engineering Logs\r\n\r\n- Tomorrow\r\n - https://github.com/microsoft/scitt-api-emulator\r\n - https://github.com/microsoft/scitt-ccf-ledger/blob/main/pyscitt/pyscitt/did.py\r\n - https://atproto.com/guides/lexicon#schema-format", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-11 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-12 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-13 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-14 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-15 Engineering Logs\r\n\r\n- Exemplary docs\r\n - https://cve-bin-tool.readthedocs.io/en/latest/CONTRIBUTING.html#running-tests", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-16 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-17 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-18 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-19 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-20 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-21 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-22 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-23 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-24 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-25 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-26 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-27 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-07-18 @pdxjohnny Engineering Logs\r\n\r\n- TODO\r\n - [x] Kick off OSS scans\r\n - Targeting collaboration with CRob on metrics insertion to OpenSSF DB\r\n - [ ] Finish Q3 plans (Gantt chart, meeting templates, etc.)\r\n - Generate template for auto creation to fill every meeting / fillable pre-meeting\r\n- Future\r\n - Engage with Loihi community\r\n - See what we can do here, not sure yet, play with system context / mitigation inference in devcloud?\r\n - https://www.intel.com/content/www/us/en/research/neuromorphic-community.html\r\n - https://download.intel.com/newsroom/2021/new-technologies/neuromorphic-computing-loihi-2-brief.pdf\r\n - https://www.intel.com/content/www/us/en/newsroom/news/intel-unveils-neuromorphic-loihi-2-lava-software.html\r\n - \r\n- References\r\n - https://medium.com/51nodes/decentralized-schema-registry-aa662b8db12b\r\n - https://www.microsoft.com/security/blog/2021/10/06/microsofts-5-guiding-principles-for-decentralized-identities/\r\n - https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/\r\n - Usage of splice\r\n - https://github.com/NVlabs/eg3d\r\n - Seeing from different perspectives, inter domain conceptual mapping, encoded sysctxs alternate mitigations\r\n - https://github.com/robmarkcole/satellite-image-deep-learning\r\n - Knitting together system contexts (Alice could use for integration of various architectures)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-28 Engineering Logs\r\n\r\n- TODO\r\n - [ ] Move this thread to something that doesn't choke machines on load (i.e. Laptop, Phone, etc.)\r\n - grep thread render", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-29 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-11-30 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-01 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-02 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-03 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-04 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-05 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-06 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-07 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-08 Engineering Logs\r\n\r\n> If you carry out every present task by following right reason assiduously, resolutely, and with kindness; if, rather than getting distracted by irrelevancies, you keep your guardian spirit unspoiled and steady\u2026; if you engage with the task not with expectations or evasions, but satisfied if your current performance is in accord with nature and if what you say and express is spoken with true [Roman](https://intel.github.io/dffml/main/news/0_4_0_alpha_release.html) honesty, you\u2019ll be living the good life. And there\u2019s no one who can stop you doing so! [Marcus Aurelius, a Self Sovereign Individual, less so were his subjects, STAY SELF SOVEREIGN!]\r\n\r\n[](https://pdxjohnny.github.io/redpill/)", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-09 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-10 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-11 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-12 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-13 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-14 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-15 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-16 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-17 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-18 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-19 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-20 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-21 Engineering Logs\r\n\r\nTransparency logs inbound. [Values stream mapping imminent.](https://github.com/intel/dffml/blob/alice/docs/tutorials/rolling_alice/0000_preface.md#volume-4-alice-and-the-health-of-the-ecosystem)\r\n\r\n> For everything that is hidden will eventually be brought into the open, and every secret will be brought to light.\r\n\r\n", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-22 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-23 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-24 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-25 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-26 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-27 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-28 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-29 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-30 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2022-12-31 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-01 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-02 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-03 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-04 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-05 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-06 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-07 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-08 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-09 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-10 Engineering Logs\r\n\r\n- IETF template https://github.com/martinthomson/internet-draft-template", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-11 Engineering Logs\r\n\r\n- https://github.com/w3c-ccg/traceability-interop\r\n - > **TODO** Verifiable Credentials for Supply Chain Interoperability Specification for HTTP", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-12 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-13 Engineering Logs\r\n\r\n- https://w3c-ccg.github.io/traceability-interop/openapi/\r\n - https://github.com/intel/dffml/pull/1273/files\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - https://github.com/intel/dffml/blob/alice/schema/\r\n- https://mtngs.io/dffml/weekly-sync/_av3pS8DT04.html#s430639\r\n - Remembered that these transcripts exist for training Q&A models\r\n- [Weekly Sync: 2022-04-15: Didn't know it yet but OA DID resolver](https://www.youtube.com/watch?v=_av3pS8DT04&t=6232s)\r\n- [Weekly Sync: 2022-04-15: How we add layers to the software stack](https://youtu.be/_av3pS8DT04?t=458)\r\n - Manifestation board indeed... I just realized the date, guess what the next day was?\r\n - https://github.com/intel/dffml/blob/alice/docs/tutorials/rolling_alice/0000_preface.md#references", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-14 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-15 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-16 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-17 Engineering Logs\r\n\r\n- https://github.com/readme/featured/defining-gitops\r\n - > GitHub\u2019s Octoverse 2022 identified infrastructure as code (IaC)\u2014which alongside platform engineering and continuous integration and continuous delivery (CI/CD) form the foundation for GitOps\u2014as one of the three big trends to watch for in the year ahead.", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-18 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-19 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-20 Engineering Logs\r\n\r\n- https://github.com/cncf/tag-security/blob/main/supply-chain-security/secure-software-factory/secure-software-factory.md", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-21 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-22 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-23 Engineering Logs\r\n\r\n- https://www.si.edu/openaccess/", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-24 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-25 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-26 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-27 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-28 Engineering Logs\r\n\r\n- https://www.chainguard.dev/unchained/understanding-the-promise-of-vex", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-29 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-30 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-01-31 Engineering Logs\r\n\r\n- https://www.chainguard.dev/unchained/accelerate-vex-adoption-through-openvex\r\n - /acc/ \ud83d\udee4\ufe0f\r\n- https://datasette.io/plugins/datasette-dashboards#user-content-usage", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-01 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-02 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-03 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-04 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-05 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-06 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-07 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-08 Engineering Logs\r\n\r\n- https://community.intel.com/t5/Blogs/Tech-Innovation/open-intel/Meet-a-New-Voice-for-Open-Source-Open-at-Intel-Podcast/post/1449811\r\n - > The series starts by laying some groundwork with topics like threat modeling and software supply chain security, then builds on that to discuss interesting projects and learn about organizations doing the work to push open source security forward.\r\n - https://openatintel.podbean.com/e/threat-modeling-down-the-rabbit-hole/\r\n - [episode-1-promo-slide-threat-modeling-down-the-rabbit-hole](https://user-images.githubusercontent.com/5950433/217665988-9fabfd68-786b-444e-9c69-db5b333d9a10.png)", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-09 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-10 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-11 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-12 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-13 Engineering Logs\r\n\r\n- [The Agora: a Knowledge Commons](https://anagora.org/go/agora-chapter)\r\n- https://gitlab.com/fedstoa/moa\r\n- https://github.com/mastodon/mastodon/releases/tag/v4.1.0\r\n- https://notes.knowledgefutures.org/pub/belji1gd#decentralizing-context", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-14 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-15 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-16 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-17 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-18 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-19 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-21 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-21 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-22 Engineering Logs\r\n\r\n- \ud83d\udee4\ufe0f\ud83d\udee4\ufe0f\ud83d\udee4\ufe0f\ud83d\udee4\ufe0f\ud83d\udee4\ufe0f\ud83d\udee4\ufe0f\ud83d\udee4\ufe0f\ud83d\udee4\ufe0f\r\n\r\n", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-23 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behind the correct implementation of the `sort_keys=True` -> CBOR situation\r\n\r\n- References\r\n - [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171)\r\n - [Alice Engineering Comms: 2022-11-28 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4250447)" | |
| } | |
| ] | |
| }, | |
| { | |
| "body": "# 2023-02-24 Engineering Logs", | |
| "replies": [ | |
| { | |
| "body": "## 2022-11-28 @pdxjohnny Engineering Logs\r\n\r\n- https://github.com/pdxjohnny/use-cases/commit/36b4578a8ae7978f55c10e4e0a2eabd88788da27\r\n- Reminder (on/off chain smart contracts! ref: https://github.com/intel/dffml/blob/alice/docs/arch/0009-Open-Architecture.rst it sounds block chainy but it's just a cyptographiclly linked list created ad-hoc with your neighbors! [grand scale speaking ;])\r\n - https://github.com/intel/dffml/blob/c7dc8985fdde61459017d3fb39cb19de1f7ece2b/docs/arch/0009-Open-Architecture.rst#L32-L36\r\n- From 2022-11-17 Mark Foster on Twitter https://twitter.com/mfosterio/status/1593094082838290433\r\n - > Proof of Trust On The Internet (https://futureinternet.io)\r\n >\r\n > We are seeing repeats of behavior on centralized false ledger systems.\r\n >\r\n > I\u2019ve had so many people calling me and asking about verification of decentralized ledgers ever since the fiasco of FTX and how to create systems to prevent Fraud.\r\n >\r\n > We should utilize cryptographic Merkle data structure proofs with open vocabularies to verify ownership, control of data and the internet of value (IOV)\r\n >\r\n > - Presentation Exchange DIF Foundation\r\n > - https://identity.foundation/presentation-exchange/\r\n > - Linked Open Vocabularies\r\n > - https://schema.org/InvestmentOrDeposit\r\n > - Web Authentication binded to a Human Input Device (HID) like a finger print scanner on your phone\r\n > - w3.org/TR/webauthn-2/\r\n > - Verifiable Credential W3C Recommendation\r\n > - https://www.w3.org/TR/vc-data-model\r\n > - Merkle Tree DAG CIDs\r\n > - https://docs.ipfs.tech/concepts/merkle-dag/\r\n > - > A Merkle DAG is a DAG where each node has an identifier, and this is the result of hashing the node's contents - any opaque payload carried by the node and the list of identifiers of its children - using a cryptographic hash function like SHA256. This brings some important considerations:\r\n > > - Merkle DAGs can only be constructed from the leaves, that is, from nodes without children. Parents are added after children because the children's identifiers must be computed in advance to be able to link them.\r\n > > - Every node in a Merkle DAG is the root of a (sub)Merkle DAG itself, and this subgraph is contained in the parent DAG.\r\n > > - Merkle DAG nodes are immutable. Any change in a node would alter its identifier and thus affect all the ascendants in the DAG, essentially creating a different DAG. Take a look at this helpful illustration using bananas (opens new window)from our friends at Consensys.\r\n > >\r\n > > Merkle DAGs are similar to Merkle trees, but there are no balance requirements, and every node can carry a payload. In DAGs, several branches can re-converge or, in other words, a node can have several parents.\r\n > >\r\n > > Identifying a data object (like a Merkle DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier, or CID. (John: Or DID! [Alice Engineering Comms: 2022-11-08 Engineering Logs](https://github.com/intel/dffml/discussions/1406?sort=new#discussioncomment-4083171))\r\n > - https://proto.school/merkle-dags\r\n > - Decentralized IDs (DID) W3C Recommendation\r\n > - https://www.w3.org/TR/did-core/\r\n > - Secure Interoperable Wallets\r\n > - https://w3c-ccg.github.io/universal-wallet-interop-spec/\r\n > - https://openwallet.foundation\r\n > - There are many moving parts but the methodology research has been done. let\u2019s build on top of the ecosystem of the future.\r\n- TODO\r\n - [ ] Play with them there context aware Markov chains! (etc.)\r\n - Maybe useful https://github.com/karpathy/minGPT/blob/master/mingpt/model.py\r\n - [ ] https://github.com/intel/cve-bin-tool/pull/2384\r\n - CD and cross plugin/project analysis is dependent on this as a dependency of our\r\n standard interface / documentation aka manifests. Also the vuln updating (goes with\r\n the teritory, this is what we are using to ride on top of as comms channel).\r\n - https://github.com/intel/dffml/blob/alice/docs/arch/0008-Manifest.md\r\n - [ ] UCAN/IPVM need to review :eyes:\r\n - [ ] https://github.com/ipvm-wg/spec/pull/8#issuecomment-1328355077\r\n - https://github.com/ipvm-wg/spec/blob/initial-job-spec/README.md\r\n - [ ] https://github.com/ucan-wg/invocation/pull/1#issuecomment-1327979869\r\n - [ ] https://github.com/fission-codes/spec/tree/main/dialog\r\n - [ ] https://github.com/ucan-wg/spec/issues/30#issuecomment-1321511824\r\n - > Brooklyn: In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs?\r\n - [ ] Ping Marc about Zephyr stuff (POC? :)\r\n - [ ] We should move DFFML flows to the IPVM style once available, or a configloader loadb/dumpb or something (dataflow?) for the time being\r\n - [ ] https://github.com/intel/dffml/issues/1425\r\n - [ ] Really need to do the chains of contexts stuff which will also double as\r\n the `alice shouldi contribute`. There is likely an issue with the current\r\n `source.update()` just merging over the old data, which means if something\r\n is no longer \"qualified\" or similar, that won't get overwritten, we want to\r\n have a `source.update()` mode which serializes the train of thought / pre updates.\r\n This likely also requires updates to `record.evaluated()` to create new instances\r\n of record data. Might be useful for when `record.data.key` needs changing such\r\n as when a `GitHubRepoID` is the key and it should be `record.feature(\"repo_url\")`\r\n or something similar.\r\n - https://github.com/intel/dffml/blob/alice/entities/alice/alice/shouldi/contribute/cicd.py\r\n - 90d5c52f4dd64f046a2e2469d001e32ec2d53966\r\n - The instructions unfortunately I don't think work from this commit message, because it's the same main package, we need to setup the lightweight package stuff as was done here\r\n - https://github.com/intel/dffml/blob/1513484a4bf829b86675dfb654408674495687d3/dffml/operation/stackstorm.py#L306-L368\r\n - https://github.com/intel/dffml/issues/1418\r\n - [ ] `Record` feature data should retain dataflow `Input` type data if possible.\r\n - Ideally we enable graph traversal, once again only need one link deep if data\r\n is available offline. Try resolution via DID, CID, OA, etc.\r\n - We should also support serialization of only the latest system context /\r\n the state of the art for a train of thought / chain of system context.\r\n - State of the art could be defined by any set of strategic plans.\r\n - :bulb: Unification of Record / DataFlow / once working system context\r\n infra plus UCANs/DIDs/DIDs/IPVM/OA on chain should allow for cohesive / cleaner\r\n and more consistent context capture / unbroken chains for both data and compute.\r\n - And this is why we've started planning before implementing folks, woohoo!\r\n - Measure twice cut once.\r\n\r\n---\r\n\r\nThank you expede! I'm hoping to dive in this week to look at all your recent developments.\r\n\r\nPining marc-hb, Brooklyn is the brains behi |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment