KERI Dev Focus Calls

Bi-Weekly Meeting Agenda and Minutes

Schedule: Every other Thursday opposite the KERI Educators call Time: 8:00 AM MST (Salt Lake) / 3:00 PM BST (London)

Quick Links

CESRide repo | Parside repo | IETF-CESR spec
Bi-weekly Zoom Meeting Link
CESR Roadmap | KERI + ACDC Roadmap
KERI Documentation

2023 Meetings

2023-05-18 #18

Agenda

1. KERIde, CESRide Storage Interface for accessing KELs and TELs.
   • Example: self.store.get_latest_transaction_event(&vcid)?;

2023-05-11 #17

Zoom Link
Passcode: %Yz*1!7b

Agenda

1. Thanks Jason for finishing CESRide!
2. Meeting combination and transformation
3. Monorepo?
4. Parside PRs 2 and 5
5. Moving CESR into a KERIide repo

Notes

Kevin: We passed what we originally intended to be in CESRide. They are not the primitives though they are how you use the primitives.

Jason: We could have code verifying KELs, TELs, and ACDCs in issues and then go through them in calls.

Kevin: general proposal is to repurpose this call. KERI dev call every week. KERI and ACDC spec calls more focused on standards work for now.

Moving CESR into a KERIide repo was not a lot of work, though was instructive. We need to get something done and released with KERIide, at least a 0.1.0.

Monorepo a good idea? We were finding it was difficult to get some of the things done across the barriers of the library. Advantages

1. dev writing KERIde you have less barriers to getting data moved around. You don't have public interfaces to restrict your access.
2. from the consumer side it is easier to use which import and just select what tools you need from that import. Things can get difficult if you don't use high discipline with monorepos.

Depends on your use case. You can change the way it builds so it builds less or more of the library depending on what you need.

KERIde is starting as a monorepo.

Wait until Jason has ported his work to KERide and then archive CESRide and put a big note on the top that the code has moved and is no longer supported.

The reason it was hard for some to write PRs for Parside without understanding the KERI code that used the parsing code it was really challenging for them.

Either do both sides of an integration or even a full stack integration to really understand how things connect together.

Graduated Disclosure is more of an application level concern.

Congratulations to Jason Colburne for finishing CESRide! This is a big accomplishment for the KERI and ACDC community.

2023-04-27 #16

Zoom Recording
Passcode: Bv8uG+!W

Agenda

1. Creder work 147
2. IIW review, announcements
3. Whiteboarding session review 3. distinction between cesride, parside, and signifide
4. State of FFI moving forward
5. Latest work - dalek 2.0 update, WASM compilation
6. Any other updates

Notes

Attendees: Kent Bull

Jason: Added code for Creder into issue 147. All that is needed right now is to port the KERIpy tests for this.

Jason: has written a bunch of parsing code. It was really simple, two files, so is all of the Parside code from DSR really necessary?

Signifide, parside, cesride distinction: Kevin: Visibility into the CESR package was changed. Changing to "pub crate" to expose things for usability in Signifide.

Jason: impetus for 0.6.0 is for the DSR folks and for Qui.

Kevin: If we get creder in there we can do 0.6.0. Creder really belongs in Signifide and Parside

Jason: Creder and Serder don't need to be in Cesride.

Signifide is to support signing at the edge. Minimally sufficient KERI

• generate keys and events and sign them on the client.

Creder and Serder are JSON structures at the moment.

Parser

Create a special topic call for discussing the Rust module diagram.

• veride (minimal consumption for verification)
• parside (consume)
• eventide (KERI)
• acdcide (ACDC)
• cesride (definitions)
• signifide (produce - minimal production for signing at the edge)

One of the most confusing thing about the events is the attachments because they are pure CESR. All the different types of attachments are different types of counters. There may be nested counters.

The hurdle to getting started was trying to understand what KERI was doing and why things were important.

Jason recommends starting with the parsing code. A message is only a Creder or a Serder. A Creder is an ACDC, a Serder is a KERI key event. keripy/src/keri/core/parsing.py:L974 (ish)

