issue/rhai-component-framework #98
No reviewers
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
puregarlic/microclimate!98
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue/rhai-component-framework"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Replace the LiveKit/WebRTC media stack with Media-over-QUIC (moq) over an iroh transport, with our server acting as the relay. Server (server/): - Embed moq-relay (Cluster + Connection + Auth) on an iroh endpoint as a new services::relay module; single-node today, cluster-ready for the future. - Mint per-channel moq-tokens (HS256) the relay verifies; track live presence from origin announcements. - GetChannelToken now returns {relay_addr, moq_token, broadcast_path}; GetVoiceChannels reports participants from relay presence. - Drop livekit-api and the LIVEKIT_* env; add MOQ_* config. Client (src-tauri/): - Rewrite channels::manager to dial the relay over iroh H3/WebTransport, publish the mic as an Opus broadcast via moq-audio, and discover/decode peers via origin announcements into the existing cpal+sonora pipeline. - Derive active-speakers from RMS; emit room stats from the QUIC connection. - Same Tauri command/event names, so the frontend is unchanged. Drop livekit. Infra: - proto/channels.proto: new token response shape. - Dockerfile: Rust 1.96 (moq needs 1.95+) plus cmake/clang for aws-lc-sys. - Vendor upstream source as pinned git submodules under vendor/ (moq, iroh) for in-tree reference; exclude vendor/ from deno fmt/lint. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>All seven components, eight shared libs, and four fixtures now exist as .scm alongside their .rhai originals, and every screen renders identically: a pixel diff of all ten screenshot scenarios shows no content differences. The Scheme versions are markedly shorter than what they replace, because the prelude absorbs the patterns Rhai needed by hand. Dropping falsy children turns the `if cond { x = x.child(...) }` rebuild dance into an inline (and cond ...), splicing list children turns array-building into (map ...), and lambdas closing over their environment retire the Fn("name").curry(id) contortion that existed only because Rhai handlers could not capture. Two harness improvements came out of the comparison: * settings_development was the only scenario running without a fixture, so it resolved the signed-in profile over the network and whether the user card had arrived by capture time was a coin flip - the screen genuinely differed between runs of the *same* runtime. It now uses the demo fixture like every other settings screen, and the two runtimes match exactly. * The modals fixture was stale: it seeded bare strings for the device lists, but settings_audio was updated to expect {id, name} records, so that screen would have failed on the Rhai side too. The Scheme port seeds proper records. A new test loads every shipped component and asserts that each entry point it defines actually resolves under its module prefix. An init that silently fails to resolve looks fine on screen but never fetches anything, which is the kind of failure that otherwise only shows up as a mysteriously empty sidebar. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>WIP: issue/rhai-component-frameworkto issue/rhai-component-framework