Slack Archive

To Index

Back To Top
<@U03EUG009MY> has joined the channel
joseph.l.hunsaker
<@U03QRSUA87Q> has joined the channel
<@U02MLCPJ85A> has joined the channel
michal.pietrus
<@U02N7K951DW> has joined the channel
Hello all, I added you here if I reached out last week to talk about CESRox. If you don’t want another Slack channel feel free to leave, we won’t hold it against you. For those that stay let’s get rolling.
Here are the code statistics for KERIox:
❯ scc
───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Rust                        57     10891     1224       760     8907        374
License                      1       191       31         0      160          0
Markdown                     1        16        6         0       10          0
TOML                         1        60        6         4       50          1
YAML                         1        22        5         0       17          0
gitignore                    1        11        2         5        4          0
───────────────────────────────────────────────────────────────────────────────
Total                       62     11191     1274       769     9148        375
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $276,050
Estimated Schedule Effort (organic) 8.433142 months
Estimated People Required (organic) 2.908133
───────────────────────────────────────────────────────────────────────────────
Processed 394062 bytes, 0.394 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
Next my goal is to analyze and get a line count from what Edyta told me about the Rust CESR implementation inside of KERI.
Edyta pointed me to the following module:
The code statistics above are from the WebOfTrust/keriox .
The Human Colossus Lab shows the following statistics:
~/code/THCLab/keriox master                                                                                                                                                 11:10:10
❯ scc
───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Rust                        82     17221     1967       926    14328        525
TOML                         5       141       15         7      119          1
Dockerfile                   2        30        6         0       24          0
JSON                         2        13        0         0       13          0
gitignore                    2        22        4        10        8          0
License                      1       287       71         0      216          0
Markdown                     1        25       10         0       15          0
YAML                         1        22        5         0       17          0
───────────────────────────────────────────────────────────────────────────────
Total                       96     17761     2078       943    14740        526
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $455,530
Estimated Schedule Effort (organic) 10.201189 months
Estimated People Required (organic) 3.967188
───────────────────────────────────────────────────────────────────────────────
Processed 635097 bytes, 0.635 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
So 5421 more lines of code in the THC repo versus the WOT repo.
There are 374 additional lines of code in the THC repo for `event_parsing` versus the WOT repo: • 1706 lines in the THC repo • 1332 lines in the WOT repo
<@U03KLB48Q2E> has joined the channel
joseph.l.hunsaker
I have the Udemy course on Rust :slightly_smiling_face:
joseph.l.hunsaker
I hope they have a good unit testing framework
michal.pietrus
along with <@U02MLCPJ85A>, we've spent some time upon CESROX evaluation and ended up with this doc . It defines `how do we get there` , step by step. This is our point of view, but we're keen to discuss it further if needed
Awesome, thanks, I'll read through it and post my thoughts.
daniel.hardman
<@U03RLLP2CR5> has joined the channel
<@U035D255M0R> has joined the channel
<@U024KC347B4> has joined the channel
This is awesome, let me catch up, I will dedicate whatever free time I can find!
<@U03N48D5VD1> has joined the channel
fyi it is on sale for 18$
<@U03UV1EBVDF> has joined the channel
Proposal from KERI meeting we establish a initial CESROX meeting to discuss the intersection of the IETF spec , the current keriox implementation and what needs to be implemented in CESROX. The proposed date time is the same slot as keri on an alternating Thursday (alternate week to terms and learning meeting).
Which means the first one would be September 1st... I think.
<@U02PA6UQ6BV> has joined the channel
Excellent, that is a good date.
<@U035JNUPF1V> has joined the channel
thanks, Daniel!!
rodolfo.miranda
<@U03P53FCYB1> has joined the channel
joseph.l.hunsaker
FREE RUST UDEMY COURSES limited time!
I’ve really been enjoying by Tim McNamara. In Tim talks about how he spent over 2500 hours writing the book, perfecting it to the masterpiece that it is. I’ve been enjoying it though I’m only on Chapter 5.
Here’s the of the podcast.
<@U024KC347B4> <@U02PA6UQ6BV> <@U03QRSUA87Q> do we have an official invite set up for this Thursday for the first CESROX meeting? If not then I’ll set one up. Should we have someone with a WebOfTrust zoom account set up the meeting or am I okay to make it with my Zoom account?
<@U02N7K951DW> <@U035ZHBF21H> <@U02MLCPJ85A> ^^^
<@U035ZHBF21H> has joined the channel
the meeting link for Thursday’s CESROX kickoff. This link also works as the repeating meeting link. Send me your email if you want to be on the calendar invite.
Kent, please add steven@collab.ventures to the invite
Thx
:pray:
<@U03KLB48Q2E> <@U035D255M0R> sent
Thx
joseph.l.hunsaker
<@U02MD0HA7EJ> has joined the channel
Waiting for the host to start the meeting.
occurred to me I am an hour early.
Exactly :slightly_smiling_face: I left Portugal for Netherlands this morning, so I knew I had an hour extra to be able to join
started now
michal.pietrus
what Henk proposed at the end of the meeting makes perfect sence and shall be part of the README of CESROX
As I make the architecture diagram(s) I will have callouts to specific design principles. I’ll be referencing the CESROX assumptions HackMD page you wrote as well, Michal. We could use that as a place to write our architecture draft.
The articles I mentioned contain the whys of CESR (compared to stuff already out there) and they are reviewed to a certain degree by the technical experts. I would really like a readme with values we adhere to and take it from there. E.g. composability - non negotiable, plugins for code tables, etc
What are we going to do (objective) to get the best out of RUST combined with CESR? Or ‘why RUST and not something else?’
<@U03EUG009MY> Is the meeting page link going to be posted in ?
I am sure technical experts can toss up the argumentation that is often so well hidden under very practical plans, like “let’s build CESROX”
Cesr related code in keriox can be found in this . The core concept here is to parse stream into __ struct that stores payload (in this case event message) and its attachments.
Yes, this is an excellent idea. I’ll go read these articles today.
Yes, I will have that in my first PR to the dev branch.
Until then I will pin the link in here.
CESROX
<@U024KC347B4> or <@U024CJMG22J> Here’s a PR for a simple readme update:
Zoom recording link to today’s meeting: Passcode: p4x@C@*^ This is also in the under the meeting heading for today (2022-09-01):
I gave it a try in the Concepts, Terms and Education repo.
Second bi-weekly meeting today in about 30 minutes. Agenda: 1. Review open items * Progress since last week * Latest August 25th 2022 CESR Spec Reading and Familiarity * Architecture Diagram * 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
I have an internal conflict and will be unable to attend.
Apologies. I can't make it
michal.pietrus
me neither
sounds good, see you in two weeks
Joseph and I are rocking the meeting today.
Edyta came as well
<@U03EUG009MY> could you please update latest meeting with passcode for zoom recording? :pray:
Oh dear, I thought I added that. I’ll add that in today. Thanks for letting me know.
For the 2022-09-15 meeting?
I just added it. The password is J9Pc139?
Tomorrow’s agenda:
1. Review Open Items
2. Create and agree on CESR type list.
3. Discuss implementation of CESR Proof Signatures
4. Adjourn
Sam Phil and I all have the same conflicting meeting this week, unfortunately.
Ok, I’ll move this to another day if Thursday’s aren’t good. What is a good day for you three <@U024KC347B4>?
We still continue today?
yes
There may be another meeting between now and two weeks from now in order to loop Kevin and the rest in.
Meeting link in the agenda would come in handy
Good point, will do.
Thursdays are usually fine. It is just unfortunate that last two meetings we've had rescheduled internal meetings.
got it, we’ll get you next time. I will bring you up to speed. We’ve just been learning and planning to this point anyway.
<@U02PA6UQ6BV> I believe I added what you were after here: in the CESR row. I rearranged the table to put all of the KERI items at the top and CESR and CESR Proof Sigs towards the bottom.
Phil planned to add a better version of the implementation table(s), below the master table.
We’ll wait for him to do this for Python. And then we’ll copy his result into the RUST implementation details table
his results -> the structure, not the content of course
<@U03KLB48Q2E> codespaces would be cool though we would need someone to sponsor them:
image3.png
<@U03EUG009MY> True. Since it would expedite adoption then we could try approaching organizations that would stand to benefit
<@U03EUG009MY> Can you please share your architecture diagram and a few relevant links so I can try putting it into a diagramming tool?
<@U024CJMG22J> has joined the channel
michal.pietrus
sorry for not attending today's meeting. Any important CESROX-related activities?
<@U02N7K951DW> Here's the meeting notes
<@U02N7K951DW> Somewhat. Most of us are still coming up to speed on the specs and CESR as well as CESR Proof Sigs. Henk and I are the farthest along right now. I have a few drafts of a KERI+ACDC architecture diagram that will show the purpose and place of CESR visually. One of my TODOs this week is to create that diagram and share it here. The most notable activity today is that we discussed an approach to creating CESROX which is compiling a list of requirements by listing all of the types we can find and making spreadsheets of all the code tables in the spec and in the existing implementations. Essentially, review current work and make a complete list of work to be done.
Yes, I’ll have that shared to this channel later today.
Yes, good idea. That would be fun to play with codespaces.
Hey all; I committed to getting a diagram out by today though I’m not done yet. As I drafter the diagram I found I need to make a use case. I went too broad in my initial take so I’m simplifying and paring it down so we have a meaningful diagram that is the right size for teaching and learning. I’ll likely have it finished in the next few days.
These are the last terms I added to the glossary, based on study of the most recent IETF CESR draft, where post-conversion post-padding has been replaced by pre-conversion pre-padding, and for the sake of clarity the latter has become ‘lead bytes’ (no joke):
All look good to me.
My personal goal is to have the first alpha version, call it 0.1.0, of CESROX done by IIW 35 so we can present on it there. This includes the following: 1. All known types from KERIPY, the KERI Whitepaper, the following specs represented and supported: IETF KERI, ACDC, IPEX, and PTEL 2. Conversion to and from T, B, and R domains. 3. CESR Proof Signatures supported. 4. All attachment semantics from KERIOX and KERIPY implemented So far I came across 30 types in the IETF KERI spec. I’m still collecting types from the other listed sources. This is an ambitious goal. By next week’s CESROX meeting it may have reduced. As a bare minimum by IIW 35 I want to have at least one cryptographic primitive with attached signatures fully supported in all T, B, and R domains. The next alpha version, call it 0.2.0, we may target to include features like composability with JSON, CBOR, and MsgPack content. Tell me what you think, how much you think is doable, and whether you’d like to see a CESROX session at IIW 35, or whether you want to be a part of the presentation!
An inception event is the first type I’m seeking to support along with any attachments including • the set of controlling public keys • signatures from the private keys • the signature threshold • pre-rotated public key digests • pre-rotated signature threshold
michal.pietrus
What i would propose to you is to consider the following exercise: A library that is able to support any data model and has proper architecture to make it happen. Data model and code tables can be artificial, only for the purpose of having proper tests in CESROX. On top of that, the B,T domains can be implemented. Having such a library, KERIpy data model is defined by the consumer, so by the KERIpy team at the point of integration. CESROX is opaque to it and does not know it until the integration. Its sole responsibility is to be able to parse CESR streams.
I really like this. All we need to do is to support the following set of pluggable abstractions and behaviors: *Abstractions* 1. An encoding - JSON, CBOR, MsgPack, CESR) 2. A raw data type - a domain-specific raw data type plugged in at an integration point 3. A code table - a pluggable data type lookup table specifying size, nesting, and other serialization-relevant properties for the specified data type 4. A code table entry - a specific entry of a data type into a type lookup table 5. Raw type mapping - a mapping between a raw data type and a code table entry. Some sort of link between a raw data type in the target language (Rust, Python, Javascript, Clojure) and a selector in code table plugged in to the CESR serialization and deserialization engine. *Behaviors* 1. Stream parsing 2. Stream type detection - binary or text - *in starting tritet * 3. Stream encoding detection - CBOR, JSON, MsgPack, CESR - *in starting tritet* 4. Code table detection - which code table should be used - * apply* 5. Code table entry recognition - which entry in which code table should be used - ** apply 6. Data type detection - Based on the supplied raw type mapping of raw type to selector. 7. Data type serialization - one of the two main workhorse functions 8. Data type deserialization - the other of the two main workhorse functions
Do you have any ideas you would like to add to this <@U02N7K951DW>? This is only my first draft and I have more thinking to do on how to create the proper architecture as you have mentioned. I agree, if we can make a pluggable architecture for CESR then the utility and usage of CESR will be tremendously benefitted and we should strive for that goal.
Do you know of any examples of somewhere the proper architecture you have in mind has been accomplished that we could use as a reference?
There will need to be some sort of parsing service provider interface, some service loader, and some parsing service instance factory that constructs parsing service instances or functions based on supplied code tables, selectors, raw types, and serialization and deserialization functions for each of the supplied raw types.
At a high level it seems CESR will have the following components: 1. Stream processor 2. Parsing service provider interface 3. Factory functions for constructing deserializer and serializer functions 4. Parsing function loader configured by the provided parsing rules and data model.
> Having such a library, KERIpy data model is defined by the consumer It seems that in order to have reliable tests in CESROX we will have to include the raw types in the tests for CESROX, would we not?
For adding mental context for CESR and making it easier to join the team please review this and tell me what I should add next:
KERI Architecture Overview.png
While I applaud your enthusiasm, I’d like to provide the following critique. This type of high level architecture and design is likely not appropriate for a low level open source library of a published protocol with one reference implementation in python and another implementation in the target language of this library. Remember, in open source projects… code wins. I’d like to suggest an alternate approach. It you really want to bootstrap this project, I’d suggest working closely with <@U02N7K951DW> and see if he can suggest some code from KERIox (he’s already offered) that could be used to get things going in this library. From there, approach <@U013SSREL0H>, <@U024KC347B4> or myself for some pointers into the KERIpy code / tests that would be a good place to initiate a first round of “compatibility tests”. If you get that working, then we can start talking about IIW presentations and the like.
<@U013SSREL0H> has joined the channel
I agree with your critique. Code is what wins. It seems like the best approach is to begin with what is in KERIox and KERIpy. I was concerned myself about getting too abstract. My thoughts were just throwing ideas out there to see if that was along the lines Michael was thinking.
The KERIox code was where I started a month and a half ago though I ended up feeling like I needed to increase my familiarity with all of KERI so I went and read all the IETF specs to cement the terminology. I’m just now getting to actual writing of CESRox code.
And the note about an IIW presentation is more to set a goal and a tone, definitely not to step on toes. I would like to present the work on CESRox at some point though I like your idea of getting code written first and then taking a step back to talk about where to go from there.
<@U02N7K951DW> along the lines of what Phil said here, what do you think about us starting with the code inside of KERIox? Do you think the architecture of that code represents the goals you have articulated for CESRox?
michal.pietrus
Hey, sorry for a late response. We have prepared a code snippet here , how we envision it from the client perspective. Below the snippet, there is a `discussion` with some more explanation of the intent. It makes CESROX agnostic to any data model any client would have. All what matters is to inject code tables that are the source of truth for CESR parsing. As a result client gets `RawMsg[]` that she addresses internally however she wants. <@U03EUG009MY> <@U024CJMG22J> <@U024KC347B4> take a look and share thoughts.
I must be missing something you are thinking. It seems like making CESRox agnostic to data model is missing the mark. CESR and CESRox should be specific to the data model of KERI and ACDC, should they not be? I can see an argument for making the ACDC portion of a CESR implementation flexible since there needs to be support for many different credential shapes though it seems the KERI code tables should be very stable and thus I see no need for data-structure agnosticism with regard to KERI. On the contrary, CESR should be tightly coupled and bound to both KERI and ACDC, should it not?
I know I’m new to KERIox and CESRox coding so please bear with my lack of familiarity or ignorance. I ask questions to learn, not to be difficult :slightly_smiling_face:
michal.pietrus
They are actually not... Anything that would require "common" data model, ie. ACDC/KERI specific would come along on top of CESROX. CESROX is purely about parsing streams. Note CESR stream in text mode for JSON is more more or less like this: `{json}attachments{json}attachments...` . Under `{json}` there is a serialized object, however CESROX doesn't care what it is or whether it is valid according to the rules of client business logic. Therefore the result of parsing by CESROX is: `[RawMsg(payload: json, attachments: [....]), RawMsg(payload: json, attachments: [....]), ...]`. You've got all the attachments that are known from the code tables that you can use further and you've got payload that you map to your data model, ie. a KERI event. You then on the client side check whether signature matches, then validate the event against its schema and so on. For CESROX all what matters are the code tables, so it can recognize attachments and give them back to you, so you can decide in your business logic what to do with them. That was the reason I proposed an artificial code table and artificial CESR stream (not related to KERI), because it is a good exercise to understand CESR basics. btw. in KERIOX the module responsible for parsing is here:
Ok, I see, so CESROX would just generate the `RawMsg` objects and the user-supplied code tables would be used to map the `RawMsg` objects parsed from the stream to concrete types in the target language.
I’m looking through the `event_parsing` module now. It’s where I’ve been focusing as well as the `keripy/src/keri/core/parsing.py` and `keripy/tests/core/test_parsing.py`
michal.pietrus
on client side, in any desired language, yes you will need to know what are the attachments to give them a meaning. CESROX cannot do it for you, because it is up to you to define it. In KERIOX it is enum that encapsulates this.
Is there anywhere in KERIox that has the `RawMsg` idea similar to `Serder` in KERIpy?
I’m looking at `Sadder` and `Credder`in KERIpy as well and looking for counterparts in KERIox.
michal.pietrus
i dont remember TBH what was the serder
Its the class that handles serialization and deserialization.
It looks like is what I was looking for, a function that does or can do cyclical parsing like in KERIpy.
joseph.l.hunsaker
:point_up: in the channel topic
yes
A decision needs to be made about the relationship to the following two repositories: 1. DIF’s repo 2. THC’s repo. Since they both have an implementation of CESRox then I suspect each of them would gladly become consumers of the CESRox library once it is complete. The DIF keriox repo is exactly the same other than 11 more recent commits when compared with the WebOfTrust repo. Why development is occurring there rather than in WOT I don’t know. I’m making a pull request today to bring the WOT repo up to date with the DIF repo.
We decided on the call today to focus our effort on the WOT repo. I am moving forward with that decision unless there is a good argument for another direction that comes up.
michal.pietrus
I believe we communicated that and suggested to consume what is in . There is not much difference in case of CESR parsing comparing to THClab/keriox and it is licensed under non-copyleft license (APACHE)
You need to be extremely careful with regard to DIF, there was an extremely painful year that went by where we tried to extract keripy from it. I would strongly discourage against pulling anything in from DIF, we didn't fork from there for a reason, and we were extremely grateful for Michal et al donating keriox to web of trust before the license change.
DIF does not have clear and concise separation of IP and implementation with regard to specifications cerated there. This is the reason KERI and CESR are under IETF as draft specifications, and why the implementations are under web of trust.
Sam wasted MONTHS fighting DIF, and to be frank, I will not approve a PR bringing in any code from there.
CESROX needs to be derived from the KERIOX donated by THC, in my opinion. <@U024CJMG22J> <@U013SSREL0H> please correct me if I am being overly defensive.
Under DIF license all source code contributions are apache2. So a pull request from an apache2 licensed repository should not be a problem. Unfortunately, DIF uses a combination of the W3C patent policy and the CC4 license for non-source code contributions and so that is where there is significant ambiguity especially since the W3C Patent Policy as written only provides provisions for management by the w3c not DIF. In June of 2022 there was a determination by DIF that there were no patentable contribution to the DIF KERI repo for which the W3C patent policy would apply. So any pull requests from code donated to DIF before June of 2022 are clean. Anything after that we should not accept because there is ambiguity as to what is “source code” and what is not when it comes to contributions at DIF. Frankly I consider DIF’s IP policy to be broken because IMHO there is no way to unambiguously determine if a contribution is source code or not. For example is javascript or python code pasted into an issue raised on DIF’s github repo count as source code and falls under apache2? Or is it text and falls under CCby4, or is it a patentable description of a process? In fact any organization including the W3C that has multiple mutually exclusive split licenses instead of one comprehensive license or licenses instead of a set of comprehensive licenses is IMHO only viable because of the good will of the contributors. There just isn’t enough legal precedent to trust such constructions. By comprehensive I mean all contributions of any and all kinds are covered by one license. One can have multiple comprehensive licenses where a given license takes priority for terms but allows for relaxed terms of use in some circumstance. but all contributions are still covered. So worst case the contribution is no freer than the most restrictive license. Stacking licenses this way is a common legal approach, but splitting is not. Splitting contributions between different licenses is problematic because of the difficulty in defining the boundary. And the worst case is that its not free at all.
<@U024KC347B4> thank you for bringing me up to speed. I will focus only on CESRox then and not worry about what is in the DIF repo. And thanks Sam for the clarifications. This all is clear to me now why we do the Apache 2.0 license like we do. I will ask a question first next time before I say I’m going to do something that could be ambiguous or complicated like this.
One more thing. All the repos in the WoT project where the KERI code and related standards reside, have a outgoing == incoming policy.This means that someones use (outgoing) of a contribution (incoming) is on the same basis or license. This prevents contributions from being poisoned by other contributions that have a different i.e. more restrictive outgoing license, because once contributed there is no way to separate contributions. It becomes a soup. It is possible however to have less restrictive outgoing than incoming or have multiple outgoing licenses that are of the same or less level of restriction but with different names because some consumers want to consume (outgoing) under a different license. This is OK as long as its part of the license structure known by contributors. So for example IETF requires that IETF spec language be contributed under BSD not Apache2. But BSD is no less restrictive than Apache2 for outgoing so it does not poison the apache2 contributions. A consumer can consume under apache2 or via IETF through BSD.
BSD is no more restrictive than Apache2
The license for the IETF spec repos in WoT include the BSD outgoing in addition to Apache2 for this reason
I made a separate section in the Q&A
based on the input above
And since we’re backwards writing our concepts.md too, I added this as our vision on open source that lead to choices ->
<@U013SSREL0H> or <@U024CJMG22J> you could pull the changes to the Q&A in via
Done
<@U035R1TFEET> has joined the channel
<@U047UUDAHUY> has joined the channel
<@U0448S72CQN> has joined the channel
Here's what I'm getting this morning on the repo
$ cargo build
warning: unused manifest key: package.edition
    Updating registry ``
