-
Notifications
You must be signed in to change notification settings - Fork 47
dev call 20260817
Ryan: Recording is on. Okay. Good morning, everyone. We gather again for a Dev Call. These are recorded and transcribed by AI, so fair warning. The idea for anyone who's new is that we try to go over everything that's happened in the last two weeks just to keep everyone on the same page, to discuss anything that's easier to discuss in person and to be able to see each other. So we roughly follow like the categories of discussion maturity in our project in a reverse order. First we talk about PRs that closed or that are being worked on and then issues and then stuff that's in GitHub discussions or that we've talked about in our forum chat or whatever. First on the list this week I didn't have this on the list until a few hours ago when my Twitter started blowing up, but 256 posted a link to RY3T's Nova product, which Schnitzel's working on. So Schnitzel, maybe you can tell us what the news is and maybe just an overview of why this matters.
Schnitzel: Yeah, happy to do so. Yeah, so the end goal of the NOVA is basically excess solar monetization. And specifically in all over the world, but specifically in Europe, there has been a lot of change on how much money you get if you inject electricity back into the grid. And specifically in Switzerland and Germany, where RY3T is working, the company is headquartered in Switzerland, the electrical cost is right between 30 to 40 cents per kilowatt if you buy. And it used to be if you inject back into the grid, you got like 30. Then a couple of years, they did change it to 15. They changed it this year to six. And now, actually, if you have more than, I think, 10 kilowatts, peak so that doesn't mean if you actually inject 10 kilowatts all the time but just if you are capable of injecting more than 10 kilowatts you get charged the real-time price or you get paid the real-time price which is sometimes in switzerland negative so you're literally gonna pay to inject energy which is completely stupid right and so people are now Everybody's freaking out. People are buying batteries. People are installing additional water heater coils to heat their water hotter. But all these systems, even with batteries, they're just at one point, they're full. And some people actually... Heavily overbuilt their solar panel systems because they were hoping that they can basically get a faster return on investment, right? There were literally claims of like, you can retire with your house and stuff like that, right? Because if you build enough solar panels, the solar panels will make you so much money that you can retire and that stuff. And that's obviously all because the government subsidized it. So we're back there where the government does some things. So the product of Nova is basically up to 3000 watts. So inside is an S19J Pro that you connect to your house and it can talk via either Modbus or MQTT to your existing inverter or smart meter that tells the Nova through these two protocols basically how much excess solar panel is generally generated and it will use this right away. And so I would say there's two main new innovations in it. One is the fact that because we can install now directly stuff on an S19J control board, we bought S19J Pros all with MLogic boards. So we don't need the Raspberry Pi part anymore. So the Nova, which is a Rust binary, runs on one of the S19 control boards directly. So we don't have to buy anything additionally. And the second one is probably what you've already seen, is the fast response to changes of watts. Because yeah, what these solar panels, because based on how they're built and because of clouds and all that stuff, the amount of solar or power that they should use needs to be very flexible. And so that's what we were showing, being able to show with Mujina is that we can react based on new or for new what requirements within like three to five seconds. And so the Nova, it starts with one, but it's actually stackable. And what is really cool is that it also discovers the other two and adds it to it. So then it automatically goes back and says, oh, I can now use 9,000 watts or 6,000 watts and things like that. You can also change it. Let's say you want to use 3,000 watts, but you have six available. You can tell it if you want to run both minders at 1,500 or if you just want to run at 3,000 first, all that type of stuff. There's a web interface. There's an app. And the Bitcoin that is mined in the end goes to the homeowner so they can choose where it's going to be sent. On the hardware side, yeah, it's an S19J Pro, but we replaced the fan. So it's actually a squirrel fan or a radial fan that cools the whole thing because noise is a bit of a concern. And it's just like super simple. Like it's power in, you put Ethernet in and basically that's it. And then you can configure it. We have the first prototypes. I mean, ultra prototype is literally running next to me right now, which is just three S19J Pros. However, we have the first box. So what you see also on the website, the first one has been built and has been installed at our customers. And we're testing like the integration into the solar panels and all that stuff because I don't have solar panels at home so I basically had to I actually had to build a little mock solar panel system for my home assistant and stuff but yeah it's really cool and like I said it's all based on Mujina it's all and there we're still seeing how much of nova itself is going to be open source I definitely want to most of the stuff will become open source there might be some things that we can do because it involves other partners and their licensing models are a bit weird sometimes. So we're still working through that. But yeah, the end goal would be is to have like some kind of either capability in Mujina or maybe it's like a site binary that you can install and then you can talk to like home assistant and automatically update the what's based on it. Yeah, basically that's it.
Ryan: That's super cool, man. Yeah. Your last comment, that's a good illustration of what we've talked about a few times lately on podcasts or whatever, cuz licensing keeps coming up and like Mujina is its own piece. So its license does not necessarily infect commercial products. What, what needs to be open source is changes you make to Mujina itself, but it doesn't force you to re release your whole product. As you're illustrating. So that's cool. What happens when there is a mismatch, even for a little while, between what you're consuming and what the panels are generating? What buffers that?
Schnitzel: Yeah, so it depends a bit on the system. If you don't have a battery, basically the grid is your buffer, right? So if you, if we, let's say the solar panels generate only 2,000 watts and you would then generate 3,000 and you would use 3,000 watts on the Nova, you would basically just consume 1,000 watts from the grid, which is going to be very expensive. So that's one of the things is Nova is very conservative in the usage, right? It rather underuses, underutilizes the available power than overutilize. And if you go the other way around, let's say we're producing 4,000 watts, but there's only one Nova, so I can use max 3,000 watts. Then you basically sell another 1,000 watts to the grid, which then depending on, yes, which price model you're in, you might be then get charged again. But that's not really the problem of Nova, or at least in the current assumption. But yeah, we're just trying, we're basically talking to the APIs of the smart meters or the inverters and try to match their overproduction as close as we can.
Ryan: Interesting. So these people that have built systems, like they're going to produce, they're on the roof. Yeah. So it's not like they can just elect to not participate.
Schnitzel: I mean, there are literally people now that build smart meters or like solar inverters that have a physical power off switch again because people saying, I need to turn off my solar panels over during lunch because otherwise the system will bankrupt me. That's so insane. It's typical stupidness of these subsidies and stuff like that. And we haven't really seen a good alternative to solve this problem. Yes, you can buy massive amounts of batteries or things like that. Or you could heat your pool to 120 degrees Fahrenheit or something. But there is not really a good alternative. And Bitcoin is the perfect thing because all it produces is heat. Right. And this is not made for heat reuse. Yes, you can put it into a shed or a garage and it will heat it, but it's literally basically just converting energy into Bitcoin.
Ryan: Well, very cool. Does anyone have any questions for Schnitzel? Well all right hopefully this this is the first of many products so thank you for setting a great example here and I'm glad it's you doing it all right let's walk down the list PRs to talk about I landed several PRs this week that had to do with the supply chain of dependencies we have in Mujina. So Rust crates coming from crates.io. We talked about this last call, but last call was right after the cold card scare. And so we sort of contemplated what that implied for all the projects in Bitcoin, including ours. And one of the things was, well, okay, we need to be more careful about supply chain attacks. Probably just for us developers. The risk here is that you go to build Mujina someday and it pulls down a dependency that has like a malicious script and build script in a crate. And then it looks around your machine and exfiltrates something or plants virus or whatever inside your network. So the standard way to mitigate against that is to, use lock files to say I only trust this version of a dependency. You know, it checksums to this. Don't pull in new ones unless I intentionally ask you to pull in new ones. That way, typically when someone injects a malicious dependency, you know, it gets caught within a few days and then pulled out of something like crates.io. The idea is if you intentionally, are you intentional about when you pull things, you can avoid those small windows of time when something's vulnerable. And you also don't want to pull dependencies that have just changed like yesterday. So if you look at my PR, it A, locks down all the dependencies to their current versions and adds some scripts for updating them. Which look to see how old they are and it will only take updates if they've aged a little while in the repo so this is sort of the standard practice for what you do on software projects that pull dependencies like this these days we just hadn't done that yet because we are still maturing as a project in various ways. So it was time to add that. So I added that. That's these first couple PRs. You can take a look if you're interested in how that machinery works. At the same time, I also added some stuff where it checks licenses to make sure that they're compatible with GPL. What length did you use for the cooldown? I used seven days. Which is a little longer than the standard recommendation, but we're in no hurry to grab dependencies right away.
Schnitzel: Yeah.
Ryan: I'm willing to negotiate on that number if anyone disagrees.
Schnitzel: No, I actually feel like seven days is maybe too short.
Ryan: Too short? Yeah.
Schnitzel: Yeah. I mean, I know in the Fiat job, we've now ended up doing two weeks. Okay. Yeah.
Ryan: I don't have any problem making it bigger. When I was poking around to see what other people did, like seven days, I think that makes this one of the longest ones I saw.
Schnitzel: Oh, really? Oh, yeah. Yeah, well, then let's leave it there.
Ryan: You know, like I say, we're in no hurry to get to dependencies quickly. There's also like a cargo advisory database that this checks against too. So every night there's a job in GitHub Actions now that checks our dependencies against the advisory's database. And if something new popped up, it would file an issue for us to see. So in that case there's also like in the scripts you'll see there's a way to update any particular package like immediately or to say update to this version right right now so that would be like our advisory response procedure you know because you don't want to wait for the seven days if you're trying to fix a security bug so I also created a way to intentionally fast forward a package past immediately if that was necessary due to these advisories. So look at those PRs if you wanna understand more about that. I also closed a PR that was started by ye olde 256 red team. Schnitzel, you wanna tell us what you did to poke at Mujina?
Schnitzel: Yeah, I mean, that one was found with just analyzing the source code. So it's basically Kimi K3 with a little bit of a pen test harness in open code. And yeah, I just gave it access to obviously Mujina. I mean, he knew how to access it, And it found not many things. That one was one of them, right? There's like a length of a read buffer. So these are like, if you basically have malicious pools that send you non-standard payloads that can cause some issues. So that one, it found itself. Yeah.
Ryan: Yeah, several of the issues you filed here seem to be related to... Yeah, just the other ones I actually found with fuzzing.
Schnitzel: So the first one was just static analysis of the code. The second one I actually, or the other three, I asked it to actually build, like it basically built a pool that just sends non-standard stuff and also non-linear, like non-logical orders, whatever. And I started the Mujina CPU miner, which, by the way, is so cool. Like, it's every time that I can just, like, I don't need to start hardware. I don't need to start an S19 anywhere. I can just tell it, hey, build Mujina mine, right, and see if you can affect, basically, with a malicious pool. And a lot of this is connected to that because Stratum V1 is unencrypted. This could be done with a man-in-the-middle attack. So it's not just a malicious pool. It could be a malicious internet provider, a malicious government, whatever. A malicious device in this own network as well. And so there are a lot of things that... If you send it back unexpected data that the Nidamachina behaves wrong or restarts or things like that. So you could basically, if you have access to the traffic of the Stratum B1 traffic, you could take down a mining site or things like that.
Ryan: Yeah. Very cool. Well, so I fixed one or two categories of that in PR 89 here. And then there's three more. At least three more here that didn't look urgent that I needed to jump on them right away. So I haven't fixed it yet. None of them are urgent, yeah. But they're sort of similar. Like you say, you found these by fuzzing. One of the things as I was working on them, I started to think, I wonder how, so you submitted these, you sort of submitted these reports as PRs with patches. And some of them are, as I looked at them and thought about them, I thought, oh, okay, I see the issue this is pointing out. I probably wanna solve it in a very different way. And so I wondered, and I'm glad you're here to ask, Is this the way you're submitting issues to all projects or cause I, and I assume your agent is, you know, doing a lot of the work here. I know that we don't have a security dot MD file in our repo that like instructs you on here's how we'd like to see things reported. Do some people prefer that your, you submit issues via issues instead of PRs and is, or are you pretty much sending patches to everybody like this?
Schnitzel: So right now I'm reaching out to the people first and ask them. It would definitely be helpful if there's a secure security MD that tells like, what do you expect? There's also, I don't know, have you ever used the GitHub security vulnerability reporting system?
Ryan: Yes. I turned it on for RCN.
Schnitzel: Yeah, it creates like a separate repository even and the gifts only the people access to it. So yeah, it would definitely be helpful if there is a security MD that just says like, hey, up to this level, right? Like I think. My agent marked all of them as low. So that if you're saying, hey, up to medium, it's fine to report them as issues or not at all, like do everything or send an email first to that place, whatever. So yeah, having some kind of policy would be extremely helpful because right now I need to reach out to each of the maintainers manually and ask them, hey, what do you want to do? And then I need to copy that message to my agent. It's a lot of copy-paste work and manual. So yeah, a security MD that just describes the process would be extremely helpful.
Ryan: OK, cool. Yeah, I think I might end up converting some of these to issues. Because some of them can sit for a little bit longer. And wait for someone else to pick them up. Or some of them might just be solved in a very different way. So it'll be cleaner if they just start as issues. Okay. And I'll probably put a simple security.md in there. Yeah. That sort of explains that same thing.
Schnitzel: Yeah because the agent definitely looks for it right like it asked me like hey I couldn't find the real way how to submit this what do you want to do and I was like okay well let let me talk to the maintainer so yeah if there would be something it would be great super cool and emails is maybe not the best either because not many agents can send emails
Ryan: Yeah, no, I think I would just, like you say, like up to a certain level, ask it to follow them as issues. Although it is nice to have the patches. I don't know. How would we do that on the issues? I guess you can still sort of inline a patch or attach a patch or something. You know, they don't look exactly the same way as PRs.
Schnitzel: So yeah.
Ryan: Anyway, cool. Thanks for doing that. Glad, Your robots aren't too disappointed in Mujina. All right, other PRs. If they have this green logo in front of them, that means they're still open versus these ones up here that are merged in the purple. Jayr submitted some initial PRs for the configuration implementation. There's also his outstanding series for the sv2 support which I'm about halfway through if he were here I'd be apologizing to him right now he's been very patient with me I appreciate that Ronald isn't here, but he's got some BZM2, not really related to that code exactly for the BZM2 chip, but stuff he changed elsewhere in Mujina as he was working on that. I need to talk to him about some of that. There's a lot here in these PRs he submitted, and I'm not sure... How to review it or how much to take, how much of it ultimately relates to something that he wants to merge into the public project versus not. So I'll probably reach out to him off to the side. There really wasn't any issue activity this week. Although, like I say, that stuff that Schnitzel submitted is sort of like issues. I guess I'll mention anyone is welcome to take a look at these if you want to comment on them or... Suggest a way to fix some of them some some it would be probably best to if you want to work on one of these to Mention that somehow in the comments and then throw in a few comments about like what how you intend to fix it so that we can just And I'll respond to those quickly But there are some these aren't always just obvious. There's some decisions to be made So it's worth talking about them first All right, down to our discussions. I think the big mover and shaker this week after RY3T is the stuff Aadhi announced that he had working on his Nano 3S. There was a big X thread about that. And there was some discussions from a few weeks ago in GitHub that mentioned that you are working on this, but why don't you, if you've got a microphone available, can you jump in and tell us what you did, how it's working? What do you think?
Aadhi: Oh my God, that's a long process to explain. Yes, of course. So basically the first thing I did was I got SSH access. So what Canaan did was they really made their CG miner for the Nano 3S open source. So with that, I was able to compile an image with SSH enabled. So after that, I started snooping around and experimenting how things work and taking control of all the IOs and et cetera. So after that, I got a base idea of how everything is structured and how every communication works. I actually tried interacting with the Stark RTOS code that runs on the second core of the processor. But I wasn't able to. Something was failing. And after that, I got too pissed off because of that. And after that, I totally stopped everything from the software side. I started hooking up my logic analyzers to the connectors. And after that, I started sniffing out the communications and guessing what registers what and doing a replay and testing everything. So it took me more than two weeks to get a solid communication out of the ASICs. Turns out I didn't do the power enable. That was my main issue. I figured out the power enable after two weeks. And after that, all the ASICs started showing up and it started to work. And after that, I had to rebuild all the whole program for the RTOS code, for the IPC mechanism, and for Mujina to talk to it. And yeah, I started working on that and took my four or five around like a week or a week and a half to finish that and like one main problem that I had was I wasn't getting like stable hash rate you know like you know like in the Nano 3S when you put it in like low mode you get like 3.3 terahashes of hash rate but I was only like getting like three terahashes So it turns out these chips have four PLLs in them. So all these SHA engines, based on the temperature of the chip and based on their error rate, they can choose what PLL they want to run at. So each PLL has a 20 megahertz difference. So when the chips get really hot enough, like up to like what, 90 C, 90 Celsius. And many of these SHA engines like jump up to like a higher PLL. It gave me like an instant hashed boost. Yeah, while testing, I was like running my fans at like max speed. That was the total issue. That was my whole problem. So, yeah, after that, once I figured out that these ships like to run the heart, you know, in a very hot environment or like a hot temperature, I started like, you know, working on everything and, yeah, it's slick work worked out fine. This was my whole procedure for what I did for this.
Ryan: Cool. So the architecture here is there are two processors or one processor with multiple cores. Is that right?
Aadhi: That is one processor with like two cores. One core runs at like 1.6 gigahertz and the other one runs at like 800 megahertz. So we call them like a big core and little core. So obviously big core runs like the RTOS code and little core runs the Linux side of everything.
Ryan: Oh, okay. I would have maybe guessed it was the other way around, but okay. Did you replace all the code on the RTOS core with your own?
Aadhi: Yep. So the RTOS is like fully a hundred percent built by myself based on my, you know, logic analyzer capture and yeah, and everything. And that was one thing. And after that, I made my own IPC mechanism based on the SDK provided by the Kendryte team. You know, it's open source for these processors. And after that, I directly link Mujina to talk to the IPC and that's it.
Ryan: What does Kendryte's SDK allow you to do?
Aadhi: Basically, it's just like this processor is available in many dev boards and other AI projects, you know, stuff. So you can literally do anything that you want related to this processor. So let me find the SDK for this.
Ryan: Okay. Then on the Linux side, you're adding Mujina to their existing OS?
Aadhi: Yep. So I basically built everything on top of their existing outsides, like remove the stock binaries, like CGMiner, MMMiner, remove the stock RTOS code. And all those three are replaced by my own code and with Mujina. And that's how I built like everything. Cause I don't want to like mess with U-boot and like all the kernel and stuff yet. I just like want to get like a base structure like working first.
Ryan: Very cool. How does the RTOS core get its program? Does Linux boots first and start the RTOS core somehow? Or is it the other way around? How does that work?
Aadhi: Basically, Linux boots first through a shared file system. The RTOS core is pushed onto the second core and it's launched that way.
Ryan: Okay. Cool. Well, what do you foresee bringing back to mainline Mujina from what you've done? Is that something?
Aadhi: Yeah, go ahead.
Ryan: Oh, yeah, go ahead.
Aadhi: So it's just like, I have to clean up my code a lot. I've messed up like, I kind of like messed with like Mujina's internal stuff a lot, you know, just to get stuff right. And turns out it was like my mistake and not Mujina's side mistake. So I have to go fix that. And there's still a lot of work to do. So once all that is done, I would probably like, you know, create a PR and like kind of like merge it into the, you know, Mujina.
Ryan: Okay. Well, don't hesitate to reach out and talk about, like, we can talk early on about how the best way to get stuff merged in small pieces and architecturally how it would fit in. Yeah, I mean, this is an interesting... Case here because you have those two cores. And so there's like second piece of like, you know, is that even part of Mujina? What would run on that other core? Perhaps not. Or is that, or do we treat it like a driver with firmware built in, you know, where Mujina loads it at start or something like there's several directions you could go with this, I suppose.
Aadhi: Yeah, I'm trying to make my RTOS code into a separate repository so that you can point people towards that and they could fetch the code, update the code from that and run it that way so that Mujina would stay a lot cleaner and the chip protocol would stay in a different repo. Only the IPC mechanism with Mujina would be in the main one.
Ryan: Yeah, that probably makes sense. So that link you put in the discussion here, that's the link to what you're open sourcing so far?
Aadhi: It should be in, wait, I'll send out my repo right now. The repo that's open source. It's called nano Mujina. So basically Mujina for nano.
Ryan: Cool. Can you throw that in that GitHub discussion?
Aadhi: Put the agenda links to.
Ryan: I mean, if you want to, if you're ready for that. Just so we've got a place where that link is recorded. Number 25 here.
Aadhi: 25. Yeah.
Ryan: Just give us a quick update in there. That'd be awesome. Cool. Anybody have questions for Aadhi?
Schnitzel: Yeah, I got a ton. Do you know at all if the Mini is similar?
Aadhi: Yeah, the Mini is almost similar to this, except the chip count is different, and it still uses the same processor. So it should be easy to port this code to the Mini and to the Cube. But porting this code to the Canaan Avalon A15 series is going to be a bit hard because it uses a different processor, the K210. And yeah. OK.
Schnitzel: So because I just got a mini today, and I would love to test this. So you're saying the first step is to do what you did, like get SSH on a firmware and then flash that?
Aadhi: Yeah.
Schnitzel: OK.
Brett: Biggest issue is that the cg miner they open source that I sent in the chat there is only for like the nano series so it should be fine like you should be able to port a very similar thing over but it's just the bigger miners are going to be harder I imagine it'll be relatively easy to port to all the smaller ones though because I think they're all running a similar cg miner cool and then tangential question that ass logic that we see on the picture right now how happy are you with it
Aadhi: Kind of happy. Very happy, actually. It's good. How fast? How fast will it go? With Windows, I can do up to 400 megahertz in, I think, 4-channel mode. And with 8-channel, up to 200. And with 16, I can do 100. But with Linux, you can go up to 800 megahertz. So, yeah, it's really good, actually.
Schnitzel: Worth it for like 80 bucks. Yeah, you bought it on AliExpress?
Aadhi: No, I bought it on Amazon.
Schnitzel: Oh, okay, because right now they're not available on Amazon. But, yeah.
Aadhi: Okay, cool. Thank you.
Ryan: And it's digital only or does it have analog channels?
Aadhi: It is digital only right now. No, there's no analog in this.
Ryan: Cool. Cool. Anybody else? How long does it run outside of the case like that without overheating?
Aadhi: So I've ran it for four or five days continuously. Oh, yeah, without the cover? Yeah, without the cover. So it's just like my fans has a PID control system. So whenever the temperature gets too limited, it would increase the RPM and cool it down. I just usually have a paper on top of the fans covering the spot, like the empty area, so the fans would blow directly on the heat sink.
Ryan: Okay. That makes sense. Well, very cool. Nice work.
Aadhi: Thank you.
Ryan: And I loved your comment about applying for a job.
Aadhi: Oh, I actually did apply for a job. And I got no reply from them.
Ryan: Well, their loss if they don't. I mean, that's just legendary right there. That's the way to do it. That's very funny. Okay. Well, I'm sure we'll see more from that in the future. On to forum and chat activity. I did not read this discussion yet, but I see that there was an addition to this long running thread of someone asked about S19s. Tyler, did you, oh, Tyler's not here. Guess we'll have to read this for ourselves. Just someone asking about tinkering on S19s. So we have our new compatibility matrix with links in the website. That's something maybe I could add to this thread. I guess to that general topic. So yeah, so the big milestones I'm working on here right now is... Merging in some stuff from schnitzel's forks and scott's fork and stuff I've been doing locally so that the mainline driver supports all the bitmain chips at one time so bitx number one s19 I even have an s21 here and then getting easy to use installers wrapped around those so that we can have official supported Mujina installers. That's my big project at the moment, in addition to trying to get to PR reviews and such. So ultimately, that's the answer for someone like this who's looking to run on S19s, right? It's probably not something the average person should try right now until we have our official support ready to go. And then this is stuff from our Telegram channel. Are any of these people here? No. I don't know if anyone wants to comment on any of this. Oh, I will point out, Tyler had a good X Spaces or whatever it's called, jointly with Canaan. He talked about hash rate heating quite a bit. That's worth a listen. There's a link for that there. And then we're experimenting with Buzz. Behind the scenes, right, Schnitzel, at 2.56? It's not public yet.
Schnitzel: It's not public yet, but the idea would be that, yeah, we're going to use that instead of Telegram. I need to check with Tyler when he wants to make this available, but we could also soft launch it across this team or this group.
Ryan: Yeah, so that's sounds like that's going to happen at some point in the near future. So we'll have to be careful about all our different communication channels and be clear about what we want to do on which channel and make sure we don't have too many and clarify what the purpose is of. I guess the buzz will just simply be a replacement for real-time chat. So that means at some point we will drop the Telegram channel, right? Because we don't want to have both.
Schnitzel: Think that's the plan yeah okay but right now right so just for people to understand like there was a lot of other infrastructure things we moved all the we consolidated all the infrastructure in one place so and part of this we just set up a bus so and I mostly made this for Tyler so now he can basically look at it and decide how we're going to use all these tools we also installed like a password sharing and like in a wiki or like a get outline type of thing so there's a lot of different just trying out stuff but yeah boss seems to be right now a very good alternative to like discord yeah I certainly have no love for discord so yeah or telegram honestly
Ryan: Are there mobile apps for Buzz?
Schnitzel: Yes. Yes. You need to pair it with the desktop app, and then you can access it. Okay.
Dylan: That's one of mine. It's still pretty buggy. It's getting better, the mobile app, but it works well enough.
Ryan: Cause that'd be one of my concerns is like, if we commit to a channel like this, it's like, how do I know when someone is trying to get ahold of me? Like, do I always have to be running buzz on my desktop or can I rely on notifications through my phone? That kind of thing. So I'm glad there are mobile apps. I'm sure it'll get better. All right, and then there were a few things from last call that weren't touched in an item above yet. One is sort of talked, again, this was fallout from the cold card discussion, like what are our promises to our users that we want to try to keep cognizant of? I didn't add anything yet, but that's sort of still pending on my to-do list, I guess. We talked about how, you know... Some kind of priority or obviously we wanna make sure we're not burning people's houses down, destroying their equipment, being a vector for infection of a network, stuff like that. I mean, it's easy to look at us and say, oh, we're not a wallet. We're not actually holding any private keys or securing anybody's money, which is true. But there are things that our users, we do have security things to keep in mind and safety things to keep in mind. So we sort of want to articulate what those are at some point. And then I promised that I would either push or push and post a link. Oh, I was going to put, make sure that this chip reference I wrote was reachable from the website somehow. I didn't do that yet, but try to get to that. Oh, Aadhi, you posted your link here. Okay, cool. This is your source for your poll. I'll check that out later. All right. Anyone else want to say hi or have a topic? Susan, I've not met you before or not seen you before in our meetings. If you're welcome to introduce yourself or not, you don't have to. I guess not. That was the Fed. That was the Fed. Yeah. Anybody have any questions or topics? All right. Hearing nothing, I guess we have a short call this week. Hope everybody's doing well. Enjoy the end of your summer. I will see you all online. Thanks, Andy. You too. Bye, everybody. Thanks, Ryan.
Aadhi: Talk to you later.
Ryan: Bye, guys.
Dev-call summaries and transcripts live in the Dev Calls discussion category. Transcript pages here are linked from their discussion threads.