Ashton Metagov
Speaker 1: Been developing the kind of, like, the Medigob tool. The quick introduction to that tool for
Top Keywords
- governance 0.013
- plug 0.009
- driver 0.008
- medigov 0.007
- different 0.007
- tools 0.007
- policykit 0.006
- plugins 0.005
- different tools 0.005
- hackathon 0.005
- sourcecred 0.005
- cred 0.005
Transcript
Been developing the kind of, like, the Medigob tool. The quick introduction to that tool for
Oh, oh, should we start recording first?
Oh, actually, yeah. Why don't we?
Ready to record it.
Okay. So yeah. So this is a kind of a very brief introduction to to Miriam and the project she's presenting. I'll I'll let her go over more the project, but the background you can find at medigo.org including these kind of the proposed protocol. There's a kind of slide deck around that, on the website. But Mary, who is our research engineer, will be presenting on some of the current work she'll be doing. And once again, this is more, I think, an occasion to invite feedback. And that's kind of initiate a conversation around, like, what are the objectives of this tool and how can we sort of, like, how are we making give you some insight in how the kind of architectural decisions we're making and why we're making them. And hopefully get some feedback online, how we can improve it. So thanks, everyone, and thank you to Mary.
Thanks, Josh. Yeah. I'm really excited to get feedback and have a lot of discussion. I did make slides, which I apparently didn't need to do, but don't take that to mean that, like, what's on the slides is is, like, declared truth. It's definitely very much in the works. But I will see if I can share my screen. Yes. So I'm assuming, like, not most a lot of people here probably aren't familiar with what the MediGov prototype is. So just going over sort of the problem statement of why I think we're building this. And I joined this project in January, so I'm, like, still relatively new to this as well, and then go over a little bit of the design overview of what I'm building and walk through an example. I don't think that should take more than fifteen minutes, all of this, and then we can have plenty of time to talk. But we can also like, if people have questions, during this, I don't know if I'd be happy to, like, have discussion broken up. If, Josh, you can, like, moderate that from the chat if you want. So my understanding of the problem statement is that a single community online uses lots of different tools, but they can't necessarily govern themselves as a community across all of those tools. So this is the one of the diagrams that Josh made for GovBase showing that across a single organization or what I'm calling a community, they use many different tools. So I think a good example for today is SourceCred, the organization. So the group of people that develop SourceCred use Discourse for discussion, as well as Discourse. They use GitHub to develop, and they, of course, use SourceCred to track value. So this is just, like, showing that. And another good example is, vTaiwan, which I'm not sure where. I think Nathan shared this in Slack a while back. This is a participatory governance project, but a way more complex example showing that there's not just like a community using multiple tools, but there's an actual workflow and governance decisions and deliberation happening that's flowing across many different tools. So part of the goal of MediGov is to facilitate communication between these different tools so that a workflow and governance can be defined that cuts across or you can govern all of these tools together, which we can do for a much simpler example than the last one. And I'll use this for walking through an example, but this is an example of a workflow ish. I don't know if this is a real workflow, but if this is an open source dev community, they might make discussions, and decisions about what features they wanna create on discourse. That value of, like, people contributing to the discussion is tracked in source cred, which is a a value tracking, like, reputation system almost. And then once they decide what to build, GitHub is the tool that's used to perform the work, and that work is also tracked using SourceCred. And then maybe they use Open Collective to get paid for their work. And Open Collective is a kind of it's a system for tracking, like, collecting donations slash invoices and community discussion. I don't know. It's kinda new to me too, but that's one of the integrations we're using. Any questions so far? Sorry if this is like super base level that everyone already knows. I'm not sure.
I'll just mention that the discourse workflow is very much a real workflow because that's literally how, like, one of the blockchains we're working with does it. You have the discussions in this course, and then it's submitted through a technical system and then sort of sent out to payment all across different platforms.
Cool.
Yeah. So this is from Josh from the docs. So meta gov right now is, a unified API gateway for digital governance services. It's designed to support rapid prototyping of governance systems, decision making processes, and social workflows across platforms. So it's basically a back end service that's just making it easier to access all these different tools that we think are commonly used for governance. So it's written in Django, and it has a plugin architecture. So these listed here are the current plug ins that are supported. The goal is the reason for making it pluggable like this is that, if I, like, I added a plug in for source cred because that's what my community uses, and then now anyone else who uses Medigap can also use that plug in that I created. So there's, like, a goal of having some kind of ecosystem of Medigap plug ins. These are the ones that exist right now. And the plug in authors I'll get more into this, but they're basically just, like, writing an implementation of the API endpoints of this back end service. So there's three main kinds of endpoints. And asynchronous governance process slash decision making process is probably, like, the most interesting one to this group. That's, like, where you are implementing, let's say, like, for Lumio, which is a voting platform, the governance process is just a vote. So it's asynchronous, meaning it can happen over, like, a long period of time, and it usually requires, like, human input. And then an action being, like well, actually, maybe I have examples on the next slide. No. I don't. Like, performing an action on discourse or an action on, like, on the blockchain through NEAR, and then resource being, like, getting some kind of document or data from an external system. System. So being that this prototype is just, like, a back end service with APIs, that's not really useful on its own. I think the question maybe now is, like, okay. What's using that service? How are we actually governing things with it? It's just providing access to these tools. So right now, I'm focusing on PolicyKit as using MediGov. So I think some folks are familiar with PolicyKit from Amy's talk a while back. But it's basically a governance, like, policy authoring tools tool that lets you create policies like govern like, governing what actions people can take on different platforms. So it supports Slack and Reddit and Discord. And I'm thinking of MediGov as providing an easy way for this, what I'm calling a governance driver, which right now is just PolicyKit, providing an easy way for PolicyKit to leverage all these existing tools.
So think of the
MediGov service as, like, So now that PolicyKit is using Medigob, it can access all these different tools because all these plug in authors, which are all me right now, wrote plug ins for all these different tools. So now in PolicyKit, you could say, like, when an invoice is submitted on Open Collective, check if they or start a vote on Lumio about whether it should go through or not. So that's an example of the governance cutting across tools, but that policy itself is defined in PolicyKit. And I'll show some screenshots of what that looks like. Yeah. I mentioned this. Yeah. Having a goal of reusable plugins. Right now, the plugins are, like, Python and Django specific. But the eventual goal, my understanding is to, like, see if a kind of governance spec emerges from this so that the platforms themselves can implement it. So, for example, like, there's some meta gov spec for what a decision making process is, and Loomio itself goes and, like, supports an API that is conforms to the meta governance spec. But that's kind of an aside, so I don't know why this slide's, like, out of order.
So
I mentioned these are some just examples of each of the kinds of processes or aspects of the plug ins that I mentioned. Participatory budgeting is another one. We have Vincent on the call, I think, who's our resident expert, but we don't have a plug in for that yet. Platform actions. I just started the near contract call one, which lets you, like, make a call to a blockchain. And then web web monetization and rev share is another one we're working on of, like, governing, a web monetization revenue share configuration, which says, like, you know, 25% of the time send, payments to this user versus this user versus this user and having a way to govern, that configuration. Yeah. And this one I haven't talked about yet. This is, another aspect of, governance policies is having them be, like, automatically executed when something happens. Right? So as a plug in author, when I'm implementing the plug in for Open Collective, for example, and I wanna support a policy that says, like, when an invoice is submitted, do this, then I have to implement this listener interface. And right now, this is all using webhooks. So the Medigov service is exposing an endpoint or several webhook endpoints for each plug in to receive events from external platforms. So this is like all of this is pretty limited by, like, what these platforms provide. So Open Collective and Discourse both happen to have webhooks built into their system. So you can register a webhook and get notified when invoices happen or when anything happens on Discourse. So that lets these plugins, like, hook into that so that we can execute governance policies when things happen. And maybe with NEAR, but I'm not sure yet about that. But that's, I guess, yeah, a listener service. So,
yeah, I'll
leave it at that. We can look at an example if that this might help clarify a bit.
So
this is what the policy kit authoring tool looks like, the policy authoring tool. So this is saying, govern or, like, only users with a certain amount of source cred cred are allowed to comment on a specific topic. So, it's getting the driver is receiving an event from Medigov, like, sort of receiving a push notification that this post was created, and it's able to then use Medigov again to look up the cred value for that user who made the post. And this here is I'm showing, like, it's just making some API requests to Medigov to get that value, and that's being like, that's just a request that's being routed to the plug in. And then it's able to this is, like, the concept of governing and action is just, like, the action happens. If I decide it's not allowed, I revert it. So I delete the post. So that's what's happening here. If they don't have enough cred, then perform this delete post action, which again is something defined by the plug in author as an action, and then create another post, like, telling you telling you that you deleted it and why. That's an example of that. That's kind of all I had, and I have some links for I mean, we can jump into, like, any questions we have right now, and I also put some just comments on, like, my own questions and concerns right now. Like, one is, like, a huge thing that we have left out so far in implementation is identity linking across platforms. So the example I just showed only worked because SourceCred and Discourse already have, like, a shared username. The SourceCred SourceCred already plugs directly into Discourse, so it's able to, like, speak the same like, has the same usernames. But we don't have anything yet for, like, I you know, account linking from a user on Loomio versus a user on Open Collective. So that's, like, kind of deferred for now. And then, like, whether or not this will be useful beyond PolicyKit. Yeah. So that's that's that's all. Do we have any questions in the chat yet?
Awesome. Thanks, Mary. Mhmm. Well, Seth has a kind of questions to start us out with. It is it jumps straight to the heart of the issue, I suppose. Seth, do you wanna kinda say out loud?
Sure. Sure. I mean, having attended so many of our meetings, I'm sort of embarrassed and feel awful that I didn't ask this sooner. But so, yeah, I mean, the premise of of of of all this, of MediGov, has been, oh, there's this giant mess of tools and communities use, like, six different ones. Loomio for this, discourse for that, and Slack for that. And and how do we get unified? And I guess my question is, are we are we saying that that's inelegant and we can make it more elegant or, like, efficient or something? Or are we saying that's a problem that we're able to solve? I think the second is stronger, but I'm having trouble articulating myself, like, how that's a problem.
How the fact that there's all these different tools that can't speak to each other is a problem.
That's right. Yeah.
Yeah. I think it's not it may not be that much of a problem, but, like, in the example, I guess, I'm thinking policy kit right now. Like, you you could do these things without Medigov, I think. You would just, like, have to one is just, like, learning all the different APIs of all the different tools. So, like, Open Collective uses GraphQL, and Discourse uses a JSON REST API. And, like, all the all of them are sort of set up differently. So, like, if you wanna write a policy get policy that's, like, interacting with all these different tools, you have to, like, learn all the different tools, and, like, make requests directly to them. But that's more of just, like, a slight inconvenience. I think I but I think that the value is partly in, like, unifying the interface to them. But after that, like I mentioned with, like, if a spec emerges is, like, ideally, there's well, I don't know. Josh, correct me if this is ideally. But my understanding is, like, the fact that those tools themselves, those services that can be governed or are governance tools could, like, implement a common interface themselves, and then, like, this tool wouldn't have to exist. I don't know if I agree with what I just said, but that's sort of how I'm feeling right now.
Shanna, are you making a stronger claim, or are you making the same kind of claim as Miriam on this on the chat?
Is there a way for me to see the chat?
Shauna, I'd
You're you can hear me. But I don't think we can hear you.
Well, to say what I think Shana is saying
Wait.
Oh, you're here.
You now.
Okay. I don't know why I had my headphones plugged in, and apparently that was causing problems with my microphone. Anyway, yeah, I was just trying to say that in addition to there being value in increasing governance capacities across services, a second thing that Medigov can enable is additional governance tools even on a single service that doesn't have them. So for instance, the ability to govern things on Slack, especially, you know, platforms that use this sort of implicit feudalism model to use a phrase that I got from, that modular politics paper. Yeah. So I think that, you know, even if you're just using one platform, it you're opening up a whole new realm of governance options options within limitations because there definitely are technical challenges in, you know, attempting to provide a governance layer that the internal platform doesn't provide. But I think that's really valuable. And I would also add that I've had a number of discussions with communities that are trying to have better governance across these platforms, and they tend to be technical communities who are, like, able to do things like, okay. Well, we created, like, a GitHub bot to do all this extra stuff that GitHub doesn't do. But, a, just because a person spent, you know, weeks and weeks of their time writing a bot doesn't mean they would prefer to do that as opposed to just using a preexisting tool. And, also, there's a number of communities out there that run into governance issues, and then they don't have the programming skill to try and create a clutch around it. So I think also the one of the values of this is that it increases the ability to govern, for people who don't have the ability to, like, write bots and things to try and get around some of the platform limitations.
I'm glad that was all recorded. It sounds like as as we're plugging in with the government in the future, that's a really great statement of what the software contributes. Thanks a lot. And and your points as well, Miriam, I think also touch a little bit in the direction of it's not it's not necessarily about solving past problems. It's also about expanding what we can do.
I think yeah. Well, just one more thing I'd add is that I'm kind of presenting these plug ins as in, like, being one to one with some external external service, which isn't necessarily true. It's not just like like, you could have a plug in that uses multiple services or, like, plug ins that use other plug ins or that use no plug ins at all. I mean, use no external services at all. Like, I have some plug in I implement that's just, like, random does, like, a stochastic vote, like, random number. But there could be yeah. They're not it's not necessarily one to one like that.
I'll just mention, to kind of supplement the discussion here, which is really fabulous. That so Medigov kind of well, I've arranged it in lots of places. But certainly one sort of, like, set piece in in the development was modular politics, which is, like, very much like a research project, right, with certain research hypotheses. And what we're trying to implement here, right now, is implemented. So to kind of directly answer your question about, like, is this an inconvenience? Yeah. I would think of it, like, there's nothing you couldn't necessarily do if you had all the technical abilities and capacity with Medica that you couldn't do without it. But it's about lowering that sort of, like, that threshold of making it easier so that more compute more communities can sort of access some of its current tools that already exist. Right? At least that's the kind of core hypothesis. The way that links to model modular politics is by idea that, well, there's this natural modularization that's already happening in the sense that people are using different governance services and different things are different pieces of, like, a governance decision making process are happening on different platforms. And it would look nicer in some sense if those were integrated, right, were properly documented. And that's is also one of the sort of questions driving, I think, some of the or one of the I I guess I would call that more of, like, a research question. Like, to what degree can we approve that? And that's not so much related to the current kind of user or product hypothesis for Medigov, which is much more developer oriented. So we have a lot of things in the chat. I think next we have. Oh, okay. We have some issues with, with policy kit, the website.
Oh, you're looking, Josh. I gotta say verbally. This is so beautiful. I am just blown away with how gorgeous this all is. Amy, Miriam, all you guys. Just wow.
Well, this is definitely very much a work in progress, and there will be good documentation that, you know, we will I think it's good already. But even better documentation that will release relatively soon so people can start playing around with the, like, actually finding some plugins if you're, you know, developer and working some of these tools. I have a long paragraph by Alex. Alex, do you wanna chime in?
I was just wondering what like, you mentioned high level architecture, and there is driver and particular driver implementation based on policy kit. So did I understood it right that basically to adopt this type of, let's say, implementation of the governance system, you would buy into adopting policy kit first. And if not, what are the other possible options and, you know, how that kind of entry point looks like for external communities to start looking into this space.
Yeah. That's a great question. So one of the is my mic on? Yes. Okay. Let me go back to this. So what we tried to do is not make Medigov super specific to PolicyKit. That's how this concept of a driver emerged where PolicyKit is the first example of a governance driver, but there could be others. And PolicyKit, like I think Amy wrote in Slack, is the most feature rich example of a governance driver you could possibly have because it exposes this
like, very
complex policy authoring tool. It has a concept of, like, bundling policies together and is, like, very complicated. But I think on the on, like, the opposite side of it, the driver could be anything as simple as, like, a, like, a Rust script that just, creates a community in meta gov and activates some plugins and then can now call those endpoints. So I didn't really go over that flow. But the way that a community is created is through an API request to meta gov that says this is the unique community name, and these are the plugins. So you activate source cred and give it the source cred URL. And right now, it's like you just send it. Like, when you activate the Lumio plug in, you pass it the Lumio API key for your community. And then you can just, like, go ahead and use it. But big caveat is that, right now, the way it's set up is that meta gov and the driver have to be deployed on the same server and sort of accessing each other through local traffic because meta gov doesn't have its own auth capabilities right now. So it just is like the endpoints all those endpoints for, like, performing an action, like, that's obviously very, like, sensitive. If you the wrong person could access that, you could just, like, suspend all your Discord users or something. So that is all restricted to local traffic and can only be accessed by the driver. But the driver could be just like a simple single community script, or it could be like a platform itself. But does that kind of answer? Or, like, what do you think about that?
No. I think it does. So I understood that it's an abstraction and kind of level of it. And most probably, it will evolve as soon as there are more implementations and more deployment scenarios beyond this kind of single single platform and local traffic thing. So it makes a lot of sense at this stage of project. I I totally understand. It's a really cool thing.
I think what I'm envisioning right now, I guess, is I haven't dockerized it yet, but that there's some Docker container of the Medigap servers that you can just, like, pull down and set up.
Next question we have. Amy has enough on a question we values.
Amy number two. Yeah. I've been Amy three in some context, but I'm happy to be Amy two.
You're currently Amy number one, Amy.
Oh, is the other Amy gone? Okay. Only only because only because they're gone. Okay. So thank you for it was very interesting. I'm new to sort of learning about this project and also PolicyKit, and I'm definitely intrigued by this idea of, like, modular governments bits that can be sort of chosen and reconfigured in on all that stuff. I was curious to learn more about how some sort of larger I guess, larger questions about, like, how let me think. How like, what are there any sort of assumption is there any assumption about values in the sort of choice of modules and also, like, who could use them and for what? So I guess that's two questions. It's like both of the what modules even exist, but also the second question is I'm thinking of I think a lot of you know Casey Fiesler, and she has this exercise she's talked about called, like, the black mirror exercise she does with, I think, computer science students where it's like, how could this tool, whatever the tool is, be misused for, like, really bad, harmful ends. And so I'm curious if that's something that this project and or policy kit has thought about of, like, how could this go really, really wrong in, like, a spectacular black mirror way? And is there anything stopping that, or is that kind of, like, beyond the scope? So I guess the second question is probably more answerable, but I'm curious about about both. Thanks.
Yeah. I can
Go ahead.
I mean, I can start. I guess we've had a lot of discussions about this. Or we've had some that Shawna in Slack is calling it the expressiveness debate, which I think in the modular politics paper, one of the key things is that the governance layer should be very, very expressive. It should be able to express any kind of governance. And it's like, I don't think we've landed on what that really means even. But I mean, I I think other people jump in, but, like, my feeling understanding of this right now is, like, the the MediGov service itself is so, like should be so lightweight that it's really just all it is is this core plugin manager that's serving up whatever is defined in the plugins. So I haven't thought about the question of gating who can create plugins or what is in those plugins. But right now, they're all just in a GitHub repo. But the driver or the policy evaluation tool is more high level. And that makes a lot more decisions about what governance is happening. So, yeah. I think that question maybe applies more to, like, that higher level of policy kit than it does to the lower level. But I could see that being upward weight too.
Yeah. I think, that's a really good way of look at separating, you know, it's not what that we're trying to evade responsibility, but there's like only so much, like, leeway we have as we're trying to define, like, you know, like, define these, like, back end services in order to support plug in that other people are writing. I would say, like, the, like, the nightmare scenario I could possibly imagine is that there's some, like, particular combination of plug ins, you know, because, like, kind of the idea here is that, you know, we give people a way to sort of, or of any kind of, like, computational infrastructure for governance is that, you know, it's relatively easy to kinda document and then export. Right? So people kinda copy this regime and sort of export it from this regime, from this community to another community, and Medigob is very much defined, or supposed to sort of help with that kind of transition or that import export. But if we do that, you know, you could imagine, like, maybe there's some version of a totalitarian regime, you know, on, like, communities that is suddenly effective for certain things. And then suddenly, you know, that just gets exported everywhere. It's sort of like, you know, Facebook is all, you know, it's about connecting people and, like, you know, posting, like, cute dog photos, but suddenly, like, it's makes it much much easier to spread, you know, all sorts of bad things. Yeah. I'm not sure how exactly we would deal with that. Like, that's that is I suppose it's quite literally meta governments. I think Shauna has a quick chime in on the on the value Yeah.
I was gonna say, I do agree with Miriam that a lot of this design pushes some of those fundamental values decisions onto the driver, and the driver just has to make some of those decisions in order for governance to work at all. Like, there's no completely neutral option.
I
will say also that there's an ongoing question about, how you actually instant instantiate expressiveness in the driver. So even the sorry. In the driver. In Medigov. So even Medigob itself in terms of by deciding what kinds of things can be manipulated and how is making governance decisions. So other topics we've talked about are trying to build in better auditing and monitoring capacity capacities into meta gov itself or requiring that the driver create them. And you can see that as being encouraging expressiveness because it's creating this whole additional language to do this vital work of exposing questions and actions around monitoring and auditing. Or you could see it as being restricting and expressiveness because if you're requiring drivers slash community to do this, then you're taking away their ability to opt out of doing it. So I think it's we call it the expressiveness debate, or at least I call it the expressiveness in my debate debate in my head. But it's not just, like, pro or cons. It's also about thinking about different ways of expressing things, and there's value decisions that goes into that. And this is, like, very much an open question that happens in our, you know, weekly calls. So folks are interested in being part of that discussion. Even if you're like, I don't understand or wanna talk about, like, you know you know, what Django endpoints we're gonna use or whatever. Like, having more input on the this question of, like, the core values around this very high level design, I think, would be really helpful for us. So I would wanna invite everyone to who has interest in that to participate.
Yeah. Absolutely. Please let us know or just hack pop into the Slack hashtag meta gov dash prototype. The next we have Harold with a question on smart contracts.
And thank you kindly everybody. Everyone working on this prototype. Learned a lot. It's learning a lot every day. You guys put in all this work. And I had to quit. I was very excited to see that you guys are already thinking about a smart contract. And, obviously, we can get funky with Expressions there too. Right? And that's exciting in a lot of ways. Particularly, I've been thinking about, you know, the the data platform and the intrinsic value motivation tracking that they have there and how smart contracts can come the fray there and be connected to, you know, prototypes like this, you know, with the beautiful work that you guys are doing. And, yeah, I just I wanted to get an idea of of what you guys were thinking about in connecting contracts, blockers, or just interesting things that came up so far. Thank you, Connor.
Yeah. Yeah. I right now, the way that I'm thinking about smart contracts as as them basically being another platform. And I don't know if this is gonna make sense, but this is where I'm at right now. The smart contract is basically a platform. Things happen on it that you and it can notify it can send requests through this, like, Oracle concept, which is, like, still new to me. So it can send events to the driver, which is that, like, listener interface, and you can also perform actions. So you could write a policy. Like, what I've implemented so far is just that you can have a contract, like one specific contract for your community, and you can make view calls, if that means anything to you for Near, to view state of the contract. And NEAR provides a JS SDK and a Python SDK. So I'm using their Python APIs right now. So all all that I'm doing right now is there's an endpoint in MediGov for making a contract call, which could then be done could be called from a policy get policy or from a driver or whatever. But there's definitely, like, a lot of issues there that I don't even really know, like, how to verbalize them yet. But I'll probably have, like, a better answer to that next week because that's what I'm working on this week.
Yeah. I'll just mention that the two kind of use cases are coming up that kind of we'll be exploring with MagaV. One is a hackathon co sponsored by NEAR, which is a kind of layer two blockchain around designing different governance experiments mostly revolving around Blockchain slash, like, web three principles. I'm sorry. Mostly around, like, sort of, like, involving sort of, like, different features of near interacting, like, with, like, specific governance problems that that Blockchain is encountering in different sort of, like, aspects of its operations. But also generalizing to just like, are there different interesting kind of experiments that we can run with smart contracts or different web three technologies involving, some what we would call like web two technologies like this course. I think the things that we're kind of primarily integrating with. So there'll be an opportunity to explore different use cases around smart contracts, as part of that hackathon, which, I'll reserve a tiny little bit of time at the end of discussion to sort of talk a little bit more about. And well, I think we're still kind of exploring exactly how the data use case is going to interoperate. We know there's gonna be some sort of, like, cryptocurrency, like, token,
and
that there are will be smart contracts and NFTs involved. But most of data's kind of governance happens off chain and kind of like, I think that's how they want it. So it's kind of unclear where we would actually be interacting with any kind of smart contract with the structure in that use case. But I think most people in, like, Blockchain world don't necessarily also, like, have a truly well defined use case for on chain governance besides, like, just wallet management. So this is something that I think we're all the entire ecosystem is trying to explore together. I think next we have, John.
Yeah. So that was a lucid presentation. It made me realize that my scrutiny of the Medigob web page has not shown me where one actually gets to, for example, integrate Lumio plus Open Collective plus Discourse or anything else. It sounds like there are actually some usable tools and I haven't found them. What am I missing?
Yeah. They're they're secret right now. No. They're not. They're at docs.medagov.org, which is still pretty new, as in it was created on Monday or maybe Friday.
Well, I see.
Put that in the chat. But that's still, like, probably not as illuminating as it should be, but I'm gonna work on, like, making, those a little bit clearer for newcomers to understand. But that's the documentation we have right now. I I can share the other links in here of, like, the GitHub repo.
Yeah. Well, cool. And so is there sorry if these are naive questions, but there's an API Is there an interface to the API currently?
What do you mean by an interface?
Is it possible for me to I'll have to read the documentation. It's just not clear it hasn't been clear to me that one could use this. Yeah. Now there's documentation that looks like I have to install software and then I have to write some code, etcetera, etcetera. So I will explore it. Thank you.
Yeah. So, I think, this sorry, I forget who asked the question about how it was deployed. But right now so we both linked two different UIs for the API documentation of Swagger and Redux. Those are just the generated docs for the APIs. But there's not, like, a public instance of Medigov that you can just, like, hit to test it out. Because if you you see those docs are interactive and you can try it, but it'll give you a four zero four every time because all the endpoints are restricted to local traffic only because they're not, like, protected. So right now, the way you would use it is you would have to deploy your own instance of Medigov and use it locally.
Okay.
So but that's also that's, like, not really explained in the docs yet. So that's where that's where we're at.
Can we Monday have a, like, a demo project that people can just hit from the open Internet?
Yeah. But it's we'll just I worry, it'll lead to a lot of insecure things happening. Because as soon as you try to activate one of the plugins, you'll be sending some API keys. And then it's just bad things will happen. But we can talk about it.
So it's not cooked yet. That's why I haven't found it. It's because it's we're getting a preview. Good to know.
Yeah. So to to be actually clear to everybody, Medigob is not released. It's not active. It is still kind of in development, but we're presenting, yeah, this preview to get some feedback. Next, we have Thomas with a question.
Yeah. I'm not sure it's a question or a a comment or or or what. This is beautiful work. I gotta make sure I say that again. I I love this. There's a way in which what we're trying to do, I I think, is allow people to self organize and say, hey. We've decided to be a collective and, you know, look out around for tools and grab some stuff and and couple things together. And, or even be an existing group and say, we wanna govern ourselves better. Oh, look. Medigob. How cool. And and then, you know, do interesting self deterministic things. And, there's there's a way in which I'm I'm reading the white paper that you referenced about expressiveness, and I'm trying to make sense of that. And I'm not sure if the the defining output of governance is in fact decisions, which I used to say all the time. Like, the the outcome of governance is decisions, you know, making them and carrying them out and verifying them and whatever. I'm wondering now if the basic unit of of value from governance is legitimacy. And I don't know if that sparks anyone to think any new thoughts or tell me we already talked about that or or what. But my recent epiphany is now here in in the in the shared space between us. And if someone has anything useful to say, I'd love to hear it. That's all I got.
You is are you using legitimacy in the in the same way that one could use accountability maybe?
For me, accountability is between any two people where one says they'll do something for the other, and then when they're done, they both agree that what the agreement was matches what the what the outcome was. And so it could be peer to peer. It could be, you know, boss to subordinate or subordinate up to boss or whatever. So accountability is a two person game, and legitimacy is more of a principal agent game where I entrust somebody to do some stuff on behalf of either me personally or on behalf of a collective. Right? The collective empower someone to be the agent to do something. And the collective can then claw that power back or even repudiate the actions of the agent and say, yeah. No. That's not what we wanted, or we've changed our mind. We no longer want that. And so it's a slightly different game to me. So, yeah, accountability is a four part, two person game minimum. And I think legitimacy and governance could could be two parties, but it might be it feels different somehow. It's a really good question.
I guess, I I can't remember where this came up before, but somebody else was also talking about, like, the relationship between legitimacy and and consensus or, let's say, legitimacy and, like, decision making processes of which, you know, governance is kind of the superset of that. And I guess, like, sorry. Go ahead.
I I have a an accountability loop diagram that I think I wanna share if I may. Since you someone used the word, and it's one of my hobby horses. So, like, claw me off the stage if you need me to. Other otherwise, I
will share. Something we could bring up because I'm just realizing we're at, like, fifty three minutes.
I'll I'll stick a link in chat. Awesome. Thanks.
But, yeah, there's there's a there's a, I guess, a convoluted relationship or maybe just a relationship that I don't totally understand between legitimacy and social consensus. But it does seem pretty clear to me that they're not actually the same thing. That you can have legitimacy without any social consensus. And like, Dada, for example. And data, for example, is, quite strong on the idea that, you know, they care about, legitimacy without any consensus. It's kinda like they're trying to make anarchy actually work. Right? But I think we have one last question, which is Alex had a question. Alex, do you wanna just mention briefly?
I just noticed looking through the documents that you shared and examples that you gave that NEAR protocol was specifically used for the prototype and, actually, as an example of, using the system. And I was wondering why why NEAR in particular and not not some other smart contract platform.
Honestly, like, I I can jump on this. Yeah. Honestly, you wanna yeah. It it just came out because I think we have built some relationships with people at NEAR. It wasn't because, like, this platform versus that platform. I think from the point of MediGov to the degree that we can be completely agnostic as to, like, the specific smart contract platform, the better. It's just that NEAR had these specific governance use cases that they had brought to us. And then, I guess, I'll just take the rest of the time to kind of briefly mention that they're organizing this essentially governance challenge. We're we're co organizing this governance challenge. And they're putting about, like, a decent chunk of change behind it to kind of fund different experiments, to actually run them on your platform. So it's just kind of like, okay. Well, we need to build start building some smart contract integrations. Why don't we just start with your Build some use cases and then from there, go elsewhere. If if it makes
sense. That's all. Yeah.
So If
you're in the oh, sorry. You're in the Slack the Slack channel? I mean, the Medigap Slack. If you have any, like, comments or questions, you've asked really good questions about, like, integrating the blockchain or, like, the architecture, just Slack me on there. Love to chat.
Awesome. I'll just take the unless are there any other questions that people might have? Okay. Awesome. Actually, so in that case before, I do like a tiny little little plug for the for the hackathon. Can I ask everybody to, in the next three seconds, to unmute themselves? Three, two, one. Thanks, Marion.
Welcome presentation. Really terrific.
And a great discussion. Cool. So just like really briefly before people head out, there I've announced in the Slack, but there is a hackathon that we are co organizing with NEAR. We're really, like, we're organizing, like, the governance parts of that hackathon. And if anybody is interested in getting involved, please just ping me directly either on the Slack or through any other channel. There will be a kind of organizer organizing meeting. I'm gonna just tentatively set that for Friday noon, eastern time. So if you wanna log in and just for say hi, we'll be trying to figure out, like, basically, designing a few kind of, like, events for hackathon participants as well as, I think more importantly, identifying, like, a set of what I think of as, like, final projects or capstone projects that different hackathon participants could get involved in or sort of use as templates for their projects. So if you have a governance experiment that you would particularly like to run or think, you know, should be run, but maybe either you'd like you don't have the team right now or the capacity, You think this is something that could fit a kind of, like, could be either it doesn't have to be accomplished over the course of hackathon, but, like, some meaningful progress on that experiment could be made by some hackers working together on a team. And ideally it should involve some sort of blockchain with smart contract logic somewhere. Then please please, yeah, stop by. Love to get your help and get some ideas flowing. And also, the sort of the really awesome thing is that, this hackathon will be one of the first ways in which we kinda start stress testing the core Dominica prototype that Miriam just presented here. So we'll be exposing this to Hackathon participants and asking them to actually use it. So awesome. Oh, actually, John made a really helpful just recommendation getting a sense of video. Yes. Eventually, there will be documentation and videos. Alright. I think if that is all, I think we can call the call the meeting. Thank you everyone for joining us.
Thank you.
Bye, Molly.