KERI is just a protocol for building and parsing messages.

2023-04-13 #15 - skipped, IIW prep

No recording for today since we cancelled the meeting.

Agenda

1. Plan for IIW, a couple sessions, which topics
2. Check on PRs for moving things between CESRide, Signifide, and Parside

Notes

No notes for today as we cancelled the meeting. Thanks to Steven Milstein and Petteri Stenius for showing up.

2023-03-30 #14

Zoom recording
Passcode: S%iTLL5E

Agenda (Remember to record the meeting! – and delete this comment)

1. SECp256r1 and SECp256k1 work status
2. FFI status report and direction
3. Parside PR merge status
4. Cryptographic Primitive implementation Milestone Report
5. what 0.4.0 is
6. Current open issues (some can be closed!)

Meeting Minutes

The SECP256r1 work is very timely for GLEIF. "r1" is the curve that is in the HSMs For Apple Secure Enclave/Hardware Security Modules.

• 0.4.0: secp256k1 and r1 support and WASM bindings, general cleanup.
  • Added two simple functions for checking whether Matter was transferable or digestible.

Vasily Suvorov mentioned he has a working CESR parser in Elixir. Possibly use https://github.com/rusterlium/rustler to bridge our work to his.

• SECP256k1 was initially not using a randomized signature and now both k1 and r1 is using a randomized signature.

  • If using CESRide and want to avoid correlation when using the signing methods without a nonce then you should use one of the ECDSA curves rather than EDDSA curve.
  • Found when Phil and Jason were doing testing, one was deterministic, one wasn'.

• FFI status report and direction

  • Trying to do an integration with KERIpy.
  • PyO3 is nice and works well, though it might not translate as well to parside.
  • We should take the KERIpy tests from coring.py and run them on CESRide.
    • half an hour to an hour to learn how to make a PyO3 object.

• Parside PR merge status

  • Still on hiatus
  • We never started the JNI work (Java Native Interface?)
  • Justification for separation of the primitives is the reason we initially made Parside. Worth considering.
    Maybe we made the wrong decision.
  • Creder in CESRide or Parside?
  • We are going to hit this time when there are common things used in Signifide and Parside. Does that mean they need to use a common library?
  • The name of CESRide is not technically correct though it is a useful library with many things.
  • Jason has an implementation of Creder.
  • Being pedantic we would do a fourth library above CESR with Creder and Serder

• Closing issues!

  • closed 118, 116, 98, 94

• Reference PRs for uniffi work

  • PRs #82 and #106

• Over the next week with PRs from

  • It will be good to have a good understanding of what
  • Three buckets
    • Signifide (which ones are required for this?)
    • CESRide (same question here)
      • default location right now for something we don't have a good place for.
    • Parside (same question here)
  • Whiteboarding session at IIW for those who have used CESRide and the others to figure out or finalize what goes where.
    • Want to get Phil's opinion from the Python side.

• code new to Jason

  • fn something(argument: impl Trait) { }
  • Ie: fn messagize(sadder: impl Sadder, …) { … }
  • This is how you pass an instantiated object that implements a trait inside a function. You don't have to pass a reference.
    You should use the & ampersand and pass the object, though the point is that things were hard to do with the "dyn" keyword.
    "dyn" is for when you are combining traits in the abstract, not in the concrete.

2023-03-16 #13

Zoom Recording Link
Passcode: pNm=Ai55

Agenda

1. Kevin will propose 0.2.0-alpha release
2. Kever, test code, signing an event

Notes

• usage of the anyhow error handling library to provide easy idiomatic error handling without having to resort to boxed errors.

  • See this commit

• SECP256-r1

  • The library documentation should state that usage of SECp256r1 makes for random signatures.
  • EDDSA25519 is not random in order to make it deterministic.

