Mujina Dev Call 20260601

[rkuester]

Summary generated by AI from the meeting recording.

Post-Meeting Summary and Transcript

Attendees: Ryan (host), AgentP, Brett, Dylan, Jeff, Johnny. Referenced but absent: Average Gary (advice on running the calls), Skot (S19J prototype, macOS USB discovery contribution), Jayr (YAML config work), Ronald (BZM2 posts), Schnitzel (DoomAxe on a podcast), Ryan Raminger of Cryobite Labs (EmberOne water block STLs).

Summary

Meeting format and recordings (00:00)

• The previous call was transcribed and summarized by AI for the first time, done locally and handed to Claude, with no paid service. It was well received, so it stays.
• Open idea: also post call recordings to Bitcoin TV, the way Fedimint does. Tentatively yes unless someone objects, since the transcript is already public.

Forum vs GitHub Discussions (04:02)

• Working split: GitHub Discussions for developer and technical conversation (close to the code, PRs, and issues), the forum for user-facing topics (showing off builds, usage questions). Ryan flagged the risk of too many channels; Brett agreed a clean separation avoids confusion and lets people self-route between them. Background: what goes where.

Framework vs specific miners (06:39)

• Restating the modular vision: Mujina is first a framework of modular components, which then get assembled to support specific miners. Prototypes should be torn down into high-quality reusable parts (power-supply controller and the like) and composed into a board support file. Each merged part makes the next miner easier for a person or an agent to assemble.

Good Vibes and handling prototypes (09:48)

• New "Good Vibes" Discussions category as the home for vibe-coded prototypes, instead of letting them land as PRs that clutter the list. Contributors open a thread pointing at a branch on their fork; others can review, discuss, and refine the good ones toward mainline.
• AgentP got Mujina running on an S19 XP (forum thread, pictures on X) and will open a Good Vibes thread describing it and linking the code. Wider point (AgentP): vibe coding lowers the barrier to open source but risks a flood of "good idea fairies"; collecting them in one place is a first way to spot patterns and triage.
• Credit for partial contributions: use git "co-authored-by" trailers so a maintainer can pull in or polish someone's commits while still crediting them on the commit and the contributors list, without forcing them through the full PR back-and-forth (Johnny). Ryan did this with Skot's macOS USB discovery work.
• Idea (Brett/AgentP): an agents.md that points LLMs at the Good Vibes discussions so future agents produce output that fits the project and is easier to merge.

Forum and chat highlights (15:47)

• EmberOne water block STL files: people keep asking. Ryan is trying to get them from Ryan Raminger at Cryobite Labs, who built them and is expected to be fine sharing. See the waterblock thread.
• Schnitzel's DoomAxe on a podcast: a LibreBoard running Mujina with a Bitaxe as the hash board, talking to a local HydraPool and Bitcoin node, battery powered.

Configuration system and REST API, MIP-0001 (17:48)

