Community Debriefs Weekly Debrief

RChain Co-op Weekly Community Debrief #192 Aug 19 2020

Tech Update:


Greg Meredith 00:01
All right, we have a lot to cover. So let’s go ahead and get started. First, I just want to say that over the last week, the network doubled in size. So we have twice as many nodes running. And we staked about 20% of the revenue circulation is backing the security of the network. So that’s a huge win for the cooperative. I want to congratulate everyone, the entire community and all the people who worked so hard to pull it off. So I’m very happy about this development. And speaking of development, Raul, are you ready to give the dev update?

Rao Bhamidipati 00:56
Yes, I am. There’s the link to the Community Update 133 and I’m going to share my screen with that update. So there were there was a lot of work done to get ready for the park change and make sure that the epoch change happens and the bonding and unbonding occurs. So we have had since then a couple of minor releases, the test, the main net, all the nodes are now running 09.25.2 I spoke about 09.25.2 in the last session briefly, which was about these things to be fixed in here if you see my screen. So improvements to the bonding and unbonding process. And we released them both in, and 09.25.2 and some security bugs. And then this review, ending improvement of updates is separate meaning it’s started, or we started listing them there, based on what scholars toward reports, but we’re in the process of resolving them, that’ll probably show up in the future releases. So that’s where we are with the network right now, both the test net and the main net are all running 09.25.2, and I will briefly display what kind of fixes were there in 09.25.2, as you can see, these are some of the things to make sure that the synchrony constraint is acting upon only the active validators. And this is something that as we moved from one epoch to the other, we realized that we needed to put that in there and this is something again, that’s a security bug. That’s now fixed the preventing deploys with the keys for blessed contracts. And then making sure that the ports stay attached is used by default for exploratory deploys, those are some of the main ones and then enabling perkier streaming queue on the outbound side. So, those are some of the changes that went into 09.25.2 the main milestone that we are working towards is 09.26 which will have the completed last finalized state and that right now is being tested. As long as we don’t run into any issues, we should have it sometime next week, ready to be released. We still have some tests to be written on 09.26 as well as running the existing tests and doing the fixes and changes as needed. That’s where we are with the 09.26 release but we’re getting close to getting that completed. That’s where we are at last session we did not do the tech governance meeting because we will busy with the epoch change and post epoch change and making sure everybody got their rewards back and checking and double checking to make sure that no accounting errors anywhere so all that type of stuff. So that’s what happened in Tech governance. We are continuing to work on a bunch of initiatives to both speak to the business model and the validator economics and the economics of the token to support the network security and network decentralization. All of those are conversations in process. We are also beginning to look at running multiple nodes on a single machine. See how that goes. Because we really from a decentralization perspective, we want to get to a situation where anybody can run a node, you know, in their basement or at work or wherever, where they have decent network connection, to be able to decentralize the network. So that’s something that’s ongoing. It’ll probably be a little while before we are comfortable saying, Okay, this is what you can do from home. That is certainly something we’ll continue to focus on. So those are the main updates. From my perspective. Are there any questions or comments on any of this? All right over to you, Greg.

Greg Meredith 06:33
Thanks very much. Yes, so sorry. I’ll just turn off notifications quickly. So while I’m doing that, Darryl, do you want to do the community week in review?

Darryl Neudorf 06:51
Oh, yeah, sure. Thanks.Okay, so here is the week in review for Thursday the 13th to today Wednesday, the 19th. On Thursday in the Governance Committee call the Governance Committee discussed reorganizing a nominating committee in order to evaluate Board of Director candidates and prep for the annual general meeting, and review the procedures followed by the nominating committee in the previous year, with a view to adapt to the process this year.

In the DApp Developer Working Group, testing locker.rho and log.rho, and investigating issues with Visual Studio Code Rholang extension.

