The controller logic for the bridge.
true
to disable BridgeContext
parameters in {@link Bridge.onEvent}. Disabling the context makes the
bridge do fewer database lookups, but prevents there from being a
context
parameter.
Default: false
.
True to disable enabling of stores. This should be used by bridges that use their own database instances and do not need any of the included store objects. This implies setting disableContext to True. Default: false.
The domain part for user_ids and room aliases e.g. "bar" in "@foo:bar".
Escape userIds for non-bot intents with {@link MatrixUser~escapeUserId} Default: true
The event store instance to use, or the path to the user .db file to load.
A database will NOT be created if this is not specified. If disableStores
is set,
no database will be created or used.
Should we validate that the sender of an edit matches the parent event.
If the parent edit event could not be found, should the event be rejected.
The base HS url
Options to supply to created Intent instances.
Options to supply to the bot intent.
Options to supply to the client intents.
True to enable SUCCESS/FAILED log lines to be sent to onLog. Default: true.
The membership cache instance to use, which can be manually created by a bridge for greater control over caching. By default a membership cache will be created internally.
A human readable string that will be used when the bridge signals errors to the client. Will not include in error events if ommited.
The factory function used to create intents.
Options for the onEvent
queue. When the bridge
receives an incoming transaction, it needs to asyncly query the data store for
contextual info before calling onEvent. A queue is used to keep the onEvent
calls consistent with the arrival order from the incoming transactions.
true
to only feed through the next event after the request object in the previous
call succeeds or fails. It is vital that you consistently resolve/reject the
request if this is 'true', else you will not get any further events from this queue.
To aid debugging this, consider setting a delayed listener on the request factory.
If false
, the mere invocation of onEvent is enough to trigger the next event in the queue.
You probably want to set this to true
if your {@link Bridge~onEvent} is
performing async operations where ordering matters (e.g. messages).
Default: false.
The type of queue to use when feeding through to {@link Bridge~onEvent}.
none
, events are fed through as soon as contextual info is obtained, which may result
in out of order events but stops HOL blocking.single
, onEvent calls will be in order but may be slower due to HOL blocking.per_room
, a queue per room ID is made which reduces the impact of HOL blocking to be scoped to a room.Default: single
.
Application service registration object or path to the registration file.
The room store instance to use, or the path to the room .db file to load.
A database will be ClientFactoryEncryptionStorecreated if this is not specified. If disableStores
is set,
no database will be created or used.
True to stop receiving onEvent callbacks for events which were sent by a bridge user. Default: true.
The user store instance to use, or the path to the user .db file to load.
A database will be created if this is not specified. If disableStores
is set,
no database will be created or used.
Generated using TypeDoc
The client factory instance to use. If not supplied, one will be created.