Internet Engineering Task Force Interim Meetings, 31 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-CBOR-20230531-1400

Description

CBOR meeting session at IETF
2023/05/31 1400

https://datatracker.ietf.org/meeting//proceedings/

A

A

Good morning can people hear me.

B

I can hear you fine thanks for the check, and it is one minute past the hour by my Reckoning. So let's go ahead and get started. um I, don't think we had any slides present uh proposed question. Did you get any? Did you see any slides proposed, no yeah, so I guess it's just a conversation.

B

So let's hit the agenda and uh Marco as always. Thank you for taking notes.

B

So the first thing we have is the DC board discussion.

A

um Well, why don't you give a quick update on the the last few changes on DC bore and the the latest um internet draft um and then let's talk about what, where we can go from here.

C

um You know just give me a moment after me up on my screen, I'll post, the uh the link as well um I present, the people who are most interested in this have actually already had a chance to look at it.

C

um The main changes were a uh you know, because we had a number of people advise us that uh the API recommendations you know weren't as interesting or useful to a lot of people in the ietf uh that they'd be uh moved to uh that. You know that they'd be de-emphasized or I I, think they're still important, so I move them to another part of the document. Also, we uh clarified some things that people had questions on and uh I think um expanded.

C

The the um uh the section on um a numerical reduction, which I think is primarily the focus of discussion at the moment. The other thing that I think um is more or less an agenda. I item is whether the uh the is where the seabor working group is going to uh officially adopt the ietf dispatch, direct recommendation that uh um that we take that it take on the DC board proposal that we've submitted as a draft uh and um uh and so I- think.

C

That's probably the easiest thing to determine at this point, uh but I think that does need the the group's kind of um consent to uh to take that on officially. So um maybe that's the first thing we should talk about and then assuming that moves forward. Then you know go on deeper into the uh internet draft or the discussion around. uh For example, numerical reduction.

A

Just in general, you know what are the next steps as far as um you know, is there interest in uh having this document be from this community, and um you know continue through to some level of RFC.

B

Okay, folks should just go ahead and speak up. We have a small group, we don't need our permission. Carson go ahead, great.

D

Yeah but I'm still going to raise my hand, even if you're then immediately start brothering. um So the the document is is really interesting uh to me.

D

The the problem we will have in in turning it into uh work for the Civil working group is there are very different things in there and we probably need to to take some time disentangling them. You already mentioned API discussions. I actually would very much um appreciate an API discussion. Christopher, your your system is echoing um I.

D

I very much would appreciate uh an API discussion, but it would lead to a very, very different document, um for instance, compared to a normative document about a particular encoding profile or whatever we uh start naming that thing and I also think that that the tutorial elements of the the documents may be useful, but maybe don't need the the iotf handed standardization process. Those tutorials really work very well as websites wikis whatever, um and if we want to extract the normative component out of that, then we probably should be skipping the tutorial parts.

D

So this is uh just. um We can probably prepare this this carving up today, but uh obviously the uh the authors uh need to do that or need to find uh people actually who want to cooperate on specific aspects of that um so I held others talking about apis as well. So maybe under this interested in that I don't know um so.

D

um I I would like to use this discussion to actually identify those components and sort them into ones that that are into possibly multiple ones that we want to discuss here and others that that are very useful but might better work outside in the idea of working group.

A

So um is uh Carson: do you have interest in helping us um at least capture the the part that you think is most standardizable? First, um you know the core. uh You know uh stuff about now: I, just I'm I guess we're looking we're we can put whatever effort in and make whatever changes are necessary uh to meet the the requirements of the group. um So, but we also welcome participation and helping us figure out how to do it. That you know meets your needs.

D

Yeah, so that was a question directly going to me um sure I I have somewhat limited time resources, um but I certainly am interested in helping you doing this this extraction and and to uh possibly formalization in a way that that we could go ahead with a senate strike document.

C

Okay, Carson uh a um I'm, not quite sure which sections of the current draft you're, referring to uh as a tutorial I, would love a little bit more specific specificity on that. I also want to make sure the group understands that my motivation for including um API recommendations in it was that I realized that um the goal of determinism is not something that can be um purely supported by the uh uh normative protocol.

C

It's something that if, if determinism is the goal, then it needs to be supported as well by how the um any reasonable codec is used uh and that this can either be supported or undermined by the API, and therefore the API itself is um um well um I've made it clear that these recommendations are not formative on the most recent version of the draft. uh I feel like there's a lot of value there and it's important to for people to understand that um that determinarism is not appearing mechanical process.

