OptionalbridgeOptionaldisabletrue to disable BridgeContext
parameters in Bridge.onEvent. Disabling the context makes the
bridge do fewer database lookups, but prevents there from being a
context parameter.
Default: false.
OptionaldisableTrue 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".
OptionalescapeEscape userIds for non-bot intents with ~escapeUserId Default: true
OptionaleventThe 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.
OptionaleventOptionalvalidateEditSender?: { allowEventOnLookupFail: boolean }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
OptionalintentOptions to supply to created Intent instances.
Optionalbot?: IntentOptsOptions to supply to the bot intent.
Optionalclients?: IntentOptsOptions to supply to the client intents.
OptionallogTrue to enable SUCCESS/FAILED log lines to be sent to onLog. Default: true.
OptionalmembershipThe 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.
OptionalnetworkA human readable string that will be used when the bridge signals errors to the client. Will not include in error events if ommited.
OptionalonThe factory function used to create intents.
OptionalqueueOptions 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.
OptionalperRequest?: booleantrue 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 ~onEvent is
performing async operations where ordering matters (e.g. messages).
Default: false.
Optionaltype?: "none" | "single" | "per_room"The type of queue to use when feeding through to ~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.
OptionalroomOptionalroomThe room store instance to use, or the path to the room .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.
OptionalroomOptionalsuppressTrue to stop receiving onEvent callbacks for events which were sent by a bridge user. Default: true.
OptionaltrackOptionaluserThe user activity 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.
OptionaluserThe 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.
The controller logic for the bridge.