Darryl Neudorf 07:33
On Friday on the climate and coordination call, we discuss the collapse of a Canadian ice shelf and the storms and flooding in Spain. We also discussed BP’s shift away from fossil fuels due to shrinking demand and the blockchain’s prospects to help humans with governance. On the Monday Casper Standup call Greg spoke to a correction in the quantum mechanics interpretation from a couple of weeks ago and extended the interpretation to include superpositions. On the blockchain art call, they did an evaluation of the scuttlebutt decentralized chat. And yesterday on the RChain Education call, they learned how to analyze RChain network operation using observable HQ. Also on Tuesday in the Communications Working Group meeting, we discussed our Instagram and Facebook accounts. We also discussed the requirements for migrating site to GitHub Pages, and integrating an KPI dashboard on the homepage. Also on Tuesday, the DAP developer Working Group developed a fix for Visual Studio Code Rholang extension. And this morning, just before this call is the member hangout call. Ian brought up the tool from the education session in regards to creating dual RChain entities. Gary talked about Rhobots sieve email filters and the scuttlebutt protocol. Theo has been working on Integrating IPFS for voting. And I discussed a new concept floating around that involves setting up a triangle of entities. And that’s about it. So yeah, I just want to thank Jim, Steve Henley, Rao, Ian, Theo, Greg, Nora, and Gary, for all their contributions to these recaps. And that’s it for this week.

Greg Meredith 09:26
Thanks very much. Any questions for Rao? Darryl?

Ian Bloom 09:32
Yeah. Regarding nominations for directors prior to the October 24 annual meeting. The deadline, according to the bylaws is this coming Tuesday to say whether you’re interested in becoming a nominee for directorship.

Greg Meredith 09:51
So please, please, please, if you’re interested, do step up. We’ve had a great team this year. And I think, you know, it’s a really fantastic opportunity to help the co op grow and meet its its goals. What’s the item of business deadline?

Ian Bloom 10:19
Not sure just off hand.

Greg Meredith 10:23
Okay. All right, we should probably. So if you want items of business to be considered on the ballot for the AGM at the end of October, 3rd week in October, please please get those to the board right away. And then. So we also have been spending some time so I’ll go over this very briefly. We sort of need to curtail too much discussion about it in this forum. But we will have you’ll sort of get your exposure to it in this forum, if you didn’t get get it last Friday, and then we can talk about about it in more detail in the Friday forum. And just to be aware, half of this presentation will will be, you know, I won’t I won’t present that until Friday. So there’s another half to this that speaks to Venus. So if you’re interested in Venus development, Friday would be the session to join. So unless there’s any questions or comments from the community, I want to talk a little bit about a model that we have been kicking around. So any questions or comments before before we dive into that?

Ian Bloom 11:47
Just the answer to your question the deadline to submit an item of business for the annual meeting is no later than two weeks before the annual meeting. That date is the annual meeting is October 24.

Greg Meredith 12:00
Okay, so So does that October 11. So right. Yeah. So that that that’s rushing towards us. Please get them in. I

Ian Bloom 12:20
think it’s the 10th 10th. Okay, so yeah, before then.

