You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Docs] Complete the voice connector authoring guide #35
Turn the connector architecture and manifest into a practical authoring guide and review template for voice sources implemented in any language.
The repository already includes connectors/README.md, a connector-manifest JSON Schema, and an initial Omi manifest. Complete the contributor-facing guide around them.
Progress and acceptance criteria
Add a framework-neutral connector directory and overview.
Define a machine-readable connector manifest and license fields.
Add an initial Omi manifest that states its real implementation status.
Explain connector lifecycle and capability behavior in depth.
Include a minimal example connector using synthetic data.
Provide a checklist for protocol provenance and license compatibility.
Document discovery, permissions, formats, timestamps, backpressure, interruption, and cleanup expectations.
Include automated-test, conformance, and physical-validation guidance.
Add a connector proposal issue template covering platforms, implementation language, protocol sources, hardware access, and privacy implications.
Link the completed guide from CONTRIBUTING.md and the README.
I'd like to take this. Plan, scoped to the open checklist items:
docs/connector-authoring.md: lifecycle and capability behavior; discovery, permissions, audio formats, timestamps, backpressure, interruption and cleanup expectations; automated-test, conformance and physical-validation guidance; and a protocol-provenance and license checklist.
connectors/examples/synthetic-tone/: a minimal example connector with a connector.json. It works at the murmur.v1 message level: it handles SessionControl and emits VoiceSource, AudioFrame and RuntimeEvent using the TypeScript SDK models, so it does not introduce a competing runtime API while [Core] Finish runtime interfaces on murmur.v1 #34 / feat(dart): add idiomatic voice runtime interfaces #50 settle. The audio is deterministic synthetic PCM, with node --test coverage under make check-typescript.
tool/check_conformance.py: validate every connectors/**/connector.json, not only Omi's.
.github/ISSUE_TEMPLATE/connector-proposal.yml covering platforms, language, protocol sources, hardware access, and privacy.
Activity
nikhilcrypto0 commentedon Sep 25, 2026
I'd like to take this. Plan, scoped to the open checklist items:
docs/connector-authoring.md: lifecycle and capability behavior; discovery, permissions, audio formats, timestamps, backpressure, interruption and cleanup expectations; automated-test, conformance and physical-validation guidance; and a protocol-provenance and license checklist.connectors/examples/synthetic-tone/: a minimal example connector with aconnector.json. It works at themurmur.v1message level: it handlesSessionControland emitsVoiceSource,AudioFrameandRuntimeEventusing the TypeScript SDK models, so it does not introduce a competing runtime API while [Core] Finish runtime interfaces on murmur.v1 #34 / feat(dart): add idiomatic voice runtime interfaces #50 settle. The audio is deterministic synthetic PCM, withnode --testcoverage undermake check-typescript.tool/check_conformance.py: validate everyconnectors/**/connector.json, not only Omi's..github/ISSUE_TEMPLATE/connector-proposal.ymlcovering platforms, language, protocol sources, hardware access, and privacy.CONTRIBUTING.mdand the README.No hardware connector and no
murmur.v1changes.docs(connectors): complete the voice connector authoring guide (octob…