677: We Got a Buzz

Summer routines live or die by how easy they are. And honestly, if something takes too much effort, I'm out. That's why Grooms is my go-to. It's my one daily pack of gummies covering my greens, vitamins and minerals. Plus it has 6 grams of prebiotic fiber, which is more than 2 cups of broccoli. No mixing powders, no giant pills, no hassle. I just rip open the pack and I'm done. They taste good and they make it easy to stay on top of my health, even when life gets busy. Save up to 52% with the code PODCAST at Grooms.co. That's code PODCAST at G-R-U-N-S dot C-O. Hello friends and welcome back to your weekly Linux talk show. My name is Chris. My name is Wes. And my name is Brent. Hello gentlemen. Well, coming up on the show today, has the best use case for Noster finally been discovered and it might not be what you're thinking? We're going to take a look at Buzz, the new tool that is sort of like multiplayer for agentic assistant work. Then we're going to round the show out with some great boosts, some pics and a lot more. So before we get to that, we got to start by saying time appropriate greetings to our virtual lug. Hello, Mumble Room. Thank you. Hello, Mumble Room. Hello, hello. Thank you for joining us even when we're remote. Yes. Hello up here from the beautiful, smoky BC. We're up in Brent's pad this week. Delicious. Hanging out, enjoying ourselves some wildfire smoke and just extremely grateful for our friends over at Defined Networking. And I think you're going to love it. Go to Defined.net slash unplugged and meet Managed Nebula from Defined Networking. A decentralized VPN built on the open source Nebula platform that is awesome and we're using the crap out of it. Nebula, it was originally created to connect Slack's global infrastructure. Could you imagine? Could you imagine? Could you imagine? I tried to imagine what it was like before they had Nebula. Oh. And the kind of data that they have to protect. I mean, it's just absolutely bonkers. And it has to be resilient. It has to scale. It has to be absolutely bonkers fast. That's what Slack needed. And that's what Nebula delivered. And you can get it now, right now, Defined.net slash unplugged for 100 hosts free. No credit card required. They also include a lighthouse now to get you going right away, but you can self-host your own lighthouse so you have complete real control over your mesh network. No tech company between you and your infrastructure. No big tech login required. Keys is how it works. It's so elegant. Check it out at Defined.net slash unplugged. And a big thank you to Defined for sponsoring the unplugged program. Well, we got no housekeeping, but we'd love to know what you think of the remote show audio. And if you watch the video and any of it comes together at all, we have no idea. So you can go to boost.jupiterbroadcasting.com and let us know your thoughts. Or you can send us an email like Mars did. Hey guys, y'all meet at Nostar wondering if you've heard of Buzz, which seems to be a self-hostable Slack alternative that also enables human and agent collaboration. You can check out their code repogit hub.com slash block slash buzz or the main website buzz.xyz. While the tech does seem cool and the back end is written in rust. Oh, is it now? Yes, it is. We didn't notice that. Oh no, we didn't. No. I find some of the vision docs in their repo to be really fascinating. I think Buzz is actually started by Jack Dorsey or at least his block organization. So not sure how I feel about that, but if it truly supports sovereignty and it functions and has features and they do what it says on the tin, then it might be worthwhile to play around with. Keep up the wonderful work on the podcast. Yours truly, Mars. Mars, you asked the right question. Does it actually deliver what it says on the tin? Or is this just a big joke? So Buzz is also kind of maybe considered a bit of a Slack killer. I think that's underselling what it does, but it includes a lot of the Slack-like collaboration and chat features. And so if depending on your workflow, this could be very, very useful. And it's Apache 2.0 license, so it is open source. And like Mars said, they've put it up on GitHub and it is moving really, really fast these days. One of the projects that's actively getting commits pushed to it while we cover it on the show. Yeah. Is it right now? It is, isn't it? I mean, the Colonel gets that sometimes. 26 minutes ago as we record on a Sunday. So they describe it as a self-hostable workspace where humans and AI agents share the same rooms. And we'll try to explain what that really means here in a minute. A Buzz community is the workspace where a user reaches by URL. There's a Noster relay on the backend, which we'll talk about more, that sort of acts as a central server. Every message, reaction, workflow step, review approval, and get event, talk more about that, is assigned event in one log. Same shape, same identity, same model, same audit trail. And in practice, it just kind of feels like a team workspace with a chat app. But under the hood, every event is logged and everything has a cryptographic signature, which is very useful. And we'll talk about that as well. Yeah. Part of the value idea here is, okay, you have to do a lot of work if you say have something like Slack to bring in maybe helpers or automation or the results from, you know, your build system when you put a new update or someone opens a new PR and needs a review and that has to be surfaced. And all of those things that we end up dragging in there. Well, what if you just had them in there from the start in a system that was designed to know about all of them and that was built on top of Noster, which is essentially just JSON with a lot of cryptography on top so that you have an audited log of all of the events that are flowing. Yes. And the architecture is such that it is actually Noster first. So what that means is, like in the Slack workflow or a Teams workflow, we've also experimented with Mattermost. They generally have like a bot API and you go create a bot account and you go set up an API for your bot, and then you go to your whatever your bot is and you put the API in there, you put a URL in there and get it all connected. And you can do a few things in your Slack or Mattermost or whatever it might be. That's not how Buzz works. Since Buzz is Noster first and everything is done as a Noster event and there's a CLI as well, everything can be managed and set up by agents like they can humans. They essentially share some of the same privileges and workflow capabilities in Buzz. And I think that's particularly a big advantage for Buzz because it means that you can tell, you can task your agent, go set up a project room for this project. And it's linked to this GitHub project and bring these five people in with read-only permission. And the agent just goes and does all of that and sends out the invites instead of you having to go create the room, invite an agent in. It's just a more natural process. And it means everything is the same. All you're doing with the fancy Buzz desktop client, which we can talk about because that's kind of the main way you experience, is sending signed events to the Noster relay. And that's all the agent does either. So if you want to audit what the agent's doing, you're also getting to audit what the human's doing. And it's the same thing and it's not two separate systems and it's all just right there. And it's building on top of Noster, which is essentially like you have this relay and you can post events to it. And it's just a super simple JSON data structure. The wire protocol is NIP01. Events have six fields. The ID, the pub key that corresponds to your identity, which is your private key, kind, tags, content, and the signature. And the kind integer is basically the way you dispatch stuff. So if you want a new feature, you make a new kind number. And then of course, it's all connected over WebSocket and it lets you do things like subscribe to queries. So you can kind of ask like, hey, give me events that match this shape. I want to be told when those come in. And that lets you form sort of this two-way communication. And then Buzz on top of this defines 80 plus different event kinds across some of the standard ranges and some of their own custom ranges. And that means again, like you need to know the semantics of what Buzz's stuff is. But beyond that, the only thing you need to really know if you want to play in the system is how Noster works. Yeah, I think the advantage to it being Noster is a couple of primary things. It's an open protocol. So instead of it being based on a proprietary backend or whatever, it's a fully open protocol that's documented. Like Wes said, the way they're doing things is via NIPs. And a NIP is a Noster improvement proposal. And so you can add functionality in an open source way to Noster through these NIPs. And then people can determine if they want to implement them at the client side or not and at the relay side. And so they haven't had to like concoct any kind of like proprietary way of doing this. They've been able to just leverage an open network. So that's the first thing. The other thing that I think really stands out is everybody that participates in a Noster network in the protocol gets an NPUB and an NSEC. They get a public key and a private key. And everything gets signed with this. You probably listeners are probably at least loosely familiar with, you know, this concept. But imagine now applying that at the agent level. So now you have a cryptographic identity for every agent that's working. So you can actually tie it back to a specific agent and cryptographically verify it was that agent or human. And that, because it's just a public private key pair is portable. So if later on you build up a cooler agent that has way more superpowers, but you want to use that identity, you can. And Noster makes it really easy to spin up a new identity like you can, you know, just a new cryptographic public key and private key. And so you could create a new identity for another bot. And you can verify they really are the people that the bot claims it is. And I think that isn't a problem that has been solved yet in any other way with agents other than like, you know, APIs and KYC that Anthropic and OpenAI, I suppose, would run. So this is a distributed open source way where everybody involved and every action involved, every git commit and everything has a public private key signing that can be audited and traced, which adds to the reliability and troubleshooting of these things. So I think that's one of the bigger innovations Buzz is bringing by using Noster. And that's why I kind of at the beginning, I was like, this might be one of Noster's best uses yet. Ironically, it's not doing it with a distributed relay. See, typically with a Noster client, the relay can be many, you can you could just substitute any relay for any other relay for the most part, if you wanted to. But in this case, you're using one specific relay, you can self host that relay, but you're using one specific relay. Well, why do you think they made that design decision? Because the default Noster, wouldn't that work too? Wes could probably explain it better than me, but there's just certain jobs that the relay is doing. You can have it executing web hooks and doing scheduled jobs, it's going to be, it's holding more information than a typical Noster relay would be by default. Okay. Was that a fair assessment, you think, Wes? Yeah, I think that's probably about right. And then you can do more integrations, like in particular, when we talk about the Git stuff, that's something that's happening here on the back end. So it is, it is in one sense, a standard relay, but it also offers some more stuff on the side. Yeah. And I think they are exploring how to do more multi member communities. But for this first thing, it's sort of just targeting like, the community is the relay. Yeah. Is there also a challenge with these NIPs in that, like, it might not be adopted by... It doesn't really matter. It doesn't really matter. No, it doesn't? Really? No, because they're implementing their own client, right? So they're implementing their own relay and their own client. And so as long as they support it, it's fine. And if you want to build your own, you just, the NIP is documented. Yeah. Okay. So that, I think the Noster aspect, is there anything else you want to talk about Noster before I move on from that? I mean, we're kind of come back to when we talk about bringing our own bots, but... Yeah, I think that's fine for now. Okay. So then the other thing that I think Buzz is bringing early on, and we should mention this is in, this is an early development, and they're probably a pretty big category of people it's not ready for yet. But one of the things that is going to probably be attractive to folks in our audience is they've integrated shared compute. And it's done really, really well. So I think it's one of their more ambitious ideas. And anybody that has the Buzz client in a community, in a workspace, can go into a section that's basically the compute section of the app. And the Buzz app will review your hardware and determine which model is the, which open source model is best going to run on your machine. Jeff needs this. Jeff needs this. And for me, it selected, first the default was Quinn 2.5, but it said actually Gemma 4 is going to work better on your machine. And I think we should allocate 48 gigabytes of virtual RAM, of your video RAM. So I say, okay, and I turn that box on. And what happens now is any members of my Buzz community can access that shared compute, and they can opt in their compute as well if they want. And that to me seems to be like the missing piece that we have been asking for on this show in particular. Sure have been. It's so great. No API keys, no cloud bill. The relay handles the trust boundary. It handles connecting. That's another thing that relay does that probably the standard relay wouldn't do. And so you get a compute mesh entirely desktop client side. That's so cool. Yeah, the discovery just, the part that relay really does is a member's mesh LLM node publishes a special kind, a bookmark set event with a Buzz mesh status tag, content is JSON. And then basically just tells it like, look, this is what I'm offering. I have this model. Here's how to get to it. And then when a consumer needs a model, it can query the relay for fresh mesh status events from the current members, verifies owner binding, that kind of all the security stuff. And then basically you always have sort of a proxy local open AI compatible endpoint from the Buzz desktop thing. And then when you connect, then that just basically then starts forwarding to whichever of the local options over the mesh or the remote ones over the mesh that you want to use. So from your client side, you could just point the same thing at it and then make use of the different models that are provided by you on the mesh, which is pretty cool. That's so cool. Mars mentioned this in his email to us. And I know Wes, you noticed this too, is they have a pretty well flushed out vision for the project and not like computer vision. I mean, like idea of where it's going to go in the future and kind of the full idea. So even though they're not there yet, it's because it's early days, kind of the full idea of like what you could expect this to be. And one of the things they outlined is there's these different surfaces, right? You have your home surface stream, form, DMS agents, workflows and search and all that kind of stuff. Yeah, here's how they put it. One community is your entire workspace. Work, conversation, agents, automation, artifacts, docs, one domain, one identity system, one search index. Myproject.com in a browser shows your repos. Git clone works. Open the Buzz app and you're in the channels where the work happens. No GitHub, no Discord, no stitching five services together. The project lives in one place and that place is yours. Run your own relay for one community or let an operator host thousands on shared infrastructure. Same open source code base, same URL is your workspace experience. Either way. And one of the ideas, right, is that you're working with the agents in tandem on projects. And so you're bringing in Git issues. The agent is tracking that and you're having, like you would, a conversation with a coworker. And I think maybe we should touch a little bit on how they kind of invasion Git and Git like workflows being integrated because I don't know if it's fully there yet. Yeah, we haven't tried this part and you might need to have your own relay. So right now, we've been making progress towards it, but we have not hosted our own relay yet just because this is all super new. So we want to try it out. So we're trying the hosted relay that you get by default. But there is Git integration. So firstly, it's built on top of S3. So you provide it in S3 as the backend storage for it. Objects are stored as content addressed packs and a manifest JSON that tracks refs and the pack list. No database holding Git objects. And then they do sort of a NIP 98 hijack. Essentially, they use the Git credential helper to plug in NOSTER as the identity layer. So the helper signs a NOSTER event over the repo URL instead of a password. The relay verifies the NOSTER SIG. That's the entire auth layer. No SSH keys, no tokens, no OAuth. That is such a brilliant use of NOSTER once again. Just assign JSON event. It becomes the identity layer everywhere. And then the NOSTER events themselves basically are the feed that builds the UI layer. So successful Git push emits kind 3618 into the buzz channel. Patches, PRs, issues are all just NOSTER events too. The channel timeline is the code review surface. And then there's also some policy stuff like you can do protection rules and various other things. But it's all basically tried to be plumbed on top of S3 and NOSTER. And then it's sort of an HTTP server on top. So and of course, if you use their hosted version, they just set all that up for you. But if you want to self-host it, you got to provide the S3 backend. But to the NOSTER as the identity layer there, NOSTER as the authentication layer there. And what's crucial is it's Git's standard smart HTTP protocol. The credential helper just swaps the password for a NOSTER event. Server swaps the file system for S3 and CAS. Git itself doesn't know anything changed. And that was part of the goals, right? If you're going to be replacing something like, hey, we also do code hosting, you kind of need it to work with mostly standard tools. That's really elegant. What I was able to do too, is I was able to bring over my NSEC identity to Buzz. So when I logged into our Buzz community, it was the same identity I have on NOSTER. So you can verify my key across multiple platforms. And as you know, it's really me in there. And I didn't have to create a new account. I didn't have to create a new profile. I didn't even have to set a profile picture. I just signed in with my NSEC and it pulled that from the NOSTER network. And I'm using that same identity now across five apps. It's so awesome. Which also means there is some multi-relay support already because that stuff was synced to other realists. Yeah, true, true. So I think the Git integration is particularly useful. The way they foresee these agents interacting with the external world is going to be through MCPs. And when you install Buzz, they kind of intend for you to use it as an agent orchestration platform itself, sort of like an OpenClaw or a Hermes. And then you can tie it to an API key for the compute, or you can use Codex or Cloud Desktop or whatever. There's a couple options there. And it acts as the agentic harness. And then they foresee you using MCPs and whatnot to interact with the external world and Git and all this kind of stuff is integrated. And the idea would be that if you were a business or a small team and you didn't already have, I think, an OpenClaw or a Hermes setup today, you would deploy Buzz and it would come with a handful of agents. You could create more. Yeah. And then we kind of tried it a little bit from there. We took two paths. One is you can do what's called a Buzz agent, where it has its own subprocess that spawns as the agent's runtime and loop. And it directly goes and talks to, say, an OpenAI-compatible endpoint that you put in there. But the other one is it can launch a different harness via ACP, sort of, you know, Cloud Code or Codex or OpenCode or something. And that can also be sort of how you run the agent, which we tried a little bit with your setup. Yeah. So do you think there's any other basics we've talked about before we talked about integration and what we try to do with it? Is there any other high-level stuff around Buzz? I mean, people can always ask if they have questions, but... Well, let's talk about, like, installation, because you had to wrap it a little bit for our own purposes. Yeah, true. So out of the box, I think they have, like, a Mac app. I don't know about a Windows app. Mobile is just shipping now, so it's moving really fast. Obviously, we wanted to try it on Linux, and they do have an app image and a dev. I spent a little time... I assume those will probably work pretty widely, and they've already made improvements to some of the app image and stuff to make, like, the GStreamer libraries that bundles a little more compatible on a wider class of distros, which is maybe partly what I was running into. I tried getting, you know, for Nix OS, and so I spent a little time trying to get that to work. Ultimately, it just became easier to do some patch elfing on the files in the dev, so I was able to make a flake for that. That builds the Buzz desktop app, which is Atari app with TypeScript UI. Atari is, like, this Rust runtime electron alternative that is, frankly, a lot nicer, actually. And then it also gives you the Buzz CLI, which is, like, JSON output primarily, really intended to support agentic use. And then on the flip side, you could also run the Relay, which is the Rust application, which we're not doing yet, and it's a separate package. Mm-hmm. There you go. Although we'll probably play around with running a Relay. And it's moving fast, as you mentioned. Very much. Super, super fast. I'm already one release behind on the desktop app, and I built it twice yesterday. Yeah. Right. There you go. So I think that's... Those are some good basics. I do feel like there's... It's such a big topic, and it is moving so fast that I think there's some more stuff to cover. But one of the things I wanted to mention is we're going to attempt to share a invite link for our Buzz community. We created a Jupyter Colony Buzz community, and we may have figured out a way to invite you where I don't have to individually add your endpubs. It's experimental. Yeah. So it might not work. That is one area I was looking at a little before the show, and if we do ever eventually run our own Relay, there is an environment variable you can set that just says, like, not even the method we're doing, like, just have Addit come join the community. So that could be a future. Not sure. Right. I don't think we can do that with the hosted Relay. But I think we do have an invite link that is valid for 30 days where I don't have to add their endpub. And help us test it, because we've already made accounts. Yeah. We've made accounts. We're in there in the Buzz community, and we're going to be playing with it. I mean, we figure why not kick the tires on their hosted setup, figure out what doesn't work, and then we'll run our own eventually. After we've learned a few last things. Because I actually think there could be real use for JB here. We don't really have a particular agentic harness picked out for JB. And we would really love to find something like Slack that isn't Slack. So this sort of solves both of those problems. And yes, we have a public Jupyter Broadcasting GitHub. But for a lot of our internal tooling, we've been considering a self-hosted GitLab or 4G or something. And maybe this would help us with that as well. But I think the question becomes that if you've already been playing with agents, or if you want to run a different agentic harness, like an OpenClaw or a Hermes, how do you integrate that with something like Buzz? Since Buzz is trying to both be the agentic harness and also the collaboration space, you want to bring your existing agents in if you have them. That right now is a bit of a mixed bag. And we tried to get it working. And we'll tell you how it went next. Well, I'll admit yesterday, while you two were heads down working on all this stuff, I was packing some boxes. So I don't quite know how all this went. Yeah, and moving motorcycles around. Well, that's true. That was the fun part. So Wes, you ran into, I'm sure, some problems. Some things went well. How did it go yesterday? Yeah, well, okay. So we got a few default agents set up, right? We got that kind of baked. I put in an OpenRouter API key. And so we got one agent going that could do that. And then Chris had it hooked up to Codex. And so we had another agent like that. We already started running into some bugs. For instance, right now, we can't use each other's agent. Oh. We can see them. They're in the same channels and all that, right? Because it's all just Nostr. But there's a bug in the client. And maybe it's fixed. Again, I'm one version behind at this point. But I think that's still open. Where it won't... When you do tagging, it's just another piece. It's like a tag that goes in the Nostr event. So there is a difference between if the UI highlights it as like a structured little tag versus if you just type at username or whatever. And so because it does that, it tries to, we can't add each other's bots. And that's how you talk to them. So already running into some problems. And it's sort of, you know, it's early project. And I think it was really inspired by something, you know, it's by folks that are doing a lot of agentic development and maybe using something like OpenCode or CloudCode. And we've talked a little bit about this. It's kind of a context shift, a mind shift between if you're running something like Hermes or OpenClaw. Yeah. Sort of flips the model a little bit. Yeah. And so right now, Buzz is really optimized for like, either it runs it directly or it launches your harness for you as an ACP. Right. So it'll launch OpenCode as an ACP and it can use it. But that's not really super compatible with like, I already have my own whole NixOS server that maintains itself as a Hermes instance. Like, I want to use that. I mean, I might use some of these other bots too. And that's where Chris is talking about, like, there's a difference between if you have a bunch of existing infrastructure or if you can kind of start fresh. Yeah. Yeah. If you're already into building your own agentic system and you have been using them for a bit, it's a little trickier to integrate them with Buzz at this point. It sounds like every couple months, that's a disadvantage. Yeah. Although it seems to be that native Hermes integration, or at least an initial form of it, is landing upstream in Buzz. Yeah, they're working on it. I think it's making it so like, it becomes ACP aware. So you could use Hermes ACP with it. In our testing so far though, there has been some limitations when using the ACP. It hasn't been as useful as just setting up the CLI or trying to go NOSTER directly. Yeah, for sure. And it's still kind of built around this notion of like, the Buzz desktop. Because the relay is really pretty stateless minus like the Git stuff, right? Yeah. So like your desktop is going to be doing a lot of this stuff, which means then you're kind of, it's all doing the desktop and then it's launching more services under that. And all the MCP stuff is like standard I own only. So it's really not built with much sort of networking in mind. But you know what is? NOSTER. And that's where it's sort of like, okay, the direct Buzz integrations, we did get it working with the CLI. That was working pretty well. So like you just export your NSEC and then you can set the right relay URL and you run the Buzz CLI and you can list channels, you can get events and you can send messages and all that. So I was able to trigger my bot or Chris's bot via the CLI because it doesn't have that bug. You can tell it exactly who to like at mention or whatever. But that's not really the experience we were going for. What we wanted, right? Because we wanted like my Hermes to be able to participate in Buzz as its own thing. Like as a full, just like me. Right. And so that was kind of our goal. And what's great about that is the root of that is NOSTER because it's all gated on the NOSTER private key. It is the core of the architecture, right? Like it's not an API. It is built around NOSTER. So if your application or agent can speak in the NOSTER protocol, you can talk to Buzz. And so this is where it's so great because I could have a bot help, right? So like I generated the new NPUB and NSEC for it. But then because I already had my own NSEC that you had added for me with my regular Buzz account and I was an admin, the relay would let me sign events to make admin updates, right? And so what I needed to do then is I could take my new bot, you know, my Hermes's new key, and then add that to the relay's relay members table, which is a kind 90-30 admin event. And that kind of controls, if you don't have it wide open, that controls who's allowed in. And then it could just add it to channels. It could set up, you know, set its nice screen name, set its user profile, because all of those are just signed events to the relay. So that got us an identity. But next, you know, we actually needed to be able to talk to this thing. And so one, we did investigate a few different options here, right? We wanted to take the easiest path and the fastest path because we were both trying to pack and play the show. Yeah, yeah. And so one thing is we did see that you could have workflows. So you could set it like, hey, when an event comes in, like that looks like this, the tags, this user has this in the reply or whatever, run this, you know, it's kind of like a YAML style workflow, run this thing, send a webhook. It had webhooks. It has scheduled events. You can set up crons in there. So we kind of got some of that working. But again, we weren't running our own relay. And this is where I really think we could probably do more. But I got the crons working. But when I tried to do the like at mention thing, the webhooks were just never final. So I don't know if that's just a bug, or it's turned off for the hosted thing. So they just don't have to smash the internet with a bunch of webhooks. And they're growing. The adoption they're seeing right now is bonkers. I can imagine the fact that the relays are even up and running is impressive. Yeah. So we were kind of hoping you could get a first version of this where like the webhook would wake Hermes webhook integration, and then the bot could wake up and it would have the buzz CLI and then it could reply. Yeah. And that was kind of like a poor man's version. Yeah. Because you're depending on this thing, you know, the webhook firing, then it's got to fire up the CLI first and the LLM's got to interpret what it gets from the CLI. There's a lot of bits and pieces in there. So what we ultimately did is we built ourselves basically first class buzz support or as close as we could get, right? So the data flow is a buzz user. Let's say I'm trying to tag my bot, right? We got my bot added in there. So I tagged my bot, ask it for some advice. I asked it, for example, to check if Linux Unplugged was live right now. That goes to the Nostra Relay, fans out to anyone that's subscribed to that kind of event, which is like updates in the channel. And then I have a buzz bridge running, and that's a little Python sidecar system D service. It connects to the Relay via WebSocket, which is how Nostra works. It authenticates as my Hermes bot, and then it filters for mentions of its name in the channel. And then anytime it gets a match, it forwards that to a little web server I'm running in a Hermes adapter plugin that's running. So then it receives the message, creates a structured event, dispatches to Hermes agent pipeline, and then Hermes processes and returns a text response. And then we send that back to the bridge, which is able to sort of do all the Nostra stuff, sign it correctly, and publish it to the Relay. And then so from the Hermes side, it basically just looks exactly like how Telegram looks. So you can have sessions on Buzz, and you can have sessions on Telegram. It's just another, it's another platform it connects to. Exactly. Ah. It's not perfect. Like some of the tool call metadata is ended up in the general channel instead of like the thread that I was asking it in or that kind of thing. But I mean, it's working. I mean, the project might want to take a look at this. Hermes, you guys should take a look at this. Just this is just native Nostra integration, and it's better than the ACP. And you might not need to really have like, I have it in two pieces where we have this like bridge server and then the part, partly because it just made it simpler and it was faster. Instead of having to rebuild Hermes a bunch, I could just iterate on the bridge and it's just like an HHP protocol. But if you wanted to, there's nothing stopping you from having a Hermes plugin that just does all of that in one little box. So I think there's definitely a lot of potential here. And there's no, because it is not some custom thing on some custom protocol, because it is just Nostra and libraries exist for this, it is all open to build on. We don't have to have a Buzz SDK to make any progress. This is the bit that we should have said at the top because people that aren't into this are probably tuned out by now. But what will be missed by our community is this is the most Linux friendly Slack killer that's ever been invented. And it has the most DevOps workflow kind of feature set that's ever been implemented in one of these. It's super transparent. The APIs are all out there. There's standard libraries to work with them. The entire entirety of the Nostra ecosystem is open source. Every NIP is open source that they're using. And Buzz is Apache 2.0 open source. And everything is an open protocol. You can build simple clients in really just minutes. There's lots of example code out there for Nostra clients as well. We as a free software community have, we are so foreign to how much, how well this is built for us that we don't even recognize it. We don't even recognize it. We're so unused to it. And when it happens, we don't see it. And it's so composable, right? Like you don't, you don't have to have a Slack API. You can just no permissions needed. Right. Like you could, I mean, you might need, depending on how the relay set up, you might need to author the relay or whatever. But like you can just subscribe to whatever events you want. I only care about Git PRs. I only care about messages from Chris. I don't need a full client. I can just have a Python script that does that and triggers whatever downstream automation I want. Or creates a dashboard. Totally. The dashboard could be the consumer, not the chat client. And so when you think about this is your projects and your infrastructure and your, all of this, like it really does matter that you can self-host this and that it is using an open protocol and standards. It matters more than I think we wanted to admit because we were so stuck with such bad options before. But now you've got a central spot where the agent and the human and everything is tracked and they can work together. It's just so fantastic. And, you know, we had been kind of struggling. Like we've been Nostra curious. You've played around with it. I think we've all played a little bit with it. You know, Fountain has support. But we hadn't really crossed a line yet to like, okay, I can see how there could be compounding returns when you have a relay. But like we didn't, there was no killer app yet that we'd really pushed us to have the relay. And this could be that. And then you could really see how you could build a lot more on top. Yeah. You just keep building. And once you have that as an identity layer, why wouldn't we build it into our other applications? Even our internal tooling? Why not? If we've all got MPubs and NSACs and whatnot, it'd be an easy way for us to authenticate our internal tooling. And then we don't have to rely on some GitHub OAuth or whatever random third-party system. No. Yeah, it's decentralized. But then you'd know it was me trolling you. Yeah, you better sign any updates you make to my default text editor. Right. I mean, as excited I am about Buzz now, I think there could be potential for us to use it at JB. I do think for most people, it's maybe worth waiting a little bit just because of the speed of development. And if you've already got something set up, if you're brand new to this concept, this actually could be a pretty nice way to get started. They make it really easy. The primary vector is you just download the desktop app and go through the signup workflow. At some point, you're going to have to figure out how you want to do compute, but they'll help you with that as well. I mean, it really is bringing so many different tools into one place that if you haven't yet experimented with an agent platform, Buzz could be a good way to go. And at least you're using an open source one. It's backed by a company like Block that's got funding and they're going to be around for a while. The other thing I would say from my experience is you don't necessarily need to even know that there's Nostra on the backend. No, absolutely. As a regular user, you need an NPUB, right? But it'll help you generate them. Exactly. And then other than that, it just looks like any other productivity chat app for teams and stuff. Yeah, we're focused on the Nostra part because it's like finally somebody built a web browser on this hypertext transport protocol standard that we're really excited about. And look, this cool web browser that's using this hypertext transport protocol, I think it's got a lot of potential. Aren't you guys excited? It's finally happening. Yeah, but what can we do with it? But like the average web user today doesn't give a crap that the web uses HTTP. It doesn't matter at all. Doesn't matter. That's the same here. But as nerds, we're excited about the fact that Nostra is actually getting used in a really elegant, useful way here. It's not truly distributed, but it is distributed in the sense that you can self-host your own relay. And the beautiful thing is like it's built for nerds, but it's also just built for everybody. Oh yeah, it's a beautiful, simple UI. Yeah, they did an amazing job and they're only four months in, which is really impressive. It is still new there. Like the UIs keep getting updates. I'm seeing that in the commits and like there's some stuff you can do like via YAML or the config file and you might want to because some of the like editing settings can be a little fussy right now, that kind of thing. But that's just going to be the polish layer, right? Yeah, yeah. And there may be some things that are just simpler to fire off right now via the CLI that aren't exposed in the GUI. Totally. They'll probably add, but yeah. And the mobile apps are just shipping for Android and iOS and they're looking good, but early. You know, it's good, but early. So do we have an URL we can share with the community for joining our crazy buzz system? Yeah, it's not, it's not super simple for the long invite, but the community URL is colony.communities.buzz.xyz. And we'll have an invite link to get you access in the show notes, but the community itself is colony.communities.buzz.xyz. And that's self-hosted or that's hosted on their relay. We may host one eventually, or maybe we'll host our private one. I could imagine keeping our public community buzz if it stuck around on a public relay on their services. And then our internal one would be a self-hosted. Totally. Something like that. Kind of like how we probably should have done Matrix. Yeah. Learning. Holy jeez, while we've been busy this week, some boosts came in. Hmm. And now it is time for le boost. We have quite a baller boost here. Kern sent us in a, what is this, a mighty row of ducks? Oh. 222,222 cents. Hey rich lobster! Things are looking up for all my duck. Wow, thank you. This was also sent via our web boost, just putting that in there. Okay. He says, not really giving back on a particular episode, just trying to give the show a little love. Oh, thank you. Thank you. Always welcome. Love is appreciated. Send it back your way. Well, Greg, the lawyer comes in with 150,000 cents. All right. I thought that would your kind of... Boost! Boost! Boost and end us aboard the trip to Canada. Aha! Did you make it? We did! We did. Right, yeah. I'm on the verge of joining the ranks of Tesla nation. I look forward to trading stories. Greg, the lawyer. Wow. It's, you know, I don't like to talk about it because I don't like becoming sound like I'm a salesperson because I don't, you know, but the self-driving will change your life. You can't hear. The car drove us all the way from my farm to here. I overtook twice, not for safety reasons, but just because I wanted to pass a guy. For unsafety reasons. Yeah, for the opposite of safety reasons. Speed reasons. But otherwise, the car drove us. So for probably a total of 30 seconds, I drove. Through the mountains, through long hours of no connectivity. Yeah, hours of no cell signal driving and navigating just fine. And the energy you get versus a 12-hour drive where you do all the driving is, it's incredible, right? Like you still have the energy to set up your campsite, interact with the people you're coming to see and say hi to them. Like in the past, when I'd take the RV, I'd show up and I'd be like, Hadiyah, can you just hold people off for 10 minutes so I can just have 10 minutes of quiet to get my shit together? Because it's tough. It's tough when you drive a rig like that for 12 hours. But in the car, it drives itself that's climate controlled. It's so easy, Greg. You're going to love it. You're going to love it, Greg. Tell us how it goes, okay? Greg, make sure you use Chris's referral code. I should have. I should do it. Yeah. Greg, I probably have one, Greg. I don't know. Is that really a thing? Probably it is. I don't know. WhomeverWiz comes in with a row of McDucks. What I'm looking for is a back-end database with structured data managed by an LM. A series of wiki pages in addition to adding their own natural language relationships and semantic info. It will then dynamically be referenced and reference the structured data when appropriate. What you got? That's a challenge. Yeah. I don't know if I have that, but I want that now. Isn't that kind of log sack in a way? Yeah. It's closed. I don't know if it's exactly that with the wiki pages, but it does do a lot of nice stuff with references in the graph. I don't know. All right. And it is now using a back-end database and tons of structured data. It's getting there. Including a nice query language. Mm-hmm. Mm-hmm. Yeah. Patient tech in our chat room says, wait, you guys went without a follow, without a map that we could follow? That's true. Yeah. We didn't do a tracker. Two reasons. It wasn't a race. Brenda was already here. But the other reason is a ginormous portion of our drive does not have cells in. For sure. So we were just out of it. Well, weren't you getting a Starlink? Didn't that? Shut up. Shut up. That's too soon. Gene Bean sends in a row of ducks. Saying, for Linux Unplugged 675, have you played with the BBS on MeshTastic yet? Is this a thing? Apparently. Gene does not send us a link. Gene. I mean, I see a Reddit thread introducing, I think this kind of rings a bell, actually. Introducing MeshBBS, bringing old-school open-source BBS fun to MeshTastic. This is 10 months ago. I've been working on a project called MeshBBS. I think this was sent in. This is ringing a bell now. And I think it's ready to share. MeshBBS is a lightweight, text-based bulletin board system. Yeah, we know what PBS is. Okay. Gene, you may have just created... Gene strikes again. You may have just created a little project, Gene. How awesome would it be if we could BBS over MeshTastic? Jeff, get on it. Yeah, PJ. Jeez. Jeez. Brian from Boise. Thank you, Gene. Brian from Boise comes in with 4,444 satushers. This old duck still got it. Our family took a trip, our first multi-state EV road trip last week. We stopped in La Grande, Oregon at Electrify America Station with chargers labeled for 150 kilowatt and 350 kilowatt. They maxed out at 50 and 80. Screen wouldn't respond, so I had to call support. Oh, man. When I went down the road to a charge point station and started charging through the Kia app, I got decent speeds, and then we were on our way. I took a quick trip to Portland, or I'm sorry, Port Townsend, Washington, where the level 3 charging was fast enough. Scanned a QR code, paid directly in the browser, no account needed. Okay. Nice. So on our ride out, every stop was a different vendor of EV. That's right. So... That is painful. Sampling them all, baby. And ironically, the only one we had a problem... One did overheat, but it was like 113 degrees Fahrenheit outside. That's not that hot. I know, but it did. They should be designed for this. Also, the power hose was totally screwed up. We were able to just move to another one in the lot and charge. So not so bad. But the big embarrassment of the trip was Rivian. Rivian, for non-Rivian owners, was such a facepalm. Their recent app UI update actually removes the ability to do charging. There's nothing in the UI to start a charge. I know that sounds like it can't possibly be true, but it is. Yeah. Brian, it was so bad because we were out there in 113 degrees and we cannot figure out this app. And we think maybe we have like heat delirium or something. Like there's just no way that Rivian, an actual company that builds cars... Nice car. I mean, we've seen in lights in Rivian. It's crazy. It was crazy. And the screen is like impossible to read in the glaring sunlight. Yeah. It's so bad. So bad. So like when you had a chance to go to a supercharger, it was like, oh, we'll go even out of our way if we had to. It was because you just know you're going to plug in. It's going to work. This was wild. But other than that, it was actually really good. And even with that, we still had sufficient coverage where we were never, ever, ever, ever in like the red. We were always plenty of charge. Yeah. We had built out a whole plan of like, try to charge here. We expect to be at this depleted charge level when we get to the next stop. And we were almost always way above that. The situation is, is that you charge so fast these days that it really isn't a big deal to just put a little extra buffer on there. So we always had extra buffer. So you didn't have any like distance anxiety and all of that? Never. Never once. More just compatibility with the charger anxiety? Yeah. Okay. Interesting. But even when that charger didn't work, because we had built up such a buffer, we just moved on to the next one. Yeah. Wes, you want to take Dan? Yeah. Dan comes in with $100. Oh! This is a tasty burger. Since Linux Unplugged is having revenue problems, I'd throw a few bucks extra. Thank you. Can I advertise? Oh. Yes. Once a month, I'll tell you my favorite floss. This month, try out Street Complete for Android. It's a gamified way to make OpenStreetMap better. Street Complete. One more way to ditch Google. I like that it's gamified. I do too. That's cool. Make it fun. Honestly, I don't know why more people don't boost in and shout out. Like a business or a project they love. It just seems like a brilliant use of the medium to me. So, absolutely do it. So, Street Complete at StreetComplete.app. Help improve OpenStreetMap with Street Complete. This app finds missing map data in your vicinity and displays it on a map as a quest. Solve each quest by visiting the location on the map and answering simple questions to update the map. The info you enter is directly added to OpenStreetMap in your name without the need to use another editor. That's awesome. I have to say, I used this app. Oh. You've been hiding it from us. Maybe 10 years ago. Something like that. A super long time ago because I was trying to push for better maps on Android. I mean, we're still... Yeah. We can do better. Well, we need maps. We need better maps outside of Google. Yes. And at that time, the OpenStreetMap data for North America was so-so compared to Europe. Yeah. Right? Because it was quite a bit more popular there. So I was trying to do my part. And I will have to say, it was a great app back then. I couldn't even imagine how great it is now. It's probably pretty awesome. So I'm going to give this a shot. Great. Senior Smile comes in with a member boost. I hate building PCs. Now that Brent has dropped plain text accounting, I want an entire segment on it. I used... Oh. Senior Smile. I have a soft spot. I used Microsoft Money before in 2005. Oh, my goodness. Microsoft Money. I forgot about that. Early Money was so much better than Quicken back then. I mean, for my use. It was incredible. Why'd you get rid of it? Oh, well, I wasn't really a Windows user. But when I got to play around with it, I was always blown away. I converted to GNU Cash for a while. Then came my money. And then BeanCount plus Fava. And now I'm back to KMoney plus HLedger. What are you all doing for your personal or business accounting? Well, mine's called... I hired out. You have a human doing it? You don't need software. Yeah, but mine's a little more complicated than the average bear. Wes? I have used plain text accounting in the past. Right now my accounting needs are fairly simple. So I don't have a crazy system. But especially now with the rise of more tools to help, I was actually considering... I used the original Ledger, although I've played with HLedger more than a few times. And it does seem like now that manipulating the data, double-checking things, writing scripts around it is easier. It kind of might be the time where I go back to it. I don't feel so bad about my decision then. Because I was dabbling with this plain text accounting. Because it follows all of our principles, guys. It sure does. This is exactly what I want. But then I realized, I guess much like Wes, which surprises me, that I don't have any of the programming skills to bring up my own reports for the things I wanted to know around my own finances. And so that's the number one thing that kept me from using it. But these days I feel like we've got several robots that are way better at this than I am. See, interesting. My main reason was not that I think I could do. Mine was mostly just I didn't really want to do... I didn't have enough things where I needed the granularity. So it's like I want to do a high-level budget to understand where my cash flows are going. But the idea of making sure that each record is accurate was not the priority. So that was the part where I was like, that's not really worth it. I don't need the granularity right now. If I did, then I would. But you're right. Reporting is a whole other aspect. You know, I just realized, boy, maybe if I had a cash flow... You do need an income to track. All right, we got to move on, you guys. Good question, though. We should maybe do a segment in the future. Moan sent in a members boost. Put some macaroni and cheese on there, too. It reads, I also recently wanted to change up my notes app. Oh, dangerous. Obsidian is great, but I wanted an open source, simple, and got the struct from the OS like Obsidian. So I settled on VS Codium with a custom workspace that only has one tab, no sidebars, and a search bar at the top. Interesting. Custom little environment, kind of. I like that for a dedicated editor. Seems like it gets tough in the mobile application. Right. But for a dedicated sit-down, like a notes PC in the garage... I understand this. I've wanted a dedicated application. I'm using Kate these days and have for a very long time. But I do many things in Kate. But having one dedicated... You always bring it up, maybe even with a keyboard shortcut, and it's always your notes app. That sounds sexy. Anton comes in with a member boost. Linux or something. I'm thinking of trying Hermes at work. To be useful, I need to teach you to be a subject matter expert by feeding it a bunch of vendor docs, R docs, example configs, that kind of thing. Can it learn that much information? Any tips for giving it lots of data? Well, do you have any before I give mine? Go for it. So it's going to kind of depend on what the subject matter is format, right? So if you could get all of the things you wanted to know in a really easy, readable format, maybe structured data or even simple markdown, you're going to have some options. So here's what we do. And this is just going to be our workflow. But we want to index every podcast, what we've talked about, what projects we've talked about, what picks we've made, what we said about a certain subject, what predictions we made. And so we're using a tool called QMD. And QMD is like a vector index and search tool that takes your markdown or your structured data and it sort of creates these relationships in the search database that then the agent or you using the command line can go back. And so, for example, we could go back and we could say, you know, besides episode 677, when else did Anton boost it? And the agent would go back and find that specific thing for us by using the transcripts, which then have been vectorized. And then we use QMD as the front end to search that and query it and index it. So QMD could be one route. I'm sure there's probably a thousand ways to solve this. I think the core piece is at that scale, you can't just rely on it all being in context. Yes. Unless you have some crazy giant context model. Yeah. What you're going to need to rely on is skills to access a storage that's quickly and retrievable, right? So as you have it go through all of that, it needs to be generating some sort of persistent on-disk output, whether that's, you know, an LLM wiki style thing, whatever kind of structure you want it to have. And then also perhaps is maintaining a database or the harness is automatically doing it or you're having it feed it into QMD directly. There's a lot of options there, but essentially you could kind of make sure that it's building a structure so that in the future, it has clear skills and clear storage of where everything, when it doesn't know something, it has clear guidance for how to go learn it so that it has it fresh in that context. Yeah. All right. James Mudd comes in with a member boost, loving the EV bonus, working as a dev at a large UK CPO. All of your complaints are valid, but I think maybe things are a bit better here than they are in the US. Not sure if you know about Octopus Electroverse, but it's great for charging stops and planning Android Auto and CarPlay. Electroverse.com. That's a great name. I'm not familiar, but cool. Yeah. I have been using a better route planner a bit, but I sort of went overboard and created the ultimate front end for my agent. So it's basically able to query every EV database that has an API, including government databases. And then the big unlock that I think was the TomTom API, because the TomTom API, it turns out to have a ton of stuff about EV and charging stations and all this kind of stuff. So you just did what Anton was asking about? I guess. Yeah. I guess so. You're welcome, Anton. You're sharing that thing or what? Hmm. You want to take Tristan? Sure. Tristan sends in a member boost. Oh! About music playing boosts. Listening to this episode on an iPod. Oh, wow. Wow. It's still spinning rust? That's incredible. Or you can upgrade them. Yeah, I know, but still. But did he? Did he? Yeah. Earlier this year, I started Music Walks with my three-year-old, bought him a cheap MP3 player and just set off my old iPod. The member URL for this podcast is an age Nix secret in my Nix config and syncs to my iPod when I plug it in overnight. That, well done, sir. Wow. Wow. That is very, very impressive. Yep. Showing us the way. Mm-hmm. Mm-hmm. Ha ha ha! Wow. Anonymous comes in with a member boost. If an anti-AI project gets an AI contribution, well, that's really no different than a project with a CLA getting a patch from someone who hasn't signed the CLA. You inform them why you can't accept it, and if they don't comply, optionally treat the bug like a feature request without patch. That kind of seems like a pretty reasonable, I suppose it depends on the severity, but that seems kind of like a reasonable view. Yeah, I think especially for maybe like a feature request or a big, yeah, patches, and hey, look, I added this thing. I think where it does get trickier, like you're saying, is hey, I noticed this flaw in the code base, and here's a patch, but are you going to throw the whole thing out, or are you still going to fix the flaw? Do you do the implementation work yourself? Do you rely on that code and fix it up yourself, or do you just throw it all away? Yeah, the other wrinkle there, like Linus has said too, is like if one LLM tool has discovered your zero day or whatever, you can probably assume another one has or will very soon. Fair enough. So there is a bit of urgency to it. And that's where there's maybe a distinction between sort of stuff you asked for and did yourself and then stuff that just shows up at your door. Eric the Magician comes in with a member boost. Hey, hey, Eric. Eric says no to ads. Speaking about our ad-free membership. Yeah. It took me too long to realize, though, that a membership discount meant less money for you. Oh. I have for years now, though, tried to increase what I pay each month. It's not a lot, but I hope this can nudge others in the same direction. Thank you, Eric. Yeah, thank you. That's very kind. Thank you for the support for years too. Really, really do appreciate it because like, you know, starting to build a leg is here at the show. We want to keep going. You guys are making it possible. I'll wrap this up. ATX BBQ Nerd comes in and says, thanks for the AI coverage. You keep it grounded and useful. Linux feels more and more punk every year. That really, when we saw that come in, I was like, that really feels true. Yeah. That really resonated. Thank you very much. Appreciate that, ATX BBQ. Thank you, everybody who boosted, including those of you who streamed those sats. 14 of you did, and collectively, not a bad little boost yourselves. You stacked 32,539 Satoshis. I don't understand what the heck is going on here. Ah, you will in just a moment, sir, once you break it all down and you combine that with our boosters. Wow, you know, you just never know what direction it's going to go. Look at this. You never do know what direction it is. You don't. I thought for sure we were going to come in light this week on a travel week, too, because it happens so often. But no, you all stepped up and you supported us. When you combine the fiat boosts and you value them at the current sats to USD, our total for this week, when you combine it all together, is 568,249 Satoshis. Not going to complain about that at all. Heck no. Thank you, everybody, very, very much. It does mean the world to us, and we really appreciate everybody taking advantage of boost.jupiterbroadcasting.com. And we still have a good batch coming in through the traditional podcasting 2.0 apps and great to see the members taking advantage of their free member perk and getting to send a free boost every single episode. We love seeing that, too. Thank you to our members. Thank you to everybody who boosted this here Value for Value podcast. We really appreciate you. Yes, we do have dynamic ads. No, they don't pay much and they're not like the traditional ad market. And we think, we think with this combination, we can continue on. And I hope, I call it, I hope, we'll see, but I call it preventing the Linux magazine fate happening to Linux pipes. Thank you, everybody. And with that, you know what? It's time for the picks. And Wes, you found us a Pipewire pick. Yeah, I thought you might need it. You know, we're doing remote streaming. We're doing more audio stuff. Could not have been better timed. It is also a modern GTK LibWadia application. Yeah, it's a control center for Pipewire. Ooh, tell me about it. Really, for any Linux distro running Pipewire. Yeah. Right now it's packaged in the AUR. There's install instructions for Fedora, Buntu, and Debian. Not sure if it's in Nix yet, but surely, you know, we can fix that. Matter of time. Yeah, it does a lot. I guess you could say just new in the most recent version. There's now a patch bay, a live node graph of the whole session, audio and MIDI. It's got a live monitor per service CPU and RAM, Sparklines, X-Run, and DSP load meters. It now has effects. Insert racks of Ladspa or LV2 plugins into the signal path. Virtual devices create null sinks, virtual microphones, combined aggregate devices, and buses and submixes. Each runs its own tiny process, temporary or persistent, you choose. So creating or removing one never interrupts playback. The new patch bay they're working on is looking really good. I think it may eventually replace QP graph that I use right now. These projects remind me that we're not the only pipeware nerds out there. I know. It's great to see. The live monitoring looks good. What I think stands out to me is the way the developer has managed to put together a pretty clean, easy-to-follow UI for something that is extremely complicated and has a ton of UI elements. It's just so much. Have you ever seen the output of some of the pipeware tools? You get just gobs of JSON. And yeah, right? So this not only has a bunch of that exposed, and you can do a lot of standard monitoring stuff, but you can also do fancy stuff all in one UI. In your standard desktop audio pipeline, you can insert effects. So if you're watching something that's a little too quiet, you can pop a compressor on right there. But from the same thing, they can just sort of manage your basic devices. Yeah. Yeah. That's the thing. It's like we've had a lot of great tooling, but then in particular, before, Linux audio was so bifurcated between like also at first and then pulse, and then with Jack on the side as its own universe. And pipewire is finally bringing them together, but we've had a lot of composable tools mostly, but have never really gotten to the full thing that it could be in the new era. And maybe this is the start. I feel like it is actually, that's such a great way to put it. It's actually unlocking the real pipewire potential. And we've needed good, oh, I'm so excited about it. Because the bones are there. They're there. Pipewire is great. Pipewire controller. I've also said at the end of the read me here, there's a, if you like tinkering like me, here are some cool Git hubs to visit for sound tools list. And there are, I don't know, 10 different Linux audio sound tools here all worth looking at. I didn't even see that. That's fun. Okay. There's one even called gentle dynamics. It's been a good week of finding tools. Oh yeah. Classic easy effects is listed in there. Got to give that a shout out. Also kind of great thing. You'll have to see there's a thanks at the end to Wim Taman's past guests on our show, creator of pipewire, who I guess reviewed some of the server pages, quantum and buffer settings. Cool. And helped fix some bugs. All right. So that pick and all our links are at linuxunplugged.com. And this right here was episode 677. So you can go to linuxunplugged.com slash 677 to get a link to that. Buzz and some of the documentation, other things we've talked about. And our invite link. If you want to join our Buzz community and, you know, give it a shot. I have no idea if it's going to work. Sorry about that. Yeah, totally. Try it with us. Try it with us. And let's learn it together, I say. And really, really let us know what you think. If you try it. Seriously. Yeah, boost in. Boost in your Buzz hot takes. We want to hear it. We want to hear it. And also you can go to linuxunplugged.com slash contact. Of course, you can make it a Linux Tuesday on a Sunday. You could join us next Sunday at 10 a.m. Pacific, 1 p.m. Eastern. Or go to jblive.tv whenever you want. And just see if it's live. That's what I say. We see where we are. We're not going to be here. That's right. Same bad time. I won't be here. No. No. None of us are. We're all going to be in different little ass. We'll be in a different country. Weird. We'll be on the other side of the continent. This is a send-off show. I'm not leaving. I'm just leaving this place. Yeah, the last broadcast from the cottage. Oh. I'm glad we could be here for it. That's nice, right? It is. Yeah. That is cool. That is cool. Wes, before we go, why don't you tell people a few pro tips, like, you know, extra data around the show. Ooh, you like extra data. I love extra data, Wes. There you go. We upgraded the audio stream, so we have a video stream, one of those fancy newfangled MP4 files. No way. Yep. Same thing you get, just with more data. A lot more data, actually. But if you like small text files, or medium-sized text files. That's my speed. Yeah, well, we have SRT, or VTT, which includes diarization, so it says what Chris said, and what I said. Oh. Yeah, and it might actually get it right most of the time. It should. Am I in there, too? You're in there, too. No, And the mumble room, and our clips. I had to delete all of Brent's stuff. Oh, that happens in post, right? That was where actually most of the time was spent. And, if you just know that it's really all about the audience, and you want to jump right to the boost segment, or the feedback segment, or you just are here for the picks only, and that's fine, too. We have chapters for that. A lot of you are just here for the picks. We understand. Thank you, everybody. We really appreciate you joining us. Brent, thank you for hosting us. Oh, you're welcome. Thanks for helping me pack up all my junk. Well, who doesn't love moving, right? It's a national past. It says to myself, I get five days off a year max, and I want to spend all five moving. That's what I says to myself, you know? Well, you know, the faster we do it, the more we get to hang out in the mountains. So, the harder we work in the 100 degree weather, the more fun we get to have. Yeah. There you have it. Hey, at least it's not your stuff. It actually makes it a lot easier. It really does. It really does. All right. Thank you, everybody, for joining us. We really do appreciate you, and hope you enjoyed this week's episode. Let us know how we did with a boost or an email. Don't forget, you can join us in that mumble room. We've got that over at linuxunplugged.com, along with our Matrix info, how to subscribe, and the back catalog. But with that, thank you so much for joining us on this week's episode of Your Unplugged Program, and we'll see you next Tuesday, as in Sunday.