error: no matching package named `serde_crate` found (required by `ed25519-dalek`)
location searched: registry 
version required: ^1.0


$ rustc --version
rustc 1.20.0 (f3d6973f4 2017-08-27)
$ cargo --version
cargo 0.21.0 (5b4b8b2ae 2017-08-12)
I'll be browsing around, but I'm a noob to rust so suggestions welcome... including suggestions for people to include since I don't know that this channel includes some of the keriox people.
2022-11-10 17:54:07 dimm@dkuzmenko /home/dimm/projects/provenant/src/keriox (⌐■_■) master
$ git up
Fetching origin
master  up to date
2022-11-10 17:54:10 dimm@dkuzmenko /home/dimm/projects/provenant/src/keriox (⌐■_■) master
$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
2022-11-10 17:54:15 dimm@dkuzmenko /home/dimm/projects/provenant/src/keriox (⌐■_■) master
$ rustc --version
rustc 1.64.0 (a55dd71d5 2022-09-19)
2022-11-10 17:54:27 dimm@dkuzmenko /home/dimm/projects/provenant/src/keriox (⌐■_■) master
$ cargo --version 
cargo 1.64.0 (387270bc7 2022-09-16)
2022-11-10 17:54:34 dimm@dkuzmenko /home/dimm/projects/provenant/src/keriox (⌐■_■) master
$ 
In short: works for me with rust 1.64.0 on the recent master branch
`cargo clean` `cargo build` works as well
Try `cargo update` it might help
Run `rustup update` and all should be fine
`rustup update` did it for me! :clap: (FYI `cargo update` gave me a similar error to the original.)
There will be no weekly meeting tomorrow due to observance of American Thanksgiving. See you all in two weeks!
In lieu of a meeting check out the latest code that <@U024KC347B4> and <@U024CJMG22J> added to the repo • Excellent work guys! These PRs represent the first meaningful code contribution beyond “hello world” to the CESRox repo. I suspected Kevin and Phil would beat me to it :wink:
I blame the after hours beers at IIW
I see pending PRs but codecov is failing to run, I pushed an update to the test.yaml to use a more recent version of the plugin, you might want to pull that change into your forks and ensure that codecov succeeds on your PR <@U03EUG009MY> / Shoeb Ahmed Tanjim s-a-tanjim
pushed an update.
Hey folks! Provenant wants to have a progress on cesrox library and I have a couple of points that I'd like to discuss on the upcoming meeting.
It's more like questions from my side, less then proposal. The first one is the structure of the cesrox project. Or more concrete: the external API we'd like to have on it and the scope of the cesrox functionality. The snipped above describes the current structure and my questions to it.
And the second one is a proposal to initiate a discussion and breaking down the upcoming work in GitHub. I'd like to create the following issues. • Create API ◦ There is a ticket for this already. ◦ It combines API design definition, documentation and implementation. • Create test vectors ◦ Gather the existing test data vectors. ◦ Define the minimal needed dataset. ◦ Questionable: do we need it at all? As I see by the code it's usually simpler to generate the data programmatically. Does it make sense at all to define it as a fixed database? • CI ◦ It's already configured. Just check and think on possible improvements. • Release process ◦ Auto-build and publish by new tags? • Implement missing data primitives ◦ Here we need to split it by categories, define the list and create issues.
To your question “- Keri data flow looks like a mix of json/cbor/mgpk/cesr that is covered by CESR draft. So it looks we should support it in cesrox library. Is it so?” I would say ‘yes’, CESR gracefully ends the discussion about CBOR vs. JSON because the protocol is able to convey all three (msgpk) and the native CESR format in one go. So Cesrox should be able to handle this, afaik.
The essence is in this section I think:
Yep, thank you. I've just wanted to ensure it's a part of cesr parser and not just a sugar for keri.
> So it looks we should support it in cesrox library. Is it so? No, implementing all three serializations at the start in my opinion is over kill. I'd implement serialization with json, then wait for Sam to finish the CESR event format in keripy, then implement that, then cbor msgpk when someone needs them.
Yep, but in this case we should anyway design this layer in cesrox. So from the design viewpoint support must be there.
daniel.hardman
<@U048YRLFKTK>: I agree that the design should imagine it, even if the implementation mostly ignores it. I'd like to go one baby step further, if it seems practical. Perhaps we could implement something *very* simple with both CBOR and MsgPack, just to make sure the design has answered the right questions, and to give future developers a place to plug in a more complete impl. For example, maybe we could just serialize integers and strings. This ability could be turned off with compile-time switches in Rust so it doesn't create dependencies for normal developers who only want JSON serialization.
I will not be able to attend today, GLEIF are working with <@U03RLLP2CR5> et al from provenant to stand up the vLEI. <@U048YRLFKTK> if you are looking for a place to get started with the API, this is what I would do. Implement a public API that supports consuming a byte stream, then peeks that bytestream to determine the serialization format (look at the first 3 bytes) and return a result that is just Result<SerializationGeneric, Error> and have it return what type of serialization you sent it. Then have four test cases, bytestream json, bytestream cbor, bytestream msgpk and bytestream unknown. This will do a few things: Establish a starting point for the API. Get familiar with manipulating byte streams in Rust. Provide future extension points. you could then look at creating bindings for other languages Provenant is using which may require cesr in the future Allow me some breathing room to finish the dual index support required to be compatible with the CESR implementation in keripy. That'd be a fun, fairly big, chunk of work in my opinion. I will also push my draft PR for dual index support so I'm not sitting on it.
See my comment about next steps, this will allow for design of it.
daniel.hardman
Yes, just read it and I agree with your recommendation.
<@U048YRLFKTK> now thinking about the API - the invocation of cesrox probably wants to be ambivalent to the types in your stream. So: cesrox.parse(myByteStream, SomeTypeDefinedInYourLanguage) that then returns Result<Array<SomeTypeDefinedInYourLanguage>, Error> cesrox can't know about every type contained in every stream, so that needs to be accounted for
Yes, this is a good question.
I am now jealous you have cycles to work on this haha :)
Don't be so positive. I'll try to not give you a chance to stay away from this stuff. :smiley: Anyway I'll need an advice here.
Very appreciate your help. Thank you <@U024KC347B4>
oh no problem at all, I should have more availability in the coming weeks to collaborate with you on this.
michal.pietrus
`cesrox.parse(myByteStream, SomeTypeDefinedInYourLanguage)` might be problematic, especially the latter argument, considering the FFI layer in the middle. Note that FFI layers, especially for duck-typed languages, have limitations; therefore, strong typing and working across boundaries with object definitions might be extra problematic. It is usually easier to continue solely with primitives. Having that in mind imposes a slightly different mental model of working with CESR streams (that consist of payloads and attachments). One option is to enable the client to establish objects of his data model straight from the payload. In such case, CESROX provides everything to the client, except it does not deserialize payload from json/cbor/mgpk. Client does it
Agree, I was thinking about it because streaming as well as iterating interfaces could be not well transferable between languages. But primitive types should have no problem except an extra memory/cpu waste on copy. So I'm thinking about working with byte arrays and transforming crypto data types. I haven't dove deep into the details of possible implementation.
In the CESR draft, some codes have been removed from the master code table: . What is the reason for this? The commit message says, "Updated code tables to latest as implemented in keripy," which doesn't explain the reasoning.
This makes sense. So then the responsibility of the CESR library would be to: 1. Frame-based data type detection: detect data types with framing codes specified by the self-framing codes from the master code tables. 2. Offer up the raw, serialized type to the host language and binary for deserialization. Then the host language would take responsibility for taking the type code read by the CESR library and specifying a type mapping to deserialize the detected data type. The exception to this would be, as Dmitry and Michal stated, primitives since the type list is small and easy to receive from an underlying library through the FFI. Does this sound accurate?
If this is the case then it seems that the CESR library’s sole responsibility is detecting codes from the master code table, consuming the number of bytes from the stream according to the master code type and the encoding (JSON/CBOR/MsgPK) and then offering up tuples to the host language of `(deserialized prefix, raw serialized type)`.
<@U047UUDAHUY> In the last KERI meeting Sam stated that the codes he removed were old codes added along time ago that have not been used.
It seems like he said one more thing though I’m not currently recalling it.
In order for this to work it seems like there must be some logic added to the parser for each type the host language expects to parse. This logic would need to have a mapping between a master code table entry and `SomeTypeDefinedInYourLanguage`so that the parser can understand what in-memory type to deserialize a given set of bytes into.
One question as I’m re-reading the whitepaper to help me understand the process of decoding used for CESR: Is a CESR stream always decoded from Base64 to raw binary prior to deserialization into the target type? Meaning, is raw binary always the intermediate representation between the Base64 sent over the wire and the target in-memory type in Python or Rust? And, the natural next question, is deserialization the process of converting the raw, base64-decoded binary bytes into the target type for the host language (Python or Rust)?
No, the power of CESR is that a stream can be sent over the wire in either the text domain (base64) or the binary domain without loss. The "raw" domain is the in memory representation in a given implementation.
You can represent a stream of CESR in text for archival or for debugging and flip the switch to binary to gain a 30% decrease in bandwidth.
Without loss
So then does this, along with the self-framing nature of each CESR data type, mean CESR could support interleaved text and binary stream segments in a single stream? And if yes, this seems to imply that there would need to be a text or binary encoding detection logic branch in the parser used for each newly encountered type in order to parse it properly from binary or text. I don’t know if people would use interleaved text and binary, I’m just thinking through CESR to understand edge cases. Am I misunderstanding the intention or use of framing codes? The definition in the spec seems to indicate things would be done en-masse, so no interleaved T and B domain support, only one or the other it seems: > The property enables a stream processor to safely convert en-masse a stream of text primitives to binary for compact transmission that may be safely converted back to text en-masse by a stream processor at the other end for further processing or archival storage.
I’m more wanting to rule out the possibility of an interleaved T and B stream in order to simplify the design though if the intention is to support such interleaving then I want to account for it.
Yes, that is the intention. Any stream can include both text and binary.
That's the beauty of the unique start bits.
Well that’s cool. Yes, a bit more complex, though not too much, and then CESR is very capable. Beautiful indeed.
michal.pietrus
<@U048YRLFKTK> apologize for a late reply. This is correct and I believe there are also other considerations. I am not sure you need to work on a byte streams, ie. as opposed to work on strings, but for sure avoiding cloning is a wise and reasonable approach. There are not so much options to choose here to avoid it. All with trade-offs. We didn't choose yet which way to go, so either with slices or rawptr's.
One more thought I want to highlight here is the following: basically CESR defines the way to understand json/cbor/mgpk/cesr in a data stream and defines a serialization/deserialization algorithm for supported data primitives. So it's not a CESR's work to understand KERI's message structure. Currently it's a little bit mixed by keriox code. What I want to do is split it in a way that allow CESR to provide serde compatible methods to deserialize primitives and leave the code defining keri structures inside keri. I.e. to provide the simplicity of `event_parsing::message::signed_message(s: &[u8])` but with configurable list of parsers defined by the app, not the cesrox library. Any feedback is appreciated.
So, CESR should be able to deserialize json/cbor/mgpk events, but cares little for the message body, it's concerned with extracting the size of the message body from the start of the message, based off the serialization, then proceeding to the attachments which use the code tables to extract the attached signatures etc. > So it's not CESR's work to understand KERI's message structure. Correct. Code tables exist for KERI in the CESR Appendix, and additional code tables could be added for other protocols.
Hey it appears we have a naming collision :grimacing: This is unfortunate but I can explain, the initial cesrox repo (and name) was conceived by Phil and I on April 25th, under WebOfTrust (), and the duplicate repo at THCLab on April 28th () under the copyleft free EUPL-1.2 license. Phil and I then committed our initial contents on November 17th () based off the work THCLab donated to WebOfTrust/keriox, and subsequently THCLab then continued work on November 23rd (). Unfortunately this work by THCLab seems to have registered both and in :crying_cat_face: Given THCLab currently only registers on and not , I'd like to ask the communities opinion on humbly asking THCLab to graciously relinquish control of cesrox to the WebOfTrust group :pleading_face:, whom are committed to an Apache2 licensed version of cesrox, and originators of the cesrox name, this allows THCLab to remain consistent in their naming of their libraries with keri and cesr.
robert.mitwicki
<@U013F46SDRR> has joined the channel
robert.mitwicki
Hey it appears we have a naming collision ;) This is unfortunate but I can explain, the initial cesrox repo (and name) was conceived by Phil and Kevin on April 25th, under WebOfTrust (), and the duplicate repo at THCLab on April 28th () under the copyleft EUPL-1.2 license which is way better then Apache as it protects the community ;). Phil and Kevin then committed initial contents on November 17th () based off the work THCLab donated to WebOfTrust/keriox, and subsequently THCLab then continued work on November 23rd (). Unfortunately this work by WebOfTrust seems to have registered keriox in . Given that cesorx and keriox on THCLab is WAY ahead with development and is more popular. I would like to ask the communities opinion on humbly asking WebOfTrust to graciously relinquish control of keriox to the THCLab group, whom are committed to an EUPL1.2 license (which is more community friendly license) version of keri, and originators of the keriox name, this allows THCLab to remain consistent in their naming of their libraries with keriox and cesrox on To gain popularity even faster, promote the work which our communities are working hard on, and take over the world!
robert.mitwicki
For those who don't get irony please don't read it :stuck_out_tongue:
robert.mitwicki
First of all HCF does not bite you can write us direct messages and we are happy to resolve any problems. We working hard same as you guys and we want to promote work which is developed by all of us. If I remember correctly <@U024KC347B4> you missed our last KERI call where we discussed the differences between licensing strategies. We showed that there is no reason be afraid of EUPL and that we could easily collaborate on one repository without any restrictions. EUPL can be reused same as Apache in any proprietary and non-proprietary software. You can easily link cesrox on EUPL into keripy without any conflicts. The only difference between Apache and EUPL which is relevant for most is that EUPL protect from "taking and not giving back" or "taking and locking it up" which in Apache case is allowed and completely fine but could bring some risk for the community.
robert.mitwicki
Speaking of the naming issues and conflicts let's discuss and see which options make sens for both. Our components keri and cesrox are already used in many projects and changing the name would generate some extra effort. We would evaluate that on our side and will get back here. As suggested on the call first I would suggest to see if it make sens to combine forces and work on one project. keriox, cesrox and said is already quite solid implementation in rust. I don't see reason why anyone would like to try to recreate that effort once again without solid argument. I respect if someone would have a wish for it but let's be realistic if we want to gain traction we need to work in synergy and not dividing and forking everything.
robert.mitwicki
Btw. is "owned" by DIF, HCF is one of the maintainers but we are not the only one. HCF is not using KERI crates since it does not make sens to do so. KERI crate is "end product" (binary) is nothing which you would like to use or embed it in any software. Distributing binary via crates is not the best idea anyway. From HCF side what we care are libraries which are helpful for others to integrate it in their systems: we are not planing to publish keri since keri is final product and would be distributed in different way. Hope that helps as well to get some overview
My message was to the community, the next step would be to follow up with THCLab.
robert.mitwicki
We feel to be part of that community as well :slightly_smiling_face: isn't that the case? :wink:
That's a strawman argument, nothing in Kevin's posts have suggested that THCLabs is not part of the community. As a matter of fact he continues to praise all the contributions you have made so far. Please, lets stay on the topic of which repos the community wants to use moving forward.
robert.mitwicki
should mark that as well with big sign "watch out sarcasm" :slightly_smiling_face: No worries all good. Just sounded weird and needed to respond :wink:
robert.mitwicki
<@U024KC347B4> <@U024CJMG22J> since you missed the last call please take a look here: to learn more about what the license does, and let us what you think and if still make sens to go with two repositories.
robert.mitwicki
Regarding the naming we don't care much is just the name as explained above we have already few libraries which are used in many places. Changing the name would make some extra effort for us to fix it in few projects. I would suggest first to find out if there is really a good argument to go for with 2 repos in times when the resources are limited.
robert.mitwicki
I can't of think of any reason why we would like to have 2 implementation of same thing. As explained on the last call we are open for any solutions if people wants to develop another code base, fine for us. We continue with building up what we started and we would continue to protect the code with EUPL to make sure that community would not be left behind.
From my 25 years of experience with venture funded start ups in the US, any copyleft-like licenses are to be feared. I have had to audit every library imported into multiple projects for anything that is not either Apache2 or MIT and remove them from the project. The liability of exposure to potential lawsuits is not something any VC wants any part of. They'd rather take their money somewhere less exposed. As a result, I will not use or contribute to anything that is not Apache2. One of the goals for a Rust implementation of CESR is to replace the existing parser in KERIPY with a faster "closer to the metal" parser and since KERIPY will remain Apache2 it will not use anything that is EPUL. So we need an Apache2 version of cesrox to achieve our goal. I'm not sure how to make it any clearer. We are proposing an Apache2 version of CESRox. If the THCLabs repo will remain EPUL, then we will host one on WebOfTrust that is Apache2. The only ask here is about the crate name.
robert.mitwicki
We respect your experience and decision, I am not denying you to start another project, just asking for reasonable analysis. What I don't like is the pressure which is made on this community to go for Apache2 due to false assumptions. There is no reason to fear EUPL by any mean. As mentioned many times we are here to build with community for community, VC interest is not our main driver, but it does not mean that we are not considering seriously businesses and investors. EUPL does not limit nor expose you to any type of lawsuits more then Apache license. It provide solid protection in the scope of patents, IP rights and more. It goes beyond that and protect code from locking it down and closing the source in case if VC or any company would decide so. We believe that for each community is important that their efforts won't be wasted. What we care about is that community would make conscious decision, I assume that decision which you mentioned above about keripy not using anything which is not Apache2 is such decision, and if you have reasonable or not reasons for that I respect that. Please continue with development as you prefer and let others to chose as well.
robert.mitwicki
Regarding the naming of crate I would suggest to do a survey within community to collect voice of everyone and follow that decision. I don't want to make any problems if community decide to "take it" even though that we created it in first place (I mean Apache2 code which you guys are using now and the crate). Just keep in mind that if we do so, does not allow to alter the past, means that on this crate you would have old versions under EUPL. I don't think there is a way to change that. Not sure if that won't generate any problems for you guys, having a code under different license which is not compatible with existing one. But if that is ok, I don't think we would block anything.
> I would suggest to do a survey within community to collect voice of everyone and follow that decision That was exactly the intent of my message to the channel.
> I'd like to ask the communities opinion
I appreciate the time you took to offer yours.
Since you took the time to offer your opinion, I feel it would be rude to not respond, at least in part. > EUPL can be reused same as Apache2 Great. Let’s just use Apache2 then. I do object to this statement, I feel it disingenuous: > What I don't like is the pressure which is made on this community to go for Apache2 due to false assumptions I have not, nor has anyone in this community, put any pressure on anyone, to do anything and I vehemently resent the implication. We created cesrox, under WebOfTrust on GitHub on the twenty fifth of April this year. We spoke about our intent for cesrox at the keri community meetings. In August of this year Kent took on leadership about bringing the effort to life and created this Slack (thanks Kent), and the creation of a community meeting published on the repo and addressed in the keri community meetings, we have then proceeded to have many meetings for cesrox (thanks again Kent). In November of this year, we did our bi-annual “let’s hack on something fun at IIW“ and were able to get cesrox off the ground thanks to the code you left with us at keriox under Apache2 in WebOfTrust. In my opinion that was ample time for someone who was interested in doing the same thing, under a different license to speak up in those community meetings. I will now give you my honest personal opinion. I find it extremely coincidental all THCLab efforts coincide with the WebOfTrust efforts, but delayed by a few days, almost like something spurred THCLab to do something, but under their preferred license, fine you are free to do so, but to then say: > I am not denying you to start another project Seems a little disingenuous again, as one effort seems to have driven the desire for you to start yours. I’m not a Rust developer, would I love the support of the team at THCLab, yes absolutely. Dr Smith has discussed licensing with you ad nauseam in previous keri community meetings, he has made his position clear, and you yours. As Dr Smith is the author, creator and visionary of KERI, ACDC and CESR I find myself predisposed to supporting his decision to publish specifications with the IETF and develop implementations for those specifications under Apache2. I will continue to attempt to develop cesr, in Rust under the Apache2 license with whomever wants to, I have made no demands of anyone. I asked the community in my original message if they would support asking THCLab to let us use the cersox name, we had some supportive responses and some not supportive responses. I have no intention of dragging this out, even though we only have a hand full out of twenty something responses I will recommend at the next cesr(ox) community meeting we discuss a name change moving forward, with whomever wishes to work on it, seems like the path of least resistance.
There is no false assumption in my response. As a matter of fact, there is no assumption at all. I provided evidence from my past experience of direct financial impact of using software with copyleft-like license. You asked “why two” and I answered that question. To call it a false assumption at this point ignores my answer and is disingenuous. You state that EUPL does not expose you to any additional lawsuits than Apache2. But then state that it “goes beyond that and protects code from locking it down”. So there are additional restrictions beyond Apache2. So then what recourse would someone use to enforce that additional restriction? Well, legal of course… that’s the whole point. So that is additional exposure to lawsuits. And VCs see it this way, I didn’t make that up.
daniel.hardman
Robert said: > There is no reason to fear EUPL by any mean. As mentioned many times we are here to build with community for community, VC interest is not our main driver, but it does not mean that we are not considering seriously businesses and investors. EUPL does not limit nor expose you to any type of lawsuits more then Apache license. It provide solid protection in the scope of patents, IP rights and more. It goes beyond that and protect code from locking it down and closing the source in case if VC or any company would decide so. We believe that for each community is important that their efforts won't be wasted. I agree that the EUPL is a good license with many virtues. However, I disagree with the assertion that "there is no reason to fear EUPL by any means." The problem is that the decision makers on open source use in most companies are not rational developers who will listen to Robert's impassioned advocacy for EUPL. They are lawyers who don't understand tech very well, and/or executives who understand neither the law NOR the tech very well. When I was at a certain large company in Europe that I won't name, there was a standard posture toward open source: *Thou shalt not use anything with a copyleft provision.* Period. There were no exceptions, and the legal department was very unwilling to entertain requests to change the policy. Getting an exception, if possible at all, would have required intervention by the CEO, who had no understanding of tech and had been told by his lawyers that the company's IP policy was incompatible with copyleft. When I worked at a large company in the US, the policy was similar, and the overhead was similar. What I believe will happen, if there exists only a repo with EUPL license on it, is that companies like this will refuse to use/adopt KERI. Not because they have done a wise analysis and come Robert's conclusion that it is fine, but because they are irrationally allergic to it. If we have two repos -- one with EUPL and one with Apache -- then the Apache one will get all the adoption by companies that have serious gravitas but unenlightened leadership. I fear, that's most of the companies we truly want to adopt. And as Robert points out, that leads to needless duplication of effort. Therefore, I think the best option is one repo, licensed Apache 2. The second best option is two repos, where the EUPL one is downstream of the Apache one, and all the contributions flow into the Apache one. This would allow companies who are enlightened to use the EUPL license, and allow others to use the Apache license if they need to. The notion that we need to protect the community from commercial interests who will appropriate KERI and run away with it seems very farfetched to me.
robert.mitwicki
thanks <@U03RLLP2CR5> for joining discussion but I think your comment goes too much personal. EUPL is not mine license I didn't invented it, I don't need to preach to people how great it is. People does not have to listen what I have to say, There is solid EU law behind that license, was vetted by all EU state members. There are tones of lawyers which can assure you about how it works and what purpose it serve. Human Colossus Community decided to go for it because it promotes our values and protect community from "takers" and risk of losing the code in commercial space. We chose it because our community (including private companies) investing money into development and we want to make sure that this won't be taken away and lost just because someone would jump with bigger resources. > The notion that we need to protect the community from commercial interests who will appropriate KERI and run away with it seems very farfetched to me. It is way closer then we think. We already had some teasers how it was done in HL with IBM, Amazon taking open source and run SaaS and more. I don't understand why suddenly everyone is so eager to question EUPL. I understand all the points about yours experience and lawyers etc. But lots of companies uses copyleft source code and are fine with that, and I am not talking just about EU and example of EUPL but GPL and companies like google, samsung, microsoft etc.. Sure they don't like it as they need to give back but still using it. I worked as well for few companies already, never had that problem what you guys describing. As soon as company is fine with giving back they never question that, only those who don't want to give back makes problems. Maybe you guys were unlucky and picked wrong companies. > Therefore, I think the best option is one repo When there is "the best" we always need to ask the best for whom? In HCF opinion the best is if we can assure that always everyone gives back. You maybe see that differently which is fine. For sure both ideas can coexist and time will shows which goes better. Companies which are related with HCF already invested lots of money in that development, they want to protect that investment. My point here was just to educated people, and correct false statement which was made few times that EUPL code cannot be reused easily ergo blocks adoption. That is not true and people should be aware of that. If they have facts they can make informed decision that is all. No idea why suddenly we made a big debate about that. We are part of that community same as you guys, I believe that you would respect our input same way as we respect yours.
robert.mitwicki
Since that get too long just shortly, did we created cesrox on purpose, sure we did, we knew what is coming and we needed to make sure that we can secure our plans without knowing what would be the result of the Apache repo. I knew that this would come sooner or later. As you mentioned we started developing rust implementation. In half way through we realized that we need to protect our work slightly better then what was at DIF. We transition to EUPL and we continue developing, donating what was done so far to WebOfTrust since DIF was not interesting to do anything with it. We worked hard to get to the point were we are, we were preparing release of cesorx for some time due the plans of clean separation of components. We can debate who was first, sure but that does not lead anywhere, we had same rights to claim that namespace as anybody else. As I said if we decide as community that for whatever reason cesrox namespace on is better for Apache project then EUPL fine we won't battle. But keep in mind that history on stays with old license as it is, I don't think that we have practical way to erase it due to that I would say that it would be easier to rename repo on weboftrust github. But if that is no problem let's vote and close that chapter if that somehow helps anybody.
daniel.hardman
<@U013F46SDRR>: I have two basic questions: > 1. Is it your intent that consumers of the THC cesrox/keriox repos should be forced to license their applications (codebases that reside in other repos, and that consume cesrox/keriox functionality through its interfaces) under a compatible copyleft license? I am hoping that you will say, "No -- only that any changes to cesrox/keriox itself must retain the EUPL or a compatible license. A derivative work is something that mixes or changes the source code of the work in question, not something that consumes the source code across an interface boundary." That would be a happy answer. If, instead, the answer is yes, then I can't consume your code and still honor your intentions, because I intend that some parts of my company's stack -- not the low-level parts, but certainly higher parts that still consume keri-and-cesr-in-rust -- have licenses that are not copyleft. I think many community members have a similar view. Assuming your intent about copyleft is narrow, this leads me to question 2: > 2. Is it actually legal for a company to build an application atop an EUPL-licensed library without being forced to license the whole application with a copyleft license? If the answer to this question is "clearly yes", then I don't think the EUPL is an adoption problem, and I will happily vote for the whole community to get behind the THC codebase. I will be a strong ally for you. But if the answer is anything less strong -- "probably yes" or "maybe yes" or "no," then I believe there is a major adoption problem, despite your intentions, because legal caution and/or FUD will trump rational analysis. Unfortunately, my analysis leads me to believe the answer to question 2 is "probably yes" in the EU and "maybe yes" in other parts of the world. Please review my analysis and correct it if needed; I would love to be wrong. The wikipedia article about EUPL has a section about strong copyleft. That section has the following encouraging quote: > According to the GPL/AGPL licensor vision, this means some restrictions and conditions regarding interoperability (due to the theory that linking other software with the covered code creates a combined derivative) and regarding compatibility (since no derivative could be licensed under another license, which may create incompatibilities). The EUPL vision that is depending on the EU law is all the contrary: linking makes no derivatives The footnote on this section is to a FAQ from a German law firm. I read the FAQ. They cite the EUPL info on joinup, and I am guessing that they specifically had this paragraph in mind (): > On the other hand, the European law (in particular recitals 10 and 15 of Directive 2009/24/EC on the protection of computer programs) seems to invalidate the idea of “strong copyleft” in the case of linking. According those provisions, any portion of code that is strictly necessary for implementing interoperability can be reproduced without copyright infringement. This means that linking cannot be submitted to conditions or restricted by a so-called “strong copyleft licence”. As a consequence, linking two programs does not produce a single derivative of both (each program code stay covered by its primary licence). Therefore the question is answered by the Directive: the EUPL v1.2 is copyleft (or share-alike) for protecting the covered software only from exclusive appropriation, but it has no pretention for any “viral extension” to other software in case of linking. Notice the hedge phrase "seems to invalidate." I think this wording indicates that there is no legal precedent or case law that confirms/reinforces the legal view that the EC is espousing. It explains the careful wording that the German lawyers used when describing the issue (; translation from Google): "This is also a copyleft license... Nevertheless, the Commission believes that the viral effect does not apply to links ( or to static ) from other programs if they are used for the purpose of interoperability. The Commission is therefore placing the EUPL in a new category of „ Interoperable Copyleft “-Licenses." Again, notice the hedge phrase "the Commission believes" rather than a flat statement of fact. I did a web search for case law and legal precedent that would clarify the legal treatment of "derivative works" under the EUPL in the EU, and I could not find anything -- not an encouraging sign. Perhaps a lawyer would have more success. However, I did find this presentation from a German lawyer that seems relevant: . According to him, the definition is not clear, and he concludes with a note that "Decisions of courts are unforseeable." The presentation predates EUPL 1.2 -- but I think it doesn't predate the section of EC law that joinup cites when it gives its opinion that linking doesn't create derivation. My takeaway from this is that there is *probably* good reason to believe that linking to an EUPL license doesn't create a derivative work under EU law. But as the German lawyer says in the slide deck I just cited, the meaning of "derivative work" is *definitely* unclear/different outside the EU. So even if the answer to my "is it legal to build a non-copyleft app" question is a pretty strong yes in the EU, an EUPL license pretty clearly doesn't guarantee that in the United States, Canada, Mexico, India, Argentina, Japan, South Africa, etc. I am not a lawyer, and I don't claim to have deep insight into legalities. However, I do think that the kind of analysis I've done here will meet or exceed the analysis done by many engineers and business people who ask whether their product can consume keriox/cesrox. If I can't lay my concerns to rest in an hour of thoughtful analysis, I don't think they will be able to, either. Please, please, teach me what I'm missing so I can lay this concern to rest!
robert.mitwicki
> <@U03RLLP2CR5> thanks for questions: > Is it your intent that consumers of the THC cesrox/keriox repos should be forced to license their applications (codebases that reside in other repos, and that consume cesrox/keriox functionality through its interfaces) under a compatible copyleft license? No, only that any changes to cesrox/keriox itself must retain the EUPL or a compatible license. A derivative work is something that mixes or changes the source code of the work in question, not something that consumes the source code across an interface boundary.2. Is it actually legal for a company to build an application atop an EUPL-licensed library without being forced to license the whole application with a copyleft license. > 2. Is it actually legal for a company to build an application atop an EUPL-licensed library without being forced to license the whole application with a copyleft license? Yes
(I think Daniel is looking for for existing precedence)
robert.mitwicki
Regarding your concerns about "linking", you are to the point. EUPL within EU law framework backs statement (according to the provision of European Law (Directive EC 2009/24 recitals 10 & 15) that EUPL allows for linking without forcing you to adopt same license. Best source which I can point you right now is this: To avoid confusion for those who are not law savvy or had lawyer in a backyard, we clearly stated that on every our repo: (each repo link to it for simplicity). Yes you can link it without adopting license for your product. We are just asking if you change something share it back. I think everyone would agree that this is fair deal. There is very important aspect which many does not think about, which is under which legal framework my license operate at? EUPL is clear about that: > - this licence shall be governed by Belgian law if the Licensor has no seat, > residence or registered office inside a European Union Member State. What that means it assure about Applicable Law no matter where you are or what you do. If you wish to change that you can clearly define under which Law you want to operate (e.g. US) but notice that this would be your choice and could have different consequences. You would notice that if license does not specify applicable law there would be always problem no matter if it is Apache, MIT or GPL. For the first time, a public body of the size of European Commission has officially developed and approved open source license which clearly address applicable law for everyone by default. To summarize it, we picked EUPL because: • it protects the code by enforcing sharing • it promote adoption by allowing it to linking with any other license • it provides unify approach to any work not only code but documentation, materials, use cases, pictures ... any digital and non digital content • in our opinion provides sustainable development due to above characteristics. We are not forcing anyone to change their minds in context of Apache2.0, we are happy that everyone would make their own choice. What we are explaining all the time is that there is no reason for any developer within that community to not contribute to EUPL based project. It would serve whole community and everyone around it no matter if he is freelancer or representing company which want to build products on top of it.
robert.mitwicki
btw. what is applicable law of apache 2.0 license on keripy? btw2. the license is just a template since the copyright is not filled, worth to change that :wink:
You do not understand how the Apache License file works. That is part of an appendix explaining how to apply the license to a single file. You are not suppose to change that in a site LICENSE.
michal.pietrus
Our industry has never found a proper way of dealing with IPRs. The status quo is to go and use the most permissive licensing model, either because it is the most straightforward approach from the adoption perspective or simply because other libraries are using such licenses, so it propagates without any further ado. On the other hand, people are getting pissed. For example, there were several known incidents in the Node ecosystem where library authors removed/broke existing libraries, which broke the whole ecosystem because they were bare bones meaning they were heavily used as a dependency. At the same time, the IT industry developed a unique ecosystem to work with because people are keen to share their work/IPRs to make life easier for others. This ecosystem to sustain needs improvements. The permissive licensing model, while perfect for companies from the adoption perspective, completely ignores the authors and contributors. Thus, the current licensing model is broken because the most significant value is precisely in the authors and contributors. Their interest in the permissive licensing model is completely ignored. I fully agree that it is up to someone other than the developer to study licenses, which is this industry's main issue. The current workaround is "use a permissive licensing model," but it is no solution. By proposing this paradigm shift, we propose to change the so-far used licensing mental model to end up in a better place. Whether it is achievable or not, we will see, but doing nothing will not change anything. While EUPL could be better, it brings some significant changes that precisely change the mental licensing model, and we propose to try it. Here, in this particular ecosystem, most of the work is paid work. AFAIK few people spend their private time adding contributions. Thus, while changing licensing model might not be in the interest of the companies behind it, it is definitely in the interest of the community as a whole to take care of the community.
Yes, existing jurisprudence or case law (if any) would come in handy and, I believe, could take away concerns.
robert.mitwicki
Yes, you are right what I failed to communicate is that repo does not seems to have explicitly copyright stated anywhere, which is not a good practice and sometimes cause problems.
<@U013F46SDRR> Thanks for bringing the EUPL licensing topic to the fore. The ramifications go far beyond this community as other core utility technologies in the first layer of the "identity-centric" and "data-centric" stacks will need to be both resolute and compatible to stop potential fragmentation. As OCA sits in the first layer of the data stack, I'm keen to learn from you and others in this community as the discussion comes to a natural conclusion. Thanks for leading the charge on this. Good stuff.
I guess if nothing else, though the original question of crate name has hit a dead end it has enticed folks from THCLabs to participate in the community again... its been a long time. Heck, <@U04F9ME0V39> finally joined the Slack even though it's been around for more than a year. I have absolutely no interest in discussing or debating licenses. I've already made my opinion more than clear. I want Apache2 versions of software to use, full stop. Since we now have multiple members of THCLabs coming out of the wood work to debate licenses and not address the original question, I am willing to concede the crate name cesrox even though we came up with it at IIW back in April. Shame on us for not being the ones to squat on the crate name (and CESR too for that matter) when we created the GitHub repo. If folks would like to continue license debates, we can create a Slack channel for that purpose so we can allow this one to get back to technical discussions of implementing Sam's CESR protocol in Rust.
The argument for me is won by the simple assertion, and the core beauty of KERI and ACDC, that a set of technology protocols for a trust spanning layer must have the lowest bar to entry. This gets at what the wide-ranging ramifications are you mention <@U04F9ME0V39>, and what Sam makes clear in the KERI whitepaper: this is a huge problem being solved. The solution, like HTTP and TCP/IP, are protocols, not application suites. As protocols are defined first in specifications it seems to me there is little to gain for a given company, and little to worry about, taking an implementation of a protocol and using it without contributing back to the community. That, in my mind, would be like worrying about Amazon or Google using HTTP and not giving back to the community.
If there were a suite of apps or implementations that KERI and ACDC depended on their implementations to succeed, like the node software for Indy, then I would lean more in favor of EUPL. The beauty of KERI is that it doesn’t prescribe an architecture like Indy and other ledger software does. KERI is truly ledgerless. It’s just a set of protocols and we happen to be releasing the first few implementations like how LMDB came out of the OpenLDAP project and now has many implementations.
Thanks, Phil and Kent. As the inventor of OCA. I am just here as a fly on the wall for now. However, I suggest that you don't brush the licencing question under the carpet just yet. <@U024CJMG22J> Go ahead and set up a "Licencing" channel and I'll head over there so that we don't pollute this one.
I agree with <@U024CJMG22J> that we should move forward and leave the licensing discussion. The question is settled in my mind. As much as I love the four freedoms and the whole free software movement of which spirit moves and inspires me I believe licensing is a matter of use case. There are some things that GPL2/3 or EUPL1.2 make sense for. There are things that MPL, MIT, or Apache 2 make sense for. Given all of the arguments expressed here it seems that KERI and ACDC and attendant libraries make the most sense to release under Apache 2 given that they are protocols first, software second and that we are going for the lowest bar of entry.
<@U013F46SDRR> and <@U02N7K951DW> I regret to leave the four freedoms behind at least a little. I’m sure there will be other applications and purposes in the space that make sense for that license. If you’d like to move forward with the cesrox name then as Phil said we will pick another one and rename this channel and the WebOfTrust repo. Shall we aim to close this discussion out before the end of the year, maybe early next week?
I just saw your edit Paul. I defer to greater wisdom than I. My goal is to move the discussion forward so we can focus this channel. I suggest we move further discussions to the <#C04FHS9EPAS|keri-cesr-licensing> channel so we may limit this channel to the CESR protocol implementation. This has been a lively and engaging discussion. I look forward to learning from each of the perspectives present.
And, really, maybe we can just work together to have a few implementations of the same thing. Maybe a few different perspectives will be valuable in the long run. Disagreement is healthy and conflict, well managed, is also a sign of a healthy community. I welcome this sort of dialogue.
Paul- I'm not familiar with OCA. Is there a community discussion group I can join to learn more?
I agree with Kent here. I've seen plenty of communities with multiple implementations of, for example database drivers in the same language. I'm sure it will work here as well. Choice is freedom, no one is locked into anything.
Sure. The at HCF is the group that will maintain the official . The next call is on *January 12th*. It is an open call. We have also recently started an channel on Matrix. The OCA experts are keeping an eye on that channel.
robert.mitwicki
Since we now have multiple members of THCLabs coming out of the wood work to debate licenses and not address the original question, I am willing to concede the crate name cesrox even though we came up with it at IIW back in April.
<@U024CJMG22J> I thought that we agreed that we would collect voice of the community and decide on that matter. I really don't understand why you come up with that statement. So far nobody actually presented his opinion on cesrox namespace topic expect me, you and Kevin. I derived from <@U024KC347B4> and <@U024CJMG22J> comments that both vote for using cesrox namespace for the project under Apache2.0 without addressing my questions about consequences related with impossibility to remove previous license from it.
robert.mitwicki
Since we would like to decide as community I would suggest to decide on next regular meeting of cesrox where we have all interested parties to address that topic.
robert.mitwicki
If someone would not be able to join suggest to do it on this channel in a form of comment under below thread.
robert.mitwicki
as addressed above we would like to make a decision about cesrox namespace allocated under . Namespace was allocated by HCF team for implementation of CESROX which was in development since quite some time. Since that implementation is under EUPL1.2 license and was allocated without consultation with community we would like to find out how to move forward. In my opinion the most fair solution would be to hear everyone voice and based on that decided on potential transition. Please try to answer following questions and if needed provide additional comments or information relevant for that: 1. Would you like to move cesrox namespace on allocated for EUPL1.2 implementation of cesorx to Apache2.0 implemenation? 2. If transition would be done, are you aware that under that project the package would include 2 conflicting licenses in the history of crate and you don't think that this would be problem from adoption perspective and won't confuse people trying to use it in the future? 3. If you are in favor of other solution to address that conflict please state it. Please comment in thread what is your opinion on that conflict, providing argumentation if any, your affiliation if you represent bigger group, your interested, stake and type of the contribution which you did and/or planning to do to help others justify your voice (all voices are equal but it would be unfair in my opinion to do voting anonymously). All information would then collected and final decision would be taken during one of the cesrox regular meeting (if there would be enough time for voting we would like to do on following meeting if not we would do it in two weeks.
robert.mitwicki
I am Head of Technology Council at Human Colossus Foundation, and CTO at MeDDEa Solutions. HCF is early adopter and implementer of keri ecosystem components. From day one HCF togheter with Jolocom and Argonauths build first rust implementation of keri components (including cesrox). After realizing risks related with the licensing we decided to change license from Apache to EUPL to protect community, donating in the same time implementation which we did on Apache2.0 to WebOfTrust repo as previously it was developed under DIF. Observing activities within our community I realized that few people would like to reactivate rust implementation of KERI under Apache2.0, I was happy to see that finally people notice values of multi-target source code which definitely would help with adoption. We were working on those project since 2020 and had already plans to extract components of `cesrox`, `said` and `teilox` as separate crates, I took immediate decision to secure the namespace. If it was fair or not you would judge. Both as HCF and MeDDEa we invested quite number of resources and money in development of those libraries even that is very early we already have some customers who are starting using them. We continue investing and committing for sustainable development and support of this community and rust implementation of keri components in the future. Because of the mistake I created both namespaces on `cesr` and `cesrox` - `cesr` is not used since following the naming convention the intention was to name create as the git repository for marketing purposes. Unfortunately there is no way to remove namespace on . We do not control or own `keri` namespace as it was stated in the first comment by <@U024KC347B4>, this belongs to DIF (or at least members of the DIF group) we do not intent to use or have neither `keri` nor `keriox` namespace at since those would not be libraries and does not make sense to distribute them through . Answering the question: 1. I would vote against moving `cesrox` namespace due to practical reasons. There is some hassle for community which is already using `cesrox` and would generate confusion on directly due to change of license. 2. I am aware of that issue and I see that this could not look very good and could generate questions about licensing of the whole crate if it consist of some EUPL code. 3. Since `cesr` namespace was allocated as well with EUPL would generate same problem but would not make any addition effort for those who already using `cesrox` I would suggest to pick any available namespace and create it from scratch to avoid problems in the future. I would like to add that neither personally nor as representative of HCF and MeDDEa I am not against Apache2.0 implementation and I am happy to see others contributions and their choices. Releasing the namespace on crates is as well not a problem although I think it won't be fair on front of all those developers who worked almost 2 years on those projects just to take it without solid reason. If the community would vote in favor of that transition I would be happy to assist and help to do the transfer. It is just a name and we still relatively early with adoption that won't cause negative impact. I just hope that after that transition, commitment of those who vote in favor would make sure to keep this package in healthy state as we would do it.
I was changing my vote to “I don’t care”. The name can stay where it is as far as I’m concerned.
The next regular CESRox meeting is this Thursday the 22nd. Due to the Christmas holiday it may make more sense to meet on Jan 5th, the next regular meeting. This would give us time to assemble arguments and notify interested parties to be there. On the other hand it would be advantageous to make this decision as soon as possible. If we have any major parties missing on the 22nd then I suggest we reschedule.
daniel.hardman
I am Daniel Hardman, CTO of Provenant. I think that as a matter of fairness and courtesy, the names "keri" and "cesr" should be treated as property of the inventor. (Note that the preceding sentence is not a statement about copyright law or legal theory, but about simple human kindness.) Going slightly further, Sam is writing IETF specs and using those names for them, and I think it is preferable that reference implementations of those technologies carry approximately the same name. This does not exactly answer the 3 questions, though. I'm just stating some principles. I think the "ox" in keriox and cesrox is cute, but is not fundamental to the question, so the fact that those names have been allocated is perhaps suboptimal but not a serious problem. Therefore: 1. I guess I vote against trying to move the namespace, on the theory that it's a lot of bother and it's easier to just invent a new name. 2. Having 2 conflicting licenses is not a problem at all. Happens with maybe half of all repos that ever existed, because if they didn't have a LICENSE file in the initial commit, and get one later, then they are in the 2 license state. The only thing that matters is what LICENSE applies going forward.
daniel.hardman
3. I am not in favor of any other solution, but I think we should acknowledge that it's desirable to do two things going forward: 1) clearly announce forks in the road with respect to licensing; and 2) try to communicate and honor the intentions of an inventor with respect to the names (not licenses, just names) of technology they invent. We live in an imperfect world, and I think people's intentions have been to do the best possible things they could, so that is not a criticism of anyone -- just a note about lessons learned.
robert.mitwicki
I am good with having it on 22nd if this topic of the cesrox namespace is blocking someone, if not we can wait until 5th so people would have more time to react. If the "voting" would be clear on slack we don't have to wait until the meeting and we can do it even "offline" no problems.
> and it's easier to just invent a new name. Sold.
I won't be joining on the 22nd. (family obligations) I agree with Daniel.
<@U03SYCGJ4Q7> has joined the channel
+ 1 -> I won’t be available Thu 22 and I support Daniel’s proposal
Seeing four votes in the negative (myself, Trent, Kevin, and Henk) and one to the positive (Robert) It looks like the 5th of January it is. I suspect this trend would continue. Thank you all for your contributions during this busy time. See you all then and enjoy your winter holidays.
There is no CESROX Biweekly meeting today due to the holidays. See you all in two weeks.
Reminder: the next step in the culmination of our licensing chat is occurring tomorrow morning / evening at the bi-weekly CESRox meeting. The zoom link is in this channel description.
The working agenda (feel free to add) is the following: 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)
In case I am late this morning (Thursdays/Fridays I drop my son off at daycare, unfortunate timing) I figured I would just put my thoughts here: 1. For me there is no naming strategy/releases and/or transfers to discuss. My original ask was answered with “No“ (I paraphrased) due to the history mechanism present in . If people want to debate renaming what resides under web of trust, that’s for the community to decide, I have no opinion. 2. For me there is no license strategy clarification moving forward. There are two implementations under two different licenses, the community is free to contribute where they like, such is open source. If you want to vote to change the license under WoT to EUPL-2.0, just contribute to the THCLab one, and vice versa. If the community wants to vote to remove one or the other, I would say that is excessive and let bygones be bygones. 3. See #2. While I appreciate Daniels suggestion I feel that having all THCLab efforts be derived from an Apache-2.0 and then subsequently relicensed by THCLab under EUPL-2.0 downstream would not meet their requirements, hence why they moved to EUPL-2.0 in the first place.
joseph.l.hunsaker
name suggestions: cesr-lib, cesr_lib
joseph.l.hunsaker
Looks like <@U024KC347B4> suggested cesride :slightly_smiling_face:
Good ideas.
Thank you to all who attended today’s meeting. A few important events happened today. 1. The group has been renamed for broad applicability from the CESROX Working Group to the CESR Working Group as is reflected in the channel name changing from `#cesrox` to `#cesr`. 2. The naming and licensing fork was acknowledged between WoT and THCLabs. As a result this working group is coming up with a set of names, headed up by Kevin Griffin, to be voted on next meeting, Thursday January 19th. Suggested names so far include: a. CESRust / cesrust- Steven Milstein b. CESRide / cesride - Kevin Griffin c. cesr-lib - Joseph Hunsaker d. cesr_lib - Joseph Hunsaker 3. Focusing of this group on the core API of Rust CESR and the foreign function interface (FFI) layer required for cross-language usability. Next meeting we will vote on a name for the WebOfTrust repository and continue our discussion on the core API and FFI layer.
See the for a full listing of the minutes.
I will suggest a name: `cesrase` the -ase suffix is like an enzyme as in lipase for digesting (or processing) fats, protease for proteins, and amylase for carbohydrates. cesrase for KERI matter
This is interesting to me, but are you concerned about the double and similar meaning of 'digest' (to process vs the explicit product of a hashing process) in this context? `cesr-rs` is another suitable repo name based on what I've seen in the rust community, but I believe the package/crate names of such repos may sometimes drop the `rs` which could pose a problem here.
Good point on “digest,” I wasn’t thinking about that. Now I retract my submission. I was more making a suggestion to stimulate discussion.
naming is hard, don't over think it :)
<@U024CJMG22J> Does signify-ts implement {,de}serialization? If it does, can I get the name of the module?
Poll for renaming WebOfTrust/cesrox > :balloon:CESRust > :wolf: cesr-lib > :dog: cesride > :robot_face: cesrase > :ghost: cesr-rs
+1 for cesride
You're supposed to vote with Emojis!!
got it, thanks for cluing me in
daniel.hardman
<tongueInCheek>How about "JuliusCesr" or "CesrAgustus"?</tic>
daniel.hardman
or "LittleCesr"?
JuliusCesr’s LittleCesr? Where are you taking us, Daniel?
rodolfo.miranda
I think that was because Daniel was lately involved with the Middled Ages: :grinning:
> _Metaphors are a two-edged sword_. Oh the irony
joseph.l.hunsaker
CESRide also fits the strict definition of -ide. Oxide is “oxygen with another element”. CESRide is CESR combined with another “code table” of a particular genus/version :)
Screen Shot 2023-01-19 at 9.40.27 AM.png
daniel.hardman
I didn't even consider that when I wrote the line, but now that you point it out, it's hilarious.
rodolfo.miranda
you convinced me! :dog:
The `cesride` and `parside` repos have been transferred to WebOfTrust here: •
Nice work Kevin!
Here’s the meeting link for this week’s meeting: Passcode: +0cL#2DW
I organized the notes for this week’s meeting into the section rather than having everything in the agenda. Keeping the notes in the Notes section makes it easier to link to individual sections of the notes as you will see below. In this week’s meeting we covered some important topics: • For those new or coming up to speed to CESR I recommend reading the meeting minutes for this week.
Over the weekend I implemented `Matter` in `cesride` at parity with `KERIpy` (I believe). Here's the code: It can probably use some more work, I'm a fairly new Rust coder (2 months but pretty intensive) but it's a good start. <@U024KC347B4> you probably want to check this out as I noticed you made some changes, too. I can open a PR for review if people want? I'm willing to contribute a great deal to this suite of projects in Rust. I tested this by instantiating `Matter` several different ways, in one gross function. It grew out of what was there, I just kind of took the path of least resistance but this is where my work could benefit the most, I believe. Better tests. I will add them later. I did generate lots of tests for `Sizages` and `Codes` though. Normally I wouldn't throw down a 1300 line PR but this is a foundational bit that was hard to get away from. For the curious, I used string transformations in Ruby to turn Python codexes etc into Rust code directly.
Sorry if this is spam, just noticed the <#C04LNE87GHE|cesr-dev> channel
I created a <#C04LNE87GHE|cesr-dev> channel at the weekend for github spam as well for notificationsn of PRs/issue assignment etc
Hey guys. I'm looking into the cesride code and trying to understand the parside one's functionality. As I see currently cesride's Matter::new_with_code_and_raw() does analyzis, reading and parsing primitives by itself. So the logic of the parser is to read the top level group and call the proper codex table implementation. Very primitive pseudocode is like:
    pub fn from_bytes(bytes: &[u8]) -> CesrResult<CesrGroup> {
        let (rest, payload_type) = take_bytes(bytes, 2u8)?;
        let (rest, group_len) = take_bytes(bytes, 2u8)?;
        let (group_item_records, item_table) = cesride::get_group_codex(payload_type);
        for i in 0..group_len {
            for i in 0..group_item_records {
                let (rest, bytes) = parse_primitive(rest);
                current_item.append(CesrPrimitive(code, bytes));
            }
            group.append(current_item);
        }
        return group;
    }