• Zeroization PRs

  • zeroize
    • When you have a private key you need to erase the contents of that key from memoryas soon as you use it.
    • The shorter the duration something is memory the lower the vulnerability it will be exposed.
    • It takes the salts and the private keys (seeds) we use in KERI and frees the memory as soon as the references are dropped.
      • On Drop you can implement a handler that does whatever you want so you can fill it with zero.
      • Zeroize provides convenience methods to provide for things like this.
    • CESRide doesn't support asymmetric algorithms right now. May in the future.
  • base64 zeroization.
    • When the base64 library copies data then it needs to be zeroed out.
    • Allocate the buffer ahead of time. b64_engine::URL_SAFE.encode_slice(&buffer, &mut b64_vec)
    • Usage of raw.zeroize(); is necessary as opposed to Zeroizing::new(vec![...]) when the slice comes in through function arguments.

• data! macro to dat!

  • This was to make it easy to have the data module exportable and consumable by library users.

• release is up to 0.3.0 now.

• kever, test code, signing an event

  • QUI integrated CESRide into one of their libraries.
  • Put PyO3 on top of it and it works in Python
  • Have another impl with CABI and ProtoBufs
  • Next steps: redis-backed hot-memory storage for vaults. Indexed by a prefix. Ephemeral vaults loaded into a Redis store for custodial signing.

• Parside: Jason would like to see Parside taken care of and open PRs merged into something usable so we can parse CESR events and data.

  • The two open PRs are:
    • #3 Initial parser implementation returning generic enum instead of groups
      • This one can't be merged
    • #2 Initial parser implementation including definitions for Groups

• FFI layer pause

  • Using SwiftBridge didn't work well for Jason. PyO3 bridge works well for Jason. PyO3 doesn't do enums well though that's OK since CESRide uses constants rather than enums.
  • Porting tests means massaging them into the new CESRide API.
    • For example, some of the massaging needed would be that something that used to be an enum in KERIpy is now a constant string.
      • We would need to reference the CESRide constant in all the places that KERIpy used to use the enum value.
    • This is an FFI committment and needs to involve Kevin Griffin.
    • Kent will ask Kevin what he sees as the next step for FFI analysis.
    • Jason has finished the FFI analysis for QUI and is moving forward. He ended up conditionally compiling includes.
      • Example: If feature "x" is enabled, include this file. Otherwise include that file.

• Milestone on Primitive Implementations

  • Most of the work remaining to be done to get a working ecosystem is in things like Parside and maybe a KERIide or ACDCide.
  • Most of the CESRide works done.
  • Kent will follow up on the status of implementation and prepare report.
    • Include a note on the abstraction of CESR code tables into a text file, .cesr file, and so forth.

• Top-down architecture jaunt

  • From an application perspective, why am I concerned about CESR. Why would I be considering using CESRide and Parside.
    • As an enterprise application developer security is on my mind almost never.
    • Security conscious application development is financial development or on-chain dev.
    • There are multiple types of secure development.
      • Example: chip manufacturers, embedded chips with a feature unlocked with a CERT uploaded to the chip.
    • The type of applications KERI is suited for are decentralized applications.
      • KERI manages your keys on your device for you in a secure way.
      • In situations where users benefit by not being gatekept by administrators.
      • All your data stays with you.
  • Top layer of the KERI application stack exposes functionality for trust and reputation.

2023-03-02 #12

There is no recording for this meeting. We forgot to hit the record button.

Agenda

1. What is the Parside interface
2. Pausing FFI development while we investigate other FFI options. See Kevin's comment on Parside's FFI
3. Example inception code in serder.rs
4. Signifide?
5. Artem's PR 95 Expose methods for parside implementatin
6. Versioning
7. CESR Code Tables outside of a programming language

Minutes

FFI Layer definition in the Terms Wiki

Parside Interface and pausing FFI development while we look at other options:

• Doing a lot of work to avoid having the FFI have a larger impact on the API than it needs to.

• Ran into issues with the UDL. Concessions we would be making to the API in CESR with UniFFI.

  • See the following PRs for a discussion of the issues:
    • 82 uniffi
    • 106 UniFFI bindings for cesride
  • Selling point of UniFFI:
    • You use UDL and get a bunch of lunches for free (kind of).