Greg Meredith 12:26
Okay, so we are looking at an equity model two and give people an option to invest in something that they can have a piece of in addition to the token models that we’ve been using and will extend. Okay, so as we know, the internet is being refactored, right, so it’s moving From centralized control by a few companies to decentralized applications serving decentralized communities. And obviously blockchain plays a big role in that. Of course, it’s not the only it’s not the only force. Obviously, you know, when the US Congress calls the CEOs of the Big Four to testify, it means that there are other forces at work besides just technology and market forces. So this is a real thing. Um, but even if we have these, you know, decentralized versions of these applications and to do that, that requires a significant amount of reimagining those services. Even if we had a working prototype of a decentralized Facebook there’s a long way from a working prototype to service that, you know, is run 24/7 so obviously blockchains like RChain that have bet on high transaction volumes to keep the transaction fees down and and then still have the network be viable. They can’t wait around for the community to just grow applications. I mean, it’s great that we that we are seeing applications coming. But, we have to we have to be in charge of our own destiny. And so the cooperative has to see the space with applications and it gets a twofer if it does that with applications that simultaneously fulfill organizational requirements, like governance, that the reason to aggressively pursue RChat and RVote, which we’re delighted to see is, is largely community driven. But again, even if we had, you know, well, I mean, and I should point out before before going down that path, it’s kind of important that these applications also provide templates for others to quickly develop applications. So the point with with zulip is to make it so that we can demonstrate just how quickly you can start with an off the shelf tool like that, and rapidly get to a decentralized version of the of the tool. And that acceleration is an important part of the way we’re thinking about this whole play. Um, so so what I said before, you know, is really critical here, because even if, you know, it only takes us a few person weeks to get zulip with an RChain back end, and all of the sort of basic kinks worked out so that we have a functioning application. And that’s really not the same as a service that’s running 24 seven. So for example, recently we’ve been seriously contemplating the end point that the exchange in the wallets use to access the network, you know, being aware of like we’ve seen now for four months how they’ve used that endpoint. And so changing the API a little bit to help them out. It might initially upset their code. And so the same is true for any DApp that’s running on top of the platform, if the protocol changes or an endpoint API changes, who’s going to be there to make sure that the DApp or some feature in the DApp doesn’t degrade or or cease to function. Likewise, you know, if an observer node goes down or any of a number of other things change, who’s going to be there to make sure that the the DApp is still running? Who’s going to make sure that the their bugs shaken out of existing features, who’s going to make sure that there are new features coming because of requirements that show up through long term or large scale usage, you know, who’s going to make sure that those features get developed. So that’s a separate set of capabilities that needs to be monetized. And what we’ve seen is that, you know, Software as a Service is a very viable model, Red Hat, mySQL, and many, many others are examples of this as a very convincing model. What’s different, though, is that with RChain, we have this ability to kind of cookie cutter stamp out a lot of these services. And so that means that a much smaller team, like a team of 10, can run 10 or more of these services. So that’s what is one of the things that might make a an organization that does that kind of thing more scalable, and therefore more profitable. So this is the kind of picture that’s emerging. First, let me let me let me speak a little bit to the right hand corner of the triangle. Can everybody see this is big enough? Yeah. Cool. So so there’s been a lot of discussion, debate dialogue, around whether RChain is a worker Co Op or a consumer Co Op. I think there’s been a lot of push within the the dev side of the community to have RChain be more like a worker Co Op. And so, you know, I mean, they’re strong business reasons why we need a consumer Co Op. But I can certainly understand why not make a worker Co Op as well. So the thought is to just go ahead and do that. And then the various members of the community that wanted to worker Co Op, they can, they can participate in that worker Co Op, so if they’re members of Colab who would want to use that infrastructure, you know, to begin to monetize some of their efforts. You know, others in the community might use that and that gives them a legal framework so that they can address some of the legal risks that are associated with providing code to various parties, and there’s a built in customer in the form of RChain cooperative, that might toss over the wall specifications, designs and early prototypes. And then, you know, suggest that they’d be taking the next step. But then at the top of the triangle we have and again, these names are not fixed. I’m just using them as placeholders. We have what we’ve been calling RSaaS or so this is a shop which is doing software as a service. So you can you can think of, you know, the co op season need, like RVote or RChat, and throws out some specs and some designs, possibly even some early prototypes. RDev takes that the next step, and then to an MVP, and then that MVP is taken up by RSaaS and run as a service and developed over time into into something that that is usable on a 24/7 basis. And of course during that course, that may produce additional requirements for the platform, right. So as they’re running the service to say, well, it’d be really nice if the core protocol did this, that or the other thing would make our lives easier. So that’s an output. That’s another kind of output that comes out of RSaaS. So Rao had a really nice observation, you can you can think of RDev is kind of the builder, you know, in the, in the in the domain of properties, you know, housing and office space and that kind of thing. You can think of RDev is like a builder contractor and RSaaS is like the property management. So that’s, that’s one way to think about it. There’s an IP issue that has to be addressed. So in particular, if the co op comes up with some designs, and our dev takes those designs to an MVP, then both of those parties should get a small slice of the revenue stream that comes out of that service. And then RSS is only going to take services on the basis of a metric that looks at the number of seats that you might see in that service and the number of click to pay events per annum per seat over the operational cost of that. So if you have RChat, then there has to be somewhere in that, some kind of tokenisation or other kind of click to pay events that generate you know, steady revenue streams before RSaaS would be willing to, to pick it up as a service. A small but very important point is RSaaS does not have to be you know, beholden or bound to RChain. It can be working with other chains as well. You know, such as Cardano or Ethereum, Elrond, who knows, whatever smart contracting chains actually make sense to build services on top of. And as such for each of these core protocols that it’s got services running on, it’s going to need a cache of tokens to run those services. So as a hedge, it makes sense for RSaaS to have a token that service users can use and it on the back end, does all of the market management to make sure that those Services perform as desired. So for example, if RChat were to offer tokenisation. So the data lives on RChain, and there’s some tokenisation behavior that lives on RChain, and some other tokenisation behavior that lives on Ethereum. For example, you know, there’s some things that you can do that run smart contracts on aetherium, then the our chain would issue I’m sorry, our SAS would issue a token that is used by endpoint end users to to drive the service and then on the back end, it sort of turns that token into the right mix of REV and ETHER. And so there’s a there’s a token management play here as well. And then RSaaS has a built in market for the services in terms of the co op and the co op is already motivated to do community development to expand its user base – its membership. But it works the other way, as well. So as more services come online, then that also drives people to the co op. So it’s a it’s a kind of win win for both parties. So what we’re suggesting is that, that the the current SPV morph into our SaaS. And that SPV is now wholly owned, as an organization by RChain cooperative. And then as people purchase equity in this instrument, in this company, then the control you know, moves outward from RChain. We don’t believe that it’s necessary for RChain to, to own or or have, you know, complete ownership of that for It’s lifetime, but it’s probably the right balance for that. So does that make sense? Any questions, comments?