My understanding from all the discussions was more like:
• parside calls cesride for fixed size types to get the size.
• parside calls cesride to get the counter group description (how many primitives are a single group item).
• parside reads all codes and data by itself.
• additionally cesride either
    ◦ provides information about what special parser to use for such types like datetime or url-like strings or
    ◦ provides the parser callback for such types
• cesride does not contain any verifier, signer, digester and so on crypto stuff. It's all the keri logic and not related to CESR at leas as I can read it in the draft.
Can someone please help me to better understand it?
<@U024KC347B4>, <@U04HQD29Z7E> maybe you have a thought?
I'll write up my thoughts, perhaps we can discuss tomorrow
:+1: I will say that in general `cesride` is under active development and pieces aren't all there yet. `Verfer` and `Diger` can verify signatures and compute digests, respectively, though.
About my last point: > cesride does not contain any verifier, signer, digester and so on crypto stuff. It's all the keri logic and not related to CESR at leas as I can read it in the draft. Yes, it's okay if we combine cesr data tables definition for `parside` with keri crypto primitives logic in `cesride` since `cesride` is designed for keri and crypto primitives. Other points still not clear for me.
Parside is responsible for initial stream introspection, I'm guessing a vec<u8> entrypoint (whatever we can work with the FFI, can you use a future::stream in the FFI?) It peaks/sniffs the first tritet of that vec/&[u8] determines, is this a binary or text stream, at that point it passes it off to a Binary/Text Parser, those parsers will peak the stream (I'm going to keep saying stream but I mean whatever vec/u8 we can work with the FFI) that peak will determine if it's json/cbor/msgpk encoded, then use the vesionage to determine the event size, likely discard that... because why would cesr know about your domain objects, then hand off decoding to the requisite parser which will create CESRide primitive objects out of the remaining stream bits.
Some thoughts from Sam on parside > Parside should start with a default version for CESR. Anytime it gets a version count code it changes the version and also elevates to the top level (the version count code must appear at the top level). The version count code determines which CESR table to load when parsing the stream. The sniffer detects if CESR binary, CESR Text, JSON, CBOR, MGPK. If any of the last three then the parser regexes to find the version string inside the JSON, CBOR, and MGPK and from the version string extracts the number of characters/bytes that is the length of the JSON, CBOR, or MGPK. The parser then resumes sniffing. When the sniff is CESR then when at the top level looks for the CESR version count code or any other count codes. The interpretation of the count codes is dependent on the version count code that is why the Parser has to start with a default version count code because the stream may not begin with a version code or may have resumed after a cold restart. When a count code is parsed then the parser may descend into parsing whats inside group for a group count code which may recursively nest down a ways.
I am in a meeting that is going long. Can someone take the start of today’s meeting for me?
Can you please share the agenda?
I can sit in for you until available
thanks Steven!
Kevin, thank you for clarifying it. Here are my follow-up questions: > the parser regexes to find the version string inside the JSON, CBOR, and MGPK and from the version string extracts the number of characters/bytes that is the length of the JSON, CBOR, or MGPK • So any stream appearing to CESR parser must contain the version string not the only inside CESR data but in JSON, CBOR or MGPK as well? Ever if we talk not about KERI, but just about a custom data tables implementation? • I'm not close to CBOR and MGPK spec, but it's binary so wouldn't regex have collisions? > When the sniff is CESR then when at the top level looks for the CESR version count code or any other count codes • Am I correct that the top level here is an exact `--GGGVVV` as a root object in the stream? Not a kind of a first item in a top-level box like `-VXX--GGGVVV-A<following data>`? Just looking to Keri streams I see data flow like `{json msg}-VXX<cesr box>{json msg}-VXX<cesr box>` So version switch here will look like `{json msg}-VXX<cesr box>{json msg}-VXX<cesr box>--AABAAB-VXX<alternate cesr data box>` . Correct? And just common one is how parser appear to an application? Provides callbacks or returns an iterator or a vector of parsed data?
Waiting for credentials to start zoom
Kent you might need to start the meeting though
> So any stream appearing to CESR parser must contain the version string not the only inside CESR data but in JSON, CBOR or MGPK as well? Ever if we talk not about KERI, but just about a custom data tables implementation? I'm not sure I agree with "as well" currently json is the only serialization we use and it does have a versionage, I imagine the CESR event format will as well, but that's still only one versionage per event
> • I'm not close to CBOR and MGPK spec, but it's binary so wouldn't regex have collisions? I don't know the answer to this.
So while we wait... how is everyone doing this morning??
Fine, I can pick the Zoom link of the alternating meeting on Thu’s and start it up + share it here
_Several people are typing_)
Wonderful! We're going to hit a wind chill of -33C, -27.4F today
sorry, yes, still in my meeting. Please start a new one without me.
Yeah, its a little chilly here too today, only supposed to reach 68F
> I'm not sure I agree with "as well" currently json is the only serialization we use and it does have a versionage, I imagine the CESR event format will as well, but that's still only one versionage per event Yep. As well we can stay on the current one if there is no version included.
> I don't know the answer to this. These questions are more points for discussion ))
Yes if you don't get a new version you would continue parsing the stream with the same parser
That meeting took a long time. Thanks Henk
No worries, notes here:
<@U03EUG009MY> the zoom recording link, already added to the notes
Wonderful, thanks again.
posting here for visibility. TL;DR: any objections on me starting work on `parside` and integration with `cesride`?
There is a thought I want to share and discuss. It's about FFI. Now we have 2 projects and 2 rust libraries. To simplify external use of it and the delivery process I'd like to have FFI a single project providing both parser interface and the default primitives implementation at once. So I see it a separate GitHub project that would depend on parside and cesride.
But then you'd be pulling in everything if you only needed some. It can be argued the linker will save you but distributing the library etc becomes cumbersome. What if a project doesn't want to use the parser?
Is the goal to simplify the integration upstream? I don't see why another library as you suggest couldn't be built, but I think the core, `cesride`, probably needs to be independent as well.
This is great, nice work Jason. You, Kevin, and Dmitry are powering through this.
Hey folks. A couple of branches just pushed for review of our view of the parside design. Review and feedback is highly appreciated. <@U024KC347B4> <@U04HQD29Z7E> :pray: This one returns custom generic type without particular groups definition. In this case we need to create a third crate combining parside and cerside defining groups constructors. This one contains definitions of groups that makes using of the libraries easier for third party applications. We just need to add constructors there. With this approach we don't need for a third crate. And there still one more question: Why we do not want to define exact cesr groups inside the cesride library? Since we already define a lot of things related to keri just there.
Also I've finished porting of `Indexer` into `cesride` tomorrow will get tests done and publish a PR.
I have a branch and an existing PR for Indexer?
:man-facepalming: I needed to check it first... I'll take a look. Thank you.
Given Daniel was worried about the use of your time, that seems like a massive waste of time and duplication
I was planning to push bexfil today which is the last method but my son was sick
I thought you were working on `uniffi`?
Sorry I should have checked earlier but didn't have time - there are no PRs associated with these branches. Do you mind opening them so we can leave feedback? You can do it against the `DSRCorporation` main branch if you don't want to open one more publicly yet, but it would be great to be able to leave comments on a PR.
This was meant for Dmitry, I realize now it followed Kevin's comment which was confusing.
To work on UNIFFI I need parside. Parside needs some more types in cesride to fully function on sample cases we want to use. So since I have Artem on this week we decided to go this way.
<@U024KC347B4> <@U04HQD29Z7E> I'm implementing dater class now. ))
Thanks, it seems I cannot assign issues to people who are not part of the WoT org, and since this is Sams "free" org I am wondering if we can just implement some house keeping rules: • Comment on an issue if you are deciding to work on it • Open a PR and set it to draft, then reference the issue in the comment, even if there is nothing in it, it is another indication that someone is working on it • Lastly, mention it in slack. If these make sense I'll update the readme too, this applies to folks within the WoT too.
Working on `Sadder`/`Saider`.
I realize they aren't necessarily done together but I found it easier to reason about when working on both.
We're having an architectural discussion now about a change in our test code, and there is a new issue I just created in the `cesride` repository. If you want to participate please add your two cents in the comments, or look in <#C04LNE87GHE|cesr-dev> if you're not a GitHub user. We also need to agree on how we come to consensus for issues like this.
I won’t be able to attend todays meeting, we’re at the w3c vc working group face to face meeting.
Enjoy your time there. I hope the W3C VCWG meeting is being fruitful. We will cover the rstest PR and the UniFFI PR.
joseph.l.hunsaker
<@U04HQD29Z7E>’s comment that UniFFI should be in `parside` made sense to me. Does it belong in `cesride`? My gut says no.
<@U04HQD29Z7E> <@U024KC347B4> can we schedule a meeting some day?
Yeah I'm thinking to remove all remnants of an FFI from cesride
There is pyo3 garbage in there I'd like to clean out
Not garbage but it's not complete by any means
I know Kevin is at the W3C thing this week but I can be available when he is, <@U048YRLFKTK>
I'm traveling tomorrow so I would prefer next week.
I'm okay with any time working for you both.
I would love to be in on this. I will make whatever time works for you three work for me.
Sure man!
As most know there has been a slow progress on getting the first parside PR merged due to conversations around the impact on cesride. We had a working call this morning with the developers involved to try come to a path forward ahead of the regular community meeting. The path forward is as follows: • ~Review and (hopefully) merge outstanding PR #103 (<@U024KC347B4>, <@U04EFUFR71Q>, <@U04HQD29Z7E>)~ :white_check_mark: • Create a new PR for a version bump for cesride and publish to (<@U024KC347B4>) • Create a new PR which introduces a thin UDL layer (for uniffi) for cesride to expose the primitives needed for parside (<@U04EFUFR71Q>) • Update the parside PR #2 to use this (<@U04EFUFR71Q>) • Merge ... • Celebrate :tada: I'd like to thank <@U04EFUFR71Q> <@U048YRLFKTK> and <@U04HQD29Z7E> for their work on coming to a resolution. As a side note, we should discuss an approach to releases on Thursday.
This is soo cool! It’s awesome how you, Dmitry, Artem, and Jason have taken this and run with it. I hope to contribute soon. I look forward to the meeting this week. Celebrate indeed! :tada:
artem.ivanov.konst
PR adding uniffi/udl for cesride -
Once I’m done with my next credential issuance tutorial blog post then I can help out finish anything else that isn’t done.
I feel my comment is of interest to the community and something we can discuss tomorrow.
:tada: I wrote some (expand `` and search for 'fn incept') using `cesride`:
❯ cargo test --release core::serder::test::inception -- --nocapture
    Finished release [optimized] target(s) in 0.12s
     Running unittests src/lib.rs (target/release/deps/cesride-1a488cfa0f1e0735)