• Wants to take a look at the Rust JNI

  • Spruce uses Rust JNI
  • Spruce sponsors a lot of the DID libraries in Rust

• Kevin talked with Daniel Hardman out of band.
  He is okay with the suggestion to pause and look at other options as we look forward

• Kevin asking GLEIF to sponsor FFI option exploration.

• What are the priorities of the languages being addressed?

  • What does UBISecure want?
  • Signify is used for signing at the edge.
  • GLEIF wants Swift bindings
  • JVM/Android needs bring Java or Kotlin

• Libsodium is deprecated in rust so we use other libraries.

• Add note to CESRide README regarding cryptographic libraries used.

  • We should create an issue about this.
    Saying these are the dependencies we use and the assumptions we make.

• Swift Bridge may be used.

Signifide library:

• at some point it will be separated out. For now we can put things like incept inside Cesride.
• Maybe we could hold off on publishing a 1.0 Cesride until we get things separated out and
  one FFI implementation in one other high level language, likely Java.

Milestone nearly reached:

• Most of the types

Versioning:

• We have been moving very quickly, though at some point we will want to put together something
  for candidate releases and things like that.
• At this point we have been doing version bumping. At v0.1.4 today
• Next one could be 0.2.0-alpha
• Much faster than quarterly. Every two weeks could be reasonable.
• Getting one out once we get #95 merged is likely the next version.
• Tags list:
  • alpha
  • beta
  • rc#
  • Prod has no tag
  • Example: v0.2.0-alpha
• Decision: we will use tagging similar to the above

CESR Code Tables outside of a programming language:

• Petteri wrote the cesr-schema in cesr-decoder to represent the code table in a JSON format.
  It is a work in process: https://github.com/psteniusubi/cesr-decoder/tree/main/cesr-schema
  • This is partially generated from KERIpy and partially manually maintained.

2023-02-16 #11

Zoom Recording
Passcode: X2y.D3%^

Agenda:

1. RsTest PR - Parameterized Testing: https://github.com/WebOfTrust/cesride/pull/71/files
   1. Keep all PRs in the future in this format
2. FFI PR - UniFFI: https://github.com/WebOfTrust/cesride/pull/82
   1. Take a look and play with each language to test it out
   2. Languages: Swift, Kotlin, Ruby, Python
3. Classes into Traits:
   1. PR 75: Matter into Trait: https://github.com/WebOfTrust/cesride/pull/75

Attendees

@kentbull

Notes

1. Rstest
2. UniFFI 3. There are some rough edges. Enums
3. Traits
4. Modularizing Code Tables
   • A Rust Enum is obviously not modular. It isn't an abstraction.
   • We need a code table abstraction.
   • Can we have the code tables in a format that is not a programming language?
     • Elements of a Code Table
       • Code Table (group of codes)
       • Code (a specific code)
       • Genus, Version
       • Sizage
         • Hard Size
         • Soft Size
         • Lead Pad Size
         • Full Size
       • Hardage
   • There is a subset of codes from the code tables that are not in the code tables.
     • It is a strong binding from a concrete class to a specific set of
       entries from a code table. This binding must be severed in order to
       modularize the code table abstraction.
   • Should the idea of a code table or code table entry be just a string that is
     passed in that becomes a concrete codex entry.
5. Testing Types 6. Unit Tests 7. Behavioral Tests - effectively indicating how Parside works
6. CESR parsing: Example from Provenant: https://cesrview.provenant.net/ 7. Petteri also wrote something: source
7. Parside implementation proposal by Dmitry and colleague created in two ways,
   One is with generics
   Other is
   • We need to define the Parside interface. Data structures it can return. Functions we can call.

2023-02-02 #10

Zoom recording link

1. Parside should be concerned with parsing group codes, cesride concerned with prasing primitives
2. Parside will contain a count code at the beginging of the stream, each cesr primitive is self framing, JSON is not hence the Version string.
3. Parside could "load" the tables it supports for dynamically loaded code tables
4. Parside could look at how/if we can return an
5. interator/generator
6. https://docs.python.org/3/extending/extending.html
7. https://github.com/WebOfTrust/ietf-said
8. https://github.com/trustoverip/acdc/wiki/self-addressing-identifier