A

Well, you mean do we do we just say that and refer to another document. If you want more details- and here is the- but here is the the poor, um uh some of the core choices.

A

Is that sufficient I don't I'm not.

B

Certainly is something that is frequently done, that uh there'll be a standard specification that refers to a Wiki page or some informational document or whatever for additional information. That's not normative.

C

I think the the kind of the the larger and more fundamental question that you know I'd like to kind of just deal with, is you know, does the does the Sea World working group feel like this? Is you know developing a deterministic SeaWorld profile, um possibly using our current draft of the starting point?

C

um I'm, not insisting on that I. Just think that you know it's a very important goal. That definitely um uh is is in Confluence with the the needs of our group, um our non-profit, uh developing higher level protocols based on deterministic seed bar. But it's assuming that the group officially wants to adopt as an effort.

C

um Obviously different people in the group will be making different levels of effort, but I think that's the that's the question to kind of resolve the the recommendation of ietf dispatch, which we presented um a month or two ago now.

A

So, what's the process of accepting something as a work item.

B

Well, that's this is the start of it having having the discussion with the working group and then uh when, when the chair is determined that the discussion has gotten to the point where we should ask the working group a final question: should we adopt this document as a working group product, we will post that to the mailing list, so I mean I, guess we can take a quick poll on this call from where we are so far with this discussion?

B

Does anybody think we should not take this on and use this as a starting point for a working group product.

D

Well, as I said, my problem is that I don't know yet what this will be.

D

um I think we should have a discussion on uh whether the the approach of of mapping, integral floating Point values under integers is something that that really is worth.

D

um Having it that separate role in in the sibo ecosystem, but that's probably easiest to discuss once we have actually written this up in in a form where we can discuss what what's actually in there and what is not uh in there. So this would be section three of of the current document.

D

And section four, uh maybe is a different thing, because part of it is is actually a protocol. How to design a c bar protocol and part of it is about the actual applications. And then we have the the API discussion.

D

So these would be separate things from here and I. Don't see a standard strike document coming out of those parts.

D

But maybe I'm glad.

B

The the next, the immediate Next Step, then, is for uh Christopher and wolf and Carson to get together and figure out how the document needs to be split or reorganized, or whatever.

C

Yeah um again, my my motivation was that this is actually rather, um you know, critical to like, for example, things defined at the application Level. um You know, if you don't do that right, then you don't get determinism on the issue with numerical reduction. Could you could you?

C

E

Sorry well, um could you try muting and unmuting again you're terribly choppy.

C

How's, it now is better: okay, um I'm, not sure what the reason for that would be.

A

Yeah wolf you're get you're you're, somehow all of a sudden got a lot of noise in your.

C

Should try switching my um my audio advice for some reason: I'm, not sure why um one sec.

A

So carsten, um Wolfe and I are at least planning on doing a day at um ITF in San Francisco. Are you going to be there.

D

No I'm not going to be in San Francisco but of course, I will be joining any events you, you want to run there like a site meeting. If we manage to to enable remote precipitation for that I've.

C

Switched microphones and I'm not.

A

Sure um I know there was time requested, go ahead and wolf.

C

Shopping is from everybody else, so maybe it's just something systemic in my browsers, like that, I might need to reload the page. um Can you hear me better now.

A

It's a little better yeah.

C

Okay, the main point I wanted to make and then I'll continue. Diagnosing. The audio issue is um that um the primary issue with numerical reduction is um uh more natural support for languages that don't have a a hierarchy of types in the two languages.

C

I'm thinking primarily are um JavaScript and Ruby, which um it's much more problematic to work with fixed size, numerical types um and uh uh that the idea that you should be able to present a particular numerical value to to a DC, War API and know that it's going to be encoded in one specific way and that that should not be cognitive burden. On the engineer to figure out the right way to present that, in a uh from, for example, JavaScript or Ruby, and it should be, it should be on the uh the Codex.

C

um It should be the code expert to decide how to actually encode that numerical value of that loss of precision. So that is the major goal, is to basically have you know unambiguous ways of encoding things and to secondarily to just make it much easier to for engineers to just present to numerical value and and know that it's going to be encoded. In a specific way,.

A