Jeremy Querci 27:09
Greg, I think the introduction of another token, probably introduces a lot more friction than it does anything else. And I would also think that from the SaaS perspective, there’s probably a lot of potential corporate users that don’t want to touch tokens, or can’t touch tokens, but and may not necessarily have what you would call click to pay events, but that want to integrate various blockchain technologies or attempt to integrate them into their stacks. And, you know, I think it’s what you described what makes otherwise other than the token makes sense. I think it’s looking at it from a retail perspective. And not from a not from like a centralized entities wanting to use this platform, which is then going to bring value and then inevitably flywheel effect, maybe retail follows. If I was, you know, a fortune 500. And I said, Hey, you know, I want to integrate RChain technology. And maybe I’m going to start off with some type of permission chard or something. There’s no click to pay events. Are we saying that that the RSaaS teams not going to work with them?

Greg Meredith 28:28
Not necessarily. Not necessarily. That so there may be, there may be an elaboration of the metric. But these these are all great comments and great question. So let’s, let’s, let’s have a vigorous conversation about this on Friday. And then on and just informational questions now. And then I think, I think Rao is setting up a time for for you and Rao and I to have a much more detailed conversation. So all of these are great comments, and I really agree. Any other any other informational questions or or comments?

Ian Bloom 29:10
Ideally, I think we would want there to be lots of different RDevs and RSaaSes out there. And I’m just a little curious what why brand these things under the under the same branding as the as the co op, if we want to demonstrate that, you know, any organization can can come in and pick up the code and start building applications and and in hosting and providing.

Greg Meredith 29:40
Yeah, I mean, that’s a that’s a great question. I don’t think that the “R” necessarily attaches it to our chain. Right. It’s not like we said, RChain developers, or RChain Software as a Service. Just the “R” is just a designation and it is It talks about it can talk more about origin rather than specific affiliation.

Rao Bhamidipati 30:07
yeah. I mean, I guess there are a couple of points here. I mean, Darryl, for example, was saying the “R” is more like “our” as in the co op. But the the point of these organizations is really to have something that will jumpstart transaction volume on the network, and increase the financial security enhance the overall usable the security, growth of the network and decentralization. It doesn’t mean that there cannot be 100 other organizations also doing something similar, right? So there is not this is more than think of that more as a jumpstart vehicle. So that then people can be inspired to it because it’s the developer ecosystem is a chicken and egg situation, people won’t start doing things unless they know that okay, this is going someplace. So this is a way to demonstrate that the protocol and the network is going someplace, going to a good place so that others can then be motivated to do their things. At least that’s how I’m I’m personally viewing that. I’m not sure if Greg agrees with that or not. But

Greg Meredith 31:24
no, I very much agree. I very much agree. I mean, you know, it’s one thing to say that we want a lot of these organizations but until there’s at least one you know, people people don’t do that don’t do it right. So we need just like you know, there’s been a lot of hue and cry Oh, we really want to workers coop and we’ve suggested: “Why not just make one” but people won’t do that right. So if we make one then people can participate in it and and get the benefits of the, you know, the legal the framing of risk.

Ian Bloom 31:54
So the co-ops role then is to jumpstart these things and to encourage them to be as open and non proprietary and as exemplary a model as possible. So, others can come in and copy it and then also for the co-op to get out from from these jumpstarted business ones as well to maintain I mean,

