Gitter–Matrix bridge: room setting changes not reflected on the Matrix side

Short answer

In the standard Gitter–Matrix bridge (matrix-appservice-gitter), Gitter is the source of truth for room state. Name, topic, avatar, and privacy changes flow Gitter → Matrix as state events; changes made on the Matrix side are not pushed back to Gitter and are typically overwritten on the next state sync. If Gitter-side changes are not appearing on Matrix at all, that is not expected behavior — it usually points to a webhook delivery problem or a bridge backlog, not a design limitation.

Who owns room state

The bridge is designed as a one-directional mirror for metadata:

• Name / topic / avatar: Gitter-side edits are pushed to the mirrored Matrix room as m.room.name, m.room.topic, and m.room.avatar events, sent by the bridge bot.
• Permissions: Gitter's public/private setting maps to Matrix join rules. Editing join rules on the Matrix side does not change Gitter's privacy setting, and the bridge will re-assert Gitter's value on the next sync. Power levels are likewise managed by the bridge bot and manual edits get reverted.
• Configurability: this ownership direction is not a bridge setting. Making Matrix authoritative would require a forked appservice or a different bridging approach.

Membership conflicts

Gitter-side joins and leaves are mirrored to Matrix via the bridge's virtual (ghost) users. A user who joins only from the Matrix side is accepted into the Matrix room but does not gain a Gitter membership: they appear on Gitter as a bridged matrix-user, cannot be @-mentioned from the Gitter side, and have no access to Gitter-native features. There is no merge logic — each side's membership is authoritative for its own platform, and the bridge only reflects Gitter's list outward.

Delayed vs. missing propagation

Some delay is normal. Message relay is near-real-time, but state events depend on Gitter webhook delivery plus the bridge's processing queue, so seconds-to-minutes lag can be expected. Outright missing updates usually mean one of:

• Webhook delivery failures (network, TLS, rate limiting) — these can drop state updates silently.
• A bridge restart, which triggers a full resync and can temporarily push stale Gitter state over recent Matrix-side edits.

Verifying with your test room

1. Change the room name/topic on Gitter. On Matrix (e.g., Element's room state view), look for m.room.name / m.room.topic events from the bridge bot within roughly 30 seconds.
2. Change the same settings on the Matrix side. Confirm Gitter does not change, and that the Matrix value is eventually reverted by the bridge.
3. Run the bridge with debug logging (LOG_LEVEL=debug) and watch for webhook receipt and state-event send lines when you edit Gitter settings.
4. If nothing arrives, check the webhook configuration on the Gitter room's integration settings and the bridge logs for webhook errors.

Caveats

This describes the standard hosted gitter.im deployment; self-hosted Gitter instances and bridge versions may differ, so treat the exact timing and resync behavior as worth confirming against your deployment's logs. One diagnostic that would sharpen the recommendation: whether your bridge logs show webhook deliveries at all when you change a Gitter setting — if they do appear but no Matrix event follows, the problem is inside the bridge rather than in delivery.