element-hq / element-hq/synapse

Do not echo/send events created by appservice back out to appservice

Open
#14,776 0 comments 0 reactions 0 assignees View on GitHub
A-Application-Service A-Performance O-Uncommon S-Minor T-Enhancement
Dominant language
Python
Stars
4.6k
Forks
600
Avg merge
5d 22h
Merged PRs (30d)
51

Description

This issue has been migrated from [#14776](https://github.com/matrix-org/synapse/issues/14776).

---

*Spawning from the PoC in https://github.com/matrix-org/synapse/pull/14729*

### Problem

Currently, when an application service (appservice) creates an event, if the appservice is also "interested", we also send that event back out to the appservice (echo). This echo is normally ignored by bridge libraries like with the [`suppressEcho` option in `matrix-appservice-bridge`](https://github.com/matrix-org/matrix-appservice-bridge/blob/a6be350a706379c92344e248e29338bb7c1b9041/src/bridge.ts#L510). But there is significant overhead when it comes to ignoring all of those transactions on the client and even Synapse itself can get backed up with events it doesn't even necessarily need to send out. Instead of having the round-trip just to ignore, we can ignore directly in Synapse to not send it out via the appservice.

We were seeing this problem in real-life with the Gitter -> Matrix import process and made a [quick patch](https://github.com/matrix-org/synapse/pull/14729) to get around this problem. @turt2live also shared a similar t2bot.io patch that they've been running for a long-time: https://github.com/t2bot/synapse/commit/3c1cd9ace85262596523e4316b10b1ead2b5dec5

### Potential solution

There should be a way to ignore events that are created by an appservice to not go back out the appservice that sent it. Or ideally, this behavior should be a sane default. This probably requires a MSC to define the behavior in the AS registration config.

@Half-Shot shared [MSC2487](https://github.com/matrix-org/matrix-spec-proposals/pull/2487) which is related but goes beyond the scope that I care about and given the extra complexity, extra bikeshedding will ensue. Probably best to create a new MSC.

### Potential alternatives

One alternative in the Gitter -> Matrix import scenario is to have something like https://github.com/matrix-org/synapse/issues/3237 which ignores any old events which would work perfectly fine since we're only importing old messages. And on the Gitter side of the bridge, we already ignore any events older than 30 minutes anyway so a solution to that separate issue makes sense in any case. But we should also handle the case for new/any events which this issue addresses.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.