continuwuation/continuwuity

Fork 41

Sending soft failed events to willing end clients #837

New issue

Open

opened 2025-05-24 21:06:34 +00:00 by Jade · 2 comments

Jade commented

2025-05-24 21:06:34 +00:00

Owner

The tracking and based on previous conversations in the chat rooms.

I think the final conclusion was an account data setting for this to come down normal sync. I believe @nex is working on it

The tracking and based on previous conversations in the chat rooms. I think the final conclusion was an account data setting for this to come down normal sync. I believe @nex is working on it

Jade added the

Matrix/Client

label

2025-05-24 21:07:29 +00:00

nex commented

2025-05-24 21:55:22 +00:00

Owner

This will likely happen in two parts, one will be sending down /sync, and the other will be exposing over /messages. I believe the former will be easier to add, but also, our syncv3 is already a little bit dodgy (see also: #779) and I want to avoid adding more complexity to it for the time being. Perhaps jumping straight to appservices for the time being would be the easiest and also of more use.

nex added the

Enhancement

label

2025-05-24 21:55:39 +00:00

Jade added the

Matrix/Appservices

label

2025-05-24 22:29:57 +00:00

nex changed title from ~~Receiving soft-failed events~~ to Sending soft failed events to willing end clients

2025-05-27 02:47:31 +00:00

nex added this to the 0.6.0 milestone

2025-06-18 16:38:39 +00:00

Jade added the

Difficulty

Medium

label

2025-06-22 23:11:40 +00:00

nex commented

2025-12-18 20:19:25 +00:00

Owner

I currently run a custom patch that allows me to see soft-failed and policy-failed events: nex/continuwuity@e99d88e9d2

There are multiple issues with this however:

We don't currently differentiate between soft-failed and rejected events, which makes us more susceptible to state resets
All clients always receive failed events, which can mess with their view of the room state (e.g. renaming a room, banning a user, and then they update the room name again will result in the room name being set to the soft-failed event)
This approach hacks by just modifying the unsigned data. A real solution would actually differentiate event acceptance types

It might be a starting point to inspire a real impl though

I currently run a custom patch that allows me to see soft-failed and policy-failed events: https://forgejo.ellis.link/nex/continuwuity/commit/e99d88e9d2bcb72bc965e29f0f3fee253463bed3 There are multiple issues with this however: 1. We don't currently differentiate between soft-failed and rejected events, which makes us more susceptible to state resets 2. All clients always receive failed events, which can mess with their view of the room state (e.g. renaming a room, banning a user, and then they update the room name again will result in the room name being set to the soft-failed event) 3. This approach hacks by just modifying the unsigned data. A real solution would actually differentiate event acceptance types It might be a starting point to inspire a real impl though

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

continuwuation/continuwuity#837

No description provided.

Rows
Columns