All right, so um uh wolf and I and Shannon are planning on um applying for a side meeting in uh on the the higher level protocol. The guardian protocol at uh the San Francisco meeting, but I thought I saw a request for time uh by the seabor community for this upcoming meeting. Is there an agenda for it yet or what the what the hour? What what we're filling that hour with for the seabor agenda.

B

And now we'll be working on the agenda on the next call in two weeks, we'll start working on the agenda.

A

Okay, anyhow, um you know we feel like this would be useful. We have the resources to continue to to uh you, know, adapt and make you know either split.

B

A

Up or make the changes that you guys recommend um uh in order to um you know we're seeing that if, as you as we're looking at uh seabor's use in other standards groups, whether or not it's w3c or ISO that having uh some clear.

A

uh Conformance uh for uh deterministic will make things easier for a lot of people um they're using it, and in that fashion um we have. We have two other topics. We wanted to also talk with this community about um when this one is done.

E

Before we get there, I'd like to jump in with a question to better understand uh that topic of numerical reduction. So my understanding here is that this is done in order to allow languages with relatively weak typing um to uh input whatever they have and receive a deterministic document out of it.

E

um What I'd like to understand is why is is float slash, integer, a sensible distinction here. So, for example, if I were to think in terms of python, 2 I might not have a good distinction between a text string and a byte string and applying the applying that rough rationale. There would mean that the information model is just um weakened a bit and then all encoders would need to say encode byte strings that happen to be utf-8 in text strings and otherwise, as by strings um or something like that.

E

Why is integer float a good boundary here um and looking at languages that have such an even weaker type model? I haven't had my hands on PHP in years, but I vaguely remember some weakness between kind of integers and text. Even um what would be what would need to be done for languages with even weaker typing? To still get that cinematic output, and can this not be applied to the languages that don't distinguish integers and flows well,.

C

So um this would I think benefit all languages, um particularly images like Ruby and JavaScript that don't have they'll just have a number type and that you know use whatever internal representation they want. But the engineer General isn't aware of it um uh who use existing um uh seabor. You know you when you present to number type it has to do something to decide how to encode that member type um and you could have the API insist that you also specified the encoding type.

C

um But uh you know, given that, there's that you know you're working with number type primarily in those languages, then you know that's becomes additional burden on the programmer in languages that have a strong typing system like C or uh similar languages. um You know you would present whatever you have. If you have a a 32-bit float, you presented a 30 foot float um controlling the codec would essentially reduce that.

C

If it had no fractional part, it would be encoded as uh uh an integer without loss of precision um or accuracy, I should say and uh uh and in the least precise type it can hold it. So you know 3.0 would be coded as single byte represent three, um and so um it would actually reduce burden on all languages uh and uh and then on the extraction side. You know when you um uh in a strongly typed languages with strong numerical types.

C

If you you know tell the API that you want to extract a uh say, a uint 8 and the value in question say an element of array you know could not be represented in that type. The API would inform you, it can't be represented in that type. um You know, obviously um maybe we'll just you know, extract the UI, U and 32, or something like that. You know and then again, if it were, you know, ended up being quoted as a big num by whatever encoded it.

C

um That would still not be representable at that type and you'd be informed of that. So um the idea being that you you input, you have, and you extract what you want um and often those will just naturally be the same. um But um and you know, and you know, weekly type language.

C

You know you input the numbers you have and you extract the number and you extract numbers, uh and you know I think this is something that um forcing users of determined to see more profile to figure out what size to represent in encoding um is, uh is going to be very error prone and I think that this is something that properly needs to be pushed down into the layer of the protocol itself, which is what we're tempting to do with the with the DC board. I.

E

I see what I I see what what this is doing, but I don't see why why this is done, for example, for for why this makes sense for kind of when going down that road. Why I stopped there? Why keep a distinction between tax strings and five strings, given their languages um like see that use the same um use the same data type for both um so.

C

I, don't think why.

E

Precisely why precisely here.

C

Yeah I, don't think you're going to be able to in in every case, um for example, you know uh a a character pointer in C. um Does that represent a byte string or does that represent a utf-8 string and I?

C

Think or uh you know, or just a generic by string I think that's kind of what you're getting at is you know, does is this properly something that the that the protocol should also carry and uh and determine somehow and no the obviously seed has no affordance for that, um and so any reason we'll see uh uh you know, DC board API would have to have you know you, you would have to present a character pointer to it or you and date, pointer and- and you would have to specify at that time, I'm presenting the utf-8 string or I'm presenting a byte string, and it would have to include it that way.

C