running 1 test
{
  "v": "KERI10JSON00015a_",
  "t": "icp",
  "d": "EBAjyPZ8Ed4XXl5cVZhqAy7SuaGivQp0WqQKVXvg7oqd",
  "i": "BEy_EvE8OUMqj0AgCJ3wOCOrIVHVtwubYAysPyaAv9VI",
  "s": "0",
  "kt": "1",
  "k": [
    "BEy_EvE8OUMqj0AgCJ3wOCOrIVHVtwubYAysPyaAv9VI"
  ],
  "nt": "0",
  "n": [],
  "bt": "2",
  "b": [
    "BC9Df6ssUZQFQZJYVUyfudw4WTQsugGcvVD_Z4ChFGE4",
    "BEejlxZytU7gjUwtgkmNKmBWiFPKSsXjk_uxzoun8dtK"
  ],
  "c": [],
  "a": []
}
test core::serder::test::inception ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 733 filtered out; finished in 0.00s
Now you need to sign it and get KERIpy to parse and accept the event. I was ecstatic when I got that working from TypeScript in the signify-ts repo.
I found use of this code in `Salter`: > `crypto_pwhash_ALG_DEFAULT`: the currently recommended algorithm, which can change from one version of libsodium to another. Though I don't see Argon2 being replaced for a while, I'd recommend fixing your algorithm so the results don't break. Probably (need to confirm but usually the default), you want: > `crypto_pwhash_ALG_ARGON2ID13`: version 1.3 of the Argon2id algorithm, available since libsodium 1.0.13. You may also want to make the params fixed (and apparently only 2 of 3 are available through `pysodium`). ref:
If you never need to update this won't matter but if libsodium needs a security patch you could be put in a tough spot.
That would be controlled how we update to a newer version of libsodium, no?
At that time we can consider it. Also, as we are not currently relying on HDK generation (we store the keys encrypted) we should be OK, except for test cases I guess.
But back to my point, it seems like Rust is only a few classes away from creating full blown KERI AIDs and that's very exciting. The jump from there to a Signify client in Rust is not very large.
signifide!
(you have to shout it like testify)
Yes definitely Phil it is not a worry unless you update the lib sodium, and like I said I really don’t expect it to change from argon2 any time soon. And yes, totally working on getting more than the canned inputs running! I am hoping to have another PR available for review later today
Signifide! This is exciting. Nice work Jason.
<@U024KC347B4> <@U04HQD29Z7E> here is my WIP PR for Wasm JS FFI for cesride. Please let me know what is your opinion on this.
Created to lock the KERIpy params down
I got around to building a simple `messagize()` and signed a more complex inception statement, but I wasn't sure what to use for the path when generating `Signers` from a `Salter`. I generated current, next and witness keys. I know I didn't need the witness ones (or technically even the next keys yet) but I want to make a receipt. Anyhow, here's the output, but unsure if it will verify given the paths:
{"v":"KERI10JSON000300_","t":"icp","d":"EJN_1ByBZfQK4yVbfL8t6C0WO-9X55xnkjSVg6OYKUGN","i":"EJN_1ByBZfQK4yVbfL8t6C0WO-9X55xnkjSVg6OYKUGN","s":"0","kt":"2","k":["DP6rJryvYNYhtfOXAOsA7VKptTGbU3PfE7ugVCQTfhuq","DB4Fh_JkHsJ-_PDk3FbfDDgX-u7cu3mfyxIcmMS6TEiz","DGbBAkbnpP9g78-iJDjNbioWr2bcKi2hGFAHDvXxTQAu"],"nt":"3","n":["EEmtLscNZf87Td_JCVZzzmK2SYAhqs8PSV1WsWShJdMS","EOCuLVqUXPpQfpRNL4pNg6GyS0cUFcM2M_b_alILJMPk","EHP6YessHe09MWCotVmyyEfXzMT66TGjB56vjOv7o8Gm","EEako_0sFaq4YQmhypTy_PgXHQWYpVnl95-AMr-E5VH6","EAmJWaLjOPGytGa5Jl7uT-PkPipR4s82EZgfMOoDUmC1"],"bt":"4","b":["DJX_JO8xfykJqHjoHytS1jxACIor043J2saj4Wte3dTP","DOC0HYilRrHIN1RvCIMG8TwqMegJcb0tau6RImpbWFHn","DCXgzFR2DsDMdcYiaJ-bNVEEWhJymDN5l12qQ8FCIbvi","DHsE9SUFWytLN0rvT9IGX319CghRu5VS3Ru8C4TFzLjm"],"c":[],"a":[]}-AADAAAfeJquPVy7lHXH4461kCyu58ysyVGpWk91-KwqxSyHvkJJmLm204Tr3LuQQ0xL05iXQzTZDS58Y6PW6HLALywOABCsGMgj0FsXCHhfgjuuQGWdg1pahBxDH4P5PdUnm0SGEUvsGeIf8yZpgHxZQPJ50Cvy5LnSdla-_gQgkh-8QKQLACBoJ8HZDCbxVznJjgrLOjLQC5EQI9wysWd7c5W1LtzckxbTvDrij6Q-Qn-HMXm9he8D55INA7kZlSVA93BIslUE
I mean it should verify obviously, and now that I think about it, why would anyone else care about those paths used to stretch into keying material.
So my next question is, does anyone know how to use `kli` or something to check this? Or do I need to write some python code now?
In the eventing tests - why are receipt `keds` created _before_ their events? Was it just to simplify the test code since the keys are all the same? Or am I fundamentally misunderstanding something?
The seal I suppose, that's the unique part? And it gets created after.
❯ cargo test --release core::salter::test::vault -- --nocapture
   Compiling cesride v0.1.3 (/Users/jason/src/jasoncolburne/cesride)
    Finished release [optimized] target(s) in 9.04s
     Running unittests src/lib.rs (target/release/deps/cesride-f97c311909e1fac0)

