Harrison_Tang: Hi everyone uh welcome to uh this week's w3c ccg and uh. ✪
Harrison_Tang: Before we begin I hope you guys had a great uh IBEW and uh today our main agenda is to talk about dwn decentralized web notes uh it's actually a quite highly anticipated uh session uh and today we we're very glad to have alandur a culture of the dif security data storage working group uh to actually talk about that uh as well as can and uh their colleagues uh to talk about dwn. ✪
Harrison_Tang: I just wanted to quickly go through some administrative stuff um so first of all just a quick reminder on the call of ethics and uh making sure that uh you know we ensure uh respectful and constructive uh conversation I think we've been doing that for years uh but I just want to start the meeting with that. ✪
Harrison_Tang: A quicker intellectual property know uh anyone can participate in these calls however all substantive contributions to the ccg work guidance must be member the ccg with full IPR agreement signed. ✪
Harrison_Tang: Uh so if you have problems uh or questions in regards to the w3c account or. ✪
Harrison_Tang: License agreement uh please just let any of the co-chairs know. ✪
Harrison_Tang: Now these meetings are being automatically recorded and transcribed and uh we will try to publish them uh both the transcription the audio recording and the video recording uh in the next uh. ✪
Harrison_Tang: Uh we use GT chat to cue the speakers during the call so you can type in Q Plus to add yourself to the queue or cue minus to remove and you can do Q question mark to see who's in the queue. ✪
Harrison_Tang: All right uh a quick uh moment for introductions and reintroductions so if you're new to the community or you haven't been uh active in the community and want to re-engage uh feel free to just unmute and introduce yourself. ✪
Harrison_Tang: Right uh what about announcements and reminders uh any announcements or reminders in regards to the upcoming events. ✪
Kaliya Young: We had a great IBEW last week um and it was fun to see people from all over the community um. ✪
Kaliya Young: Our next iaw inspired event is the digital identity unconference Europe in Zurich June. ✪
Kaliya Young: 18 To 20 we are quite likely to sell out so if you are. ✪
Kaliya Young: Based in Europe thinking about coming uh please register sooner rather than later so we don't have to. ✪
Harrison_Tang: Any other announcements or reminders. ✪
Harrison_Tang: Anyone want to share their uh most memorable uh IBEW talk or maybe ideas or discussions and sessions that uh you would like uh the ccg to host in the coming weeks. ✪
Joe Andrieu: Thanks Harrison um yeah I just want to share There's A really lovely demo of uh using BBS plus with ZK snarks for range proofs using um the vcd so the the. ✪
Joe Andrieu: Verifiable credentials data model and that they what was very interesting the reason I wanted to highlight it today is uh the issuer doesn't need to know about these range proofs if they have um issued their VC with BBs plus then this range proof can be added on as a negotiation between the holder and the issuer so you can late bind these complicated predicates and the initial issuing authority doesn't need to uh be involved or even know about these predicates which is really interesting terms of late binding in the ecosystem. ✪
Harrison_Tang: Any any other 1 else want to share uh what they learned from IBEW. ✪
Harrison_Tang: And Joe I I probably would want to connect with you offline later in regards to seeing whether we can host a session on this uh PBS plus and the range proofs. ✪
Benjamin Young: Yeah I just wanted to let everyone know um I'll be sending out an email about this um pretty soon the uh ecdsa test suite for the verifiable credentials spec um related to data Integrity the test Suite is ready for implementations um. ✪
Benjamin Young: Here today and then next week we'll be doing our uh test Suite office hours if anyone is working on implementations of anything VC 2.0 or um. ✪
<joe_andrieu> /me @GregB i'll look for a reference
Benjamin Young: Any of the data Integrity proof stuff or anything related to the. ✪
Benjamin Young: Suite of specs we have going both at the working group and the community group um I'd love to have you join us that's next Wednesday at 10 a.m.. ✪
Susan_Stroud: Thank you um 1 of the things that I really appreciated about iiw was the conversations in the healthcare space um so often we're talking about jobs and education which are super super super important and lay down a lot of the foundation to allow us to move into places such as Healthcare but starting to reimagine healthcare where we can get some of the folks that are in the middle you know out of the patient and provider um physician relationship is really exciting and to be able to kind of Envision how to use the entire Suite of products to address needs and Health Care um was really exciting and there's a couple of events um and sessions in that space and so I just wanted to share that view coming from Healthcare lens not just the jobs and education and they all they all fit very well together. ✪
Harrison_Tang: As soon as I might want to connect with you in regards to like who we can invite to talk about kind of the SSI and the healthcare uh industry uh later on. ✪
Harrison_Tang: All right any other last calls for any comments. ✪
Harrison_Tang: All right let's get to well let me check the queue first. ✪
Harrison_Tang: All right let's get to the uh main agenda uh so again this is a very highly anticipated talk in regards to decentralized web nodes and uh very very honored and glad that the outdoor the culture of the dif secure data storage working group uh. ✪
Harrison_Tang: And your colleagues and actually join us today uh to talk about decentralized web now uh dwn uh is actually a data storage and me message relay mechanism um it's. ✪
Harrison_Tang: Important and critical part of the kind of the web 3 and decentralized identity uh stack so the very interested to learn more about it and uh you know without further Ado just uh I'll pass the the mic to them and then they will talk more about it. ✪
Andor_kesselman: Thank thank you Harrison uh really appreciate it um I'm going to share my screen here. ✪
Andor_kesselman: Um can everybody see my screen let me see if I pull up here. ✪
Andor_kesselman: Awesome so quickly uh we have 3 people representing this today uh myself um I'm chair of the TSC at diff and co-chair of the data being working group actually the it was handed off to me from Kia who's here and also thank you Kia for the wonderful IBEW which I was fortunate enough to attend we have Kim who's the executive director at deaf um and as well as Dan Buckner who's been an editor of the specs since the very beginning and had a decentralized identity at block so we'll be each taking a separate sections um and if you have any questions during this presentation feel free to ask if there's a shorter questions we're happy to answer them like on the fly but if you have a longer question that is a discussion uh we'll leave that towards the end so the the agenda today is first I'll give a overview of dwns kind of where they're at today give some ideas around kind of giving updates on on the state of dwns uh Dan will come in and and share a demo and then finally um Kim will end up with how de Vans are fitting with. ✪
Andor_kesselman: Are working on and very excited to to sort of fit dwns as a as a part of it so and then we'll finally end with Q&A after any any questions or or thoughts before we move on. ✪
Andor_kesselman: Awesome so uh goals of my section is to just give you better understanding of dwns know Works being used today and understand how it's been moved over time. ✪
<ryan> Are we expecting to hear audio? I dont!
<harrison_tang> yes, i can hear the audio. it might be your browser. i am using Chrome on Macbook Pro
Andor_kesselman: So real quick what is the dwn solve um as as Harrison mentioned it's a data storage and message relay mechanism that people use to to locate public or private permission data uh relative to a a did um I like to think about it as it's in an attempt to make building D apps um decentralized apps more accessible and easier than historically they have been uh and I think the key feature here that the key sort of insight is by by just writing a simple Json document a developer can establish a basis for a safe and robust interaction between an across apps it's not it doesn't require a blockchain and has a very loose interpretation of identity so we're not dealing just with for example credentials we're also just you know dealing with posts and images and and all those things that you might create Force for social interactions or any other type of interactions dwns are intended to be sort of a a more General uh mechanism to to handle this. ✪
Andor_kesselman: So kind of logically if you think about it um. ✪
Andor_kesselman: That I like to think about dwns and and the way that uh it's intended to sort of Act is basically a separating out when you're building an app the UI and logic layer are separated out from the STA and storage layer and so the dwms is this thin layer that sits above storage that provides you the permission layer the the the semantics and so forth to allow you to interact with the storage layer but at the same time it's standardized so that the UI and logic layer can can operate and you know you can have multiple apps that do uh you know interact with the same same uh lower layers. ✪
<daniel> Here now, sorry for being late
Andor_kesselman: So kind of as as a problem statement for developers it's reduction of a lot of development time that you normally spend building data access controls so you can focus on more of your use cases and actual app for users the idea is is that you you have control over your data you're not um beholden to a single data provider and for an ecosystem uh we're hoping that by using dwns we're going to establish more interoperability between apps that and and that will hopefully create some value chains that that do not exist today so that's kind of the the goal I think um from the perspective of of 3 different layers here. ✪
Andor_kesselman: So first thing first how do you pronounce it uh we've heard it um we've heard a lot of people asking in different ways uh so you have Don's um you also have dweb nodes you have dwns choose your your version uh there's no official way of pronouncing it but it has come up a lot you know the pronunciation. ✪
Andor_kesselman: So the history of uh dwns it was incubated at diff under the Secure Storage working group uh and again uh just for some clarity here and also um I was I came in about a year and a half ago after kuya had invited me to take over uh as co-chair um but obviously Dan has been there since the beginning I can call you you've been there since a very long time as well uh but it's been a work in progress since November 2016 originally it was called identity Hub and it's been uh we meet bye weeks on Wednesdays at 9:00 a.m. PST and if anybody would like to contribute to the working group we'd love your participation and uh we we work on the specs usually during that that time. ✪
Andor_kesselman: So what makes dwin special um first of all it's t2p so uh you don't need necessarily a server and its transport agnostic. ✪
Andor_kesselman: It has a protocol definition and uh layer which allows you to easily configure discover and build um daps on the Fly um it has fine grain access controls to allow you to to handle permission uh complex interactions with permissions on your D apps with a simple configuration file. ✪
Andor_kesselman: So we used uh you know service Discovery endpoint service endpoints for discovery. ✪
Andor_kesselman: And they're inspired by a number of Technologies we we reference them all the time activity path you can solid Noster edps all things that have inspired some of the decisions that we've made um and and learned from. ✪
Andor_kesselman: Any questions before I move on. ✪
<tallted_//_ted_thibodeau_(he/him)_(openlinksw.com)> ( link to this deck? )
Andor_kesselman: We've seen as as we've kind of dealt with dwns it's been a it's a long haul um but we've noticed that a lot of people are struggling to understand kind of what is dwns mean related to other Technologies so 1 of the efforts that we've put together as a companion guide it evaluates various other types of personal data stores for example solid ceramic Atomic data stores pure goats encrypted data vaults midex The Hub of all things we take a look at an OCTA pull it up here. ✪
Andor_kesselman: You can see here that we've made an attempt to try to help people understand what exists in the ecosystem today to give them some guidance um but if you have a personal data store that you'd like to add onto this list or like to clarify anything this is our stabs um that we took to to sort of help clarify some of the the offerings in the market um pureos had actually their offer come in and and add in their their entries and we've had a few other ones since the initial creation which has been very exciting um but if you have any ones that you'd like to add in feel free to add do so and and the links that this I can uh send in the chat just put it here. ✪
Andor_kesselman: Um and then IBEW um we had a great IBEW session on a personal data store face off um we had 3 representations aside from dwns you both data spaces and solid and we talked about sort of why we're doing the approaches we're doing and trying to sort of align and understand are we even trying to accomplish the same goals and so you know we've been trying to evaluate how dwns are relative to other Technologies and trying to listen to the uh advice we're getting from other people around uh how they're approaching the same problems or or different problems and why they're approaching different problems. ✪
<limari_(dif)> Your screen is still showing the DIF document
<limari_(dif)> You may need to reshare your screen so we can see the slide deck.
Andor_kesselman: So a dwn in actual practice runs kind of similar to how you think about pwa it's a very thin layer that sits uh under the apps that allow you to semantically organized basically data in a way that you can re-record different apps so for example if you have a profile as an example um today if you're on like for example Instagram or or Twitter or whatever and you have your profile it's and they kick you out you lose all your data right you lose your your identity across that app and the idea here is that even if uh there there's since you own the app or the the the the the the data that all these apps will connect to it but you won't lose that data across it so this data becomes portable across your apps and the apps become much more simple in terms of their their mostly handling the logic of rendering and and sharing the how that data is represented to you not in terms of actually storing and keeping that data. ✪
Andor_kesselman: And because dwns have a semantic error you can actually represent them over schemas and so forth. ✪
Andor_kesselman: They can run anywhere in the browser and Native app server and Docker it's kind of. ✪
<daniel> How much time do we have left?
Harrison_Tang: By the way on door I think your screen is still showing the dif uh uh web page uh yeah thanks. ✪
Andor_kesselman: Oh sorry sorry about that um thanks for for telling me um so wants to pull back here uh. ✪
Andor_kesselman: So twins run like a pwa so you can see right here um this is the slide where it shows basically it's running as a thin layer underneath the apps. ✪
Andor_kesselman: And basically all apps can connect to that data layer over dwn. ✪
Andor_kesselman: And you will have basically for example a profile this profile is uh able to be used across apps so there's no single app that that contains your profile it's reusable across crap and and it's semantically driven so you're able to actually you know represent your uh reuse that data and kind of um. ✪
Andor_kesselman: Partition it in the same dwn um and and have users basically build on top of it. ✪
Harrison_Tang: We don't have we don't have to uh do the whole hour we can do the q&as at the end yeah. ✪
Andor_kesselman: Um dwm thanks can run in the browser in a native app in the server and Docker um and we've had a number of apps that have been built with WN and the hackathon uh we've had like at least probably more than 10 I've just listed a few of them a decentralized LinkedIn Anonymous door unlocking uh revocation system Health X protocol everybody's trying different things with dwns and there are number of tutorials from the main implementers of that are TVD a chat app the church do app and a book review app that you can check online they're really helpful just to know how to interact with w. ✪
Andor_kesselman: Appointment line there is a few different types of ways you can deploy it um the simple deployment is because it's peer-to-peer you don't need an extra server sitting on the cloud you could do this locally just between 2 TW dwn but for most cases we expect that you're going to want a remote dwn for high availability so in this case scenario 2 uh Bob has a local and remote dwn Alice has a local and remote dwn and they're kind of communicating uh across 30 W over the remotes just to keep the high availability um to make it so that way you know if you're on a plane fly or if you're out of network if you're on camping you can still connect with Bob's dwn or Alexis dwn. ✪
Andor_kesselman: So this is what that kind of looks like. ✪
Andor_kesselman: Boba Sheriff has did with Alice Alice then would uh resolve Bob's did Allison sends a message to Bob promote note. ✪
Andor_kesselman: But then relay that that message to to uh his local node. ✪
Andor_kesselman: Then now Bob has that message on this phone where then he could relay his responses back to Alice's note and and down to Alice's note uh local note. ✪
Andor_kesselman: Any any questions on this slide before we move on. ✪
Andor_kesselman: You just check the chat real quick. ✪
Andor_kesselman: So all of basically messages that communicate over dwn are are Json based messages uh they include execution parameters authorization materials signatures signing encryption information um and they arrive in ipld sits and dag API so um. ✪
Andor_kesselman: We have basically 2 main really important interfaces so if you go to the actual spec on actually I'll pull that up real quick. ✪
Andor_kesselman: I'm going to pull up the spec real quick. ✪
Andor_kesselman: Okay if you look at the spec you'll see on the left hand side we have a number of interfaces defined you have records protocols and permissions. ✪
Andor_kesselman: Uh domain I think like really important ones are records and protocols those are 2 critical interfaces of course permissions matter and sink but the ones that are really unique I think our records and protocols permissions is actually getting an upgrade uh pretty soon so we've been talking about ways that we can handle permissions a little bit better um but I'll go quickly to describe a little bit about how records and protocols work and then permissions is moving to a first class protocol that's something we've been discussing um and then sink is the concept around keeping those eventually consistent with each other. ✪
Andor_kesselman: Um so let's do the records and I'm running through this relatively quickly because we do have a lot of content here but if anybody wants me to stop and pause on a particular slide uh feel free to to let me know. ✪
Andor_kesselman: Records um records are just where you you start there the messages that store your data basically and and you can filter them on various uh parameters you can filter them on schema you can filter them on context IDs uh you can filter them by your parent IDs or by the protocols themselves um on the records query you can do temporal sorting so you can you can query by data sending or decreasing so that gives people the ability to sort of Define you know how they want to order their records when they query them off of the dwm. ✪
Andor_kesselman: And uh these records are encrypted in a fine level so that way you only have access to the records that you've been authorized to have access to you're not going to have any access that you don't shouldn't have. ✪
Daniel Buchner: Yeah I would I would you know insert that the record. ✪
<carly> Are records all in JSON? Or could tabular data be stored in a record?
Daniel Buchner: Not um well everything in the D of un is effectively a record right it's uh some are stored some are not but there is no HTTP API it is effectively almost like RPC um that was done because it it was trying to maintain you know gnosticism in terms of the the transport so when you when he showed that like object that said query you can query by all these things in the right by by um tags that you apply to the records and um and you would send this content object sign with your bid you know maybe permissions if necessary or not if it's something public to filter and and select for what you want and this is going to be interpreted by the dweb node to say okay well I'm going to run this query now that filters on these certain attributes that you know he was describing um everything really is an object though whether it has a binary attachment or not or Jason attachment or not everything is an object um and when we get to the records portion here. ✪
Daniel Buchner: Because everything is an object even mutations of files so like if I logically create a record that stands for say an image um I would then update it by pushing new record objects that tie to its ID and mutate it. ✪
Daniel Buchner: And it keeps its eventually consistent so um it understands even though there might be multiple changes coming into different instances of your dwn that live in different places it's always going to achieve the same eventual consistent state of that logical record um given the mutations that occur on it does that make sense. ✪
Daniel Buchner: So he'll he'll go through this I think in 1 second. ✪
Harrison_Tang: By the way there's a a question in the chat uh are the records all in Json or could the tabular data also be stored in the record. ✪
Daniel Buchner: So the the the records are like more of a logical Concept in the sense that there's this control object that that is Jason it's always Jason um and that is small it's really small it's just like this little descriptor thing you see here plus um you know jws for signatures you know if you need to prove who it came from right you did um that's that's really all right that is always Jason um the whether it has a data payload the data payload could be anything and we've tested it with up to 100 gigabytes binary so it could be as large as you want it to be um so it has large file capability um but all these little items in here are um are a little little items that some of these are a little bit outdated with the encryption thing isn't doesn't list it there anymore but like most of them are saying um and that's a control value and then it also has an authorization object that is the JBL so I was talking about beyond that um your records are whatever the current state is of data you push in accordance with the latest record. ✪
<carly> Ok - so a record can be like a catalogue entry of the content referenced by the record. Thank you.
Andor_kesselman: We'll keep on thinking um the other main piece of uh dwns I think are really important here are protocols. ✪
Andor_kesselman: The protocols are basically if you were to Define how users interact with the data layer uh via. ✪
Andor_kesselman: Office verb action scope how would you do it and um it's basically a Json document and um it's defined in the spec here I'll just pull up here uh an example of a protocol would be like this which basically says uh on a post anyone you can read the post on a reply anybody can write a reply and so it's establishing basically authorizations around who can do what um over a Json document. ✪
Andor_kesselman: And uh you can see here on the the the bottom right this would be an example of post anybody for your right and and reply to recipient and the offer of the post can write the reply to it so there are certain established like words that you can use but it's essentially its own little you know definition language um that can describe the pre-advanced interactions with your your data layer um. ✪
Andor_kesselman: When you want to establish an app for a protocol you just basically configure the protocol on a dwn and now various apps can also connect over that same protocol and and do whatever data interactions they they require. ✪
Daniel Buchner: And something I'll note is so these Protocols are queryable if you make them there's this published true property you can put in your protocol definition if you do that then people can actually query your dwn to see what you have installed um to see all the the you know if you have a chat protocol installed if you have like a you know social media if you have LinkedIn style protocol whatever and then they'll know whether they can interact with you the protocols have like a dialect so like Andrew if you show them the example again um that sort of simple example you'll see that there's these uh the actions right those actions have other capabilities like you can set certain objects to be roles where are you going to cover this by the way Andor the role thing. ✪
Andor_kesselman: Uh I'm very Loosely because I was figuring. ✪
<ian> Is audio dropping out for folks?
<paris> Same for me
<harrison_tang> the audio works for me
Daniel Buchner: Okay so I'll just I'll cover it so you can make like an object a role you could have like a under structure you could declare that there's this object or record type called member right and you could say dollar sign role true just kind of like actions these are all reserved sort of um triggers and so role would mean that some any any did that you make the recipient of that member record for instance uh becomes a member and then you can refer to it in your actions you can say roll member can do this um and they have to show up when they go and do their queries or whatever their mutations are in reference to that they have to sign it with their did so that you understand that it's coming from someone who occupies that role really what protocols are is kind of a first open-source decentralized implementation of gbac like graph-based authentication which actually is tied to did so it's sort of like this hybrid um object capabilities Apple thing. ✪
Daniel Buchner: And uh like Arbok its its role it it offers some role-based capabilities and some defined actors like anyone author and recipient um but all based on DS. ✪
<dmitri_zagidulin> this is fairly classic RBAC, fwiw.
Daniel Buchner: Um and the really cool part is you can compose pretty much any apps authorization structure that we've come across anyway you could do slack authorization structures of admins on channels you can do kind of anything you want by coding in this dialect um there's a couple other actions or not action but trigger types like. ✪
Daniel Buchner: Action their size you can set size minimum maximum on certain things so if you said post and you said dollar size you could say minimum this money by its maximum this money bites or whatever combination you want and that would actually tell the dwn to enforce maximum sizes on records so that you don't end up with posts that are gigabyte maybe you want them all under a megabyte you can actually do that and then all of your nodes will listen to it they will effectively look at this rule sheet and they will become eventually strongly consistent against the rules um so what we've done effectively is we've taken out most of the centralizing business logic from um from the uh from apps and we've said you know because because really what centralizes an app is not just like hey can I address it by did right like I I could make I could sub out Dub or DNS domains for bids today and it wouldn't make Facebook decentralized right what makes Facebook decentralized is. ✪
Daniel Buchner: All the logic that comprises the output of a thread on Facebook if I can't replicate that looking at the same set of data and I can have that on my devices it's not decentralized the logic the actual guts of the app is in Facebook so we're taking that out um the I saw someone in the chat say well it sounds like our back the difference is Arbok um Demetri is the Arbok typically keeps a table of actors or an actual off to the side and then refers to data the thing to keep in mind here is that the actual object capability across are the actual data objects so if you had a member object that actually contained like Bas 64 images or binary image or whatever an object a record that stood for that the record itself is the capability so you're not separating like oh I have a capability over here and let me use it with a record the record that was sent to you and you being the recipient like Alice to Bob of that did that's the capability so. ✪
Daniel Buchner: About I'm issuing capabilities and then I'm dealing with data you're always just dealing with data because the data and the graph is the capability. ✪
Harrison_Tang: And Dory if you're speaking we cannot hear you at this moment. ✪
Andor_kesselman: Oh sorry thank you um it's on the other table um so I'm gonna skip over subscriptions um I'm gonna just talk about some of the work coming up um that we we know we have to tackle propagation is something that we care about which is how to get uh basically a synchronized State faster through uh a larger Network um so there's a few things we're working on um but we've obviously come a long way since since the last year and and uh we're hoping that hits us back pretty soon um implementations right now there's mainly 1 implementation with uh. ✪
Andor_kesselman: TBD um but additional implementations would be appreciated so if anybody wants to try to build their own uh dwn SDK um I think that would be very helpful for the spec and and help inform us as well so um feel free to to take this back and uh try to to implement your own version. ✪
Andor_kesselman: Uh we are working on aligning the implementations currently with the uh or aligning to spec with implementation and we have an MVP of the spec coming out pretty soon uh we're just trying to close out a few uh final items for the uh finished version via MVP of the spectrum. ✪
Andor_kesselman: So I'll pull it off now to Dan Dan if you want to take over and show a little bit of that demo and then um we'll follow up with him at the end talking about some of the stuff we're working on on dip that's going to include DW in some parts of the process. ✪
Daniel Buchner: All right this is I don't know if people can see this this is still kind of really rough I've only been working on it really like Super Heads down for a couple weeks maybe 3 um but this entire demo that you're going to see and there might be warts and stuff so just you know please be uh aware of that um is all just DW on this is a straight up static web page that is served um there is no quote unquote active application server behind it we we want to make sure almost everything we can do is just you know as as you would a pwa right that can be hosted on GitHub pages so the end goal is that we're going to release this demo at on GitHub pages that you could fork and change the colors and make your own version or tweak the display but it's all just actually driven off the user cwn so there's this sort of ghetto connect that I have that's going to get a lot better this will create an identity. ✪
Daniel Buchner: Just to make my profile look better all this stuff is being stored both locally and in a remote dwm at the same time so you always have this you can do offline inherently offline um so you don't need to sit there and you know wonder if like your data is going to persist um you know let's do that you know put in some. ✪
Daniel Buchner: Um yeah so it kind of adds a little social stuff um 1 little interesting little part here I'll just put in a bunch of my like past job stuff I I kind of copied um LinkedIn effectively um so we have all their features now. ✪
Daniel Buchner: I'll just put 1 in to show you all what it's like um what was it it was like september 2016. ✪
Daniel Buchner: Um so yeah it has the it has like all this uh all this good stuff which is just again all driven by your dwn so if as long as this works there you go so um you can put in a bunch of things it'll link it up just like like it does with um with LinkedIn you know connect all your your um contiguous employment stuff like that and and again all of this is just dwn records this image is a record um that's defined in the protocol I'm using this background hero is a record um this is a social record that encompasses your career I can kind of show what that is like right now um I'll just go in and this protocol is deconstructed a little bit just for expediency sake but this is um if people can see this screen. ✪
Daniel Buchner: Fall is just a social protocol um that we're proposing has some objects here aggregators follows story like people you follow all these can stand for actors for instance could be follows um thread reply media right so I've laid out the structure if you see that there's no actions allowed like this is it just means that only the user themselves can do it so the actual owner of the dwn that did can do that um story you know we're going to say there's no actions under story immediately so only a the person who owns the blog can can add to it media author of the story can create update and delete media um comment anyone can create update delete their own comments create update and delete by the way our our constrained by default to your own material so effectively records You author if you this is saying that the author of The Story So me if I authored something and you came in commented code delete means that you're you're allowing people to delete across the stream. ✪
Daniel Buchner: Other pools wrecks and all of this is eventually strongly consistent so if you synced 1 of my blog posts that I put in my dwn um the activities to create comments and represent comments and the deletion of them are all eventually strongly consistent so everyone gets to see a consistent view of everything that transpires under that blog post um whether it's the update of image or anything um. ✪
Daniel Buchner: So let me go back to this there's this concept of stories I'll write my first story this is all just live real time then added to the dwn you know maybe I want a nice image of a pool or some crap like that um as I live type that this unknown image thing is picked up here um with did relative URLs so if you see this dweb thing I can kind of enlarge it real quick um. ✪
Daniel Buchner: I'm working on right now a service worker that will actually catch um what we call drls dweb links where they did is the authority portion and then there's this path that's understood by dwn Centric apps and then it'll actually catch that um transform it into an HTTP compatible URL by looking up the ddoc getting the service endpoints and then replacing the URL path for the authority portion and so that's actually what driving this image there's no code on the page that understands these links um but this is a DRL link that's dropped in an image and caught as a part of a service worker at the network layer and so what we actually can end up doing is having did relative links on the web if someone just installs this service worker in their app which I think is pretty cool so even an app that's not even built using mostly dwn stuff maybe it's an app that's totally centralized and just has like a random image that comes from a deal a DRL link. ✪
Daniel Buchner: It'll make those things magically resolve whether it's linked assets or scripts or images anything on the page that takes a URL that goes and does a remote fetch will now be active and able to be resolved against this the did relative link does that make sense. ✪
Daniel Buchner: Um so there's a little view I'm working on some of this stuff now but you know it's it's coming a long way I mean a lot of what you saw was just set up it took a lot to kind of you know get the app going but single page app totally static all the data comes from the local dwn went offline or if online optimistically tries to go get content from other people's dwns instead of the cache local content um but we believe that you know this is an application substrate we we've. ✪
<harrison_tang> what is the difference / relationship between DWN and PWA?
Daniel Buchner: After it in a way where you should be able to build anything on the next 1 I'm going to tackle is Evite like we're just going to replicate Evite um after this sort of medium Centric thing um and and I'm just going to keep going until I've we've got a Cadre of apps that just cross the gamut of of everything not just social I mean a lot of people like to make social protocols that don't work well for other stuff but we're talking about like private collaborative document editing like you would have with Google um you know docs everything it should support it um so I don't know totally want to take questions um. ✪
Andor_kesselman: Harrison and a question about the difference between uh or relationship between GW and pwa it's not the dw1 is actually the pwa is just sort of this statement right underneath the the the app that can allow you to run it you know as like an app but dwn will will there essentially that data linking so there I I don't think PWS haven't scoped really the same uh sort of data capabilities that a dwn would have but the the the the reason why I brought up is initially was just that you're running it as a light layer underneath your existing app. ✪
<ryan> How easy is it to use a crdt on top of a dwn? Why do applications become eventually consistent?
Daniel Buchner: Yeah and I I would say that the 1 1 big thing to remember is that like we see like a pwa is basically you know with this did stuff we like to call it dwa it's just like imbued with the service worker that understands how to translate did relative URLs into um into other you know actually resolvable URLs um so in that sense like a pwa is just or a dwa is just a pwa on steroids I guess you could kind of think of it as. ✪
Harrison_Tang: And then Ryan has a question on how easy it is to use like uh crdt on top of a dwn and why do applications become eventually consistent. ✪
Daniel Buchner: So the dwn itself kind of is a a very rudimentary crdt like the D the it is a a um last right wins effectively d i so there I just added another little guy but um it's effectively a laestrite wins crdt at the very base so like if you have a file that's a newer version of the file that's appropriately signed follows the protocol rules for whatever protocol it lives under um it's going to win and all the when it's circulates amongst your dbms it's you know it's going to be the 1 that is the the latest known record um you can add other crdt functionality so for instance there is if I go back here to this protocol definition um if you wanted to craft and I'll just quickly create like an alternative structure to show you so let's say that I I have a different type of app and I create this structure and my app is going to be a a Docs app so I'm going to have a logical Doc and these can have instances so it means when I say. ✪
Daniel Buchner: Doc here it's like there can be. ✪
Daniel Buchner: Right it's almost like a class in here I could have Commit right I could have this thing called commit I out on the outside I could say um I could say every doc. ✪
Daniel Buchner: Participants has participants and I go in here and I say roll true so now I've just made the participants records a role record meaning yeah I can store data about a participant in a role record but it actually is when it's uh assigned by as a recipient to Bob for instance he becomes a participant so I can come in here and say actions. ✪
Daniel Buchner: It should be Doc sorry doc participant. ✪
Daniel Buchner: Docs participant and then I can say can um let's say can. ✪
Daniel Buchner: Okay cool so so let's say I do this right I have my and obviously I need these same objects declared up here but I have docs that can have participant roles and they can have commits against them so someone creates the doc right and Alice does she adds she has a participant role record she sends the Bob's dwn because maybe their friends you can even have like global global records like friends. ✪
<harrison_tang> is DWN analogous to Controller in MVP (model view controller) framework (but decentralized)?
Daniel Buchner: Um and you know because she's a friend she gets to drop the dock in Bob's thing and um and now Bob and her have this first understanding that there's a dock that they share together they can start crafting commit records now though the payloads of those commits records could be Delta crdt stuff like it could be Auto merge payloads it could be merge patch payloads whatever you. ✪
Daniel Buchner: So what I'm declaring is that all of the payloads of commits are Json patches so what happens is as Alice and Bob are adding these in a in sort of a commit stack like a little bucket they're going to pull them down and stream them and then be assembling the chains to the document that they're both co-editing. ✪
Daniel Buchner: Which is going to give you output of the total document there's a little action under here called squash that we're working on um to help this out. ✪
<andor> The controller is normally a little more ambitiously scoped than the DWN. DWN's are pretty stupidly scoped
Daniel Buchner: You can put a commit in that rolls up all the other commits so basically saying delete all data that's older than me I've got like the smash together done thing so far right and obviously that's powerful you wouldn't want to be doing these squashes all the time but you know whenever there's a lull in traffic you might compress it um and that ability right here to do a Docs app um that any any sort of crdt you want under your commits it's mostly the payload that drives it and then the the clients who are taking those payloads and assembling them in accordance with the particular crdt you chose to employ does that make sense. ✪
Daniel Buchner: Okay yeah let me just cut the call cut off the feed here and just stop sharing. ✪
Geun-Hyung Kim: Oh great so I will share uh my slides 1 second. ✪
Daniel Buchner: @Harrison: DWNs are more Processors than Controllers at least in the GDPR sense ✪
Geun-Hyung Kim: Okay so um first of all thank you for having us um you know I used to be a co-chair of the WPC CCB and uh very excited when it's morning with the chairs about how we can continue to work together so um we wanted to roll out a preview some of our plans um just to contacts I think um iaw of this year is probably good um grounding for what we're trying to do so um I think we saw a lot of signs of success for decentralized identity standards and protocols um you know a lot of the sessions were uh really sort of heads down focus on you know uh a specific technical stack and achieving interoperability and that's great because that really shows signs of adoption including for regulatory sources but it's also a really good time to check in and figure out you know so what were the original. ✪
Geun-Hyung Kim: Goals of decentralized identity or self-government identity what are we trying to accomplish here and it's much broader than the sort of um you know individual interoperability uh specifications that we're working at it's a a privacy um the ability to own control your data portability avoiding deep platforming and I think Daniel's demonstration shows really compelling example of how um you know if you're controlling your data then you get to reuse it across this variety of applications which currently are siloed and this is a much broader problem than just you know the sort of um kind of low-level standards that that we're focusing on um of late which again is great great sign of success but a good time to pop up and think about the bigger goals so um this is part of a broader effort that we're doing which is spinning up a dip incubation lab and the idea is to host. ✪
<daniel> If data is encrypted, a provider of a remote host can't see the data, and the host cannot manipulate the state, because as long as you can get the data from anyone, you will become consistent with the correct state
Geun-Hyung Kim: Spin up apps like in the demo that you saw I'm going to speed through this because I want to leave time for answers most of the answers sorry questions and answers most importantly but um some context on the life cycle so historically what we've been doing is stepped uh 1 and 2 which is incubate and develop specifications and um you know really focus on that incubation part and getting the matured and they live in um sorry I went to a show some examples so BBS plus did Cam dwn presentation exchange and then specs can either live in dip or they can uh be uh move on to other organizations so w3c open ID foundation and ITF and uh included are some examples that have have moved along um we do want to complete this cycle by focusing on step 3 and that's really where this incubation. ✪
Geun-Hyung Kim: That's where we want to allow people to figure out these things so you know independent of the sort of low-level discussions of specifications how do you fit it all together what can you achieve with it what does it really mean to achieve interoperability and um you know through a broader ecosystem lens and so um what this group is focusing on is uh you know it serves as an incubation environment for decentralized identity based user applications and specs it does provide an IP safe environment so that for example if it's an incubated spec it can uh mature appropriately and for this group a really interesting in attracting people who are building products um and interested in real applications of decentralized identity and building we mean in the most expansive uh sense you don't have to be producing code um because there are examples of some work items that will be coming through the group that are. ✪
Geun-Hyung Kim: Um ecosystem landscape surveys recommendations but of course you can incubate specifications you can develop code and I think most importantly and this is 1 reason that we're really Keen for feedback from this community is we're not intending to restrict it to decentralized Identity specifications so um we we want to be very practical and realistic that these standards live in a broad range of organizations and where people are really struggling is figuring out how they all fit together so you can sort of think of this as a um live executing um um sort of instantiation of what we do with different profiles which are specifications I give a um a sort of description and reference to other specs to achieve interoperability. ✪
Geun-Hyung Kim: I want to skip over this part just um to leave time for Q&A but some of the uh initial work items proposes uh this 1 Z kdns coming out of the diff hackathon. ✪
<harrison_tang> who do we expect to run the DWN nodes? will it run on the server, or can it run in browser (like PWA)? and how long does it take to achieve eventual consistency?
Geun-Hyung Kim: Um that's that's going to be a code and some uh draft specification efforts the interoperability so the current the group that currently lives is the interoperability open group they're interested to make this uh the work items move faster and move those into the labs as a work item within Labs working on um updating the ecosystem mapping report performing analysis best practices and and what you just saw so actually we did the memo um at this point I'm going to stop sharing any questions about any of this and again thank you for having us. ✪
Harrison_Tang: I have a lot of questions but I just want to make sure that other people can ask their questions first so please feel free to just type in Q Plus Susan please. ✪
Susan_Stroud: Um yes I was curious if um and maybe I missed this about how to engage with the incubator what's the best like contact method for folks that may have a good fit for what you're looking for. ✪
<kim_duffy> kim@identity.foundatiion
Geun-Hyung Kim: Yeah uh just reach out to me I will include um my contact information in the chat right now so you have it and uh yeah just uh reach out to me so uh it would be through diff and so um we I'll I'll connect you with all the information you need. ✪
Harrison_Tang: By the way uh there was a a question in regards to kind of the different comparisons uh and uh I I know there's a a document in regards to the comparison guide but uh uh can someone actually summarize it a little bit how does the dwn approach kind of differ from like solid and other you know like encrypted Data Vault you know those kind of approaches yeah. ✪
<dmitri_zagidulin> Encrypted Data Vaults - a lot more low-level, just a read/write of client-side-encrypted objects.
Daniel Buchner: Yeah yeah so yeah I can run the Gambit a little bit on some of the popular ones right so solid is you know similar similar aims right very similar probably probably the most similar in terms of overwhelming aims um I I would say it's it's a quite a bit more centralized uh uses web ID instead of DS I think they were talking about adding DS may have even um but you know focused on web ID that was a big thing for Tim for like Jesus like almost like 2 decades um and so a lot of the authorization model is is much more trusting um it's not an eventually strongly consistent uh system like that it's not a distributed and decentralized system so it's it's much more about Provider Host Centric um hostcentric view uh suppose you know effectively whereas dwns are are very very um uncaring about their hosts to the extent where their adversarial they're very adversarial to each other so. ✪
<andor> i think Solid also requires client/server. DWN's do not
<harrison_tang> got it
Daniel Buchner: 2D bands like if you hosted a dwn instance at Microsoft and the 1 at Google and then 1 at your house none of them trust each other in the sense that it it's sort of like a blockchain I mean it's not a blockchain but it's sort of like it in the sense that it has this rule set and it must prove uh through the signing and capabilities that it holds when it transfers them and it eventually strongly consistent way that they should be at that State not because you know you get a message from a particular host or domain that says oh it's for me you trust me right and then you do something that doesn't require actual validation um yeah data events also don't require client server I mean technically it's a transport agnostic so you can send these record payloads um over anything we actually modeled them through jrpc um for you know off the bat because technically there's jrpc modules for Bluetooth and other stuff um so it's inherently able to be sent over all these mediums um when I would compare it to something like nostril for instance which is you know kind of a little bit has a little bit of Limelight not. ✪
<andor> They were at IIW and we discussed. I think they were interested in contributing to the comparison guide.
Daniel Buchner: Like activity Pub and Mastadon you know roughly 1. ✪
Our Robot Overlords are scribing.
Andor_kesselman: From the community but if anybody just thinks that there's something that's either inaccurate or needs to be uh sort of Revisited feel free to write an issue for us or um contribute to PR would be great um and we'll we're updating them as we get PRS and so forth and contributions so um just wanted to make sure people knew that there was also things like uh ipfs and Noster on this this comparison guide as well. ✪
Daniel Buchner: Does that make sense so in terms of the comparisons you heard like is it does it kind of do you understand what it is versus other approaches. ✪
Harrison_Tang: Yes thank you for the overview yeah. ✪
Harrison_Tang: Alright I think we are at time uh any last questions uh I think we have a little technical difficulty where a lot of people got kicked out sorry about that um any other last questions. ✪
<ian> Will the recording be posted?
<andor> thank you everyone.
Harrison_Tang: All right well thank you thank you and door thank you Daniel thank you uh Kim for jumping on and hosting this great session and and this is again this is like 1 of my most anticipated sessions and thank you for answering a lot of questions for us thanks a lot. ✪
<ian> Thank you-
<andor> thank you Harrison for inviting us
<harrison_tang> thanks a bunch!
<ian> @Harrison will the recording be available?
<harrison_tang> yes
<harrison_tang> we will try to publish it in the next day or two