So you can't avoid it. In all cases, many languages do have a much stronger typing system with regard to Strings and byte strings, JavaScript and I think Ruby 2 among them, where a string is easily determinable to be a string and has an unambiguous encoding. And therefore you don't me, you wouldn't even need in the API I'm, not I'm, not uh proposing that we specify an API I'm proposing that we specify a.

C

um And and I should say, the the issue with numbers is uh is distinct in some ways from other things that you could say are similar like say, byte, strings and UTF strings, um and uh but you know, you're not going to avoid this in all cases um and different languages have different.

C

um You know fundamental assumptions they're built on, and so when you can distinguish between them, you you ought to, and when you can't, then yeah you're going to have to default to the way that you're forcing the new network numbers numbers are just so common uh and so uh uh and it's so easy to make mistakes when, when it comes to numbers that uh and and they're handling such a variety of ways, I think it's very important that this distinction be part of a DC board profile.

A

The other thing I just want to throw out here is you know where these are being used. um uh You know there is a lot of JavaScript um challenges with JWT having to do with.

A

uh You know um uh various people saying well in order to do this type of stuff, we have to include a schema and then there's a whole complex, schema language, and that, eventually you know is you know, there's a lot of of uh kerfuffle in the w3c, verifiable credentials and other groups that are using uh both JWT and trying to also use uh um uh the w3c link data standards because of these types of issues, so we're trying to basically go below it and say: no, that's not the right place to address it.

A

You know, stop stop bringing in semantic information and um and all of that type, the stuff and defining your data by you know semantic, but well it's not really semantic graphs. It's defining your data through a schema.

A

um uh You know I'm, not we're not against schemas, but we just feel like it's uh causing lots of challenges. We also have uh uh patrons of black blockchain Commons that are working on very constrained devices with very constrained processors. So it's not just, for instance, uh you know, uh you know C versus uh rust or something of that nature. It's you know. A constrained version of C working in a constraint with a constrained version of rust as well is a is another Target.

D

Yeah, maybe I should throw in some some history. I've tried to do this on the mailing list, but maybe it's better if I say this orally. So um when we started to design c-bar really the the birth event of sibo was when we looked at the the format that we stole everything from the message pack format and found that the the distinction between Bud strings and text strings was very murky there and- and we really wanted to have a better way um to to separate these out.

D

And uh so we started discussing with the message back uh people and and found that they were not interested in uh moving the format forward towards standardization. uh So we decided to just go ahead and and throw away the baggage. That was on a message packs back, and this was how how sibo was created um so uh looking at issues um which distinctions actually make sense in a specific application, um is, is very close to the heart and and to the founding myths of sibo.

D

um So when we looked at, the numerical part, uh What, uh of course was our Focus was on was constrained devices. uh So we already knew that that floating Point uh applications would be a subset of the devices that that would use numerical data. So much of what we were going to be using was going to be integer or or implicitly scaled, fixed point.

D

So having a good integer system was important and and that's what we got, um but of course we had to have floating Point support, so we put that in as well and at the time we had a state of mind that that also was uh saying: okay, that that's just extending the the number of space with additional numbers and and really the the integer numbers and the integral floating Point numbers should be treated the same.

D

But at the time we didn't have the the concept written down of what what actually is a generic data model and how how to use this um in in this uh specification. So this is what RC 7049 did.

D

um It doesn't didn't outright say that that integral floating point and and integers were the same, but it kind of was open to to uh civil protocols that that mapped them onto each other and in the seven years, between uh 1749 and and 89.49, uh we got a lot of feedback that that was not a good decision. So I cannot replicate every single item of feedback that that we got here but I think in in total.

D

It was pretty clear that people were very unhappy with somehow integers and floating points uh turning up in in the same uh context and that we were better off in in keeping them separate, at least at the sibo level. So Engineering in 49 is more on the other end of the pendulum here by by keeping them separate. But of course, 8949 doesn't prevent an application from doing this mapping.

D

So if your application wants to accept both integers and floating Point values in a specific numeric position, uh that's of course fine from the point of view of C but see where it has everything it needs to to support that.

D

So um what was a bit surprising here was the the desire to move this uh discussion uh over from from uh the the application view. What is an application allowed or supposed to do with numbers uh towards something that that is deeply in the belly of siwa, which is the deterministic encoding mechanism?

D