running 1 test
inception message:
{"v":"KERI10JSON000300_","t":"icp","d":"EE8xDuqkA2IaYEsw2D0qjx91Kqyc0AUn56S_yVJbuoRU","i":"EE8xDuqkA2IaYEsw2D0qjx91Kqyc0AUn56S_yVJbuoRU","s":"0","kt":"2","k":["DBfox0sPV36fj8iZ7oNiiMOzUpeW2tM-XK727bEARo6e","DHfj5y5M1AVaGbCusFfaw4IQ9YOND8JpTU12GRy7s2hU","DEkzXDZOQAaACEct5AqMhBGuXgkK4Y30HkzGuAOiJUty"],"nt":"3","n":["EO4V3zcv9IvTSpvfKTCqsNaH_TcOQsyt-_4hFkiKOLjH","EMqOxMRWnMiWmmEqRxjNQAtMWfRZ4laQrzpGqnbUr2NT","EAoliGcL-ewtuad3JZu3dNSASsY6yIQjoaVtOXxXxxp4","EEEd35vdZM3892fUb6Fv4ejY9bl80LD9AW-z6hHAO9H8","EDfWJ2XpfVYbNr_qJs2l44LDezBsPg3W7jZEzjTQfPDg"],"bt":"4","b":["DDni1WuRgVbNHXFdh03W9od84zvU6oH9dbaUKkrtforR","DL_OPGUlBsPx4_ZZbqWXpu5qAuhC3Nbrq3F7impZ_ZNy","DJ8T56HzD_YPPeXFtd5s-4qIt_j5zIVrmhZeOLN0DrBN","DJh8EITH0bLP1dO5S8hBZ_QqQOOgmood5zozR3d9vOTd"],"c":[],"a":[]}-AACAABrBTA2zXJ5DciFFHKkMocegsu8z9Nb3FaoXw2D2SljGUhai5MtxTHrk1oi1epMeYTZilfwUHl4ygYTKmCqmggKABBo1fBxtHkN3WFoulqCihZl0VEBbjT1t6qdrkHcV9Z8L-EJo93AgcJyf6oAYa5zSqcZIuplAxO-WZNdxeXmygYF
receipt message:
{"v":"KERI10JSON000091_","t":"rct","d":"EE8xDuqkA2IaYEsw2D0qjx91Kqyc0AUn56S_yVJbuoRU","i":"EE8xDuqkA2IaYEsw2D0qjx91Kqyc0AUn56S_yVJbuoRU","s":"0"}-BAEAADHbUcPIpsyN-15CbZ6HOpL16vXd0T9NO9duf2rxMoCjXO1H5p_-nj7qNbfgVxOgHREefT1Y8D9ZneJIiBMAaIGABAk-I3Df2RCdf2v3phYidIUOc6Dxi5I_fRBOEeyDFOENggKqAYMGA26zsk_Uy-Ncp6vSVvYFs1GaZutsn5q7S8CACCXWeiVt_2TDkzMf7NRh7HmhPSv989_BZ2qviT5arvtn2PYdM-LaGN-8j31djhWV4Fm85zfATh6LIIYMDUrrSsPADDcuOc2368NBvFjysI4eXjUWYfvfux0bu8tt06xb3UurxAD9bk4Q_FbRGvTyluTO0eMNamn-BcNmaQaDa5xMrgE
test core::salter::test::vault ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 735 filtered out; finished in 1.53s
Just realized I put a -1 in the wrong place. I'll edit.
So now, there should be 2 sigs of 3 on the inception message and 4 witness sigs on the receipt. I think I created the seal correctly.
Oh or now that I am looking, the seal is only processed when key signatures are present, not just witness signatures. Maybe that means I need both on the receipt?
Here's one generated that way:
❯ cargo test --release core::salter::test::vault -- --nocapture
   Compiling cesride v0.1.3 (/Users/jason/src/jasoncolburne/cesride)
    Finished release [optimized] target(s) in 8.32s
     Running unittests src/lib.rs (target/release/deps/cesride-f97c311909e1fac0)