Glossary items created

• parside
• cesride
• strip-parameter
• version-code
• version-string
• sniffer

Feel free to push the edit button and amend / correct text

Agenda

1. Design of the FFI layer for CESR.
2. Dmitry has code he has pushed. Let's review that. (Been postponed to next meeting)

2023-01-19 #9

Zoom Meeting Link
Passcode: +0cL#2DW

Agenda

1. Core API design for CESR.

   • English Semantic Naming Conventions

2. CESR - The Future

3. Contributing to CESR

4. Rename Vote

   • Formal vote on Name and Repositories

5. Chat with Sam. Naming. How did he come to the names he did in KERIpy?

   • Wanted names that are disparate from existing names in the software space. SEO, no baggage, new meaning, blank canvas.

Notes

English Semantic Naming Conventions

1. English words have many operators. Can be used to create valid words that are not in the dictionary. English has the issue of polysemy. 6 million words in the English language, many relatively unused, and without baggage. Keep KERIpy more readable with short, evocative names. Short, but descriptive names. 50 to 100 suffixes can be used to convert a noun to an adjective.
   • book: C Elements of Style: The Programmer's Style Manual for Elegant C and C++ Programs
   • rules
     • -er object instances that do stuff - manager, parser, kever
     • -ery factory classes or classes that manage other classes
     • Matter classes are qb64 representations
     • -s plural are list of things.
     • Plural noun for plural name, singular noun for singular name
     • Example:
       • siger - creates signatures
       • sig - would be qb64 repreesentation of a signature
       • sigs - would be a list of signatures

CESR Future

• The amount of cryptographic primitives to be added to CESR exceeds the amount of primitives currently in CESR. There is plenty of work to do in both KERIpy and CESRide/Parside.

• Native CESR KERI Events Means new codes to support lists, config trait string as CESR and version string as CESR. Already have SN as Number and the seals as fixed field.

• Native CESR ACDC field maps (so now we have CESR native equivalent of JSON, CBOR, or MGPK)

• New CESR code for list of two tuples (which can represent an ordered dic, or json object, or field map etc).

• CESR code for version string

• CESR code for edge operators (ACDC Native CESR)

  • ACDC is not fixed field, KERI Events are. Payload, attributes, rules, etc.
  • Need CESR equivalent to a dict (ordered list of tuples). Will add a count code for this. Supports field maps, etc.

• Refactor group codes to do pipelining fully, reorder group codes so that pipeline and generic codes are first (so they don’t change for different protocol tables) and then structure specific codes are appended on a first come first served basis

• Add CESR codes for variable length assymmetric encrypted ciphers.

• Add CESR primitives for symmetric encrypted salts, and private keys/seeds

• Add CESR codes for variable length symmetric encrypted ciphers.

• Add CESR code or codes for UDP header of UDP envelope of segment of CESR stream.

New Architecture

In order to keep the cognitive overhead low and to cleanly separate concerns two things are happening in the WebOfTrust Rust CESR implementation:

1. Use names and code architecture similar to KERIpy and Signify where practical.
2. Separate out the type mapping and parsing concerns to two separate libraries (CESRide and Parside, respectively).

Contributing to CESR

• Look for "Help Wanted" tag in the CESRide repo. Most of the 11 or 12 issues are simply to look at the Python code, the test, and go write the test
• Parside: Parser needs to know the code tables so it can pull it off the stream though it just pulls those bytes off and then sends it to the CESR library to convert the bytes to the raw, in-memory format.
  • Parser coupled to the code table interface.
  • The version code tells you which code table to load so when you are pulling bytes from the stream you know which primitive from which table to use.
  • Every code table must implement the version code.
• KERI and ACDC are protocols that can use CESR parser primitives and map them to implementation-specific types. This could be used for other protocols like RATS (Remote ATtestation procedureS)

