dev call 20260601

Mujina Dev Call transcript, 2026-06-01

Speakers: Ryan, AgentP, Brett, Dylan, Jeff, Johnny. Transcribed and lightly cleaned by AI from the recording. Summary and discussion: https://github.com/256foundation/mujina/discussions/61

Ryan: Recording is on. Recording is on. Okay. So I have created an agenda and made a Dev Call section in our GitHub discussions. So you can follow along there or watch it on my screen share. Thanks to Average Gary, who's not here this week, I guess, for giving me some advice on how to hold these meetings. Roughly, the plan is to try to touch everything that's going on in the project so people can stay up to date and do that by following the development workflow of the project. Going from sort of least formal to maybe most formal of our communication channels. You'll see how that works as we go through the agenda today. I will start by pointing out that the last call got summarized and transcribed by AI for the first time. So I'm interested to hear what people thought of that, if anybody looked at that, if anybody objects to that. Otherwise, I guess we'll keep doing it. Any thoughts? I thought it turned out pretty well, actually. And just FYI, I didn't use any grand service for that. I just locally did the transcription and then fed that to Claude to have him summarize it. Him, I shouldn't say, to have it summarize that and clean up the transcript a little bit. Like raw, it just says like speaker one, two, three, four, but Claude was able to infer from our discussion, like,

AgentP: Who those speakers were probably.

Ryan: And so that it made, it made editing that transcript really nice. So I thought it turned out well.

Dylan: I haven't gone through it yet, but it does seem, I skimmed it quickly. It does seem helpful for catching up and calling us.

Ryan: Yeah. Or appointing agents at it and asking questions about what happened. If you want to read through it'll be good for history. All right. I looked through the action items from the last meeting and I think that we will cover them by touching on the various discussions, issues, etc. So there's nothing we need to like specially talk about as a follow up to the last meeting. It's going to happen naturally. Oh, well, one question I did have is I noticed there are some groups like Fedimint who post their recordings to Bitcoin TV. I don't know if that's something we want to do. I didn't post the last one. I probably won't post this one, but maybe something for us to think about. I guess the only reason, I mean, we're posting transcript anyway, and if there's some reason we wouldn't also post the video so someone could watch it. I don't know. Any thoughts?

Dylan: Seems like a good idea to me.

Ryan: Okay, well, maybe we will do it unless someone objects. All right, on to the agenda. So we can start with our least formal, which is forum chat and maybe some X posts worth discussing. So in the forum, Jire asked, what should go in the forum versus in GitHub discussions or maybe the other communication channels. So thoughts would be good chance to refresh. Obviously the project is young and we're still trying to figure this out. So this is all subject to change. But I think for now the distinction we're trying to draw between the forum and GitHub discussions at least is that GitHub discussions are for developer technical conversations, especially about the code because you're already in GitHub then and it's easy to make references to PR's issues in code. Whereas the forum is more of a user facing So, hey, I'm showing off this thing I did or I have a question about how to use something or, you know, less developer-centric, more user-centric. I guess that's the idea for now. But we'll see how it goes. I am a little concerned that... We end up with too many different ways to communicate. And so it's confusing and not obvious what to use. So I'm aware and sensitive to that issue. We should make sure we don't create a problem for ourselves. But for now, this is kind of, I think what our philosophy is. Anyone have a thought?

Brett: I think that makes a lot of sense what you're suggesting. All right. Yeah I think like the forum being for more casual sort of discussions as opposed to more technical discussions being on GitHub I think a clean separation there doesn't create that issue of like what you were saying with like having too many discussions, because the people who are focused on technical are going to be on GitHub anyway. And if you say, want to take a break from technical stuff and go look at, okay, what are people building with this, that type of thing, you can go over to the forum. And if anybody's having a technical issue on the forum, somebody is going to point them from the forum to GitHub. Right.