running 1 test
inception message:
{"v":"KERI10JSON000300_","t":"icp","d":"EJmzggABxNrBI17K7Y8Zv5TDD_lhc25c9wC3N4xltysD","i":"EJmzggABxNrBI17K7Y8Zv5TDD_lhc25c9wC3N4xltysD","s":"0","kt":"2","k":["DAqiSYrtB8SOEJXaqDPkGzI91skKGLcSalWx0iwRuDUt","DKl-_PCqYQ1QmjgdB7QripUMud7V-ldPz6ALKV2sLsoe","DA4LL6M1-qPOBUEA2F2KcsqOvg-e28Pr5W7jrw4kGQxx"],"nt":"3","n":["ECd8fH4HAw_iYExJfyYiH44c4rCEo9CiRc4rKmi6_u7R","EIdmeCMt2Qh2L49vsBr41_TbMuUiStDax-Hsci6SJ2g8","EBAXw1zBfOfbhintSQpMX2dBGMRAf18ngFw-o6Es9p9A","EH08r2wJy8mBfAQT9QIuoP6LyccfIM5dufjNX7dZx7Cq","EKWzcHeqYe1IhflddRNGFSXBTL1N54dd2xlaBtQmsfoI"],"bt":"4","b":["DOnASIVyCs64lepC5DkXbTfclov86ZD8C0PwsrbsXNyY","DC1gzwwkHDck55L_NsgLc7X9GroIqrsTWKj5qjrAhu-7","DJ_v8vTe7QiTnAiBEcOQUp_OMPqq5zXvXzDCzC5IvG8N","DGxv9WaDRH_gyPCJUPmBjqBrptLQLU5Q-E08kKvTQHZC"],"c":[],"a":[]}-AACAACMVbD2lWbwdIw3Kp5iJpX2EriuSyAYnMuTuNNQ_WkUNBtDd89grWfdz7cAJcaa6hm_RWWB9wtO5I09SFXqZ0MOABBPGyphE8V7dWEQDjEVICrLa4FH_eCa6Tkeu5eaoTRA_DzifY3FKvwb5HHbs4qnLhRLAzZaflqRs03tiTGk_UYC
receipt message:
{"v":"KERI10JSON000091_","t":"rct","d":"EJmzggABxNrBI17K7Y8Zv5TDD_lhc25c9wC3N4xltysD","i":"EJmzggABxNrBI17K7Y8Zv5TDD_lhc25c9wC3N4xltysD","s":"0"}-FABEJmzggABxNrBI17K7Y8Zv5TDD_lhc25c9wC3N4xltysD0AAAAAAAAAAAAAAAAAAAAAAAEJmzggABxNrBI17K7Y8Zv5TDD_lhc25c9wC3N4xltysD-AACAACMVbD2lWbwdIw3Kp5iJpX2EriuSyAYnMuTuNNQ_WkUNBtDd89grWfdz7cAJcaa6hm_RWWB9wtO5I09SFXqZ0MOABBPGyphE8V7dWEQDjEVICrLa4FH_eCa6Tkeu5eaoTRA_DzifY3FKvwb5HHbs4qnLhRLAzZaflqRs03tiTGk_UYC-BAEAAD8zDPTJFBqPCNeLHWfgrvQxbJxesZeifCOHnx98dcfRo9uTbWbw6MyucwGvAlqiEcQWOlB1RR_X-5cgAZyCr0MABAappd4NimsQ6ig5-KzX3kLPz7QgbRYHA14lZACfvS4M6WuFnnR6e4-6ZOgYG0mwfcaK72FOTUulMpHdDe0Su4EACBasLq7wzlntblpqPdVohrEp31tBSmx8T_MwTq9HaJoJiFsNEq8DyktPs4t0P-xQyMXlQdn3XU5wkkcQSZurdwLADD48riBHhx5HmcEyE9rpyy78mcMVz45PJV6qhvJnl6vb8qsOKDKqf8AsPvLrV8kkoSnAYVb9oiCQaD8u-rwFmAB
test core::salter::test::vault ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 735 filtered out; finished in 1.43s
I looked at my notes on the original paper and it doesn't indicate the seal is required, I'll need to read about it more.
(for a general receipt)
must be for chaining
?
yeah for anchoring data to a key event, so in this case chaining which is why inception doesn't have it, right? at least if my notes are accurate
Ok, lots to unpack here... You are correct, the path you use for the Salter doesn't matter to any verifier of signatures
So there is no need for your approach to paths to match anyone else's, unless you want compatibility of HD keys across implementations (which is not something we need to worry about right now).
As for witnesses... Those should be Ed25519 verification key, basic derivation AIDs (should start with 'B') and they should be the AIDs of actual witnesses. You would create the event locally, sign it and submit it to each of your witnesses.
If you were to parse this event, it would fail because the witness AIDs are wrong, but even after you fix those, you'd end up in a partial witness escrow because you'd need to submit them to actual running witnesses first who will provide receipts.
I suggest removing witnesses for now, you can come back to them later.
Signature: It looks like you only have one signature which means this event will end up in partial signature escrow until it gets another signature (threshold of '2' with 3 keys). You'll need to sign it with at least one of the other 2 private keys you generate and pass both (or all 3 if you want) to messagize and it will append and index the signature attachments.
After you fix those things you _could_ host this inception event on a web server with an OOBI and pass that to `kli oobi resolve` to see if it will load, but that is more effort than its worth. Locally I have test script that I use for testing in python:
from  import habbing
from keri.app.cli.common import displaying