Formal Vote on Name and Repositories

We did a voice vote with all community members on the call and were all in the affirmative for the following proposal:

1. CESRide and Parside are the new names for the Rust implementation of CESR for both the byte primitives to raw data structure mapping library and the raw parsing library.
   • CESRide is the library containing the logic to map a properly encoded byte stream to a raw, in-memory type. This
   • Parside is the library containing the logic to read a byte stream, detect data structures from the CESR code tables, and pull the correct number of bytes for each primitive in a unit to be handed to the CESRide library for mapping to the raw type.
2. WebOfTrust CESR work will continue in two new repositories, CESRide and Parside.
3. WebOfTrust CESRox repository will be archived to eliminate any ambiguity.

New Repositories

CESRide Parside

2023-01-05 #8

Zoom Recording Link Passcode: Ny9r@cs1

Agenda

1. Repository naming strategy moving forward including any potential name releases or transfers to the WebOfTrust organization.
2. Licensing strategy clarification moving forward.
3. Contribution strategy moving forward for Rust implementations of CESR (WebOfTrust as the upstream or dual upstreams with WoT and THC)
4. KERIox Update from conversation with Charles Cunningham
5. Dmitry's opinion

Notes

1. Naming
   1. Will conduct a poll in the #cesr channel - Kevin
   2. Will have a live vote on the next CESR call
   3. Name suggestions:
      • CESRust (Steven Milstein)
2. Licensing
   1. We acknowledge the fork. It is Apache 2.0 for WebOfTrust, EUPL 1.2 for THCLabs
3. Contributions
   1. With respect to the IP that is contributed to each repo be very careful on the IP that is shared. Completely avoid verbatim copy and pastes.
4. KERIox convo
   1. Make make a DB interface to make KERIox use LMDB like KERIpy.
   2. Other notes Kent will assemble and put into the Slack channel
5. CESR design for Provenant
   1. Has a design for the core API, assembling things.
   2. The foreign function interface (FFI) for other languages to use CESR is the current focus of the design.

We could ask Sam Smith to come and do a review of CESR, the CESR For Muggles talk, for the CESR Rust implementation group.

Sam’s slides for CESR for First Year Wizards Is here:

• https://docs.google.com/presentation/d/12nX_IIPp5xw8qAxhZy-ae2aWYytYQmFBbB9K3PcVhqQ/edit#slide=id.ga411be7e84_0_0

We will ask Sam to talk next time.

Naming conventions - see docstrings in classes.

• Example: Matter

Could make a listing of existing classes and functions and their names.

2022 meetings

2022-12-22 – SKIP – Christmas Holiday

2022-12-08 #7

Zoom recording Link Passcode: @^f51KEa

Agenda

1. Updates
   1. Dimitry's update from Provenant in Slack
   2. Pull requests in the last two weeks
2. New Business 3. Architecture diagram issue 14 4. Test cases issue 13 5. Dmitry will add more issues on what he sees CESRox needs
3. Adjourn

2022-11-24 – SKIP – Thanksgiving in the US - Holiday

2022-11-10 #6

Zoom Recording Link Passcode: UCw###a6

Questions Henk:

• status of keriox repo under weboftrust
• sequence of going through .rs files
  • recommended to look at tests in this order: derivation, preview, event, event_module, processor, and finally keri/test for the test signing
  • in Rust, convention is to include unit tests inside the source file (sometimes within a mod)
• terms brief definitions have been synced to https://github.com/trustoverip/acdc/wiki? Yes, because the brief defs stem directly from the central database Terms-WOT-manage

Agenda

1. Updates
   1. Review KERIox tests from last week
2. New Business
   1. IIW CESRox presentation draft review 2. Story: Licensing, Coordination with existion implementations, learning Rust, CESR differences compared to other protocols, why not keripy
   2. Edyta update on THC repository with regard to CESR 4. Updated encoding scheme so events are compatible with Keripy 5. Preparing for CESR to be removed from KERIOX. errors_ref and split_cesr branches have the most recent work
   3. Review KERIOX tests? 6. Start with the processor/tests.rs