um I. Think it's very important to keep in mind that having deterministic encoding on the sibo level doesn't lead to deterministic encoding in general, so the application has to do with it. It's a piece of work for deterministic coding as well, um but um interspersing a layer between the application and and sibo cbo's generic data model that that changes.

D

These numbers for for the entire use of this profile that that's certainly a new idea, and uh you will find us reacting a bit reserved to this, because we we came from that thinking originally in 2013, and learned that, at least in the the world of constraint devices and in the world of high performance systems. People are not so happy with that. They prefer keeping floating Point data and individual data separate from each other. Yeah.

A

Carson um so I guess one of my questions I mean so one of the things that maybe is reason why we're bringing this profile forward is that we are representing we're so we're a not-for-profit Commons organization consisting of a large number of software Developers, but what they all have in common is that they're they're signing data uh in one form or another.

A

Whether or not it's sensor, data coming off a wellness ring, um you know or uh uh a uh uh uh you know, a photograph or you know various kinds of of statements that are being made and uh uh the the that's the application and because of the signing requirement and making that consistent uh across many different uh classes of devices uh and CPU engines- and you know even worse secure element, engines uh with very constrained things is, is what's driving who drove us to Seaboard.

A

um That being said, a lot of the code that's out there, I mean I'm, still shocked. There's this thing called micro python that lots and lots of people are using now on uh on these chips.

A

um So you know at some point: we're going to have to you know, make a version of this in micro python, um but we they all have to interoperate.

D

Right, so what I'm trying to find out is uh why the the signal we got from implementers uh about separating integers and floats was was uh uh so strong and and how how your community arrives at at a different signal, so that there may be several reasons for that. One is that your community is just different from the one where we got the initial feedback for sibo another one.

D

Another reason might be that the the environment has just changed and um I I already said that we are going to have a lot of interesting number of presentations coming up um in in the near future.

D

We already have several CPU and GPU and npu, and whatever chips that have interesting number of representations, um so we we probably will have to look at this in in a more General sense later on um people who have lots of numeric data, often organize these and arrays, and that's why we have tagged arrays in in sibo, and it's probably also necessary to think about signing information that is in these tagged array.

D

So we, whatever we do here, probably also needs some thinking about tagged, arrays and and the current types that are uh in the current number types that are in there and the future ones coming up.

A

So speaking specifically to that was sort of my other agenda items, so we had two pieces of feedback based on you know presenting um uh gordian envelope at dispatch.

A

um The first was, uh you know, they didn't quite understand the um you know who are quote our customers were, um and we basically had two responses to that. uh One important response was, we feel, like you know, anybody who stores data at rest in ITF standards should be subject to the the two rfcs that uh the ITF had published on privacy and um that's 69, 73 privacy considerations for internet protocols and also 80 to 280 Research into human rights protocol considerations.

A

Those are supposed to be what we are now mandating, yet there are basically no standards that are really uh taking advantage uh of using those as a basis for requirements um uh at the data at rest level. So you know you were just talking about. uh You know, data formats. The data format that people are using for lot of this type of stuff is a graph store, which is a little bit more complex than than lists.

A

So we basically created what we thought was a very elegant, triple store that could store not just the linked data graphs that is very popular in the w3c side of the world, but could also support other graph triple forms and and such and allow for those triples to be also elitable while being signed. So IT addresses those uh those ITF rfcs requiring options for data minimization, and we have lots of I have a whole lot of use cases on our website about.

A

You know how this can be used by the wellness industry by the education industry by other Industries, um so we're kind of confused on you know how to try to move this forward, because one part of it is this.

A

You know requirements of you know for securing data at rest of things like what DC what seaboor uses and then there is the uh you know this additional kind of layer, that's separate from any kind of a lesion capability, which is how do you do various forms of graph data in seabor and we've addressed both of those in in gordian envelope have working code and people are beginning to. Actually, um you know we're looking at a a wellness ring. uh You know that it that also does cryptographic signing uh you know using this technology.

A

You know this year so um and they're in so and they're, not the only ones, but that's probably the most constrained one. So we'd like to try to you know see if there's interest in the in uh the ITF- and you know uh standardizing the six tags that we have for a uh uh excuse me. It's seven tags, but we're reusing one uh one existing tag uh to allow for some fairly sophisticated, uh triple Stores um and options for triple stores and gives you this additional capability.

A

If you wish to to Allied uh uh data for data minimization requirements without doing fancy, BBS cryptography and things of that nature, which is okay uh but we're not we're trying to it, I can have a whole discussion about when you should use CL, sigs versus ec6 versus BBS, plus proofs or things of that nature, but the simple hash based Collision, uh you know we think, uh is powerful uh to address these structured data requirements.