Ryan: Yeah. So we'll do that and see how that works. Another forum discussion worth pointing out. Someone asked, looking at Skot's Antminer demo, whether we kind of asks a bigger picture question about Mujina. Are we building a framework here or are we building things that support particular miners? And so I gave an answer here that I think restates a vision we've talked about before, but just to restate it here so that we all stay on the same page. I think what we're trying to build is, first and foremost, a framework, basically, of modular components, and then we assemble those to support specific miners. That shouldn't be mind-blowing, but I think that does kind of guide what we do with some of these vibes. You know, when we have this prototype of something work on an S19, for example, I think our goal should be to tear that down into its parts and end up committing and merging some high quality framework parts that support the different things. So like power supply controller, whatever the reusable parts of that are. And then we compose those parts into a solid board support file for that particular miner. And the good news is as we continue to build on the parts down the next time someone shows up and like oh I want to do this with my s19 xp or whatever like all the framework is just all the component parts are sitting there and it becomes much simpler for a person or an ai to just assemble those into a new board so we build component parts and we assemble them to like support specific miners and We try to merge it all into mainline Mujina once it's of high quality enough. So hopefully that vision makes sense. Jump in with any comments anytime, guys. I was hoping AgentP would show up because he posted in the forum that he got things working on an S19 XP, which is really cool. In fact, he posted some pictures to X. And generated a little bit discussion on X about it. So, if he were here, I would ask him to give us a tour, but, so this is really cool. Let's see, I think in the forum posts, maybe not this one, but in a different one, he asked, so what do I do with this? You know, I, how do I help get this into Mujina? And So I think part of the answer to that is we talked a little bit in previous times about how like, okay, it's going to, I think one of the workflows that's going to emerge for us and in this new era is people do some prototyping. They share a branch with it. And then maybe, you know, one of the things maintainers can do or they can do or people who show up looking for something to do can do is to pull from these branches and sort of review things, polish it up, and turn these prototypes into legitimate contributions. So I started a new category in discussions. Called Good Vibes and seeded it with one of my own. So we'll get to this when we hit the discussion section, but just to preview, I think this is the direction we should point stuff like this for now is like Skot did a S19J prototype vibe earlier. I've seen some other stuff. Ronald has been posting some stuff on BZM2. Rather than have these show up as PRs, I think we let people create discussion threads pointing to their own branches, branches from their own forks. And that would be a good place because now people think people could talk about them. People can reference the branches and they're not like cluttering up our poll requests looking like legitimate things that we're working on. Comments?

Johnny: I think actually that's a really good idea. In my other project, similar thing. I have people that want to contribute, but they aren't able to do the back and forth to champion a pull request to get it across the line. So I think the right balance is let them do that. And to either pull in their commits directly into your pull request or maybe co-author them or something so that they get some kind of you know you still want to incentivize people to do that so they get their credit without like forcing them to do the back and forth pull request thing So I think anyway, my point being that, like, I think you're in the right direction. Like, that sounds really good. And I think the trick there is to figure out how to add them as co-authors or what that looks like.

Ryan: Yeah.

Johnny: To incentivize people to get contributions without maybe being forced to do the whole thing.

Ryan: Well, mechanically in GitHub, I know, let's see. I did this before Skot submitted something to me. I think his Mac OS USB discovery thing. And it was pretty close, but I had to make a lot of changes to it. But when I committed it, yeah, I just tagged him as Skot. I put a co-authored by field in the git commit log, and GitHub picks up on that and lists him as a... Let's see if I can find it. Like in the commits, it shows that it was me and Skot.

Johnny: I think that's a good balance, yeah. Oh, geez, it was a long time ago. Maybe I won't find it easily.

Ryan: But you've probably seen it before, you know, like where it shows up with two, like you see both people's icons on the commit and it lists their name. And it's also how, I think that's how Skot ended up.

Brett: Commit hash starts with D as in delta 174. Thank you.

Ryan: What's the, can you give me a few more?

Brett: Send the chat for you. D as in Delta, 174, C as in Charlie, D as in Delta, E as in Echo.