Rao Bhamidipati 32:16
once you are inviting investors into it, what does “co-op getting out” mean that means co are basically giving up full control to the outside parties is basically what it means. But, but I mean also to keep in mind that this ecosystem development is not a either well understood or well defined process. So there will always be questions coming up for us to have to resolve to say, Okay, how should this be this be configured some situation will arise where we have to make a decision as to say what does the coop have anything to say about it, and what do they want to say if they do have something to say about it? So those kinds of that kind of experience you won’t have in the organization unless you are also running something like this. In sort of thinking of it as if a large an enterprise is running an inside Innovation Center, on a venture center, they’re more equipped to deal with winter’s coming from outside and what to do and how to do and all that kind of stuff. So this is similar to that in that we have a lab, if you would, that not only for technologies, but also for organizational practices and conflict resolution, and how do we make sure that the competition is is healthy and helps the growth of the network as opposed to leading towards more centralization and more takeover of the network, that kind of behavior. So there are a lot of benefits to working with something like this to identify the issue. ahead of time, and then say, Okay, well, here are two or three different ways to resolve those issues. At least I see that as one of the benefits to  doing something like this. Otherwise, you basically are leaving it for whoever, either with the money under control or whatever to take it over. And as an open source, it that is always a possibility anybody can do their own version of it. So we’re not expecting that somehow having this is restricting anybody from running their own models. But it’s more that having this kind of an organization helps us identify debate and resolve issues around the conflicts and mutual synergies and how do we optimize the synergies and things like that?

Greg Meredith 34:48
Yeah, yeah, absolutely. I’m in 100% agreement, you know, and then until you have such a thing, you know, we can we can say, Well, you know, there should be lots of them, but there has to be at least one. And, and we and, you know, and and to a certain extent, we will have failed if, you know, our SaaS builds all of its services on some other chain, right that won’t help the co op from the point of view of generating transaction volume. So we have to execute as a as RChain cooperative, we have to execute in such a way that it’s very beneficial for RSaaS to build on RChain, right, there’s a good solid reason to do that.

Darryl Neudorf 35:36
I think like another analogy that could be played here is another Co Op, that I worked for Mountain Equipment Co Op here in Canada. Very much like REI we made our own products. So we had the MEC brand mountain equipment co-op brand and, and, you know, we built, I think some of the best outdoor clothing ever made, you know, like we I think we did a really amazing job at it. We had an r&d department and a guy developed a type of clip that is widely used on other products now. So, to me, I see it kind of similar to that where we were a store, we sold mountain equipment co op products, but we also sold Helly Hansen and all sorts of other company’s products as well. And it’s still going strong.

Greg Meredith 36:40
Yeah, you know, Darryl, your comments about you know, because you had said you wanted to do a kind of music streaming cooperative. And your comments were when we when we walked it through the model, I thought they were helpful and clarifying. So when you say So so you as a client of this ecosystem, you might come in and say, Well, you know, I have some ideas about what I want this thing to do and how I want it to look as a music sharing service. And so you could go to RDev and say, Hey, can you can you can you make me You know, I’ve got so many K to put together an MVP. And they bid on on that. And assuming they, they win the bid for your dollars, they put together an MVP. And then with that MVP, you you move along to RSaaS and you say, all right, well, here’s an MVP for a service. Right? These are this is this is my click to pay model. This is my economic considerations. I’d like to buy your services for a year to have this, this streaming service, be operational for at least a year and they They take on that contract and keep it running for at least that amount of time. And they there may be a back and forth where they give you some guidance about, about your economic model say, Well what we found from these other services that this tokenisation is better than that tokenisation. And you might, you might take that feedback back to RDev and say, Hey, can we modify the MVP a little bit like this, they do that and then you toss it over to our RSaaS, and then they they make it run as a service. I thought that was a, you know, when when we walked it through like that, you know, I thought it was very edifying and, and clarifying. Does that. Does that picture still make sense to you?

Darryl Neudorf 38:42
Yeah. I mean, to me, this is the path that I need to do what I want to do. So, you know, it excites me greatly. It actually helps me think that, hey, you know, maybe I don’t need to generate $2 million to start the startup. Maybe if I came up with like, 50 grand, or maybe a couple, a couple hundred grand, you know, I could I could hire some developers from RDev, and you know, get the ball rolling with it. So it kind of gives me like a, as, as someone who wants to build DApps on RChain, it gives me this kind of easier thought about how I could get started and get going with it.

Jim W 39:23
And the importance of tokens is that you can they’re tickets to use your product. And if you can create 1000 tokens, and then if people believe in your product, they’ll buy the tokens. So that’s the other side of the token. I think they’re necessary.