A

So is I. Just I'm wondering. Is there interest in this community and uh you know, defining uh you, know those seven tags and how they are put together to make for a fairly powerful um uh structures.

D

So maybe it's worth pointing out that there's um ITF working group that that is doing something very, very similar, uh which is uh the skit uh working group which is looking at supply chain, transparency, which has a lot of of uh rather similar requirements, so they're, also looking at the Mercury trees and and how to have transparency registries um that that can provide both transparency and and privacy and so on, and so I I think you should really try to involve those people um and- and maybe first have some offline discussions with the main drivers uh there and and then later on, decide.

D

um Whether maybe human envelope format is is a useful formative contribution for what what skit is trying to achieve.

D

um So this is describing this as a set of seven tags is, is certainly one way of looking at it, but really it's um uh pretty powerful data structure that that will be used in a lot of areas, and so it I think it would be good if we have a common view in the iitf of how this is done.

D

A

The suggestion it was that that uh and we actually have a uh you, know, kind of an early draft of something which is um uh a problem statement, an area of work. um uh Where did there there? It is uh so that is a uh an early draft of a you know, problem statement of hey. You know this is the requirements of those two rfcs one of the key areas that to be able to support those requirements is data minimization and then you know, uh go go down down that route.

A

uh You know, I I do monitor the the scitt uh list.

A

um They are an application, um uh they have a you, know, very specific purpose um and then they're basically kind of uh you know they are aware of gordian, but they're also flailing a little bit, because it is an application group for a very specific application which is supply chain, whereas ours is much more generic and uses uh I mean it's a lot closer to Seaboard I mean one of my fears is this gets kind of dragged into security, um whereas I really feel like this other than the fact that it has a hash Tree in it.

A

I really feel like it's an art function. It's an it's an application function, you know it's a it's a tool for um I mean we actually have a demo of um uh in our use. Cases of uh the Mastodon protocol uses uh an ietf standard uh that once again puts data at rest at these different servers. uh How can we leverage um data minimization to protect privacy on Mastodon servers?

A

Well, if they just stored their data at rest in in a gordian format, it would address a lot of their problems and they're, not part of skit, we'll, never be part of skit. So I don't know, I, don't know what the the right answer. I just feel like there is a you know. Seabor is a support.

A

A very elegant spot in a support layer that um is relatively straightforward doesn't require you to go to some antique layers with schema data and whatever, in order to do all of the different types of operations that you want to do. It has The Primitives that you need right now. There are no formal RFC Primitives for one of the most common types, which is graph data and ours.

A

We believe ours can do all three major forms of graph data, as well as some lists and other different types of things that are interesting and that's just a fundamental basic addition to seabor. And thus we I mean we'd like to see that possibly not as a whole have to form a whole, not new group working group to to do gordian, but at least get the graph part of it into uh the the Seaboard group.

C

May also may also add something else here, which is, um you know, obviously I'm working engineer: uh I'm, not a cryptographic expert, but I've been working with various kinds of cryptography that uh that uh you know and and I'm very practically minded when it comes to.

C

um You know uh the apis, I work with and and develop and I I've been designing this accordion uh and implementing this accordion envelope uh protocol on top of seaboor and a lot of my impetus for the DC4 uh internet draft um has arisen out of my actually first of all implementing um uh envelope without it uh just based just using uh third-party c-more codec, open source, cboard codec um and then realizing that due to these uh issues that keep coming up with numbers and so on and now having implemented it in in uh in two um well I've fully uploaded in Swift, which has a strong strong number type system and I'm currently implementing in Rust and I'm, anticipating doing a JavaScript, a typescript and.

A

C

Well that we basically and kotlin yeah um uh and some of these we may be working with their parties on. But a lot of this stuff is, you know, I'm it's a sole effort, but supported by blockchain Commons um that uh install open source that um these number, these issues, particularly with numbers, keep coming up and anticipating also working with more weekly type member systems.

C

It really I realized that um that a lot of things I was having to deal with at the envelope level, were more properly pushed down to the Seaboard level um and uh and handled in a very kind of uniform way.

B

C

If this we're creating this, the the DC more uh spec and that's why it also handles things that I had to deal with, including both things that would be considered normative for Seaboard coding itself, but also um things like uh you know, API recommendations which I I've. Just you know, I have empirically found to make my higher level code much more straightforward and and also the apis. People have to to work with to to use the Gordy envelope uh protocol itself.