• Ryan wrote up the config-and-API design as a requirements-style document and started a Mujina Improvement Proposal (MIP) repo, in the spirit of BIPs and NIPs. MIP-0001 is that document, and the discussion links to it. The process is intentionally light, just a place to park and discuss a real design doc. Old config/API discussions were closed and redirected to it.
• DR1, the in-memory configuration tree: one authoritative data structure inside the program, with the API and other subsystems as views onto it or inputs into it, and changes propagating to subscribers, rather than several separate trees kept in sync.
• Dynamic-config options (Brett's framing): (1) immutable, restart to change anything; (2) dynamic, with an internal cache that persists but the user's config file is never edited; (3) dynamic, and Mujina edits the user's config file too. Brett leans toward option 3 for maximum dynamism (for example, solar-powered load management that retunes frequency and voltage by time of day without restarting and re-running chip startup).
• Ryan's design is closer to option 2: Mujina keeps its own separate, persistent layer for API-driven changes and leaves the user's config file alone. Downside is that no single file shows the full picture, so a config-dump API endpoint would surface the merge of built-in defaults, user config file(s), and saved API changes. Brett is fine with separate user and internal config as long as the internal layer persists across restarts, and floated a dynamic YAML file mirroring the proposed directory structure.
• Guiding principle (Brett): give users a good API; almost no one touches the firmware layer directly, so the backend choice matters less than a responsive, well-designed API. Ryan noted developers, packagers, and tinkerers are the main config-file users anyway.
• Not consensus yet. Let it ride a few weeks for people to read MIP-0001 and comment in the discussion or on the MIP PR.

Ryan's vibe: a getblocktemplate job source (43:54)

• Built at a TabConf mini-conference hackathon before Vegas (a two-hour "hack AI into your open source project" session). It is a new job source that mines directly against a Bitcoin Core node via getblocktemplate, no pool, running on the Bitaxe. Shared in Good Vibes.
• Johnny suggested looking at Bitcoin Core's new Unix-socket IPC as a possibly easier path than JSON-RPC.
• Ryan stressed shaping vibes as a series of small atomic commits (his was about eight or nine) rather than one giant commit, since breaking them down is part of getting a vibe into mainline. The repo history and contribution docs already model this for agents to learn from.

Community: office hours and chat (48:47)

• Dylan runs informal Home Assistant office hours, Wednesdays 10 to 11 a.m. Mountain on a Jitsi call: people drop in to ask questions or show what they are building. Helpful even when only a couple show up. Worth considering something similar for Mujina.
• Chat: interest in an always-on "live hang" room. The Mujina-specific channel was deleted, so for now use the 256 Foundation chat. Telegram, Slack, and Discord all came up; Ryan mildly prefers Telegram but is not thrilled. Still an open question.

Action items

• Ryan: pursue posting call recordings to Bitcoin TV unless someone objects.
• Everyone interested in config: read MIP-0001 and comment in the discussion or on the MIP PR over the next few weeks.
• AgentP: open a Good Vibes discussion describing the S19 XP work and linking the code.
• Ryan: ask Skot to post his S19J / JPro prototype as a Good Vibes discussion.
• Ryan: keep trying to get the EmberOne water block STL files from Ryan Raminger at Cryobite Labs.
• Look into Bitcoin Core's Unix-socket IPC as an alternative to JSON-RPC for the getblocktemplate source.
• Consider an agents.md pointing LLMs at the Good Vibes discussions.
• Think about chat approach (and whether to recreate a Mujina channel), and weigh Mujina office hours like Dylan's.

Transcript

Full transcript on the wiki: https://github.com/256foundation/mujina/wiki/dev-call-20260601

Agenda (as planned)

Note: These meetings are recorded and transcribed by AI.

Purpose: touch news and happenings to keep everyone aware of what's happening,
roughly follow development workflow, not replacement for the other communication
channels

Follow-up

• Last call
  • AI summary and transcript
  • Should we post recordings to bitcointv.com?
• Action items covered by items below

Forum & Chat

• Forum vs. Discussions
• Modular vision
• AgentP: S19XP + amlogic
  • Best practices for hacking Mujina onto other miners
  • S19 XP pics on X
• E1/00 waterblock files
• Schnitzel's DoomAxe on HomeMiningPod

Discussions

• Configuration system and REST API #57
• MIPs!
• Closed a number of old discussions related to config and API and redirected to Configuration system and REST API #57
• Direct-to-node (getblocktemplate) mining source: a TabConf vibe #60

Issues

• All issues
• feat(transport): add USB hotplug support on Windows #58
• bug(cpu_miner): forced share rate is wrong and never converges #59

PRs

• REST API: allow for voltage change on board #30
• feat(bitaxe): add PI-based fan speed controller #33
• yaml based configuration #36
• Make non-glibc Linux cross-compilation work #55
• cpu-miner: make the CPU backend a first-class citizen for API/tooling #56

Other

• Dylan: Tell us about your Home Assistant office hours

Open floor

[rkuester]

Summary and transcript are now in the top post.