 And we're live. Hi, I'm Daza Greenwood, a scientist at MIT Media Lab, and this is a presentation and discussion that I'm doing with friend and colleague Beth McCarthy at her regular Tuesday Mechanism Design Working Group. Here's everybody in the group. Hi, everybody, and Hi, Beth. Hi. Great. So tonight, I was, Beth and I thought it would be interesting to talk about this type of system that I've worked on over the years, many years now, in more of like a web world, because there might be some things that we could learn from it that could be extrapolated and maybe reused with some evolution in a blockchain space or in other, you know, more modern and emerging space in technology where questions of governance and overarching rules are needed. So we're calling it multipolar interlateral networked governance. And so the first word there, multipolar, kind of speaks to the type of network system where there's a bunch of stakeholders or people that basically can't fire each other. So it's not a single hierarchical system or a centralized system in the sense that there's like a five term or a single authority in charge. So this would be different in that way from, say, you know, Facebook or a payment system or a government system or almost, you know, most systems that we think of have a kind of a hierarchical ownership of control to it. But some systems actually are multilateral. There's some treaty organizations in the public sector that are that way. You could think of the United Nations as being something like that. There's lots of trade consortia to supply chain sometimes is one kind of supply chain where there's one big supplier at the top of it. And in a lot of folks that they sell to, or there's a big buyer at the top of it like like, you know, Ford Motor Company or Boeing and a lot of suppliers that go up to them. But some of them actually have a lot of big buyers and a lot of big sellers. And they're in more of like a network. So the idea of multipolar is getting at where there's not just, you know, one or two, but there's several big players that all have to agree voluntarily on how they're going to connect and operate together. So that's the first word, multipolar. The second word is a little bit strange. It's multi, excuse me, it's interlateral. And that's a word I just made up. And what most to mean is, you know, in the contracts, so you could say the multipolar kind of speaks to the business kind of real politic of, you know, how many power players are there and how is that all distributed. The second word interlateral speaks more to the legal dimension. And so in the law, when you've got two parties agreeing to something by contract or even by like an international agreement, we would call that bilateral. If you've got a multi-party agreement, I sort of mentioned this earlier, you might call it multi-lateral. That's sometimes used that's in a multi-party contract, we would probably just call it multi-party contract or something. Multi-lateral is more of like a when you have sovereigns involved. But the idea of interlateral is that there's a bunch of players and the system describes interactions that are ongoing and like an operations layer. So just like we have like internet, for example, you can also structure rules at a high level so that they allow for like many to many and even like emergent interaction. So it's what interlateral is trying to get out there. You'll see more what I mean when I show some examples. And then the last word is networked and that kind of speaks to the technology a little bit more. And that just means that we've connected the endpoints like the systems and the services, like the nodes, if you will, on a network so that there's a sense of continuous connection. So a blockchain is networked in a sense. Certainly anything on the web is networked. Anything within a local area network or a wide area network in an organization's networked. So network just really speaks to the connectivity that's continuous and online and digital. Okay. So before I kind of go any further, can you help me ask it if there's any kind of questions or, you know, clarifications on just that scope of the talk? Because I know that's sort of a... Yeah, I think it would be really good to kind of ground and how each of those relates to blockchain, like maybe even go back through, you know, each of those words and say, okay, now that we have an understanding of where this concept comes from in a general sense, how it relates specifically to kind of the possibility space that we're looking at in blockchain. Specifically when you were talking about like sovereigns, for example, it's like interesting to think of, you know, if that originally applied to kind of sovereign states that are all able to kind of like act autonomously in this network to figure out, you know, incentive compatible ways forward or, you know, pushing like laws or standards, like, what could that mean in a system of sovereigns, you know, figuring out how to govern itself, such as, you know, Adele or, you know, these other kind of blockchain systems that we're creating. So, and yeah, just, you know, to kind of have a grounding of, you know, how governments in terms of, you know, governments and parties that, you know, are able to act autonomously from a legal perspective, then flows into a, you know, term of governance that's both kind of a metaphor and kind of an abstraction, but also a very, has a very specific meaning, so. Okay, yeah, there's a lot there. So, I think in general, what I'd like to do in terms of connecting it to the blockchain is first just show three kind of examples of how this stuff has been done in the past. And then once you've kind of seen those three examples, then I want to extrapolate, well, first of all, just if there's any questions about it, make sure everyone understands it, and then extrapolate to sort of best of these systems that could perhaps be used in a, in something like a Dow or another distributed type of system on the blockchain. I think that would be the best order. There's one little distinction I'd make from the way you said it, with the sovereigns, it's not so much about them acting autonomously. They have no problem acting autonomously. This is an example of a framework that is, you know, been honed over most centuries in a sense, but certainly decades, so that they can act collectively, despite the fact that they are sovereign and have the right to act autonomously, and, you know, on their own prerogative and do whatever they want. It's sometimes in their interest to agree voluntarily to have a kind of, you know, a set of expected behaviors and interactions that actually limit in some sense their sovereignty, based on their agreement, because they find it's in their interest to act collectively sometimes. So this is fundamental for the multi-polar intermodal governance. Does that describe any governance system that operates in the context that you describe, or is this a very specific framework for governing? So, what are the two options? So, does any governance system which operates in the context that you define a multi-polar intermodal governance, or are you presenting a very specific framework that you feel is well adapted to those contexts? So, unfortunately, this is the curse of, you know, these kind of consumer-grade technologies, but you blurred out the word that was most important, which was what that context was you were describing. So, thank you for the distinction. I'm sorry. Thanks for passing me. Can you hear me better from here? Way better. I can hear every word now. It's a dream. Perfect. So, yeah, my question was the context that you described would be a multi-polar intermodal governance. Would any governance system that is used within the context you describe fit into that bucket, or are you presenting a specific framework that you feel is well-suited to those contexts? I got you. Okay, thanks. Boy, it sure is handy hearing every word. So, yeah, that's a great question. Could you put me back? Yeah. I bet this is what it's like if you upload your consciousness to like a brick or something, you know, people take you places. Okay, now I'm back here. The answer is, yeah, this is very much tuned to a specific subset of situations or contexts where this combination of attributes for governance seems to be handy. You know, the most typical kind of governance that I've set up in my career has basically had not either of the first two attributes. It's not kind of multi-polar. It's singular and it's not interlateral. It's more like unilateral and basically they're like bylaws or rules governing a hierarchical system. So, most of what I'm talking about here would be totally inappropriate and overkill for that kind of thing. But when you start getting a bunch of different parties together that kind of can't fire each other or cannot order each other around, it ups the ante a little bit. It requires a little more sophistication for coming up with an umbrella set of rules and the governance of those rules and technical architectures and business practices and everything. And so, what I'm going to show you is a method of addressing those. So, let me actually just spend the next few minutes and just show you some examples and then let's talk a lot with the examples in mind. And definitely I'd be very interested to join you in a brainstorm about if there's any things here that we could learn that could be useful in this kind of very next generation enterprise of coming up with distributed autonomous organizations and entities with a blockchain. So, I'm going to do a little screen share here. Am I sharing? Yeah. Okay. All right. So, here's just a blog page I set up for tonight with some links. So, okay, here's a good example of a very common set of rules. I participated, got back in the 1990s with this group. It's called NATRA, National Automated Clearinghouse Association. So, their ACH payments are a big part of how money gets moved from banks to bank and this is the organization that comes up with the rules for that. But it turns out that they have a number of councils that come up with rules for different types of payment networks. One of them that I've worked on is called EBT, Electronic Benefit Transfer. And this is an example of the rules for that. So, just at the high level, you can sort of see there's always some definitions, which is a whole thing coming up with single definitions across different players in context. And now notice here, so okay, first of all, the type of system this is is sort of like a credit card system. But the card holders are actually welfare recipients. And the idea here was to move away from paper food stamps for welfare benefits because paper is so gross and and fraud prone and fragile and people lose it. Getting it onto a card, we thought, would make it more efficient. And also a little bit less stigma when it came time to pay at the point of sale. They just use a card like anybody else. And we felt that there'd be big savings and it would be better. In fact, over the decades, it has been shown to be much better. So, one of the things in any card holder kind of payment system, most like specifically credit cards, but also these debit type cards is that you have banks or one stakeholder group. There's two kinds of banks, the issuing bank and the acquiring bank. The issuing bank kind of issues the cards. And the acquiring bank kind of works with a merchant and they've kind of received the money. And then I kind of gave it away, but you have merchants that are at point of sale that kind of receive payments. And you have card holders and in Visa operating rules and MasterCard and others, they have more systems, they have more sections on the card holders and the card holder agreements. With the welfare, it's kind of just already, it's already so heavily regulated, they didn't need to treat in the rules here. Now, other kinds of things you have in here are, here's a good one, liability and indemnification. So in these multi lateral types of arrangements, especially the voluntary private sector ones, that one of the reasons we're doing is to figure out how what everyone's risk is and to try to contain and manage the risk. Another thing is breaking into having, knowing what role you play in the network and what your rights and obligations are with respect to every other role in the network is another reason why we kind of write it down and negotiate it. So there's roles and relationships and they're specified. And then for the type of transactions they're doing here, error resolution, settlement and reconciliation are big processes that the network deals with and they have guidelines and standards and rules for that. Security is always a big, big thing here. And then another thing is people want to know who's in the club and who's not in the club. So there's usually some kind of trademark or service mark or some kind of logo that will let you know if you're in the visa club or if you're in a certain supply chain or in some network or consortium or federation and that's an easy way to know who's in and who's out. And the fact that it can be trademarked also means if people start using that mark but they're not really in the club, like maybe they're a fraud artist or they're trying to mislead people or they've been kicked out recently, you can stop people from using the mark because it's basically a violation of trademark if they're not approved to use the mark. So trademark is another interesting characteristic of basically all these groups. Miscellaneous was just due to sloppy drafting and then you also see agreements. So the way that people, you might wonder like how do these overarching rules, how are they, how do they apply to anybody that's in the group? Like how are they enforceable? Well they're enforceable by contract, just private people agreeing with other private people and the basic feature of the participation agreements for any party playing any role in the system is that they say we agree to abide by the rules of the system. Like that's the main thing that they do. So let's take a look at one or two of these as an example and then I'll just skip over to a couple of others. This could be a good time to stop and ask questions because I know there's a lot of different parts here. Kind of starting with the fact of the importance of operational definition. I kind of divided what you said into kind of sections of first set out operational definitions of like who the actors are, who they are in relation to each other and from that you're able to say these are the different points that make up the system and then you need, you know, marks to come in and say, I mean, you know, marks as in like trademarks to have a function of saying, okay, these are the, you know, kind of assets or products or like, you know, materials related to the system or entities and, you know, because it's been very clearly defined who is able to, you know, access or use or attribute what in which ways. Then like the marks enable these kind of, I don't know, use cases to be like enforced and directed. So then it's almost like an operational definition of like actions. Sort of is a little blurry at the end of your mark, but everything else you said I think was exactly what I was saying. A couple of notable things that you didn't mention, which I can't stress enough, is in the business part, it's like, well, who's in and who's out and how do you get in, you know, and how do you get in as a certain role. So like there's certain things you can't just declare yourself a minor, for example, like you'd need to download a node and, you know, have some computational power, like there's things you literally have to do to be a minor. In the case of these more kind of lockdown networks, some of those things include signing agreements and, you know, have a certain amount of insurance or, you know, other types of things. So like who's in and who's out is a major one for business rules. And I can show you the subset of that is the process for onboarding usually involves some kind of process and some way to get into a registry or directory. And then the process for offboarding. So one of the great things about looking at systems that have been functioning for decades is they worked out a lot of things and regularized it and, you know, kind of the water is flowing over the rocks. So there's no sharp edges. So offboarding is like voluntary, you know, if you decide I don't feel like being in this anymore or lose my entities getting out of that line of business, there's like, you know, you kind of give a notice and you tie up your affairs and you and then you're taken off the list. And then there's involuntary termination, like, oh, wow, like you're plaguing everybody. And, you know, you've been like the source of a lot of fraud and problems. And, you know, we've gone through arbitration through times with you. And there's some criteria at which people can no longer be in the club anymore. And that's a core part of a voluntary organization to be able to keep functioning is to know what are the minimum expectations to remain in. So who's in and who's out major on the business level on the legal level is the next big bucket of things. Liability is like 90% of what is argued about 90% of the rules are parsing liability and damages. And the technology, it's really security and standards and procedures for interoperability and what kind of data do you have to gather and what services are supported, that kind of stuff. So those are some of the major features. Now, let me show you one that I think is a little better because I wrote it. So you might have noticed I just kind of put things into new categories. Here we go. And the categories I found having done a few of these things seem like everything kind of fit into business stuff, technical stuff like card specifications, security stuff is almost all technical and legal stuff, liability arbitration, dispute resolution, whatever. So here's an example of another organization. This is called ID Federation. And for the last maybe 15 years or so, whenever I write up these rulesets for these multilateral organizations that are in some transactional system, I always break them into business stuff, legal stuff, and technology stuff. And that seems to have worked really well. So here's the trust framework is the overarching rules for this identity federation and the insurance space. And then there's the participation agreements. Let's take a look at the trust framework. Here's the most current one. So one thing I'll say is that the insurance industry was very classy and they were very good and they were very, I appreciate that they let us publish this one under a Creative Commons license so that in moments like today, it can be shared. So some mission statement is best practice at the top. What is this about? The equivalent might be this DAO is to allow people to pool their assets and figure out what they want to invest it in. Or this is to make it easy to digitally sign things or time stamping. Just basically whatever it is, it's helpful to make sure everyone's exactly on the same page for what the scope of the thing is. Then there's a bunch of business stuff, more detailed scope. And then I literally just separate all the roles out right at the top. So in this one, it's identity providers, relying parties, people you can sign in with, policy authorities, this federation operator, which would be the equivalent of people like miners and like whoever the core developers are, assessors or people who go around if something has to be certified, who's qualified to certify that it meets a standard. In this case, when there's an official communication of some type, or when there's a notice or an alert that's official, not just email or something kind of whimsical and a GitHub issue, you want to distinguish those. Where do you find all the policies? Who's eligible to be in? How do you stay in? 103 continued compliance. And how do you get out? You can be terminated voluntarily or involuntarily. And then you get some warnings as typical, audit. You could be suspended in this case because they wanted to get people a chance to get back in without too much service disruption. Training, there's training requirements. And how do you use the trust mark? Now, here's a bunch of legal stuff. We just put all the legal stuff in this section of the same document so everyone can see all the business legal and technical stuff, no matter whether they're business people, legal people or technical people. We found that made everything work much better. I found that many times. So legal stuff, liability, like I promised is the first thing. And there's some interesting stuff there. People want to drill down into it. If you start getting enough of an industry doing something, that's really good feeling, but it also has some bad stuff that can happen. So sometimes you need an antitrust policy in there. So we had one in this case. People usually like to obsess over who owns things or something on intellectual property. Dispute resolution is huge. One of the best things about having people agree on how they're going to behave upfront is you can keep disputes inside of the system. There's no need to go to court when this is done very, very well or there's rarely a need. So we have sort of a system here for mediation and that doesn't work, go to arbitration. In this case, we just identified the American Arbitration Association's rules. They have a subset of rules for commercial arbitration and we just kind of set that. Not much is confidential. I'll skip over some of this stuff, but the only other thing I want to say legally is order of precedence. So a lot of times you're dealing with parties that are not just using your system to do things with each other. They may have other contracts and other business relationships. So a big question can be like, you know, you have to understand that whatever DAO you have or whatever network you have is not the only thing that governs these people's relationships. So sometimes you need to indicate if they've got other contracts, maybe those don't apply when they're doing this thing or if they have some other big contract between themselves where, you know, they split liability evenly. Well, maybe that's between those parties going to be the thing that governs and if it conflicts with the liability of your little network, then, you know, their previous agreement maybe they want to govern. So being real clear about the order of precedence of what rules apply, especially with a bunch of parties that have a bunch of relationships is very good idea to do an amendment. So, you know, it's foreseeable that you're not going to come up with a be all end all rules on day one. And this system here has actually been amended four times over the last 10 years, you only have the most recent couple up there. But, you know, technology changes, the types of transactions and use cases they want to cover change, stuff changes, and there needs to be a way to amend the rules by by consent. And then here's my favorite part, all the technical stuff. This is the fun stuff. And so usually when I do these things, I just start right up with the use cases, like what use cases are we covering? And how do you get new use cases on in the future, on board, like on a roadmap? And how do you retire use cases that we don't want anymore? And so we have an appendix for all that. And then here are the standards that we're applying in this case. Oh, there's an excuse the interruption. Is there any chance to set what? Wait, let me read telegram here. I just got a notice, but then it disappeared to set the live stream on your screen share. What does that mean? Oh, is it not sharing? Oh, no. Oh, here we go. Okay, sharing now. Thank you whoever said that out in Internet land. You can go back and see everything I just said by scrolling through IDFederation.org. And from here on out, I've now set the right camera for the live stream. Sorry about that. And isn't telegram great. You're welcome, David Hamill. Okay, so standards. So in this case, we're just using a few standards. Security Assertion Markup Language was the big one. So what subset of that standard are we applying in this case? Call that a profile of the standard, which attributes and what fields are we setting and how just to make sure everything's interoperable, we kind of write all that down. The big thing here is to get into the network technically, we have to do a metadata exchange for all the players. And that's how we onboard them onto the network and make sure everything's routed correctly and everything's discoverable and we're auditing, making the right stuff, kind of operate correctly and that we can audit it later. Time Sync can be big where you stratum three here, which is pretty fast, but not like military grade fast, not even TV grade fast, but pretty fast for a network and for these transactions. Some stuff on usernames and passwords, the equivalent would be key management on a blockchain and wallet stuff, delegation, logging and monitoring is big with these people, security is humongous in the industry. And then the technology people really were awesome and part of what they did was come up with this little table. They wanted to know, well, for any given role, like what are the specific things we have to do? So just at a glance, our staff can know what we're doing. So we put that in there. And here's the appendices. So well, just scroll down. Here's a certificate policy because we're actually, we're building on top of a public infrastructure a little bit there. Here's what you can and can't do with a trademark. Basically, when you're in, you can put it on your page and put on your service. When you're out, you have to take it off. Antitrust policy is if you're very successful, you'll be lucky enough to have to worry about that. Intellectual property rights, basically, most of this stuff was not proprietary. Amendments and change management, really important. I can talk about that later, but basically all the key stakeholder groups in this case, it was insurance carriers like the Hartford, like Liberty Mutual, I think, progressive insurance. That's one group. Another group was brokers, agents, vendors. So those are the kind of major stakeholder groups or the polls, if you will, in this federation. And they all got to decide for themselves. They could kind of put people on this board of directors to make sure they all have representation. And then when it was time to change the rules, then those are the people that you could bring it up to. And then they, on their next meeting agenda, say we want to update to a new version of SAML or change something or other, and then they create a new version of the overall rules. So one thing I want to say about that actually, let me just get back here. So there's an example of a federation that's used in the insurance industry. And the most important thing about these overarching rules when they're voluntary is that in the participation agreement, you want to let people be able to voluntarily leave the federation before new rules for a future version of the thing become binding. So you can argue in the fed, in the group, do we want to fork this or do you want to upgrade that or support some new service or standard? And then maybe you win and maybe you lose. But when the sunrise of a change for the overarching rules is going to happen, needs to be more time than the amount of time for people to just easily voluntarily get out of the system. Now, some systems like the ones that I've worked on, it doesn't make sense for people to pull out in five minutes notice because you have to finish reconciliation and settlement and untangling them from all the systems and have them not show up on things. So usually it's like weeks or months even to get to wind down participation. So if people have three months, for example, to voluntarily opt out of this insurance federation, then maybe a new rule can't go into effect any sooner than like five months so that if you can't live with the next set of rules, you can leave. That's a core set of the basic deal for a voluntary overarching system like this. So that's a second. I've got one more example I want to show you, but maybe we can pause again and see if there's any questions or comments on what I've just said. I have a question on that subject. And the ID systems that I'm familiar with, mostly Trusona, which is not blockchain-based at all, Sovereign, which has a permission network on the blockchain, and Civic, which is permission-less. So what I was wondering, those three types of ID management system, are you envisaging, how much of those are you envisaging transferring what is currently done by human beings and organizations into smart contracts? And does the aspects of the system that can be represented in smart contracts vary greatly between different types of IDs? For example, sorry, I'd be very interested to hear what your comments would be on those existing blockchain-based ID systems. Are there fundamental characteristics that are significant and different from what you just described and insisted that? Are there any potential differences, or are you really looking at different functional behavior within smart contracts? Yeah, that's a great question. So the only one of those systems that you mentioned that I'm really familiar with is Sovereign and the Sovereign Foundation. And I'm very vaguely familiar with the others. I could take a look and speak in a more informed way about them, but just to at least address Sovereign, they are an example of a very overarching multilateral voluntary organization that does exactly what I'm talking about. And I'd say they're actually best practice. When it comes to rules, they have business, legal and technical sections of their overarching rules and participation agreements. And it's very sophisticated the way they do it. The question, so in terms of what the rules are that govern that kind of network, I'd say they're really good examples of what I consider best practice. And I didn't have anything to do with those, but I really admire them. However, you'll notice that I'm a little bit out of my depth there, but to my knowledge, I think they're all pretty much instantiated in narrative human readable text documents. And the smart contracts that they have in the Sovereign Foundation, to my knowledge at least, they haven't translated yet. And I'm not aware of any of these federations or consortia that have yet translated these rules into purely machine readable code. And part of the reason why I wanted to have this conversation with Beth's group tonight with you all is to, first of all, get a good hardcore look at what the fundamental ribcages for how to make these networks work. And then have a real conversation about, well, is there anything some of it probably shouldn't and doesn't apply? Some of it maybe would be very wise to apply, because the kind of issues, because humans ultimately at the bottom of a lot of this, and it's foreseeable we'll have disputes, and it's foreseeable that things will change over time, et cetera, et cetera. How could we express some of this in, well, solidity or another smart contract languages? So I'd say that's very much an open question right now. And I think the question you asked is the question that gave rise to this talk and that we want to talk about. Well, thank you. And I will definitely listen to the rest of the talk about mine, too. Thank you very much, and I look forward to hearing more. Hopefully we'll be in the next steps in reference. Yes, we'll check out the next. Any other feedback before I show the last one? Okay, hearing none. I'm just going to show you one more, and then let's talk about whatever you want to talk about. So here we go. Okay. So now here's one more I want to show. This is one that came thanks to some DARPA funding at MIT, several years ago, like God, back in 2012, I think it was, we had this system where they wanted to see if we could, how would we develop a personal data system, basically, so that vets like returning from the wars could have their own system for holding their personal health records and other personal data. So we prototyped some WISBANG MIT technology for that, and it was very distributed with PDSs or personal data stores. And this was an example of what we thought the rules base would be for that to operate. So again, maybe no surprises, but there's some business stuff, legal stuff and technical stuff. Business stuff has like, what is the scope, what I just said, personal data for individuals and operating with their care providers and others, friends and family, individual participants, system provider, like who's running the system, third party providers, like maybe WebMD perhaps or clinic or something like that. Now something that I started doing around this time was having a section up in the business part where we actually identified what services were currently supported and provided in the system. So you can just sort of slot in new services and sunset old services. So for various reasons we didn't go into detail about each of these services, but in this system there was a personal data storage and archive service, kind of like imagine a Dropbox, but that was more owned and controlled by you. There was a data collection and import service, so you could get all your stuff with something called Blue Button from the Veterans Administration and from doctors and other stuff. That was a specific service with some standards and some metadata and kind of JSON and XML stuff for data structuring. There was a personal data sharing control service which allowed for certain authorizations that the users could set. That was a service that was addressable at a REST interface. Analytics and visualization, so people could see stuff in their data and they could use third party apps and services to analyze and visualize their stuff. They could hook it up so long as they were standards compliant. How do you know what standards compliant? You could read section 1.2.4 for all that in an export and deletion service. So that became way bigger years later with the European Union's right to be forgotten. So this ended up, you'll see it's the last one, it almost didn't make it in, but it ended up being very important. So recording, what are we keeping records of, who gets to use the logo, it's the kind of business stuff. Legal stuff, who makes the rules and it was basically like the idea is it would be like a representative consortium, order of precedence again, rights and obligations between the parties, it's handy to know. What are you supposed to be logging and how do you do reporting? Liability, like I said, I promise it's always a big part. How do you amend the things? How do you get notices when it really matters? Other stuff. And then the best part, technical stuff. So in this case, we're using OAuth2. And so we sort of indicated the profile of OAuth2 we're using to integrate external third party apps and services and platforms. And what's authoritative and normative? So these are like the absolutely official versions of the standards that we were applying. Authoritative and normative? Yeah. Do you see section 3.1.2.4? Yeah. Yeah, so we might have just called them normative and we might have just called them authoritative, but and they're fundamentally synonyms, but some people that were involved used one word, other people used another word. And we all agreed that if we called it authoritative and normative, everybody knew what it meant. But so literally that's how this sausage was made. Well, could you kind of explain the concept of that? Because I think I know what it is, but I think that I feel like that's one of the most useful things for extrapolating this to a blockchain system. For example, especially in a context where these systems are made by developers, usually not involving lawyers at all, then how do you have a system that has normative rules? And when do those normative rules also convey authority within the system? And then for this question of extrapolating that to smart contracts, how does the authoritative power kind of invade autonomously within the system? So yeah, I think going into authoritative and normative would be super helpful for kind of grounding this discussion. Yeah, sure. So you'll notice that there's very little in section 3.1.2.4. We have the OAuth standard, the core standard and for bearer tokens. And then in this case, we had JSON object signing and encryption. So like JWOT tokens, JWS signing, JWE encryption, JWK keys and our algorithm. There's a lot of stuff that people would do that we didn't say was authoritative and normative. So for example, how are you doing CSS? Well, that matters for the apps. And you know, there's a lot of different things people did that they could sort of do their own way in that we didn't, we said was out of scope of what it meant to be able to be interoperable and to be a basically like part of this network. But what was not negotiable were these two sets of standards, some OAuth 2 token stuff for authorization tokens and basically the digital signature and signing stuff and the crypto stuff. And that was the result of discussion about what was core and fundamental to the network. And it was so core that there was really no argument that it needed to be in the rule set and we needed to define what version of it we were going to all apply and if people couldn't deal with that, then they shouldn't be in this network. And that's why we wrote it down. Yeah, so how do you account for that changing? For example, like if you, you know, a certain, you know, a certain version of CSS, or like if you're referring to like a component library or like a pattern library for being, you know, what is used within the system, what if that changes? You know, how do you account for the ability for that change to happen and still be in accordance with, you know, the way that the system is functioning? Yeah, so up in the legal part, we have this section called amendment. The rules may be amended from time to time by the system provider in accordance with the notice requirements. So you'll notice that this is somewhat arbitrary and partly, you know, mind you, this was this particular system, let me get off screen here. This particular, and you can all see the links yourselves, but this particular system was a pilot from, you know, a part of Department of Defense called DARPA. It was an advanced research project and it was absolutely hierarchical. And so they just, you know, it was, you can think about almost like Facebook or Dropbox or Google, they're going to provide it, but there was not any debate about it being a democracy. And so whoever provided the system would amend it, they'd give you notice, and that's that. So nothing really fun or even interesting there. And the insurance network, by contrast, if they wanted to change the standards, which has come up from time to time, then basically the way they worked it out was very interesting. So what made sense in that context was people across the industry that were involved actively in this network would join one of three working groups. One of the working groups was a technology working group. So it was people from the CIO or CTO's offices or the security offices from across the industry, no matter what stakeholder they were, insurance providers, brokers, vendors, they did the technology stuff. And when they all kind of agreed that we needed to change something in the rules for the technology, then they would vote on it, basically. And then they would propose it to the government, this little governance council we had, which was, you know, had some representation from all the industry. And for the most part, the governance council would, you know, ask everybody, has anyone objected this or no one objected, then they would change the rules. And so it was very much bottom up, you could say, people in the technology working group or the legal working group from across the industry or the business working group wanted to change something. They would just propose what sections they would change. Something that was interesting that they had to do, by the way, in that case, is a few months into it, they realized, you know what, like the technology people are changing stuff, we're not really sure what the implications are. Like, do we need to change something legally? Or is it a change of business process? So they ended up doing this beautiful thing, which was called a harmonization committee. And I wish more industries and groups had that. And basically, the chair who was voted by across the business legal and technical groups, they all had a rotating chair. That person, the chair of the business group, the legal group and the technology group had a three person harmonization committee. And whenever any of the groups wanted to change something, they'd just show it to the other people, and they'd scan down the stuff that like the business people really understood the business stuff, legal people understood the legal stuff, technology people understood the technology stuff. And they could just talk like three people and be like, oh, would that change our notice? Or would this change the specification? They could go back and forth. And sometimes they had to ask a clarifying question back of the group who didn't realize the implications. And they would work out what the changes should be. So usually a change in one section would actually cause a little nipper talk in one of the other sections. And then when they, so at the end of the day, actually, they agreed that only changes that were recommended by the harmonization committee to the governance words were the ones that went through. Because whether we voted for or against it, at least we know we weren't going to break the whole thing if we change one part of it. So I was surprised by how beautiful the insurance industry was to work with. They get a bad rap, but they know how to govern stuff. And at some point they decided we're not competing on passwords. We need to make this interoperate and be invisible. We need to collaborate even if we compete on the market. And so I'd say that they're a really good example of how to collaborate well and harmoniously. So those are some examples of how you might change what the norms are that are authoritative within a system. If you had a little bit more formality and explicitness with the rules, usually norms like true norms are not written down at all. They're just kind of agreed socially and impliedly. They're more like customs almost. But when you use the word normative, it has a little bit more of an official flavor to it. Yeah. I mean, and, you know, in terms of being something that isn't usually written down, I think that's one of the core questions about how to translate these, you know, kind of emergent like qualitative relationships into smart contracts where it's like, you know, if you want a system that runs like autonomously or semi-autonomously with regards to governance, then you need to translate the sort of thing that aren't usually written down, you know, have a way of translating norms. And then throughout the system, that is interoperable with, you know, all of those three like BLT verticals. So I think that's one reason why this discussion is incredibly useful for mechanism design. Like, you know, so that will be incredibly useful. Hopefully, yeah, that's the understanding. So that's kind of what I wanted to go over. I wanted to show you three kind of examples of what a umbrella rule set for a big network with a bunch of people that can't fire each other could look like and how you could break things into business legal and technology buckets. And that can actually make it run a little bit smoother and then not just break into business legal and technology buckets, but to have those three things be part of a single markdown document or single file so that everyone can see the whole thing and having unified glossary or unified definitions across them can make it easier to have true interoperability is not just a technical phenomenon. A lot of interoperability happens at the business level and the legal level too. So you kind of got to get all three of those cylinders firing in sync to have complete interoperability of systems in my experience. Yeah. So let's open it up to everybody. I don't care if you don't want to talk about what I just said, but what does everyone want to talk about now? That's a straightforward question. So you mentioned the importance of having like some concept of being in or out of a network. In cases of like the origin of these networks where you may have, can't think of a concrete example, but let's say you've got a couple of bodies that are adhering to the same standards, but they are different networks. Yeah. I guess have you encountered any strategies for kind of reconciling that like situation where I've got linked networks and that in or out problem. By one network's criteria, this actor is going to be out by this network's criteria is going to be in. Yeah. Yeah, that's like my whole life basically. Heterogeneous networks, but like they want to kind of interoperate when they want to, but no one wants to change what they do or how they do it. And it can be a challenge. So sometimes you can come up with like translators or adapters or you know, things that will up level or do some sort of, you know, some sort of like some kind of like translator of some type and that can work. Sometimes, you know, there's different parts of an organization. Like this happens in libraries. Here's a good example of what I think exemplifies what you're referring to. So libraries have are usually members of multiple different networks. And some of that has to do with just what they can interoperate with. So their card catalog might be one way, the way that they do kind of like, you know, like reservations could be another way. The way they do events is a whole different way. The way they, you know, they've got these different systems of systems, and they have to be in different federations and networks to make it work. And usually, it kind of clusters into people that really have a high value or priority to work together and who have like leadership that is willing to either change to basically use standards or approaches that maybe aren't their first choice, but achieve the, achieve membership in the community they want to be kind of, you know, operating within. Or sometimes it ends up being that we've got, you know, two different networks doing the same thing for no reason other than that they were locked into different, you know, vendors or different standards or even different versions of standards sometimes. Like I remember with RSS, like there were all these great podcasting networks that use one version of RSS, then RSS, there was sort of a second version, some of them used it, and that really broke a lot of, you know, great things, the fact that the standard moved and some people didn't and other people did, or they tried to use some other stuff, RDF came along. And so I think what you're talking was really at the cutting edge of the conversation of how do we get along and what are we willing to do the same and when do we draw the line because we don't want to do it that way. And can you explain the significance of RDF and how long it's impacting this because I think that's also a really important thing for people to understand with this discussion. Okay, so who knows what RDF is in their show of hands? One, oh okay, so I guess this is good. So RDF is a standard that comes from MIT, actually, from CSAIL and the World Wide Web Consortium and Tim Berners-Lee specifically. And it basically has this way to sort of its structure data, so it's a data structure kind of standard and it operates based on so-called triplets. So it's a way that you can sort of like connect three things together, like kind of like a subject and object and verb or that kind of thing. And it makes perfect sense to a lot of people, they love it, makes no sense to a whole bunch of people, they don't get it and it seems somewhat arbitrary at some point. But if you use it, it gives you a little more flexibility with what they call semantic web, so you can do more sophisticated nuanced ways to relate different things. There's other people that use this standard, which is just straight JSON. It's a notation language for structuring data that's more like almost like a markup language, so you can basically kind of like chunk parts of information between tags almost. And so it doesn't have a sense of triplets. And so one example that I think is beautiful and it comes up with DIDS, distributed identifiers in like the sovereign space and some of the sovereign identity space, is people came up with this hybrid of the two, JSON-LD, which is this kind of version of JSON that represents RDF like triplets in it. So they kind of like use the JSON syntax, but then they also kind of use this RDF concept and they've found a way to sort of merge it. So at least on the surface, it still kind of looks like JSON, but it also kind of achieves the stuff that you want from RDF. In reality, it's RDF at the bottom of it, so like you still have to understand that and the logic of it to parse it and make an application do the right things. But that's a great example to the gentleman's question about what are people, like how do you deal with different folks kind of having maybe different standards and how do you make it interoperate? Well, there's a lot of people that wanted the RDF world and the JSON world to interoperate, like including people in the sovereign identity space and I think people came up with like a new hybrid standard for it. That was one way they did it. More typically people, it's kind of winners and losers, I'm sorry to say, where people are just like, well, do it this way or the highway. That's unfortunate. The best thing is when you look at what you're actually trying to do and then you select the standards or you select parts of the standards that you're going to apply to the way your community wants to do it. I'm starting, maybe I'm getting old now, but it kind of feel like the best most important thing is human beings is fascinating and wonderful as technology is. And then if you know there's a bunch of people that want to have a relationship with each other and they want to be doing things together, I just feel if you're creative enough and intelligent enough and have enough endurance, you can find technology that can support and reflect the way people want to behave and want to interact and build backwards from what people want and who wants to play with each other. But people should never be prevented from playing with each other because someone in a technology group said you can't. To me that's a failure of the technology. Yeah. And also, yeah, I don't know if this is getting too specific, but yeah it would be really cool to kind of explain like the role of like why RDFs are useful for representing the semantic information in a way that's more, I don't know, well, so this is getting like that. Oh, sorry, that's actually what I was doing with the question. So, yeah. What's a GTR? Sorry. Oh, right, right, right. Yeah. I'm sorry. GTR has like three different meanings in my head. Okay, I got you. Yeah. Thank you. It's totally good. But I think links those potentially. I have kind of a directed question that like links those, I think. So, you know, we have the goal of like drawing back from this to mechanism design and talking about how, you know, what we've been talking about here is like very specific examples of, you know, mechanisms that work and mechanisms, you know, mechanisms that are working in a system and how those are codified and, you know, how they work on a technological perspective and these different things. And so I think, you know, it would be very useful to like, if you could kind of like draw back in terms of detail to say, you know, this is what, this is how linked networks or like why it is necessary for linked networks to be able to represent information in this way. And then, yeah, to get to your point of, you know, when we're designing mechanisms that are acting in the system, whether it's, you know, something like a TCR that like is trying to accomplish a certain goal that that goal, that goal would need to be able to be codified in these agreements, or whether it's, you know, a governance structure that doesn't necessarily involve, you know, explicit mechanisms for curating, but instead just, you know, mechanisms for behaving equally, like, you know, why it was important to go into this detail and also, you know, how, for people who aren't thinking of it in such a technical way, like, specifically how this applies and why that is like, you know, unique to blockchain specifically. I think you made things like additional networks are set off and how this is things in the, yeah, I was wondering about- Could you move my, could you move my little computer body closer to the speaker? I just want to hear every word you're saying. Thank you. Sure. So it sounds like we've been talking about additional networks and how actors can be added to them, what sort of governance rules can be set up. And so now kind of seems to make sense to talk about, well, how can we implement this in the blockchain world and develop trustless networks that, that accomplish the same and some. Yeah, I agree. So can I, Beth, you mind if I just pick it up from the speakers? Yeah, sorry. She actually asked exactly what I was trying to kind of articulate drawing it all together. So here's a few thoughts on that. So one thought would be, I'm drawing a little bit from conversations with, with Dao Stack and, and with some other groups that are trying to do more flexible Dao's, you guys know Noah Thorpe, he's in San Francisco. Anyway, Noah Thorpe and Tony Lai is another one that's been working on a bit of a gap that seems to exist with blockchain-based systems. And it's specifically at that level of governance. And so that raises a question. So last time it was at Starfish Network was during San Francisco Blockchain Week, and we had this big event on governance and blockchain. And one of the part of what we were talking about, which I think we're still talking about tonight, is what is in the gap? Like what are the, the way I would say is functions of governance that you would want to have addressed and available in a blockchain? And, and how could you do it? If you wanted to exist, for example, in a smart contract, if you wanted to have an attribute of trustlessness, these are kind of how-tos, but there's also a question of what would you do for governance? So some things that I would suggest are in the past have been helpful in governance or one to have a clear way to distinguish who's in and who is no, shouldn't be in a network. So if you've got, for example, people that are, I don't know, fraud artists or trying to bring the system down, being able to distinguish an attack from, you know, from a healthy node is a great thing to do. And yet you don't want to draw that line wrong and cut out people that are not doing anything wrong. You don't want to draw the line wrong and have a bunch of people and bring in a network down. Governance is a place where you can have a conversation about those kinds of standards. The other thing is, how do you avoid like a dramatic, tear-filled hard fork? A hard fork that is the result that surprises everybody? One way to look at that is, well, could you have anticipated that there might be a desire to go different directions, or there might have been a way to come to a consensus on a future version in a roadmap that addresses everybody's concerns through governance? Like could there be something, some method, mechanism, process that you could identify within your system that would enable a kind of progressive and a graceful evolution of the system, as opposed to an unexpected, dramatic, mostly offline hard fork? This would be another feature or function of governance, I would say. So that's how I would kind of look at what could potentially be learned from the past. What you don't probably want to do is in the past people had meetings, you know, so that it'd be a certain number of people on a committee, it was bureaucratic, and they would have a vote and they would vote on the next version. But is there a way you could do that in a way that's programmatic and automated? So it's a result of the activity on a system, or it was crowdsourced, or in other ways could utilize the system itself to internalize what the evolution of future versions of the system would be. But anyway, these are some of the features of the best of functions of governance of multi-player networks of the past, and some of them could be on a to-do list for architects of DAOs that are looking for functions to achieve through autonomous automated methods. So that's kind of how I look at the look at the connection that I think you're asking about. Yeah, and do you think that there is really one differentiating system? Yeah, I don't see why you couldn't. Like if people in the past that had paid me in the private sector to create these systems, it said, Dazza, we don't want to have meetings. We don't want to have like a harmonization committee, and we don't want to have that, and we don't want to have Microsoft Word export as PDF as the rules. Rather, we want an express in solidity, and we want people not to have a vote on a committee in a spreadsheet, but we want a token to represent how people have a say and how we update other parts of the network. I think it would be possible to come up with that. I think if you set as a constraint for developing and architecting the processes and systems of governance that you want to effectuate it through tokens, and you came up with tokens that represented proposals as you do. I mean, that's an old thing now, and maybe tied to proposals that change the system rules versus proposals that are a transaction within the system and set new kinds of barriers like they do in DAO stack for supermajorities, for big rules, and you could even do things like tokens that represent that someone has accurately performed a formal verification of a proposal and that that creates a kind of token, and you need that token with the other voting tokens before something goes on a roadmap. I do think it's possible to do things with tokens. I don't think anyone's done it yet, and not to this level of sophistication, though. Yeah, I am a curator, so I'm always asking if that makes sense, and I'm not sure that not sure anyone has yet answered the why you need a token in this kind of system. Why you need a token? Yeah, I mean it's possible, but why? Oh, well, I think I mentioned this at the start. Nobody has ever paid me money and said, you need to use a token. It's never been the most efficient or effective way to just get their network doing the transactions they want, but if somebody felt there was a business needing a priority, I think you could use a token. I to this day have not heard a business case for doing that, but people keep swearing, people I respect tell me that there's something worth it, like Tony lies, I respect him a lot, and he really believed in saying with this guy, I know where Thoroper you should meet in San Francisco. They think that there's something about this token economy that's worth exploring, so that's partly why we're talking about it. I myself have not yet seen that light. I do, because actually what he just described is like what I'm building, so it's like building a token in our system before one of these gal companies to basically as a method of enacting governance, so that was kind of the basis of this discussion like, you know, saying what is, you know, like in terms of like architecting a system that is able to enact governance in this way, and for us, like, you know, we're still at the beginning of kind of developing, you know, the token as the primary function is like, from using a token as a way of abstracting something, well, abstracting and then creating something like reputation. So if you want to be able to have like a variable in the system that goes with, you know, so it's like we had talked about how like, you know, identity is like really important, like variable to describe for how like these objectives are actually achieved. It's like how do you have identity served in a functional way for kind of figuring out, you know, who is able to, you know, take into a small work, who's able to define the rules, who, you know, is able to like enact and enforce the rules, who's able to change them when, and, you know, there's not a system, so essential, oh, yeah, so it's completely decentralized, well, not completely, it's decentralized in a certain way, and so it's like, you know, in order to figure out who it is that's able to do those things in a decentralized system that you have to be able to have like reputation and, you know, or competence, or whatever it is, it's just reputation, you know, the function that's often used, and it's like the kind of token that is runable right now, so it's like, you know, how do you define competence, etc., and how do you like accumulate that in which way that sets parameters, like that's why, so in that system, it is reputation, sorry, I can't like super talk about it yet, but in a few weeks, yeah. So can I ask, is there, see there's a few other people around the table, there's, you're under no obligation to speak and I want to make you uncomfortable, but does anyone else have any thoughts or reflections or, yeah, so could you move my little computer body close to the speaker, sorry? Yeah, so I think like, I think like the identity problem is the crucial problem first to solve for decentralized governance, because for example, if you just take governance by token, right, say like everybody in the system is voting for a particular decision whether to go left or right, so you can't just do that with tokens, because then there's going to be a form of civil attacks where the person with the highest take is going to be able to choose the direction of the path, so you kind of need an identity where you know like a single person is not voting twice, no matter how much stake he has, and until that thing is not solved, it's going to be pretty difficult to like have mechanisms to really operate and make it more complex to really govern the system. Yeah, so on that, can I ask a question? What are you, what if, so I've been talking to a number of people since 2016 specifically on how best to distinguish at population scale, whether an entity on a network is a human being or a non-human entity like, you know, software or a bot or some type, and one, so here's the question, what do you think of the idea of using an existing capability that we have in every country, which is, that's widely deployed and accessible pretty much to almost every person other than very, very rural areas, and that's a notary. So in the U.S. you can go, there's plenty of notaries that are a little bit more of a trusted role, you know, they have a license from the government and they watch a person sign something and they notarize it, they saw this human sign it. That's not so different from watching a person do something on a keyboard, for example, in fact a lot of notaries now are electronic or digital signature notarizations. Do you think it could be possible to address the issue you're just describing by utilizing like a new class of players which are human notaries that are government licensed to authenticate the fact that the entity that utilized that token was in fact an individual human being? Yeah, so I think like it's more on the onboarding aspect, right, like taking a human being and putting him in somehow like electronic form, right, so we can always have like this on ramp, right, like for example you have trusted entities across the globe who are basically onboarding a human being to a particular key or particular identification on the blockchain, right, once that thing is onboarded you're pretty sure that like this is a legit account and the way you can do is that you can have certain like insurance model or something where for example I'm the entity who's onboarding a lot of people, I stake some of my money on the chain or somewhere and I basically do background check or something for that particular human being and if he does something bad on the chain any time I do a certain stake so it's the entity who is doing that is responsible so it's basically like would you let this guy drive your car or not, right, depending upon what kind of governance system is entering they can be multiple checks and you can have certain kind of staking model where I can as a business charge him for getting him on the particular model but as well I'm staking something to make sure that I put the right persons on the governance model. Yeah so you have a vouching and accountability for the vouching, yeah, that's very interesting so I think you may have answered your own question there, for what it's worth. It's kind of difficult, right, since we don't have that system right now like place where you can really have that solve that thing but I think once that's all like you can do awesome stuff like quadratic voting and everything with governance and I think that would be the crucial part once that's done then we're gonna have CEO really good mechanisms and the other thing I also think is that before you go to the other thing just one comment on the last thing is the life cycle moment you're describing is an identity management what we call enrollment you know like or you said onboarding is pretty good and you know enrolling in validation that the person you know should have a card or should have a this or whatever a connection but you know there's a lot of ways after people are onboarded to then proxy offer for them to zombie their machine and other things to aggregate it so I do think there's a lingering thing that's going to come back and bite us and you know 2020 and 2022 and in the future more and more when we still have these non-human actors that are aggregating things maybe without the knowledge or consent of where we're about for them in the first place and maybe even without their knowledge or consent because they downloaded the wrong email or something and having some continuous way to monitor just that someone is human and alive I have a feeling it's going to also be important I just want to say that but what's the next thing yeah I just started on I'm sorry I had a question oh wait sorry let me just say something quickly I think what you just said is an important answer to this question of how blockchain comes in it's like blockchain's ability to verify and blockchain's ability to make it so once the identity is verified and you know like number one that enables like the identification you know in a discrete scenario but also over time so that you can know you know that the same actor is you know being the actor in the system over time and once you verify that they are a human or that they are the right person that is supposed to be doing that you can continue knowing it's the right person and then the other thing too is that then once that's able to be done then you can have these quadratic voting mechanisms or whatever you were describing and so it's like it both enables um you know like foundation of the system to be laid and then like the rules and kind of put around a minute um I would love yeah if you could explain a little further about like why you know how blockchain vectors and gls choices for all that I think that could be very important yeah even like I just remember the other thing as well so I like uh this is like a very naive opinion but I think like the governance even if you start with like more democratic it's in the end it's gonna still like converge towards a small committee voting on the decision and I think people are gonna decide who like the committee could be big like 12 people 20 people 30 people but then people like a system with like let's say 2 million people are gonna stake their vote on somebody else voting for them basically so you're gonna have a small committee but like the entire ecosystem is gonna vote for the person who think they want to latch on because every decision cannot be like I cannot make a decision for like a technical reason for like governance of the political system right because I'm not educated enough but I might uh stake my vote on somebody I think would make the right decision yeah it's like in the end it's gonna converge still converge to a small committee of people that's what I'm guessing yeah but I'm yeah that's a well taken point I when I was much younger I ran for office and was elected to a like a local um government and something I did very frequently um because I was you know just my early 20s is I would look to people that I had a relationship within who I respected for certain like budget items and some people really understood infrastructure like sewage and roads and I couldn't necessarily evaluate all the information I was getting on whether we should do a 30-year bond and this and that or not and I would just ask them and I sometimes literally just look to see well how are they voting if they'd stick their hands up I'd stick my hand up and if they didn't I wouldn't and it would be different people for different things actually like education I'd look at other people and sometimes I would have my own opinion sometimes I just I don't know just got kind of like um whatever uppity and just did whatever I felt like doing uh but I don't think it's necessarily a bad social outcome for people look at those that they trust and to proxy their votes there's a whole big system in Google now um that where they're perfecting very scalable ways to um vector your trust in a sense and vector your votes to people that you think um uh can do a better that you want to represent you want a topic by topic kind of thing and then to be able to at a moment change that to other people so that you know you're always sort of accountable and it's always transparent and uh but that um it allows for the social function of people um you know congregating in in um factions or parties or voting blocks and that kind of thing I do think there's something very human about it and it's not not necessarily bad and it would also be like uh kind of critical to just examine how like big enterprises over here they say Google Facebook are all those big enterprises which are not run by a particular single entity right a single person how they make their critical decisions right how their company's going to progress and how they come to a conclusion or a consensus about what decision next stage should make right so that kind of model could also be somehow taken like you can take inspiration from some that kind of model to basically try to bring it to like other systems as well what do you think about yeah I agree um some of the best stuff I've done I've stolen from Google you know because like they've got a lot of people thinking about a lot of interesting things and some of the stuff they're doing should for civic purposes should not operate under a single oligopoly like Google but we should do it in open public networks and I think a lot of what they do is open source and it's very translatable and if I understood your question correctly I think it's a good idea to take good ideas from wherever they come and try to avoid patents when you can and reuse and extend them yeah yeah I was more about like how people inside Google right the board member or whoever is leading Google basically try to manage their their problems or their critical decisions right because that is also like a big governance system which like there is no like a single guy not deciding like who's or what decision to make in the particular enterprise yeah yeah I've been working a lot with Google people now that are you familiar with the walkout that they did um there's like 20 of the Google workforce walked out in protest over um like a golden parachute for like some disgraced um executive and then they did some other stuff with result with respect to their um just um their disagreement with their military contract and some other things for the um uh dragon fly project with India and censorship um they're organizing now very much inside Google in a non-hierarchical way that's peer to peer on these interesting dark nets and encrypted little forum things like that so there's a lot of lessons we can learn from how people are self-organizing at Google and not just the official ways either um okay who else has any questions or ideas could you move my robot eyes yeah I think you want to ask a question oh um yeah I was like many Google projects are open source and they're actually on GitHub and you can fork them not not everything what's that about the vector voting and like what you're talking about with the employees oh yeah um so Beth can you can you send me a follow-up um by email or telegram uh so I can go back and find that um that proxy was the word they used proxy voting tail um I'll find that and I'll I'll I'll send it to Beth and or I'll do it on the telegram group uh forum for um mechanism design and I'll share what I have on that is I recall the person published a paper and some of the code was out there and it was still a little bit iffy like a year ago last time I checked in on it and but I would love to share that I thought it was actually very promising cool yeah that sounds really awesome okay so oh sorry about the light I just uh I wanted to I read a big daza Anthony here okay what's going on so I read a book I believe last year by Temo Riley called WTF what's the future and in it and it talks a lot about artificial intelligence and looking at yes we are humans and we do make illogical choices is there a way I'm just I'm curious to know your opinion how do we integrate um data analysis data science artificial intelligence to help us improve our governance performance um both at the micro level but also reverberating beyond the little microcosm because you back up a few words I sort of spaced out or something it was how do we do what yeah how do we use uh artificial intelligence to optimize our governance structures because we are you know we we do get locked into kind of our self-fulfilling prophecies and we we may miss things because of ego or or just you know limited site so how do we integrate artificial intelligence to maybe get a bigger picture not just on our small microcosm but is there a way to compare our little bubble to another little bubble uh and within the bigger bubble what a great question thank you for asking that um so I know I can share uh so first of all I think the answer is yes um that that's possible and the way to achieve it is by continuously asking the question you know um but let me give you an example of of how I've seen it achieved um so um in the research lab where I'm a scientist um it's called human dynamics lab um and oh do you know it oh no okay I felt like I was on like a hovercraft there from but anyway uh so the human dynamics lab um did a very interesting um what we call computational social science research project with um with a um European European um trading exchange system and um I'm blanking on the name of it now I can send you the site later it's written about written about in this book called social physics uh where you can you know learn more about it but basically the the issue that they were having was that in this um training network well first of all the a function that it provided was what they call social trading or something like that and you could basically stake a sum of your holdings within within the network um to just do whatever trades someone does so it's almost sort of like an index but it's like if you're watching how other people are performing and even if you don't understand how they're making the decisions you just like what they're doing you're gonna be like well 15 percent of my holdings just do whatever that user does um and so one of the things that happened is if it is that it was subject like every market is subject to these bubbles um and so there'd be these like there'd be these um times when people would be sort of following the leader and then also be getting certain information like like all trading systems to give you like analyst reports and news items and things like that and they would be this like um bubble and it would bust and this is not very efficient for a market like a little volatility is fine but bubbles and busts we reserve for you know market malfunction um and so basically um what this group did um in collaboration with the trading system and in accordance with the rules was they did deep data science on what were the characteristics when one of these bubbles was forming and one of the one of the things we could say in colloquially was there's like an echo chamber so it was like enough of people that other people watched were sort of listening to each other and they kind of worked themselves into this frenzy and then there'd be a bust so using well you could easily you could call it artificial intelligence for sure but using various model driven you know kind of data science methods that are all cited in the papers that you can read they were able to identify when one of these bubbles seemed to be forming so before it formed and then they would actually give the people in that sphere and like one number outside of it I think different information it's just like well just start listening to other parts of the network and get more of a rational you know more of like a statistical norm of what's happening in your marketplace and they were able to you know very effectively reduce the number of these bubbles and busts um way below what would have been expected in the in trading period so that's one example where they realized they had an issue um they worked with some data scientists to in a sort of programmatic way break these cycles that were really the result of somewhat human foibles but also a little bit of system design so that instead of like having a rule or a meeting the system literally would programmatically change some of the communications or messages and make it more representative to avoid the echo chamber that'd be one you know kind of very literal example of a way that I know it's possible but in general what I'd say is what you said I think is the high promise of artificial intelligence and data science is make it so that we can get almost like a god's eye view on a system and not be so subject to the foibles and you know uh faults of um irrational of what we do as individuals and in her in her mentality yeah um I just wanted to follow up with that to connect to what um well so what you just described is exactly what I was hoping to get out with the question about like normative versus authoritative rules so there's this idea that I'm putting forward with some people called like algorithmic governance that's basically you know kind of taking the idea that you just described and saying you know here is the um like you know and like uh from algorithms determining like what the emergent rules and structures are um that you know kind of end up being authoritative rules or you know identifying what the normative rules and normative interactions are within this governance system and then you know because they are representative programmatically then they're able to become um you know the authoritative rules for the system if they you know are emergent enough so um you know if that would be interesting to talk about people I would love to kind of hear your thought of the connection between um those two things yeah well I think the way you described it when we were trying to when we were saying why don't we do a session together I think was going from like code to pros and from pros to like parameters and data driven processes well kind of the more what I was saying with that was in what we were saying about an RDF triple which is how those things all loop together it wasn't a um like linear process as much as like a two-fold that includes all three of those things as being applied for the emergent yeah the emergent structure to be defined so no for sure I think the trick with all this stuff is to you know do do some math and do some thinking and theoretical work and some design work but there's nothing better than to you know there's nothing to it but to do it sometimes um and you know being able to find existing systems like this research team did with the existing trade network um and do and try some of the data science approaches and measure very carefully um what the results were to see if it was you know safe and effective um and then to see if it made sense to deploy in production and then to build more systemically in um that's one way to do it and another way to do it obviously is to build a brand new system that just supports and reflects this algorithmic governance and see how it works you know one trick is getting enough people um so it's you know valid um sample and having something that's you know worth them actually doing as opposed to you know paying them to be like a research puppet or something and then the other thing is to another trick is sometimes people that kind of know how to break the system just wait until it gets big enough and there's enough honey in the pot for them to go and bust it so having a lot of people that are there in a scientific you know lawful way but doing whose whole job is just to break your system you know do every dirty trick every penetrating test anything they can think of because you know that will certainly happen naturally later anyway yeah totally and um yeah well up so are we um are we kind of at the witching hour now yeah so I would just love yeah if anyone else has like a final question or um just it's still would like some clarification of how all these things relate back into blockchain and mechanism design specifically I would definitely want to make sure that it's really clear to everyone that everything that we are talking about is grounded in mechanism design explicitly watching so if anyone still like yeah I have a little more time if people have more questions to clarify or more ideas or comments this is a perfect time to do it wait could you move my robot ears closer to the speaker so this is just kind of more of a brief comment to follow up on the um what we kind of framed as like an identification problem um and um there's a an argument that I've seen a few times which kind of sink in for me now and I'll kind of phrase it in the terms that we've been using so we we said there's a network and there's going to be some rules for who's in and who's out um if you design the rules for who's in and who's out in a way that is like okay I can be confident that someone obeying these rules is going to you know achieve the goals that I want with them this network then at that point you shouldn't care if that actor is a human or a robot or a consortium of humans because they're behaving according to the rules you designed um and I so I think that's a way to kind of design out that identification problem because um you're right it's like you're not going to be confident that this address is really a human or yeah yeah what was that um was it Neil Stevenson didn't somebody write a book not like you know 10 or 15 years ago on was it anathema or something or anyway someone wrote this interesting you know medium future book where there's all these like you know where the existing states uh government states you know long since past and you know it's become more like a combination of franchises and of warlords and whatever and you know half of the most effective ones were definitely not human like they were combinations of ai's and things and um I think we could definitely postulate that um for most of the systems that I do nobody cares if you're human or not they're very they're either financial systems or or their um kind of research systems and whoever's performing is fine and honestly most of the ones that are humans and corporations most of the activities happening in these like either like hikes and algorithmically anyway sometimes I do think it is important to have humans like until like for example in um for purposes of and this may not be an issue for some of you but for purposes of like um a post enlightenment public sector government um I think consent of governed is important and I think it's for the foreseeable future I would want to know um who are the human beings um that have consented to be governed um for the validity and the health of the social compact I think if we get to the point in the not foreseeable future where some entities are not carbon based and you know not you know but they're you know silicon based and we grant them citizenship um then that would no longer be an issue but until that happens I do think we're things like voting um and um public opinion about you know um you know like do we go to war or not and uh who's the president and that kind of thing um I that case that's where I was more speaking to in terms of knowing when you have a human uh because we're subject to um exploitation and uh being hacked basically otherwise like the it's not that we have this well behaving AI it's that in fact they're there to ruin everything so we can't have nice stuff anymore um so that's under my kind of high level musings on what you said but in general I'm kind of with you like if you have like software do things better like I would I would take care of most of my legal things like even when I used to practice law the best stuff I did was the result of scripts that that I wrote that were you know very not error prone everything was formatted correctly and you know it wasn't me at late night making some dumb ass error or you know kind of like format issue I feel like you know computers are great at doing a lot of the stuff that people currently do in commerce and you know they shouldn't be treated as you know it was but there's still some certifications there so we would like when so what you said about well behaved and performing according to the rules it's sort of rated you know I think it's we'd have to still have a conversation about what does that mean for algorithms and you know do you should we be able how do you audit algorithms that are black box or proprietary and how can you reproduce something or be able to explain why it came up with a certain answer um to know whether it is or isn't complying with a rule or whether we'll have some anomalous you know kind of um output later that will ruin everything in the in the perfect storm combination so what's that humans have that kind of output too yeah I know we do yeah so in some sense I don't know I guess I appreciate your point of view and I share it mostly um but to the extent that we've premised everything on it being human beings that are acting at that point I do think it's critical to distinguish whether it's a human acting or not or whether it's like a giant bot army that's been you know purchased like a mercenary to disrupt something yeah I wonder too if there is a governance model that can be created to help with demilitarization and denuclearization because I feel that a lot of the problems um surrounding like World War three scenarios is nobody wants to back down and there's no like drawdown method of pre prescribed like I just feel like the current system hasn't produced the results that we wanted to and I wonder if blockchain um offers a solution to having that transparent you know drawdown yeah it could I mean like I could imagine something where um where like strategic defense systems of like major powers um had a failsafe where when you know things were heating up according to some objective criteria we basically got like a time out from the blockchain you know to core jets and doesn't matter how many people you know do the keys at the same time we're not launching like we've basically suspended launch mechanisms I think that one of the first issues I'm thinking about there as well that would be the very first system I would hack on my adversary if I wanted to pound them you know they could put them in suspension but not me um but yeah I think you would be nice if we could have cooler heads prevail and frequently the coolest head is made of silicon the heatsink right with a good fan okay well I think I'm just about out of time unfortunately thank you so much thank you awesome thanks everybody I'm really useful bye I know