D

So what would happen if we moved the numeric reduction into the guardian envelope protocol.

A

Not not necessarily I mean I see the the out um for it in and of itself.

A

uh You know, I mean there is a scenario in the future where we, you know, work together to create a uh uh you know uh on in w3c what we would call a note that basically says hey if you're implementing seaboor and you have these specific types of requirements.

A

Here's a profile of you know what is required to be deterministic, and these are the kinds of things you have to be careful of and here's some choices that were made as uh you can do, whatever you want, but here's some choices that were made that were you, know, carefully thought about if you're really looking for consistency here, um maybe another note on if you, if you feel like it, needs to be separate on, you know, sort of the application side of that and how are those decisions made Etc and then there's another document that says hey you know here is a small set of tags that you can use in some very elegant ways to create fairly complex structures of a new new.

A

You know not just lists, not just tables, but uh you know various kinds of graph structures uh with seabor and if you're doing graph structures you know you can do everything you need with these seven tags in this way and then there would be something else to say. Oh well, as long as you're doing that, you know hey here's some ways you can do some simple data minimization to protect people. Maybe I, don't know if those are all separate documents.

B

A

Even not all of them even have to be done by the Seaboard group, but I could see a future where all four of those are are published.

C

Carson to to address your question specifically, you know, and now having pushed these um these issues down into our own DC board libraries, which are exist both in Swift and rust and and are being looked at by the people or and ourselves for conversion. Another language is still um I would never pull it back up into Guardian envelope. It's too generically useful and basically streamlines all the rest.

C

The higher level code built on it, um and so our goal with the internet draft is to post the ITF that it's not just useful for us, it's useful for everybody um and that therefore it'd be uh ultimately adopted as some form of RFC. If that weren't possible, we would still publish it as our own profile and continue using it. um You know because it's just it makes things much easier at higher levels. They're.

E

They're, when you're trying this into.

C

The requirement.

E

I'm I'm pretty sure there are cases where it's where this is useful, especially when working with with languages such as JavaScript, um but it may help to make kind of moving. So in I'm, not sure it makes so much sense in the encoder. It may not make sense in Guardian either.

E

um Looking back at the at the at the discussion um on on the first part of first part of this, and before we switch to the triple topic.

E

um Maybe this is not so much about an encoding, but it's more a new information, a new variant of the information model, so you're um you're, taking the generic, um uh the uh the general C4 information model, placing the new information model on top of it in which all numeric types are equivalent, which then has precise rules for encoding into cboard, and then these uh and then that sibo can be encoded. Deterministically and applications such as gordian may choose to use that information model, um maybe maybe excluding it along.

E

Those lines helps helps keeping this keeping these a part of it because we're having there's a there's a lot of material in here and we're jumping back and we're jumping back and forth between layers and I. Think this is hard to keep track of foreign.

A

Are you going to be in San Francisco um only only remotely only remotely, okay.

E

I will be in Prague, but that's half a year from now.

D

A

Well sounds like uh uh not sure both of us can be be uh there uh in person, um but certainly remotely we can we're dealing with a third of the world away, uh but we'll figure it out. um You know we'll.

A

um We think this is important work. um You know, I agree that it is kind of a weird we're not doing a great job uh describing our layers but boy, it's even worse at the level above us.

A

um So you know in Jason LD, uh which is you know what w3c has been moving forward for a while. um It is so tangled. It's like!

A

uh Well you you know you have to understand the semantic layer and you have to be able to parse this context, and this part, this context, has all kinds of of um you know extra details about what it means and how it this meaning is different than this other meeting, oh and by the way, we're using that to sort your arrays so that they can be deterministic and it's like you know, everybody's pulling their hair out at all of the complexity of layers um uh and and their interactions in that area, and they haven't even really gotten to standardizing uh some.

A

Some uh men, you know, data minimization at rest, type, issues um and they're. You know kind of fighting with the JWT group uh about various. uh You know: data profiles there and whenever I look at it, I go just there's just like you know, I'm, not counting, but you know five or six layer violations that are happening uh over there that are causing problems so I'm, very sympathetic on this side to say yeah. Maybe this needs to be divided up into a little bit more layers to be clear.

A

