Secure Data Storage - WG
7:58PM Jul 9, 2020
Michael and say
Hi, Claudia, how are you? Okay.
Sounds like you're having your captain crunch or something.
I'm having chicken salad with
celery in it. Oh, that's what the crunchy part is.
All right, I guess my mic is really good. I'll turn off
All right, two minutes past the hour. Welcome everyone to the weekly secure data storage Working Group call. Going to give another minute for people to file in and we'll get started. The agenda link is here in chat.
Clear Do you mind
passing cohost over to me and
Yeah, no problem. The editors.
Okay, how do I more?
All right, brilliant.
Okay, so well.
Let's get started.
Clear. You care to take us through
the IVR reminder and introductions.
who would like to introduce him solves this new
API a reminder first,
I know Okay, fine. So that's all IVR protected. Um, if you have not signed the IPR agreement, please go do it. Um, and we cannot accept the stand up contributions from you if you haven't signed the agreement. who's who's new to the call and would like to introduce themselves?
I'm new to the call attending this for the first time.
Cool. Awesome. Awesome. New.
I'm George from Seattle, Washington.
Fantastic. RJ Can you also in Yeah, George, say a little bit more and RJ will go back to you after that.
Yeah, sure. So I've,
for the past seven
years have been trying to get a digital badging project up and off the ground.
So I'm just now
very belated, but just now cueing into
what all is going on on that front from w three C.
Excellent. Well, welcome. And I J.
Yeah, so I'm part of the community from couple of years working on building different kind of OSI solutions. Recently, we were participating in a hackathon in India called account aggregator hackathon, which is for data exchange in the FinTech world, and we're trying to see if we can leverage some of the standards, some of the ideas of SDS like encrypted data war, or similar one
cool Would you be willing to share a link to that? Yep. Information about that, because I think it's interesting for this group and it may also be the basis of a use case that might be worth writing up.
So do we,
we have a use cases document, right?
Yes, yes, we do have a use cases document.
So we'll post a link in the chat A j and in the minutes, and maybe it's worth, you know, after this call looking at that and seeing if there's aspects of those use cases that we could drawn.
In this, I've just shared the link after a section called special interest topics, that and we are focusing on data governance solutions on virtual data room in that
Very cool. Thank you.
Okay, anyone out Oh, we introductions. I guess we're old enough we can do that now.
who hasn't introduced themselves yet in this group?
Who's been before?
Nadir? I'm gonna pick on you
can you read it? Can you introduce yourself? Naina
hear me? Yeah, yeah,
yeah, one minute.
Oh, he might be in a noisy place.
Sorry. No problem. Hey,
you just wanted a quick intro. Yeah, yeah. Hi,
my name is Nadir
Helmi. I work for matter in New Zealand.
Although I'm located in the US for the time being. Yeah, I've been sort of in the decentralized identity space for about two, two and a half years or so. And really
enthusiastic about this work and
other important efforts like did calm and
just aligning different standards communities. So
happy to be here. Thanks, Manor. Cool. Okay.
All right. So Today we have possibly abbreviated agenda, we're continuing
discussing layer B, which is a lower level encrypted documents, config for the vault. encrypted indexes, and what better way of discussing layer B, then doing it through issues? Who of the editors wants to take us through issue review? Although before we do that, Does anybody else have any pressing questions or concerns or items to add to the agenda?
All right, so yeah, let's, let's dive into issue your view. forea fear you're being volunteered.
All right, I can do that. But before I do that, usually the chairs and W three c working groups are doing This issue review driving so if right, I'm just wondering like point of process manual like, is this a thing that editors should be doing? Or is this a thing that chair should be doing?
It can happen either way. It's really up to the working group to decide. Usually I usually I've seen editors do it not necessarily chairs do it. Um, but I mean, it happens either way. So
cool. Well, I will, I will drive them let me get the
Can everyone see my screen? Yes. All right issues.
I hate this
based on recent
least recently updated. There we go.
Issue number one, input documents have been archived and pointed here. So I opened this issue. This is these were the input documents that we had. Identity helps has been archived and is directing people to this working group to participate. This is the encrypted data vault specification. And there's no mention of the fact that this is ongoing work
over here. I will update that right now. And archive it.
Awesome. You are assigned at issue. Cool. All right, closing this
Any update on where this is currently for official use question from someone March 16.
I just directed them basically to Ask questions slash participant in the working group. I feel like we should close this issue because I marked it as pending closed on May 14, and we never heard back from them. So I'm going to close this issue.
next issue, future of identity hub and where to look for updates. Same guy, same question marked as pending closed. No response. Closing due to inactivity.
Enable async credential request with identifiers. Sam, are you on the call? Sam is not on a call. May 14, ping to a couple people. To try and answer questions about this, it seems, in my opinion, in my opinion, this would not be something that you would encode in the spec anyway, it would be another protocol you used outside of it. Agree. Does anyone want to leave a comment on the issue like that? Or shall I just close it because no one responded and marked it as pending closed on May 14, so group agreed out of scope.
Let's see explanation for equals syntax and encrypted index query example. So someone asked a question, how do these encrypted index was work? I pointed them to documentation about it. They said that they'll take a look. Doesn't seem like there's any action here other than potentially adding more spec text around how indexes work. work when I'm not sure that that's even a thing that we would want to do with this, so I feel like we should just close this because it's been answered. Any objections?
Plus One, two closing.
Alright. Okay, now some things that are ready for prs clarify in relation of storage to agent wallet relative to some sections. Eric Welton, and open this issue. Dave Langley responded is Eric on the call.
I don't think Eric is on the call today. I
think this is a request for a diagram. I labeled it ready for PR as such. Does anyone want to help take this over?
Now we do have a PR with a diagram for what it's worth.
Does anyone want to comment on issue 48? whether or not there isn't a PR that's addressing it, so that it shows up in good history.
I can comment.
I don't want to leave this assigned to Eric because we've passed him a couple times and he hasn't been on the call.
He's taking a short sabbatical from
Stanford. So I'm gonna assign it to the editors In the meantime, and it's gonna be up to us to handle it. And assigning three people the most surefire way of making sure something never gets done. I guess whoever and whoever on assigns themselves last will only have one of the editors holding the bag.
Which is the PR? And then we can look at reference the PR. Yeah Then Then why don't you just just reference the PR and closer.
So I just left the comment referencing the PR.
And then you can close it.
I will close it next time we come around to it if the PR is merged. Okay. Issue 45. How does compression of document play into chunking of indexes?
Kyle, are you on the call?
Kyle does not sound like he's on the call. I think we're ready for a PR which defines the relationship between incorrect compression in compression and encryption maybe with a note about how valuable encryption is for large probably should be how valuable compression is for large files. I'm ready for PR Kyle opened it he's not here. We're gonna move on.
Right she's 38 paradigm shift. shoe to shift from client server to content provider consumer Johnny crunch open this. Some discussion wordsmithing and promises of pull requests on May 28. Johnny crunch Are you here?
Yeah, and I've actually made some changes. I have been submitted a PR though,
so I will do that.
A floor only opened this issue 39 section four This global configuration needs to acknowledge client role more prominently. Section 4.2 point three persist global configuration should indicate that there's interplay with the client. Dave longer in the call and you want to summarize this?
Yes, I am on the call. I think this was
trying to think back.
This is when we were going over
the high level sections
said to do with making it clear that the client is going to be largely in control of configurations and servers just need to
meet some kind of basic capability
to be to support interoperability. So server needs to support some set of capabilities that the spec says and the client then decides how to use those.
Ah, alright, so it seems like the action here is improved. language around what we just said.
is worth adding a ready for PR tag.
Yeah, I think this is ready for PR. All rights. Issue 37 articulate the layers, your goals for identity have staniel generate PR for this. Can you clarify so that people can collaborate? Daniel, you want to take this one?
Yeah, yeah. So I I don't think we're speaking in terms of layer zero anymore. In terms of this right? Isn't a strategy at this point to go through sort of the layers and identify where they would have touch points or how we want to talk But I feel like the premise of articulated as layer one layer zero may not be relevant to our approaching things anymore.
I agree. Can I close this? Sure.
Right. How does one request access? This is a complicated one, Adrian opens it. Adrian, you want to give us the summary?
yeah, it's been a long time. But the goal of this was to focus attention on who gets to know, to do traffic analysis effectively from a privacy perspective as a driver. relates to the storage resource. And let me just leave it at that.
Though. How do we make this actionable? Is this update spec language around? Like, what? You know, where traffic analysis can occur in the different ecosystem components and then describe how they impact the privacy impact of traffic analysis at those layers. Is that fair summary?
Well, yes, I mean, I think this relates to a series of issues, which can be summarized and I don't remember offhand which issue it is, as we have layers that are policy decision points, layers that are policy, enforcement points and potentially the role of a mediator and defined by Aries. And this is all tied up into that discussion, as well as this long discussion which we haven't captured. I mean has been captured but I'm not sure it's in an issue. It's in an email thread about introducing mediators in the into the vocabulary that applies to secure data stores. So somehow or another I think we have like five, at least three possibly five different issues which could be resolved together.
Sounds like we need to work basically towards some spec language around these privacy authorization issues.
Just a quick q plus Um, so if we have five issues that are being discussed here, They need to be broken up into separate issues each each issue separate and focused. Otherwise, discussions just going to go on forever in this thread and people are not going to be able to follow it. So So if if we. So Adrian, if you think there are five issues in here, you should raise five separate issues and close this one. Once you've done that.
No, what I'm saying is that there already are five issues being discussed. And this is one of the five
Okay, yeah, sorry, I misunderstood.
So I think
and they're all related to privacy.
Do we have to get through all five layers before we know which ones can be the authorization point, which ones can't?
Yes, because each one may have its own authorization layer.
This is this is what I was remembering data. Lumley's explanation and I thought
there seem to be very various places authorization can live.
So I'd like to get in the queue. I don't see how to raise hand when co presenter.
Sure, just go ahead.
So my question is, should this be in scope?
And maybe we can take a glance at our,
at the working groups charter, which does does try to do its best in limiting the data model and some protocols. So
I feel like we're gonna have to get through the layering discussion before we can see as a working group, whether or not this is in or not scope, out of scope. So I think the action here is like we know this is an issue we have to get through authorization at all the layers before we can come back and try and say whether it's in scope or out of scope. But my suggestion would be let's just skip over it knowing that we're going to cover it as we talk about authorization and all the layers.
So it's good. I agree. Do we have an open issue for each of those, those those, those layers for authorization? If we don't, it might be worth just to be able to focus the discussion. I
think we have open issues for all of the components of this that Adrian mentioned. There's certainly some cross linking I can see in here,
but I see a couple but not No.
Adrian, if you think that there is a missing issue, please open it so that, you know, we can we can track all of them.
Well, I think that the missing issue is how this relates to the service endpoints discussion in the mid core. I I don't know that that is mentioned as an issue in any of these three or however many related things in security data stores.
Think I remember discussing that on one of the open issues, but feel free to open a new issue and we will cover it as a do if it's a dude. Okay, all right. Any other cue? Was there any anyone that you know, I think that's right. Issue 49. Clarify SDS sharing, which I think is sort of related in some ways to requesting access or read write. Eric Walton opened it.
editors are getting assigned this one. I do not know there's a long discussion with Dave lonely. Dave, do you have any advice on how to move this forward
I would say it falls into the same authorization discussion that we need to have.
I mean, the short answer to this is yes, you can do read write, but the real question is, where does that happen? And at how many different layers and
what are the protocols and authorizations? That's just complete
complexities here. Okay.
There we got discussion on here. I feel like we need some kind of authorization label. Everyone okay with me creating a label on the fly.
Do it yep. Cool.
That seems like a nice friendly pink color. All right.
Is that like the facto like with with with google google docs for sharing? Isn't that isn't the basic structure? I don't know.
Host otter AI meeting minutes today. W three CCG mailing list assigned to the chairs marked as critical chairs.
Is it critical?
I think we were on the hook for doing this as part of getting this working group started. So,
so we need to have Yes, this is our action item and we have not yet met with belies about it. So I'm gonna I will assign it to me.
What's your GitHub handle?
identity woman? Ah.
You need to be added.
I can't do that right now.
I'll do that. Okay.
Thank you. That's issue 43. And if you could do that, that'd be great. Move on.
I can't do that I don't have rights.
Ah, well, hopefully there's at least one other chair editor who isn't driving who can be helpful and handle that.
It is finished. Awesome.
But you must accept the invite in your email. All right.
Yeah, let's make sure that all the editors and chairs have the appropriate access because we want to share these duties. Issue 58 replication user stories, I dump these into here as a result of a conversation that we had on I think it was the editors chairs call. I'm the only person who's commented on it. It was mostly in response to this replication use cases associated with the identity hub replication issue. That Daniel is brought up I since it's my issue, I'm in favor closing this and just covering it later. Daniel, do you object?
No. Wait, wait. Quick, quick question.
so we have a separate use cases documents,
What if we mark this one as ready for PR? And we can just even if there are stubs, we can put these replication user stories in the replication section, have our use case document,
as I understand it, that's kind of already been handled by those use cases. So I don't think there's any action here so I'm in favor closing it.
Okay. Sounds good.
If we believe we haven't, then let's address it in the use cases directly and not this one off issue.
Can somebody tell us the current state of the replication functionality?
It's blocked pending our ability to get through all the layers and authorization. Excellent.
You might want to put authorization tag on it.
Right? Yeah, I bought everything that's replication would get authorization then so I'm just gonna close it for now. But I hear you.
So here's here's the link to our existing use cases document.
I'm not sure
how well replication is addressed. So definitely a call for pull requests to add replication considerations to
To our use cases Yep.
Okay, issue 51 criteria for deciding the layering transformed operations in each layer. venues. Are you on the call? Can you do this?
There was a lot of discussion, this felt very meta to me suggest a pull request add language about layers relating to it. Venues issue. It's not on the call, we're going to move on. Let me add the ready for er. At some point, we're going to have to groom ready for PR as in like, it's ready for pull request, but nobody's opening them. So we should just close them so that people who want to open pull requests can pick from a bucket of things that they could actually tackle. Criteria rites, replication and layering. Another big, big one assigned to Daniel looks like I created it and then assigned it to him questions about replication and layering.
I think that we should probably nail down layering and then then we can talk about replication and where
anyone want to pose to me just closing this and tackling this when it comes up again.
No opposed to closing it, I do have a counterproposal to what Daniel just said. There's a little bit of a chicken and egg in terms of us, tackling, layering,
or use cases first. I love to add
a couple of replication use cases. For example, Online offline, if I have a data store at my house and I have a data store in the cloud, I would like when the house loses connectivity for it to replicate to the cloud, when connectivity is resumed, so, Daniel, I think, at least you and I have plus other fans of replication should add a couple of anchoring use cases to the use cases document so that he can help guide our authorization layer in conversation.
Right, I'm assigning a noting that both of you are volunteering to do that and closing this issue. Okay.
You have my x.
All right. Questions. All right. Issue 52. Debate replication at layer one is implicitly required. I think we're we're still sorting stuff out.
Thank you see, there was a use case, then we could better judge
the sign this. Daniel, you're assigned this last comment on June 14, for you to comment a proposal. How do you want to move the decision?
You scroll up a little bit?
I mean, cuz
it's like, I feel like Bill Clinton and say it depends with the definition of layer is here. But like, if layer one doesn't include the type of data that I would, if layer one is is defined as such that it doesn't encompass where I think the type of data required for application would have to exist, then it isn't implicitly required. If layer one would be defined as something that does encompass that part of data it would be required, so I feel like I need to understand so
knowing what you know now, what would you recommend? I write on this issue in terms of an update or what should you Write on this issue in terms of an update. Actually, you should totally be writing on this issue, not me. So can't leave a comment about this or tell me whether you think it's a good idea to close it or not.
Okay, either of those will work. So I have a question regarding this.
What you just said, Really begs the question of what is the metadata required for replication?
That's a great comment to make sure you should leave that on.
And I would say it depends on how you want to do a replication system,
and you guys can have that conversation. We're thinking of user data stores and permissions between hubs also assigned Daniel, do you want to give us an update on
the study of pattern
users user? Can you go up to the title again, okay, easy data storage permission. helps.
no, I would say that there's a lot of different strategies that we can employ.
One, say that on the issue, even update on the issue, unless there's anything that's changed or you think that this like, is there, if there's any progress on this issue, you should tell the group summary of it, then you should leave a comment on the issue discussing or noting that there's been no progress on it. Okay. And then if you think that we should just close it because we're trying to do things in the wrong order, you should you should tell me, and everyone else who is reviewing issues should be doing the same thing. As we go through these.
I want to add a comment to that
about sinking of permissions in stores, which is
one of the things that doesn't often get
considered in conversations replication is replicating not just the data. But also permissions like this issue mentions, and indexes, the replication of indexes is actually
often gets on the floor. So I would like
to add to what I just added a comment based on being capital product to do so. And it says basically, that like, no matter what objects we put in the system, there's ones that have to be logically evaluated. All of them should basically like the replication aspects to just see them all as objects, regardless of what you do. You know, regardless of how they're evaluated thereafter, they all replicate exactly the same. And then they become the system when you essentially evaluate them. Does that make sense?
All right. Do we have a definition of what hubs are?
Well, ya know, there's a specification section called hubs and it's defined there. If you if we feel like the definition that's provided there is not sufficient, then we should open an issue to improve it.
And someone who opens the issue should work to make sure that it gets improved.
So I think that Adrian, the action item there is take a look at the hub section of the spec. Yeah, and see if that defines its official name. If not,
yeah, exactly. If you feel like it's not good enough, just open an issue saying it's not good enough. And this is what I'd like to see and tag people and ask for move work towards a something where someone could open a PR to fix it. Issue 57 on signed a Daniel debate. Goal of SDS should be that it can immediately be used for universal progressive web application storage. And you'll provide some examples. There's some back and forth on interfaces. Daniel, you want to give us an update?
I will maintain that. My, I believe we should. This should be the top level goal. Basically, what you see here should be standard in all browsers. So everything we do should be in support of that goal. And because this is this is gives you the world changing stuff.
I do I work this towards an issue that can be closed.
I think this would play into if there is an issue I forget, there's just so many about like, what would the help interfaces look like that we would put in the spec to kind of drive towards even if we'd radically change them a PR that has like the strong interfaces, and this would be an input into that? I would guess. Maybe?
Okay, easy statement.
is true. All right. I'm, I'm directing you to consult The Hub interfaces into someplace and then close this issue. So please do that. Right debate mono repo first, I created this. So my suggestion was, hey, all like, we're not really sure exactly how we're gonna approach test suite reference implementation modularity associated with sample implementations or if we use that term sample implementation, or read, go read Wikipedia about sample implementation versus reference implementation. This suggestion is let's not go create another repo and split up the community. Let's do everything in this repo until we see so much contribution from people the issues are getting close and raised and pull requests are coming in so quickly that we can't handle it anymore. And let's split it up after that. So that's my opinion. And I think in order to close this issue, we need a test suite and some implementation that that test suite is running against in order to kind of close this issue. So there is actually already a mono repo pack set up here. And there already our vendor interoperability test. So this is one half of this issue already done. And I will note that on the issue I've done you have tests me need a sample implementation.
initial implementation exists some proposals around how things should go I created this issue. The update is we have ci CD for external vendors who claim to be implementing the specification. We don't Have any sample implementation setup at all? So the update is you have some tests. You need to get started on a sample implementation.
And I think we're probably not going to tackle this until we feel like we're more unified as a community on the layers and authorization line kind of thing. Unless someone says, Oh, please, God, just start that work. I really wish you would do it, which case I will consider prioritizing it. Add application level use cases to drive layer conversation, Daniel, this seems like what you and Dimitri have been talking about on the past three issues. You want to give us an update on this.
I feel as though I provided several very compelling And amazing use cases. And can I just be done? Is that my part?
I mean, yes. My initial. My next question was going to be Do you want to do a PR?
Oh, exactly those things that you provided?
Yes. Just a PR in the use cases document
deaths again. Okay.
All right. Yes, I will take them. No modifications everyone forever hold your peace. I guess I'll just review them and tell me there. Yeah, as
soon as ready for PR.
How should vaults be related to wallets I opened this I discussed some layering. We've seen pictures of this. There's been some me alone on an issue by myself in favor of closing this issue, as there's been no comments on it for 30 plus days.
This about this is about custodial versus non custodial or
this is about what how our wallets related to vaults and I have attempted to spark some community discussion by posing the question of how should vaults be related to wallets?
So what's evolved in your definition I think might be because because people don't, might not might have different different definitions of one of a what a wallet is and B what a vault is.
Sure. So we're here in the secure data store Working Group talking about encrypted data vaults which do a vault I mean, encrypted database as defined in the specification today, and then hubs built on top of them which are built on top of of them. So that's the question is how our wallets that exist in the wild today related to this topic. And I'm looking for some comments on the issue. contribution from from others. But if there isn't any I feel like we could just mark this we can we can close it like, basically.
Yeah, no i was i was encrypted data vaults that makes sense. vaults per se was still a stone symbol.
Okay, so I think this to be encrypted data vaults. Part of the reason I use the term vault is I want to be respectful, whether it's like a hub thing or not, like hypothetically in the future. So maybe this is this is clear.
Or do do we have do we have? Do we have anything that that specifies the relationship of wallets and hubs you know, what, what has wallets as as as controlling entities or is that or is that still completely open? vaults or house keys? Good?
That's a good question. We have a proposed folder request that partly answers your question, which is, unfortunately, the GitHub PR interface doesn't give previews to SVG s. So inside could link to the Google slide from from which it comes, but I was gonna ask you or actually,
I mean, it's especially relevant because
you were one of the founders of the universal wallet specification. So you should definitely have taught us. Yeah. And curious if there's consensus in the community about the relationship of wallets to vaults, which is, vaults require key management. Key Management is out of scope for the spec.
That's where wallets come in. I mean, could it be as simple as that?
Yes, I think so. I think gets wallets have an inner wallets our wallets have access to key management and wallets used their ability to access key management to store data involved is like the explain like I'm five version of it. Now I don't think we have any language in the specification that necessarily makes it that clear for people and potentially This is a request for someone else to do that work or I guess eventually make it this is my issue. So if the working group feels like this is a valuable discussion, and we would like to see it move forward, leave a comment on here for how you want me to solve this.
We just say that it's that is that that's out of that's out of the wallet are out of scope.
So I would like to do a straw poll, which is so strong Paul.
And we add a section of religion relationship of this back to other entities in the ecosystem?
Okay, so should we
Cool. Putting these comments on issue 78, right?
Yes, but in chat, please
like to see plus one minus ones
which would inform whether or not
plus one Okay, can't
and right right presenting does make the chat interface super annoying but there's a lot of
sharing but I'm just not gonna try.
excellent. Yeah Matt meta points out the chat isn't recorded so this never happened, which is fine. Right plausible deniability and this Just gives us an idea of should we should we add this language? Let's back. It sounds like there's a lot of demand for clarifying the relationship, at least between those two things.
Cool. Leave those comments on GitHub, which is permanent.
Yeah, we can we we can we can leave the details to reference implementations. Yep. Right.
Yep. It's a quick question for the community. I will leave it as a comment in 78. Or, is it said somewhere that secure data stores have something to do with the IDS? No. This is the secure data stores can live completely independently of wallets.
That is true.
Yes. All right, that's our 10 Minute Warning. Please leave comments on issue 78. I will as as the evolves, they will get to the point where we can do a PR and I will do a PR on on it. Because it's my issue and I'm responsible for that. deduplication of Section 1.3 and use cases document assigned to Eric ready for PR. I think that we maybe have done this already.
One you did this. What's your handle?
can assign you to the issue. Get into diff. Wait, I'm not what, I don't know. I can't assign you to the issue if you're not part of the org
So you're not assignable.
I'm going to close this issue and let to reopen it if they want to. Alright, that was do deduplication and this one well known your eyes. Okay, here we go. So I give an example how we use well known your eyes to help with did discovery of encrypted data vaults. Basically there is a root level path argument that you kind of need to hold on to as you're using the encrypted data vaults clients that exists today to access them, and I expose that root level URL under well known your I in our implementation. And I'm wondering if that's the kind of thing that people want to see in the spec, and Dimitri says you'd love to see a PR so I will mark this as ready for PR. And since it's assigned to me when I'm looking through the assigned to me and ready for a PR section. I will know what I'm supposed to be opening pull requests on
are you can I ask that you actually do that in conjunction with the definition of what a service endpoint entry would look like? Or is that more of like a hub thing?
And they're not related. And I don't want to conflate them. I think there is another issue for service endpoints somewhere that will.
So I like to keep plus to bring up matters common to that issue. 40. So mana finds out that that well known as a hack, which probably discuss there are better ways. I would be like, I agree with both of those things that it is a hack. I'm having trouble
thinking of what are the alternatives man, would you like to
Island data Island, embedded JSON or JSON LD in the HTML requesting the document in a certain format. There, there are other options that are better.
This all falls under discovery approaches manual. Can you include those specific examples with links to them and I will account for them in my pull request if I'm able to
cool collaboration with data shards collaboration with data sharts. Who is this math? Emacs? And are you wanting to surge?
What's the status update on this issue?
Well, I don't think we have a status update. We discussed data shards last week and we discussed potential areas of collaboration, but it seems unclear whether we whether data shards would be the layer B or B a possible layer B. So I think That's, that's something that we have to continue discussing.
Can you leave a note about that on the issue?
Sure. Let me 61 Yep, I will I will do that.
And if there's like a if you think that proposing some kind of facade interface or data access layer abstraction would solve for that. Okay. Let me should try and figure out how to get that done.
I will do that. As soon as I figure out how to login.
Alright, criteria for deciding the layering and transformation operation to the layer. What do we do we just cover this? Like, I just cover this? Yeah.
I think what's gonna happen is when you get a page to
printed and it's all gonna be bored, you might have to reverse the order
or something. Okay, let me just, let me just refresh. Everything. All right. Am I on page two still? Yeah. I'm just go here, over here least recently updated. Okay. I think we've we've wrapped around on everything. So and we have five minutes left. So I think we should call it for issue review my yield back the remainder of my time to the chairs.
All right, thank you so much.
Do we have any other questions or concerns before we wrap up?
All right. Thank you, everyone. Thank you.
Next week, we're trying to have an we're trying to have the ipfs folks present but we haven't confirmed all that yet. So we'll let you know.
Yeah, I think I can give the the IP LD talk that I gave in the community CCG. Excellent. That'd be helpful. Right?
That that would definitely be helpful.
Yes. Okay. Yeah.
So I do want to note, so talks to some nebulous folks. You probably know them. Jonathan. Dietrich, you know, a few of the folks that work on go. And they so they don't show up next week. And they can help participate in that chat as well. If that's, you know,
what, we had one here.
I mean, we were thinking that we could have an AI ipfs and an IP LD presentation. Yeah,
yeah. All the ip ip star, you know,
yeah. Yeah. Perfect. Yeah. So please, please reach out to them and reconfirm core for next week.
pull us up, pull us on to the thread with Daniel. Cheers. be great. Cool. Yay. Oh, and just before everybody, man dishes I will put in the chat and I'll send it onto the list. JOHN Jordan was in a really bad accident and we have a card for him. I should have said something at the beginning. Sorry. No worries. Um, so if you know john even if you don't know john, he's very keen to hear from the community and he is um he's he was well enough to go outside in a wheelchair this week. So he's getting things are bad, but also relatively speaking seems to be getting better. So thanks, everyone.
Thanks while I thank you.