migration
Bring the room with you.
No app store here — just the shortest paths for bringing a room with you. Bring your structure, bring your history where the terms allow, wire your notifications in, and keep every bridge honest about where messages came from.
Channel operators can create incoming webhook URLs from channel settings when the server exposes that capability. Onyx treats webhook creation as a channel-admin action and keeps the copy clear: a webhook posts into one room, under one configured identity, with classic text fallback.
| Field | Behavior |
|---|---|
| Target | One channel per URL. |
| Format | Compact JSON payloads with text fallback for classic clients. |
| Controls | Structured buttons are limited to safe links or copy-only values; posted payloads do not run client commands. |
| Lifecycle | Operators can create, rotate, and revoke. |
Onyx can import reviewed action manifests into Preferences. They become command-palette entries, stay local to the device, and are limited to two capabilities: open a URL or copy text. Payloads are not stored in the audit log.
{
"version": 1,
"actions": [
{"id": "open.status", "title": "Open status", "capability": "open-url", "url": "/status/"},
{"id": "copy.room", "title": "Copy room", "capability": "copy-text", "text": "#root"}
]
}OroWasm hooks run server-side and can filter delivery before messages reach clients. Onyx treats those hooks as protocol infrastructure; user actions still pass through reviewed manifests and capability checks.
Imports should land as reviewable drafts first. The operator decides what becomes server-visible and what stays local device memory.
Bridges are operational surfaces, not magic. The public contract is that a bridged room should show where messages came from, whether the bridge is healthy, and what identity mapping is being used.
- Bridge identity is visible in the message source or room status.
- Failures degrade to read-only or paused, not silent loss.
- Imported or bridged messages keep provenance labels.