Managed Mjolnirs are being informed of every event sent to the appservice

[Gnuxie]

The mjolnirs will still compare the event against their joined/protected rooms deeper in the chain, so they won't act on any events in rooms they're not joined to or protecting, but this still is problematic and we should have defence in depth.

mjolnir/src/Mjolnir.ts

Lines 533 to 558 in 818e4cf

	private async handleEvent(roomId: string, event: any) {
	// Check for UISI errors
	if (roomId === this.managementRoomId) {
	if (event['type'] === 'm.room.message' && event['content'] && event['content']['body']) {
	if (event['content']['body'] === "** Unable to decrypt: The sender's device has not sent us the keys for this message. **") {
	// UISI
	await this.client.unstableApis.addReactionToEvent(roomId, event['event_id'], '⚠');
	await this.client.unstableApis.addReactionToEvent(roomId, event['event_id'], 'UISI');
	await this.client.unstableApis.addReactionToEvent(roomId, event['event_id'], '🚨');
	}
	}
	}
	// Check for updated ban lists before checking protected rooms - the ban lists might be protected
	// themselves.
	const policyList = this.policyLists.find(list => list.roomId === roomId);
	if (policyList !== undefined) {
	if (ALL_BAN_LIST_RULE_TYPES.includes(event['type']) || event['type'] === 'm.room.redaction') {
	policyList.updateForEvent(event.event_id)
	}
	}
	if (event.sender !== this.clientUserId) {
	this.protectedRoomsTracker.handleEvent(roomId, event);
	}
	}

mjolnir/src/ProtectedRoomsSet.ts

Lines 176 to 178 in 818e4cf

	if (!this.protectedRooms.has(roomId)) {
	return; // We're not protecting this room.
	}

Inspiration should be taken from bridges on how they manage tracking of rooms. The thing is you shouldn't do this naively because it does duplicate effort. Mjolnir instance already track which rooms they are joined to and are protecting, we just don't have a way to map from a roomId to a set of Mjolnirs that are joined to that room.

mjolnir/src/appservice/MjolnirManager.ts

Lines 99 to 104 in 818e4cf

	public onEvent(request: Request<WeakEvent>, context: BridgeContext) {
	// We honestly don't know how we're going to map from bridge to user
	// https://github.com/matrix-org/matrix-appservice-bridge/blob/6046d31c54d461ad53e6d6e244ce2d944b62f890/src/components/room-bridge-store.ts
	// looks like it might work, but we will ask, figure it out later.
	[...this.mjolnirs.values()].forEach((mj: ManagedMjolnir) => mj.onEvent(request));
	}

[Gnuxie]

Loosely related #411

[Gnuxie]

One way to do this is to:

• Provision bridge intents ourselves (whether we extend matrix-appservice-bridge or wrap the bridge class or provide some kind of injection API is TBD).
• Special kind of intent client that has the same listeners as matrixEmitter it is just transparent with respect to whether the events are sourced from /sync or appservice magic
• The intent only emits events when .start has been called like the bot-sdk syncing client
• We keep a persisted cache of the joined rooms for each intent. We always update this cache when we notice the intent being added/removed from rooms.
• When the intent is created, we call joined_rooms and shouldn't have to again.
• We recognize that although the transactions api in theory ensures the appservice is informed about all events, this isn't always the case, state resets happen and we already had a misconfiguration issue on mjolnir.matrix.org where Synapse "forgot the appservice existed".
• To counter this whenever we get an error for "user not in room" or "user banned" etc we invalidate the cache for that intent and recalled joined_rooms. This has to be a hidden process that is always active regardless of whether .start has been called and the intent is "running".
• We need to decide on the semantics of .start and .stop, does the appservice queue events while the intent has been stopped? Or are we free to discard them?

[Gnuxie]

Technically is blocked on #415 but if you just use the data store interface you'll be able to get most of it done