Ryan: Cool, thanks. Yeah, so GitHub recognizes these co-authored bylines. And then it shows that Skot and I committed this. And it also makes sure they end up on the contributors section here on the main page. So yeah, that's the kind of credit I was thinking. Like yeah, that's important. So cool. We'll see how that works out. I'll talk a little bit more about that when we get to the discussions. What else in the forum? People have been asking... Run button. Man, you lose your mind when you're projecting. You forget how to type. People have been asking if the STL files for the Ember One water blocks is something I have. I don't have them at the moment. I'm trying to get them. Ryan Raminger from Cryobite Labs built those for us, and I'm pretty sure he said we could have them. I just haven't been able to reach him. So I'm still working on that. And then just wanted to point out for anybody who didn't see it, Schnitzel talked about his DumaX, which runs Mujina, on a podcast recently. So I dropped a link to that. But this is LibreBoard running Mujina using Bitaxe as a hash board the way we do in development. Talking to Hydra Pool. Actually, it was running Hydra Pool locally. It was running a Bitcoin node locally. It was battery powered. Very cool. So check that out if you haven't seen it. All right, that covers the forum and chat section. So on to the discussions. And again, the reason we're taking things in this order is because that's kind of the way things flow through our projects. They sort of start as a twinkle in somebody's eye maybe, and they talk about it in the forum. Or in chat, and then it becomes like a development discussion before it becomes a verified issue or a PR or something like that. So that's why we're taking things in this order. Okay, so important discussions. Here is the... Discussion. I added, the configuration system and rest API. So this was the big topic last week. And sorry, last two weeks ago, our dev call where we were reviewing, Jeff's and, Jair's, work on the YAML configuration files. And I kept saying, yeah, this feels like a bigger issue. Like I want to talk about, because I had some ideas on how the configuration file intersects with the API and how configuration flows throughout the inside of our code since it has wide-reaching effects. And I promised that I would write this up. So I did write this up. This discussion points to all that. And I actually hope this works out. I invented a new thing because I ended up you know, this isn't just a small discussion. This was like, I ended up writing up like a requirements style type document. So because it became a document and it's something I think it will be easier for us to collaborate on like as a document, like actually comment on sections of it or push changes or something like that. I actually wanted it to formally be in GitHub as a document. So I started a Mujina Improvement Proposal Repository. Obviously, in the style of BIPs and NIPS from Nostr, not everything we do has to flow through this process, and I'm trying to, I'm not suggesting we make some kind of heavy-handed process here. I just wanted a place to dump something that looked like a requirement document so that we could talk about it. So the discussion links to this. This is MIP1, which is all about configuration and the API. So this is what it looks like. It's quite long. I don't know if anybody's read it yet, because I only posted it a couple of days ago. But I would definitely be interested in everybody that was interested in this topic last time going through this. Because this pretty completely gets my thoughts out on paper. So I'd be very interested in everyone's feedback since everyone was quite interested in this discussion last week. There's two ways you can read these things. You can either look at the Markdown formatted version, obviously, or... But to really work on it, you're going to have to read the markdown and make comments and stuff in here might be useful. Anybody have a chance to look at this yet? And if so, what do you think?

Jeff: I read through it, Ryan.

Ryan: Cool.

Jeff: And I thought it was outstanding. So thank you so much for the level of detail that's provided in this. This is great. Do we have some amount of time to talk about it, or should we table that for some other time?

Ryan: No, I think we should dig in. This is probably the meatiest thing we have for the call today, so we can talk about it a little bit.

Jeff: Okay. So a lot of it made sense. But the one thing that I wanted to ask about, and if you can elaborate on, is the requirement for a in-memory configuration tree so specifically dr1 design requirements

Ryan: What I was trying to say here was just that as I pictured it taking shape inside the code, I mean, we can end up implementing this however it makes sense, but hopefully it's clear that from the user's perspective The configuration tree, the tree that you see in the API, those should all sort of feel like they're one tree, right? And because of the way... Like, if you make a change to part of this tree, that value should sort of propagate to listeners inside the code that have subscribed to changes in that value. I was just picturing that there would be some sort of core data structure inside the program that would represent all these things. The API's view of it, because the API sort of adds on measurement things that aren't necessarily configuration values. The API sort of, these other parts of the code sort of have views onto this tree. So I just didn't want there to be, you know, You know, a configuration tree, the API has like a whole different tree. There's another tree for another purpose. And they're all just kind of like kept in sync somehow. I was just more trying to point us in the direction of hopefully when we end up with a data structure inside, that's kind of like the authority and all these other things are sort of either views or inputs into it. I don't, that's just kind of what I was picturing. I probably didn't write that up very well, but I got tired toward the end of the document.

