Skip to content

Speak the host's generic videoconf protocol, not a Pexip-specific one - #14

Open
rodrigok wants to merge 4 commits into
mainfrom
feat/rocketchat-videoconf-protocol
Open

rodrigok wants to merge 4 commits into
mainfrom
feat/rocketchat-videoconf-protocol

Conversation

@rodrigok

Copy link
Copy Markdown
Member

The messages this plugin exchanges are all about the host's chat panel — is it open, does it have anything unread, please open it. None of that is Pexip's, but the namespace said otherwise: pexip:plugin:external-chat/* describes a protocol only Pexip could ever implement, when the page on the other end will take the same actions from any provider's plugin.

So the namespace becomes the host's — rocketchat:videoconf/* — and the two actions the plugin receives are renamed to describe the state they carry rather than the widget this plugin happens to render for it. A plugin for another provider might show unread as a count, or not at all.

Before After
toggle-chat-button-state { active } chat-state { active }
toggle-chat-badge { visible } chat-unread { unread }

ready, toggle-chat, connected, disconnected and the dial-out trio keep their names under the new prefix. Nothing else about the plugin's behaviour changes: same button, same badge, same events, same dial-out.

The README's postMessage API section is updated throughout, and now says out loud what both ends already did by accident — unknown actions are ignored, so either half can learn a new message without breaking the other.

The other half

Rocket.Chat's conference window speaks this protocol from useProviderPlugin (apps/meteor/client/views/conference/hooks/useProviderPlugin.ts), on the call-window branch of the persistent-chat stack. It answers ready with chat-state + chat-unread, pushes chat-state whenever its panel moves — so this button follows a panel closed from Rocket.Chat's own UI — and treats a user-initiated disconnected as leaving the call.

Before merging

  • This is a breaking protocol change, and deliberately without a compatibility shim: a workspace pairing this build with a Rocket.Chat that still expects pexip:plugin:external-chat/* gets silence — no toggle, no badge, no leave. Both sides need to ship together.
  • Needs a release to reach a deployment: make bump (1.5.0 → 1.6.0) then the release workflow. Left out of this PR since bumping is a release step here.
  • dial-out is documented but nothing on the Rocket.Chat side sends it yet — its participants modal takes usernames only.

Verified with tsc --noEmit, eslint . and npm run build; the built bundle carries the new namespace.

🤖 Generated with Claude Code

rodrigok and others added 4 commits September 10, 2026 15:46
The messages this plugin exchanges are about the host's chat panel — is it open,
does it have anything unread, please open it — and none of that is Pexip's. Naming
them `pexip:plugin:external-chat/*` made a protocol that only Pexip could ever
implement, when the page on the other end will take the same actions from any
provider's plugin.

So the namespace is the host's: `rocketchat:videoconf/*`. Nothing else about the
plugin changes, and the two actions it receives are renamed to describe the state
they carry rather than the widget this plugin happens to render for it — a
different provider's plugin might show unread as a count, or not at all.

  toggle-chat-button-state {active}   ->  chat-state   {active}
  toggle-chat-badge        {visible}  ->  chat-unread  {unread}

`ready`, `toggle-chat`, `connected`, `disconnected` and the `dial-out` trio keep
their names under the new prefix.

Both ends already ignore actions they don't recognise, which is now written down
in the README rather than left as an accident of the switch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The plugin's half of the bridge changes shape: it speaks the host's generic video-conference protocol rather
than a Pexip-specific one, which is not something a page already embedding it can pick up without knowing. A
major says so.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seven of them, and six are lockfile-only: js-yaml 4.1.0 → 4.3.2, nanoid 3.3.7 → 3.3.19, postcss 8.4.38 →
8.5.28, brace-expansion 1.1.11 → 1.1.21, axios 1.7.2 → 1.20.0, form-data 4.0.0 → 4.0.6. Each is at or past
what its PR asked for; the resolutions are what the current ranges give rather than the exact pins Dependabot
proposed, since they were opened weeks apart and would otherwise have to be replayed in order.

The seventh is vite, and it is a real one: 5.2.12 → 8.3.0, three majors. The config is `base`, a build target
and the mkcert plugin, all of which vite 8 still takes, and the engine it now asks for — node ^20.19 or >=22.12
— is met by the node 22 both workflows pin. Build and lint are green from a clean `npm ci`.

Eleven advisories are left, all in the eslint 8 chain and none of them the subject of a PR here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ntrols

The bridge carried a chat button and little else. It now tells the page what it can do, says who is in the
call, and does what it is asked about them.

`ready` carries the list of features this plugin supports, so the page renders a control only where there is
something listening for it. The roster goes up on every change, each participant with the flags Pexip keeps
per person — who may be muted, moved, spotlit, hung up on — because those flags are the only honest answer to
whether a control is worth offering, and nothing here replies to a request that was refused.

Inbound: mute, camera, admit, disconnect, spotlight, raised hands, role changes, transfers and DTMF, each
forwarded to the conference call that carries it out. Two of them are translated rather than passed through —
a host is a `chair` to the role endpoint, and a transfer's `alias` is its `destination` — so the protocol can
say what it means without Pexip's vocabulary leaking into the page. A transfer with no role stated makes a
guest, so it can never quietly promote anyone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant