Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2162: Signaling Errors at Bridges #2162

Open
wants to merge 17 commits into
base: old_master
Choose a base branch
from
Open

MSC2162: Signaling Errors at Bridges #2162

Changes from 1 commit
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
3131afe
Add MSC2162
Jul 9, 2019
3b468c7
Block style paragraphs for MSC2162
Jul 10, 2019
6606c84
Small fixes
Aug 3, 2019
c6b8c08
Add m.bridge_unavailable and m.no_permission as error types
Aug 3, 2019
cf6723c
Add time_to_permanent property
Aug 3, 2019
909f0c0
Add note about recursive bridge errors
Aug 3, 2019
3ef997c
Add clarifications to m.unknown_event
Aug 3, 2019
766e9dc
Add section for retries and error revocation
Aug 3, 2019
4e852c7
Add special case of unavailable bridge
Aug 3, 2019
6556024
Fix grammar and wording
V02460 Aug 4, 2019
4fe8ffe
Add chapter about rights management
Aug 5, 2019
0212729
Add alternatives regarding MSC 1410
Aug 5, 2019
6eeb102
Add security consideration regarding power levels
Aug 5, 2019
ab27cca
Add note about homeserver impersonation
Aug 5, 2019
d0cd9d4
Make affected_users use an regex array
Aug 5, 2019
9e1f20a
Update time_to_permanent description
Aug 6, 2019
54e0546
Change m.relates_to to m.relationship in examples
Aug 6, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions proposals/2162-signaling-errors-at-bridges.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,11 @@ There are some common reasons why an error occurred. These are encoded in the

* `m.unknown_event` The bridge is not able to handle events of this type.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of the type or format (or both)? A bridge might support text messages, but not HTML, or it might support stickers, but not emotes. The language here implies that a bridge has to support all of m.room.message.

Additionally, with the usual goal of a bridge to be instant messaging, I don't think it's fair to ever raise this error. The event types bridges wouldn't be able to send are the same event types it is unlikely to ever be able to send (server ACLs, room aliases, etc). On the other hand, if the bridge is able to raise this error for subtypes/formats of events it doesn't understand, this could be used to flag that a kick/ban was not carried over.

Can we put some recommendations in here that bridges shouldn't send this error for events outside of its use case (ie: for instant messaging, don't signal errors on ACLs, aliases, and custom event types).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Subtypes are fine, I think I clarified it now in the new version.

Let's assume a bridge that doesn't know about stickers yet. It would be very nice to have a sticker sent in that room trigger an m.unknown_event then.

I am more in favor of whitelisting some events by having the bridge recognize those event and not acting on them at all. Everything that is completely unknown would still trigger this. I don't expect there to be many false positives in practice, but if so, the UI for this type of error could be reduced to something less noisy.


V02460 marked this conversation as resolved.
Show resolved Hide resolved
* `m.bridge_unavailable` The homeserver couldn't reach the bridge.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a subclass to this which has shown to be problematic in recent weeks: When the homeserver is also dead, the users on other homeservers will see the message as delivered when in fact it is not.

I don't know if it makes total sense here given the traffic concern, but maybe flipping this proposal around for positive reactions to messages when they are delivered? Maybe a new kind of m.receipt for this specific purpose.

or maybe we train the general public that the bridge sending a read receipt is fine?

Presumably these ideas have already been covered, so I'm curious as to what the decisions were that led to it not being used.


* `m.no_permission` The bridge wanted to react to an event, but didn't have
V02460 marked this conversation as resolved.
Show resolved Hide resolved
the permission to do so.

Nothing prevents multiple bridge error events to relate to the same event. This
should be pretty common as a room can be bridged to more than one network at a
time.
Expand Down