Jeff: That works. That works. I get it. And so I guess, so sorry, I missed the discussion from two weeks ago. It was on a family vacation, but it sounds like the group has come to consensus. Maybe I'm reading into this that we want Mujina to allow for dynamic configuration updates. As opposed to being in immutable application. That. The system of. The source of truth for all configuration would be in the in the configuration files themselves. Does that question that makes sense? And then is that, am I, is that true?

Ryan: What you say to me make, yeah, that makes sense. I guess I would, I would say, it's probably not established consensus yet. It's probably, that's what I want or, and that's what I've laid out in this document. And I suppose that's one of the very things that's up for discussion and debate here.

Brett: So to clarify, are you asking whether Mujina should, when there is a live configuration change, make changes to the configuration file? So there's a couple of situations, right? There's the sort of like immutable Mujina that I think you were talking about, which is like, You set a configuration when you start Mujina and it stays that way and you don't mess with anything. It just stays that way. And to make any changes, you have to restart Mujina with a new configuration file.

Jeff: That's exactly what I'm asking about.

Brett: So that's option number one. And then, yeah, option number two is, hey, we want to make this dynamic. And maybe Mujina keeps a cache of this information but doesn't actually update the configuration file. And number three is Mujina keeps an internal cache while also editing the configuration file with dynamic changes. I think the ideal scenario is probably option three. You wanna be as dynamic as possible, especially you think about like a situation like dynamic load management, right? Okay, imagine I have a solar panel and that solar panel produces a different amount of power throughout the day. I'd actually like to be able to step down the frequency, the voltage, the power consumption of that miner that's running on that solar panel based off of the time of day, ideally without restarting Mujina, because as soon as you have to restart it, you have to go through the chip startup procedure and everything again. And the less downtime you can have there, the better, I think. So I'm generally preferential to fully dynamic.

Jeff: Got it. Okay.

Ryan: Yeah, I think what I've written up here would be probably in category two, if I understand right. And the distinction I guess I would make is, yes, I want Mugenia to be as dynamic as possible and totally dynamic. I would describe it that way. The part maybe I didn't buy into yet or we should discuss is that In my design, the user's config file is not something that Mujina edits. Mujina has its own other, you can think of it as another config file, another layer where it saves changes that are made via the API. The problem with that, I guess, one downside is you can't just open a file and see the entire configuration. In my case, if you open the user's config file, you would see the things the user said that differed from the defaults. But if you, in order to get a true sense, like a true dump of the whole configuration, that really sort of only lives inside of Mujina where it's pieced it together from all its different sources. And so you'd need some kind of tool or command or API view where you're like.

Brett: Or an API endpoint that summarizes like API v1 config or something like that would maybe make sense.

Ryan: Where you would see the merge of the built-in defaults, the user config file, maybe multiple user config files, and then saved config that Mujina is saving from the API, things that come in over the API so that that persists across restarts. It's described pretty thoroughly in the document, so take a look there and see.

Brett: Yeah, sorry, trying to read through this document and listen at the same time. Generally, I like the idea of the user configuration and Mujina's internal configuration being separate as long as Mujina's internal stuff is relatively, what's the word, persistent. It sticks around across reboots or restarts or whatever has to be done. Yeah, and I guess it also heavily depends on what's in the user config file, right? Like if the user config file is just like, oh, I put these boards in or theme or something like that, right? It's less of a big deal. Yeah, I don't mind the idea of having it be an API endpoint that consolidates this.

Ryan: Yeah. I mean, ideally, I'd love to be able to just open a config file and actually see everything at once, but I think it's just too complicated to... That works for a simple program. I think Magine is just too... It's not going to... That doesn't handle a complicated case.

Brett: Is there anything wrong with, say, for example, having a dynamic YAML configuration file that holds that config that mirrors the directory structure that you're proposing here? So you just have subkeys that mirror that directory structure?

Ryan: Instead of separate files in a directory structure, you mean?

Brett: Either or, right? You could have a directory structure like that that is then mirrored by Mujina into a YAML configuration file if you wanted to hold that, and or they go back and forth. It's just a thought, right? That's a way to sort of accomplish what you're thinking while also putting it in a single file in a way.