3. Future business 5. First KERIOX diagram: Component Diagram of both the WOT repo and THC repo 5. Review Keripy class diagram 3. Review how code tables are represented in Python

2022-10-27 #5

Zoom Recording Link Passcode: e?$fP5fG

Attendees

Kent Bull Henk van Cann Trent Larson Stephen Milstein

Agenda

1. Updates
   • Kent: learning rust, made the KERI Daemon
2. New business
   • Henk: How do we know if something is a KERI implementation?
3. Current Two Week Focus
   • Kent: finish Rust book, read the following two tests:
     • src/keri/tests.rs:16 test_direct_mode
     • src/keri/tests.rs:174 test_qry_rpy
   • Trent: run tests (higher goal: understand them)
4. Adjourn

Meeting Notes

Henk: How do we deal with beginner questions in a friendly, productive way?

Trent: Since we are early enough we get to define the culture.

Henk: criteria for what is a (proper) KERI protocol implementation: MUST,SHOULD and COULD haves, first draft:

• MUST :
  • All of these IETF-draft implemented: KERI, ACDC, CESR, OOBI, SAID
  • all data formats
  • Witness / watchers
• SHOULD:
  • Duplicity reconciliation: Jurors
• COULD:
  • All optional / scalable protocol design and authentic web requirements

2022-10-13 #4

Zoom Recording Link Passcode: re?Eb5pf

Agenda

1. Updates
   1. Update from Kent on last two weeks
   2. Simple KERI Architecture Diagram
   3. Update from Henk
2. New Business
   1. Architecture
3. Next meeting Goals
   1. Presentation on keripy
   2. Diagram of keripy classes
   3. How are code tables represented in Python? How do we want to represent them in Rust? How does KERIOX do it now?

Attendees

Kent Bull Daniel Hardman Henk van Cann Edyta Pawlak Joseph Hunsaker Trent Larson Stephen Milstein

Minutes

Henk Update

• Has been studying CESR. CESR is getting more complicated.

Kent Update

• Keripy very instructive
• keripy/src/keri/core/coring.py
• Nom Creator Geoffrey Couprie description video: https://www.youtube.com/watch?v=b7M8Uj7k_0Y
• 1Password Youtube tutorial on writing a parser in Nom: https://www.youtube.com/watch?v=zHF6j1LvngA&t=1389s
• Different shape for publishing action on diagram

Edyta update

• Look for tests containing signed_event_stream(s: &[u8]) -> nom::IResult<&[u8], Vec<SignedEventData>> for the parsing loop

Licensing

• Use the WebOfTrust repo since using Apache License is required: https://github.com/WebOfTrust/keriox

2022-09-29 #3

Zoom Recording Link Passcode: 8^54Sr&.

Agenda

1. Review Open Items
2. Discuss CESR Proof Signatures
3. Create and agree on CESR type list and set of master code tables.
4. Adjourn

Attendees

Joseph Hunsaker Kent Bull Steven Milstein Henk van Cann Trent Larson

Meeting Minutes

• Recommend reading all the specs
  • Suggested reading map: https://kentbull.com/2022/06/05/keri-start/
• CESR Proof Signatures explained well by the following article:
• Kent TODOs:
  • Add KERI+ACDC terms link to meeting minutes, DONE Henk anchor
  • Create CESR type list and publish
  • Create Master Code Table spreadsheets and publish
  • Create Architecture Diagram draft 4 and publish
  • Get the integration test script running successfully
  • Possibly begin coding
    • Get the developer workflows working
      • Rust -> Python: Publishing a Rust binary and importing it into keripy working
      • Rust -> Rust: Publishing a Rust binary and importing it into keriox working
    • Look into using GithubIssues as the work tracking place
• What we use as an integration test: issue-xbrl-attestation.sh script is at:
  • keripy[main branch]/scripts/demo/vLEI/issue-xbrl-attestation.sh