Jeremy Querci 39:46
I would just say I would just say with tokens in general, I mean, I’m not an anti token person, but I do think at times they’re overused. But I would also say that even when they’re used appropriately, you have to consider things such as ensuring that there’s systemic liquidity available so that you don’t have to have a human person in the middle exchanging these tokens, you need to make sure there’s an active deep book of liquidity on both the buy and sell side, you need automated execution. I don’t know if that’s bonding curves or whatever it may be. There’s a lot of friction with tokens, even ones that are appropriate, that needs to be taken into consideration. You then also have a lot of people that are not crypto native, which is inevitably needed to come into the ecosystem, if we’re going to have visa level transaction demand that either can’t touch tokens, don’t want to touch tokens, whatever it may be. And so there’s a lot of considerations out there. Not saying tokens are bad.

Jim W 40:46
Yeah, you know, it can always be play tokens.

Greg Meredith 40:53
Yeah, yeah. Understood. Yeah, these are these are really important questions. I mean, the the more tokens, you have The difficult more difficult it is for a user to wander through your space. Right? This is something I thought a lot about when we were thinking about RSong was, you know, it makes sense for certain artists to have their own token. But it does not make sense for every artist to have their own token. Because then you got, you know, 10 million tokens and, and, you know, exchanging amongst them to get to the artists services that you want is, is a nightmare and a headache. You know, it’s not it’s not easy, it’s now much more challenging. So there’s some, there’s some sweet spot somewhere in there. But finding out what that is, is difficult.

Jim W 41:38
Well, you know, your wallet needs to pay for things in the tokens you don’t want and sell them in the ones they want.

Jeremy Querci 41:51
I’ll just say that, like, every single token that is created, inevitably needs to have a sustainable economy in and of its own and inevitably creating more tokens in and of itself does not necessarily create more value and hence if you’re spreading value out amongst more tokens, especially if the aggregate value is still early and in question, you may actually be sabotaging the hall, whatever it is that’s being built, sabotaging any one from getting any type of critical mass of value, which then attracts liquidity or attract network effect.

Jim W 42:25
Well obviously if you create more tokens, then there is demand for your product. No, that’s not, you know, you’re not going to be liquid. So if you’re if you’re providing a service that people want, and are willing to pay for it in advance, then you can go

Greg Meredith 42:46
Yeah, I think I think that there’s there’s a lot of interesting discussion and debate and I think it’s really important to, to to look at it from from multiple angles before….because it’s there at this point, it’s very easy to mend tokens. It’s too easy. So yeah, it’s definitely worth thinking, thinking this through from every angle that we can think of. And I really, really enjoy the vigorous discussion. That’s it’s great to see so much energy in the community debriefs. All right, well, unless there’s any other informational questions or comments about the the thoughts that we’re having right now. We we are we have time sided on Friday for a much more in depth talk, and also talk about how this fits into Venus. So looking forward to having that conversation. Any other questions or comments from the community before we sign out?

Darryl Neudorf 43:47
I have one thought. About 15 minutes or so ago, we were talking about the “R” part of the RChain brand and what the “R” means and all that? The way that I look out It is that “RChain” is the brand. And the “R” is the philosophy or the “why” of our chain. So when I think about, you know, these, these kind of like, placeholder names that we’re giving for these, these different ideas here, like our “RSaaS”, and “RDev” and “RSong”, you know, they’re probably not going to be the actual names of these entities. But it helps me with the philosophy that it’s a new form of capitalism. We’re building here. It’s shared ownership, and that’s what excites me. So I just wanted to kind of lay that down right now.

Greg Meredith 44:42
I love it. That is exactly right. You know, it’s this this this highly compressed way of talking about that, that I I don’t I don’t want to say ideology but that that that particular The worldview?

Darryl Neudorf 45:01
Yeah, well, I think, you know, philosophy, I think, you know, and again, connecting to the “why”, of why we’re doing all this. It’s like, you know, when I think of “our” in front of these things, it like you say it’s just high impact, it quickly gets the point across. And, and it helps me maintain that focus.

Greg Meredith 45:21
Yes, indeed, indeed.

Darryl Neudorf 45:23
And so as we start to kind of solicit the traditional top down business model, right, we’re trying to solicit that mentality here, right. With the SPV. So, you know, as we do that, you know, we’re always consciously aware that we are, we’re wearing the pants.

Greg Meredith 45:43
I love it

Jim W 45:45
that we’re decentralizing. We’re creating an sociocratic polyarchy.

Greg Meredith 45:51
Indeed. Awesome. That’s a great note to end on. Thanks to all I really appreciate the hard work. And I’m glad to see that we’re you know, we’re on an upward path, I would strongly encourage those in the community of female persuasion to consider a board seat, the board could could use you know, more estrogen. So please, please consider, please consider running for for a board seat. All right, thanks to all talk to you soon.