with habbing.openHab(name="test", temp=True) as (hby, hab):
    print(hab.pre)
    
    icp = (<inception event here>)

    hby.psr.parse(bytearray(icp))

    displaying.printExternal(hby, "<aid here>")
Just copy and paste your inception event as binary (b'...') and add the AID from your 'i' field and see if you get output.
To answer your other question if I understand it correctly is that, for a basic transferable identifier you don't need any seals.
Very exciting! Let me know if there is anything else I can do to help.
Awesome, thanks for all your help. I did create witness keys, and sign things with them but I doubt I signed the right things :smiley: I'll get back to this in the afternoon
Why must a witness key be non-transferable?
my second output above, the inception portion, produces this output:
❯ python3 ./src/keri/app/cli/verify_icp.py
EIaGMMWJFPmtXznY1IIiKDIrg-vIyge6mBl2QV8dDjI3
Identifier: EE8xDuqkA2IaYEsw2D0qjx91Kqyc0AUn56S_yVJbuoRU
Seq No:	0

Witnesses:
Count:		4
Receipts:	0
Threshold:	4

Public Keys:	
	1. DBfox0sPV36fj8iZ7oNiiMOzUpeW2tM-XK727bEARo6e
	2. DHfj5y5M1AVaGbCusFfaw4IQ9YOND8JpTU12GRy7s2hU
	3. DEkzXDZOQAaACEct5AqMhBGuXgkK4Y30HkzGuAOiJUty