• We should have tests within CESROX as well as within KERIOX?
• Main KERI and ACDC roadmap, feel free to add items in a CESROX row
• TODO: Build out Priority Table similar to KERI+ACDC priority table

New Terms CESR related

2022-09-15 #2

Zoom Recording Link Passcode: J9Pc139?

Agenda

1. Review open items

• Progress since last meeting
  • Latest August 25th 2022 CESR Spec Reading and Familiarity
  • Architecture Diagram
  • Read new CESR Spec

2. First Goal
   • Elements of CESR to port first
   • Analyze CESR changes from neo branch of keripy
     • What required changing the order of an identifier?
3. Any parallel or related efforts
   • THC - KERIOX

Attendees

Joseph Hunsaker Edyta Pawlak Kent Bull

Notes

Edyta - nothing to report. Joseph - nothing to report. Kent - Read vast majority of new Spec (Published: 25 August 2022)

Kent: I believe

Edyta: Text is much easier to develop with

Kent: Port one representation

Joseph: Looking for a way to make CESROX use-case agnostic, schema agnostic.

Edyta: The CESROX Readme provides a set of thoughts on making CESR use-case agnostic

Kent: Goal for next week: finish CESROX spec, first unit test going from R->T->B and back Joseph: Reading spec, research use-case agnosticism Edyta: Analyze changes from neo branch in keripy.

2022-09-01 #1

Zoom Recording Link Passcode: p4x@C@*^

Agenda

1. Kickoff CESROX team effort
   • Initial Customers: who is interested in CESROX?
     • keripy (CESR event loop)
     • keriox (as a library)
     • acdc Rust library (as a library)
     • IETF participants expressed an interest in CESROX
     • FFI layer to any C-supported ecosystem, Nodejs interface
   • Initial Maintainers: who is writing CESROX?
     • Look at the attendees list
2. Definition of Done at a high level
   • What is an MVP of CESROX?
     • One that implements the entire CESR specification
     • Include the textual representation
       • Easiest to work with while debugging
   • NVP (Next Viable Product)
     • Include the binary representation
   • What should the first unit test or set of unit test verify?
     • Comes from KERI-ox
       • Rust has concept of features, can be included or excluded.
       • We should consider optional or required features when compiling the binary.
       • Rust Workspaces maybe useful
3. Review existing definition here: CESROX Readme
4. Make Architecture Diagram

Attendees:

• Kent Bull (Dev, Architecture Discussions)
• Henk Van Cann (concept, terms and glossary + sophisticated multisig adapter for CESR
• Michal Pietrus (happy to discuss anything)
• Kevin Griffin (involved in original CESR, KERIML, KERI Swift)
• Trent Larson (Dev)
• Joseph Hunsaker (Dev, Architecture Discussions)
• Steven Milstein (Product)
• Mijo Kaliger (Dev)
• Edyta Pawlak (Dev)

Notes

Articles Henk wrote about CESR:

• CESR Proof Signatures are the “Segwit” of Authentic Data in KERI.
• CESR, one of Sam Smith’s inventions, is as controversial as it is genius.

First Steps

1. Have read the CESR specification.
2. Have read the two articles from Henk. (Phil, Kevin, and Michal contributed)

Design of CESROX - brainstorming

1. Reactive Extensions - possible source
2. Code Tables - possible plugins, extension points
   • CESR stream is a payload, signature is an attachment
3. Primary responsibility -
   • Deconstructing a stream of data and providing back the associated cryptographic primitives
   • Data Model agnostic - cryptographic primitives with attachments
4. Unit tests available in KERIPY for text + binary

Licensing

1. Can we consume EUPL into Apache 2.0?

Action Items

1. Create a dev branch, PRs against dev (Kevin will create)
2. Architecture Diagram (Kent) 3. Make design principles explicit
3. KERI-OX port to CESR-OX (Kent) 4. Michal will point out the code from KERI-ox that should be ported. 5. Using the nom crate. Everything is synchronous. Take a look into async-nom for non blocking
4. Begin porting tests from KERI-PY