Modpol Metagov
Speaker 1: Welcome to our discussion about Mod Palfour MIND tests. I'm Nathan Schneider. I'm a professor at the University of Colorado Boulder in media studies. And I'm joined here by two collaborators who've been working deeply on this project, Luke Miller, who is an undergraduate student at Notre Dame. Luke, do you wanna say hi?
Top Keywords
- modules 0.023
- module 0.009
- luke 0.008
- mind test 0.007
- orgs 0.007
- governance 0.006
- game 0.006
- test 0.005
- consent 0.005
- code 0.005
- excellent child 0.005
- users 0.004
Transcript
Welcome to our discussion about Mod Palfour MIND tests. I'm Nathan Schneider. I'm a professor at the University of Colorado Boulder in media studies. And I'm joined here by two collaborators who've been working deeply on this project, Luke Miller, who is an undergraduate student at Notre Dame. Luke, do you wanna say hi?
Yeah. How's it going? Good to meet everyone.
And Luke is involved in a number of of Medigab projects, so so you'll, you know, see him in other contexts as well, I'm sure. And then, Skyler, Hugh, do you wanna say hello? Skyler is a an undergrad here at CU Boulder. Hey, guys. Alright. So, the two of you, please feel free to interrupt me as I just offer a few introductory notes. And then we'll get into discussion and play and experimentation. And I apologize to anybody who's heard any of these things before. This has been an ongoing project that we've been updating folks about. But we're now at a point where we've released the first version and really excited to share with you what's going on here. And, you know, feel free to jump into the chat if you're having trouble playing. So this is MindTest. It is a open source Minecraft clone that's all community run, non commercial, you know, really vibrant community building this this tool together. And, you know, we come out of, you know, through the conversations that have been developing in mind test or in sorry, in Medigov here, it just started to seem to me like we needed a place to play and to try applying some of these ideas to a game world. And actually, you know, the origins of the Medigov project itself come out of a game company asking for help on enabling governance to happen in its game. And then also, for instance, our collaborator, Seth Frey, you know, has done tons of work on on governance in Minecraft. And so the idea of trying to apply some of our our, you know, the the ideas we've been developing in MediGev to a game context, like mine test just, seemed in some sense kind of kind of obvious, and it's an extremely flexible platform to build on. You know, it comes for me out of work on this idea of implicit feudalism, the way in which so many of our online spaces are really impoverished in terms of their tools for governance. I won't go into depth about that, but you know, you can explore if you like. And so it poses this question of what else could be done. And some of the early thinking in the MediGov project resulted in this paper around this idea of modular politics, a framework for what a governance layer for online communities and across online communities could look like. And I'll just summarize a few of the principles there. Modularity, you know, enabling different features to be to be kind of modularized and combined with each other. Expressiveness to be able to capture as diverse a governance toolset as possible, portability that, you know, a tool created for one platform could move to another, and interoperability so that, you know, in appropriate context, tools created, tools across different platforms could actually work with each other and interact. We've been developing a bunch of prototypes in the Medigap project, such as the Medigob Gateway, informed by that thinking and that work. And this is a parallel project, a kind of experiment to try to apply some of these these ideas in a in a game context. One of the features of of MINDEST as a test site is it is, extendable in the language Lua, which is a popular extension language. So, we designed a, a mod for MINDEST that enables governance to occur within it, enables some of these features of modular politics. But because it's written in, you know, a widely used extension language, it can actually be migrated to other platforms with, you know, we hope relative ease. Most of the code base is is platform independent and can be run on the command line as well as in mind test. And so, you know, to bring it to a new space that also uses Lua as an extension language, it would require writing a few pieces of code, a new, but most of the existing code base would work. A few, also kind of design practices we we brought in that I think really differ from from foregoing habits is is putting power in groups, not in roles. So, conventionally, in online spaces, particular users hold particular roles, and they have permissions assigned to them in a way akin to the UNIX file system or the UNIX permission system. You know, we explored, you know, the design space of, you know, that I think is actually more akin to, to how, you know, people tend to operate in the wild, which is power is assigned in groups, rather than in particular people. When groups of friends organize together, they, you know, have to operate as a group, not, you know, having assigning a certain king to your friend a group. And so we tried to build on that kind of naturalness. You can still replicate role based power, but you do it you have to kind of do it through groups rather than having to rather than the other way around. We also kind of designed around assuming consent rather than autocratic authority. Again, a real departure from the usual design patterns you see in online spaces. And also nesting and inheritance. So, you know, this again recognizes, I think, how a lot of groups work in the wild where, you know, people take what they know about how to self govern from one space. And then when they create a new space, they kind of fork those ideas into it, into that new space, bringing a lot of their culture and habits with them. And, you know, we designed a system, you know, when you create what's called an org within another org, it inherits the the features of of its parent. Again, you can you can, you know, reverse that, but, you know, that that that's the default. So so, again, we, you know, built this tool set over the last year. You can you know, we can share the the the code base. I don't know if, Skyler or Luke, if you could put a link in the chat to the to the GitLab page in case anybody wants to explore that. But it you know, we're really excited to share a little bit about what this looks like. So I'm going to turn off slides. I'd I'd love to turn to Luke to share a little bit about the development process. Luke has been a, you know, incredible partner in this work, and and, you know, we've we've run into some roadblocks and so forth. So, Luke, do you wanna share a bit about that experience?
Yeah. I'd love to. So I started working on the project about a year ago now. When I hopped into it, we're kind of working on implementing the org structure, kind of a little bit code that governs that. And so we went through, like, a couple different iterations of how to kind of structure modules, which is a way that we build governance into this org system. So, essentially, modules are just little bits of code that can be attached to orgs. And so that allows for users to do things like hold elections or automatically create child orgs and more complicated processes, like, creating juries. And so initially, we were planning on having kind of a more restrictive structure which had a lot, like, better defined modules. And we spent a lot of time developing that and having this very kind of, like, well defined process by which modules operate. So, like, users can start a module that will, like, send that kind of request out to everyone in the org. And then based on our, like, earlier kind of intent to focus on consent, it would need to be approved by everyone in the org, and then that action would finally take place. But we realized that this kind of structure was a little bit too rigid and kind of limited the forms of governance and the expressivity of the module system. And so in the past couple of months, we've been reworking this to the current version. And right now, we have modules that are pretty simple, and that is essentially just code that anyone inside of an org can run. And so the system is, like, very widely extendable because we can have modules call other modules. We can have modules call a vote inside the org or call for users in the orgs to declare actions. And by creating this, like, system of building blocks, we've been able to implement a bunch of these kind of base layer modules to do things like have a vote to kick someone out of the order or if someone requests to join, make sure everyone approves it and things like that. And so we think that this current version is, like, a really expressive way of writing the module system. And so we have, like, a a couple of built in modules which are on the screen right now. So one of those is consent. And so that's something that any user, if they're writing a new module, can just call. And so it makes it super easy for users to quickly write a new module, to add a new process that functions through democratic means. But someone could just as easily create, say, like, a dictatorship module that routes all decision making to a single subword or user in that subword.
Great. Yeah. So, you know, as Luke's saying, it you know, it's been really a a a push toward toward doing less hard coding in the core of the software and putting more and more of the of the activity in the modules. And and, you know, over and over finding ourselves, like, oh, we are importing our assumptions, even our, like, you know, apparently radical assumptions into this design, and that's really actually limiting the expressivity of the tool. And so, you know, our our major rebuilds in the middle of a building were all around recognizing, oh, gosh, we are, you know, we're we're assuming something that we shouldn't be assuming. Oh, I think we had a a a runtime error. Yeah. We have a a bug here. Oh, gosh. It's in the it's in the it's in the utility functions. I'll start I'll start us up again. The server's running again, so folks wanna join in, but that's something we need to we need to know it and catch. So we're we're treating this as a, you know, as a bug hunting session as much as anything else, so thank you for bearing with us. So for those of you who are who are unable to join directly, I'm just gonna share share my screen in in mind test, and so you can see what's going on here. And I'll walk you through a few things, and then we'll we'll open up for, for more discussion. So let me see. I as I recall, it's a bit of a challenge to share, on Mind Test. Let me see if this works. I might do you do you all see it? Are you in my test or something? Oh, it's just showing my desktop? Okay. Yeah. Let me just let me I think I have to just do the share screen thing. Share, you know, share whatever is on my screen. Do you see it now?
Yeah. I do.
Okay. Great. So so, you know, we're in this world. This is a a world I've been building with my kid on weekends. It's got an Empire State Building. It's got a kind of sad our take on the Geisel Library in in San Diego. It's got an airport and a fire station, all sorts of things. And I'm sorry I didn't add a mod for changing the appearance from the assumption of whiteness that is built into this game. I meant to do that, but I forgot. I'm I'm sorry about that. So please forgive the the, you know, sad uniformity of this, you know, of of our of our user base here. But let me just introduce you to a little bit of of what the the mod looks like in action. So if I type in the command m p, then I get this dashboard. And this is the kind of entry point to what all that the mod does. As is this is all language imported from the modular politics paper. It may not be the best user experience language. You know, we've been focused on just kind of doing as literal and implementation as we can. But I see Luke might be underground in the subway system. The we've got orgs. So there's a root org that everybody is in. And then we have another org called City Hall that fewer people are in. So if I go to the root org, I can see all the members who are who are in the game. I can see child orgs. That means, you know, an org within that org, and City Hall is is one of those. And then I have this oh, I'm not getting modules coming up. That is a terrible glitch. And now we have a crash. Let me try again.
It might be a good idea to try and wipe in the old, multiple data through the fresh
Oh, yeah. I can do that. Okay. Yeah. I just, wiped that. Okay. Now our modules are there. Sorry about that. We will figure out what's going on there. So, the modules are kind of a list of all the things you can do. So modules present to the users as actions, and some modules are hidden. Like, for instance, that consent module is kind of a dependency for others, but it's not available because it doesn't do anything on its own. But so for instance, if I wanna create a child org with with consent here, then I have to then I say I wanna do this, and then maybe I wanna create, you know, club meta gov. And so this enables people to form groups. And then now you've got a pending action en route. Everybody who is in the game should be in the root org. They should see that there is a pending action for them. They should have gotten a notice in the corner that they have a pending action. They should go to their dashboard. So anybody who's in the game, Luke just decided yes. You see in the top left corner to he voted in the in the poll. I can do the same. And so I've I've nothing pending, but but we're still waiting on others to participate in that in that poll. So the the module, you know, is set up in such a way that it requires that that poll to go. I just saw I have a new pending action in root, so I can go check on that. And it's another child org, my most excellent child org. I'm gonna prove that. So right now, you know, we're kind of inhibited by the fact that everybody has to participate. We have to wait for all these people to to to jump in. If that's an inhibition, maybe it's a maybe it's a feature. I think we have some issues on the numbers of people that it's expecting, Luke. It's maybe not. Oh, we've got nine people in, so a lot of people are needed to approve these things. But some some modules, for instance, don't require, you know, that that kind of full consent of everybody. We've just set a lot of these on default to to require that. We've got, for instance, a module for a token system that enables you to create a token within your org and to send people tokens and to issue them. That's still pretty preliminary, but there's been a lot of interest in the mod in the Mind Test community and having a token system integrated with the, you know, the governance tools. Oh, somebody voted no on creating a most excellent child orgs. That's probably not going to work. You can also display a list of the processes that are currently running. You know, this needs some work in terms of making making the information a bit more usable, but it's the beginning of, you know, the kind of thing that we'll definitely need to do in terms of making the processes really visible to, to participants. I can send a message to orgs, all sorts of things. And and just, you know, one last thought. I like how everybody's jumping. You, you know, once we got some of the basics in place, you know, the the process of starting to write write these modules started to get that's when the fun really began. It from my perspective at least was, you know, when we had a kind of a a core set of functionality and you could you know, I would just start going through my day thinking, oh, you know, we should, you know, we should really have a module to do this and then, you know, spend thirty minutes writing it and then another thirty minutes debugging it. And then we had the that module. Oh, we have a fire truck on loose. Somebody died here too. That's that's very sad. Those are bones. There's also a train to a little snowy village over there, which is fun to ride. So, you know, and this was just a real pleasure after all the work we've been doing on on Mod Paul and then on kind of theorizing some of this to actually be at a point where you can start writing functionality and seeing it work. So so so it's a real joy and and just kind of gives me a sense of confidence and and excitement about, you know, all the different stuff we're doing in in MediGov and and the kinds of tools we're building. This is still very much, you know, a work in progress, but, you know, we hope it gives people a chance to, you know, experience online governance in a in a context that, you know, that you know, where where where it's not as familiar. Skyler, is there anything that you wanna add as well before we open it up more?
Yeah. Sure. So I'm kinda new to this project. I didn't really start working on it until, like, just about, like, two months ago. But from my perspective, I've been mostly focusing on documentation and then just, like, trying to, like, understand all the code. But I found that it's, like, surprisingly easy to develop modules. And I've gotten to the point where I'm, like, also starting to think about new modules to create. And I just, like, I just found this like, for someone like me who has, like, not really much background in, like, governance, I found that this was, like, a really interesting way to implement it. And I think it's really accessible for, like, just anybody to, like, participate in, and I think that's, like, one of the best parts about it.
Awesome. Thank you. And I'd love to ask if somebody could could just moderate the discussion because I'm having trouble, you know, because I had to share my full screen. It's a little tricky to follow the chat and and show the game. So could somebody step up to to moderate any any questions or comments? Yeah.
I can see if they can hear me in the chat.
Thanks. Does anybody wanna get us started?
I'll ask a question. So while you were working on this, you know, we've talked about some of the, I guess, technical pain points, but from a, like, a say, from a making like, making the modules or, you know, sort of policy standpoint, have you had occasion to create anything that just, like, did not work as intended? And and, I mean, technically, it worked as intended, but, like, the kinds of, you know, interactions or behaviors that elicited were, like, just not at all what you expected.
Luke, do
you have any any thoughts on that?
I'm trying to think of some examples. I know you definitely had some weird behavior, but I think you're asking more about, like would you say, like, social behaviors as we expected as opposed to the correct behavior or or both?
I mean, I was gonna say that you kinda saw it already. I suspect that, you quorum or a really high approval rate, then you can end up having things blocked just by people simply being kinda trolly. Like, there's no reason to say no except I mean, to see what would happen if you said no, and humans always do shit like that. So there's some sensitivity to parameters at the very least that needs to be considered. And I'm I'm just curious if there are other examples that you might have encountered.
Yeah. I think you're right. Today is a good example, and I think our our default form right now I think we need to have a 100% approval to to pass anything for the reorg. And that's one of the things we've been working on through modules is adding a system for essentially configuring modules to have different properties, different scenarios. So we could have set up the the reorg to have, like, a smaller quorum, and that's something you can configure for your individual org if you only wanna have, like say, for example, a process that proves instead of based on how we feel about yes as long as the certain people don't vote no or something like that. Nathan, do you have any examples?
Yeah. I mean, we haven't had the chance to do an enough social testing to see you know, to to you know, we've really been focused on the the on the technical designs more than the than the social designs. But, again, I think the on the on the technical side, the, you know, the the issue has just been, like, trying to discipline ourselves to hard code less and enable more flexibility so that people can, you know, address these these questions to, you know, within the within the tool rather than relying on on some kind of broader rewriting.
I'm a big fan of the fan.
Yeah. Sorry.
Go ahead.
Big fan of that, but I also have experience with people literally not being, able to set parameters in particular. So, like, one of the challenges that you run into is you wanna do that, then you need to also develop guidelines for how to make choices because people aren't gonna automatically understand. They're gonna do something that's possibly even worse. So you don't wanna, like, code or impose your assumptions on them. But if you give them nothing, you're actually doing an almost worse version of that because then you're gonna get often, like, sort of ill informed or borderline random values if you don't also equip them with sort of, hey. This is what this parameter means. This is the kind of thing that it might it affects. Therefore, here are some questions you should ask yourself when you pick this parameter. And I know you guys aren't far along, but from a, like, an algorithms, you know, policy design paradigm, like, if it especially in the web three space, but not exclusively in the web three space, we have encountered mountains of work to close the gap. When you make expressive software, you actually have to build a bunch of documentation. Otherwise, it'll get used even worse than how it would have been used if you, you know, prescribed values.
Yeah. That's a it's a great and I and I think that question of how to how to how to build documentation is is, you know, front of mind and and and how to make the tool as, you know, in some sense self documenting as possible. But, you know, right now, again, we've been you know, Skyler, for instance, has been leading the development of just developer documentation to enable people to figure out how to understand the system enough to be able to write modules. But I think I think building in that that configuration capacity, which is kind of the next priority, is, you know, is going to go a long way to enabling people to see more transparently. You know, here's here's how, you know, you design a, for instance, a consent process that actually makes sense for for your situation.
Okay. We have a question from Josh and Elaine, which are related. So just ask, is there any interaction between the org modules and the Mind Test game data or game state? You you can probably anticipate it, and I can. But I think that's the goal down the line to have, like, interaction with, for example, allocation of resources in game. Right now, we have I think the one integration with MindTap is using the form specs, so I think it's it's feasible, right, to use other functions in the game.
Yeah. It's a great question. So just to introduce you a little bit to the, you know, to the structure of the code. So, you know, this is the main directory, and there are kind of two main boxes where things live. Core, which is all the platform independent code, and then Modpal Minedest, which is the Minedest specific code, which, you know, for instance, if you were to develop this for Roblox, which also uses Lua or, you know, I just saw today that people can write plugins for Jitsi, the video conference software in Lua, then you would create, you know, ModPaul, Jitsi, or whatever. So if you so most of the modules are in this core directory, and these are all platform independent modules that use, you know, the standard functions available to to module developers. Mine tests override some of those functions that need to be specific. So for instance, you know, the for to create those dashboards and the interface elements, you know, those are overridden from the core. They're also implemented in core for command line. And there are also there's also the capacity for platform specific modules. So I've only done one so far, but that is is called Priv2Orgs. So, for instance, you know, the way that works is I can go into to root, and Mind Test has this concept of privileges or privs, and I can take a priv that I happen to have and share it with with members of an org I'm part of. So I'm gonna share a train operator with everybody that didn't require any consent. I've added that privilege to, you you know, share that privilege with everybody who's currently in org. They gotta sign that privilege. And that's, you know, something that exclusively happens in in Mind Test. You know, a crucial thing that, for instance, you know, I think we need to implement in this context is, like, you know, there are there's the ability to own, you know, a structure. Right? And in mind test where only people who have that Priv can can build or or change a structure. So if I wanted to create a a fire company for this firehouse, you know, I could create an org that does that, and then I could, you know, assign the rights to changing the firehouse only to those people. And this this is something that's very relevant to how people actually play mind test in multiplayer context. So so so building those those platform specific modules is, you know, is gonna be really important for making this thing, you know, this thing relevant. And, in these platform specific context, but it absolutely, you know, is is part of the part of the goal here and something we've just started experimenting with.
So there's a really question. What are the limits or are there any limits to what modules can do? So we can kind of anticipate that, yeah, essentially, there is a lot of, like, stuff that can be expanded based on, like, platform specific functions for those versions of multiple if you're implementing other platforms. There are some limitations of kind of our infrastructure right now. Like, currently, the pending actions are not saved on a server reboot. And there are some issues we're still working out with, like, persistent storage because that kind of varies in implementations. Like, my test is on solution or the command line could just see the file. But in general, I'd say that it's, like, it's pretty open in terms of what you can do with it, and there's a lot you can add on. Okay. So we have we have a bunch of questions now. So how dynamic is the process of adding modules, changing the rules of the governance game, server reboot, which loads new load files? I believe that is how it works now. Right? To add new modules, you have to go to one of the files and and reset.
Yeah. You have to you have to reset the server. And, actually, to to change the module set, you have to really reset the whole system. So, actually, I could do that now. I have there's a, you know, a command m p test, which is, you know, really just meant for testing purposes, probably be removed ultimately. But it kind of refreshes all the modules because it load well, you know, just the way the way it loads modules to orgs requires a refresh. But once you have, like, an extensive set of modules that you like in your file system, you can start choosing your your set of modules within the GUI. So so I can go to root, and I can go to change modules. And this is a module itself that gives you a list of all the available modules, and I can uncheck the ones that I don't want to include. It just includes everything by default. And then and then it, you know, can send out a consent or something to and you can do that at the level of any org. So so this is how you'd craft the governance of a particular org. You know, for instance, the way that you could create a kind of benevolent dictator structure is create a sub org that is the benevolentdictator org, have one person in it, assign a certain set of modules, remove all the powers from the other from the other org. There's also the ability this is all done through modules to defer defer decisions to another org. And so you could adopt only deferred decisions, have all the modules deferred to the benevolent dictator. And so they whoever's in that org ultimately decides on all the decisions in the in the parent org. So so by just having that choice of which which modules you you have, you can configure, you know, the behavior of of certain orgs, you know, pretty pretty extensively. You know, it's still right now at a point without the configuration capacity that you, you know, you just have to rely on what is hard coded into particular orgs. But, you know, but still, you you can make some choices there.
Just following up on that. It you said if you wanna change the module sets, like, would that be to add a new checkbox in that list of things that could be checked or unpacked?
So so right now, that that list includes everything that is available in the file system. So it that list is everything you have. And so, you know, so so if I if I change modules, right, you know, they're all checked by default. But what I could do, for instance, is before the game, I could go in here, you know, before other people join on my own and uncheck all the ones I don't want anybody to have access to. And then by the time everybody joins, they are, you know, subject to the rules that I set up, and and they can't recheck anything without, like, you know, at this point, it's set up as a consent thing. So they would have to pass a consent proposal to to change things in in the root org. They could also, at this point, create a sub org that could add those modules on. So, you know, a a server administrator can can both change the set of available modules by swapping out what is in the, you know, in the file system, or they can leave, you know, a more extent extensive set, but they can craft what is in the root org that they are you know, that all the users are in.
Cool. Thanks. Yeah. I'm kind of curious. Like, I think this comes from, like, a backdrop of like, in distributed context, it's can be really hard to do the equivalent of rebooting the server and, like, reloading the code. So there's interesting, I think, dynamics around, like, what's static and fixed and requires everyone to, like, update all at once and get the new version versus what's, like, happens at runtime. But thanks.
It it would be it would be pretty easy to to do that update at runtime. You know, it's it's just it it would just be a matter matter of adding a line of code. So I I don't think that's we we've just been, you know, building and testing it on in the context where we're restarting the server every five minutes. And so it hasn't arisen as a pain point, but I think you're absolutely right that it it would arise in any kind of context where people are trying to run something that doesn't get shut down.
Cool. Thanks.
Alright. I have another question from the chat. It seems like documentation we need to inform users not only on the technical details of the software, but also how to design effective institutions that have the qualities users desire. It's making it difficult because the goal of modples to get users the ability to experiment with few governmental forms. Have you given any thought on how to allow documentation or the community to share knowledge learnings about how to design effective institution?
Luke, do you have any thoughts?
Yeah. I guess it's something that we haven't thought a ton about yet, but I I definitely see the the benefit of that because, like, beyond just the technical aspects of learning how to set up an org and how to configure it properly, There's definitely a lot of questions on, like, what governance form is the best. Obviously, it's a much bigger, more complicated question, but that would be really cool to see people kind of share their own opinions about what works for them. And I thought we had it early on was, like, sort of allowing users to template orgs. So that would be one way of kind of, like, sharing that information is if you set up an org that works really well, maybe like a representative democracy or something, Users would be able to kind of freeze all those properties and then let another user kind of pull a network. And then they would be able to kinda play around with that and see, you know, what governance works for them.
Yeah. Absolutely. And, Skyler, any thoughts there on documentation?
I'm sorry. Aponva
specifically? Oh, no. It's okay. Just on, like, documenting, not just, like, the technical side, but, you know, how to use, you know, helping people helping to guide people through building better little institutions here.
Yeah. That was, like, one of the first things I was working on originally, just basically on how to, like what's, like, for both, like, developers, it's just, like, how to implement it. Because, like, for me, I have, like, a pretty big experience in gaming. I just grew up with it, and, like, I also play esports for CU. And so I think, like, that part of documentation is really important, and I've been, like, trying to I've been focusing a lot more right now on the developer side, like, every time we code. But I definitely wanna, like we're also trying to, like, create some documentation just for, like, general users and make it more accessible for everyone to use.
Yeah. Absolutely. And and I really think of this as, you know, as something that I hope will be a laboratory where we see patterns and practices emerge. I don't think we know what the right way to do it is. You know, to me, a major kind of research question that that this tool introduces, right, is, you know, is kind of relates to to Seth's work on on on Minecraft where he saw, you know, very kind of fire hierarchical patterns emerge in in a lot of the servers that that he was studying and, you know, raises the question of whether people would behave differently if they have a different set of options. Right? If, you know, some form of consent, maybe one a little less onerous than the one we we have hard coded right now, we're just more of a norm, and we're more available.
I would comment that there's empirical evidence that if you provide different tools, you get different social structures just from, like, studying the source cred community even though they're we've been doing some of our, participatory ethnography work in in that community. And, like, they have very different set of tools they use to organize themselves, and they organize themselves very differently. And not that that's, you know, so a single sample size, but just, like, understanding that there's evidence that you give people different stuff to organize themselves, and they will use those tools, and it will often result in them organizing themselves differently.
Great. Yeah. I see Jenny's hand up. Is is Luke's sorry. I don't wanna usurp.
I I think it'd be really interesting to see how the org dashboard, for example, can be designed to kind of inherently communicate the features of modular governance. I feel like what's interesting about using Minecraft is that you're building this physical world, but when you're designing governance, you're also building, like, societal constructions. And so I feel like there's a way to visualize maybe what the root org looks like as a governance structure, some sort of, like, visualization of, like, the distribution of numbers and the privileges that people have. And you can also see within that, like, what the child orgs have or what they're afforded and what they're not. So I feel like part of me is kind of interested in how, like, you can build this physical space, but then maybe there's, like, another screen or part of the interface where you can also see the governance creation that you're building, and maybe that looks different. So I just I think that's a really interesting opportunity.
Absolutely. Absolutely. And I I I mean, you're absolutely right that the the logic of crafting really should be, you know, the logic of the dashboard rather than these, like, very text based drop downs. And, you know, that just for me comes down to, like, it took me long enough to figure out how to get these dash these drop downs working. The the the kind of tool set around what these GUIs, which are called form specs, is so weird and it but someday, I would love to, you know, bring that kind of logic of crafting where you're seeing objects and you're seeing their relationships to in different, you know, to to to have people experience the governance piece. Yeah. Thank you for that.
Yeah. That's a really good point. And I think something just as simple as showing, like, a diagram of the nested order to be really useful in helping to illustrate kind of, like, how different orders kinda govern themselves.
Do more questions. Like, one more comment or or something?
Yeah. Oh, maybe it's for me. Alright. I'll take one more. So Eric asked, have you thought about when the sales process for decisions would look like? Eric, do you mind explaining that a little bit more?
Yeah. Sorry. I was actually exploring in game. The danger of giving me a game world to play in during a video call is is is why I prefer to teach in person because I would have been one of those students who was gaming alongside the lecture. I mean, imagine a world where the denial of my proposed group is just an insufferable injustice. Can we do anything about it? I noted in the follow-up, one option is don't have a top down heavy cumbersome complex appeals process like that under which our judiciary labors and just say you get to revote after you've, you know, lobbied community members or dissatisfaction with the voting outcome. That's lean. It does set up the possibility, though, of, like, what's to prevent proposal spamming when I get angry enough that my most excellent child org was denied? And so every time you guys log on, you have to redeny my proposal for the most excellent child org until finally you're like, I'm done. I'm done declining this. Just just to put this to bed, I'm gonna say yes on the most excellent child org. And so there are trade offs here, but I also think there are certain decisions that, at least in most social communities, tend to have an appeals process that there's, like, some type of stop gap or ex post community review. I was just questioning whether you all have thought through the need for that at all or just going with the lean route.
Yeah. We haven't developed anything around an appeals process. But as you're describing it, I'm I'm already thinking of, like, okay. You know, maybe you have a a dependency module that, you know, it becomes a container that anything else you might that you might wanna run any other module through, and it has to pass that appeals process before it can before it can proceed. So I can definitely see how this architecture could enable that kind of thing. We also have, you know, I've played around with building a kind of jury module that randomly selects, you know, you know, I know this isn't exactly what you're talking about, but but, you know, if you wanted to replicate a kind of conventional court structure, you know, we, you know, we have the basis of a of a jury kind of utility module that would that you could use in that in that picture. But, you know, at this point right now, you know, users can just, you know, put in there, you know, if they don't like how something goes, they can just raise another, proposal.
Completely agree. And and, actually, the jury might be very relevant to what I was describing in the sense that if an appeals process is subject to exactly the same decision rule and pool member composition that's exerting that decision rule, it risks delegitimizing it because the person's gonna be like, why would I appeal? You guys all just voted me down. You're gonna vote me down in the next one. This is nonsense. This isn't a legitimate appeal process. And so there's actually good structural reasons for at least being like, look. Yeah. You get to appeal to a random set of members because of the unfortunate veto that was exerted on your best named ever most excellent child org.
Awesome. It's a really quick question, but, Alex, did you wanna quickly respond to that? Sorry. Sorry.
Yeah. I was just thinking in Eric's okay. I actually know a guy who would put himself up for a statewide election every cycle. It's like not a cycle would go by. He wouldn't let you throw himself up there. Kinda like Eric spamming people with this. Yeah. Thank you. And I thought, well, I'll just try to mod that anything Eric proposes is I auto vote down, and I'll make it available to everybody. It'll make a little cabal of people who are sick of Eric's shit, and we'll all just join the the the no to Eric club. And we'll run this model all the time, and you can, like, turn it off. But it'll just be, like, an auto an auto no to anything Eric says and kind of a social thing. Right? It it but I really like what you're saying earlier about the importance of legitimacy. It's like the the outcome of governance is is it's like 40% decisions and 60% legitimacy. That's that's been my sense. And if you're if you're not aren't defending legitimacy, then no amount of decisions is gonna help you.
Yeah. Absolutely. And, you know, I just, you know, can't wait to develop this to the point where gamers are are using it and hacking it and breaking it and, you know, and doing all sorts of like non liberal things that that that help us see kind of possibilities. But thank you all so much for helping us get that started. This is the largest group of people who've been in this ever. And so we're really grateful for the chance to to road test it and break break it in the process. Thank you all so much.
Maybe you can, like, introduce this discussion in the Slack afterwards. We can save each other, like, questions that you can answer.