Ryan: I think it's, yeah, it sort of works like that. Definitely not a single file. But yeah, I think we, it sounds like we mostly agree in spirit on some of this. I like the directory structure. The devil is definitely in the details. That's why it took me so long to write this. Because once you go down the road with an idea, you're like, well, what about this? What about this case? How does this get saved? What if it restarts now?

Brett: The solution, as with anything, is just provide a good API to the user, right? The user 99.99% of the time is never going to even look at the sort of firmware layer of Mujina. They're not going to do any of this. Everybody should be interacting with it via the API. In theory, whatever decision you make on the backend does not matter as long as the API is responsive and reasonably designed.

Ryan: That makes some sense. We're the main users of these config files, honestly, as developers, probably.

Brett: Exactly. So whatever you think makes sense, probably makes sense.

Ryan: The developer, the packager who, you know, is making an image for a fleet of miners or whatever, like the config files sort of serve them more than anybody else. The tinkerer. Anybody else want to make comments now I mean I think we're there's a lot here so and a lot of people aren't here in the meeting so we'll probably just let this ride for you know several weeks let people make comments after they've actually read it like comments in the discussion and or mip PR here

Dylan: I'll make sure I read this this afternoon. I currently lean heavily on the dynamic side. I think option two had headlines.

Ryan: Cool. Yeah. Yeah, no, this is great. I mean, I think we got people with all the right perspectives here to look at this. I'm excited. Like after I got done writing this, I thought this is pretty dope. Like if it worked like this, that'd be pretty cool.

Dylan: Did you write that and think, wow, someone should build this?

Ryan: Yes. And I thought, wow, there's a lot there. You think you're building a miner, but you're building a lot of other things. OK, guess we will move on. Any comments about the whole MIP thing in general? Like I say, the goal is not to be process heavy. I just needed a place to park something like this, where it get, it got wrote up pretty thoroughly. All right, as with everything else, we'll see how it works. I think that's our general policy here. I closed a number of old discussions that were sort of subsumed by this discussion of configuration and API stuff. So if some of you had opened discussions in the past, you might have saw that. I just sort of closed and redirected them to this discussion. Okay, other discussions. Like I mentioned before, I started this good vibes category for the purpose that we outlined before. Oh, AgentP is here now. Awesome. We talked about your your stuff a little earlier, but let's do it again now that you're here.

AgentP: Sorry, I was on another call and hopped in late, but I wanted to say hi to the team. I'm mostly vibe coding, but it's fun to be able to contribute a little bit with those tools.

Ryan: Yeah. No, no worries about being late for all. What you did looks very cool. And you're definitely the first person to use this on an S19 XP. I'm just curious, what is your, like, technical background? Because I'm curious what I mean, obviously, you seem pretty technical to me if you were able to make this work. But I'm curious what level was able to make this happen.

AgentP: So my background, a long time ago, I went to University of Michigan and got a computer engineering degree there. So I did pretty detailed embedded systems work and robotics engineering. So that's my technical background. So I'm familiar with embedded systems and then kind of didn't use it for a while because I went into the military. So I've done that military work since 2010. So the technical stuff, I've kind of tried to keep the skills warm as a hobby because it's fun and I enjoy it. I have a busy life and so I don't get a lot of hours to sit down and write code, but LLMs make it so that I can sit down and write a 10-minute prompt and then go take care of the kids and get dinner ready and then come back and check on it later. That's how I tinker these days.

Ryan: Okay, sweet. Well, if you don't win the sats from this contest, I don't know who will.

AgentP: It's fun. I kind of ratioed him. I think it's the first time I've ratioed anybody. But it's cool. I don't think he likes me because I poke at him because he doesn't like open source stuff. Yeah, that's true. I poke at them once in a while. I don't care. It's fun either way.

Ryan: Well, that's fun. So this plus the post you made in our forum actually sort of prompted me to think harder about we've talked in the past a little bit about like, okay, how do we deal with prototypes like this where someone has vibe coded something really cool? And you even asked like, well, how do I help get this back into Mujina? So what I did was create a new section in Discussions? Bear with me. Okay. So, I made a new category in discussion called good vibes. Sweet. And then I put one of my own in here. But I think this is what we'll test out doing for now. Can you please create a discussion in here that describes what you did and links to the code? Yep. Easy. Yeah. Because then we can collect these and I think this will be a good place for certain level of contributors who are like, well, I want to work on this. I don't know what to do. We can say, hey, there's this awesome prototype here. Can you go through it and do some reviews? That's really good. Pull it into parts that can be merged.