that's good right?
The original message was incorrect, you're right
I should probably call that script 'validate'. Although I am testing verification specifically. Anyhow not sure why I'm even mentioning as I won't check it in.
Witnesses are committed to in the controller's KEL and thus rotation of a witness provides no value. If a witness gets compromise you rotate it out from the controller's KEL.
Ahhh thanks
So you save a lot by having a non-transferable identifier for witnesses... no KEL, etc
Yeah for sure, that makes sense
That is an AWESOME step there. You fully verified the event.
It's easier to spin a new one up
Just no witness receipts
Yeah and when i tried to use my signed receipt, it didn't change the output but it didn't bail on input
Oh right
I need to use non-transferable
Thanks
❯ python3 ./src/keri/app/cli/verify_icp.py
EIaGMMWJFPmtXznY1IIiKDIrg-vIyge6mBl2QV8dDjI3
Identifier: EMgav7OIM583_1gu8WHzNhySiE0O6VOU9AS4oiPwtzw7
Seq No:	0

Witnesses:
Count:		4
Receipts:	4
Threshold:	4

Public Keys:	
	1. DLjuvn3HjTB5ZgMudOSD4lhQkd9l2CN2Mye9GGSUqC_A
	2. DHOh9WPrF927gkdJ2XsYwZS_Z96PbBWK_O-JPoIo8zJT
	3. DID9REVqsX8VWD1ynnc7dyMpu5LA8yJf1axJaj0R9lZ8
:tada:
Woohoo!!!
very exciting! I'll push my code
For anyone that is interested, I managed to get a working inception event and receipt verified by KERIpy from cesride just now! . Expand `` and look at the test code, `vault()` in specific. Big thanks to Phil for helping through the verification process!
(that PR contains another full PR and I need to rebase after that one merges, sorry about the length)
I shall be toasting this at IIW!
Thanks <@U04HQD29Z7E> <@U048YRLFKTK> <@U04EFUFR71Q> - we have everything merged we wanted to and are proposing the v0.2.0-alpha release - this will form the base of starting signifide and continuing the parside JNI work.
We have yet to fully define the Signify client protocol. Right now it is being developed in conjunction with the cloud agent in the `signifypy` library. The intent is to limit the amount of KERI needed on a client so there are subtleties to the answer to your question. We will be discussing this in detail at an upcoming KERI meeting.
joseph.l.hunsaker
Did the meeting start?
joseph.l.hunsaker
I might have the wrong link
Same
Same
Not sure what's happening
joseph.l.hunsaker
Time change?
joseph.l.hunsaker
The time change this week
Kent is in North America so I doubt it
I just texted Kent. :crossed_fingers:
We can always video chat here if anyone else has items. :slightly_smiling_face:
hey
sorry for being late
We’re in!
We're on
joseph.l.hunsaker
Apologies I can't make it, something came up this morning.
We had a good meeting, talked about the zeroization PRs, the SECp256r1, the `data!` to `dat!` macro rename, the fact that we are up to release 0.3.0, some comments on how to move Parside and the FFI layer implementation forward, and a short high level architectural chat. Shoutout to <@U04HQD29Z7E> with all the hard work these last two weeks! And thanks <@U03QRSUA87Q> for coming and asking questions. They help us hone our message.
Oh, and the move to the Rust error handling library.
<@U024KC347B4> <@U04HQD29Z7E> could you please review the WASM JS bindings PR for cesride? I think it's done now.
I have a GLEIF call so I will likely miss the cesr dev call thanks as always Jason and Dmitry for their contributions, 0.4.0 is available (thanks Jason) and has the wasm bindings, p-256 support for things like the Apple Secure Enclave/Hardware Security Modules and more clean up.
It might be worth on the call revisiting the current open issues (is:issue is:open -label:roadmap) and discussing where we feel they're at, do they still need to be addressed, do we have thoughts on progressing them? A comment on each issue would help or labeling, however folks want to tackle it.
<@U04RNMG8Z51> mentioned he has a working CESR parser in elixir, my comment to him was, I'd love to see what it would take to add rustler () bindings to cesride to try bridge our work with his, it'd be a great test to see if what we're doing in cesride is consumable by others, so that'd be a really fun conversation to have too
<@U04RNMG8Z51> has joined the channel
joseph.l.hunsaker
I cannot make it today. I have sick kids and my wife is out of town.
That sucks, hope they feel better soon.
Did you wife leave because they kids were sick? Power move on her part. :smirk:
joseph.l.hunsaker
She had this conference planned for a while.
Hi guys, I will miss today’s meeting since I have an appointment. <@U04HQD29Z7E>, <@U024KC347B4> could one of you lead today?
Here’s the meeting minutes link (also added to the channel description):
I can jump on and make someone host so we can record though I will be driving on my way to an appointment and will need to drop out close to 9AM MST (~100 minutes from now)
I won't be able to make it, sick kid
got it
We just ended the meeting. <@U03KLB48Q2E> and <@U03U37DM125> and we had a nice chat about Keep. See everyone in two weeks after IIW!
No recording for today since we didn’t cover anything important.
:pray:
Sorry! This dropped off my calendar.
Thanks for the report
Would someone post a link to Keep? (Did a quick search for it but I don't think I'm seeing the right stuff.)
Sorry, was at an onsite this week and couldn't make it to the meeting! See you at IIW!
From todays call
Zoom link for today’s meeting is posted and is right here: Passcode: Bv8uG+!W
Is there a storage location for the community meeting recordings? My Zoom storage is 83% full and soon I will run out and I want this community to have access to all old recordings.
Should we say we preserve recordings for up to six months?
There is not, but there should be.
I got my storage down to 72%:
image2.png
I’ll likely just upgrade my account to 30GB for $10/mo
My Zoom account only has CESR meetings now haha
Maybe we can use filecoin to store everything and we could just donate to a community wallet.
I save it to my local disk and then upload it to Google Drive
It would be cool to build a KERI & ACDC auth mechanism on top of filecoin to access recordings. We’ve got to start dogfooding this anyway. We’re close.
Kor and I want to pull every recording we have onto a cheap self-managed server and then start indexing this stuff automatically.
So wait to delete them please. Save ’m on your local disk or better: Drive, Dropbox etc.
In many of them there are useful explanations of KERI concepts by Sam, Phil, and yourself etc. We might wanna use AI to find these explanations (vid + time) in the future.
I could organise storage on DIDA's Sharepoint for the KERI community. Let me know if that works for everyone.
Hey folks, we've been having some discussion and it seems given the direction and momentum of signing at the edge (signifypy, signify-TS, and signifide) and the drop off in the need for an edu call, alongside the completion of CESR (way to go Jason) that we could re-purpose both calls for a weekly signify dev call. We've seen increased interest from multiple parties and it seems wise to utilize this (Thursdays 10am EST) slot moving forward. The call will be focused on those implementing "signing at the edge", integration with KERIA etc, and not focused on spec Q&A (we have Tuesday calls for that). We'll likely try rotate the focus between implementations if we find the need to do so. I'd like one more cesride call to discuss cesride/parside/keride and we need a week or so to gather peoples opinions. Please respond in the <#C04G1KR5R6D|signify> channel, that's where we'll try gather consensus.
nuttawut.kongsuwan
Will we use the same meeting link as the edu meetings?
I am not sure yet.
I like this direction. It makes a lot more sense. Cesar has been complete. Signing at the edge Seems like the next most important goal.
If we want to keep using the same zoom link, we can, though I wonder if we want to use a zoom account that is tied to the web of trust in some way.
I’m glad to continue providing the Zoom link for the keri-dev calls for as long as we’d like.
GLEIF has offered to host the recordings so Phil, Lance, myself will likely set up the meeting, means we're not reliant on one person to record every call
That’s awesome. It’s nice to spread things out.
Today was the last meeting of the CESR-specific working group. Congratulations again <@U056E1W01K4>, <@U024KC347B4>, <@U04EFUFR71Q>, <@U048YRLFKTK> and anyone else who contributed for all the hard work to make CESRide, Parside, and KERIde a success. I look forward to joining the KERI dev calls when the start up in a week or two. Once that meeting link is available I will make sure it is pinned to this channel for continuity to point people to the new meeting.