What you know you know here at seaboor and then here is a DC bore thing on top of it and then here's a guardian uh graph structure on top of it and have those be very nice and clean, I'm, very sympathetic uh to that I. Just you know, I I would I guess. The key question is, you know: are there sufficient other people in the seabor community that are interested in these types of things that um it's worth driving forward? You know uh multiplier I mean we.

A

We are providing one of the uh you know well more than one uh implementation with you know rust and Swift. um We have partners that are working on it in Python and other languages.

E

At least for at least for for many distinct parts of this, you will find people here that um that will that will contribute, contribute.

E

um That's one thing in in the interest of of keeping this um easy to understand and keeping the layers low. There's one thing that I'd like to understand, and maybe I just missed it when, when looking through the DC board Parts um in many other places uh where we were about signing uh Seaboard data, what worked well was to just um pass data around a seabo, encoded, byte strings and work from those and just never re-encode did you was this evaluated around DC4, because all those numeric all those numeric flexibilities would basically fall out.

E

If this were an option.

C

A

C

It's a guardian envelope level once you've encoded something um as an envelope. uh You know it's a hash tree. um A number of the types are based. You know the actual hashes are based on the encoded seaboor. So in that respect, you can't change the coded C4 afterwards. The question is, for example, if I encode.

C

uh If, if I want to encode the value 10- and you want to go to the value 10 separately, are we converging on an equivalent or an identical um hash and um and if separate, encoders can't necessarily coordinate across time and space right to unless they have a standard to focus on and what you're suggesting is that we have? You know uh that I encode 10 and then you never re-encode it well. The question is: why not just have the same wave, encoding, 10.

E

The other thing is we we're already passing around a signature and, at some point we're passing around the data that is being signed.

A

Yeah I can answer this a little bit differently, um so this is basically an architectural choice that JWT made and others have borrowed since, um which is you basically have the original plain text um you know, in whatever form it is uh and because it's being carried around because you know they're, not canonicalizing, the Json they're, basically keep taking whatever the Jason hold on. Let me let me finish the uh that style of thing um is biting people all over the place.

A

So, first off, uh when you start doing multi multi-signature stuff, it ends up massively multiplying the the uh the size of this of the structures in a number of these a lot of these structures. Now it's not just one signature. It's many signatures. um uh You know over time. Also people are trying to you know. Basically, uh no I, don't want it in a seaboar format. You know I need it in my graph database, uh which can handle these types of things. Yet I need to be able to check and see.

A

Is this still valid when I export out of my uh graph database? So when it ends up happening with JWT situations often is that they actually have to pull in the the data into the database and then a Big Blob of the JWT data along with it because they, you know they have no guarantee that the they can reconstruct and and compare the hashes. uh So they just take the original object, which then causes problems when things become updated, because if the thing something you exported out of The Blob gets changed.

A

You also have to to invalidate The Blob and just there's been a lot of headaches with that sort of style of construction.

D

Yeah I think the the consensus that we have reached by now is that if you can get away with it design data in flight, so this is what what cozy does.

D

There are applications that require assigning data at rest. That's.

A

What we care about.

D

The the mistake that XML do you think made was to say: oh that's the only kind of data we will support, so they pulled in all the complexity of signing data at rest into the places where assigning data in Flight would have been completely appropriate. So we we will from the people who have worked with cozy.

D

um You will always get a pushback asking. Do you really have design data at rest? Or can you get biodata in flight because we have a much easier way to solve that problem, um so you will always get that pushback, but I. Think there's also an understanding at this point in time that there are applications that need to do that.

A

B

C

Our people are doing credentials. Many.

B

C

Of Guardian envelope that I.

B

Have to interrupt here, we.

C

Are out of time.

B

C

Okay, I think there's some lag. um Yeah we've we are I've published a number of samples according envelope where all the data at rest is absolutely signed.

B

I've shut you off, we are out of time. um So let's take this discussion, the rest of this discussion to the mailing list, and um we know the steps forward now right, uh the next. The next step is to uh the next step, for the other discussion is for Carson to get together with the DC board people and sort out the document, and we can continue the rest of this discussion on the mailing list.

B

A

B

Thank you. Thank you, everybody for coming today and uh if we need to put this back on the agenda for two weeks from now, we can do that. I would prefer that we try to continue the discussion on the mailing list instead and um and then see where that goes.

A

B

A primary discussion for two weeks from now will be starting to put together an agenda for the uh iptf session in July. So thanks, everybody we'll see you in two weeks.

A

Thank you thank.

D