AgentP: I think... I think it's really good. I was thinking about this just musing in the car the other day. So the vibe coding era, I mean, it's changing the world. For open source especially, it used to be that the limiting factor for open source projects was just the time, availability, funding for devs. And now it's to the point where anybody with an idea can contribute halfway reasonable code. That's really cool, but it could come with the added challenge of just a flood of good idea fairies that get vibe coded real quick. And how do you wrangle all those cats and not have it overwhelm the maintainers of the project? How do you, how do you pull those good ideas in, and keep it structured, but still be able to leverage and take advantage of all of these new capabilities and new ideas and new contributors that are trying out different things. So a good vibes section seems like a really good first way to test this out. Maybe after enough of those get collected and then you start to see, oh, maybe there's patterns between them or some commonalities. And then you can start to see, oh, here's a structured way we could actually pull in a few of these into a way that makes sense. I don't know. But it'll be interesting. It's a whole new world for sure.

Ryan: For sure. Great time to be starting a new open source project.

AgentP: Yeah, but I will go ahead and make a section in there in the discussion. Perfect. Put some details and we'll go from there. But yeah, this really was a couple of prompts. I pointed it to the main repo and said, hey, make this run on my machine. And for reference, here's Skot's repo where he got it on a JPro. And look at those two things and write some code and here's the IP address. Let me know when you're done. It was kind of, that was the gist of it. And the thing got to work and, got it working. So.

Ryan: Yeah, no, that's awesome. And it's also interesting to, that you posted your prompts and sort of talked about your process cause that's helpful too. So yeah, anything you can build into the discussion there would be great. I will ask Skot to put his JPro thing here in a similar way because that's the perfect thing. In the future, that would be the place to discover something like Skot's branch and then base your thing on it. Right.

AgentP: Or future vibers, if they're pointing their LLMs at this repo, hopefully that those agents pull in these good vibes discussions as well in these other repos and can do more research and then you'll get better output from future vibe coders, hopefully that are.

Brett: Taking into account these other things that's actually a really good idea you could build up an agents.md file that points the loms directly to those discussions actually in theory yeah like yeah hey check out these discussions here under good vibes for more information on certain things right

AgentP: Yeah, I think you'll get better input that way from future agents. They'll probably produce output that's structured better according to how you want to build the project and will make their outputs easier to pull in to main when it's appropriate.

Ryan: Yeah. So this is great. And thanks for showing up here. I guess as long as we're looking at it, I'll just make a brief pitch for my vibe here. Because I'm curious what people think in the future if they want to comment on this. But... TabConf had a little mini conference before Vegas. And as part of the mini conference, they did a little hackathon where it was like, take two hours and see what you can hack with AI into your open source project. So obviously I did something from Mujina. And what I hacked in was a work source. You know how we've sort of abstracted the idea of pools and other sources of work into a, what we call a source in Mujina, a job source. So I built a new job source that points directly at a node and uses Git block template. So sort of mine directly from the node without a pool. So I just- I just built this for the Bitaxe. Oh yeah? Cool.

AgentP: I just wanted to see if it was possible on that little ESP32. Turns out it is.

Ryan: Yeah. Very cool. Makes sense. So, so that's my vibe. I don't know if that will actually turn into a real job, if anyone that would actually use such a thing or whether that's worth turning into a real job source for Mujina, but, who needs a pool, right? If you're truly just lottery mining.

Johnny: Should take a look at the, new IPC also for Bitcoin core.

Ryan: Yeah. So you're saying I did this the old school way?

Johnny: Yeah. There is a Unix socket-based IPC. It should theoretically be easier. I don't know if it is, but yeah.

