Repository navigation
groups
Live participant groups are not operational in the current server and browser runtime. Settings includes Groups & two-way audio, but its directory reports unavailable. The generated protocol defines list, join, and leave messages; the running implementation does not handle those commands. There are no real group names, participant counts, join sessions, or participant recording states to display. Creation and administration controls explain this limitation.
Do not add an invented [groups] section to config.toml or infer support from generated types.
The configuration reference lists the supported settings.
| Concept | Current purpose | What it does not grant |
|---|---|---|
| Camera group labels and access grants | Organize cameras and define which cameras an identity may access. | Membership in a voice or conference session. |
| Saved dashboards and their audience | Share a camera layout and its wall presentation settings with selected viewers. | Permission to see cameras outside the viewer's grants. |
| Live participant groups | A protocol and design model for named camera collections with optional participant audio/video. The runtime is unavailable. | A working walkie-talkie, conference, or group administration feature today. |
Use Authentication and access control for camera grants and Live wall for saved layouts. These implemented features work independently of live participant groups.
The group client scenarios describe server-owned definitions with static camera stream members, optional passwords, and optional live participants. Participant media would have a server-assigned identity and its own stream and recording policy. Camera membership would not change a camera's ordinary recording policy.
The design is full duplex: it has no floor control, moderator, or server-enforced speaking turn. Push-to-talk means a client gates its own microphone while keeping its publication ready. It is not a server command or a promise that the current browser includes a working radio console.
Those scenarios explain the intended contract, including reconnect and per-participant recording behavior. They are not evidence that the handler, client capture, directory, or recording path has been implemented and qualified. A future implementation needs runtime and device evidence before this chapter can provide operational setup instructions.
Talkback sends audio to a supported physical camera. A live participant group would exchange media between clients through KeepPeek. Support for one does not imply support for the other.
The current browser Talk control is unavailable. Consult Camera controls for supported physical camera operations and the availability reason shown for the selected device.
- KeepPeek
- Feature guide and navigation
- Get started
- Authentication and access control
- Camera controls
- Demo videos
- Live wall and kiosk display
- Recording and evidence
- Digital zoom and pan
- Camera and stream health
- Visual configuration management
- Configuration reference
- Export and import configuration
- Backup and restore
- Upgrades and migrations
- Recording maintenance
- Recording archive recovery
- Native camera events
- External analysis
- Notifications and integrations
- Home Assistant card
- Groups and two-way audio: current status
- How KeepPeek works
- Users and design choices
- Release readiness and known limitations
- Reporting bugs
- Open source and licensing
- Contributing
- Access control
- Backup and restore
- Camera controls and vendor alignment
- Computer Vision Service Scenario
- Visual configuration management
- Demo Video Publishing
- MQTT 5 Event Forwarder
- Event-Loop Runtime
- Event presentation metadata
- Event browsing, search, and encoded previews
- Event Review and Shared Bookmarks
- Evidence exports
- External authentication proposal
- Operate external authentication
- External authentication performance evidence
- External authentication verification
- Group Client Scenarios
- Hikvision ISAPI integration notes
- Home Assistant Card
- macOS installation
- Native event recording performance
- Notification rules and delivery
- Native event acceptance evidence
- Generic ONVIF and RTSP events
- Performance benchmarks
- Event pre-recording contract proposal
- Event pre-recording performance qualification
- Event pre-recording acceptance evidence
- Pushover notifications
- Recording integrity
- Recording policy audit
- Runtime profiles implementation contract
- Secrets configuration
- Shared State Store Scenario
- Transcoding Service Scenario
- Viewer Application Scenario
- Wiki publishing
- Windows service