Ryan: Cool. The other one thing I will point out about my vibe, because all the other... I feel like such a kid calling them vibes. But the vibes I've seen from most other people, it kind of ends up just as one commit, one large commit. And one of the things we would have to do in order to get those into Mujina is obviously break it down. Not just into good components within Mujina, but also just a good series of commits that kind of adds things piece by piece. So I sorta tried to get my agent to do that as I was developing it. So you'll see that my vibe is a series of about eight or nine commits, which I'm just showing you this to sort of get the idea across of like One of the things I want to make sure we keep doing in Mujina is keep our commit history very patchy, small atomic patches like this. So that's part of the work we will have to do when we take vibes in is sort of breaking them down into like this isn't a 2,000 line patch that just touches the whole code base. Sort of walks it step by step. So just thought I'd point that out as long as we were here. And so maybe that's something, if you're planning to do a vibe, like get ahead of that a little bit by sort of teaching it the way Mujina wants to see its commits. And I've in it, Our repo is already a great example of that. I'm sure an agent will pick up on that if it looks at it, the existing history. And it's also covered pretty well in our contribution documents. I spent a lot of time initially like anything that I was recognized as I was working that like, oh, this is something I'd want to see from contributors. I've tried to make sure that ends up sort of documented for people to read. But now in this new era, also just for agents to read. So if you're vibing and your agent isn't already looking at that stuff, have it look at that stuff. So we were trying to end these at an hour, so we probably won't make it through everything. So let me scan to see if there's anything worth pointing out. Maybe I'll just open it up and say, Is there anything someone else really wanted to see talked about today that's on the list or not? A lot of things I listed here were just sort of catch-ups since we've never actually gone through all the issues in PRs, so these aren't necessarily hot things that just happened. I was just sort of covering them for completeness. Dylan, I was interested in if you, I didn't warn him, but I was sort of interested in what you do for, I've noticed that you do office hours for your home assistant project. I was wondering if you could say what you do and like how that works out and like, does that seem useful to your community? And what would that look like if we did something similar in Mujina?

Dylan: So far? I think so. It's very informal. Every wednesday at 10 to 11 a.m mountain time I just have an hour on a jitsi call where people can pop in either ask questions about a home assistant show off what they're building doesn't matter if they are feeling something very complex or something very simple I will do my best to help I do not think I'm an expert but I have made a lot of mistakes and I'm willing to help people build correctly in the right direction. Yeah, I'd say, I mean, only usually a couple people show up. And if not, if no one shows up, it's just a dedicated hour I have to work on my very long list of one day I'll do this home assistant projects. So I think it's helpful. I think it's, I would have wanted someone to do that when I was starting on home assistant. 10 years ago. So it's just helpful for people to come ask questions if they have them.

Ryan: Cool. Okay, that's cool. Keep that in mind. Another thing I thought sort of related to that was in some other open source communities, it's common to like have a chat room where when people are sitting there hacking on stuff they just they're in that chat room and sort of just office hours in that sense of like yeah we're all here working on something like if anybody has a comment or a question sort of we kind of have our 256 foundation chat maybe that's the place to start for now but I guess I don't know that I would always hop in there and announce, hey, I'll be working at my desk for the next four hours. Right.

Dylan: I like the idea of that. But I think Telegram or the other chats might be... Just a continuous group call in Telegram?

Brett: Wow. I'm in a couple chats that do that, that just have a group call open at all times that you can just hop in and out of as you see fit.

Ryan: I guess I would, I guess I kind of wish or picture that whatever chat channel we have, hopefully, cause right. We don't want too many, but would sort of just be that a kind of live ongoing hang. But we sort of deleted the Mujina specific channel got deleted. So I don't know, maybe we do need to create something. Maybe we do need a separate one for us. I don't know. For now, we can just flood the 256 Foundation one until they get tired of us. But anyway, if you're ever just working and have live questions, I try to pay attention to that if I'm working. But I also hate Telegram, so it's tough.

Brett: I guess that's a question. What would you prefer? What is the better option there?

Ryan: Better option. Maybe there isn't one.

Brett: Show up at your house, knock on the door. Brian, I have a question about Mujina.

Ryan: I guess time has moved on. We're not going to do IRC channels anymore. I don't know what's better than Telegram. I guess I'd rather have Telegram than Slack or Discord. That's fine for now, unless someone has a great idea. All right, well, we've hit our hour mark. Thank you for attending. And take advantage of all of our communication channels to follow up. I'm definitely curious about your opinions on the configuration thing. And would love to see some more vibes and good vibes. And I'll see you guys in the ether. I'll hang out for a little while if anybody wants to talk. We can release everyone to go on with their day. Thanks everybody.